設計部門の課題と原因分析(その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回では、個人単位でテーマ創出のためのスパーク(革新的アイデアの創出)を起こす重要...


AI(人工知能)が加速させるモノづくりの進化

 1980年代、世界のIT業界で人工知能(AI)ブームが起きました。日本の通産省が人工知能を実現する次世代コンピューターの開発を目指して、第五世代コンピュ...

 1980年代、世界のIT業界で人工知能(AI)ブームが起きました。日本の通産省が人工知能を実現する次世代コンピューターの開発を目指して、第五世代コンピュ...


普通の組織をイノベーティブにする処方箋 (その172) 物になったと仮定して

【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その171)へのリンク】   これまでアナロ...

【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その171)へのリンク】   これまでアナロ...


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

もっと見る
進捗管理の精度を上げる:第2回 プロジェクト管理の仕組み (その14)

 実際の進捗管理方法について、基本メトリクスセットの中の「作業成果物」から紹介します。作業成果物とは開発作業を進める中で出力されるもののことです。ハードウ...

 実際の進捗管理方法について、基本メトリクスセットの中の「作業成果物」から紹介します。作業成果物とは開発作業を進める中で出力されるもののことです。ハードウ...


仕組み見直しとグローバル化(その1)

◆「気づき」能力向上のカギは製品開発経験の活用    前回は、日本の多くの開発現場で「組み合わせ型」アーキテクチャの製品を「擦り合わせ型」の...

◆「気づき」能力向上のカギは製品開発経験の活用    前回は、日本の多くの開発現場で「組み合わせ型」アーキテクチャの製品を「擦り合わせ型」の...


富士フィルムにおけるコア技術の活用戦略

 本業であるフィルム事業がなくなることを経験した、富士フィルムの技術の棚卸活動は注目に値します。アスタリフトや液晶用フィルムは、フィルム事業で培ったコア技...

 本業であるフィルム事業がなくなることを経験した、富士フィルムの技術の棚卸活動は注目に値します。アスタリフトや液晶用フィルムは、フィルム事業で培ったコア技...