「3匹の子豚」から学ぶ品質の優先順位付け：山浦恒央の“くみこみ”な話（11）

　大混乱したソフトウェア開発プロジェクトを生き抜く有望な方法の1つとして、「トリアージュ（野戦病院方式）」があります。

　前回のコラム「サボりのモジュール化・サボる部分の独立化」では、ソフトウェア開発でトリアージュを適用する際に必要となる“開発する機能の優先順位付け”について解説しました。今回は、各機能の“品質の優先順位付け”について説明したいと思います。

品質の優先順位と『3匹の子豚』

　最前線の野戦病院では、医者や看護師、薬、ベッドの数が限られており、この限られたリソースだけで、次々に運び込まれる負傷兵の治療をしなければなりません。必然的に負傷兵の優先順位、すなわち「すぐに手当てをしないと死亡する」「重傷」「軽傷」を考慮して、限られた医療リソースを割り当てることになります。これをソフトウェア開発に置き換えると、「必須機能」「必要機能」「希望機能」の3つの優先順位を付けるのが普通です。これが「機能の優先順位付け」であり、「何を作るのか」の取捨選択となります。

　ここまでが前回のコラムで紹介した内容ですが、優先順位付けには、もう1つ「どの程度まで作るのか」という“品質的な要件”が存在します。

　「2階建ての家を建てる」が機能的な要件だとしたら、どの程度ちゃんとした家を建てるのかがこの品質要件に当たります。雨風がしのげればベニヤ板1枚のあばら家でもいいのか、震度8の激震でも壊れない頑丈な鉄筋コンクリートの家を建てるのかということです。同じ家でも、品質要件が異なると価格で数百倍もの違いが発生します。どんな家にするのか、ある意味、藁（わら）の家、木の家、レンガの家を建てた童話、『3匹の子豚』の家と同じです。

「ブー・フー・ウー」の工学的解釈

　家を建てる場合、単に雨風を防げればよいのであれば、「藁の家」で十分ですし、布1枚のテントでも構いません。時間とお金をかけてレンガ造りの家を建てるのは、ある意味、“過剰品質”となります。例えば、テキスト・エディタ用のソフトウェアの品質を、原子力発電所制御システムで必要な品質レベルまで高めるようなことは、時間とお金を無限に投入できる「個人の趣味の世界」でのみ可能なことです。

　エンジニアリングとしてのソフトウェア開発では、吉野家の牛丼のキャッチ・フレーズ、「安い・うまい・早い」を工学的に実現すること、すなわち、「低価格で、高品質の製品を早く提供する」が超基本です。「投入するお金と時間」と、その結果得られる「品質」のバランスを常に考える必要があるのです。

　『3匹の子豚』では、怠け者の「ブー」と「フー」が「藁の家」と「木の家」を造ってオオカミに壊されてしまい、「ウー」がまじめに造ったレンガ造りの家はオオカミを撃退できたことから、「サボらずキチンと生活しましょう」との教訓を子供たちは学ぶことになります。

　『3匹の子豚』の話をエンジニアリング的に見ると、「家を建てる」という機能案件と、「オオカミが襲ってきても壊れない」という品質案件のお話と見ることができます。品質要件を満たしていなかったことが「良くないこと」であり、逆に、「オオカミの襲撃に耐性がある」という品質要件がなければ、「藁の家」が正解です。

　童話では「正直と真面目」が基本であり、美徳ですので、「夜露をしのいで寝られればよい家があれば十分なのに、必要以上に頑丈で立派なレンガの家を建て、破産してしまいましたとさ」という皮肉っぽい過剰品質のストーリーはあり得ませんが……。

品質の優先順位

　では、品質の優先順位をどのように付ければよいでしょうか？

　機能の優先順位同様、細か過ぎては混乱を招きます。例えば、品質の優先順位を10段階に分けると、「6」と「7」の違いがよく分かりませんし、「6」にするのか「7」にするのかで余計な時間を使ってしまいます。混乱プロジェクトでは、「時間」が最もクリティカルなリソースですので、分類で悩むようでは優先度を導入した意味がありません。

　機能を「必須」「必要」「希望」の3つに分類したように、品質も「必須」「必要」「希望」の3つに分けるのがよいでしょう。具体的にどのようなテストをすれば、3つの品質レベルのそれぞれを満足できるのかを知っておくことも重要ですが、その前に、一般的な「ソフトウェアの品質的な出荷基準」について考えてみましょう。

　品質で手を抜く前に、「望ましい姿」や「本来の品質」をきちんと把握することが重要です。

出荷品質の基準

　いつ、ソフトウェアを出荷するのか？ 何をもって、ソフトウェアが出荷品質に達したと判断するのか？ これはソフトウェア技術者の“永遠のテーマ”です。いろいろな考えがありますが、グレンフォード・マイヤーズの古典的名著、『ソフトウェアテストの技法』に書いてある必要条件と、私の経験則を加えた「基本的な出荷基準」は以下のとおりです。

1. 全機能をテストした
   ブラックボックス／ホワイトボックス・テストで同値分割を実施した。
2. 境界条件をテストした
   ブラックボックス／ホワイトボックス・テストの境界値分析を実施した。
3. 未実行コードがない
   ホワイトボックス・テストのC0パス網羅を満足した。
4. エラー・ゲシング（Error Guessing）を実施した
   バグを想定し、それを摘出するためのテスト項目を設計・実施した。
5. 長時間耐久テスト、過負荷テストを実施した
   48時間の連続運転や、過負荷状態での稼働テストを実施した。
6. バグの発生が頭打ちになった
   いわゆる「バグ摘出曲線」がフラットになった。
7. 未修正のバグが残っていない
   摘出したバグは全件修正した。

　上記の7つの基準をすべて満たしたときに、ソフトウェアを出荷するのが理想であり、品質の「必須」「必要」「希望」をすべて満足したことになります。この7つの基準の取捨選択、および、各基準を満足するレベルにより、「必須」「必要」「希望」で何を実施すべきかが決まります。

　次回は、7つの基準の詳細を解説しながら、「必須」「必要」「希望」でどのレベルまで実施すべきかについて紹介したいと思います。お楽しみに！ （次回に続く）