設計部門の仕組み構築(その1)

更新日

投稿日

【設計部門の仕組み構築 連載目次】

 私は、設計部門における仕組み構築は下表のように山登りだと考えています。前回は、現状分析をもとに課題を整理し、その原因を分析することを通じて、現状課題が設計部門が置かれている現在地点を明らかにすることであり、その原因分析が目標を達成するために必要となる対策方針を明らかにすることで、登山マップとコンパスに相当するものだということを解説しました。
 
            R&D
 
 システム化を伴う場合も、そうでない場合も、設計部門における仕組み構築は、一本道をまっすぐに進むことで実現できるのではなく、『頂上を目指す山登り』であり、どの登山ルートを取るのかが重要であることを解説してきました。今回は、設計部門の仕組み構築として、その登山ルートを決めるところまでを解説します。繰り返しになりますが、事例としてあげている設計部門では、現状の課題を次のように整理できています。
 
(1)繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施し
   ている
(2)開発試作は4ヶ月間程度のかなり工数を使う作業であるが、試作(開発試作)製作や顧客対応な
   ど、設計部門が様々な作業を請け負っているため負担が大きい
(3)2S(第2試作)という試作期間にもっとも多くの工数がかかっており、設計作業、評価作業ともに
   最大の工数が必要になっている(工数手当て・調整は容易ではない)
(4)開発期間を通じて、設計作業、試作関連作業、評価作業が同時に実際されており、開発の状況把握
   やマネジメントは容易ではない
 
 前回、「(1)繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施している」について根本原因分析を行い、次のことが本質的な問題であることがわかりました。
 
  ・設計完成度を確認する仕組みがない
  ・改善活動をマネジメントするチーム(組織機能)がない
  ・評価項目や評価条件を再利用する仕組みがない
 
 あるツールベンダーが「試作が予定通り完了しないから進捗管理を徹底しましょう」「そのためには、進捗管理機能が充実しているシステムを導入しましょう」という...

【設計部門の仕組み構築 連載目次】

 私は、設計部門における仕組み構築は下表のように山登りだと考えています。前回は、現状分析をもとに課題を整理し、その原因を分析することを通じて、現状課題が設計部門が置かれている現在地点を明らかにすることであり、その原因分析が目標を達成するために必要となる対策方針を明らかにすることで、登山マップとコンパスに相当するものだということを解説しました。
 
            R&D
 
 システム化を伴う場合も、そうでない場合も、設計部門における仕組み構築は、一本道をまっすぐに進むことで実現できるのではなく、『頂上を目指す山登り』であり、どの登山ルートを取るのかが重要であることを解説してきました。今回は、設計部門の仕組み構築として、その登山ルートを決めるところまでを解説します。繰り返しになりますが、事例としてあげている設計部門では、現状の課題を次のように整理できています。
 
(1)繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施し
   ている
(2)開発試作は4ヶ月間程度のかなり工数を使う作業であるが、試作(開発試作)製作や顧客対応な
   ど、設計部門が様々な作業を請け負っているため負担が大きい
(3)2S(第2試作)という試作期間にもっとも多くの工数がかかっており、設計作業、評価作業ともに
   最大の工数が必要になっている(工数手当て・調整は容易ではない)
(4)開発期間を通じて、設計作業、試作関連作業、評価作業が同時に実際されており、開発の状況把握
   やマネジメントは容易ではない
 
 前回、「(1)繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施している」について根本原因分析を行い、次のことが本質的な問題であることがわかりました。
 
  ・設計完成度を確認する仕組みがない
  ・改善活動をマネジメントするチーム(組織機能)がない
  ・評価項目や評価条件を再利用する仕組みがない
 
 あるツールベンダーが「試作が予定通り完了しないから進捗管理を徹底しましょう」「そのためには、進捗管理機能が充実しているシステムを導入しましょう」という提案をしたとしても、このような単純で一本道の仕組み構築の考え方では現状の問題は解決しないこと、そして、現状の問題を解決できなければ開発効率2倍というゴールも達成できないことがわかると思います。
 
 次回は、現状課題の(2)(3)(4)について、根本原因分析を行い、登山マップを完成させます。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
技術文書の品質管理(その1)文書の内容が明確に伝わるかどうかを確認

     【目次】 1. 技術文書の品質管理とは 製造業での品質管理とは「製品の品質に問題がないよう...

     【目次】 1. 技術文書の品質管理とは 製造業での品質管理とは「製品の品質に問題がないよう...


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

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

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


普通の組織をイノベーティブにする処方箋 (その20)

 今回も前回に引き続き、合理的思考の重要性について解説をしていきます。 ◆関連解説『技術マネジメントとは』   1. 人間は本当に合理性と...

 今回も前回に引き続き、合理的思考の重要性について解説をしていきます。 ◆関連解説『技術マネジメントとは』   1. 人間は本当に合理性と...


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

もっと見る
技術資源の有効活用: 事例紹介 (その2)

 TRM(Technology Resources Management)事例その2は、建築物の防食事業を営む企業の取り組みをご紹介いたします。   ...

 TRM(Technology Resources Management)事例その2は、建築物の防食事業を営む企業の取り組みをご紹介いたします。   ...


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

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...


トレーサビリティの保証 プロジェクト管理の仕組み (その44)

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...