例えば、もし世界で初めて電気自動車(EV)を作るのであれば、いきなり最終製品を大量生産するのは大きなリスクがあります。まず、シャシー、タイヤ、電池、モーターだけを載せて、正常に走行するかをチェックし、問題があれば設計仕様を改善します。これが第1ラウンドです。致命的な問題が最終工程で出るのは避けられます。
第2ラウンドとしてシャシーにボディーを載せ、サーキットで走行させます。ここで、さらに問題点を改善し、最終工程として、GPS、エアコン、カーステレオ、エアバッグなど、フル装備でテストし、問題がなければ最終形として生産体制に入ります。
このように、数回に分けて開発するのがスパイラルモデルです。「ウオーターフォールモデルを何回か繰り返す開発方式」であり、ウオーターフォールモデルの派生型といえるでしょう。
何回繰り返すかはプロジェクトによりさまざまで、2回の場合もあれば、1週間で1回、回していたプロジェクトもありました。何回、繰り返すにしても、最重要課題は「品質が良いこと」です。バグだらけだと、1回も回りません。
初めての顧客用にシステムを開発する場合や、経験したことがない新しい分野のソフトウェアを開発する場合、スパイラルモデルをおススメします。今回の「ワインショップのECサイトの開発」では、スパイラルモデルを採用し、小さい単位で細かく開発することで、仕様の誤解を防ぎ、顧客からの変更要求にも柔軟に対応できるようにします(図3)。
以下に、図3で示した3つのバージョンを解説します。
このように、発注側からフィードバックをもらいながら進めることで、最終段階での致命的なダメ出しや、急激な仕様変更に対応できます。
今回は、前回に続けて要求仕様フェーズの問題点を整理し、その対処法を紹介しました。要求仕様フェーズの問題点は解決するのが非常に大変で、どんな組織であっても何らかの悩みを持っています。
学生の皆さんは、会社に入ると、要求仕様フェーズの問題と嫌でも戦うことになります。今はあまりイメージできないかもしれませんが、問題点と対処法を知識として頭の片隅に入れておいていただければと思います。
本連載で取り上げた「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.