「インターナルプレスリリース」をエンジニアが書いてみて感じた効果
この記事は、NAVITIME JAPAN Advent Calendar 2022の6日目の記事です。
こんにちは、bananaです。ナビタイムジャパンで『行程表クラウド』というB to BのWebプロダクトの開発・運用を担当しています。
私の所属するプロジェクトでは、新規プロダクトや新機能を検討する際「インターナルプレスリリース」を書くことがあります。
これは、Amazonで取り入れられている手法を参考にしています。
「インターナルプレスリリース」をなぜ書くことになったのか、書くことでどんなメリットがあるのか、エンジニアの視点からまとめたいと思います。
インターナルプレスリリースとは
プレスリリースは、本来はプロダクトや新機能のリリース前に、社外向けに書くものですよね。しかし、Amazonではプロダクトの検討段階から、先に「社内向け」にプレスリリースを書くそうです。これはインターナルプレスリリースと呼ばれています。
ステークホルダー（利害関係者）に対し、いかにその提案の良さを理解してもらうか。
(中略)
そして、ステークホルダーに対する説得ツールの1つとして、アマゾンではプレスリリース形式のフォーマットを、非常に有効な手段として考えているのです。
参考にした書籍によると、例えばこのような構成になっています。
ヘッドライン：タイトル
サブヘッドライン：市場
第1段落：商品概要・利点
第2段落：解決する問題
第3段落：解決方法
第4段落：責任者の声
第5段落：どれくらい簡単か
第6段落：お客様の声
第7段落：まとめ、補足
インターナルプレスリリースを書くことになった背景
私が初めてインターナルプレスリリースに触れたのは、新規プロダクト開発開始のためのキックオフミーティングでした。
プロジェクトマネージャーがGoogleドキュメントに執筆してくれたものをチームで読み、コメントをする形で認識のすり合わせをしていきました。
箇条書きで書かれることが多いプレゼンの形式とは異なり、Narrative(物語的)であるプレスリリース形式で書かれていることで、認識の齟齬がなく理解できたように感じました。
このとき、初めて集まったメンバーにも関わらず「インターナルプレスリリース」での認識合わせがとてもスムーズに進んだので「これからも、新プロダクト開発時だけでなく、新機能レベルの開発時にも取り入れてみよう」ということになりました。
プロジェクトでどのように取り入れたのか
私が所属するプロジェクトはB to Bのプロダクトを運用しています。
今までの新規開発時の動きは、
営業がお客様の要望をヒアリング
営業が機能のイメージをエンジニアに共有
エンジニアがGoogleスライドで仕様に落とし込み
プロジェクトで議論して仕様確定
という流れでした。
この流れの中で、仕様を作成する前に、エンジニアが「インターナルプレスリリース」を作成するステップを追加しました。
インターナルプレスリリースを書いて感じた効果
①ロジックが通っていないことに、実装前に気づける
インターナルプレスリリースにはテンプレートがあるのですが、その中には「解決する問題」「解決方法」の他に、「実際のユーザーAの声」を書く必要があります。
一番気づきが多いのは「実際のユーザーAの声」を書くときです。実際のユーザーになりきって、機能を使ってみた感想を書くことになるので、ロジックが通っていないとうまく文章をまとめることができません。
実際にあった例を紹介します。
私が担当している『行程表クラウド』は、主に旅行会社と貸切バス事業者の方向けのサービスです。旅行会社が作成した行程表(旅行プラン)に対して、貸切バス会社が見積もりを作成することができ、両者のやり取りの中で修正を重ねて、最終的な見積もりを確定します。
利用中の旅行会社の方から「今は企業内の行程表がすべて確認できる状況になっているが、行程表が増えてきて、自分が所属しているチームが担当している行程表がどれなのかわかりにくくなった」という意見をいただきました。この課題に対して、当初「行程表ごとに公開範囲を設定する」という機能のイメージが提案されていました。
この内容でプレスリリースを書こうと思った時、うまく文章をまとめることができませんでした。
行程表クラウドを利用中のT旅行会社の管理者Aさんは
「T旅行会社には全国に6つの支店があり、各支店ごとに状況を把握する必要がありました。今回のアップデートで、行程表に公開範囲を設定できるようになったことで、、、(ここで手が止まってしまった)」
見える行程表が制限されて支店の状況が見えやすくなりました？
そもそもユーザーが行程表ごとに公開範囲を設定するのは大変なのでは？
ここで、求められているのは「行程表ごとに公開範囲を設定する」ではなく「行程表を作成したチームごとに絞り込む機能」だと気がつきました。
下記は、最終的に私がユーザーの声を書いた内容です。
行程表クラウドを利用中のT旅行会社の管理者Aさんは
「T旅行会社には全国に6つの支店があり、各支店ごとに『どの行程表が見積もりまで完了しているのか』などの状況を把握する必要がありました。今回のアップデートで、チームの作成・チームでの絞り込みができるようになったことで、自分の支店のメンバーの状況が把握しやすくなりました。」と話しています。
「あ、この機能のままだとユーザーの課題のすべてを解決することにはならないな」逆に、「課題の解決に対しては機能が過剰すぎる、もっと削ぎ落として早くリリースしたほうがよさそうだな」
など、ロジックが破綻してしまっている部分に、実装前に気づくことができました。
②課題やユーザーに提供したい価値について、営業や検証のメンバーと共通認識がとれて、認識齟齬がなくなった
私のプロジェクトでは、インターナルプレスリリースをプロジェクトマネージャー、デザイナー、営業、QMなどのメンバーが集まってレビューします。
異なる目線のメンバーがレビューすることで、内容がよりブラッシュアップされたり、課題の捉え方などの認識齟齬に気づけたりするメリットがあります。
ここで認識統一がされていることで、この後の仕様検討時の議論がかなりスムーズに進んだ実感があります。「課題ってこういう捉え方で合っていましたっけ？」などの確認は一度も起きませんでした。
おわりに
インターナルプレスリリースを最初に書いておくことで「最終的にユーザーが求めているものを実装できている」という安心感をもちながら、コミュニケーションコストも下げて開発をすすめることができます。
インターナルプレスリリースの執筆は、特に機能のイメージがまだ定まっていないような場合の開発時や、新規プロダクトの開発時に特に効果を発揮すると思います。
ご興味がある方は是非お試しください。
私がインターナルプレスリリースについて詳しく学んだのはこの書籍からです。よろしければご覧ください。
こちらの記事にもインターナルプレスリリースのサンプルの全文が載っています。