こちらの記事は hacomono Advent Calendar 2023の8日目の記事です

はじめに

こんにちは。開発本部フィーチャーグループのぺいです。

本記事では、私が所属しているフィーチャーグループで取り入れてみた「ツーマンセル開発」と呼んでいる開発スタイルについて、導入の背景や実際にやってみてどうだったかということについてご紹介したいと思います。

まずは私から導入の背景や課題についておはなしし、その後に実際にやってみてどうだったかというところについては同チームのエンジニアのれんれんにバトンタッチをしたいと思います。

導入の背景と課題

現在、hacomono の開発組織は拡大しており、以下のような組織構成になっています。

開発組織に属しているチームとしては、スクール・POS・フィーチャー・エンタープライズ・運用保守・Engineering Officeの6つがありますが、フィーチャーグループはこの中でも特に広範囲の開発を担当しているチームというのが特徴の1つです。担当する開発案件についてはもちろん、各所からの問い合わせや不具合の調査・修正等にも幅広く対応していく必要があります。

このようなチームの特性もあり、フィーチャーグループではチーム全体でまとまった1案件に全員で取り組むというようなスタイルではなく、個々人がそれぞれの開発案件を持ちつつ、日々の開発・運用に取り組んでいます。

課題1: コードレビューの難しさ

フィーチャーグループでのコードレビューは、メインレビュアー・サブレビュアーの2名をランダムにアサインする仕組みを取っていますが、先ほどのチームの特性もあり感じた課題がありました。

まずレビュアーの視点に立つと、チームの各メンバーがどのような案件に取り組んでいるかをおおまかには知っているものの、詳細についてはあまり知らないという状況です。そのため、しっかりとコードレビューをするにはそれなりに時間がかかります。その一方で、各々締め切りのある案件も持っている人も多く、あちらを立てればこちらが立たずというような状況にもなりやすいと感じていました。

レビュイーの視点に立つと、考慮漏れやバグを防ぐためにもちゃんとレビューをしてほしいと感じる場面が多いと思いますが、前述のとおりレビュアーとしてはなかなかそれが難しく両者がコンフリクトしているような状況になっていました。

なおここについては、私が入社2-3ヶ月時点だったという背景もあり、コードや仕様の理解も浅かったことは関係していたと思います。しかしながら、組織が拡大しつつあることを考えると、今後も引き続き発生する課題とも感じていました。

課題2: 一人で抱えやすい問題

hacomono はフルリモートワークを実践しており、チームのメンバーが住んでいる地域も様々です。非常に柔軟な働き方ができ、自分自身もフル出社に戻ることはもう考えられなくなってきていますが、各所でも言われているとおり意識しないとコミュニケーション不足に陥りやすい問題もあると思います。

フィーチャーグループでも、毎朝の朝会はもちろんオンラインで集まってわいわい開発する時間を定期的に取ったりと工夫をしています。

ただ、各々の持っている案件の細かいコンテキストについては共有しきれていないこともありピンポイントの具体な質問が少ししづらかったり、また緊急度の高い差し込みの対応に入ることで開発案件のスケジュールが厳しくなってきた場合も個人ががんばってなんとかするような場面もちらほら見えていました。

このような背景・課題の解決策の1案として、ツーマンセル開発をチーム内に提案し、実際にトライしてみることになりました。

ツーマンセル開発について

ツーマンセル開発とは、ほぼ言葉の意味そのままにはなりますが、我々の中では次のような開発スタイルと定義しました。

1つの開発案件に対して、2人がコミットし、品質やデリバリーまでの責任を持つ
- 上記を前提として、タスクの分担は自由。ペアで進めるもよし、設計と開発で分担するもよし
ペアプロすることではない
コードレビューはペアの人を指定し、サブレビュアーとしてフィーチャーグループから1名を指定する

ポイントとしては、常にペアで進めるというのではなく、2人が品質・デリバリーに責任を持つものとし、細かな進め方については特別なルールはほとんど設けなかったところです。ペアプロもあくまで一手段であり、使うかどうかは2人の判断次第です。

コードレビューは変更の背景や修正の目的といったコンテキストの理解が重要になります。案件にコミットしている人であればその理解は自ずと深まっていき、短い時間で効果的なレビューができるようになると考え、ペアのメンバーをレビュアーにするという方針だけ決めていました。ただ、逆に2人で視野が狭まってしまう可能性も考慮し、第三者的な視点で見てくれるサブレビュアーは通常通りチーム内からアサインすることにしました。

実際にやってみた

2023年の9月 ~ 11月にかけて、ツーマンセル開発で取り組むのにちょうどよい規模感の開発案件があったため、ぺい・れんれんペアで取り組みました。

課題１に対して

お互いにどのような案件か理解し、コード理解も深まっているため素早く正確なレビューが行えました。軽微な修正などの小規模PRのマージのスピードが速くなり、修正点があれば即座に対応できました。これにより、開発の停滞を最小限に抑え、迅速かつ効率的なプロセスが確立されました。

機能の実装が完了した後、動作確認とテストコード実装を手分けして担当できました。これにより、開発速度を維持しつつ品質の担保ができ、バグの早期発見と修正がスムーズに行えました。協力体制による分業が、開発サイクルを効果的に短縮しました。

課題２に対して

複雑な箇所のコーディングについては、ペアプロを行うことでコミュニケーションを密にとり、お互いのコード理解度を上げることができました。また普段は1人で黙々と進めているので気分転換にもなりました。

どちらかが多忙な時にも、もう一方が柔軟にタスクを引き受けることができました。これにより、プロジェクトの進捗が滞ることなく、常に効率的に作業を進めることが可能でした。予定変更にも対応できる柔軟性が、プロジェクトの安定性を高めました。

思わぬ収穫

案件に関わったPdMやQAからのお褒めの言葉や反応を多くいただけました。

質問をした時の回答をどちらかがすぐに対応できるため、待ち時間が少ない点や、QAで見つかった不具合の修正も分担して行うことで、すぐに修正が上がってきた点など。

またそれぞれが複数案件を抱えている中、案件に対して全員がしっかりと向き合っており、良い議論ができました。

感想

フィーチャーチームでは誰かと1つの案件に一緒にコミットすることは少なかったため新鮮でした。かなり複雑なロジックに手を入れる必要があったため、1人ではなく2人で進められたことは、安心感があり落ち着いて案件を進めることができました。また複雑な箇所を理解しているメンバーが増えチームとしても良かったように思います。

結果的により良いものを提供するために一部リリースを見送った箇所がありましたが、そこの判断もツーマンセルだったためより良い判断ができた印象でした。