CTO不在のスタートアップを長年支えて気づいた、技術的負債の“本当の怖さ”

守秘義務があるため詳細はふせるが、あるスタートアップに“開発を手伝ってほしい”と声がかかったことがある。

CTOはいない。創業者は非エンジニア。開発は外部のエンジニアに委託していた。

プロダクトは動いていた。ユーザーも増えていた。しかし、アーキテクチャ的には問題を抱えていた。

— 不必要にサーバーがGoogle CloudとAWSの両方に分散している。

— FirebaseとRDB（リレーショナルデータベース）に同じデータが重複して保存されている。

“動いている”と“健全である”はまったく違う。それを経営者に伝える人が、この会社にはいなかった。

僕はそこから、このスタートアップの技術基盤を支え続けることになる。最初はコードを書く役割だったが、気づけば技術選定やアーキテクチャ設計まで担っていた。

この記事では、そういった状況に置かれた複数の現場で目の当たりにした“技術的負債”の怖さを、経営者の方に向けて書く。技術用語はできるだけ使わない。使う場合は必ず翻訳する。

なぜなら、技術的負債の本当の怖さは“経営者に見えない”ことだからだ。

技術的負債とは何か — 経営者のための3分解説

金融の“負債”と同じ仕組み

技術的負債という言葉は、金融の負債になぞらえて生まれた概念だ。

ソフトウェア開発では、納期やコストを優先して“とりあえず動く”コードを書くことがある。これ自体は悪いことではない。事業のスピードを優先する判断は、スタートアップでは当然のことだ。

問題は、その“とりあえず”を放置し続けたときに起きる。

• 元本 = 動くけれど構造に問題があるコード
• 利息 = 毎月じわじわ増える開発コストと速度低下
• 返済 = コードの構造を整理し直す作業（リファクタリング）

金融の負債と同じで、元本を放置すると利息が膨らみ続ける。最初は月に数時間の無駄だったものが、1年後には開発工数の半分を食い潰すようになる。

なぜエンジニアに説明されても分からないのか

エンジニアは技術用語で説明する。“リファクタリングが必要です”“マイクロサービスに分割すべきです”“テストカバレッジが低すぎます”。

経営者は経営用語で判断する。“いくらかかるの？”“売上に影響あるの？”“今やらないとどうなるの？”

この2つの言語を翻訳する人が、CTOだ。

CTOがいない会社では、エンジニアの危機感が経営者に伝わらない。経営者の優先順位がエンジニアに伝わらない。両者の間にコミュニケーションの断絶が生まれる。

技術的負債の怖さは“見えない”こと

売上は数字で見える。在庫も見える。人件費も見える。

技術的負債だけは、専門家でないと見えない。

会計なら決算書を見れば健全性が分かる。法務なら契約書を読めばリスクが分かる。しかし技術的負債は、コードを読める人間が中に入らない限り、その存在すら認識できない。

だから気づいたときには“手遅れ”になりやすい。そして、CTO不在の会社ほどこの罠にはまりやすい。

CTO不在の会社で技術的負債が“静かに”膨らむ3つの構造

構造1: 誰もコードを“評価”できない

CTOがいる会社では、コードレビューという仕組みがある。エンジニアが書いたコードを別のエンジニア（多くはCTOやリードエンジニア）がチェックし、品質を担保する。

CTOがいない会社では、この仕組みがない。“動く＝正しい”という判断しかできない。

冒頭で書いたスタートアップがまさにそうだった。

サーバーインフラがGoogle CloudとAWSの両方に分散していた。Google Cloudだけで十分なのに、だ。最初に関わったエンジニアがAWSで一部を構築し、その後に別のエンジニアがGoogle Cloudのサービスを使い始めた。

誰も“統一しよう”と言わなかった。なぜなら、それを判断できる立場の人がいなかったからだ。

結果として、2つのクラウドプラットフォームの運用コストと学習コストが二重にかかり続けた。月額のインフラ費用だけでなく、エンジニアが両方の仕様を把握する時間的コストも馬鹿にならない。

これは“技術選定を統一する司令塔がいない”ことの典型的な帰結だ。

構造2: “動いてるからOK”で判断してしまう

経営者にとって“動いている＝問題ない”は自然な判断だ。むしろ、動いているものに余計な手を加えるほうがリスクに感じるだろう。

しかし技術の世界では“動いているが、次の変更で壊れる”という状態がある。

同じスタートアップで、FirebaseとRDB（リレーショナルデータベース）に同じデータが重複して保存されている問題があった。

Firebaseはリアルタイム同期に強いサービスで、RDBは構造化されたデータの管理に適している。本来は役割を分けて使うべきものだが、開発の過程で同じ情報が両方に書き込まれるようになっていた。

片方を更新しても、もう片方は古いまま。ユーザーには見えない不整合が、静かに蓄積していた。

ある日、データの不整合がユーザーの目に触れる形で顕在化する。“前に保存した情報が消えている”“画面によって表示される内容が違う”。こうなってから対処すると、修正コストは予防コストの何倍にもなる。

これが“動いている”と“正しく動いている”の違いだ。そしてこの違いは、技術者でなければ見分けられない。

構造3: 外注先にとって負債の指摘はインセンティブがない

これは構造的な問題だ。

外注先の仕事は“依頼された機能を作る”ことだ。“この設計は将来問題になります”と指摘すれば、工数が増える。工数が増えれば見積もりが高くなる。見積もりが高くなれば、失注するリスクがある。

だから合理的な外注先ほど、既存の問題には触れず、依頼された範囲だけを手早く仕上げる。

悪意があるわけではない。ビジネスとして当然の振る舞いだ。しかし結果として、短期的に動くコードが積み上がり、技術的負債は誰にも指摘されないまま膨らんでいく。

CTOがいれば“ここは今は負債を許容する”“ここは今のうちに返済する”という判断ができる。その判断をする人がいないまま開発を続けることは、家計簿をつけずにクレジットカードを使い続けるのに似ている。

技術的負債が“爆発”するとき — 実際に何が起きるか

技術的負債は、ある日突然“爆発”する。正確に言えば、負債が一定量を超えると、あらゆる開発が急激に遅くなる瞬間が来る。

新機能の追加に3倍の時間がかかるようになる

“前は1ヶ月で作れた機能なのに、今回は同じくらいの規模なのに3ヶ月かかると言われた”

経営者がエンジニアに不信感を持つ瞬間だ。

しかし多くの場合、エンジニアはサボっているのではない。既存のコードが複雑に絡み合い、新しい機能を“既存の機能を壊さないように”追加するために、膨大な時間がかかっているのだ。

地盤が傾いた建物に増築するようなものだと思ってほしい。建物自体は建てられる。しかし傾きを考慮した設計、補強、確認作業に、通常の何倍もの手間がかかる。

この状態を放置すると、経営者は“開発チームの生産性が低い”と判断し、エンジニアは“経営者が技術を理解してくれない”と感じる。信頼関係が壊れ、組織として機能しなくなる。

エンジニアが“このプロジェクトはやりたくない”と離れていく

優秀なエンジニアほど、技術的負債の大きいコードベースを嫌う。

なぜか。負債が大きいコードで開発すると、自分のスキルが伸びない。バグの原因調査に時間を取られ、創造的な仕事ができない。履歴書に書ける実績も作りにくい。

採用面接を通過したエンジニアが、入社前にコードを見て辞退するケースは珍しくない。

そうなると、残るのは“このコードでも気にしない”エンジニアか、“他に選択肢がない”エンジニアだけになる。人が離れるほど属人化が進み、属人化が進むほど負債が溜まる。典型的な悪循環だ。

ある日突然、セキュリティインシデントが起きる

技術的負債の中でも特に危険なのが、セキュリティに関する負債だ。

ソフトウェアは外部のライブラリ（部品）を組み合わせて作られている。これらのライブラリには定期的にセキュリティアップデートが提供される。

しかし技術的負債が溜まった状態では、ライブラリをアップデートすると既存の機能が壊れるリスクがある。だから“今は触らないでおこう”となる。

こうして脆弱性が放置され、ある日、外部から攻撃を受ける。個人情報の漏洩、サービスの停止、顧客への謝罪と補償。事後対応のコストは、予防コストの10倍以上になることが多い。

あなたの会社は大丈夫？ — 技術的負債チェックリスト

技術の知識がなくても判断できる項目だけを選んだ。自社の状況と照らし合わせてほしい。

1. 同じ機能の改修を2回以上、外注に出したことがある
2. “この機能を変えると他の機能が壊れるかもしれない”と言われたことがある
3. 開発会社を変えようとしたら“このコードは引き継げない”と言われた
4. エンジニアから“リファクタリングしたい”と言われたが、何のことか分からなかった
5. 新機能のリリースが、当初の見積もりより常に遅れる
6. テスト（自動テスト）があるかどうか、把握していない
7. サーバーやインフラの構成図を見たことがない
8. セキュリティアップデートが定期的に行われているか、把握していない
9. 開発チームの中に、コード全体を把握している人がいない（または1人だけ）
10. 技術的な意思決定を、外注先や特定のエンジニア1人に任せきりにしている

判定の目安：

• 0〜2個： 現時点では健全。ただし定期的なチェックを推奨する
• 3〜4個： 注意ゾーン。技術顧問やコードレビューの導入を検討すべき段階
• 5個以上： 危険ゾーン。技術的負債が事業リスクになっている可能性が高い

3個以上該当した方は、この先を特に注意して読んでほしい。

技術的負債を“返済”する — 経営者ができる3つのアクション

アクション1: 技術の“健康診断”を受ける

人間の体と同じで、まず現状を知ることが第一歩だ。

コードレビューや技術監査を外部の専門家に依頼する。“今のコードにどんな問題があるか”“どこから手をつけるべきか”を可視化してもらう。

費用は規模によるが、数日〜数週間の調査で数十万円程度が目安だ。

重要なのは“問題が見つかること自体は悪いことではない”という認識だ。健康診断で異常値が出たからといって、それまでの生活が無駄だったわけではない。今知れたことが価値なのだ。

アクション2: 開発予算の20%を“負債返済枠”として確保する

Googleほどの企業でさえ、開発リソースの一定割合を技術的負債の返済に充てている。

目安として“新機能開発を8割、負債返済を2割”というルールを設けることをお勧めする。

“返済”とは具体的に何をするのか。コードの構造を整理する。不要な重複を解消する。テストを追加する。古いライブラリを更新する。地味な作業だが、これをやらないと利息が膨らみ続ける。

経営者がこのルールを設定すること自体が、技術チームへの強いメッセージになる。“技術の健全性を経営として重視している”という姿勢は、エンジニアの信頼を得る上でも効果が大きい。

アクション3: 技術の“目利き”を味方につける

フルタイムのCTOを採用するのが理想だが、スタートアップの初期段階では難しいことが多い。優秀なCTOの採用コストは高く、そもそも市場にいる人数が限られている。

代替手段はいくつかある。

• 技術顧問（月数時間〜）： 定期的に技術の方向性をチェックしてもらう。コストを抑えつつ「技術の目」を入れられる
• CTO代行（月数日〜）： より深く関与し、技術選定やチーム構築まで担う。フルタイムCTOの代替として機能する
• 内製化支援： 将来的にCTOを採用するまでの橋渡しとして、技術チームの立ち上げを外部から支援する

どの形態を選ぶにしても、重要なのは“経営の言葉で技術を翻訳してくれる人”であることだ。技術力だけが高くても、経営者に伝わらなければ意味がない。

なぜ僕がこの事業を始めたか

ニャンパス株式会社を経営していた中で、CTOのいないスタートアップを外から支え続けた。

最初はただコードを書く役割だった。しかし気づけば技術選定、アーキテクチャ設計、エンジニアの採用面接のサポートまで担うようになっていた。

その間に何度も思ったことがある。

“もっと早い段階で関われていたら、この負債は生まれなかった”

Google CloudとAWSの混在も、FirebaseとRDBのデータ重複も、最初の設計段階で技術の方針を決められる人がいれば防げた問題だった。対処するのに何ヶ月もかかった問題が、最初の1週間の判断で回避できたはずだった。

技術的負債は、技術の問題ではない。

“技術と経営の間に翻訳者がいない”という、組織の問題だ。

だから僕は、その翻訳者になる事業を始めた。

CTO不在のスタートアップや中小企業が、技術的負債に気づかないまま事業リスクを抱え込むのを防ぎたい。技術がわからなくても、正しい判断ができる状態を作りたい。

もし“うちの開発、大丈夫かな？”と少しでも思ったなら、それは健全な危機感だ。

その感覚を大事にしてほしい。

技術の“健康診断”、受けてみませんか？

Sasaraでは、CTO不在のスタートアップ・中小企業向けに、技術監査・CTO代行サービスを提供しています。“うちの開発、大丈夫かな？”と思ったら、まずはお気軽にご相談ください。

→ お問い合わせはこちら