並行開発によるコンフリクト……巨大システムゆえの辛みと解決策
この壮大な改善プロジェクトは、机上の空論通りに順風満帆に進んだわけではない。当初、これらのステップを直列のウォーターフォール的に進行させ、1つの業務領域の整理を3カ月で完了させる計画だったが、6カ月経過時点で想定の4割程度しか進捗しないという極めて厳しい壁に直面した。
最大の要因は、巨大なシステムゆえの「並行開発」との激しい衝突であった。日常的な機能追加を進める他チームと同じコードベースを共有しているため、パッケージの抜本的な変更はとてつもない規模のコンフリクト（競合）を引き起こした。深見氏は「ただただコンフリクトを解消することに時間を浪費するようになっていって、辛みが出てきた」と当時の苦境を語った。
この状況を打破するため、チームはアプローチを根本から転換する。ステップ1から3のプロセスを一度に大きく進めるのではなく、機能単位の極めて小さなサイクルに分割し、クイックに回してはすぐにメインのコードベースにマージする手法へと切り替えたのだ。この柔軟な軌道修正により、コンフリクトの発生を最小限に抑え込むことに成功した。
さらに、サイクルを短期間で回すことでチーム内に経験値が急速に蓄積され、コードの不吉な匂いを素早く嗅ぎ分ける能力が向上し、改善の質とスピードそのものが劇的に高まっていった。また、ステップ2の「物理的な境界線を引く作業」とステップ3の「論理的な知識を集約する作業」は、シームレスに行うべきだという実践を通じた深い学びも得たという。
結果として、システム全体の課題はどう変化したか。増大するプロダクトの規模自体は変わらないものの、境界分けと業務知識の集約によって、コードの見通しは以前とは比べ物にならないほど良くなった。必要な処理が適切な場所にまとまっているため、エンジニアの認知負荷は大幅に低減している。
また、単体テストが拡充されたことでチームに「ちょっとこういうリファクタリングを試してみようか」という心理的安全性が生まれ、「リファクタリング耐性の低さ」という壁は見事に乗り越えることができた。属人化の解消に関しても、単体テストが生きた仕様書として機能し始めたことで、着実に改善の兆しを見せている。
さらに特筆すべき定性的な効果として、この地道な活動に賛同するエンジニアが徐々に増え始め、最終的には深見氏の組織内での年間目標にこの活動が正式に据えられるに至ったことだろう。
