ステークホルダーで意見が割れる
営業は「顧客が求めている」と言い、開発は「技術的に難しい」と言い、
経営は「コストが高すぎる」と言う。いつまでも合意できない。
対立の典型パターン
- 営業「大手A社がこの機能を求めています。失注したらどうするんですか」
- 開発「その機能は技術的に複雑で、3ヶ月はかかります」
- 経営「3ヶ月もかけるなら、他の案件を優先すべきでは」
- (2時間後)「来週また話しましょう...」
なぜ合意できないのか
1. 「顧客」が人によって違う
営業が言う「顧客」は大手A社の担当者。
マーケが言う「顧客」はペルソナとして設計した想定ユーザー。
開発が言う「顧客」は技術コミュニティ。
全員「顧客のため」と言いながら、見ている人が違う。
2. 価値の測り方が違う
営業は「売上インパクト」で価値を測る。
開発は「技術的な美しさ」で価値を測る。
経営は「ROI」で価値を測る。
物差しが違うから、比較ができない。
3. 感情と政治力で決まる
共通の判断基準がないから、結局「声の大きい人」「政治力のある人」の意見が通る。
それに不満を持つ人がサボタージュを始め、プロジェクトは停滞する。
toishi で合意形成する方法
ペルソナで「顧客」を統一する
「20代女性」ではなく「渋谷で働く28歳のマーケター、田中さん」として定義。
名前、年齢、職業、課題、行動パターンまで具体化することで、
全員が同じ人物を思い浮かべながら議論できる。
「田中さんならこう操作するよね」
ペルソナが共通言語になる。
ROI で価値を数値化する
「この機能は月間何回使われるか」「工数はいくらか」を計算し、ROI を出す。
営業も開発も経営も、同じ数字で議論できる。
Before
「この機能は大事です」「いや、こっちの方が」(永遠に平行線)
After
「A は ROI 625、B は ROI 33。A を優先」(15分で決定)
承認フローで責任を明確化
誰が何を承認したかが記録される。
「聞いてない」「知らなかった」がなくなり、
後からの蒸し返しを防げる。
対立が協調に変わる瞬間
「大手A社がダッシュボード機能を求めています」
「toishi で ROI を計算してみましょう。月間何回使われますか?」
「A社だけで月500回、同業他社を含めると月2,000回は使われます」
「フル機能だと40人日、MVP版なら10人日です」
「MVP版なら ROI 200、フル版でも ROI 50。どちらも価値はありますね」
「MVP版で始めて、効果を検証してからフル版に投資しましょう」
数字があれば、30分で建設的な結論に到達できる