Offers MGRの思想も導入の決め手に！
- まずはOffers MGRを導入の目的を教えてください
2つあります。1つ目はNotionやGitHubなど、プロダクト開発に必要なツールの更新頻度などを計測をしていくためです。Pull Request数やコミュニケーション頻度など数値化して振り返っていくことはプロジェクトマネジメント上でも必須ですし、Offers MGRはその点において我々のニーズを満たしてくれると判断しました。
2つ目は、Offers MGRの思想に共感したことです。Offers MGRは「非同期コミュニケーション」かつ「ドキュメント文化」の開発組織向けに作られています。PdMやデザイナー、エンジニアの業務時間の大半はNotionやGitHub、Slack、Figma、Jiraといった各ツール上で時間を費やされている前提で設計されていて、弊社の開発組織の思想と近いものがあります。
それにOffers MGRを運営するoverflow社も非同期コミュニケーションでドキュメント文化を大切にしています。そのような思想の持ち主たちが生み出したプロダクトですので信頼感もありますね。
実際に使ってみると、権限管理がとても細かく作られているので、今後組織がどういう状態になっても利用できそうという安心感があります。Offers MGRはまだプロダクト初期フェーズですが、現時点でここまで考えきれているのは素直に尊敬してます。
スプリントの振り返りとして、Offers MGRを活用
- Offers MGRを御社ではどのように活用されているか教えてください。
主にスプリントの振り返りに利用しており、GitHubの数値を見ることが多いですね。この振り返りの留意点としては、稼働数が多かった・少なかったで評価をしないことです。あくまで目的は稼働の内容を確認することです。
例えば当初の想定よりも開発がスムーズに進んだのであれば、具体的に何が良かったのかを振り返ったりしています。issueの消化が想定より少なくなってしまった場合には、想定より少ないことがポジティブなのかネガティブなのかをチーム間で認識を揃え、もしネガティブなら、その原因と次回に向けた対策の検討などに活用しています。
- いわゆるKPT法（Keep Problem Try）として活用しているイメージですね。
そうですね。あるスプリントでは、実装するタイミングでPull Requestのレビューコメントが多く発生していました。気になって詳細に振り返りを行うと、仕様の認識がずれた上で開発が進んでしまい、要求とデザイン、仕様に対する認識の齟齬が発生していたことで、レビューコメントでのやり取りが多く発生していました。
結局その時はイシューに取り組む前のPRD（要求定義書）を要件定義のタイミングできちんと読み合わせるようにしようとか、読んだ上でどんな実装をするかの認識を関係者間で揃えるようにしました。
このようにしてプロセスを計測して振り返りを行い、不要なやりとりで工数が発生していることの認識を揃えつつ、次回の改善に役立てています。
PdMとして認知負荷が低減
- Offers MGRの機能として「ここが良かった点」はございますか？
「アラート機能」と「アウトプットログ機能」を活用しています。導入時は使わないかなと思ったのですが、最近はこの2つをよく見るようにしています。
- どのような場面で役立っているのでしょうか？
「アラート機能」は、Pull Requestが一定以上放置されている場合や、コメントのやり取りが多くなった際にアラートを出すようにしています。
具体的には、Pull Requestが出てから2週間放置した場合と、Pull Request中でコメントが10回以上やり取りがあった際にアラートを出すようにしています。これが適切な数字か分かりませんが、この機能によってGitHubをいちいち見に行く工数が減ったので助かりました。
この「アラート機能」を使い始めた背景として、Pull Requestを出した人とレビュアーのやり取りが長くなり、レビュワーの負担が増えていることに私が気づけていないケースがありました。できるだけGitHub上で発生したやりとりも確認するようにしているのですが、Pull Requestレビュー中にやりとりが発生するとコメントの方はなかなか見れていなくて。
弊社の開発体制としては、今は業務委託を含めて5人程度の規模感ですが、それでも都度GitHubを見に行くのは手間があります。今後組織が大きくなって、かつ私がPdMからPO、そして経営にシフトしていくうえで、これを検知するのは不可能になると思っていたので、この「アラート機能」はかなり助かりました。アラート機能があることで、特定のレビュワーに負担が大きくなりそうな開発体制にならないようにする配慮ができそうです。
- 「アウトプットログ機能」についていかがでしょう？
Slackのスレッドやスタンプ、Notionの起票など、自分が通知対象になっていないやり取りとかって、基本的には検知できませんよね。
それが「アウトプットログ」として可視化されるので、開発メンバー個々のアクションが一覧化されるので、メンバーのコンディション確認にも活用できます。
例えば「副業の◯◯さんは、先週に比べて稼働が低いな。今週は本業が忙しいのかな」ということもログで認識できるので、SlackやNotionなどのアウトプットログはよく見ていますね。
このあたりの機能は今後アップデートされていくことを期待しているので、ゆくゆくはOffers MGRさえ見てさえいれば、誰がどれだけ稼働していて、どんな企画をしているのかを確認ができるようになるといいですね。
- Offers MGRで確認すべきことが一元化されると、時間も削減できて開発により集中できそうですね。
そうですね。この「アラート」と「アウトプット」の各機能によって、各種ツールを見にいかないといけない認知負荷が減りました。アクション数が多いから良い、アクション数が少ないから悪いといった単純な話では無いのですが、各人の稼働の内容を確認して、分析や改善を効率的に行えるようになりました。
Offers MGRは導入した2022年10月当初から高い期待値を持って使い始めたのですが、とても満足しています。冒頭でお話した権限まわりなど、全般的によく考えられて作られていて使いやすいですね。
個人的な意見ですが、非同期コミュニケーションでドキュメント文化を作ろうとしている組織で、かつROIもしっかりと見ていきたいのであれば、Offers MGRを導入しない理由はないと思います。
Offers MGRで理想の組織へ
- 最後に、御社の理想の組織像についてお聞かせください。
組織自体をソフトウェアのようにしていきたいと考えています。ソフトウェアのすごい所は、明文化されたすべての記述を上から逐次処理して一つのサービスが動くこと。組織においても、機能別のチームが目的に合わせて連携し、効率的にプロダクトを作っていく未来を想像しています。
だからこそ、弊社ではドキュメント文化を大切にしているのですが、当然ながら人間はドキュメントに記述されてないこと以外もできるので、ソフトウェアで捉え直すのは難しいところもあります。そこは明文化されたルールと不文律などを合わせた上で、組織のソフトウェア化を推進していきたいと考えています。
そして組織が大きくなるにつれて、構造変革の必要性も出てくると思います。その際にも柔軟に実施できることが理想だと思っており、ソフトウェアのようにスケーラビリティを担保したような運営をすごく意識しています。
- 組織のソフトウェア化に向けてOffers MGRはどのように貢献できるとお考えでしょうか？
Offers MGRがある前提で組織設計を進めていく想定です。「指標を測定すること」と「指標を役立てること（開発生産性を向上させること）」は別の議論だと考えていますが、Offers MGRは前者の役割を非常に効率的に行えると認識しています。
後者に関しては自社固有の議論もありますが、Offers MGRを利用しながら改善を行っていきたいですね。
- ありがとうございました。