こんにちは。カケハシでソフトウェアエンジニアをしている椎葉（@bufferings）です。私の所属するチームでは先日「質とスピード」についてのふりかえりを実施しました。この記事では、チームが「質とスピード」をふりかえってどのようなことを話し合い、何を決めたのかご紹介します。
この記事は カケハシ Part 1 Advent Calendar 2023 10日目の記事です。今年のカケハシのアドベントカレンダーにはPart 1とPart 2があるので、両方とも楽しんでいただけると嬉しいです。
「質とスピード」の社内講演会
カケハシでは、9月に和田卓人さん（@t_wada）をお招きして「質とスピード」の社内講演会を開催しました。
講演中には社内のSlackで「わかる…」「刺さる…」「考えさせられる…」などさまざまなコメントがすごい速さで流れて非常に盛り上がりました。講演後には開発のメンバーはもちろん、ビジネスや薬剤師のメンバーからも「参加してよかった」という声があがっているのを聞いて、お話をしていただいて本当によかったなと感じました。ちなみに、私は講演前からワクワクしすぎていました。
「質とスピード」をふりかえろう
それからしばらくして、チームのエンジニアの間で次のような話題があがりました。
- 改善したいことはたくさんあるが、ビジネス的・開発リスク的に優先度が低いものは後回しになって、ずっと対応されないままになりやすい（これまでの経験上）
- しかし、このチームはそういったことにも対応していけるチームでありたい
- 「ゆとり」を開発プロセスに組み込むことがキーポイントになりそう
実は、私の所属するチームは私が入社した今年の4月に立ち上がったばかりの新チームです。最初は4人だけの小さなチームで、仮説検証のための土台作りにがむしゃらに取り組んでいました。その後、徐々にメンバーが増え、今では8人のチームになっています。開発も土台作りを終え、その土台の上で仮説検証をすばやく繰り返していくフェーズに切り替わりました。
このように、メンバーが増えてきたタイミングかつフェーズが切り替わるタイミングだったため「このあたりでいちど、このチームの開発リズムを見つけたいね」という話をしていて上記のような話につながりました。
チームのエンジニアリングマネージャ（兼スクラムマスター）である、いくおさん（@dora_e_m）に相談したところ「とてもいいですね。『質とスピードとゆとり』についてプロダクトマネージャも含めてみんなで議論する場を設けましょう」と、ふたつ返事で引き受けてくれました。
質とスピードとゆとり
それからしばらくバタバタしていて少し時間があいてしまいましたが、ついに11月に「質とスピードとゆとり」の会が開催されました。
いくおさんのファシリテーションの段取りがすばらしくて、さすがだなと思いながら見ていました。次のような情報を事前に共有してくれていて、当日はFigJamのボードを見ながらチームのみんなで意見を出し合いました。
- テーマ
- チームで「質とスピード」をどう働き方に落とし込むかを話し合う
- アウトプットのイメージ
- 落とし込んだ内容をもとにしてワーキングアグリーメントを作成する
- 進め方
- 前半：「質とスピード」をふりかえる
- 後半：僕たちにできること・やりたいことを考える
前半：「質とスピード」をふりかえる
前半は「質とスピード」の講演を思い出しながら、みんなで意見交換をしました。いろいろな話題について議論をしたのですが、今日はその中から3つだけピックアップして紹介します。
同じものを見ることが大切
まずひとつ大きな話題として「プロダクトマネージャとエンジニアで同じものを見て話すことが大切だよね」という話がありました。
技術的負債をどう返済するかといった内部品質の改善についての話は、ともすればプロダクトマネージャ対エンジニアのような構図になりがちです。ユーザーに少しでも多くの価値を届けたいプロダクトマネージャと、技術的負債を返済したいエンジニアで意見が対立するという構図です。
でも、よく考えると対立するのは変ですよね。プロダクトマネージャもエンジニアも、視点は違えど実現しようとしているのは「ユーザーへの価値提供」のはずです。大切なのは「ユーザーにとって何がよくなるのか」という同じゴールを見ながら話すことです。
そのため、お互いの意見に敬意を払いながら、プロダクト視点とエンジニアリング視点の両方の視点を考慮に入れてプロダクトをよりよくしていきましょう、という話をしました。
実際に最近、プロダクトマネージャから次のような言葉がありました。「改善はプロダクトのためにとても大切だと考えている。だから私たちプロダクトマネージャがやるべきことは、改善の時間を削って機能を詰め込もうとすることではなく、仮説検証をより素早く効果的に回せるようロードマップを整備することだと考えている」。
一方、エンジニアからもこのような声があがりました。「少し先を見据えた改善はとても大切だと思っている。だが、先ばかりを見すぎて目の前の仮説検証が回らなくなると私たちのプロダクトの意味がない。改善に取り組みつつも、継続的に新機能をリリースしていきたい」。
今回のふりかえりによって「質とスピード」という観点でお互いの認識を揃えられたため、自分たちが同じ「ユーザーへの価値提供」を中心に持っていることを再確認できました。そして、お互いの意見を尊重する意識がより一層強まりました。
改善は毎日のいとなみにしたい
「改善をしていくにあたって、どういう仕組みで取り組んだらいいだろう」という話もありました。
何も仕組みを用意せずに「改善を意識しましょう」というだけでは改善が進まなさそうだなと容易に想像がつきます。プロダクトマネージャだけでなくエンジニアも「少しでもはやく、少しでも多く、機能をユーザーに届けたい」と強く思っているからです。何の仕組みもないと、改善よりも機能開発を優先してしまいます。
ひとつの方法として「何ヶ月かに1回だけ特別なスプリントを用意して、そのスプリントでは機能追加をせず改善だけに取り組む」というものが考えられます。また別の方法として「スプリントの最後の日は改善にあてる」のようにするのもいいかもしれません。そういった「改善のためのスプリント（または日）」を用意する方法です。実際に私は過去にそのような取り組みを実施したことがあります。
それはそれでとてもいい取り組みだと思っているし、実施したいとも思っているのですが、今のチームではもう少し踏み込んだ挑戦もしたいなと思いました。それは「改善を特別扱いせずに、毎日のいとなみにしたい」ということです。
特別なスプリントや特別な日を用意するのではなく、日々の開発の中で改善にも取り組みたいという思いです。他のメンバーからも日々改善に取り組む文化をチームでつくりたいね、という話が出ました。
どう取り組むことにしたのかは、後半の部分で紹介します。
チームとして課題に取り組もう
最後に「チームとしてどうすれば、ゆとりが生まれるだろう」という話もありました。これに関しては「個人ではなくチームとして課題に取り組もう」とプロダクトマネージャから提案がありました。それによってチームとしてゆとりを持てるようにしようというアイデアです。この提案がプロダクトマネージャから出てくるのが、このチームの強さだなと思いながら聞いていました。
エンジニアは、メンバーが増えて4人になってからモビングで開発に取り組んでいます。複数のユーザーストーリーに同時に着手して各メンバーがバラバラに動くのではなく、全員で同じユーザーストーリーに取り組む進め方です。
この取り組みは、プロダクトマネージャから見てもいい取り組みだったようです。仕掛中のユーザーストーリーを少なく保って、小さなユーザーストーリーに全員で取り組み、最短でリリースまで持っていくことで、すばやく仮説検証を繰り返せるからです。
プロダクトマネージャもエンジニアもこのやり方を気に入っていたので、この進め方をチームの進め方とすることにしました。 カケハシではフルリモートの働き方を採用しているため、私のチームのモビングはSlackのハドルで開催しています。プロダクトマネージャやエンジニアリングマネージャも、参加できるときはモビングに参加しようということになりました。
後半：僕たちにできること・やりたいことを考える
「質とスピード」のふりかえりを終えて、後半は「それで、僕たちはどうしたいか」という話をしました。前半の中でもそこまで踏み込んで議論していましたが、もういちどチームで認識を揃えました。
私たちの思いは次のとおりです。プロダクトマネージャもエンジニアも、そしてエンジニアリングマネージャも、チームのみんながこの両方に賛成しました。
- 仮説検証のための新規開発は止めたくない
- だけど、日常的にカイゼンにも取り組みたい
そして、この2つを両立させるためにどうしようか、と話し合った結果、次の2つをチームのワーキングアグリーメントとして定めることにしました。
- プロダクトの成長とカイゼンを両立するため、新規開発5割、エンジニア提案2割、残り3割可変でスプリントを計画する
- ユーザーストーリーを小さく保ち、ペアワークやモビングで1個ずつ潰していく
ここで「改善」が「カイゼン」に変わっているのは、いくおさんのアイデアです。広い視野を持ってサービス全体を見ながら継続的にカイゼンしていこう、という思いが込められています。
このワーキングアグリーメントの作成をもって「質とスピードとゆとり」の会は終わりました。チーム内でいい議論ができて、とても有意義な時間でした。
それから1か月
このふりかえりから約1か月がたって今この記事を書きながら、「質とスピードとゆとり」の会を開催して本当によかったなと再度感じています。
この会の次のスプリントからは、ワーキングアグリーメントにしたがってスプリントへ入れる新規開発タスクの量は控えめになりました。そして、残りをカイゼンへあてられるようにしてみています。
最初のうちはそれでもまだ新規開発のタスクを多く入れすぎてしまい、ほぼそちらに時間を使ってしまっていました。しかし、その後は徐々に感覚をつかみ、カイゼンにも時間を割けるようになってきました。
具体的なカイゼンとしては、利用されなくなったAWSリソースの削除、気になっていたコードのリファクタリング、一部手動で行っていたリリース作業の自動化、モニタリングの改善、自動テストの追加などに取り組みました。
また、プロダクトマネージャやエンジニアリングマネージャが、可能なときはモビングに参加してくれるようになりました。そのおかげでプロダクトマネージャにその場で仕様の確認をしながら進めたり、エンジニアリングマネージャにその場で他のチームとの協業についての相談ができたりと、よりスムーズに開発が進められるようになっています。
まだまだ、試行錯誤中ではありますが全員が同じ認識を持ってチームとして前に進んでいることを実感できてとても嬉しく思っています。これからも、質とスピードを保って開発が続けられるように新規開発とカイゼンの両方に取り組んでいきたいと思います。
この記事では、和田さんの「質とスピード」の講演に対するふりかえりをチームで実施して、ワーキングアグリーメントに落とし込んだお話を紹介しました。
明日は、このチームの立ち上げ時のエンジニアリングマネージャでありカケハシのVPoEでもある、ゆのんさん（@yunon_phys）が担当です。お楽しみに。
