コンサルタントとして多くの開発現場に入ると、普段使っている単語、もしくは意味しているものが開発現場によって想像以上に違うことを実感します。たとえば、「レビュー」という基本的な単語ひとつとっても、開発工程ごとに完了確認を行うための公式な会議を意味する開発現場もあれば、技術者同士が議論しながら設計を確認することを意味する開発現場もあります。そうすると、「レビューはきちんとやっています」と話してくれたとしても、開発工程ごとに適切な中間成果物が作成されたことを、組織として客観的に確認していると言うことなのか、技術者が行う設計作業の一貫として他の技術者に自分の設計結果を見てもらうと言うことなのか、その発言が意味する内容は大きく違ってしまいます。
「システム設計」も、開発現場によってその位置づけや作業内容が想像以上に違う言葉のひとつです。そもそも、開発の上流工程が明確になっていないと言うこともあるのですが、開発現場によって対象となる領域が、ハードウェアだけなのかソフトウェアだけなのか、それともハードとソフトを併せた製品あるいはシステム全体なのかも違いますし、仕様や顧客要求を詳細化することを指すのか、仕様や顧客要求を製品やシステムの構造に変換（マッピング）することを指すのかという開発工程上の位置づけも違います。
ここでは、システム設計を図67 のように定義したいと思います。図67 は開発の上流工程を記述したものですが少し解説しておきます。一番左にあるのがエンドユーザや顧客の要望、ニーズですが、それらはエンドユーザの言葉で記述されたものですから整合性や一貫性は保証されていません。これをハードウェア、ソフトウェア、その他いくつかのサブシステムに分けて、相互に不整合がないように要件を整理する作業を「システムエンジニアリング」工程と定義しています。さらに、システムエンジニアリングで明確になったハードウェア要件は「ハードウェアエンジニアリング」により、ハードウェアの仕様や内部構造、必要な開発作業などに分解（展開）されます。同様にソフトウェア要件は「ソフトウェアエンジニアリング」によりソフトウェア仕様、ソフト内部構造、必要な開発作業などに分解（展開）されます。
このように開発工程を定義したとき、「システムエンジニアリング」と「ハードウェアエンジニアリング」「ソフトウェアエンジニアリング」などのサブシステムごとのエン...
ジニアリングを「システム設計」と定義します。したがって、システム設計の対象領域は製品（システム）全体、および、そのサブシステムであるハードウェア全体やソフトウェア全体となります。また、開発工程としては、仕様を詳細化する工程も、仕様から内部構造に変換（マッピング）する工程も含まれます。
図67. システム設計とは
次回は、開発現場で起きているシステム設計の問題について解説します。