常松さんの新著、アジャイルプラクティスガイドブックに、監修としてお手伝いさせていただきました。
本書には11本のコラムが掲載されているのですが、うち一本を私の方で書かせていただきました。技術プラクティスの説明のために技術的負債という用語を使う方は多いと思いますが、デプロイの自動化がどのようにメリットがあるのかを説明してみた、というコラムになります。
許可をいただき、こちらのブログにも掲載させていただくことになりました。校正中の原稿ですので最終稿は少し変わるかもしれませんが、ご賞味いただければ幸いです。
本原稿については、特別に角征典さん、大金慧さんのレビューをいただきました。ありがとうございました。もともと伝えたいことがだいぶ散漫だったのですが、多少読めるものになったとすれば、お二人のおかげです。
技術的負債 - 問題発見までの時間とリスクをビジネス側に説明する
技術プラクティスに関わるコストについて話していると、「開発者たちは認識しているが、ビジネス側に説明しにくい」という意見を聞くことがあります。まさにそういうケースで発明された用語が「技術的負債」です。経営者や財務担当者にとって、負債は必要な時にはとるべきリスクであり、一方で溜めてしまえば会社を危機にさらすものだと理解されています。この負債をメタファーとして使って、エンジニアが抱えている課題を説明しようとしました。例えば、「問題の発見までの時間がかかっている」ことは、現時点ではリスクにすぎませんが、緊急の障害が発生した場合には、そのビジネスを危機にさらすことになります。当面は問題ないように見えるかもしれないが、実は大きなリスクがあるということをビジネス側の人にも共有しておき、リスクを減らすための投資として技術プラクティスを調べたり、適用するコストをとることの共通理解を作りたい。アジャイル開発を作り上げてきた先達も、エンジニアでありながら、相手に伝わるようなうまい説明を編み出し、かかわっているビジネスの成功を目指してきました。
しかし、ただ「技術的負債があるから返済したい」と言っても、ビジネス側の人には伝わりません。具体的なエピソードにかみ砕いて伝える必要があります。一つの例として、問題が見つかってから、直すまでにかかる時間について、いくつかのケースを通じて考えてみます。
1.リリース前の手動テストに頼っている
初期にプロトタイプとして作ったアプリケーションが、よい評価を受けて本番に成長していく過程では、自動テストは後回しにしておき、自分で動かして確認た上で他の人に渡す、というケースがよくあります。自動テストができることよりも、新しい機能を早く客に見せたいと判断するケースはこれに当たります。リリースした後に問題が発見され、数週間前に作った部分のどこかにあるであろう原因を調べる必要が出てきます。報告者の勘違いで問題がない可能性も考慮に入れるべきですし、かなり広い範囲の推測を頭に描きながら、問題の理解に頭を使うことになります。これはストレスも高い作業です。そして、対応をリリースすると、さらにその変更によって同じような問題を埋め込んでしまうことすらありえます。サービスが正常に動いている状態に戻すには、リリース前の状態に戻す必要があります。もし、このタイミングでリリースしないといけない機能がある場合、かなり難しい判断を迫られることになります。
2. テストを自動化して、毎日ビルドとテストを行っている (デイリービルド)
以前は毎日ビルドを行うことをデイリービルド、夜間に行えばナイトリービルド、などと呼んでいました。ビルドを自動化して毎日自動的にチェックするようにすれば、翌日には問題が発見されることになります。ただし、テストケースの範囲内だけですが。少なくとも、ビルドできない、などの致命的な問題は発見できます。昨日行った作業のどこかに問題があったということはわかるため、まず一旦そのコミットを取り消して前日の「動いていた」状態に戻すことができます。一日分の作業を一時的に戻すだけなので、それほど大きなインパクトはない可能性があります。その上で、その後に行ったコミットを確認して、怪しいところを探り出していきます。
3.コミットをフックして、自動的にテストが走る（継続的インテグレーション）
コードの修正をメインブランチにプッシュすると、自動でテストが走るようにしておくことを、継続的インテグレーションといいます。開発者たちにとっては、作業完了ごとにさまざまなフィードバックが得られるようになります。それまでに「動いていたコード」と「パスしていたテスト」のいずれかが、「先ほどの作業」で動かなくなったということがわかります。原因を探すために検討すべき範囲は非常に狭くなります。製品を作り込んだ１０分後に問題が発見されたなら、まずはその１０分間にした作業を疑うだけでよいですし、その部分を一旦捨てることは容易でしょう。
アジャイル開発では「既知の不具合はない」状態を維持することを目指します。それは既知の問題に関するテストを自動化しておいて、人間はそれ以外の部分をちゃんと探索するようにしよう、ということです。「ゼロバグトレランス（Zero Bug Tolerance）」ともいいます。もちろん我々は全知全能ではないので未知の問題は発見できないわけですが、この状態をなるべく高い頻度で確認できる状況を作り、維持することで「次に問題が見つかったとき」の反応速度が向上し、障害対応時の心理的負荷が下がります。そして「今は深刻ではないが、いずれ大きな問題になるかもしれない懸念」について、早い段階で検討することができるようになります。心の余裕を持ちながら、検討を忘れない慎重さが生まれてきます。品質の悪いコードを抱えているチームほど、次に発生する問題に対する余力は少なくなり、しばしば明確に存在している問題にすら対応できません。
「それは理解しているものの、ビジネス側から継続的インテグレーションやテスト作成のための時間を許可してもらえない状況だ」という相談を受けたことがあります。こうしたときに「技術的負債」のアイデアを活用して、ビジネス側にもわかるように説明することができるかもしれません。以下のように説明してみるのはいかがでしょうか。
バグが少なく、問題点の修正が早いということは「アジリティ」すなわち「近い将来のビジネスの変化についていくためのスピード」を向上させることにつながります。技術プラクティスを自分たちの選択肢として使えるようにしていくことは、ビジネス価値を高めることにつながります。まだそうなっていないのは、これまで対応のコストをかけてこなかったからかもしれません。その部分を「技術的負債」として考えることで、未来への投資となることがわかります。もちろん、いきなり大きな時間をかけてシステム全体をカバーする自動テストを書くなんてできませんし、まずは目の前にある1 つの変更点から、自動テストを足がかりにしていきます。
具体例を使って説明することで、ビジネス側の人にもリスクを伝えることができます。技術的負債を解消することには、ビジネス的に価値があります。「なぜそんなこともわからないんだ！」口にしてしまう前に、一歩一歩説明する勇気を持ってみましょう。深刻な問題が起きてしまう前に、こうしたことを話す勇気を持っておきたいものです。今日からでも遅くはないはずです。
次の第３章では、こうしたビジネス環境を作るための具体的な方法として、継続的インテグレーションと継続的デリバリーについて説明します。
