設計部門の課題と原因分析(その1)

更新日

投稿日

【設計部門の課題と原因分析 連載目次】

 前回、『設計部門における仕組み構築の道のりは、ゴールに向かう一本道ではなく、いくつものルートがある山登りと同じである』と解説しました。これは、製品、技術、設備、設計者などが設計部門ごとに固有であり、現時点の開発の仕組み(登山のスタート地点)は、どの設計部門をとっても同じものは存在せず、ゴール(頂上)までのルートも設計部門によって違うものになるからです。だからこそ、ルート選択そのものが目標達成のために重要な要素となります。

 従って、ツールやシステムのメーカー、又はベンダーが提示するゴールと導入プランにしたがって仕組みを構築することは、大きなリスクを抱えることを意味します。目指すべきゴールが高ければ高いほど、固有の綿密な登山計画を立てる必要があるはずです。完全には人任せにできないはずです。

 それでは、図20を使って登山計画を立ててみることにしましょう。最初にやることは、スタート地点(設計部門の現状)を正確に特定することです。そのためには、図20 に示すようにプロジェクトの工数分析を行い、課題を整理することが有効です。事例としてあげている設計部門の課題は次のように整理できます。
 
       R&D
                  図20.設計部門での製品開発プロジェクトにおける工数の使い方

 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行実施しています。そのため、設計も評価も中途半端です。開発試作は4ヶ月間程度のかなりの工数を使う作業ですが、開発試作依頼や顧客対応など、様々な作業を設計部門が請け負っています。そこで、本来の構想設計がおろそかになっています。2Sという試作期間にもっとも多くの工数がかかっており、設計作業、評価作業ともに最大の工数が必要になっています。一時的な設計者増員は困難であり、そのため、設計者の負担は大きなものになるでしょう。

 開発期間を通じて、設計作業、試作関連作業、評価作業が同時に実際されており、開発の状況把握やマネジメントは容易ではありません。どうしても、完成度の確認は開発の最後になってしまい、修正の際に大きな手戻りが発生します。

 ここであげた課題を解決することなしには、...

【設計部門の課題と原因分析 連載目次】

 前回、『設計部門における仕組み構築の道のりは、ゴールに向かう一本道ではなく、いくつものルートがある山登りと同じである』と解説しました。これは、製品、技術、設備、設計者などが設計部門ごとに固有であり、現時点の開発の仕組み(登山のスタート地点)は、どの設計部門をとっても同じものは存在せず、ゴール(頂上)までのルートも設計部門によって違うものになるからです。だからこそ、ルート選択そのものが目標達成のために重要な要素となります。

 従って、ツールやシステムのメーカー、又はベンダーが提示するゴールと導入プランにしたがって仕組みを構築することは、大きなリスクを抱えることを意味します。目指すべきゴールが高ければ高いほど、固有の綿密な登山計画を立てる必要があるはずです。完全には人任せにできないはずです。

 それでは、図20を使って登山計画を立ててみることにしましょう。最初にやることは、スタート地点(設計部門の現状)を正確に特定することです。そのためには、図20 に示すようにプロジェクトの工数分析を行い、課題を整理することが有効です。事例としてあげている設計部門の課題は次のように整理できます。
 
       R&D
                  図20.設計部門での製品開発プロジェクトにおける工数の使い方

 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行実施しています。そのため、設計も評価も中途半端です。開発試作は4ヶ月間程度のかなりの工数を使う作業ですが、開発試作依頼や顧客対応など、様々な作業を設計部門が請け負っています。そこで、本来の構想設計がおろそかになっています。2Sという試作期間にもっとも多くの工数がかかっており、設計作業、評価作業ともに最大の工数が必要になっています。一時的な設計者増員は困難であり、そのため、設計者の負担は大きなものになるでしょう。

 開発期間を通じて、設計作業、試作関連作業、評価作業が同時に実際されており、開発の状況把握やマネジメントは容易ではありません。どうしても、完成度の確認は開発の最後になってしまい、修正の際に大きな手戻りが発生します。

 ここであげた課題を解決することなしには、目標の開発効率2倍を達成することは考えられません。したがって、この課題を解決する対策を検討することが、目標達成のための登山ルートを検討することになります。

 次回は、観測できた課題一つひとつを分析して課題の根本原因を明らかにし、次に、その原因を除去するための対策検討を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
新規事業ができない理由?それはエラい人にある?~技術企業の高収益化:実践的な技術戦略の立て方(その31)

  【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 「テーマ創出が出来た後はどのような見通...

  【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 「テーマ創出が出来た後はどのような見通...


ロードマップの作り方

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...


設計標準の必要性と作り方(その2)

  【目次】   1.設計標準はベストコストのガイドライン   前回のその1に続いて解説します。一...

  【目次】   1.設計標準はベストコストのガイドライン   前回のその1に続いて解説します。一...


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

もっと見る
成功体験が重荷となる製品開発プロセス(その1)

◆ 現状の課題    スマートフォンの開発マネジメント支援を行った経験から、従来の製品開発のやり方を踏襲した改善では問題の根本解決は難しいと...

◆ 現状の課題    スマートフォンの開発マネジメント支援を行った経験から、従来の製品開発のやり方を踏襲した改善では問題の根本解決は難しいと...


品質の仕組みとは3 プロジェクト管理の仕組み (その29)

 これまでISO9001を例にした話になっていますので、ここで PMBOK (Project Management Body of Knowledge) ...

 これまでISO9001を例にした話になっていますので、ここで PMBOK (Project Management Body of Knowledge) ...


製品開発部へのカンバン導入記(その2)

        前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(...

        前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(...