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

更新日

投稿日

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

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

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

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

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

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

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

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

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

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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
IS/ISNOT思考法は、問題分析の基本

 多くの場合、問題が起きて原因を推定する際には、何が起きたか、どこで起きたか、いつ起きたか、どの程度起きたかといった事実を頭の中に入れた上で、可能性のある...

 多くの場合、問題が起きて原因を推定する際には、何が起きたか、どこで起きたか、いつ起きたか、どの程度起きたかといった事実を頭の中に入れた上で、可能性のある...


設計品質の作り込みと、人的設計ミス防止策(その4)

  【設計品質の作り込みと人的設計ミス防止策 連載目次】 1. 設計品質とはなにか 2. 設計プロセスと設計ミス回避策 3. 設計ミ...

  【設計品質の作り込みと人的設計ミス防止策 連載目次】 1. 設計品質とはなにか 2. 設計プロセスと設計ミス回避策 3. 設計ミ...


リーン製品開発の基本原則(その1)

  1. リーン製品開発の基本原則1  新製品開発プロジェクトの初期にすべきことは、何でしょうか。プロジェクトの初期に次の各項目に焦点を...

  1. リーン製品開発の基本原則1  新製品開発プロジェクトの初期にすべきことは、何でしょうか。プロジェクトの初期に次の各項目に焦点を...


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

もっと見る
製品開発部へのカンバン導入記(その3)

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...


プロジェクトの進捗管理 プロジェクト管理の仕組み (その4)

 前回のその3プロジェクトの計画策定に続いて解説します。最後は、プロジェクトの監視と制御、そして、測定と分析です。まとめて進捗管理といっても問題ないと思い...

 前回のその3プロジェクトの計画策定に続いて解説します。最後は、プロジェクトの監視と制御、そして、測定と分析です。まとめて進捗管理といっても問題ないと思い...


マトリクス体制での品質保証3 プロジェクト管理の仕組み (その32)

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...