株式会社プラハは2022年、株式会社アガルートによるM&Aで子会社となりました。
この変化の一環として、アガルート社長自らがプロダクトオーナーのひとりとして参加する新規プロダクト開発が始まりました。プロダクトの開発はプラハの私たちが担当し、私も「開発チームのリーダー」としてそのチームに加わることになりました。
私はこれまで開発メンバーとしての経験しかありませんでしたが、エクストリームプログラミングとかレガシーコードからの脱却とかめっちゃ好きで、本で学んだプラクティスをリーダーとして実践できる機会が与えられて最高にハッピーでした。しかも、プロダクトオーナーの一人として参加するアガルート社長はこれまで伝統的な開発手法しか経験したことがないとのことで、新たな開発の進め方を経験してもらう絶好の機会でもありました。
やったこと
「欲しい機能一覧」を受け取ったが、いったん白紙に戻した
プロジェクトが始まる際、プロダクトオーナーから「欲しい機能一覧」を受け取りました。この一覧は有用な情報源として受け止めつつも「顧客が本当に必要だったもの」を作るためには、このリストをそのまま実装すべきではないと考えました。
そこで、プロダクトオーナー、開発チーム（開発者とデザイナー）全員でキックオフミーティングを開催しました。この会議では、次の内容について話しました。
- なぜこのプロジェクトが始まったのか、という情報の共有
- 解決したい問題、もしくは誰にどのような価値を提供したいか、という情報の共有
- プロダクト開発の進め方として、すべての機能を一度に実装してからリリースするというやりかたは危険であるという認識の共有
- 開発した機能が本当に必要なものだったかどうかは、ユーザーからのフィードバックがくるまでわからない
- 計画が巨大であればあるほど見積もりの精度は悪くなり、計画通りに進まないことが多い
- 上記を踏まえたうえで、どのような機能をどういうやりかたで開発していくべきか、全員で議論した
プロダクトオーナー、エンジニア、デザイナーがそれぞれの経験に基づき意見を交換することができました。
そして、「成果を検証できる必要最小限の機能を備えたプロダクト」を最初にリリースし、その後機能開発を繰り返すという方針が決まりました。
「毎週必ず成果を見せる」開発を行った
開発を順調に進めるためには、機能開発だけでなく、定期的なリファクタリングや環境の整備が必要です。しかし、非エンジニアであるプロダクトオーナーから見ると、実際に機能開発が進んでいるかの確認ができない状態で開発チームがリファクタリングや環境整備に時間を割くことは不安なのではないかと考えました。そこで、プロダクトオーナーと開発チームとの間で信頼関係を築くことを目標に、新たに実装された機能や改善点を毎週プロダクトオーナーにデモンストレーションすることで、進捗を具体的に示すことにしました。
この定期的なデモンストレーションは、プロダクトオーナーに安心感を与えるだけでなく、開発チームにとっても非常に有益でした。毎週「今週末にこの機能をデモする」という具体的な目標を設定することで、チーム全員が明確な方向性を持って効率的に作業を進めることができました。さらに、社長は 「このように迅速かつ柔軟に開発が進められるなら、いまとは違う事業のやり方も考えられる」という新たな気づきを得ることができたということでした。大きな成果！
CI/CDなどの仕組みづくりは最初から力いっぱいやった
開発プロセスの初期段階から、CI/CDやその他の環境整備に力を入れることで、コードの品質を担保し、開発効率を向上させました。毎週の成果発表を通じてプロダクトオーナーからの信頼を確立する一方で、定期的なリファクタリングと環境の整備も平行して行いました。
実施した環境整備は多岐にわたります。
- 自動テストの整備
- DockerでDBを用意してクエリを実行するテスト
- Storybookを使ったUIのテスト
- Playwrightを使ったE2Eテスト
- 自動デプロイの整備
- 任意のブランチをチェックアウトしてビルド→デプロイするGitHub Workflow
- develop/staging/mainブランチへのマージ時に自動でビルド→デプロイするGitHub Workflow
- Turborepoを使ったモノレポの管理、ビルドや開発の効率化
- インフラのコード化
- Figmaからデザイントークン（json）を生成→Reactで利用するための仕組み
- renovateを使った依存パッケージの自動更新
- アプリケーションの監視 → エラー・アラートをSlackに通知する仕組み
これらの仕組みのいくつかは他のプロダクトから流用したり、社内ライブラリとして実装して利用しているものもあります。これらの詳細はそれだけで一連の記事になり得るため、別途詳述する予定です。いくつかすでに記事になっています。
行動分析ツールを導入した
迅速で柔軟な開発が実現したところで、ユーザーへの価値提供ができていなければ（できていることが確認できなければ）意味がありません。 ユーザーが想定通りにアプリケーションを操作しているか、どの点で躓いているかを把握するために、行動分析ツールを導入しました。
具体的には、セッションリプレイ機能を備えたPostHogを採用しました。プラハ社内の別チームのメンバーに教えてもらってはじめて知ったサービスだったのですが、セッションリプレイだけでなく各種分析機能やFeature Flagなどの機能も備えており、非常に使い勝手が良いと絶賛だったため、採用しました。
実際使ってみて、評判通りの使い勝手の良さでした。機能が多くまだ使いこなせてない部分もあるため、引き続き機能を活用していきたいと考えています。
git-flowをやめた
実装と社内レビューを繰り返し、無事に初回リリースを迎えることができました。
当初の予定通り初回リリース後も継続的に機能開発を続け、さらに開発環境の改善も繰り返してきました。開発効率が向上することでプロダクトオーナーからの要望にも多く応えられるようになり、開発プロセスの中に新たなボトルネックを見つけることができました。
当初のプロジェクトではgitのブランチ戦略としてgit-flowの方法を採用していたのですが、変更を「developブランチ → stagingブランチ → mainブランチ」に順にマージしていくプロセスが、新たな要望や優先順位の変更に柔軟に対応するのを難しくしていました。「作ってる途中のものをいったん置いておく」をしようとすると長寿ブランチが生まれてコンフリクト解消が困難になったり、バグ発生時のホットフィックスが発生すると煩雑なブランチ運用が必要になったり、さまざまな問題が見えてきました。
この問題に対処するため、PostHogのFeature Flag機能を活用しました。mainブランチから生やしたブランチをdevelop/stagingブランチを経由せずにmainに混ぜる（Feature Flagで機能は隠している）→機能をリリースするタイミングでFeature Flagを操作して機能を可視化する、という運用です。develop/stagingブランチが不要になったことで開発プロセスがより柔軟になり、緊急の依頼や開発の優先順位の変更にも迅速に対応できるようになりました。
私はLeanとDevOpsの科学を読んでトランクベース開発について知りましたが、最初は非現実的なアイデアにしか思えませんでした。しかしFeature Flagを運用することでトランクベース開発が可能になることに気づくことができ、しかもすぐ現場で実践できて超ハッピーでした。
とはいえ、このやりかたはあらゆるプロジェクトに適用できるわけではないこともわかりました。前述した通りこのプロジェクトではCI/CD全力投球 & アプリケーションの監視・通知をしっかりやっていたため大きな問題はまだ起こっていませんが、これらの仕組みがないプロジェクトでは本番で事故を起こすリスクは従来のやり方と比べて高くなると思います。
なぜうまくいったか
かくして「ぼくがかんがえたさいきょうのプロジェクトマネジメント」を実践できて、いろいろな成果を上げることができたわけですが、これは奇跡的な好条件がいくつも重なった結果であると言わざるを得ません。
メンバーに恵まれすぎていた
チームのエンジニアはフロントエンドとかバックエンドとかインフラとか領域問わず対応できるメンバーで構成されており、スキル的な面の問題がまったく発生しませんでした。領域ごとに多少の得意/不得意はありますが、コミュニケーション能力も申し分ないため、必要に応じて協力して動ける環境が整っていました。「来週はこのデモを見せよう」と決めると、技術選定から設計・実装、テスト、プレビュー環境へのデプロイがあれよあれよと進んでいきます。
こういうメンバーが揃うのは本当に奇跡的なことだと思います。日々、XやZennでよさそうな人探しをがんばっていますがまだまだ人足りないので、引き続き採用活動もがんばります。
社長はじめプロダクトオーナー全員が毎週の成果発表会に参加してくれた & Slackも基本即レス
社長が意思決定の場にいてくれるということは、あとでその決定がひっくり返ることはない、ということです。こんな安心感はありません。また、全員が毎週同じ場に揃って雑談も交えながら議論できているため、単純に仲が良くなります。「社長だから」とか「エンジニアは何言ってるかわからない」みたいなことはなく、フラットな立場で意見を交わすことができています。
毎週の成果発表会だけでなくSlackでもさまざまやりとりをしていますが、プロダクトオーナーは基本即レスです。「返信待ち」とか「関係者の会議の調整」が必要なく、スムーズに話が進みます。
おまけ
実際こういうやり方で開発してみてどうだったか？これからどうしていきたいか？を社長にインタビューしてみました。
Discussion