Club-Zコラム第24回

【第24回】システム設計とは

株式会社RDPi　　代表取締役　石橋　良造

2009.08.27

これでシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなことが典型的なものです。

□ 製品の企画や仕様がいつまでも決まらない

製品規模の増大や複雑化の進展などにより、製品全体を把握することが困難になりシステム設計を担当する人がいなくなったり、専門の企画グループを設置したことで設計グループとは別に行動して実現性検討が曖昧になったり、リリース直前まで仕様を変更したりすることが原因になって、いつまでも仕様が決まらない状態になります。


□ 開発終盤で品質問題が多発する

製品全体のシステム設計をすることなく、機能の光り物や目新しい要素技術に注目した作り込みを行い、その他の機能は後で作り込んで製品としてまとめ上げるという開発スタイルをとるため、後になって作り込んだ部分と先に作り込んだ部分との間の不整合が不具合の原因となります。


□ 同じラインナップの製品を作っているのに品質や生産性が上がらない

システム設計によるアーキテクチャの検討、確定、共有が実施できないため、同じような製品であっても毎回新製品として開発することになります。アーキテクチャが確定しないため再利用も場当たり的な対応になってしまい、効率向上につながらないことになります。


システム設計を実施しないとこのような問題が起きることが多いのですが、具体的にどのようなことが起きているのかを考えてみたいと思います。図68 を見てください。次のようなことが起きています。





企画担当が構想や企画、仕様定義といった開発工程を通じて、製品仕様の詳細化、具体化を行いますが、アウトプットは市場や競合の分析から検討した仕様一覧です。これは、図67で定義したようなシステム設計はまだ実施されていませんから、「実現したい」仕様一覧表ができている状態ということができます。本来は、この実現したい仕様一覧表をインプットとして、図67のシステムエンジニアリングとハードウェアエンジニアリング、ソフトウェアエンジニアリングであるシステム設計が行われるはずなのですが、多くの開発現場ではこの工程が抜けてしまっています。つまり、「実現したい」機能一覧表から、担当者あるいは担当チームに直接「実現したい」機能のサブセットを割り振っています。

そのため、「実現したい」仕様一覧表はシステム設計による実現妥当性の分析や評価により「実現できる」仕様一覧表になるはずのものが、実現性の裏付けのない「実現したい」仕様一覧表のままで開発が進むことになります。「実現したい」仕様のサブセットを担当するところだけで見た場合は、問題なく詳細設計や試作が進むかもしれませんが、他のサブセットを担当しているところとつなげたとき、あるいは製品全体で結合したときに、動かない、性能が出ないと言うことになる可能性が非常に高くなります。製品全体で見たときにはシステム設計により実現妥当性を検証した「実現できる」仕様一覧表になっていないからです。