見出し画像
Photo by 東洲斎写楽 / メトロポリタン美術館

提案を通す資料を書くためのチェックリスト

piqcy

「Amazonの会議は黙って文書を読むところから始まる」文化を聞いたことがあるでしょうか。AWSも例外ではなく、入社してから文書を書く機会が増えました。私はAWSの機械学習領域のDeveloper Relationsとして活動していますが、このポジションは私一人なので基本誰かに提案しない限り物事が進みません。特に海外のサービス開発チームのPdMと会話する際は英語があまり達者でないので、事前に提案書を用意して冒頭沈黙、コメントを書いてもらうということが多いです。

本記事では、書籍を読んだりレビューを頂く中で得た知見を整理しました。見出しがチェックリストとして機能するよう執筆しています。新年で提案書を書く機会が出てくる方もいると思うので、参考になれば幸いです。プレゼンテーション資料の作成術には触れていないので、参考資料を参照いただければ幸いです(今後書き足すかもしれません)。

提案は次図の構成になります。課題と仮説の箇所でボックスの大きさが変わっているのは意図的で、優先順位付けを意味しています。以降の節で、各構成要素の解説と確認点をまとめます。

提案の全体像

問題は相手にとって重要か

提案には相手がいます。相手にとって重要な問題でなければ、提案を聞いてもらえません。提案に関わる人の状況は一様でないので、だれにとっても重要な問題は意外とないと思います。そのため、場合によって重要な問題に「みせる」ことが必要になります。

例えば、あなたが子育てをしていて、定時ジャストに帰らないと保育園のお迎えに間に合わないとします。あなたにとって定時以降の残業は保育園のお迎えに間に合わないため「問題」です。しかし、子育てをしていないチームメンバーにとっては問題でなく、上司にとってはメンバー間の業務の融通で解決できるため自分にとっての問題ではないと考えているとします。

あなたの「問題」を他のメンバー、上司にとっても「問題」と思ってもらうにはどうしたらよいでしょうか。組織面と個人面、2つのアプローチ方法があります。

相手の組織内での役割から問題に見せる

会社として子育て世代に配慮した業務の調整を推進しており、各部門の部長が旗振り役にならねばならない、と通達が出ていたらどうでしょうか。上司には会社という組織から「子育てをしているメンバーへの配慮」が求められているので、職務上あなたからの要請を検討する必要があります。そのように振舞わない場合、会社の方針に反した行動をとることになるので上司にとって「問題」になります。

相手の個人的なモチベーションから問題に見せる

最近結婚してこれから先自分と同じ問題を抱えうるメンバーにとって、子育てのための制度が整っていないことは問題になりえます。上司が、そもそも残業時間を削減し誰にとって働きやすい職場を作りたいと考えていたらもちろん定時に帰れないことは問題です。一人一人プライベートな事情やキャリアへの思いを抱えて仕事をしているので、それを知ることは問題として見てもらうことに役立ちます。

なんだか人心掌握術みたいな印象ですが、なんにせよ「提案が相手にとって重要な問題を扱っているか」は提案をまず聞いてもらうために重要です。問題の影響度、範囲、頻度の前提は人によって異なります。

  • 影響度: わたしはそれほど問題だとは思わない

  • 範囲: わたしに影響は及んでない(訳: あなただけの問題)

  • 頻度: わたしにとってはそれほど発生しない

これらを組織面、個人面の観点から提案を受け取る人すべてにとって重要な問題に見えるようにする必要があります。

課題はリスト化され、問題へのインパクトが高い順に言及されているか

課題は問題を解決するために取り組む活動です。問題が「理想的な状態」と「現状」の差だとすると、現状を理想的な状態に持って行くための活動になります。子育ての例でいえば、「業務量を減らす」「業務の処理速度を上げる」「お迎えにかかる時間を減らす」「お迎えを他の人に依頼する」などがあるでしょう。

課題をリスト化する

課題をリスト化する時、フレームワークを使うことは有用です。子供のお迎えであれば、「業務の時間」と「お迎えにかかる時間」の2つを合計してタイムリミットに間に合えばよいので、業務の時間を減らす活動だけでなくお迎えにかかる時間を減らす、あるいはなくす活動も考えられます。MECEは「Mutually Exclusive and Collectively Exhaustive」の頭文字を取った造語です、「互いに重複せず、全体として漏れがない」様です。課題を洗い出すときはMECEにできているか意識すると良いでしょう。

課題のインパクトを評価する

課題は問題へのインパクトに沿いリスト化することが好ましいです。例えば、「お迎えを他の人に依頼する」ができたら少なくとも職場においてはあらゆる問題が解決します。逆に「業務量を減らす」のは通常そんなに減らせるものでもないので難しいかもしれません。一度に実行できる活動は限られますし、複数の活動をするとそれだけリソースも分散するため優先順位をつけることが好ましいです。

仮説はリスト化され、リスクが低い順に言及されているか

仮説は課題を解決する案です。検証されるまでは「仮」のアイデアです。「業務量を減らす」なら「新しく業務を引き受けない」「誰かに委譲する」などがあるでしょう。ここでも、MECEなどフレームワークを使うことが役立ちます。

仮説のリスクを特定し評価する

解決策にはリスクが伴います。たとえば、「新しく業務を引き受けない」なら人間関係が悪くなったり仕事が減る分給料が減るかもしれません。「誰かに委譲する」場合、仕事の仕方を教えたり手順をまとめるなど実施するためのコストがかかるかもしれません。最終的にはインパクトが大きい課題を低リスクで解決したいので、リスクを評価しておく必要があります。

(Optional)リスクの対応策を検討する

リスクの対応策を検討しておくと提案時の受け答えに役立ちます。リスクは容認する以外に予防、軽減、移転できる可能性があります。たとえば、あらかじめ仕事が引き受けられないと宣言しておくことで予防、万一発生してしまったら丁寧に断るようにすることで軽減、仕事の依頼は上司を通じて行ってもらうようにすることで移転するなどです。

検証は仮説の実現性とリードタイムを明らかにしているか

仮説が実際に実行可能か、可能な場合どれぐらいのリードタイムでできるかは事前に検証しておくことが好ましいです。検証に費用が掛かることもあるので、「どの仮説を検証するか決める」で提案を切ることも多いです。課題のインパクトと仮説のリスクを評価しておくことで対象の仮説を決めやすくなります。

仮説の検証は直接、間接の2通りがあります。ソフトウェアの開発で、プロトタイプを作って検証するのは直接検証に近いです。重要な提案であれば、直接検証を行う方が好ましいでしょう。

  • 直接検証

    • 実際に近い形で実施することで検証する。

  • 間接検証

    • 論文や書籍などから仮説の実現性を検証する。

「お迎えを他の人に依頼する」について母親が「大丈夫よ」といったものの、2~3日続けたら「大変だからもう無理・・・」となることはままあります。また、業務量を調整しようとしたら来年度でないと難しい、というリードタイムの問題が発生することもあります。仮説の検証では、すこしでも直接検証に近い形で手を付けてみるのが重要です。

示唆は相手の選択肢を絞り込んでいるか

示唆は提案の結論です。仮説は検証しても確実な答えは得られないので、「こうしたほうがいいと思います」という示唆に留まります。ただ、相手にとっては、最もインパクトが高い課題を最もリスクが低く実現性が高いアプローチで短期間に解決できる方法が示唆されていることになるので、決断が容易になる点で価値があります。

提案の段階に応じた会議体を設計しているか

最終的に示唆を出す前に、複数回会議が設けられるのが通常です。提案の構成のうち、どこまでを確認したいのか決めてから会議を開催します。次の図では、5つの会議を定義しています。結構細かく区切ったので、実際はまとめて実施されるものもあると思います。

  1. 問題点を共有し課題を洗い出すための会議

  2. 課題を解決する仮説を洗い出すための会議

  3. 取り組む課題と検証する仮説を決定するための会議

  4. 仮説の検証計画を承認するための会議

  5. 問題を解決する活動を決定するための会議

提案の段階に応じた会議体の種類

1と2を混ぜるのはお勧めしません。課題 x 仮説 は多くの組み合わせがあるので、1つの会議で両方話していると発散しすぎて収集がつかなくなるからです。仮説の洗い出しは、課題に詳しい人を集めて行う方が良いと思います。「業務の時間」と「お迎えにかかる時間」それぞれを短縮する課題があるとき、前者は職場で話し後者は家族で話したほうが適切かつアイデアが出ると思います。

提案を聞いた相手にしてほしいことは明確か

提案には依頼が書かれているのが通常です。予算を出してほしい、採用してほしい、物品を貸してほしいなど様々です。先ほどの子育ての例でいえば、「お迎えがある日は定時で変えれるよう業務を調整してほしい」などになると思います。意思決定を求めつつも、前節で言及したように相手の問題を理解していることが前提です。次図を参考に、特に人間関係を壊してしまう非難や説教になっていないよう注意してください。

コミュニケーションの目的分類
(ロジカルプレゼンテーション 図 3-3 を参考に作成)

個人的な経験としては、業務改善系の提案は非難や説教、顧客への提案の場合講義になりがちです。前者は「xxすべきなのにできてない」と相手が改善に踏み出せない状況(真の問題)を理解せずに正論をぶつけるパターン、後者は「アカウント登録してください」とか「ソリューションを採用してください」とか最後の一言を言わないで説明だけしてしまうパターンがあります。

提案の構成と、提案を通すための会議体についての解説は以上です。私自身、このチェックリストを使って今後もちょくちょくブラッシュアップしていこうと思います。

参考資料


この記事が気に入ったらサポートをしてみませんか？