イチから全部作ってみよう（15）テストの第一歩「セルフチェック」が大惨事を防ぐ：山浦恒央の“くみこみ”な話（184）（3/3 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

5．バグが見つからないとどうなるか

　要求仕様書のセルフチェック（レビューなども含む）をしないまま先に進めると、潜在するバグが次の工程へ波及し、前のフェーズに戻って作業する必要があります（図4）。

図4　工程が戻るイメージ［クリックで拡大］

　図4は、ウオーターフォールモデルにおいて、バグが波及していく様子と手戻りのイメージです。ウオーターフォールモデルは、次のフェーズに行くだけとの誤解がありますが、逆方向へも進みます。

　要求仕様を定義するフェーズでバグを潰しておかないと、次の設計、実装、テストフェーズにバグが波及し、バグが深く広く拡散します。仕様書段階なら数百円で修正できたバグも、顧客にリリースした後では、修正に数千万円もかかります。例えば、銀行のATM制御プログラムにバグがあると、バグ修正のために24時間稼働のシステムを一時、止めねばなりません。システム停止は短時間なので、その間にシステムの入れ替えと、正常に稼働するかのチェックが必要です。「短時間の1回勝負」は、精神的に大きなストレスになります。時間的な余裕がある要求仕様フェーズでバグをしっかり潰しましょう。

　バグが見つかると、手戻り（前の工程に戻って作業する）が発生するでしょう。例えば、実装フェーズで要求仕様起因のバグが発生する場合は、要求仕様フェーズに戻って修正することになります。これは、すごろくで1マス進んだつもりが、「止まったマスで4マス戻れ！」と言われる絶望感と変わりありません。

　セルフチェックでは全てのバグは潰せず、次の工程へ波及するバグもあります。他人が使う製品は、まずは「確実にセルフチェックをすべき」というのが筆者の意見です。これは、ウオーターフォール、アジャイル、スパイラルなどの開発方法論にもよらない最低限のことだと筆者は考えています。

6．おわりに

　今回は、作成した要求仕様書のセルフチェックに着目しました。まず、「自分の完璧」がいかにあてにならないかとのイメージを共有し、自分自身で要求仕様書をセルフチェック（脳内シミュレーション）しましょう。「やっておいてよかった」と思うバグが必ず見つかります。

　セルフチェックで全てのバグが見つかるわけではありませんが、セルフチェックは必要条件です。後工程で大事件が起きないよう、まずは自分自身でしっかりチェックする必要があります。

山浦先生執筆の書籍が販売中です！

　本連載で取り上げた「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。

　前著「ソフトウェア技術者のためのバグ検出ドリル」（2019年11月刊行）も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。

画像クリックで出版社のWebサイトへ

　両書とも興味のある方は、Amazon.comや書店でチェックしてください！

【 筆者紹介 】

山浦 恒央（やまうら つねお）

東海大学 大学院 組込み技術研究科 非常勤講師（工学博士）

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

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