皆さんならどう進めますか？

4月上旬、2つの機能開発を担当することになりました。

どちらもDBスキーマからバックエンドAPI、フロントエンドまでフルスタックで作る必要があり、大きめの実装ではありました。とはいえ、ADRはすでに書き終わっていて設計の方針は固まっていたので、あとは実装するフェーズでした。

さて、皆さんならどう進めますか？

AIを活用した開発が当たり前になってきた今、コード生成は並列にいくらでも回せるようになりました。2つの機能を抱えたら「同時に進めて速くリリースしよう」と考える方が多いのではないでしょうか。

でも私は、並列にしませんでした。あえて直列で進めることにしたのです。

なぜ並列にしなかったのか

今回担当したのはファイル管理機能と仕様設計管理機能の2つです。まず前提として、この2つの機能には共通する要素がかなり多いという点がありました。どちらもフォルダでファイルを管理する機能が必要で、PDFのプレビュー機能やファイルの移動機能もあり、重複する要素は多くありました。

並列で進めるメリットはもちろんあります。両方の機能が同時に進むので、カレンダー上のデリバリーは早くなる可能性がありますし、片方がレビュー待ちの間にもう片方を進められるので手が空く時間も減らせます。

ただ、共通部分をうまく共通化しながら2つの機能を同時に進めるのは、思った以上に難しいのではないかと考えました。

似た機能を2つ同時に進めると、それぞれの仕様の違いを常に正確に把握しながら判断し続けることになります。似ているからこそ混乱しやすく、「この仕様はどっちの機能の話だっけ？」というミスが起きそうだと感じました。

さらに厄介なのが共通化のタイミングです。「ここ共通コンポーネントにしたい」と思っても、もう片方がまだそこまで進んでいないと設計が定まらない。そのまま進めると、似たようなコードが別々に生まれて、あとから統合する手間が増えてしまいます。

それなら、先に片方を作りきってしまって、そこで生まれたコンポーネントを共通化しながらもう片方に展開するほうがずっとやりやすい。そこで今回は、ファイル管理を先に完成させて、それを"土台"として仕様設計管理を作るという順番にしました。

結果：どちらも約10日でデリバリー

まずファイル管理は、10本のサブPRに分割して4/7〜4/16の約10日でリリースしました。PDFプレビューのDrawerやフォルダツリーのピッカーなどは、「次でも使う前提」で少し抽象度を上げて実装しています。

機能同士は直列でも、サブPRの中では切り分けられるものは並列に実装を進め、レビュー待ちの間に次のPRへ先行着手することで、待ち時間もなるべく詰まらないようにしました。

続く仕様設計管理は、14本のサブPRで4/17〜4/27の約10日。ファイル管理よりスコープは大きかったのですが、セルフマージの導入も伴い、ほぼ同じ期間で出せています。特にPR5〜PR14は2日間で一気に積み上げられました。

ファイル管理で作ったコンポーネントがそのまま使い回せたので、新しく書くのはドメイン固有のロジックだけで済んだのが大きかったです。

ファイル管理仕様設計管理
期間4/7〜4/16（10日）4/17〜4/27（10日）
サブPR数1014
変更ファイル数106153

直列で進めたことで、1つ目の実装では「ここは後で共通化する部分だ」と意識しつつ目の前の機能に集中でき、2つ目の実装では「1つ目のどこを再利用するか」だけにフォーカスできました。考えることがフェーズごとにシンプルになるのは、直列ならではの良さだったと思います。

並列で進めていたら、両方の進捗を常に追いながら共通化のタイミングを見計らったり、ブランチの切り分けに悩んだりと、実装以外のところで消耗していたのではないでしょうか。

余談：それでもミスは出る

直列戦略で集中できたとはいえ、速度を上げた分の副作用はありました。既存のenumの設計意図を十分に理解しないまま不要な値を追加してしまったのです。自分のレビューでも抜けていましたし、既存設計の「なぜそうなっているか」はAIにも判断しづらい部分でした。本番リリース前に気づけたものの、すぐに実装方針ドキュメントに運用ルールを追加しました。こういったミスをチームの資産にしていくところまで含めてデリバリーだと思っています。

まとめ

AIに指示すればコードは並列にいくらでも生成できますし、できるだけ早くリリースしたい気持ちもありました。ただ、「本当に自分は並列で速く進められるのか」と考えると、少なくとも自分の場合は難しいと感じました。似た機能を同時に扱うとコンテキストの切り替えが増え、結果的にミスが出やすいためです。

そこで今回は、並列に進めること自体を目的にせず、進め方の粒度を分けてコントロールしました。Epicは直列、サブPRは並列という形です。見かけの並列度を上げるより、判断をシンプルに保つほうが結果的に速いという感触でした。

今回の判断の軸は並列度そのものではなく、「スピードと、自分が安定して判断できる範囲のバランス」です。今後もこうしたバランスを考える場面は増えそうですし、この記事がその判断のヒントになればうれしいです。