Club-Zコラム第8回

【第8回】現状課題とその原因分析は目標達成のための登山マップとコンパス

株式会社RDPi　　代表取締役　石橋　良造

2008.03.27

前述の分析で進捗上の問題であることが明確になったので、次にその原因を分析しましょう。もしかすると、単純に進捗の問題にしてしまうことに違和感があるかもしれません。実際、計画自体が現実的ではないから、計画通りに開発を進めることができないのは確かです。

ただ、多くの製品開発は、開発着手とリリースの日程が決まっており、その決められた日程での開発を開発現場は要求されています。日程最優先ですから、トラブルなどにより遅延を生じたときには、品質、機能、開発メンバーなどのどこかにしわ寄せが出てしまいます。通常、計画作成は開発経験や技術スキルを持った人が行っていますから、計画通りに開発を進めるにはどうしたらよいのかと割り切って考えるのが、仕組み構築には良い結果を生むことが多いようです。今回は、計画通りにできないことを問題と考え、その原因を分析しましょう。

図 22 は開発工程別の工数比率を計画と実績で比較したものです。まず、評価が少ないことがわかります。これは、設計が計画よりも多いことと関係しており、設計が予定よりも長引くことで、結果的に評価時間を少なくしていることが原因です。これを確認するためには、レビューにおける不具合指摘件数やその対処時間などを調査し、設計完成度の推移を確認する必要があります。この事例では、そもそもレビューで設計完成度を確認していなかったこと、試作におけるトラブルは設計での確認が不十分だったことが少なくないことが確認できたので、試作ごとの設計完成度が低いことが原因であることは確かです。



次に、間接作業が多いことが目立ちます。ここで、間接作業とはプロジェクト内の開発作業とは直接関係のない作業であり、出張のための移動時間やプロジェクト内の改善活動、社内報告会のための準備などが含まれます。間接作業について詳しく調べてみると、この設計部門では様々な改善活動をタスクフォースとして実施しており、開発メンバーは、製品開発には関係しない打ち合わせやレポート作成などのタスクフォース関連作業に、かなりの時間を使っていることがわかりました。改善活動は必要なことですが、計画の２倍近い時間をかけていることや開発そのものが遅れていることなどから考えると、問題ととらえるのが妥当でしょう。そして、このような状況を引き起こしている原因は、設計部門における改善活動の全体をマネジメントしているチームが存在せず、何か問題があるたびにマネジャーの指示で新たなタスクフォースを作っていることです。

また、設計作業が多くなっているので、回路設計や原価計算、製造性設計など設計における個別作業の効率が低い可能性についても確認する必要があります。設計作業を詳細分析したところ、評価項目の設計に多くの時間が割かれていることがわかりました。大量の評価項目のリストアップを、抜けや条件漏れなどがないように細心の注意を払って行わなくてはいけないにもかかわらず、技術者が開発のたびにゼロから実施していました。同じラインナップの製品であれば評価項目や評価条件などは再利用可能なはずですが、この作業が副次的なものであるために、改善を議論することはなかったのです。