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

更新日

投稿日

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

 前回のその1に続いて解説します。工数分析により大きく4つの課題を抱えていることを把握できたので、この設計部門の現状が明確になりました。次のステップは、このような課題を抱えているスタート地点からの登山ルートを決めることです。そのためには、まず、観測できた課題一つひとつを分析して課題の根本原因を明らかにし、次に、その原因を除去するための対策を検討することになります。

 最初の課題、「(a) 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施している」をとりあげ、実際にやってみましょう。ポイントは、計画の問題なのか、実績(進捗上)の問題なのかを切り分けることです。

 図21は「アクティビティ重心」の推移を示したものです。アクティビティ重心とは、プロジェクト(プロジェクトの中の任意のチームでもかまいません)の活動の重心が開発工程上のどこにあるのかを示したもので、図21は、その時間推移をあらわしたものです。縦軸は開発工程になっており、構想から、設計、試作製造、評価を経て、最終的に製造移管で設計部門の開発業務は完了です。
 
                R&D
                    図21.計画と実績のアクティビティ重心推移
 
 このグラフを見ると、計画では、設計から評価のサイクルを大きな波のように試作のたびに繰り返し、最終的に製造移管が完了することがわかります。大きな波になっているのは、試作ごとに設計、試作製造、評価を逐次的に実施する計画になっているということです。

 しかし、実績は、計画に較べて波打っていないことがわかります。これは、設計、試作製造、評価が重なってしまい、試作の切れ目がはっきりしない開発になっていることをあらわしています。課題 (a) がこのグラフでも確認できます。したがって、計画の問題ではなく、進捗上の問題であることがわかります。このような分析をしなくても、開発日程表(スケジ...

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

 前回のその1に続いて解説します。工数分析により大きく4つの課題を抱えていることを把握できたので、この設計部門の現状が明確になりました。次のステップは、このような課題を抱えているスタート地点からの登山ルートを決めることです。そのためには、まず、観測できた課題一つひとつを分析して課題の根本原因を明らかにし、次に、その原因を除去するための対策を検討することになります。

 最初の課題、「(a) 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施している」をとりあげ、実際にやってみましょう。ポイントは、計画の問題なのか、実績(進捗上)の問題なのかを切り分けることです。

 図21は「アクティビティ重心」の推移を示したものです。アクティビティ重心とは、プロジェクト(プロジェクトの中の任意のチームでもかまいません)の活動の重心が開発工程上のどこにあるのかを示したもので、図21は、その時間推移をあらわしたものです。縦軸は開発工程になっており、構想から、設計、試作製造、評価を経て、最終的に製造移管で設計部門の開発業務は完了です。
 
                R&D
                    図21.計画と実績のアクティビティ重心推移
 
 このグラフを見ると、計画では、設計から評価のサイクルを大きな波のように試作のたびに繰り返し、最終的に製造移管が完了することがわかります。大きな波になっているのは、試作ごとに設計、試作製造、評価を逐次的に実施する計画になっているということです。

 しかし、実績は、計画に較べて波打っていないことがわかります。これは、設計、試作製造、評価が重なってしまい、試作の切れ目がはっきりしない開発になっていることをあらわしています。課題 (a) がこのグラフでも確認できます。したがって、計画の問題ではなく、進捗上の問題であることがわかります。このような分析をしなくても、開発日程表(スケジュール)を確認すればわかることなのですが、図21のような進捗管理をしていれば、簡単に計画と実績の乖離を把握することができます。
 
 次回、その3では、進捗上の問題の原因分析を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
時間軸(Time) 普通の組織をイノベーティブにする処方箋 (その53)

        イノベーションに必要な要素を表したKETICモデルの2つ目、Experience(経験)の解...

        イノベーションに必要な要素を表したKETICモデルの2つ目、Experience(経験)の解...


自社の存在価値 普通の組織をイノベーティブにする処方箋 (その113)

  現在、知識や経験を整理するフレームワークとして、本質とそれ以外という区別があるという理解から「本質とは何か」を解説しています。また、企...

  現在、知識や経験を整理するフレームワークとして、本質とそれ以外という区別があるという理解から「本質とは何か」を解説しています。また、企...


検図とは?「検図力」を高めてトラブルを未然に防ぐ【検図完全ガイド】

【目次】 【この記事で分かること】 検図がなぜ「最後の砦」と呼ばれるほど重要なのかが分かる 見落としをなくすための具体的なチ...

【目次】 【この記事で分かること】 検図がなぜ「最後の砦」と呼ばれるほど重要なのかが分かる 見落としをなくすための具体的なチ...


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

もっと見る
スーパーマンではなくプロフェッショナルな技術者に(その3)

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...


設計部門の仕組み改革(その1)

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...


進捗管理可能なソフト開発計画 プロジェクト管理の仕組み (その6)

 前回のその5:ソフト開発計画の作成方法に続いて解説します。    製品機能に対するソフトウェアの各モジュールが実装すべき処理(内部機能)が...

 前回のその5:ソフト開発計画の作成方法に続いて解説します。    製品機能に対するソフトウェアの各モジュールが実装すべき処理(内部機能)が...