基盤開発中に起きた「認知負荷の増大」と「スプリントレビューの形骸化」　“やりたかった開発”を進めるための、それぞれの対策

吉岡氏の自己紹介

吉岡良治氏：では「プロダクトプラットフォーム開発におけるフィードバックサイクルの回し方」で、リクルートの吉岡から発表をします。あらためまして、みなさんこんばんは。吉岡良治と申します。リクルートの「スタディサプリ」というサービスで、基盤開発グループのエンジニアリングマネージャーをやっています。

経歴としては、もともとRailsエンジニアでWeb開発をしていた時期が一番長くて、最近はGoやRustを推していますが、EMになってからはほぼ業務で書いていないです。

ヘアドネーションのために2021年から髪を伸ばしていて、かなり長いんですが、まだちょっと長さが足りずに、あと1年ぐらいは伸ばす必要があるかなといったところで、がんばって伸ばしています。

「スタディサプリ」について

スタディサプリについて簡単に説明すると、スタディサプリは学びたいすべての人に対してオンラインで学べる学習サービスを提供しています。

その中で、小学生から受験生、一応大人までの学習をしたい人に向けて提供しているBtoCの「スタディサプリ」というサービスと、それ以外にも学校の先生向けに提供している「スタディサプリ for TEACHERS」。または英語の学び直しとか、TOEIC対策で勉強したい人向けに、英語にスコープを絞ったアプリケーションとして「スタディサプリ ENGLISH」などのプロダクトも提供しています。

私が関係しているのは学生向けのスタディサプリと、先生向けに提供しているスタディサプリ for TEACHERS。この2つに対して基盤開発を行っているグループに所属しています。

今日話すことですが、基盤開発におけるフィードバックループをどのように実現したかということを、実際に私たちに起きた課題と、それをどのように解決したかの実例を交えながら説明していきたいなと思っています。

これはあとで資料を見る人用の3行サマリーです。

（スライドを示して）こちらはアジェンダになります。

「スタディサプリ」における2つの基盤

最初に「スタディサプリの基盤開発が何なのか」から説明したいと思います。「スタディサプリ」にはプラットフォームと呼ばれている基盤が2種類あります。これは社内用語ですが、社内ではアプリケーションプラットフォーム、もう1つをプロダクトプラットフォームと呼んでいます。

いわゆるアプリケーションプラットフォームと言われているのは、SREが提供してくれているような、いわゆるアプリケーションを開発するための基盤になっていて、プロダクトプラットフォームは共通基盤と言われているようなものを、社内ではプロダクトプラットフォームとして呼んでいます。私が関係しているのはプロダクトプラットフォームのほうになります。

このプロダクトプラットフォームがない世界ってどんな世界だったかというと、いわゆる分断されたモノリスのようなRailsアプリケーションが点在していて、例えば認証みたいな機能がそれぞれのRailsアプリに実装されているような状況でした。

そうなってくると、スライドに書かれているようなさまざまな問題が起きているので、これをどうにかしたいというのが始まりです。

（スライドを示して）プラットフォームがある世界はこのようなかたちになっていて、いわゆる認証や、動画基盤がマイクロサービスとして切り出されて、そこに必要な処理が集約されているような状況です。こうすることで、もともとプロダクトプラットフォームがなかった世界の課題を解決しようと目論んでいるところです。

そんな世界はまだ目指している途中で、道半ばなのでこれからもやっていきたいなと思っています。

基盤開発中に起きた課題1　認知負荷の増大

その基盤開発を実際にやっていた時に発生した課題がいくつかあります。その中で特に大きな2つの課題について説明すると、1つが認知負荷の増大。もう1つがスプリントレビューの形骸化になります。

順に説明していきます。認知負荷の増大で何が起きたかというと、もともと基盤開発グループというのは、機能開発で初めての横断領域の開発をするチームだったんですね。

複数のサービスがあって、そこから同時に参照されるモジュールは、どこがオーナーシップを持つか非常に曖昧になっています。そこに（フィットする）横断領域を見るチームが生まれてしまうと、良い感じにオーナーシップを持ってしまうことになるんですね。

そうなってくると、事業的にすごく優先度の高い横断的な課題、横断的なプロジェクトがあると「このチームで持てませんか？」というかたちで、けっこう差し込みがくるんですね。

そういったところにすごく課題感があるんだとわかったので、当時のこのチームは「開発支援グループ」という名前で新たな組織を作り、領域横断的な課題を解決するグループとして、4名のプロダクトプラットフォームエンジニアが所属することになりました。

とはいえ、この4名のチームだけで横断領域にまたがる複数のすごい課題を同時に進めるのは、非常に大変なことでした。

例えばバックログの優先順位付け。これ（開発支援グループ）はワンチームなんですが、バックログの優先順位付けをする時も、どこのドメインから割り振ればいいのか。「こっちから来た差し込みはどこの優先度にすればいいのか」ということ（を考えるの）がすごく大変だったりします。

持っているドメインが多いということは、そのドメインにつながるアラートだったり、他チームからの質問、差し込みだったりにも対応しなければいけなくなります。そういったことが続くと、メンバーが開発の中でコンテキストスイッチが多発する状況になってくるんですね。

そうなってくると、本来やりたかった基盤開発のプロジェクトが一時的に停止せざるを得ないし、「落ち着いてきたから今度再開しようか」といっても当時の記憶が曖昧だったりして……。また始めてみるもしばらく経つとまた差し込みが、みたいな。そういうループに陥っていました。

基盤開発中に起きた課題2　スプリントレビューの形骸化

もう1つ、スプリントレビューの形骸化です。当時の開発プロセスは『スクラムガイド』にほぼ準拠したスクラムらしきもの。“らしきもの”と言っているのは、専任のプロダクトオーナーがいなかったり、専任のスクラムマスターもいなかったりの状態でやっていたので。

エンジニアが4名集まったチームで『スクラムガイド』をきっちり読み込んで、専任のプロダクトオーナーやマスターがいないけど、そこをなんとか自分たちで兼務しつつ『スクラムガイド』どおりで、みたいなかたちでスクラムを回していました。

また、やっている開発の目標というのも、当時の認証ドメインであれば、認証のモジュールとかはAs-Isのまま機能をマイクロサービスへ切り出すことだったので、特に新しい機能とかは実装しないし、整合性を担保したままそマイクロサービスへデータを移行するというところが当初の目標でした。

そういった開発になってくると、プロダクトバックログがすごく技術中心な内容になってしまいます。組織の中にテクニカルプロダクトマネージャーと呼ばれる方たちはいましたが、ビジネス寄りな背景を持っている方が多くて、そうなると技術中心のバックログ管理は非常に難易度が高いです。

また、インクリメント、成果物もすごく技術的な内容が中心になってしまうので、これを組織でレビューできる人、もしくはレビューをしていこうという意思を持てる人が、当時の組織にはほぼいなかったという状況になります。

その結果、関係者を集めてみてレビューを実施したりもしましたが、結局進捗確認の場にしかならなくて、スプリントレビューで求めているフィードバックループが回らない状況だったし、そもそも自分たちも「これをやっていてどんなフィードバックがほしいのか」ということがちゃんと把握できていなかった状態だったと思います。

そんな中で開発を進めていくと考慮漏れみたいなものも出てくるし、「これはたぶんドメインに詳しい人にきちんと見てもらっていたら気づけたな」という問題もすごく多く発生しているような状況でした。

認知負荷の増大への対策「ドメイン境界を定める」

こういった問題を解決しなければいけないので、チームは考えたわけです。まず1つ目の認知負荷の増大に対してやったこととしては、ドメイン境界を定めるというものです。

まず開発支援グループは、その時いたメンバーに「そもそも自分たちはなぜここにいるんだっけ？」ということを問いました。グループワークを行って、いわゆるグループのVision/Mission/Valuesを作成します。

Visionはプロダクトチーム、いわゆる機能開発をしているチームですね。機能開発をしているチームが価値の提供に集中できる世界の実現。先ほどの発表にあったコアドメインに集中するというところです。

だから似たようなビジョンになっていて、そのビジョンを実現するためのミッションとして、プロダクト開発を支援する堅牢なプロダクトプラットフォームを作る。「これが自分たちがここにいる理由だ」ということをあらためて定義しました。

それを定義すると「自分たちがやるべきことって、横断領域の課題をすべて解決することじゃないよな」ということが見えてきます。自分たちは4名のチームしかいないので、4名のエンジニアでできることって、当然限られている。なので、自分たちが4名で何をなすべきかは、選択と集中をしなければいけません。

なので、もし新しい差し込み、新しいプロジェクトが流れてきたら、その意思決定をする際に、自分たちで決めたこのMission/Visionに立ち戻って、そこに貢献するものなのか、それともまたちょっと違う話なのかをきちんと判断した上で、もし異なるのであればきちんと「No」と言う。

ただ、「No」と言って拒絶するだけじゃなくて、ちゃんと別の解決策を一緒に考えることが必要だと思います。

あともう1つは、自分たちのミッションを表す組織名に名前を変更しました。「開発支援グループ」と言われると、「幅広い横断領域の開発に対して支援してくれるグループなんだな」と（思われてしまうと）いうところで、さまざまな差し込みが来ていました。

だけど、そこを「小中高プロダクト基盤開発グループ」は「プロダクトプラットフォームを作る開発グループなんだ」というところであらためて定義しました。

名前から受ける印象ってすごく大事だなと思っていて、名前を変えたことによる影響はチーム内外でかなり大きかったと実感しています。

このことはチーム内で決めて終わりではなくて、きちんと自分たちが何をしているグループなのかを社内にアピールしていく必要があります。キックオフだったり、勉強会だったり、そういったところで何度も繰り返し能動的に「自分たちはこういうチームなんだよ」というPresenceを出しています。

これは過剰なぐらいでちょうど良いと思っていて。少ないと認知されないかなと思っています。最初は半期ごとぐらいアナウンスをしていましたが、それだと認知されなくて、「そうだったんだ」という話をけっこう聞くので、もう本当に頻繁に繰り返しやっていくことが大事だなと今でも思っています。

それでも認知負荷が高い状態が続いた

ただ、それでも高い認知負荷が続いていて。新規で増えるドメインやコンテキストは防ぎましたが、すでにある既存の複数のコンテキストは、やはりハンドリングするのが難しい状態です。なので、スプリングプランニングにもすごく時間がかかっているし、そこは何とかして解決しなければいけない課題でした。

解決する方法は一応見えていて、結局のところチームの認知負荷を下げるには、1つのチームが1つのドメインに集中できる環境を作るのが大事なんですね。そうすると、差し込みとか並行作業におけるコンテキストスイッチは最小化していくので、それが理想なんですが、当時は4名しかいなくて。

その中でいくつもドメインがある状態で分割すると、2チームに分割しても2名体制のチームになってしまって、チームとして非常に脆い体制だなと思っていました。

ですが、そこで思い切ってドメインチームを立ち上げます。1チーム2名の体制を構築しました。やはりまず試すことによってフィードバックを得るということを最優先にしました。結局自分たちで考えているだけだと何も決まらないというか、何もわからなくて、実際にやってみることしかフィードバックは得られないので。

もちろんリスクはあるのでダメだったら戻すし、採用もがんばる。メンバーとの期待値調整も事前にちゃんとやるということを前提の上で、2チーム体制を構築しました。

実際にドメインチームにしてみた結果、試みはすごく成功して、チームのスループットは向上しました。計画していたロードマップとかも大幅な変更や遅延なく完遂できて、プランニングもスムーズに行えるようになりました。

ここからわかってくるのは、やはりコンテキストスイッチのコスト、差し込みのコストはバカにできないということで。メンバーからも「作業がやりやすくなった」という感想もすごくあったし、コンテキストスイッチを最小化することは成果を出す上でも非常に重要なことだったなと思っています。その後、無事に採用もできたので、今も2チーム体制は継続しています。

スプリントレビューの形骸化への対策「Platform as a Productの取り入れ」

というところで認知負荷の増大に対して対処をして、次はスプリントレビューの形骸化に対して、自分たちはPlatform as a Productという考え方を取り入れました。

まずそもそも、スプリントレビューがうまくいかないことはレトロスペクティブで何度も課題としてあがっていて、自分自身はスクラムに代わる何かをずっと探していました。

いろいろとぼやきながら発散していたんですが、何も見つからないような状態でやっていて。解決方法は1つ見えていて、「専属のスクラムオーナーとかスクラムマスターとかを用意して正しいスクラムをやれば、そこそこできるんじゃない？」と思っていました。

先ほど説明したように、組織に技術系のバックログ中心のプロダクトマネージャーという席を用意するのは難しかったし、それを今すぐに自分たちでやることもけっこう難しい状況でした。

そんな中、ある日偶然とあるブログを見つけました。メルカリさんのブログだったんですけど、基盤、いわゆるプラットフォームも社内向けの、いわゆる1つのプロダクトとして捉えるんだということが書かれています。これを読んだ時にものすごく衝撃を受けて、今までの自分のモヤモヤみたいなものがすごくクリアになったんですね。

そもそもプロダクトオーナーの責務を考えればわりと自然なことで、じゃあプロダクトオーナーが何をやってくれているかというと、チームのプロダクトマネジメントをやってくれているんですね。僕らに欠けているのはプロダクトマネジメントであって、基盤プラットフォームを社内向けのプロダクトとして捉えれば、適用できるということだったんですよ。

それに気づかなかったのは、やはりAs-Isでの移行開発みたいなところの性質が自分の思考に少し制限をかけていたかなとかを思っていたりはしますが、当時の自分は本当に気づいていなかったので、今思うと「なんで気づかなかったんだろうな」と思ったりします。

やるべきことが見えてきたのであとは行動するのみということで、まずは自分がプロダクトマネジメントの本を何冊か読んで、プロダクトマネジメントの基礎みたいなところを学びました。

それで得られた知見を基に、チームで最初はミニマムに検証しようかなと思いました。まずはリリースサイクルという6週間のサイクルを定義しています。これは先ほどのブログにもありましたが、「Basecamp｣が採用しているThe Six Week Cycleを参考にしています。基盤を切り出すということは、1週間とか2週間のスプリントだと実際に動くものまでたどり着くのは難しいです。ですが6週間とかになってくると、そこそこいけるかなというのが自分の実感としてあります。

これはサイクル内で開発するインクリメント、成果物をリリースアイテムとして管理するようにしました。初期バージョンは本当にミニマムに始めたかったので、そこにはフォーマットとして概要、提供される価値、どのように利用するのかという、この3つだけに絞ってあります。

ここで気をつけることは、そのインクリメントでは必ずユーザーが実際に使えて、試せるものを開発する。これはフィードバックを得るために必要なことだったので、すごく重要視しました。

実際にやってみたんですが、6週間で動くものを提供しようと思うと、強制的に開発のスコープを削減させられるんですね。今までやっていた、重厚長大な設計議論を長々と2時間とかやっていると、とてもじゃないけど動くものは作れないんですよ。なので、とにかくスコープを削減するという意識がエンジニア全体に働きました。

あとは誰に対して価値を提供しているのかという部分で、提供する対象＝レビュワーになるんですが、そこを設定するのも良かったです。

利用方法は、基本的には評価方法を明確にするということなので、この概要と提供する価値、利用方法を定義することで、いわゆるどういうフィードバックを得るためにやっているのかがすごく明確になりました。

実際に開発したリリースアイテムをレビューしていくわけですが、最初はレビュー対象は参加できているかというところで、この時点ではまだチームで見るケースしかなかったです。なので、自分たちで作ったものを自分たちでレビューする。ちゃんと動くものができているかは実際に動くコードで確認をして、そこでちゃんと価値が出ているかを判断できました。

最初にちゃんと言語化していることによって、自分たちでもレビューを回せることが実感としてすごくあったし、スプリントレビューというか、その時はリリースサイクルのレビューになっているんですが、息を吹き返してきたんじゃないかなとすごく実感して、良い感じな気がしてきています。

（次回に続く）