即断即決の仕組み

製品開発では、初期の構想をいかに明確に設定するかが重要です。


セットベース開発では、構想段階で沢山の代案を考えておいて、意思決定を遅らせることによって、結果的に効率化が図れるそうです。


私はそうは思いません。


プロジェクトメンバーは、自分の開発した部分が、構想に照らして良かったのかどうか、自分の成果の評価を早くしてほしい。

あるいは、自分が次の一歩前を踏み出して良いかどうかが気になります。



例えば、車のドアの中のスペース獲得闘争があります。

少し大袈裟な表現ですが、ドアーの外板と内張り(ドアトリム)の間のスペースには、ウィンドウレギュレータ、やスピーカーなどをはじめ、想像以上に多くの部品を配置します。


ウィンドウレギュレータ、やスピーカーの設計者はそれぞれ別の担当者です。

両者が話し合って、配置案がうまく成立すれば良いのですが、両者の主張が対立してしまった時、どうしたら良いでしょう。


そこにプロダクトマネジャーが登場します。両者の言い分を聞き、初期の構想をベースにして、どういう落とし所にするかを決定するのが、チーフエンジニアです。


チーフエンジニアは、お客さま満足を第一に構想をまとめますので、その視点で常に全体最適を考え、意思決定をします。


このような意思決定にあたって、チーフエンジニアに、アポイントをとって、会議室を設定して、関係者をできるだけ多く集めて、対策会議を開いていたら、製品開発のリードタイムはどんどん伸びていきます。

その間のあ関係者の工数を拘束することを考えると、非効率極まりない状況になってしまいます。これがセットベース開発です。


大部屋なら、

関係者が同じ部屋にいますので、スピーカー設計者から持ち込まれた問題は、立ち所にチーフエンジニアに裁定を仰ぐことができて、ウィンドウレギュレーターの設計者の言い分をその場で聞いて、チーフエンジニアの方針が下ります。


例えば、構想で示した新技術を検討したが、思う通りの性能が出なかったというような場合。代案がいくつかあるとその内から選ぶことになります。


構想に織り込んだ新技術は、その製品の目玉です。代案があったらそれを諦めることになってしまうかもしれません。


しかし、構想案はその段階での「あるべき姿」です。

ここからが問題解決の出番になります。


「あるべき姿」と「今わかっていること(できていること)」そのギャップが課題です。

そのギャップの原因が何かを「なぜなぜ」で潰していきます。

「なぜなぜ」は、技術開発の左前線でも活躍しています。


日頃からの「なぜなぜ」の訓練がここで生きてきます。

上司と部下、先輩後輩、同僚の間で常日頃に問題をぶつけ合って、解決をする職場風土が大きな力になります。


組織の中には、専門家がいます。この領域のことは彼に聞け!という人が居るはずです。

もし一つの組織で問題が解決できないときには、専門家の知恵を借ります。

他の組織でも「なぜなぜ」を常日頃から活用していますので、言葉はすぐに通じます。

こうして、全員参加で周知を結集して、壁を乗り越えて、構想通り、構想以上の製品を生み出すのです。



閲覧数:18回0件のコメント