前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなことが典型的なものです。
1. 製品の企画や仕様がいつまでも決まらない
製品規模の増大や複雑化の進展などにより、製品全体を把握することが困難になりシステム設計を担当する人がいなくなったり、専門の企画グループを設置したことで設計グループとは別に行動して実現性検討が曖昧になったり、リリース直前まで仕様を変更したりすることが原因になって、いつまでも仕様が決まらない状態になります。
2. 開発終盤で品質問題が多発する
製品全体のシステム設計をすることなく、機能の光り物や目新しい要素技術に注目した作り込みを行い、その他の機能は後で作り込んで製品としてまとめ上げるという開発スタイルをとるため、後になって作り込んだ部分と先に作り込んだ部分との間の不整合が不具合の原因となります。
3. 同じラインナップの製品を作っているのに品質や生産性が上がらない
システム設計によるアーキテクチャの検討、確定、共有が実施できないため、同じような製品であっても毎回新製品として開発することになります。アーキテクチャが確定しないため再利用も場当たり的な対応になってしまい、効率向上につながらないことになります。
システム設計を実施しないとこのような問題が起きることが多いのですが、具体的にどのようなことが起きているのかを考えてみたいと思います。図68を見てください。次のようなことが起きています。
図68. システム設計の欠如
企画担当が構想や企画、仕様定義といった開発工程を通じて、製品仕様の詳細化、具体化を行いますが、アウトプットは市場や競合の分析から検討した仕様一覧です。これは、前回で定義したようなシステム設計はまだ実施されていませんから、「実現したい」仕様一覧表ができている状態ということができます。本来は、この実現したい仕様一覧表をインプットとして、システムエンジニアリングとハードウェアエンジニアリング、ソフトウェアエンジニアリングであるシステム設計が行われるはずなのですが、多くの開発現場ではこの工程が抜けてしまっています。つまり、「実現したい」機能一覧表から、担当者あるいは担当チームに直接「実現したい」機能のサブセットを割り振っています。
そのため、「実現したい」仕様一覧表はシステム設計による実現妥当性の分析や評価により「実現できる」仕様一覧表になるはずのものが、実現性の裏付けのない「実現したい」仕様一覧表のままで開発が進むことになります。「実現したい」仕様のサブセットを担当するところだけで見た場合は、問題なく詳細設計や試作が進むかもしれませんが、他のサブセットを担当しているところとつなげたとき、あるいは製品全体で結合したときに、動かない、性能が出ないと言うことになる可能性が非常に高くなります。製品全体で見たときにはシステム設計により実現妥当性を検証した「実現できる」仕様一覧表になっていないからです。
実際のシステム設計の実施方法は次回に解説します。今回は実施のポイントを整理しておきます。
【対象は製品あるいはシステム全体】
電気、機構、ソフトといった主要なサブシステムはもちろんシステム設計の対象となりますが、生産技術、製造、保守、サービスといった領域も対象にします。
【機能要求と非機能要求のセットで考える】
仕様や要件のブレークダウンを行う際に常に品質属性を考慮することが大切です。機能要求と非機能要求とをセットで取り扱うことにより、品質属性の取り扱いが容易になります。
【ブレークダウン（展開）は構成要素間の関係を保証して実施する】
仕様の詳細化や仕様から内部構...
造への変換など、適宜構成要素をブレークダウンしていくことになりますが、その際に、構成要素間の関係がどのようになっていて、それが機能・非機能要求を満足することになっていることを記述することが大切です。また、設計根拠を明確にすることも重要です。
今回はシステム設計のイントロダクションになりました。システム設計に対する認識が人によってかなり違うため、まずは、開発工程におけるシステム設計の位置づけや、システム設計が行われない場合の課題についての解説を中心に話を進めました。これでシステム設計が意味するところについては共有することができたと思いますので、次回はシステム設計の実施方法について解説します。