　山浦恒央の“くみこみ”な話の第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。連載第170回を読んでいない方は、以下のリンクから一読することをオススメします。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

　要求仕様フェーズでは、発注者から「どんなソフトウェアを作ってほしいのか？」をヒアリングし、要求仕様書を作成します。要求仕様書は、開発の根幹に関わる文書で、これがないと開発に取り掛かれず、最悪の場合は、プロジェクトが頓挫します。

　要求仕様書をきちんと書くためには、高度な技術が必要です。前回も述べたように、「野球を一回も見聞きしたことがない人に対し、野球の進行手順やルールを詳細に定義し、それを読んだ瞬間、野球ができるようになる説明書」と考えると非常に高度なスキルが必要だと分かりますね。誰でも一応、ベーシックな野球のルールや進行を知っていますが、ルールや進行方法を細部まで完全に網羅して、相手に伝えるのはものすごく大変です。

　筆者の想像ですが、アップル（Apple）が世界で初めてスマートフォンを開発した時、開発チームは、「こんな機能を開発したい」とのアイデアはあったでしょうが、先行商品のない世界初の携帯電話機なので自分達にもどんな製品に仕上がるか予測はできなかったと思います。そんな製品を開発する場合でも、軸になるのが要求仕様書です。

　前回の第174回では、要求仕様書を作成する上で鍵になる、要求仕様フェーズにおける問題点の対処法を紹介しました。今回は、その続きです。

2．要求仕様フェーズの問題対処法（その2）

2.1 開発方法を整備する

　要求仕様フェーズの問題点に対処するため、開発方法のルールを制定して対処するアプローチがあります。「開発の標準化」「開発プロセスの策定」なんて呼ばれることもあります。

※写真はイメージです

　身近な例として、ハンバーガーの全国チェーン店をイメージしてください。店では、日本全国の従業員に対して、ハンバーガーの作り方、接客、清掃などのルールを細部まで作成したマニュアル通りに作業するように指導しています。そのため、基本的に従業員は、「こちらの調理方式の方が速くできる」などと考えて自己流で作業することはできませんね（多分、ものすごく怒られます）。

　調理マニュアルを細かく定め、ハンバーガーを作ることは、美食を追求するグルメには、「日本のどこで食べても同じ価格、同じ味、同じ時間で出てきて、個性がない」と低い評価になりますが、エンジニアリングの視点では理想的な製造法です。「どんなソフトウェアを開発する場合でも、同じ開発プロセスに従い、同じ価格、同じ品質、同じ開発期間で作る」のは、トッププロ集団の高度な技です。

　作りやすいところから手を付け、スケジュールはなく、できた時が出荷日。品質は、開発者の技術力次第で、スーパープログラマーが担当すれば高品質なものが出来上がるが、ダメなエンジニアに当たるとボロボロ……。これでは、趣味でソフトウェアを作る「学生プログラミング」です。

　ここで、「ビジネス指向のプログラミングが良くて、趣味のプログラムはダメ」と言っているのではありません。プログラミングに無限のコストと時間をかけられる「学生の趣味（や研究目的）のプログラミング」により、コンピュータサイエンスは驚異的に進歩しました。UNIXやLinuxが良い例ですね。採算性や利益が出ることを最優先する「ビジネス指向のプログラミング」ではまねができません。

　「ビジネス指向のプログラミング」と「学生による趣味のプログラム」は馬車の両輪とお考えください。ビジネス指向のプログラミングでは、吉野家の牛丼のように、「安い、うまい、早い（低コスト、高品質、短納期）」が最重要で、そのためには、日本全国、どこでも同じ味、同じ価格、同じ調理時間でハンバーガーを作る「調理マニュアル（開発プロセス）」を組織として定めて、その通りに作業することが必須です。

要求仕様書の開発手順の例

　　　　　　 1|2|3 次のページへ