Platform as a Productのプロセス最適化
吉岡良治氏：これならやっていけそうだということがわかったので、次にそのプロセスを最適化していきます。
まずはPlatform as a Productという取り組み自体を仮説検証をしていきました。ミニマムに始めてうまくいきそうだという手応えを感じたので、それをより良くしていくためには何が必要かを考えます。まずは課題を見つけて、その課題を仮説として実際の改善に取り組む。
プロダクトマネジメントにおけるフィードバックループの考え方はだいたいのことに適用できるなと思っていて、そもそもの取り組み自体の改善にもこういった概念を使ってやっています。6週間ごとにやるので、基本的には半期ごとのスコープでの検証になっています。
リリースサイクルが6週間なので、半期でもだいたい回せるのは4サイクル。4サイクルぐらい回して検証できるので、いくつかの大きめなテーマを取り入れて、この改善に取り組みました。
まずはフィードバックの質を高めたいので、リリースアイテムのフォーマット改善に着手しています。今だと概要、仮説、リリース、検証の4項目を作って、それぞれに対してより詳細かつ必要な観点を記載するようにしています。また、自分たちだけでレビューをしていてもしょうがないので、チーム外から評価をもらう方法も探しています。
1つ、よくあるのがユーザーインタビューというかたちで社内のユーザーを呼んで、実際にレビューをしてもらう。その時も、実際に作成したサービスのインターフェイスに対して置き換えたプルリクエストのDiffみたいなものを作って「これぐらいシンプルになるんだけど、どう思う？」みたいなところでコードの差分を見てもらって、関係するエンジニアにレビューしてもらうようなこともやっていきました。
それともう1つはリリースサイクルに対しても、プランニングとレビューを導入しています。このプロダクトマネジメントは、最初は自分が始めたんですが、最終的にはチームで回せるようになることが重要だと思っています。
そのための第一準備としてプランニングとレビューというのを導入しました。必要な準備としては、まずは「GitHub」のIssueでフォーマットを整備します。
その上で、プランニングのレビューとプロセスをリリースサイクルに組み込んで、そのレビューをする責任者を任命します。最初はというか今もそうなんですが、マネージャーの自分が担当しています。
あとは、各チームのテックリードに、プランニング前にリリースアイテムという6週間の計画を立ててもらって、それを事前にレビューした上で、リリースサイクルが終わったらアイテムごとにレビュー、状況確認をする。定義を満たしていれば責任者が承認する。GitHub Issueで管理をしているので、Labelを付けるということをやっています。
（スライドを示して）これは情報量が少ないリリースアイテムですが、こんな感じでIssueを作って。右にLabelがあるんですが、こんな感じで承認していくプロセスを回しています。
他にもいろいろとやっていたんですが、今日は発表時間が短いので､ここでは割愛します。
使ってもらうために存在感を出す
最後に存在感を出すというところで、僕らのバリューの中に「Presence」というバリューがあります。開発した機能を評価してもらうためには、能動的な成果の共有を大切にする必要があります。その評価から学びを得て次の開発に活かすということが、このバリューのことなんですけど。
やはりただ単に開発しただけだと使ってもらえないんですね。
使ってもらえないと、結局のところはフィードバックが得られない。やはり使ってもらうためには自分たちのほうから能動的にアピールすることがすごく大事なので、ここが自分たちのバリューにも含まれています。いくつか社内で取り組んでいるものがあるので、ここでも軽く紹介しようと思います。
1つは、これはみなさんもやっているかもしれませんが、社内向けのリリースノートです。隔週でAll-Hands Meetingをやっているんですが、そこで完成したリリースアイテムに対してIssueにリリースノートをまとめて、社内のチャンネルで共有するということをやっています。
もう1つはプロダクトチャンネルです。関係者を集めてやり取りをするチャンネルなんですが、例えばDarklaunch v2ブログを見てもらえばいろいろと詳細とかが載っています。Darklaunch v2というプラットフォームを作っていたんですが、#darklaunch-dev-jaというチャンネルを作って、ここでいろいろとやり取りをしています。
そこには要望リストがあったり、気軽にチームに対してメンションしてもらえば反応するようなかたちになっているので、そこでやり取りを行っています。
（スライドを示して）また、部内キックオフみたいなところでも、主にチームごとのロードマップ計画とか進捗、グループの戦略・戦術などもこまめに共有していて、右のような資料を作って説明していたりします。
あとはブログですね。ブログは主に社外向けにやっているものだと思いますが、実はこれも弊社では立派なアピールツールになっていて。弊社ではブログ記事を書くと、別の領域の関係者がレビューをしてくれるんですね。
なので、プラットフォームの記事を書くだけで、それをレビューした人に知ってもらえるので、それもある種の社内の宣伝にもなったりします。
つまるところ、結局は作るだけじゃなくて、やはり認知してもらうということがフィードバックにはすごく重要なんじゃないかなと自分は思っています。結局自分たちの目的はプラットフォームを利用してもらってフィードバックを得ることなんですよ。
でも、知ってもらわなければその便利な機能も使ってもらえないので、結局フィードバックは得られない。なので、とにかく自分たちから能動的にアプローチをしていって、社内にPresenceを出すことが非常に重要なことなんじゃないかなと今でも思っています。
使ってもらうために存在感を出す
まとめです。自分たちがなぜここにいるのかをちゃんと言語化しよう。基盤をプロダクトとして捉えて、プロダクトマネジメントの手法を活用する。どのような改善もフィードバックループというものを素早く回すことがやはり大事だというところと、フィードバックを得るには能動的に成果を共有して、ちゃんと認知してもらおうねという話になりました。
以上になります。ご清聴ありがとうございました。
