イチから全部作ってみよう（4）要求仕様フェーズに潜むさまざまな罠：山浦恒央の“くみこみ”な話（173）（2/2 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第4回は、前回に引き続き、要求仕様フェーズの問題点を解説します。

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

2.3 計画した見積もりとマッチしない

　要求仕様書が完成しても安心できません。その後のフェーズで、「決済サービスを増やしたい」「関連会社と合意できなかったので」といった理由から、要求仕様の追加／変更が発生することがあります。この「後出しジャンケン」は、東京オリンピックや大阪・関西万博の開催費用の増加としておなじみですね。

　仕様の変更／追加は、物理的に問題はなくとも、計画した工数や日程の見積もりとマッチしなくなると最悪です。この場合、「予算の増額を交渉する」「人員を投入する」「仕様を『松』と『竹』に限定して規模縮小する」など別途考えることになります。東京オリンピックならばスタジアムの予算、大阪万博ならばパビリオンの建設費高騰などをイメージしてください（規模感は全く違いますが）。

　筆者の経験上、予算は常に雪だるま式に増える場合が圧倒的に多く、少なくなることは、まずありません。この問題が起こらないように、仕様を凍結しようと考えるのですが、社会情勢を必要以上に考慮したり、より良い製品を作ろうと「不必要に意欲的な」機能を盛り込んだりすると、この事象が発生するようです。

2.4 締め切り日になったので要求仕様フェーズを終了する

　要求仕様書の作成に苦労すると、納期に間に合わなくなります。その際、プロジェクトマネジャーが取る作戦の一つが、要求仕様フェーズの強制終了です。例えば、以下のような提案を行います。

提案：納期を考えると、検討事項はTBDとして、設計フェーズで考えましょう

　TBDは、「To Be Determined」の略で、それらしく聞こえますが、要は「後回し」と同義です。本来は、要求仕様を完成させてから、設計フェーズに入るはずが、時間の関係上、決まらないまま、先へ進んでしまいます。一見、問題がないように見えますが、次のフェーズに行っても、TBD事項は何も決まっていません。結果、次の設計フェーズでも要求仕様フェーズが続くのです。

2.5 作業の難易度判断に溝ができる

　クライアント的には簡単でも、開発担当にとっては実現困難な機能も少なくありません。ソフトウェアは、高層ビルや長大な吊り橋のような大規模建造物と違って、目で見て作業量を測りづらい特徴があります。また、前回も説明した通り、クライアントは商品知識、販売、運用が得意領域で、開発担当はソフトウェア開発が主担当です。クライアントはソフトウェアの中身ではなく、外見しか把握していないため、両者で作業の難易度判断に溝ができてしまいます。例えば、以下のケースです。

クライアント　はやりのクレジットカードやプリペイド・アプリケーションでの支払い方法にも対応して欲しい。

開発担当　支払い方法を追加できますが、テストなどの工数が増えるので、そんなに簡単な作業ではありません。

クライアント　はぁ、支払い方法を追加するだけなので、大変な作業とは思えませんが。

　両者に溝があると、こんな攻防を日々繰り広げることになります。ソフトウェア開発が難しい原因の一つは、建造物と違い、視覚的に、作業量や作業の複雑さを確認できない点です。

3．終わりに

　今回は、前回に引き続き、要求仕様フェーズの問題点を取り上げました。学生の皆さんには、要求仕様フェーズのイメージはつかみにくいかもしれませんが、「こんな問題点があるのか」と認識していただければ幸いです。

　要求仕様フェーズは、ソフト開発の起点となる大事な文書ですから、きっちり考えないと、最後まで苦労します。苦労の先取りと考え、しっかり取り組みましょう。

　「ソフトウェア開発で、上流工程が最も重要」とよく耳にしますが、上流工程とは要求仕様定義フェーズです。ソフトウェア開発技術者にとって、要求仕様書が圧倒的に重要で、難度の高いドキュメントです。「野球を一回も見聞きしたことがない人に対し、野球の進行手順やルールを詳細に定義し、それを読んだ瞬間、野球ができるようになる説明書」が要求仕様書です。野球の仕様をキチンと定義できれば、80％は完成したも同然。後工程の設計、コーディング、デバッグは粛々と進みます。

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

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

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

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

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

【 筆者紹介 】

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

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

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

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