リリースを加速するACES Meetの設計プロセス

こんにちは、株式会社ACES でソフトウェアエンジニアをしている奥田（@masaya_okuda）です。

この記事では、私の所属するACES Meetの開発チームで実践している設計プロセスをご紹介します。ここで言う設計とは、PdMから開発チケットの要件定義が共有され、本格的な実装を始める前までの期間に行うプロセスを指します。

背景には、私たちの開発チームが以下の課題を抱えていたことがあります。

これらが原因となり、リリースまでの期間が大きく遅延したり、手戻りによる実装者とレビュアーの疲弊につながっていました。

改善にあたり、開発工程のどこに課題があるのかを検討した結果、Pull Requestの粒度であると分かりました。

背景には変更の全体像が不透明なまま開発が進められ、結果的にスコープが広がってしまうという構造的な問題もありました。 Pull Requestの粒度に関してはFindy社のテックブログでわかりやすくまとまっており、参考にさせていただきました！

Pull Requestの粒度を適切に保つためには、本格的な実装を始める前に変更の全体像を把握し、タスク分解することが重要と考え設計フェーズで行うことを整理しました。

設計フェーズは、大きく4つのステップで構成されています。

Step4のタスク分解は1つのPull Requestで行うことと対応しています。設計フェーズの目的は、1つのPull Requestが意味のある粒度で小さくなるようにタスクを分解し、その開発ステップをレビュアーと合意することです。

設計の初めに要件を具体化します。この工程では、満たすべき仕様を整理し、開発者間で認識を共有できる形に落とし込みます。

このステップでは要件に対する理解を深め、仕様に納得感を持って次の工程に進むことを重要視しています。特に、開発者がPdMやデザイナーと協力して仕様を検討することで、現場感覚を反映した実現可能な設計を追求しています。

要件を具体化する中で、以下のような場面に直面することがあります。

上手く言語化できないとき
- どの画面上でどのように動作するのか？
- ユーザーの状態によってどのように分岐するのか？
- → PdMやデザイナーと開発者が直接対話することで、具体的なシナリオを共有します。
ボリュームが大きくなりすぎるとき
- この機能開発で複数のことを同時にやろうとしていないか？
- もっとシンプルにしたり、機能を分割することでリリースを高速化できないか？
- → チームで優先度を再評価し、必要に応じて分割案を議論します。

ここで重要なのは、「言われたことをそのまま作る」ではなく、開発者自身が仕様の妥当性や実現性を検証し、必要であればフィードバックを返すことです。例えば、設計段階で以下のような「現場の気づき」をチームに共有し、納得できる解決策を模索します。

次に仮実装を行います。次に仮実装を行います。仮実装の目的は、「タスク全体のイメージを掴むこと」と「適切な粒度でタスクを分解するための判断材料を得ること」です。

タスク全体のイメージを掴む
- 具体的にどの箇所に変更が必要か？
適切な粒度でタスクを分解するための判断材料を得る
- 実装の前例が無いなど、不確実性の高い実装はどこか？
- セキュリティリスクが高く、慎重な設計が必要な箇所はどこか？
- 修正箇所で事前にリファクタリングが必要な箇所があるか？

この段階では、作り込みに時間をかけすぎないように注意します。例えばフロントエンドの仮実装の場合は、以下の観点で進めます。

仮実装で開発の全体像を掴んだ後にタスク分解を行います。この工程は本格的な実装時にレビュアーとなるエンジニアとバディで行います。レビュアーが以下のポイントを事前に理解しておくことで、レビュー時のコストが大幅に削減されます。

さらに、仮実装を確認しながら、手戻りが大きくなりそうな認識のズレがないかを事前に検証します。

設計フェーズを改善した結果、冒頭で挙げた課題への効果を実感しています！

課題：大きなPull Requestが作成され、レビューコストが高い
- タスクを小さく分解することで、1つのPull Requestが意味のある粒度に保たれ、レビューが効率化
- 仮実装の段階でタスク分解を行うため、レビュー時に「何を見ればよいか」が明確になり、レビュアーの心理的負担が軽減
課題：レビュアーと実装者の認識齟齬による指摘の多発と手戻り
- 設計フェーズで要件を具体化し、認識を共有することで、仕様や設計の方向性に対する共通理解が形成され手戻りが減少
- 仮実装を通じて、「想定外の仕様変更」や「実現が難しい設計」を早期に発見し、実装後の修正コストを削減