ドキュメントなしの維持コスト——技術的負債の試算

2026.06.06

執筆者:DigKnow株式会社 CTO 桑原 脩

「技術的負債の話はわかる。でも、具体的にいくらかかってるの?」——この問いに即答できる人は、どれくらいいるでしょうか。私自身、ドキュメントの薄い現場でコードの読解に想像以上の時間を取られてきました。「なんとなく大きい」とは感じても、数字で出せと言われると詰まってしまうのです。この記事は、そのモヤを少しでも数字に寄せる試みになります。精緻な会計ではなく、思考の補助線としての試算です。

 

コスト可視化の前提とモデルケース

ドキュメントのないシステムの維持コストが語られにくいのには、構造的な理由があります。ソフトウェア開発のコストは、普段は「新機能の開発工数」や「インフラ費」といった発生源が明確な項目として計上されます。予算申請にも、決算にも、きれいに並びます。
一方で、今回取り上げたい維持コストは、既存の開発工数の内側に溶けています。「新機能の実装に2週間かかった」と報告されたとき、その2週間の内訳を誰も分解しません。実装そのものに使われた時間、既存コードを読み解くのに使われた時間、「なぜこう書かれているのか」を探索するのに使われた時間——これらは一つのチケットにまとめて計上されます。結果として、ドキュメントがないことによる時間的損失は、発生していても観測されません。予算会議に姿を現さないので、経営判断の俎上に載ることもありません。
この記事でやりたいのは、その観測されない支出を、乱暴でも構わないから一度数字にしてみることです。精度より、桁感。以下の試算は「仮のチーム」を前提にした思考実験であり、実際の企業の数値ではありません。ただ、枠組みとしては多くの現場に当てはまるはずです。

具体的に考えるために、一つのモデルケースを置きます。
– エンジニア10人のチーム
– 平均人月単価80万円(人件費+間接費を含んだ、経営から見たコスト。スタートアップや中堅SIerの現実的な水準として置きます)
– 稼働日数:月20日、1日8時間

この前提で、年間の人件費は単純計算で10人 × 80万円 × 12ヶ月 = 9,600万円。約1億円のチームと考えてください。この1億円がどう使われているか、を分解していきます。なお以下の比率は「仮置き」なので、読者のチームと合わないと感じたら、現場の感覚で数字を差し替えて読んでみてください。それができる時点で、このフレームワークは役に立っているはずです。

 

コスト1:コードを「読み解く」時間

まず一番大きい塊から見ていきます。既存コードを読み解く時間です。
新機能開発にせよ、バグ修正にせよ、機能拡張にせよ、ほぼすべてのタスクは「既存コードを読む」ところから始まります。この「読む」に、本来どれくらいの時間が使われているのか。
「コードを読む時間は書く時間の10倍以上」とロバート・C・マーチンも『Clean Code』で指摘しているように、エンジニアの時間の多くは「すでにあるコードを読み解くこと」に使われています。その読解時間のうち、ドキュメントがそれなりに整っている現場では、タスク全体時間の15〜20%ほどが「いま手元で触っているコードがなぜこう書かれているか」を理解するために溶けています。一方、ドキュメントが薄い、あるいは古くて信頼できない現場では、これが30〜40%に跳ね上がります。差分はざっくり15〜20%ほどです。

このギャップを年間コストに換算してみます。
– 年間稼働時間:10人 × 20日 × 8時間 × 12ヶ月 = 19,200時間
– 読解時間の増加分(20%と仮定):19,200時間 × 20% = 3,840時間
– 時間単価換算(80万円/160時間 = 5,000円/時間):3,840時間 × 5,000円 = 1,920万円

1億円のチームで、年間約1,900万円。全体の約20%が、「コードが何をしているか」を再発見するためだけに溶けている計算になります。これを「実装の一部」と見ていたときと、「ドキュメントが薄いことによる追加コスト」として分離したときでは、意思決定の色がまるで変わります。年2,000万円の支出項目があれば、経営は放置しません。

 

コスト2:オンボーディングの長期化

次に、新しくチームに加わるエンジニアがキャッチアップする時間です。
ドキュメントが整った現場では、新人が戦力化するまで1〜2ヶ月というのが私の感覚です。ドキュメントが薄い現場では、これが3〜6ヶ月に伸びます。この差分をコストに直してみます。
一例として、差分を3ヶ月、年間の新規入社者を2人と置きましょう。
– 2人 × 3ヶ月 × 80万円 = 480万円
新人自身の稼働ロスだけで年間約500万円。さらに、新人のキャッチアップ期間中には既存メンバーの説明時間が上乗せされます。Slackでの質問対応、ペアプロ、ドキュメントにない文脈の口頭伝達——これらを新人1人あたり月20時間と仮に置くと、2人 × 3ヶ月 × 20時間 × 5,000円 = 60万円。
合計すると、オンボーディングの長期化だけで年間約540万円の追加コストが静かに発生していることになります。1,900万円と比べると小さく見えるかもしれません。ですが、人の出入りは毎年あります。採用を増やすフェーズに入れば、この項目は比例して膨らみます。

 

コスト3:障害対応と意思決定の遅延

三つ目は、障害対応時の損失です。ドキュメントが整っている現場と、そうでない現場では、障害発生時の平均復旧時間(MTTR:Mean Time To Repair)に差が出ます。「本来これはどういう設計だったか」を踏まえた一次調査ができるかどうかで、復旧までの手探りの時間がまるで変わるからです。

モデルケースで、年間に重大障害が5回、軽微な障害が月2回発生すると仮定します。
– 重大障害:5回 × 復旧時間の伸び10時間 × 3人同時稼働 × 5,000円 = 75万円
– 軽微な障害:24回 × 復旧時間の伸び2時間 × 2人同時稼働 × 5,000円 = 48万円
年間約123万円。さらに、復旧が長引けば売上機会が消え、SLA違反による賠償や顧客信頼の毀損といった、数字になりにくいコストも積み上がります。

そして、もう一つ厄介な「見えにくいコスト」があります。経営レベルの意思決定が遅れる・歪むコストです。「このシステムをリプレイスすべきか」「このモジュールを切り出して別サービス化できるか」「競合が新機能を出したが、今のアーキテクチャで対抗できるか」——こうした判断には、システム全体の設計思想と制約を理解している人が必要です。理解者がいない場合、経営は次の三つのどれかを選ばされることになります。

① 判断を保留する(競合に先を越され、機会損失が発生する)
② 安全側に振りすぎる(よくわからないから触らない、を繰り返してイノベーションが止まる)
③ 過大な調査コストを払う(外部コンサル費や数ヶ月の現状分析で数百万〜数千万の追加支出が発生する)

いずれも、本来払う必要のなかったコストです。この項目は上の三つと性質が違って、年あたりの定常コストではなく、重要局面で一気に請求される不定期な支出になります。ですから平時には見えません。しかし3〜5年に一度、大きな経営判断のタイミングで、まとめて請求書が届きます。金額化しにくい一方で、「組織の戦略的自由度そのもの」を削るという意味では、重みとしては最も重い可能性があります。

 

合計して見えてくる「年間人件費の25%」

コスト1〜3の定量化できる部分を足し合わせると、モデルケースでの年間の「見えないコスト」は、約2,500万円強になります。1億円のチームの、約25%です。
参考までに、Stripeが2018年に発表した「Developer Coefficient」というレポートでは、開発者の労働時間のうち約42%が技術的負債やbad code対応に費やされているというデータが示されています。今回試算した「25%」は、そのうちドキュメント起因の部分だけを切り出した数字なので、業界調査と並べるとむしろ控えめな見積もりに収まっています。
この数字を、額面通りに受け取ってほしいわけではありません。前提を少し動かせば、1,500万円にも3,500万円にもなります。大事なのは、桁感です。1億円のチームで毎年数千万円、10億円規模の開発組織なら数億円——この桁のお金が、請求書の届かない形で見えないまま溶けている可能性がある。その構造を、経営判断の解像度に入れておくかどうか。そこにこの試算の意味があると、私は思っています。
もう一つ、AIコーディング時代の文脈でこの数字を見直してみてください。コードが書かれる速度が上がれば、説明されていないコードの量が増えます。コスト1とコスト2は、コードベースの大きさと複雑さに比例します。つまり、AIによって開発スピードが上がるほど、この見えないコストのベースが膨らむ方向に働くわけです。生産性の恩恵を受けながら、維持コストの膨張も同時に進行している——という構図が、今多くの現場で起きていると考えています。AIが10倍速くコードを書く世界で、ドキュメントが「実装速度との乖離」によってどのように見えなくなっていくのかについては、今後の記事で改めて掘り下げていく予定です。
経営の現場では、数字で語れないものは議題になりません。「なんとなく技術的負債が重い」という感覚は、予算会議ではほぼ無視されます。でも「年間2,500万円の見えない支出がある」と言えば、話は動き始めます。私自身、この試算をやってみて一番感じたのは、数字の精度よりも、議論のスタートラインを作ることの価値でした。大事なのは、ご自身のチームで同じ分解をやってみること——コスト1〜3の枠組みに、自社の稼働時間・人数・単価を入れ込んでみることです。出た数字は、たぶん想像より大きいはずです。

 

まとめ

ドキュメントのないシステムの維持コストは、既存の開発工数に溶け込んで観測されません。エンジニア10人・年間人件費1億円のモデルケースで試算すると、コード読解・オンボーディング・障害対応で年間約2,500万円——人件費の約25%が「見えないコスト」として消えている可能性があります。さらに不定期に請求される「意思決定の遅延」が、組織の戦略的自由度を削ります。AIコーディングで実装が加速するほど、このベースは膨らみます。

あなたのチームの年間人件費のうち、「コードを読み解く時間」に溶けているのは、何パーセントだと思いますか? その数字を出すための材料は、社内のどこにあるでしょうか?

次回は、コストの話のもう一つの定番——「仕様書を書く時間がない」という現場の定型句を、本当にそうなのか、時間の使い方の側から分解していきます。