既知のバグを抱えたまま発売日に間に合わせた場合、「スピードのために品質を犠牲にした」と捉えられがちです。しかし実際には、逆のことが起きる場合が少なくありません。バグによって、スピードが失われるのです。オートモティブ、医療機器、一般的なソフトウェア開発の現場でエンジニアリングや品質を率いる方々は、これをトレードオフというより、一つの仕組みとして語っています。次のリリース日をめぐる議論が始まる前に、一度整理しておく価値があります。
この対立は、双方の話がすれ違うことから生じがちです。経営層はリコールのような重大事態を懸念し、開発現場は壊れやすいコードや、遅くて古いツールを懸念しています。どちらも同じプレッシャーに反応しているだけで、その両端に立っているにすぎません。
「二者択一」という思い込み
スピードと品質を相反するものと考えるのは、無理もないことです。品質への投資、とりわけテストは、短期的にはチームの速度を落とします。これは事実であり、軽く扱わずにはっきり認めておくべき点です。
ただし、効果が現れるのは後になってからです。品質を工程の初期から組み込んだシステムは、次のフェーズで手戻りを起こしません。開発段階で見つかるはずだった問題を、本番環境で修正するためにチームが引き返すこともありません。時間が戻ってくるのは、投資したスプリントではなく、その後のすべてのスプリントです。予定外の修正に振り回されなくなるからです。
持続的な速度は、品質を省くことではなく、品質を確保することから生まれます。
一度は素早くリリースできても、その後の対応に追われるチームは、そもそも速かったとは言えません。コストを先送りしたにすぎないからです。実際には、テスト、レビュー、重要な判断を、リリース直前に集中させるのではなく、設計の時点も含めてプロセス全体に分散させることになります。
「鉄の三角形」の正しい理解
プロジェクトマネジメントでは、このトレードオフに「鉄の三角形」という名前が付いています。三つの頂点はスコープ・期間・コストであり、品質は含まれません。品質は三角形の中心にあり、この三者のバランスがどれだけ取れているかの結果として決まるものです。時間と引き換えに手放せる、四つ目の調整項目ではありません。
この違いは重要です。品質は、削って時間を買い戻せる頂点ではなく、スコープ・期間・コストのバランスがすでに崩れているときに現れる結果です。スコープが固定され、期間もコストも厳しい状況では、意図して品質を下げるわけではなく、副作用として品質が下がります。しかも、それが事前に知らされることはほとんどありません。
ツールや自動化は、このプレッシャーがかかる場所を変えます。テストプロセスを自動化すれば、スコープにもコストにも手を付けずに時間を取り戻せます。その時間は、スピードの向上やテストの拡充、あるいはその両方に振り向けられます。
その一例が、カバレッジ率を一律に追い求めるのではなく、実際のリスクに基づいて関数に優先順位を付けるアプローチです。限られたテスト時間を、不具合につながりやすいコストに集中させられます。これは、品質だけは三角形の制約から外れてほしいと願うことではなく、三角形そのものに働きかける手段です。チームはスピードと品質を両立できるのか、と考えているのであれば、より的確な問いは、品質に必要な余裕を確保するために、スコープ・期間・コストのどこへ投資すればよいか、ということです。
後工程での修正コストは、余裕のないシステムほど大きくなる
欠陥の修正コストは、一様に上昇するわけではなく、どこでも同じように上昇するわけでもありません。Barry Boehm 氏と Victor Basili 氏のその後の研究では、欠陥を後から修正する場合と早期に修正する場合のコスト比は、開発対象によって異なることが示されています。
この差こそが要点です。後から見つかった欠陥が、単なるコード修正では済まず、再設計・再認証・リコールを引き起こす場合に、影響は最も大きくなります。これはまさに安全重視ソフトウェアの特徴であり、早期の欠陥検出がとりわけ大きな効果を発揮する理由でもあります。
ただし、これはあらゆる場面に当てはまる法則ではありません。そうだと主張する説明に懐疑的になるのは当然です。この問いに関するこれまでで最大規模の実証研究（産業界の 171 プロジェクトが対象）では、欠陥が未検出のまま経過した期間と修正コストとの間に、全体として一貫した関係は見られませんでした。ただし、二つの結果は実際には矛盾しません。コストの上昇は、後工程の欠陥が構造的な手戻りを招く大規模・高信頼性システムでは確実に現れ、そうならない小規模または影響の小さいコードベースでは目立たなくなります。単一の倍率よりも、プロジェクトがどちらに当てはまるかのほうが重要です。
どちらの研究にも表れない、もう一つの見えにくいコストもあります。コードを最初から正しく書けていれば、その担当者のもとへ同じ問題が戻ってくることはありません。一方、欠陥を含んだコードは、誰も予期していないタイミングで再び表面化し、その担当者が本来進めていた作業を中断させがちです。
リリース日をめぐる話し合い
リリース日をめぐる議論は、開発部門と事業部門の間で最もよく起こる摩擦であり、解決策は透明性です。既知の不具合を抱えたまま出荷するかどうかは、なりゆきではなく、意識的に決めるべきことです。
開発側はスピードが優先だと考え、経営層は品質が優先だと考えている場合、そのずれは何かが壊れるまで表に出ません。壊れたときには、誰もが責任の所在を探し始めます。リリース日が確定する前にトレードオフを言葉にしておけば、事後の議論が、チーム全体で下した決定に変わります。具体的には、リリースの最低基準、譲れない品質特性、基準を下回って出荷した場合のコストを、IT の細部ではなく、事業側が判断に使える言葉で事前に合意します。
10 年間安定して動作しなければならない車載部品と、展示会で見栄えさえよければよいデモとでは、求められる水準がまったく異なります。デモは故障しても手作業でリセットできますが、車載部品はそうはいきません。
固定の品質チェックポイントを設けると、「ウォーターフォールに戻るだけではないか」という反応が返ってくることがよくあります。これは、日々のチームの進め方と、リリースの承認方法という、別の二つのことを混同しています。前者はアジャイルのスプリントが担い、後者は、アーキテクチャレビュー、セキュリティスキャン、リリース準備確認といった少数の固定チェックポイントが担います。チームがそう呼ぶかどうかにかかわらず、です。
SAFe（Scaled Agile Framework）は、まさにこの組み合わせ、つまりチームレベルではアジャイル、リリース時には構造化されたチェックポイントを体系化したものです。アジャイルの原則を否定するものではありません。リリースを出荷するという判断は、スプリント分のコードを書くこととは性質が異なる、というだけのことです。実際には、テスト開始前に適切な関係者が集まって行う、20 分程度のリリース準備確認でも十分に機能します。
ビジネスケースの作り方
品質が大切だという一般論で、経営層が動くことはまずありません。効果があるのは、数字を添えることです。
実用的なモデルの一つは、広く引用されている「開発者は、既存コードを安全に変更できるようになるまでに、作業時間の約半分を理解のために費やす」という前提から出発します。たとえばアーキテクチャ検証の自動化によって、この理解にかかる時間を 4 分の 1 短縮できれば、プロジェクト全体では 12.5% の削減になります。これを人件費に当てはめれば、投資対効果の数値が導き出されます。こうしたコストを正確に把握している組織はほとんどなく、それで構いません。モデルに正確さは求められません。事業側のリーダーが前提を検証し、自分の数値に置き換えられる程度に、シンプルで透明性があれば十分です。
もう一つ、明確にしておきたい捉え直しがあります。品質チームにかかるコストと、現場で障害が起きる可能性とを比べるのではなく、近道を選んだことで生じる問題と、近道を選ばないことで避けられる問題のどちらがコストが大きいかを問うのです。これは、品質を最小化すべき予算項目として扱うのではなく、経営層が判断に使える比較になります。
素早く、そして計画的に動く
初日からあらゆるチェックを前倒しにすべきだという話ではありません。プロトタイプ、デモ、最初の機能サンプルに、量産レベルの厳密さは必要なく、その段階で素早く動くのは正しい判断です。
安易なスピードは、初日から土台として必要なチェックを省き、後から追加できると考えます。規律あるスピードは、どの段階でどのチェックが必要かを理解し、その計画を守ります。後回しにできる品質への投資もあれば、そうでないものもあります。そうでないふりをするところに、本当のコストが隠れています。早い段階でチームが取り組む内容は、顧客と合意したスケジュールに見合った水準にするべきであり、それを下回ってはなりません。
速度と品質はダイヤルの両端ではない
問われているのは、コストのどれだけを、今コントロールされた形で支払い、どれだけを、後からはるかに高い価格で、しかも最悪のタイミングで支払うか、という点です。品質を持続的なスピードを支えるものと捉えれば、リリース日が開発サイクルのたびに蒸し返されることはなくなります。
この対話を始めるための三つのステップをご紹介します。
-
「どちらか一つを選ぶ」議論を、予算の議論に置き換える
スピードと品質を両立させる必要があるときは、どちらを犠牲にするかではなく、どのようなツールや自動化への投資で時間を取り戻せるかを問います。
-
納期のプレッシャーがかかる前に、リリースの最低基準を決める
譲れないことと、柔軟に対応できることを合意します。基準を下回って出荷した場合にどうなるかを、関係者にも理解してもらいます。
-
シンプルなコストモデルを一つ作り、毎回使い回す
経営層が検証し、調整できる、大まかで透明性のあるモデルのほうが、誰も信用しない精緻な数値よりも説得力があります。
スピードと品質は、どちらも同じ判断から生まれます。
