POとしてスクラムをやってみた備忘録

半年ほど前から「JapanTaxi」アプリのひとチームで、スクラムを取り入れてプロダクト改善を進めています。プロダクトオーナー観点（に限られませんが）でどんなことを感じてきたか、どのような試行錯誤を辿ってきたか、備忘録として書いておこうと思います。すでに忘れていることが色々ありそうです。あとすみません文字だけです。

かつて直面した問題

スクラムへの理解

別プロダクトで実施しているチームはあったものの、アプリチームはこれまでプロジェクト制*がメインだったため、メンバーごとにスクラムの理解度にばらつきがありました。書籍や研修をベースにドキュメント化し、スクラム勉強会を実施しました（会ごとに概要/チーム/イベント/成果物に分けて説明）。あとはやはりシンプルなフレームワークなので、プロセスを回す中で徐々に慣れてきたところもあります。

• アプリ開発体制の変遷は田中GMが書いてくれてました！
• 「JapanTaxi」アプリ開発体制の変遷（2019 Winter）

スクラムマスターとプロダクトオーナーを並行でどっちもやってみた

一時期スクラムマスターとしても並行して活動しましたが、各書籍にも書いてあるように完全にアンチパターンでした。

• 技術的な相談、判断ができない（これは自分のせいだけど）
• 見積もりの妥当さがわからない（これも自分のせいだけど）
• チームのROIを上げる活動と、チームのプロセス改善の活動は両立できない（本質的に）

ベロシティの安定性

最初の方はあまり安定しなかったのを思い出しました。

周期性が見えたので過去数スプリントの平均値を取って次スプリントのベロシティを予測したり、そもそもの対応としてアイテムを細かく分割したり、段々と安定してきました。

今も試行錯誤していること

ROI思考

プロダクトオーナーとして、いかにROIドリブンで考えるか/いかにROIを高めるかを考えることは必須だと言われています。

中には横並びにして比較しづらいものもあったり、Returnにも時間軸の観点があって短期だとこっちだけど長期だとこちらみたいなトレードオフがあったりで難しいと思う部分は多いのですが、最終的に責任は自分にあるので様々な方面から意見をもらいつつ納得できるまでは考えるようにしています。

仕様検討

「JapanTaxi」アプリは細かいパターン分岐が結構複雑で、実装着手してみないと気づかないという点がわりとあります。従って、仕様確定までのリードタイムが結構ボトルネックになります。

どこまでをPOがやりどこからチームでやるかの役割分担や、どうやってやるかについて試行錯誤を重ねてきました（チームメンバーを集めて要件を説明して検討漏れをフィードバックをもらう形式にしたり、施策シートに要件書いてコメントしてもらったり。。。）。

いまハマりそうなのは、WHYとWHAT(粗々)をPO側が提示しつつ、スクラムチームでWHATの詳細化とHOWを決めていくプロセス（このタスクをチームにはリファインメントとして扱ってもらう）。

これまでPO/デザイナーが描いたものがそのまま実装できるわけではなかったりで手戻りしているケースもありましたが、WHATの詳細化からエンジニア観点を入れることで、実現できるものが明確化されて手戻りが減りそうな感触です。

実装に当てられる時間的なリソースは減りますが、検討漏れによる手戻りを考えるとむしろ効率は良さそうなので、しばらくトライしてみます。

ユーザーに向き合う時間

社内と向き合う時間と同等、もしくはそれ以上に重要ではあるものの、他の案件があったりと、気づいたら一番削られがちな部分ですね。。

ユーザーインタビューはなるべく足を運ぶようにしたりとしていましたが限界はあるので、たとえばPMとPMMに分業するとかを近いうちに検討したいなと思ったりしています。

見積り

プラットフォームがiOS/Android/Serverと３つがある中で、基準となるタスクをどうするか、見積の精度はどうなのか、みたいな話しは定期的にちょこちょこ課題にあがります。

POとしてもいつまでに何ができそうかを把握するバロメーターになるので、この辺りは引き続いての課題です。

(たぶん)良くなっていること

チーム/組織としてのラーニング

これまではプロジェクト制で、チーム/組織としてのラーニングは貯まりにくかったように思っています。

もちろんプロジェクト単位で振り返りはあったものの、そこで得た個人のラーニングを別のプロジェクトで還元できていたかというとそういうわけでもなかったりしました（プロジェクトによって状況やメンバーがかなり異なったりするので横展開が難しかったりする）。

スクラムは毎週レトロスペクティブ（振り返り）があるので、チームごととして課題の把握と解決策の案出し、TRYによるサイクルが回るので、チーム/個々人にもラーニングが浸透している感覚があります。

横断的な情報連携体制

かつてはQAやカスタマーサポート、データ分析チームが開発プロセスの最後（というか外）に待ち受けていましたが、機能横断なスクラムの原理原則のもとで各部門の担当がアサインされ、特に情報共有の負担がだいぶ軽減されています。それまではこの共有コストが結構しんどかったです。。

ここも一気に解消された、というより、スプリントを回していく中で外に出ている機能に関わる部分が課題として上げられ、段階的に解消していった形です。

個人

毎週のレトロスペクティブで自身の活動の課題振り返りや、チームメンバーが感じる自分の活動に対する課題指摘をもらう中で成長させてもらっています。

正直言い訳をしたくなることもありますが、人格そのものへの指摘ではなく、活動への指摘と捉える（変換する）こと。チームにこの共通認識が前提にないと辛いだけだと思います。

直近ではLarge-Scale Scrumのフレームワークを取り入れて開発を進めていきます。

また色々な課題が出てくると思いますが、それを乗り越えることでチームとしてより良いプロダクトを社会に還元できることを楽しみに頑張ります。この文脈でふと下記を思い出したので引用します。取り組みの初期は心の拠りどころにしていました。

スクラムが決めていることをチームがうまく回せないときは、その事実を認識することが大事だ。チームができることから始めていくようにしなければ、強いストレスが蔓延し、まともなプロダクトは一向にできあがらないだろう。チームができることに取り組んでいるうちは、スクラムと言えないかもしれない。ただそのことを問題視することよりも、チームが段階的にスクラムに近づいていくことの方がよほど尊い。『正しいものを正しくつくる』より引用

とりとめもない文章ですみません。最後に、JapanTaxiでは各職種で積極的な採用を行っています！ご興味ある方はぜひ下記リンクをチェックしてみてください。

Mobility Technologies では共に日本のモビリティを進化させていくプロダクトマネージャー・プロジェクトマネージャーを募集しています。話を聞いてみたいという方は、是非 募集ページ からご相談ください！