【設計部門の仕組み改革 連載目次】
前回のその2に続いて解説します。理想追求型アプローチは、本質的にリスクを抱えています。それは、システムベンダーなどが紹介する事例や成果が、自分の組織に合うかどうかがわからないという点です。あくまでも他社の例なのですから、システム機能の一つひとつについて有益かどうかは判断できても、自社の設計部門全体から見たそのシステム機能の期待効果や、導入コストまではわかりません。コンサルタントとしていくつもの設計現場を見てきましたが、設計部門全体で見るとその仕組み（開発プロセス）は様々です。どの設計部門も、長年の知恵や工夫が詰め込まれた固有の仕組みを持っています。したがって、紹介された理想型をそのまま導入できるかどうかも、他社事例を参考にできるかどうかも、費用対効果をしっかりと見極めないと大きなリスクを抱えたままの投資となってしまいます。どうして、このようなリスクがあるにもかかわらず理想追求型アプローチを採るのでしょうか。これは、設計部門における仕組み構築に対する認識の問題だと考えられます。
理想追求型アプローチを採る設計部門の方と話をすると感じるのですが、仕組み構築の行程は、ゴール（あるべき姿）に向かう一本道を、多少の障害があるものの、とにかく前進してゴールを目指すものと考えているようです。しかし、私は、設計部門における仕組み構築は下表のように山登りだと考えています。
仕組み構築の目標（ゴール）は開発効率2倍、開発期間 1/2 などと様々ですが、上表ではそれを頂上とし、開発効率 20% アップ、40% アップなどの途中の段階を（標高）レベルとしてあらわしています。現在の状態は山の麓のレベル1で、仕組み構築とは、レベルを一つひとつ上げていき、最終的に頂上にたどり着くという活動です。
設計部門といっても作っている製品や、技術者、設備、規模、歴史など様々です。先ほども、設計部門全体で見るとその仕組みは固有で様々だと述べました。したがって、現時点（レベル1）におけるポジションは様々です。そして、同じ頂上を目指すとしても、そこまでのルートも様々なのです。ひとつ上のレベルに登るのでも、その位置取りには選択の余地があります。東側を目指すのか、南側を目指すのか、選択の余地は小さくありません。さらにその一つ上のレベルに登るときも同じです。つまり、現在地点からゴールまでのルート選択には非常に多くの選択肢が存在しているのです。時には、他社事例という他の登山隊が通ったルートを選択することができるかもしれませんが、また別の時には、ルートそのものを開拓しなければならない場合もあります。
製品、技術、スキル、マネジメント、歴史など様々な要素から成り立っているのが設計部門なのですから、その仕組み構築とは一本道を進む活動なのではなく、頂上を目指す山登りなのです。そして、ゴール設定も重要ですが、ゴールまでのルート選択が成功と失敗を決めることになるのです。
以上、ある製品開発事例を使って、開発効率2倍をゴールとして、製品開発の現状を工数という視点から定量化して、そこから現状の課題を明らかにして、その課題解決のためのルート候補をリストアップしてみました。次にやるべきことは、このルート候補を評価してどのルートがゴールまでの最短ルートなのかを評価することです。
図20.製品開発における開発工程ごとの工数推移
ところで、図20 の例では、構想設計に大きな時間がかかっていること、開発試作と2Sにピークがあることも気になる点です。次回は、これらの気になる点に加えて、個別の開発プロジェクトだけではなく、設計部門全体の現状についても把握した上で、ゴールまでのルート候補の評価を行う過程についてお伝えしたいと思います。ゴールを開発効率2倍と設定するということは、その達成のためのロジックを考える際に、今回のように定量的に現状を把握する必要があることを忘れないでください。仕組み構築の最初のステップは、仕組み構築のプランニングに必要となる定量把握の仕組み...
