建築的思考でシステムを設計する
「開発が進むほど、なぜか遅くなっていく」その原因とは
「最初はスピーディーに開発が進んでいたのに、最近はちょっとした機能追加にも時間がかかる」
「エンジニアから『この部分は改修が難しい』と言われることが増えた」
「バグ修正をしたら、別の場所で新しいバグが発生した」
「新しく入ったエンジニアが、コードを理解するのに1ヶ月以上かかっている」
こんな状況に心当たりはありませんか？
これらはすべて、**「技術的負債」**と呼ばれる問題の症状です。
技術的負債とは、短期的な開発スピードを優先した結果、コードベースに蓄積される「借金」のようなもの。
放置すればするほど、利子が膨らんでいきます。
そして最悪の場合、「この機能を追加するには、システム全体を作り直す必要があります」と告げられることになります。
数百万円、場合によっては数千万円の追加投資が必要になるケースも珍しくありません。
でも、この問題は防げます。
建築家が建物を設計するように、ソフトウェアも「構造」から正しく設計すれば、技術的負債を最小限に抑えられるのです。
同じ苦しみを経験したスタートアップは、想像以上に多い
「うちだけじゃなかったんだ…」
技術的負債の問題に気づいたとき、多くの創業者がそう感じます。
実は、スタートアップの約70%が、何らかの形で技術的負債に苦しんでいると言われています。
特に非エンジニア創業者の場合、問題が表面化するまで気づけないことが多いのです。
「エンジニアに任せていたら、いつの間にかカオスになっていた」
「開発会社を変えたら『このコードでは保守できない』と言われた」
「追加開発の見積もりが、想定の3倍だった」
これらは「あるある」です。
あなただけが特別に運が悪いわけではありません。
問題は、設計思想なしにコードを書き始めてしまったことにあります。
建物を建てるとき、設計図なしにいきなりレンガを積み始める人はいません。
でもソフトウェア開発では、「とりあえず動くものを作ろう」という姿勢で始めてしまうことが多いのです。
その結果、構造的な欠陥を抱えたまま成長してしまう。
後から修正しようとしても、すでに多くの機能がその欠陥に依存しているため、簡単には直せない。
これが技術的負債の本質です。
この記事でわかること：建築的思考でコードベースを設計する方法
建築的思考でシステム設計
この記事では、建築的思考をソフトウェア設計に応用する方法を解説します。
読み終わる頃には、以下のことがわかります：
- なぜ「とりあえず動くコード」が危険なのかを理解できる
- 建築と建築の共通点から、良い設計の原則がわかる
- 堅牢なコードベースの3つの柱を知ることができる
- 開発会社やエンジニアに何を求めるべきかが明確になる
- 技術的負債を防ぐチェックリストが手に入る
技術がわからなくても、「良い設計とは何か」を判断する目を養うことができます。
建築とソフトウェア：意外なほど似ている2つの世界
建築家は「見えない部分」にこそこだわる
素晴らしい建物を見たとき、私たちが感動するのは外観のデザインです。
しかし、建築家が最も時間をかけるのは、目に見えない「構造」の設計です。
- 基礎：地震に耐えられるか？地盤沈下しないか？
- 骨組み：荷重を適切に分散できるか？増築に対応できるか？
- 配管・配線：メンテナンスしやすいか？将来の変更に対応できるか？
これらが疎かだと、どんなに外観が美しくても、住めない建物になってしまいます。
ソフトウェアも同じ
ユーザーが目にするのは、画面のデザインや機能です。
しかし、長期的に成功するプロダクトの鍵は、見えない「構造」にあります。
- アーキテクチャ（基礎設計）：システム全体の構造は適切か？
- モジュール設計（骨組み）：機能同士の依存関係は整理されているか？
- データ設計（配管）：データの流れは効率的か？変更に強いか？
これらが適切でないと、表面上は動いていても、内部は崩壊寸前というプロダクトになります。
「設計」と「施工」の違い
建築では、設計と施工は明確に分かれています。
設計図を作ってから、工事が始まる。
当たり前のことですが、ソフトウェアではこれが曖昧になりがちです。
「とりあえず作りながら考えよう」
この姿勢が、後の大きな問題につながります。
もちろん、ソフトウェアは建築より柔軟です。後から変更できます。
しかし、基礎設計を間違えると、変更コストは指数関数的に膨らみます。
だからこそ、最初の段階で建築的思考を持つことが重要なのです。
堅牢なコードベースを作る「3つの柱」
3つの柱
建築的思考に基づいた、堅牢なコードベースの3つの柱を紹介します。
第1の柱：関心の分離（Separation of Concerns）
建築での例：
住宅では、リビング、キッチン、寝室、浴室が明確に分かれています。
キッチンで料理をしていても、寝室の静けさは保たれる。
浴室の湿気が、リビングの家具を傷めることはない。
それぞれの空間が、それぞれの役割に特化しているからです。
ソフトウェアでの適用：
コードベースも同様に、役割ごとに明確に分離すべきです。
- 画面表示を担当する部分（UI / プレゼンテーション層）
- ビジネスロジックを担当する部分（ドメイン層）
- データの保存・取得を担当する部分（データ層）
これらが混在していると、どうなるか？
「ボタンの色を変えただけで、なぜかデータ保存機能がバグった」
こんな不可解な事態が起こります。
分離されていれば、変更の影響範囲は限定的。
ボタンの変更はUI層だけで完結し、他の部分に影響しません。
チェックポイント：
- 画面デザインの変更が、ビジネスロジックに影響しないか？
- データベースを変更しても、画面表示のコードを変える必要がないか？
- 各層が独立してテストできるか？
第2の柱：シンプルさの維持（Simplicity）
建築での例：
「良い設計は、シンプルな設計である」
これは建築の世界で広く共有されている原則です。
複雑な構造は、施工ミスを誘発し、メンテナンスを困難にします。
バルセロナのサグラダ・ファミリアは、あまりに複雑な設計ゆえに、140年以上経っても完成していません。
ソフトウェアでの適用：
ソフトウェアも、シンプルであるほど堅牢です。
- コードの行数が少ない = バグが潜む場所が少ない
- 依存関係が少ない = 変更の影響範囲が小さい
- 理解しやすい = 新しいエンジニアがすぐに貢献できる
「凝ったテクニック」や「高度な抽象化」は、一見すると優れているように見えます。
しかし、理解できない複雑さは、負債でしかありません。
チェックポイント：
- 新しく参加したエンジニアが、1週間以内にコードを理解できるか？
- 各機能が、なぜそうなっているか説明できるか？
- 「これは何のためにあるの？」と聞かれて答えられないコードはないか？
第3の柱：拡張性の確保（Scalability）
建築での例：
優れた建築は、将来の変化を見据えています。
- 家族が増えたときに部屋を追加できる設計
- オフィスなら、組織が成長したときにフロアを増設できる設計
- 配管や配線に余裕を持たせ、将来の設備追加に備える
「今」だけでなく「将来」を考えた設計が、長く使える建物を作ります。
ソフトウェアでの適用：
ソフトウェアも、成長を前提に設計すべきです。
- ユーザー数が10倍になっても動作するか？
- 新機能を追加するとき、既存コードをどれだけ変更する必要があるか？
- 外部サービス（決済、認証など）を入れ替えられるか？
ただし、過度な拡張性は逆効果です。
「将来使うかもしれない」という理由で複雑な設計をすると、第2の柱（シンプルさ）を損ないます。
必要になったときに拡張できる余地を残す、というバランスが重要です。
チェックポイント：
- 現在の10倍のユーザーに対応できる設計になっているか？
- 新機能追加に必要な変更範囲は限定的か？
- 特定の外部サービスに依存しすぎていないか？
よくある「悪い設計」のパターン
パターン1：「神クラス」問題
建築で言えば、1つの部屋にすべての機能を詰め込んだようなもの。
リビングにキッチンも浴室もトイレもベッドもある。
便利そうに見えて、実際は最悪の住環境です。
ソフトウェアでは：
1つのファイル、1つのモジュールに、あらゆる機能が詰め込まれている状態。
- ユーザー登録も、メール送信も、決済処理も、すべて1ヶ所に
- 変更するたびに、関係ない機能が壊れる
- コードが数千行、数万行に膨れ上がる
解決策：
- 機能ごとにファイルを分割する
- 1つのモジュールは1つの責任だけを持つ
- 「この部分は何をするところ？」と一言で説明できる粒度に
パターン2：「スパゲッティコード」問題
建築で言えば、配線や配管が壁の中で絡まりあっている状態。
水道管と電気配線が交差し、一方を修理しようとすると他方を傷つける。
ソフトウェアでは：
モジュール同士が複雑に依存しあい、どこから手をつけていいかわからない状態。
- Aを変更するとBが壊れ、Bを直すとCが壊れる
- 影響範囲が予測できない
- 「触らないのが一番」という雰囲気が蔓延
解決策：
- 依存関係を一方向にする（AはBを知っているが、BはAを知らない）
- インターフェース（契約）を通じて連携する
- 依存関係を図に描いて、循環がないか確認する
パターン3：「コピペ地獄」問題
建築で言えば、同じ設計の部屋を毎回ゼロから作り直しているようなもの。
標準化された設計図を使わず、毎回職人が独自に作業する。
品質にばらつきが出て、メンテナンスも困難。
ソフトウェアでは：
似たような処理が、コードのあちこちにコピペされている状態。
- 修正が必要になったとき、すべての箇所を変更する必要がある
- 漏れがあると、動作に不整合が生じる
- 「どこかで見たコード」が大量にある
解決策：
- 共通処理は関数やモジュールにまとめる
- 「2回以上書くコードは共通化を検討する」というルール
- ただし、過度な共通化は避ける（微妙に違う処理を無理に共通化しない）
非エンジニアでもできる「設計品質」のチェック方法
「技術がわからないのに、設計の良し悪しを判断できるの？」
できます。以下の質問を、エンジニアや開発会社に投げかけてみてください。
質問1：「新しいエンジニアが参加したら、どれくらいで戦力になれますか？」
良い回答： 「ドキュメントを読んで、1〜2週間で基本的な開発ができるようになります」
危険な回答： 「うーん、このコードは複雑なので、1〜2ヶ月は見てもらわないと…」
→ コードベースが複雑すぎるサインです。
質問2：「○○機能を追加するには、どの部分を変更しますか？」
良い回答： 「この機能はこのモジュールが担当しているので、主にここを変更します」
危険な回答： 「いろんなところに影響するので、一概には言えないですね…」
→ 関心の分離ができていないサインです。
質問3：「データベースを変更することになったら、どれくらい大変ですか？」
良い回答： 「データアクセス層を変更すれば対応できます。ビジネスロジックには影響しません」
危険な回答： 「かなり大変ですね。コード全体に影響があります」
→ 層の分離ができていないサインです。
質問4：「テストはどのように行っていますか？」
良い回答： 「ユニットテストでモジュール単位、統合テストで全体の動作を確認しています」
危険な回答： 「手動でテストしています」または「テストは書いていません」
→ 品質管理の仕組みが整っていないサインです。
質問5：「技術的負債は、どのように管理していますか？」
良い回答： 「定期的にリファクタリングの時間を確保しています」「負債リストを管理しています」
危険な回答： 「技術的負債？特に意識していないですね…」
→ 負債が蓄積し続けているサインです。
開発会社・エンジニアに伝えるべきこと
設計品質を高めるために、発注時に以下を伝えましょう。
1. 長期的な視点を共有する
「このプロダクトは、5年、10年と成長させていく予定です」
「今だけでなく、将来の拡張性も考慮してください」
短期的なスピードだけを求めると、「動けばいい」という設計になりがちです。
2. 設計ドキュメントを求める
「実装前に、アーキテクチャ設計書を見せてください」
「主要なモジュールの役割と、依存関係を図で示してください」
ドキュメントがあると、非エンジニアでも構造を理解できます。
3. リファクタリング時間を確保する
「新機能開発だけでなく、コード品質を維持する時間も見積もってください」
「スプリントの20%は、技術的負債の返済に使ってOKです」
負債返済の時間がないと、負債は永遠に増え続けます。
4. コードレビューを義務化する
「すべてのコードは、別のエンジニアがレビューしてからマージしてください」
複数の目でチェックすることで、設計の一貫性が保たれます。
「美しいコードベース」がもたらす5つのメリット
メリット1：開発速度が落ちない
構造が整理されているので、新機能の追加がスムーズ。
「どこを変更すればいいか」がすぐにわかるため、開発速度が持続します。
メリット2：バグが減る
関心が分離されているので、変更の影響範囲が限定的。
「Aを直したらBが壊れた」という問題が起きにくくなります。
メリット3：エンジニアの離職リスクが下がる
美しいコードベースは、エンジニアにとって働きやすい環境。
逆に、カオスなコードベースは、優秀なエンジニアが逃げていきます。
メリット4：引き継ぎがスムーズ
開発会社を変えることになっても、新しいチームがすぐに理解できます。
ベンダーロックインを防ぐ効果もあります。
メリット5：事業売却時の評価が上がる
M&Aの際、買収側は技術デューデリジェンスを行います。
コードベースの品質が高ければ、事業価値の評価が上がります。
こんな方に特におすすめです
以下に当てはまる方は、今すぐコードベースの健康状態をチェックしてください：
- 開発が進むにつれて、スピードが落ちていると感じている方
- 「改修が難しい」「影響範囲が広い」とエンジニアに言われることが増えた方
- バグ修正が新しいバグを生む、というサイクルに陥っている方
- エンジニアの入れ替わりが激しく、引き継ぎに苦労している方
- これから本格的に開発を始める、非エンジニア起業家の方
- 開発会社の提案が、長期的な視点を持っているか確認したい方
今すぐチェックすべき理由：
技術的負債は、時間が経つほど返済コストが膨らみます。
今日のちょっとした問題が、1年後には数百万円の大工事になることも。
早期発見・早期対応が、最もコスト効率の良い解決策です。
まとめ：建築的思考で、長く成長できるプロダクトを作る
まとめ
この記事のポイントをおさらいします。
重要なポイント
- 技術的負債は、すべてのスタートアップが直面するリスク
- 建築的思考で「見えない構造」を設計することが重要
- 堅牢なコードベースの3つの柱：分離・シンプル・拡張性
- 非エンジニアでも、適切な質問で設計品質を確認できる
- 美しいコードベースは、開発速度・品質・事業価値すべてを高める
3つの柱を振り返る
- 関心の分離：役割ごとにコードを分け、変更の影響を限定する
- シンプルさ：複雑さは敵。理解しやすいコードが最強
- 拡張性：将来の成長に対応できる設計を（ただし過度にならない）
今日からできるアクション
- エンジニアに「新人が何週間で戦力化できるか」を聞いてみる
- アーキテクチャ設計書があるか確認する
- 定期的なリファクタリング時間が確保されているか確認する
- 技術的負債リストが管理されているか確認する
堅牢で美しいコードベースは、一朝一夕には作れません。
でも、正しい知識と適切なパートナーがいれば、必ず実現できます。
技術がわからなくても、「良い設計とは何か」を理解することは可能です。
この記事が、その第一歩になれば幸いです。
プロダクトの「見えない部分」に不安を感じている方へ
- 自社のコードベースが健全かどうか、判断できない
- 開発が遅くなっている原因が、技術的負債なのか確かめたい
- 新しい開発会社に引き継ぎたいが、コードの状態が心配
- これから開発を始めるにあたり、正しい設計で進めたい
一つでも当てはまるなら、専門家の力を借りてみませんか？
atelier binary（アトリエ・バイナリ）では、「技術がわからないことで挑戦を諦める非エンジニア起業家をゼロにする」というビジョンのもと、コードベースの健康診断から、適切な設計方針のアドバイスまで、非エンジニア創業者が技術面で正しい判断ができるようサポートしています。
建築家が建物の構造をチェックするように、あなたのプロダクトの「見えない部分」を診断します。
30分の無料相談で、現状の課題と改善の方向性についてフィードバックをお伝えします。
