製品開発では、初期の構想をいかに明確に設定するかが重要です。
セットベース開発では、構想段階で沢山の代案を考えておいて、意思決定を遅らせることによって、結果的に効率化が図れるそうです。
私はそうは思いません。
プロジェクトメンバーは、自分の開発した部分が、構想に照らして良かったのかどうか、自分の成果の評価を早くしてほしい。
あるいは、自分が次の一歩前を踏み出して良いかどうかが気になります。
例えば、車のドアの中のスペース獲得闘争があります。
少し大袈裟な表現ですが、ドアーの外板と内張り（ドアトリム）の間のスペースには、ウィンドウレギュレータ、やスピーカーなどをはじめ、想像以上に多くの部品を配置します。
ウィンドウレギュレータ、やスピーカーの設計者はそれぞれ別の担当者です。
両者が話し合って、配置案がうまく成立すれば良いのですが、両者の主張が対立してしまった時、どうしたら良いでしょう。
そこにプロダクトマネジャーが登場します。両者の言い分を聞き、初期の構想をベースにして、どういう落とし所にするかを決定するのが、チーフエンジニアです。
チーフエンジニアは、お客さま満足を第一に構想をまとめますので、その視点で常に全体最適を考え、意思決定をします。
このような意思決定にあたって、チーフエンジニアに、アポイントをとって、会議室を設定して、関係者をできるだけ多く集めて、対策会議を開いていたら、製品開発のリードタイムはどんどん伸びていきます。
その間のあ関係者の工数を拘束することを考えると、非効率極まりない状況になってしまいます。これがセットベース開発です。
大部屋なら、
関係者が同じ部屋にいますので、スピーカー設計者から持ち込まれた問題は、立ち所にチーフエンジニアに裁定を仰ぐことができて、ウィンドウレギュレーターの設計者の言い分をその場で聞いて、チーフエンジニアの方針が下ります。
例えば、構想で示した新技術を検討したが、思う通りの性能が出なかったというような場合。代案がいくつかあるとその内から選ぶことになります。
構想に織り込んだ新技術は、その製品の目玉です。代案があったらそれを諦めることになってしまうかもしれません。
しかし、構想案はその段階での「あるべき姿」です。
ここからが問題解決の出番になります。
「あるべき姿」と「今わかっていること（できていること）」そのギャップが課題です。
そのギャップの原因が何かを「なぜなぜ」で潰していきます。
「なぜなぜ」は、技術開発の左前線でも活躍しています。
日頃からの「なぜなぜ」の訓練がここで生きてきます。
上司と部下、先輩後輩、同僚の間で常日頃に問題をぶつけ合って、解決をする職場風土が大きな力になります。
組織の中には、専門家がいます。この領域のことは彼に聞け！という人が居るはずです。
もし一つの組織で問題が解決できないときには、専門家の知恵を借ります。
他の組織でも「なぜなぜ」を常日頃から活用していますので、言葉はすぐに通じます。
こうして、全員参加で周知を結集して、壁を乗り越えて、構想通り、構想以上の製品を生み出すのです。
Comments