今回は前回に続き新規事業開発での私の失敗談をご紹介します。
今回のテーマは「意思決定が複雑」です。
複数部署からメンバーを集めて
前回の投稿で紹介した新規事業プロジェクトは、社内の複数の部署からメンバーを集めたプロジェクトでした。役員が主導して複数事業部で検討されていた事業を統合して１つのプロジェクトにしました（詳しくは前回の投稿をご参照ください）
複数の部署で検討されていた時には、それぞれ事業部長や部長がプロジェクトオーナーをしていました。統合されると2名の事業部長が合同でプロジェクトオーナーをすることになりました。
ただ、2名の事業部長は責任範囲が広く、プロジェクトの定例ミーティング（週に1回）くらいしか、新規事業プロジェクトにコミットされた時間はありませんでした。
また、事業部長の下に部長クラスが数名いましたが、彼らも事業部長と同じく週に1回も定例ミーティングしか参加しません。日々の意思決定は課長クラスがプロジェクトマネージャーとして管理しており、営業、開発、マーケティング、業務設計など役割ごとにリーダーが指名され、私はマーケティングの責任者となりました。
役割ごとに業務を推進
日々の業務は、 営業、開発、マーケティング、業務設計など役割ごとにリーダーに任され、各役割ごとに予算やマイルストーン（プロジェクトや作業の中間目標地点や節目のポイント地点のこと）をプロジェクトオーナーである事業部長と握って作業をすすめました。
事業部長が参加する週次の定例ミーティング以外に、 プロジェクトマネージャーと各リーダーが議論する週次の定例ミーティングが設定され、細かな仕様などは、ここで議論しました。
大切な意思決定が玉虫色
細かな仕様などは、プロジェクトマネージャーと各リーダーが議論する週次の定例ミーティングで決められるものの、開発仕様から機能を削ったり、予算やリソースの調整はプロジェクトマネージャーと各リーダーに権限が委譲されておらず、 事業部長が参加する週次の定例ミーティングで判断を仰ぐかたちとなりました。
特に困ったのが、各事業部ごとに微妙に事業成功の定義がズレていることでした。総論的にはプロジェクト参加者全員が同じ方向を向けているのですが、システム部門にあたる事業部はIoTの事例として新規事業を成功させたいとの思いがありましたし、営業部門系の事業部は既存顧客に横展開できるプロダクトをつくることが目的となっていました。
このシステム部門と営業部門の事業部長がプロジェクトオーナーだったため、新規事業のサービスとしては、必ずしもマストではないIoTが優先度高く仕様に盛り込まれましたし、既存顧客の要望が必要以上に重視され仕様に盛り込まれました。
「その機能より、この機能の方が大切ではないか」とプロジェクトマネージャーやリーダーが集まる定例ミーティングでは方向性を示せても、事業部長2名が参加するミーティングで各事業部長が譲り合って、それぞれの要望する仕様の優先度を高めてしまいました。
反省点と学び
このプロジェクトから、私が学んだことは
- プロジェクトとして重視する軸を決めておく
- 意思決定者を複数置かない
- 意思決定は現場で日々、新規事業と向き合える人に任せる
といったところでしょうか。
このプロジェクトを経験して、私は新規事業プロジェクトを立ち上げる際には事業の『ミッション・ビジョン・バリュー』を決めるようにしました。
プロジェクトメンバー内で意見対立が起きても、 『ミッション・ビジョン・バリュー』を決めておくことで、立ち返って議論することでメンバー内に納得感のある決定ができるようになりました。
また、役員や事業部長など最終意思決定者にはプロジェクトマネージャーに権限移譲してもらえるように、初期に議論するようにしました。もちろん大きな予算の組み換えなど最終意思決定者に判断してもらう事項もありますが、良い報告だけでなく、悪い報告や課題の共有なども積極的におこなうようにして、安心して権限を委譲してもらうことが出来ています。
複数の事業をみる役員クラスからすると、新規事業の細かな意思決定を任せてもらうことでのメリットと、その前提での情報共有の方針を伝えることで快く、権限移譲してもらえています。
コメント