調達後に返す技術的負債の順番

調達を終えた直後、開発チームから「今のうちに作り直したい」という提案が出ることがあります。シード期に速さを優先して作ったものが限界に来ている、という感覚は多くの場合正しいものです。ただし、その解決策として全面的な書き直しを選ぶと、別の問題が起きます。

技術的負債との付き合い方では、事業インパクトと変更頻度で優先順位を付ける一般的な考え方を扱いました。本記事は、調達直後という特定の状況に絞り、何を先に返すかを整理します。

全面書き直しを選ばない理由

全面的な書き直しの提案は、技術的には筋が通っていることが多いです。問題は、その間に何が起きるかです。

事業が止まって見える期間が生まれる。書き直しの間、顧客に届く変更は減ります。調達直後は、投資家にも社員にも進捗を示すことが求められる時期です。半年後に「見た目は同じだが中身が新しくなった」という報告だけが残る状況は、説明が難しくなります。

書き直しの期間は、見積もりより長くなりやすい。既存のシステムには、記録されていない例外処理や、特定の顧客向けの調整が含まれています。書き直してみて初めて「この処理は何のためにあったのか」が問題になり、その調査に時間が取られます。

書き直した先が正しいとは限らない。シリーズAの段階では、事業の形はまだ変わります。今の理解で「正しく」作り直したものが、一年後の要件に合っている保証はありません。

移行そのものの作業が発生する。データの移行、両方を動かす期間の運用、切り替え時の不具合。書き直しの工数とは別に、これらが積み上がります。

全面的な入れ替えが妥当な場合もありますが、それは既存の仕組みが事業の成長を物理的に支えられない場合や、使っている土台の保守が終了する場合など、限られた条件のときです。判断の枠組みはレガシーコードのモダナイズで扱っています。

返す順番を決める基準

調達直後に優先すべき基準は、「新しく入った人が、戦力になるまでの障害」です。

調達後にやることは、多くの場合、人を増やすことです。人を増やしても出せる量が増えないなら、調達の効果が出ません。そして、増えた人の立ち上がりを遅らせているのは、コードの美しさではなく、もっと手前のところにあります。

この基準で見ると、返す順番はおおむね次のようになります。

1. 環境を作れない、動かせない

最初に返すのはここです。新しく入った人が、手元で動かせるようになるまでに何日もかかる状態は、全員の時間を奪い続けます。

• 環境構築の手順が文章化されていない、あるいは書いてあるとおりにやると動かない
• 特定の人の端末でしか動かない設定がある
• 本番に近い状態でテストする手段がない

ここは、コードを書き直さなくても、手順の整備と自動化で改善できることが多い領域です。効果に対して工数が小さい部類に入ります。

2. 変更すると、どこが壊れるか分からない

次がテストです。すべてを網羅する必要はありません。変更頻度が高い箇所に絞って、壊れたことに気づける仕組みを入れます。

テストがないと、新しく入った人は変更を怖がります。怖がると、影響を調べるのに時間をかけるか、触らずに回避する書き方を選びます。後者が積み重なると、負債はさらに増えます。

3. 名前と構造が実態と合っていない

シード期に方向転換をすると、名前が実態とずれます。「案件」と呼んでいるものが実際には別の概念になっている、使われていない項目がデータの中に残っている、といった状態です。

既存メンバーは慣れているため気づきませんが、新しく入った人にとってはこれが最大の障害になります。コードを読んでも、業務の理解と対応が取れないからです。

すべてを直す必要はなく、中心となる概念の名前だけでも合わせると、説明の負担が大きく減ります。

4. 特定の一人しか触れない領域

決済の処理、外部システムとの連携、バッチ処理など、一人しか分からない領域が残っていることがあります。この段階では、その人が休むと事業が止まるリスクとして扱います。

返し方は、書き直しよりも、二人目が触れる状態を作ることです。処理の流れを文章にし、変更の手順を残し、実際に二人目が小さな変更を担当してみる。

5. それ以外

ここまでを終えたあとで、性能、コードの重複、古いライブラリの更新といった項目に入ります。これらは重要ですが、人が増える局面での優先度としては後になります。

あえて残す負債

すべての負債を返す必要はありません。調達直後に、あえて残す判断が有効な領域があります。

事業の仮説に強く依存する部分。料金の体系、マッチングの条件、画面の流れなど、今後も変わる可能性が高い部分です。ここを丁寧に作り直しても、変更されれば無駄になります。

使われていない機能。作ったが利用されていない機能は、直すのではなく、消すか放置するかを判断します。消せるなら消したほうが、以降の保守が軽くなります。

変更が発生していない部分。半年以上触っていない箇所は、読みにくくても実害が出ていません。触る必要が生じたときに返せば十分です。

重要なのは、残すと決めたことを記録しておくことです。無自覚に残っている負債と、判断のうえで残している負債は、扱いが違います。記録があれば、後から入った人が「なぜこうなっているのか」で時間を使わずに済みます。

返済を計画に組み込む

負債の返済は、別枠の特別な取り組みにすると続きません。機能開発との優先度の議論が毎回発生し、たいてい機能開発が勝ちます。

続きやすいのは、開発計画の中に一定の割合として最初から入れてしまう形です。割合を決めておけば、個別の交渉が不要になり、エンジニア側も「いつになったら返せるのか」という不満を抱えずに済みます。

割合の目安は案件により異なりますが、決め方としては、直近で「変更に時間がかかった」と感じた作業を振り返り、その原因の解消に必要な時間から逆算する方法が現実的です。

判断を経営の言葉に置き換える

技術的負債の議論が噛み合わない原因の多くは、技術の言葉のまま話されることです。経営側が判断できる形にするには、次のように言い換えます。

• 「コードが読みにくい」→「新しく入った人が最初の変更を出すまでに何日かかるか」
• 「テストがない」→「変更を出すときに、どのくらいの確率で不具合が出ているか」
• 「設計が古い」→「この箇所を変更するのに、以前の何倍の時間がかかっているか」

いずれも数字で表せます。数字になれば、返済に使う時間と、それによって取り戻せる時間を比較でき、判断が可能になります。

調達後の負債の扱いや、書き直しの是非の判断については、既存サービス改修・モダナイズやWebシステム開発のページとあわせてお問い合わせからご相談ください。ご相談・お見積りは無料です。