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

更新日

投稿日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
技術戦略 研究テーマの多様な情報源(その37)

     前回は、アイデアを創出する活動として『隣接可能性』を説明しました。それでは、隣接可能性で創出した『粗いアイデア』をど...

     前回は、アイデアを創出する活動として『隣接可能性』を説明しました。それでは、隣接可能性で創出した『粗いアイデア』をど...


関係性の種類、包含とは 普通の組織をイノベーティブにする処方箋(その94)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回も前回に引き続き、下記の「関係性の種類」の中の「(...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回も前回に引き続き、下記の「関係性の種類」の中の「(...


イノベーションの創出 普通の組織をイノベーティブにする処方箋 (その127)

  【この連載の前回へのリンク】 「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にもとづき、日々...

  【この連載の前回へのリンク】 「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にもとづき、日々...


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

もっと見る
作業要素の進捗分析2 プロジェクト管理の仕組み (その19)

  前回のその18:作業要素の進捗分析1に続いて解説します。    図50は製品構造の観点から管理単位にブレークダウンした例です。製品がどの...

  前回のその18:作業要素の進捗分析1に続いて解説します。    図50は製品構造の観点から管理単位にブレークダウンした例です。製品がどの...


開発部門の管理職が学ぶべきこととは

  今回は、新任の開発課長が学ぶべきこと、課長就任前に3週間で準備をすべきこと、さらには課長就任後に取り組むべきことについて解説します。 &...

  今回は、新任の開発課長が学ぶべきこと、課長就任前に3週間で準備をすべきこと、さらには課長就任後に取り組むべきことについて解説します。 &...


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

◆ 解決策    成功体験が重荷となる製品開発プロセス(その1:現状の課題)では、スマートフォンで起きていることを例にして、従来の組み込みソ...

◆ 解決策    成功体験が重荷となる製品開発プロセス(その1:現状の課題)では、スマートフォンで起きていることを例にして、従来の組み込みソ...