アイデアを採用する時、実行する時に期待されるのは実行ではなく結果
昔、こんなスライドを書いたんです。部下だった時に色々アイデアを上申したけど、うまく通らなかったなぁという経験です。
この経験から、どうやったら思い通りに物事が進められるか考えたのがこのスライドでした。
あれから数年経ちまして、今は製品開発で役職までついているわけですが、改めて承認しやすい提案と、承認しにくい提案があるなぁと悩んでいたので再度筆をとりました。
アイデアを採用する時、実行する時に期待されるのは実行ではなく結果
仕事柄、様々なアイデアをいただくことがあります。外から受けるアイデアは学びとして受け取って消化すれば良いのですが、チームから受け取るアイデアについては気を使ってハンドリングする必要があります。
もしアイデアを採用しない場合、どの様な理由を述べたとしても
メンバーとしては拒絶のように感じたり思い通りに行かないと感じさせてデモチベーションさせてしまうからです。
だから、反対の理由が重要なのではなく、上手に上司と議論する為には何を満たさなければ行けないかを先に共有しておきたいと思います。
特に、目先の改善アイデアではなく飛び石的な改善アイデアです。
例えばUIをリニューアルしましょう！製品を変えましょう！などの野心的でチャレンジングなアイデアに対してこの記事はお役に立てると思います。
最低限３つの要素を満たしてほしい
アイデアを完璧な状態で持ち込む必要はないし、アイディエーションも問題ありませんが、意思決定を求めるタイミングで欲しいものは３つです。
⚠ 最初から最終意思決定を求めなくてもいいです。記事の都合上、直線的に議論が進む様に書かれていますが実際には詰めが甘い部分は詰めれば良いし、根拠が曖昧なら「曖昧なんですが」と断ればいいし、経験が足りなければ助けてほしいといえば良い。
意思決定のタイミングで欲しい物
Desirability
アイデアのセンスの良さみたいなもの。つまり、より上位の目的を理解して、提案してきているかを見ています。例えば受注率を上げたいのにマーケットを広げる提案をされると優先度が下がります。今、その会社・チームで改善したいKPIや数字は何かを把握して、それに影響を与える提案であることを理解できる様に説明されると良いです。また提案がそれらに良く寄与することが書かれているとなお良いです。実際に効果産めるって思えるソリューションアイデアがいい。思えないなら下調べして欲しい。または下調べまでしたいと相談してほしい。
Feasibility
実現可能なコスト、技術、アイデアなのか？技術だけじゃなく、コストやアサインなども含めて実現可能かどうか。例えば100人月かかる素晴らしいアイデアは全然素晴らしくないです。100人月あれば他の優先度高いことが出来るだろとなるからですね。つまり限られた予算や制約、既存機能や負債の中で出来ることであってほしいわけです。
当たり前ですがその年の戦略を考えるために多くの情報を持って議論してきて決めた優先度や予算があるわけです。それひっくり返すことになるわけなので、それ相応の議論が求められるでしょ？十分に練られた議論と戦うなら十分に練った提案が必要になり、大抵の場合それは難しいんです。なぜなら提案者は上司ほど情報をもっていないからだ。十分にキャッチアップしていれば問題ないがそれらが出来るケースは限られているように思う。
だから、現実的な解答、アイデアにチューニングされた状態で持ち込んでほしい。
もし未来的で非現実的なアイデアの場合は時間が必要であるということは理解してほしい。
ここの実現可能性を満たすには様々な方法があるので、最も頭を捻ってほしい場所だ。ミニマムにできないか？大きくやるならもっと勝率を高められないか？など。あなたの知識と経験（または頼る先輩や友人）によって大きく影響する。QCDSを意識すれば良い。
Viability( = GRID )
最後に重要だと思うのはGRIDです。提案されたいのは方法論ではなくどの様な結果を産みたいかを見ています。例えばXXの機能をリリースすると良い！という提案のときに見るのは機能本体ではなく、それによって得られる効果や狙いだ。この狙いにコミットしてくれる人材からの提案であれば受け止めやすい。機能をリリースするだけで終わられても困るわけで、リリースによって得たいコトを責任として提案してほしいし、その為のKPIや計測値を決めて置きたいわけだ。よくアウトカムと言われるもの。
逆にいうとアウトカムさえ、ビジネスの方針（Desirability)と合っていれば、方法は変えてもいいと思う（Feasibleな範囲で）。つまりマネージャーはOutcomeを期待して任せるわけで、How/Solutionは所詮実行アイデアの一つでしかないわけだ。つまり提案者は自分が達成できると思われるアウトカムを提案すると良いというわけだ。
そしてこれらを確認する為に以下のような質問をする
この提案の背景、原体験、モチベーション、課題意識は何？
なんでこの提案選んだの？他にもアイデアあった？
実例
もう少し、実体験に沿って話すコトで私が何を行っているのか理解を手伝うことができれば嬉しい。
うまく行かなかった提案の実例：
エンジニアからデザインの問題に対して、もっとクールでアクショナブルでシンプルなわかりやすいUIにするべきだと提案された。今が如何に悪く、海外のSaaSはこうだから、もっとこうすべきだし、そうするともっとユーザビリティは良くなって製品は改善するはずだと。
様々な分析や所感を述べた提案書をもらったが、リジェクトした。なぜか？
実行すべき人が不在。つまり「誰かやった方がいい」という提案だった。GRIDが期待できない。そうゆう提案は責任不在になるので通りにくい。せめて誰か同意してくれるデザイナーを連れてくるべきだっただろう。私はアイデアをありがたくいただき、１年後に実行に移すことになった。
ソリューションと効果が提案されたがDesirabilityに関する提案が大きく欠けていた。つまり私にとってはあらゆる「やった方がいい」に新しい「やった方がいい」が追加されただけだったんだ。優先する理由がない。基本的に全ては一般論だった。
GRIDとつながるが、成果（アウトカム）に対して述べなかったのでアイデアは参考にとどめることになった。せめて海外の事例やレポート、論文などの客観的な情報をもう少し与えてくれたら判断は変わったかもしれない。つまり終始ソリューションが提案されただけなのだ。「リリースして何も変わらなかったら、どうやって振り返るの？」概ね95%は何も起きない。
うまく行った時の提案の実例：
新しいツールをリリースしてみたらどうかと提案された。それによって得たいアウトカムはリードの獲得や、トライアルコストの低減、認知の獲得であると。その為にはそれほど大きな開発を必要とせずに1.5人月くらいで出来る提案だった。
デザインリニューアルに比べれば大胆ではない提案だったが、大きな期待値をもてる提案として承諾した。なぜか？
提案者はエンジニアだったが、ツールによって生み出せる価値（アウトカム）を定義していた。これは、何を計測して成功とみなすのかを聞いたところ、ユーザーの利用率またはリード獲得を目的とすると言い切った。ツールのリリースがゴールではなくアウトカムを得られたかどうかが議論できるだろうと感じた。ゴールは遠すぎず、この提案によって得られる現実的なゴールだった。そして提案者がこのオーナーシップを持てると感じた。エンジニア側からもこの効果(例：ユーザー獲得）を作ってくれるなら、それは最高だと思った。
提案者がこの提案を実行し、失敗したとしてもゴールに対してPDCAを実行し、新しい提案をくれるだろうと感じた。つまりアウトカムにコミット(オーナーシップを持てそうな）できそうな提案だった
ソリューションはそれほど目新しいものではなかったが、コンセプトとしては今直面している問題に対してアプローチできる手段のうちの一つだと考えた。
大きな提案をする時には以下の点を明らかにしよう。
あなたがオーナーシップをもてることなのか？またはオーナーシップを持つ相手を見つけているか？あなたがアウトカムの獲得までやりきれるセンスと知識と経験を持ち合わせているか？(背伸びしすぎてないか)
今優先度高いアウトカムを目標としているか？戦略と沿っているか？
現実的に実行可能か？追加予算は許容範囲か？失敗したときに継続して理チャレンジできるか？
そう、アイデアを採用する時、実行する時に期待されるのは、実行（リリース）ではなく、結果（アウトカム）であることを忘れずにしよう。
提案を考えるのは難しくなるが、通るのはより簡単になるだろう。しかしこれこそが本当に求められている「実行可能で効果的なアイデア」なのだ。
オーナーシップを持つということは、責任をもつということ。責任とはアウトカムを生み出すことにかかっているものが一番強い。
10000のアイデアは貴重だけれど、大変なのはそれを３つの要素を満たす行動プランに移すことだと日々感じている。ぜひそうゆう視点で提案活動をブラッシュアップしてもらえると良いのではないかと思います。