設計部門の仕組み構築(その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)について、根本原因分析を行い、登山マップを完成させます。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
技術の棚卸し 技術企業の高収益化:実践的な技術戦略の立て方(その2)

   2020年、ビジネスの現場ではWEB会議が当然のようになり、ハンコもなくなろうとするなど、従来の価値観が大きく変わろうとしています。...

   2020年、ビジネスの現場ではWEB会議が当然のようになり、ハンコもなくなろうとするなど、従来の価値観が大きく変わろうとしています。...


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

  【この連載の前回へのリンク】 【この連載の次回へのリンク】 今回も前回、前々回と同様、「切り取った知識の重要部分を発想するフレーム...

  【この連載の前回へのリンク】 【この連載の次回へのリンク】 今回も前回、前々回と同様、「切り取った知識の重要部分を発想するフレーム...


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

  前回までの4回で、視覚を活用して創造性を高めイノベーションを起こす能力を強化する方法について、考えてきました。今回からは、聴覚ついて考...

  前回までの4回で、視覚を活用して創造性を高めイノベーションを起こす能力を強化する方法について、考えてきました。今回からは、聴覚ついて考...


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

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

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

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


ソフトウェア開発スケジュールと結合テスト プロジェクト管理の仕組み (その7)

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。    ソフトウェア開発スケジュールでは次のような問題を抱えています。 &...


設計部門とリスク管理(その1)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...