私はいま会社でテックリードをしていますが、いちエンジニアとして技術的改善をチームに提案するスキルに関してまだ課題感を持っています。その際同じくチームに所属しているエンジニアリングマネージャー（EM）の方にヘルプしていただき、実際に提案資料をペアライティングした中で湧いたイメージがあるのでブログとしてまとめて自分の考えを整理してみようと思います。
効果的なストーリーテリングのための既存のフレームワーク
技術的な提案をするには効果的なストーリーテリングをするスキルが必要だと考えています。私はストーリーテリングに関して詳しくありませんが、仕事を通じて以下の二つのフレームワークを知りましたので軽く紹介します。世の中には他にもいろいろあると思いますが、基本的な考え方は近いのかなと想像しています。
- 空・雨・傘
- STARフレームワーク
空・雨・傘
EMの方と会話する中で「空・雨・傘」というフレーズを何度か耳にしました。恥ずかしながら自分はこのフレームワークを知らずに仕事してきましたが、問題解決・思考整理のための手法の一つだそうです。
「空に黒い雲がある（現状認識）」→「雨が降りそう（現状分析）」→「傘を持って行こう（解決）」のような整理の仕方をしようというものです。
STARフレームワーク
別の文脈で「STARフレームワーク」も仕事を通じて知りました。こちらは評価面談に向けた自分の仕事を振り返る時に使ってはどうかと同僚に以前共有されたことがあり、実際に使ってきたものです。
「Situation（状況）」「Task（課題）」「Action（行動）」「Result（結果）」の頭文字をとっていて、実際にどのような状況をどういう行動をとって結果をもたらしたのかというのを人に伝える際に説得力のあるストーリーテリングができるようになるというものだそうです。STARフレームワークは面接で自己アピールをするのに適しているそうです。
順序立てて話すということ
結局ここで紹介した二つのフレームワークはどちらも物事を一つのストーリーとして順序立てて話しましょうということだと理解しました。何か突発的な問題や課題をエンジニアが認識する際はすぐさま解決策を考えて行動したくなることがあったりしますが、選択肢が複数ありトレードオフもさまざまな場合はしっかりなぜそういう選択をするべきなのかという話をして説得力を持たせたいものです。
話に説得力を持たせたい時に事実と憶測や感情などが混じっていると話を聞いている側はコメントもしづらく「いいですね」とは言いづらい。そうならないためにも、「空・雨・傘」では「空」と「雨」を明確にわけているし、「STARフレームワーク」では相手に伝えることを意識して「状況」や「課題」をひとつずつちゃんとわけています。
相手を意識して伝えるということ
順序立ててまとめることにより、提案の説得力はあがります。とはいえそれで満足するのではなく、結局誰かに納得してもらうことが本来の目的のはずなのでその相手の立場にたって資料や文章をまとめることを意識する必要があります。
テックリードの立場でエンジニアチームに向けて「今後これこれこういう理由でこの技術的選択をします」と伝えるだけなのであれば技術面での前提知識は既に揃っていたり、そもそも議論の余地もないケースであれば共有するだけでOKだったりします。
一方で、「2月からエンジニア1名の工数を1ヶ月使ってこういった改善を行いたいと思っています」みたいなことをプロダクトオーナー（PO）に向けて伝えたいのであればしっかりとそう思い立った理由をPOが理解できる形でまとめなければいけません。POが非開発職バッググラウンドだったりする場合は特にそうです。
具体的に必要なものは最初に話していたストーリーテリングの他に、以下の2点もあると思います。
- 相手の知りたい情報を簡潔に書く
- 具体的には、実施した場合のコストと見込まれる効果を明示する（費用対効果）
- 非開発職にも伝わるような日本語を使う
どのような施策を実行したら効果が出るのかエンジニアで検討する際は細かくいろいろ考えるかもしれませんが、PO目線では課題・分析・選択肢・コスト・効果が知りたいのでそこを簡潔に伝えられると難解な文章を読み解いてもらう必要がなくなってよいです。
また、PO vs. 開発者みたいに切り分けて考えるのも良くないです。何なら技術的施策を考えるテックリードも技術領域に特化したPOとも言えます。プロダクトの次の施策を考えてなぜやるべきかをPOがまとめるのと同じように、TLも技術的施策を丁寧に進められるとよいのかなと思います。
