開発ベンダーが新機能を納品しました。動いています。ボタンを押せば反応し、データは保存され、ページは読み込まれる。あなたは承認のサインをします。
3ヶ月後、シンプルなはずの新機能が予想の4倍の時間を要しています。ある箇所のバグが、まったく関係のない別の機能を壊しています。ベンダーのリード開発者は「技術的に複雑な問題」と説明しますが、あなたにはそれを確認する術がありません。
これが、技術的背景を持たないファウンダーの盲点です。そしてそれは実際のお金を失うことを意味します。
「動いている」はクオリティの指標ではありません。 それは最低限の基準です。コードベースは表面上は完璧に機能しながら、その内部に何年分もの問題を蓄積させることができます。重複したロジック、テストなし、ドキュメントなし、誰も更新しない依存関係、明日退職するかもしれない特定の一人に依存したデプロイプロセス——。
コードを読めなくても、これらの問題が迫っていることに気づくことはできます。どこを見ればよいかさえ知っていれば。
本当に重要な代替指標
技術的な品質は、作るものだけでなく、チームの行動にも痕跡を残します。以下の点に注目してください。
デプロイについてどう話しているか
健全なチームは頻繁に、そして低ストレスでデプロイします。月に一度しかデプロイしない、リリースのたびにリスクを感じる、あるいは「全員が揃う金曜日しかデプロイできない」というベンダーは要注意です。頻繁で自動化された、緊張感のないデプロイは、しっかりした構造のコードと堅固なプロセスの表れです。
質問してみてください：「どのくらいの頻度でデプロイしますか？そのプロセスはどのようなものですか？」
プルリクエストはレビューされているか、それともそのままマージされているか
コードレビューは、問題が技術的負債になる前に発見する手段です。開発者同士がコードをレビューしてからプロダクションに反映しているかを確認してください。「小さなチームだからそのままマージしている」という答えなら、ソフトウェア開発で最も重要な品質ゲートを省略しているプロセスを見ていることになります。
バグにどう対処しているか
どんなコードベースにもバグはあります。重要なのは、その周辺にあるシステムです。ベンダーはバグを体系的に追跡していますか？根本原因を調査しているか、それとも症状を修正しているだけか？ログイン問題、決済エラー、データの不整合など、同じカテゴリのバグを繰り返し修正しているチームは、根本のコードが壊れやすすぎて正しく対処できないため、症状の修正にとどまっている可能性があります。
コードベースについてどのように説明するか
自信を持ち、誠実なチームは、アーキテクチャ上の決断を平易な言葉で説明できます。「後でXを変更しやすくするためにこのアプローチを選びました」「ここは古い部分でリファクタリングを考えています」といった言い方をするはずです。曖昧な答え、過剰な専門用語、質問への防衛的な反応は、自分たちが作ったものを十分に理解していないか、あなたに理解させたくないチームのサインです。
ベンダーへの質問
技術的な知識がなくても、これらの質問はできます。必要なのは質問する勇気と、答えをじっくり聞く忍耐力だけです。
「リード開発者が退職したらどうなりますか？」
正直な答えは「大したことはない。なぜなら知識はコードとドキュメントにあって、特定の人の頭の中にあるわけではないから」です。曖昧な答えや気まずい沈黙があるなら、あなたが思っている以上に特定の個人に依存しているかもしれません。
「意思決定はどのようにドキュメント化していますか？」
優れたチームは、なぜそのように構築したかの記録を残しています——アーキテクチャ決定記録、コードコメント、社内Wiki。ベンダーがそのドキュメントの所在を示せないなら、毎日見えない負債が積み上がっています。
「仕様から本番リリースまでのプロセスを説明してもらえますか？」
明確で反復可能なプロセスを聞き取ってください：調査、計画、設計、開発、レビュー、テスト、ステージング、本番。このチェーンのギャップ——特にテストとレビュー周辺——が品質問題の入口になります。
「テストカバレッジはどの程度ですか？」
技術的な意味を理解する必要はありません。ただ、それが存在するかどうか、そしてチームがそれを重視しているかを知ればよいのです。この質問をされたことがなく、即答できないチームは、品質について真剣に考えていなかったということです。
「このコードベースで一番誇れない部分はどこですか？」
経験豊富な開発者なら誰でも、この質問に正直に答えられます。「すべて問題ない」と言うチームは、自分の仕事を批判的に考えていないか、あなたに正直でないかのどちらかです。
関係性の中の警戒サイン
コード品質の問題は、ソフトウェアに現れる前に、チームの行動パターンとして現れることが多いです。
すべてが緊急になる。 ベンダーがすべてのリクエストを急ぎ仕事として扱うなら、シンプルなタスクが本当に長い時間を要するほど絡み合ったコードベースで作業している可能性があります。そして、なぜ時間がかかるのかを説明するのではなく、すべてを急いでこなすことで補おうとしているのかもしれません。
要件を断らない。 優れた開発チームは確認の質問をし、意味をなさない機能リクエストや、システムの構造と矛盾する要求を時には断ります。何でも「はい」と言うチームは、いつ「いいえ」と言うべきかを知るほどシステムを理解していないか、長期的な品質より短期的な売上を優先しているかもしれません。
着手前に質問しない。 優れた開発は理解から始まります。ベンダーが仕様書を受け取ってから黙り込み、完成した機能を持って現れるなら、認識のズレを防ぐ確認ステップを省いています——そして誰も立ち止まって考えなかったときに書かれる、雑なコードの典型です。
遅延は常に「技術的な複雑さ」のせいにされる。 本当に複雑なものはあります。しかし、「技術的に複雑」が具体的な説明なしに遅延の繰り返しの理由になっているなら、問い直す価値があります。何が複雑なのかを説明してもらいましょう。明確に言えないなら、複雑さが本当の問題ではないかもしれません。
コストの比較で問題を具体的に
適切な技術監査——独立したシニア開発者を雇ってコードベースをレビューし、レポートを作成してもらう——は、スコープとレビュアーのレートによって異なりますが、通常15万円から70万円程度です。数日から1週間かかります。
品質の低いコードベースを引き継ぐコスト：
- 中規模アプリケーションの完全な書き直し：700万円〜3,000万円以上
- 蓄積する技術的負債による納期の遅れ：数ヶ月
- エンジニアがそのシステムで働きたくない場合の採用コスト：現実的な問題
- システムが脆弱すぎて拡張できない間に失うビジネス機会：計り知れない
技術監査は安価な保険です。3ヶ月間の協業で何かおかしいと感じたなら、12ヶ月経って方向転換できないほど深みにはまる前にやっておく価値があります。
そして最も重要なこと：もしベンダーが独立した監査に抵抗するなら、それ自体がすでに答えです。
あなたが実際にコントロールできること
コードは読めなくても、賢い質問をすること、チームの行動を観察すること、自分に見える形でのプロセスを要求すること、そして必要なときに独立した視点を持ち込むことはできます。
優れたソフトウェアを手にする非技術系ファウンダーは、コーディングを学んだ人ではありません。良い仕事をしているから自信に満ちているチームと、あなたが十分に知らないから質問されないだけのチームの違いを見抜くことを学んだ人たちです。
その見極め力は、どんな技術スキルよりも価値があります。
