システム設計2 プロジェクト管理の仕組み (その34)

更新日

投稿日

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

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

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

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

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

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

 
 システム設計によるアーキテクチャの検討、確定、共有が実施できないため、同じような製品であっても毎回新製品として開発することになります。アーキテクチャが確定しないため再利用も場当たり的な対応になってしまい、効率向上につながらないことになります。
 
 システム設計を実施しないとこのような問題が起きることが多いのですが、具体的にどのようなことが起きているのかを考えてみたいと思います。図68を見てください。次のようなことが起きています。
 
R&D
図68. システム設計の欠如
 
 企画担当が構想や企画、仕様定義といった開発工程を通じて、製品仕様の詳細化、具体化を行いますが、アウトプットは市場や競合の分析から検討した仕様一覧です。これは、前回で定義したようなシステム設計はまだ実施されていませんから、「実現したい」仕様一覧表ができている状態ということができます。本来は、この実現したい仕様一覧表をインプットとして、システムエンジニアリングとハードウェアエンジニアリング、ソフトウェアエンジニアリングであるシステム設計が行われるはずなのですが、多くの開発現場ではこの工程が抜けてしまっています。つまり、「実現したい」機能一覧表から、担当者あるいは担当チームに直接「実現したい」機能のサブセットを割り振っています。
 
 そのため、「実現したい」仕様一覧表はシステム設計による実現妥当性の分析や評価により「実現できる」仕様一覧表になるはずのものが、実現性の裏付けのない「実現したい」仕様一覧表のままで開発が進むことになります。「実現したい」仕様のサブセットを担当するところだけで見た場合は、問題なく詳細設計や試作が進むかもしれませんが、他のサブセットを担当しているところとつなげたとき、あるいは製品全体で結合したときに、動かない、性能が出ないと言うことになる可能性が非常に高くなります。製品全体で見たときにはシステム設計により実現妥当性を検証した「実現できる」仕様一覧表になっていないからです。
 
 実際のシステム設計の実施方法は次回に解説します。今回は実施のポイントを整理しておきます。
 

【対象は製品あるいはシステム全体】

 電気、機構、ソフトといった主要なサブシステムはもちろんシステム設計の対象となりますが、生産技術、製造、保守、サービスといった領域も対象にします。
 

【機能要求と非機能要求のセットで考える】

 仕様や要件のブレークダウンを行う際に常に品質属性を考慮することが大切です。機能要求と非機能要求とをセットで取り扱うことにより、品質属性の取り扱いが容易になります。
 

【ブレークダウン(展開)は構成要素間の関係を保証して実施する】

 仕様の詳細化や仕様から内部構...
 前回でシステム設計の位置づけが明確になったと思いますので、次に、多くの開発現場で起きているシステム設計の問題について考えてみたいと思います。次のようなことが典型的なものです。
 

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

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

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

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

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

 
 システム設計によるアーキテクチャの検討、確定、共有が実施できないため、同じような製品であっても毎回新製品として開発することになります。アーキテクチャが確定しないため再利用も場当たり的な対応になってしまい、効率向上につながらないことになります。
 
 システム設計を実施しないとこのような問題が起きることが多いのですが、具体的にどのようなことが起きているのかを考えてみたいと思います。図68を見てください。次のようなことが起きています。
 
R&D
図68. システム設計の欠如
 
 企画担当が構想や企画、仕様定義といった開発工程を通じて、製品仕様の詳細化、具体化を行いますが、アウトプットは市場や競合の分析から検討した仕様一覧です。これは、前回で定義したようなシステム設計はまだ実施されていませんから、「実現したい」仕様一覧表ができている状態ということができます。本来は、この実現したい仕様一覧表をインプットとして、システムエンジニアリングとハードウェアエンジニアリング、ソフトウェアエンジニアリングであるシステム設計が行われるはずなのですが、多くの開発現場ではこの工程が抜けてしまっています。つまり、「実現したい」機能一覧表から、担当者あるいは担当チームに直接「実現したい」機能のサブセットを割り振っています。
 
 そのため、「実現したい」仕様一覧表はシステム設計による実現妥当性の分析や評価により「実現できる」仕様一覧表になるはずのものが、実現性の裏付けのない「実現したい」仕様一覧表のままで開発が進むことになります。「実現したい」仕様のサブセットを担当するところだけで見た場合は、問題なく詳細設計や試作が進むかもしれませんが、他のサブセットを担当しているところとつなげたとき、あるいは製品全体で結合したときに、動かない、性能が出ないと言うことになる可能性が非常に高くなります。製品全体で見たときにはシステム設計により実現妥当性を検証した「実現できる」仕様一覧表になっていないからです。
 
 実際のシステム設計の実施方法は次回に解説します。今回は実施のポイントを整理しておきます。
 

【対象は製品あるいはシステム全体】

 電気、機構、ソフトといった主要なサブシステムはもちろんシステム設計の対象となりますが、生産技術、製造、保守、サービスといった領域も対象にします。
 

【機能要求と非機能要求のセットで考える】

 仕様や要件のブレークダウンを行う際に常に品質属性を考慮することが大切です。機能要求と非機能要求とをセットで取り扱うことにより、品質属性の取り扱いが容易になります。
 

【ブレークダウン(展開)は構成要素間の関係を保証して実施する】

 仕様の詳細化や仕様から内部構造への変換など、適宜構成要素をブレークダウンしていくことになりますが、その際に、構成要素間の関係がどのようになっていて、それが機能・非機能要求を満足することになっていることを記述することが大切です。また、設計根拠を明確にすることも重要です。
 
 今回はシステム設計のイントロダクションになりました。システム設計に対する認識が人によってかなり違うため、まずは、開発工程におけるシステム設計の位置づけや、システム設計が行われない場合の課題についての解説を中心に話を進めました。これでシステム設計が意味するところについては共有することができたと思いますので、次回はシステム設計の実施方法について解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
新たな時代の「ものづくり」(前編)従来と異なる分野で事業化する

 企業は自社が持っている技術を常に見直し、新たな商品開発を行う必要があります。企業の商品開発活動では、従来自分たちが戦ってきた分野だけでなく、異なる分野で...

 企業は自社が持っている技術を常に見直し、新たな商品開発を行う必要があります。企業の商品開発活動では、従来自分たちが戦ってきた分野だけでなく、異なる分野で...


情報コンテンツ 見えてきた、2030年の技術社会 (その4)

  【見えてきた、2030年の技術社会 連載目次】 1.  自動車業界のパラダイムシフト 2.  シェアリングエコ...

  【見えてきた、2030年の技術社会 連載目次】 1.  自動車業界のパラダイムシフト 2.  シェアリングエコ...


 インクルーシブデザインの実務、「平均的ユーザー」の枠を超え、リードユーザーと共創する製品開発

【目次】   「開発の最終段階でアクセシビリティの不備が見つかり、大幅な修正工数が発生した」「良かれと思って追加した機能...

【目次】   「開発の最終段階でアクセシビリティの不備が見つかり、大幅な修正工数が発生した」「良かれと思って追加した機能...


「技術マネジメント総合」の活用事例

もっと見る
プロジェクトの問題を見極める1 プロジェクト管理の仕組み (その23)

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...


仕組み見直しとグローバル化(その1)

◆「気づき」能力向上のカギは製品開発経験の活用    前回は、日本の多くの開発現場で「組み合わせ型」アーキテクチャの製品を「擦り合わせ型」の...

◆「気づき」能力向上のカギは製品開発経験の活用    前回は、日本の多くの開発現場で「組み合わせ型」アーキテクチャの製品を「擦り合わせ型」の...


‐産学交流からの開発テ-マと市場の観察‐  製品・技術開発力強化策の事例(その7)

 前回の事例その6に続いて解説します。産学交流による開発テ-マの探索や共同開発に関心が寄せられています。 大学には基礎研究の面で優れた開発テ-マの候補にな...

 前回の事例その6に続いて解説します。産学交流による開発テ-マの探索や共同開発に関心が寄せられています。 大学には基礎研究の面で優れた開発テ-マの候補にな...