介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー、酒井(@_atsushisakai)です。
前回は、カイポケのフルリニューアルプロジェクトの紹介をさせてもらいましたが 、今回はローンチから17年も経過したカイポケのような大規模 SaaS プロダクトをフルリニューアルする、という大きなゴールを目指すプロジェクトに立ち向かうために、どのようなプロセスとマインドで開発を進めているのかをご紹介させていただきます。
フルリニューアルプロジェクトの特徴
まず前提として、このフルリニューアルプロジェクトは、いくつかの観点で、プロジェクトの進行難易度を高めるような特徴がいくつかあります。
作るべき「価値」が膨大に存在することが最初からわかっている
このプロジェクトでは、すでに現在動いているカイポケの重要なお客様にとっての「価値」を大きく損なわないように開発を進めていかねばなりません。これは、機能的な互換性を保つ、ということではなく、あくまで「価値」にフォーカスした話です。そして、その価値はローンチから17年間も積み重ねてきた結果、非常に膨大な分量になっています。
ただし、すべてのお客様にご満足いただけるような機能一式をいきなりすべて作り上げてビッグバンリリースするわけにもいきません。フィードバックを得ながらも戦略的に小さく価値を積み上げ、結果的に現在動いているカイポケが提供している価値以上のものへと、プロダクトを超高速に育てていくことがどうすれば可能なのか、ということを常に模索していく必要があります。
関わるメンバーやチーム数が最初から多い
上記の通り、作るべき価値が膨大であることは最初からわかっているため、関わるメンバーもそれなりに大人数となっています。少数精鋭で密なコミュニケーションを取りながら、小さく小さく…、という作り方ではなく、ドメイン分析を行い、最初から複数のチームで責務分割しながらたくさんの価値を並行で生み出していけるような開発プロセスが必要です。
介護保険制度や介護事業所の業務への深い理解が必要不可欠
例えば、先日の宮坂さんの記事で書かれているように複雑な介護保険制度への理解が必要不可欠であったり、法改正についての情報のキャッチアップも必要です。また、介護事業所における細かな業務を再度理解し直すことも重視しています。これらの複雑度の高い情報を扱いながら、抽象度高く戦略的・長期的にプロダクトがユーザーの課題を解決し続けていくことを狙えるプロセスを見つけていくことは非常に難易度が高いものです。
プロダクトマネジメント体制
さて、上記でご紹介したようにこのフルリニューアルプロジェクトは、意識せずにやっているとコミュニケーションコストが高く、解くべき課題が膨大かつ超高難度、という非常に難しい特徴があります。このような状況に対応するために、常に開発組織全体がさまざまな観点の解像度を高く維持することができるよう、プロダクトマネジメントに関わる各種ロールが設計されていますのでご紹介します。
プロダクトマネージャー
プロダクトマネージャーは、新しいカイポケにおける複数のアプリケーションを束ねた SaaS 全体の視点から顧客価値をスケールさせ、事業価値へつなげていくためのビジョンや戦略の立案を行います。ユーザーストーリーマッピングを元に、プロダクト全体の長期ロードマップとスコープ管理を横断的に行っていきます。
プロダクトオーナー
プロダクトオーナーは、カイポケ内にドメインごとに設計された複数のフロントエンドアプリケーションやバックエンドサービスのそれぞれについて、プロダクトビジョンを作り、プロダクトバックログアイテムの優先順位を管理していくことに責任を持ちます。プロダクトオーナーに紐づく形で開発者やQA、デザイナーなどのクロスファンクショナルなスクラムチームが組成されています。
ドメインエキスパート
ドメインエキスパートは、プロダクト開発組織に対して、複雑な介護保険制度や介護事業所内の業務プロセスの専門知識を提供し、プロダクトの成長に貢献します。過去の経歴において、実際に介護事業所での勤務を経験しているため、開発する対象への深い理解と意味づけをしてくれる重要な存在です。
このような体制を敷くことで、プロジェクトの全体像を組織全体で捉えながら、スクラムチームで足元の仮説検証を繰り返し、ユーザーや業務・制度の理解を深めていくことで提供価値に向き合えるように体制設計されています。
プロダクトバックログアイテムができるまで
それでは次に、各スクラムチームがプロダクトバックログアイテムの優先順位を確定し、チームのスプリントで着手可能なタスクにどのように分解されていくのかを解説します。
まずは、プロダクトマネージャーとプロダクトオーナーが協力して将来2〜3ヶ月分で創出したい価値を「エピック」と、それに紐づく「プロダクトバックログアイテム」という粒度でざっくりとリストアップします。エピックは、プロジェクト開始時に作成された巨大なユーザーストーリーマッピングが元になっています。
その後、ここで作成されたプロダクトバックログアイテムを各チームのエンジニアがレビューし、背景や要件を理解しながら、さらに細かなプロダクトバックログアイテムの分割を行っていきます。ある程度プロダクトバックログアイテムの粒度を整理し、チーム間の依存関係なども理解しあった段階で、開発の規模感を見積もるためにストーリーポイントを用いた「ざっくり見積もり」（組織内では本当にこう呼ばれています）を行います。その後、見積もりを材料に、スコープと優先順位を再度プロダクトマネージャー/プロダクトオーナー/エンジニアで話し合いながら、向こう2〜3ヶ月で取り組む開発内容を確定させていきます。
既にドキュメントやUIのドラフトとなる資料が Figma などにある場合は、その上にでコメントし合ったり、プロダクトオーナーとエンジニアやデザイナーが直接ディスカッションしたり、ドメインエキスパートにヒアリングして介護事業所で行われている業務を把握したりしながら、開発対象の理解を深めていきます。正直、果てしなく地道な作業でとても大変なのですが、ここでの対話はその後の開発対象への理解を深めるための非常に重要なプロセスとなっています。
フロントエンドチームでのスクラム
さて、ここからは私が所属しているフロントエンドチームのスクラム開発の様子を解説します。まず、すでに作成されたプロダクトバックログアイテムに情報を加えながら、 チームで管理している JIRA プロジェクトに全てのプロダクトバックログアイテムを改めて登録していきます。ある程度事前に見積もりもされているので、それをそのままストーリーポイントとして入力していきます。
プロダクトバックログアイテムは、最終的に以下のようなフォーマットに整理して登録を行っていきます。
このフォーマットは、非常にシンプルに記載できますし、主にユーザーに提供する価値にフォーカスしているため、個人的に非常に気に入っています。例えば、How をプロダクトバックログアイテムに記載しすぎると、見積もりの正確性を求めすぎてしまったり、相対的に Why への意識が目減りしてしまったりするので、このぐらいの内容でざっくり書いておくと開発チームが自律的に思考できるようになる、という良い影響を感じた経験があります。
バックログが完成すると、バックログリファインメントで着手していくための戦略をリードエンジニアが中心となって立てていきます。リードエンジニアは事前に関連するバックエンドエンジニアとのコミュニケーションを取っており、その情報と合わせて最短経路で上位のプロダクトバックログアイテムやエピックを実現するための手順を考えながら、スプリントにおける優先順位の調整や必要であればさらにプロダクトバックログアイテムの分割、再見積もりなどをリードしていきます。そして、毎週の「バックログリファインメント」の時間では、精度が上がり、開発対象への理解が深まったプロダクトバックログアイテムがスクラムチーム内で再度共有されることになります。スプリントが終了する頃には、次のスプリントで着手するスプリントバックログが完成されており、スプリントプランニングでは、計測されたベロシティをもとに、見積もり済みのプロダクトバックログアイテムを使ってコミットラインを決めていきます。
最終的に、このスプリントで達成したいとチームで決めたことを1文で表したスプリントゴールを決めることにしています。スプリントゴールを決める目的は、チーム内で以下のように定義しています。
- チームとして期間中に達成したいことを一言で表現することで認識を揃える
- このゴールを達成するために障害となることを積極的に取り除いていくように意識を働かせる
スプリントの途中でも、時々ゴールを見直して、本当にゴールに向かえているかをデイリースタンドアップミーティングの中で確認しあって、集中できているかを確認したりします。
そのほか、スプリントレビューやレトロスペクティブ、スプリントプランニングなど、各種イベントをスクラムガイドの通りにしっかりと行っています。経験を大事にして、チームが成長する過程で出てきた、チームに最適化されたローカルルールもいくつかで始めており、イテレーションの回数が増えて行くほど効率化したり、チャレンジしたりできているのも実感しています。
まとめ
ここまで述べてきたように、私たちは、カイポケという非常に大きな SaaS プロダクトをフルリニューアルするという非常にチャレンジングな開発に取り組んでいます。この記事では、難易度の高いプロダクトをどのようにマネジメントし、日々の仕事に落とし込んでいるかというプロセスを紹介してきました。この記事を書いてみて感じたのですが、我々が今取り組んでいることは、複雑さや難易度の高さを正面から受けとめ、現実的な落とし所を見つけていく作業の繰り返しというのが正直なところです。驚くような効率的なプロセスではないですが、地道に向き合いながら、スクラムのプラクティスを取り入れて実直に経験を積み重ねるように開発を進めています。フルリニューアルプロジェクトは、まだまだ不確実性が高い状態なので安定した開発プロセス、というのとはほど遠いものですがチャレンジングであるがゆえの面白さも日々感じています。
経験主義で技術もチームワークも学習することを大事にしながらプロダクトと共にチーム全体が成長している実感を味わえる非常にスリリングでわくわくするプロジェクトだと思います。興味のある人はぜひより詳しい話を聴きにきませんか？
