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

　なお、本シリーズ第1回目を読んでいない方は、以下のリンクから一読することをおススメします。

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

2．前回の振り返り

　まずは、前回までに解説してきた要求仕様フェーズの大まかな開発手順を示します（図1）。

図1　要求仕様フェーズの開発手順［クリックで拡大］

　図1は、要求仕様フェーズの一連の開発手順です。発注側が企画を考え、開発側がヒアリングを行います。ヒアリングした内容は、ヒアリングシート（議事録など）にまとめ、要求仕様書として定義します。作成した要求仕様書は、最終的に発注側とレビューし、合意できれば要求仕様フェーズ完了です。

　前回は、図1の右半分の中段にある「要求仕様書作成」に着目し、ジャンケンを題材として要求仕様書のイメージを深める記事としました。簡単に思えるジャンケンですが、仕様の抜け漏れなどがあり、簡単でないことが分かりますね。

　今回は、より一歩進み、機能分割について取り上げます。

3．要求仕様書における機能分割とは

　高校の「情報」の授業で作る10～20ステップ程度のプログラムなら、仕様書や設計書を書く必要はなく、いきなり、コーディングする方が効率的です。しかし、携帯電話機やエアバスの航空機の制御プログラムは、要求仕様を定義し、設計書を記述し、コーディングして、デバッグし、ソフトウェア工学としてきちんと開発する必要があります。例えば、1人乗りの舟なら、ホームセンターで板や丸太を買ってきて、ロープで縛れば簡単に完成しますが、3000人乗りの船だとそうはいきません。流体力学、構造計算、内燃機関の解析、船体設計など、高度に専門的な知識と経験が必要です。

　ジャンケンの仕様書も簡単ではありませんが、それよりはるかに大きく、複雑怪奇なソフトウェアの仕様を記述する方法として、大規模開発プロジェクトで採用しているのが「機能分割」と「段階的詳細化」です。

　例えば、日本最大の企業であるトヨタ自動車（以下、トヨタ）を考えます。従業員が37万人、年間の売り上げが約45兆円の会社であり、組織としての規模や複雑度は非常に大きくて巨大ですね。従業員1人をソフトウェアの1モジュールと考えると、37万モジュールの巨大プログラムと言えます。最近のスマートフォンのソフトウェアの総モジュール数が5万～10万ぐらいなので、規模感としては、トヨタに似ています。

　図2に、想像で書いたトヨタの組織図を示します。社長の配下に、今後どんな自動車を作るかを企画する「製品企画部」、エンジンやボディーを設計する「設計部」、実際に自動車を作る「製造部」、自動車の検査や品質保証を担当する「品質保証部」、作った自動車を販売する「営業部」、社内のお金の動きを引き受ける「経理部」、人事や社内の福利厚生を担当する「総務部」に分かれます。さらに、各部は、例えば、設計部の場合、「ボディーの設計課」「エンジンの設計課」「電気系統の設計課」などに分かれ、さらに「エンジンの設計課」は「ピストンの設計係」「クランクの設計係」などに分かれ、最後は「山田太郎さん」「鈴木一郎さん」になり、図2内にある四角の数が従業員と同じ37万個になるのです。このように、組織を役割で分割するのが「機能分割」、1つの組織を上から順に分割して細かくするのが「段階的詳細化」です。この考え方は、トヨタの組織でも、ソフトウェア開発でも全く同じです。

　ソフトウェアの1つのモジュールは、ソースコードの行数で50～200ステップと言われます。これは、トヨタの組織図でも同じで、社長であっても、入社3カ月の新入社員であっても、1日の労働時間は8時間前後と考えるのと同じです。