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

更新日

投稿日

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

 前回のその2に続いて解説します。前回の分析で進捗上の問題であることが明確になったので、次にその原因を分析しましょう。もしかすると、単純に進捗の問題にしてしまうことに違和感があるかもしれません。実際、計画自体が現実的ではないから、計画通りに開発を進めることができないのは確かです。
 
 多くの製品開発は、開発着手とリリースの日程が決まっており、その決められた日程での開発が開発現場は要求されています。日程最優先ですから、トラブルなどにより遅延を生じたときには、品質、機能、開発メンバーなどのどこかにしわ寄せが出てしまいます。通常、計画作成は開発経験や技術スキルを持った人が行っていますから、計画通りに開発を進めるにはどうしたらよいのかと割り切って考えるのが、仕組み構築には良い結果を生みます。今回は、計画通りにできないことが課題として、その原因を分析します。
 
 図22は、開発工程別の工数比率を計画と実績で比較したものです。まず、評価が少ないことがわかります。これは、設計が計画よりも多いことと関係しており、設計が予定よりも長引くことで、結果的に評価時間を少なくしていることが原因です。これを確認するためには、レビューにおける不具合指摘件数やその対処時間などを調査し、設計完成度の推移を確認する必要があります。この事例では、そもそもレビューで設計完成度を確認していなかったこと、試作におけるトラブルは設計での確認が不十分だったことが確認できたので、試作ごとの設計完成度が低いことが原因であることは確かです。
 
                       R&D
                                             図22.計画と実績の開発工程別工数比率
 
 次に、間接作業が多いことが目立ちます。ここで、間接作業とはプロジェクト内の開発作業とは直接関係のない作業であり、出張のための移動時間やプロジェクト内の改善活動、社内報告会のための準備などが含まれます。間接作業について詳しく調べてみると、この設計部門では様々な改善活動をタスクフォースとして実施しており、開発メンバーは、製品開発には関係しない打ち合わせやレポート作成などのタスクフォース関連作業に、かなりの時間を使っていることがわかりました。改善活動は必要なことですが、計画の2倍近い時間をかけていることや開発そのものが遅れていることなどから考えると、問題ととらえるのが妥当でしょう。そして、このような状況を引き起こしている原因は、設計部門における改善活動の全体をマネジメントしているチームが存在せず、何か問題があるたびにマネジャーの指示で新たなタスクフォースを作っていることです。
 
 また、設計作業が多くなっているので、回路設計や原価計算、製造性設計など設計における個別作業の効率が低い可能性についても確認する必要があります。設計作業を詳細分析したところ、評価項目の設計に多くの時間が割かれていることがわかりました。大量の評価項目のリストアップを、抜けや条件漏れなどがないように細心の注意を払って行わなくてはいけないにもかかわらず、技術者が開発のたびにゼロから実施していました。同じラインナップの製品であれば評価項目や評価条件などは再利用可能なはずですが、この作業が副次的なものであるために、改善を議論することはなかったのです。
 
 以上の分析により、「(a) 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施している」という課題を引き起こしている原因が、次のように整理できることがわかりました。
 
  (1)設計完成度を確認する仕組みがない
  (2)改善活動をマネジメントするチーム(組織機能)がない
  (3)評価項目や評価条件を再利用する仕組みがない
 
 これらの原因を解消することができれば、設計作業を予定通りに完了させることができ、評価やその次の試作の設計を並行して実施することがなくなると考えることができます。そして、これは開発効率2倍という目標達成のための有効な方策となるはずです。また、この段階でこれら一つひとつに対して対策を考えたり、ツールやシステムを調査・検討するためにメーカーやベンダーの話を聞くことになります。
 
 ここまで、課題 (a) について原因分析をしましたが、(b) (c) (d) の課題についても同じように原因分析を行い、その解決のための対策を検討します。これができると、目標達成のために取り組むべき一連の対策が明らかになります。また、その対策を実施することで何がどうかわるのかも明確になります。頂上までの登山ルート(対策の実施順序など)はまだ明確にはなっていないものの、一連の対策という登山マップと、対策実施の効果というコンパスを手に入れたということです。
 
 この段階で、各種のツールやシステム、手法や技法を調査・検討しますが、これらはある意味、万能です。いくつもの機能を持ち、多様な要求に応えることができるようになっています。そのため、機能を比較してどれだけ万能なのかを評価したり、他社の活用事例を収集した...

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

 前回のその2に続いて解説します。前回の分析で進捗上の問題であることが明確になったので、次にその原因を分析しましょう。もしかすると、単純に進捗の問題にしてしまうことに違和感があるかもしれません。実際、計画自体が現実的ではないから、計画通りに開発を進めることができないのは確かです。
 
 多くの製品開発は、開発着手とリリースの日程が決まっており、その決められた日程での開発が開発現場は要求されています。日程最優先ですから、トラブルなどにより遅延を生じたときには、品質、機能、開発メンバーなどのどこかにしわ寄せが出てしまいます。通常、計画作成は開発経験や技術スキルを持った人が行っていますから、計画通りに開発を進めるにはどうしたらよいのかと割り切って考えるのが、仕組み構築には良い結果を生みます。今回は、計画通りにできないことが課題として、その原因を分析します。
 
 図22は、開発工程別の工数比率を計画と実績で比較したものです。まず、評価が少ないことがわかります。これは、設計が計画よりも多いことと関係しており、設計が予定よりも長引くことで、結果的に評価時間を少なくしていることが原因です。これを確認するためには、レビューにおける不具合指摘件数やその対処時間などを調査し、設計完成度の推移を確認する必要があります。この事例では、そもそもレビューで設計完成度を確認していなかったこと、試作におけるトラブルは設計での確認が不十分だったことが確認できたので、試作ごとの設計完成度が低いことが原因であることは確かです。
 
                       R&D
                                             図22.計画と実績の開発工程別工数比率
 
 次に、間接作業が多いことが目立ちます。ここで、間接作業とはプロジェクト内の開発作業とは直接関係のない作業であり、出張のための移動時間やプロジェクト内の改善活動、社内報告会のための準備などが含まれます。間接作業について詳しく調べてみると、この設計部門では様々な改善活動をタスクフォースとして実施しており、開発メンバーは、製品開発には関係しない打ち合わせやレポート作成などのタスクフォース関連作業に、かなりの時間を使っていることがわかりました。改善活動は必要なことですが、計画の2倍近い時間をかけていることや開発そのものが遅れていることなどから考えると、問題ととらえるのが妥当でしょう。そして、このような状況を引き起こしている原因は、設計部門における改善活動の全体をマネジメントしているチームが存在せず、何か問題があるたびにマネジャーの指示で新たなタスクフォースを作っていることです。
 
 また、設計作業が多くなっているので、回路設計や原価計算、製造性設計など設計における個別作業の効率が低い可能性についても確認する必要があります。設計作業を詳細分析したところ、評価項目の設計に多くの時間が割かれていることがわかりました。大量の評価項目のリストアップを、抜けや条件漏れなどがないように細心の注意を払って行わなくてはいけないにもかかわらず、技術者が開発のたびにゼロから実施していました。同じラインナップの製品であれば評価項目や評価条件などは再利用可能なはずですが、この作業が副次的なものであるために、改善を議論することはなかったのです。
 
 以上の分析により、「(a) 繰り返し実施する試作が同時作業となっており、設計の時期に直前の試作の評価を並行して実施している」という課題を引き起こしている原因が、次のように整理できることがわかりました。
 
  (1)設計完成度を確認する仕組みがない
  (2)改善活動をマネジメントするチーム(組織機能)がない
  (3)評価項目や評価条件を再利用する仕組みがない
 
 これらの原因を解消することができれば、設計作業を予定通りに完了させることができ、評価やその次の試作の設計を並行して実施することがなくなると考えることができます。そして、これは開発効率2倍という目標達成のための有効な方策となるはずです。また、この段階でこれら一つひとつに対して対策を考えたり、ツールやシステムを調査・検討するためにメーカーやベンダーの話を聞くことになります。
 
 ここまで、課題 (a) について原因分析をしましたが、(b) (c) (d) の課題についても同じように原因分析を行い、その解決のための対策を検討します。これができると、目標達成のために取り組むべき一連の対策が明らかになります。また、その対策を実施することで何がどうかわるのかも明確になります。頂上までの登山ルート(対策の実施順序など)はまだ明確にはなっていないものの、一連の対策という登山マップと、対策実施の効果というコンパスを手に入れたということです。
 
 この段階で、各種のツールやシステム、手法や技法を調査・検討しますが、これらはある意味、万能です。いくつもの機能を持ち、多様な要求に応えることができるようになっています。そのため、機能を比較してどれだけ万能なのかを評価したり、他社の活用事例を収集したりしがちなのですが、『自分の設計部門で効果を出すことができるかどうかは、課題の原因を解消できる使い方ができるかどうか』にかかっています。つまり、効率的、効果的に自分の設計部門用に用意した登山マップとコンパスにあわせた使い方ができるかどうかが重要なのです。次回は、開発効率2倍のゴールを達成するための登山ルートを具体化するまでのステップを解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
製品ライフサイクルとサプライチェーン

 新製品を開発した後、市場に投入(上市)して売上を伸ばしていく過程で、短期的に増減があったとしても、大きなトレンドとしては上昇過程があってピークに達し、そ...

 新製品を開発した後、市場に投入(上市)して売上を伸ばしていく過程で、短期的に増減があったとしても、大きなトレンドとしては上昇過程があってピークに達し、そ...


技術戦略 研究テーマの多様な情報源(その33)

  前回の『価値づくり』に向けての三位一体の技術戦略 第3回では、個人単位でテーマ創出のためのスパーク(革新的アイデアの創出)を起こす重要...

  前回の『価値づくり』に向けての三位一体の技術戦略 第3回では、個人単位でテーマ創出のためのスパーク(革新的アイデアの創出)を起こす重要...


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

  前回から、「発想のフレームワークを使ってイノベーティブなアイデアを発想する手順」の次のステップで、かつ最後のステップである「切り取った...

  前回から、「発想のフレームワークを使ってイノベーティブなアイデアを発想する手順」の次のステップで、かつ最後のステップである「切り取った...


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

もっと見る
設計部門の仕組み構築(その3)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...


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

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

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


技術高度化の5戦略

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...