「手戻り」を仕組みでなくせる。ITANDI 賃貸仲介チームが辿り着いた爆速開発の最適解

はじめに

こんにちは。「ITANDI 賃貸仲介」開発チームの藤井です。

私たちのチームでは、現在サイクルタイムの中央値が「1.4時間」という数値を記録しています。さらに驚くべきことに、レビューが依頼されてから承認（Approve）されるまでの時間は中央値0.0時間、つまりほぼ即座に承認されています。

「そんなの、レビューを適当にやっているだけじゃないか？」と思われるかもしれません。しかし、実態はその真逆です。

品質を担保したまま、なぜこれほどの流動性を実現できているのか。本記事では、個人の技術力に頼らない仕組み（合意とチケット運用）の力についてご紹介します。

かつての課題: 開発の「淀み」

以前の私たちの開発現場では、以下のような「淀み」が頻繁に発生していました。

  • 実装後の大きな設計指摘による「差し戻し」
  • レビュー待ちによる「手持ち無沙汰」
  • PRが溜まることによる「コンフリクト解消」のコスト

これらはすべて、早く作りたいのに止まってしまう状況を生んでいました。

爆速開発を支える「3つの柱」

私たちは、この「淀み」を解消するために、ワーキングアグリーメント（チームの合意）として以下の3つの柱を定義しています。

1. 「着手前の対話」で不確実性をゼロにする

実装が完了した後にレビューで揉めるのは、最大のムダです。 私たちは、チケットのステータスに会話済みという項目を明文化しています。PdMとは「どういう価値を完成させたいのか」を、エンジニア同士では「具体的にどう実現するのか」を事前に議論し、合意を得てから手を動かします。

2. 「マイクロ分割」でチケットを最小化する

ストーリーポイント（SP）が5以上のチケットは、スプリントへの組み込みを禁止しています。 常にデモ可能な最小単位でチケットを構成し、1、2、3の小さいポイントで回すことで、レビューアーの脳内負荷を最小化しています。

3. 「20分ルール」で詰まりを放置しない

手が止まって20分経ったら即ヘルプ。一人の「詰まり」をチーム全体の課題として捉え、誰かがすぐにサポートに入るカルチャーを徹底しています。

手戻り0を実現する「チケット作成の黄金4ステップ」

具体的にどのようにチケットを運用しているのか、そのフローをご紹介します。

  1. デモ単位の定義: まずPdMと「最終的に何を見せるか（デモの内容）」の会話を行い、受入可能な最小単位にStoryを分割します。
  2. 設計の目線合わせ: 実装前に設計について会話します。ここで設計の合意を取ります。
  3. SP 1, 2, 3の原則: チケットが重ければ、躊躇なく分割します。
  4. E2Eの実装: Storyの最終ステップとしてE2Eテストを実装し、品質を担保します。

具体的には、PdMとはユーザーストーリーの目線合わせや受入条件の合意を、エンジニア同士ではDesign DocやDraft PRを用いた設計の合意を行っています。 会話や合意の粒度は、チームの習熟度や状況（新人がいるか等）に応じて調整していますが、「着手前の対話」で不確実性をゼロにすることが、私たちの開発プロセスの根幹を成しています。

PRは「答え合わせ」の場ではない

私たちのチームにおいて、PRは「確認」だけの場です。

事前に設計が合意（会話済み）されているため、レビューは「あ、さっき話した通りだね」と確認する作業になります。これが、レビューから承認まで「0.0h」という数値の正体です。実装後に「これ、設計からやり直しね」という悲劇は、私たちのチームでは起こり得ません。

現在の課題と今後の展望

ここまでの内容だけを見ると完璧な開発プロセスのように映るかもしれませんが、正直にお伝えすると、まだ検証しきれていない点もあります。

  • 大規模開発での未検証: この開発プロセスに移行してから、規模の大きい開発をまだ経験していません。チケットのマイクロ分割や事前合意といった仕組みが、複雑度の高い機能開発でもスケールするかどうかは今後の検証課題です。
  • メトリクスと実質的な価値提供のギャップ: サイクルタイムの数値は確かに良好ですが、「計画し始めてから顧客へ価値を届けるまでの時間」で見たときに、本当にこの開発プロセスが効果を発揮しているのかはまだ十分に検証できていません。メトリクスの改善が、顧客への価値提供のスピードに直結しているかを引き続き見極めていく必要があります。

これらの課題に向き合いながら、チームとしてさらに進化していきたいと考えています。

最後に：アグリーメントは「自由」のためのガードレール

私が大切にしている言葉があります。

チームの合意（アグリーメント）は「縛り」ではない。チームを「自由」にするためのガードレールである。

ルールがあるからこそ、迷う時間が減り、コンフリクトや差し戻しに怯えることなく、私たちは本来の「開発」という創造的な活動にフルパワーで集中できています。 この運用術が、開発効率に悩むエンジニアやPdMの方々の参考になれば幸いです。