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