――いま、木曜日の19時。明日は、1時限目に「オペレーティング・システムII」の中間試験があるとします。必修科目なので、単位を落とすと卒業できません。別のプロジェクト演習に時間を取られたり、家族が入院したり、バイトで事件があったりして、まったく勉強時間を確保できず、いまから徹夜で勉強することになりました。翌朝まで寝ないで頑張っても、12時間しかありません。徹夜で試験対策をしても、試験範囲をすべてカバーすることが不可能な場合、どうするか？こんなとき、4000年前の古代中国やエジプトの時代からヤマを張ってきました。

　「中間試験のヤマを張ること」と、「十分な開発時間が取れないソフトウェアのデバッグ」はよく似ています。

　まず、試験範囲を洗い出し、一番重要な個所をピックアップし、枝葉の部分は潔く捨てます。残りの12時間で、幸運にもこの「最重要個所」をカバーできれば、捨てた部分から「次に重要な個所」を攻略するか、明日に備えて睡眠を取るのですが、通常は、「最重要個所」を全部カバーできないので、ヤマを張ることになります。

　「中間試験のヤマを張ること」と、「十分な開発時間が取れないソフトウェアのデバッグ」は似ていますが、決定的に違うことが2つあります。1つは「良いニュース」で、もう1つは「悪いニュース」です。

　まずは、悪いニュースから。中間試験の場合、合否結果が出れば、良くも悪くもそれで終わりますが、ソフトウェアの出荷は「終わり」ではなく「はじまり」である点です。製品を出荷してはじめて、ユーザーが使いはじめます。ソフトウェアをリリースした後に顧客サイドでバグが出れば、その責任を取らねばなりません。

　良いニュースは、ソフトウェアの場合、「先生（顧客）」と交渉して、「試験範囲（実装機能）」を減らしてもらったり、「試験日（出荷日）」をずらしてもらえる可能性があることです。「第4章の『仮想記憶』の部分は、期末試験に回してください」とか、「試験の実施日を来週の月曜日にしてください」とお願いするようなものです。もちろん、中間試験でこんなお願いをされて、「うん、いいよ」と笑顔で承諾する先生は皆無でしょうが、ソフトウェア開発の場合は十分にあり得ます。

　出荷日を厳守しないと、発注側のビジネスが大打撃を受ける場合、機能を削減しても、納期を守ることになるでしょう。そうでないと、発注側、開発側の双方が共倒れになります。あるいは、機能をすべて実装することが納期より優先度が高い場合、出荷日をずらさざるを得ません。機能削減も、納期延長もダメな場合、最後の手段が「品質での手抜き」です。

1．2．システマティックな手抜きのステップ

　日本のソフトウェア開発エンジニアには、「これまで、高品質のプログラムを作ってきたし、これからも作らねばならない」という強い信念やプライドがあります。良い悪いや、好き嫌いは別にして、この精神的なバックボーンが、アメリカやインドのソフトウェア技術者と決定的に違う点です。

　品質が非常に重要な日本人エンジニアでも、時には、品質で手を抜かざるを得ない場合があります。そんな場合、いつもいっていますが、「手を抜いていることをキチンと認識し、エンジニアリング的に手を抜く」ことが非常に重要です。決して、行き当たりばったりに手抜きしてはなりません。正しく、システマティックに手を抜くことが、プロのエンジニアの態度です。

　以下に、「システマティックな手抜き」のステップを記述します。

（1）手を抜く前の段階として、テスト項目、テスト・シナリオは、手を抜かず、きちんとフルセットで作ることが重要です。テスト項目やシナリオの設計は、要求仕様が凍結できた時点から着手可能ですし、その時点から設計すべきです。テスト項目やシナリオのフルセットを設計する時間もないなら、このプロジェクトは、誕生時から失敗していることになります。こうなると、エンジニアリングで解決できる問題ではなく、経営戦略や政治的な問題になります。

（2）テスト項目やシナリオのフルセットを設計するときに（この時点では、プロジェクトがデスマーチ化するとは思っていないことでしょう）、将来、時間が足りなくなってプロジェクトが大混乱するかもしれないと予想し、機能ごとに、「品質確保策を完全に実施」「かなり実施」「そこそこ実施」の3つに分類しておきます。寿司の「松」「竹」「梅」みたいなものです。具体的には、テスト項目やシナリオを、「そこそこ実施」で実行する必要最低限のテスト項目、「かなり実施」で追加実行するテスト項目、「完全に実施」で走らせるテスト項目に分類します。「完全に実施」では、テスト項目やシナリオのフルセットを実行することになります。

（3）プロジェクト・マネージャは、品質、スケジュール、コストに関し、最低限、週に1回はプロジェクトの現状を具体的な数字で割り出し、将来の予想を立てます。いま現在、保有している人月と、これからの作業に必要な人月を天秤（てんびん）に掛け、フルセットの品質確保策、すなわち、「松」でいけるのか、それとも「梅」にしなければならないのかを動的に決めるのです。

（4）残りの日数や人月で、「梅」も実施できないなら、もはや、エンジニアリングをベースにしたプロジェクトではなく、単なるギャンブルです。あるいは、投資格付け会社の評価で、「BB」より下の「ジャンク・ボンド」や「投資不適格債」のようなものでしょう。ジャンク・ボンドの場合、債務不履行にならないことの方が多いでしょうが、ソフトウェア開発プロジェクトでは、このままでは必ず破滅します。早急に、何らかの抜本的な対策が必要です。

2．「松」「竹」「梅」の具体的な方策

2．1．「7つの基本的な出荷基準」の再掲

　本コラムではこれまで、ソフトウェアを出荷する際に満足していなければならない「7つの基本的な出荷基準」の詳細について述べてきました。この概要を以下に再掲します。

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

　品質で手を抜く場合、この7つの基本的な出荷基準の一部を、あるいは全部を割愛することになります。その“手抜きのガイドライン”、すなわち7つの基本基準と、品質確保での「松（手抜きせず）」「竹（少し手を抜く）」「梅（きちんと手抜きする）」の関係を表1に示します。


	①同値分割での機能テスト	②境界値分析		③パス網羅（含机上での網羅）	④バグ推測
	①同値分割での機能テスト		境界値	③パス網羅（含机上での網羅）	④バグ推測	限界値
そこそこ実施（梅）	○	○	○	―	―
かなり実施（竹）	◎	◎	◎	C0を80％以上	外部破壊、深刻のみ
完全に実施（松）	●	●	●	C1を80％以上	外部破壊、深刻、プラス、中程度


	⑤極限テスト			⑥バグの収束	⑦バグ修正
	過負荷テスト	長時間耐久テスト	最大構成テスト	⑥バグの収束	⑦バグ修正
そこそこ実施（梅）	―	―	○	無視	外部破壊、深刻
かなり実施（竹）	―	○	◎	考慮	プラス、中程度
完全に実施（松）	●	●	●	十分考慮	すべて
表1　品質手抜きのガイドライン

　表1で、①②……は、7つの基準の①②……に対応しています。また、○は「代表的なものを実施」、●は「フルセットを完全に実施」、◎は「その中間」、―は「実施せず」を意味します。

　次回、この表の詳細について解説していきます。お楽しみに！（次回に続く）

【筆者紹介】

山浦恒央（やまうらつねお）
東海大学大学院組込み技術研究科助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」（Academic Press社、共著）、「ピープルウエア第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。