AI時代に学ぶべき、非エンジニアのための「アーキテクチャ」入門

なぜ今、非エンジニアこそ「アーキテクチャ」を学ぶべきなのか

AI の登場で、ソフトウェアを「作る」コストはここ1〜2年で一気に下がりました。Claude Code や Codex、Cursor のようなツールを使えば、エンジニアでなくてもプロトタイプはそれっぽく動かせる。経営者やプロダクトマネージャーが自分でプロダクトの試作品を組み上げる、ということも普通に起きています。

ただ、ここで見落とされがちなのは、「作るコスト」は下がったけれど、「動いているものを動かすコスト」はまったく下がっていないということです。

AIに任せて「とりあえず作っちゃう」までは速くなった。でも、本番で動いているプロダクトを少し変えるとき、ユーザーがすでに使っているデータを移し替えるとき、外部サービスの連携を組み直すとき。そこにかかる労力は、AIが登場する前と何ひとつ変わっていません。むしろ、最初の作りが雑だった分だけ、あとから直すコストが跳ね上がるケースが増えています。

この「あとから動かしにくさ」を決めているのが、アーキテクチャです。

エンジニアでない人にとって、アーキテクチャは「エンジニアが勝手に決める専門領域」に見えがちです。でも、AI で誰でもプロダクトを作れる時代になったからこそ、非エンジニアでも「将来どこを動かしにくくなるのか」を判断できる感覚を持っておく必要があります。判断できないと、エンジニアに「これだけ追加して」と気軽に頼んで、見積もりが想定外に跳ねて初めて「なんでこんなに？」となる。

この記事では、駅の工事の話とお店の話を例にしながら、非エンジニアの方が「アーキテクチャって、要するにどういう話なのか」を直感的につかめるように書いています。専門用語をできるだけ使わずに説明するようにします。

まずはクイズから

いきなりですが、クイズです。

選択肢は3つ。

• A: 50億円（新駅の3分の1くらい）

• B: 150億円（新駅とだいたい同じ）

• C: 290億円（新駅の1.5倍）

正解は C：290億円 です。

ゼロから新しい駅をまるごと建てる工事よりも、すでにある駅をたった130メートル移動させるほうが、約100億円も高くついている。

「なんで？」と思うかもしれません。

ただ動かすだけなのに。新しく作るよりも、既存のものをちょっとずらすほうが安く済みそうな気がしますよね。

でも実際は逆なんです。動いているものを動かすのは、新しく作るより圧倒的に大変で、お金もかかる。これがソフトウェア開発でもまったく同じ構造で起きている、というのが今日お伝えしたい話です。

なぜ銀座線渋谷駅の移動はそんなに高いのか

銀座線渋谷駅は、もともと東急百貨店東横店の3階に駅ホームがあったのを、明治通りの直上まで130メートル動かす工事でした。航空写真で見るとこんな感じです。

たった130メートル。地図で見ると本当にちょっとです。それでも290億円かかった。理由を整理してみます。

• 営業しながら工事しないといけない（電車は毎日走り続けている）

• まわりの建物・線路・道路にぶつからないように設計する必要がある

• 工事できる時間帯が限られる（終電後の数時間だけ、みたいな日も多い）

• 工事中も乗客の安全を守らないといけない

一方、高輪ゲートウェイ駅は新規駅なので、

• 更地に近い場所に好きな形で建てられる

• 営業中の制約がない

• 設計の自由度が高い

つまり「動いているものを止めずに動かす」という条件が、コストを跳ね上げているんです。

そして、この構造はソフトウェア開発でもまったく同じように現れます。

僕がソフトウェアのアーキテクチャとして意識していたこと

ここで一度、ソフトウェアの「アーキテクチャ」という言葉を整理しておきます。

エンジニアじゃない方に説明するとき、僕はよく「家の設計図」に例えます。

家を建てるとき、設計図には何が描かれているでしょうか。

• 部屋の配置

• 柱の位置

• 水道管・ガス管・電気の通り道

• 玄関やトイレの場所

下記は単なる間取り図ですが、実際はミリ単位の設計図が必要になるでしょう。

ソフトウェアにも、まったく同じものがあります。

• データをどこに置くか

• どの機能とどの機能をつなぐか

• 外部のサービスとどう連携するか

• ユーザー情報をどう扱うか

こういう「全体の骨組み」が、ソフトウェアのアーキテクチャです。

そして家の設計図と同じで、一度建ててしまうと、あとから変えるのがとても大変です。

家の配管の話

家を建てるとき、水道管やガス管は基礎工事の段階で通します。壁ができる前、床ができる前に、「どこに水が必要か」「どこにガスが必要か」を決めて、管を埋め込んでおくんです。

この段階で「将来、2階にもトイレをつけるかもしれない」とわかっていれば、配管だけ先に通しておけます。追加コストは数万円程度です。

でも、家が完成してから2階にトイレを増設しようとするとどうなるか。壁を壊して、床を剥がして、配管を通し直して、そしてまた壁と床を元に戻す。数十倍のコストがかかります。

ソフトウェアでもまったく同じことが起きます。

「配管だけ通しておく」という考え方

僕が開発に携わってきた中で、何度もこういう場面がありました。たとえば、メールマガジンの配信基盤を作るケースを考えてみましょう。

最初の要件は「登録してくれたユーザーに週1でメールを送る」というシンプルなものだったとします。送るだけなら、そこまで複雑な仕組みはいりません。

でも、ちょっと先を考えると見えてくることがあります。

• メールを開封した人と、しなかった人がいるはずです

• 開封したけど、本文中のリンクをクリックしなかった人もいるでしょう

• クリックしてサイトには来たけど、すぐ離脱した人もいるかもしれません

• そもそも配信解除した人や、メールが届かなかった人もいます

開封・クリック・配信解除といった行動ログを取れるようにしておけば、あとから「開封してない人には件名を変えて再送する」「クリックしたけど買ってない人には別のオファーを送る」「興味の薄そうなセグメントには配信頻度を落とす」といった施策が簡単にできるようになります。

これが「配管を通しておく」ということです。

行動ログの仕組みを最初から設計に組み込んでおくのは、+数十パーセントの追加コストで済みます。でも、システムが完成してから同じことをやろうとすると、既存の仕組みを壊して作り直す必要が出てきて、数倍以上のコストになってしまいます。

「蛇口はあとからつければいい」

ここで大事なのは、「配管を通す＝全部作る」ではないということです。

配管さえ通しておけば、蛇口をいつつけるかは自由に決められます。キッチンの蛇口は入居前につけるけど、庭の水道は来年でいい。そういう判断ができます。

ソフトウェアでも同じです。行動ログを取る仕組み（配管）は最初から入れておく。でも、そのデータを使って何をするか（蛇口）は、あとから必要に応じて決めればいいんです。

「開封してない人にだけ再送する」という機能は、開封ログさえ取れていれば、蛇口をひねるだけで実現できます。

配管の提案には「ドメインへの関心」が要る

ここで一つ、大事な前提があります。

配管を通す、つまり「将来必要になりそうな仕組みを先に仕込んでおく」には、未来に発生するであろう要求を予測する必要があります。そしてこの予測は、技術の知識だけでは絶対にできません。

メールマガジンの例で言えば、「開封率を計測したくなる」「セグメント別に文面を変えたくなる」「配信頻度を最適化したくなる」というのは、メールマーケティングという領域でよくある打ち手だから出てくる発想です。マーケティングの世界をまったく知らなければ、「メールを送る機能」しか実装の対象になりません。

これは、メールマガジンに限った話ではありません。

• ECなら、カート投入から購入までの離脱がどこで起きるか

• SaaSなら、どの機能を使った人が継続契約するか

• 採用システムなら、応募から面接、入社後のオンボーディングまで何を見たくなるか

その業界・その事業で「次に何をやりたくなるか」を理解していないと、配管をどこに通すべきかが見えないんです。

僕が今までやってきたことは、エンジニアリングの仕事である一方で、半分以上はビジネスとドメインの理解を深める仕事でした。事業のことを知らないエンジニアは、目の前の仕様通りには作れても、「こういう配管も通しておきましょうか」という提案はできません。逆に言えば、ドメインに関心を持って学び続けるエンジニアは、コストの跳ね上がりを未然に防ぐ提案ができます。

「うちのエンジニアは技術はあるけど提案がない」と感じることがあったら、それは技術の問題ではなく、事業のことを話す機会がエンジニアに十分に渡っているかという問題かもしれません。配管の提案は、ドメインへの関心からしか生まれないので。
少し補足すると、配管の提案ができるエンジニアは、「何を作るか（What）」よりも「なぜ作るか（Why）」を先に理解しようとします。Whyがわかっていれば、「だったらこの先こういう機能も欲しくなるはずだから、配管はこっちに通しておこう」という判断ができるのです。逆に、Whyを共有されないまま「これを作ってください」だけを渡されると、目の前の蛇口だけを最短距離でつけて終わってしまう。
このあたりの「WhyをエンジニアにどうWhyとして渡すか」は、それだけで一本の記事になるテーマなので、別記事にまとめてあります。

すでに動いているシステムを変える話

ここまでは、新規で家を建てるときの話でした。

ここからが、いちばん伝えたい話です。

すでに完成して、毎日使われているシステムに対して、あとから大きな変更を入れる場合、コストはさらに跳ね上がります。

新規開発の場合は、最悪まだ作っていないので「壊れるもの」が少ないのですが、すでに本番で動いているシステムは違います。

• 毎日ユーザーが使っている

• 毎日売上が立っている

• 止めると損害が出る

• 既存のデータがすでに大量に溜まっている

• 他のシステムや業務オペレーションともつながっている

つまり、銀座線渋谷駅の移設工事と同じような条件になるんです。

新築 vs リフォーム

少し話を変えまして、新築の家を建てるのと、築35年の家をリフォームするのでは、どちらが大変でしょうか。

「リフォームのほうが安いに決まってる、家を一棟建てるわけじゃないんだから」と思いがちです。でも実際には、規模によってはリフォームのほうが高くつくケースが珍しくありません。

築35年の家のリフォームを想像してみてください。

「キッチンを広くしたい」と頼むだけでは、見積もりは出てきません。リフォーム会社はまず、こんなことを調べる必要があります。

• 壁の中に水道管はどう通っているか

• 電気配線はどうなっているか

• この壁は耐震構造で抜けないのか、抜けるのか

• 床下はどうなっているか

• ガス管はどこを通っているか

この調査だけで数日〜数週間かかります。新築なら、図面通りに作るだけなので、こんな調査は要りません。

そして、いざ壁を壊してみたら、「想定外のところにガス管が通っていた」「柱がここにあるとは思わなかった」「シロアリの被害があった」といった発見が次々と出てきます。そのたびに設計を見直し、見積もりを修正することになります。

下記のベストアンサーを読んでもらえると
より、イメージがつきやすいかと思います。

ソフトウェアの世界でも、まったく同じことが起きます。

何年も動いているシステムには、当時の判断や、特殊な事情で入れた例外処理が積み重なっています。「なぜここがこうなっているのか」を、コードを読んで、関係者に聞いて、データを調べて、ようやく理解できる。この調査だけで、新規開発の半分くらいの工数を使うことも珍しくありません。

なぜ「ふつうのリフォーム」は安いのか

クロスを張り替える、キッチンを入れ替える、トイレを新しいものにする。こうした「ふつうのリフォーム」は、新築よりずっと安く済みます。

理由はシンプルで、家の基盤部分（基礎・柱・梁・主要な配管・耐震構造）に手を入れていないからです。

家の中で、変えやすいものと変えにくいものを分けると、こうなります。

• 変えやすい: クロス、床材、キッチン・トイレなどの設備、照明、ドア

• 変えにくい: 基礎、柱・梁、主要な配管ルート、耐震構造、断熱材

ふつうのリフォームは、変えやすい部分だけを基本的に触っています。基盤に触らないから、安いのです。

ところが

• 旧耐震だから耐震基準を満たすところまで補強したい

• 断熱がほぼ入っていないので断熱材を全部入れ直したい

• 水道管・ガス管・電気配線がすべて劣化しているので総入れ替えしたい

• 間取りを大きく変えたいから柱や壁を抜きたい

これらは全部、基盤の話です。基盤を触ろうとした瞬間、新築より高くつくゾーンに突入しやすくなります。

ソフトウェアでも「基盤を触るかどうか」で景色が変わる

ソフトウェアでも、まったく同じ分かれ目があります。

• 変えやすい： 画面の見た目、ボタンの文言、メールの文面、表示する項目の追加

• 変えにくい： データベースの構造、認証の仕組み、システム間の連携の根っこ、課金の仕組み

「ボタンの色を変える」「メール文面を変える」程度なら、本番システムでも数分から数時間で終わります。これは「クロスを張り替える」と同じ感覚です。

でも、

• ユーザーIDの管理方法を変えたい

• データベースの構造を根本から見直したい

• 課金の仕組みを別のサービスに乗り換えたい

• 認証を別の方式に切り替えたい

これらは全部、ソフトウェアの基盤の話です。一度動き出してから基盤を触ろうとすると、とたんにとても難しくなります。

エンジニアから「これは結構大変です」と言われたとき、それが設備の入れ替えレベルなのか、基盤工事レベルなのかを確認すると、コストの規模感が掴めます。「キッチンの交換ですか？それとも基礎の補強ですか？」と聞いてみるイメージです。

一つの変更が、思わぬ場所まで連鎖する

もう一つ、リフォーム特有の現象があります。

「1階に水回りを増設したい」と頼んだとします。リフォーム会社が調べてみると、こんな話が返ってきたとします。

最初の依頼は「水回りを増やすだけ」だったのに、

• 隣の部屋の床を剥がす作業

• 梁の補修作業

• 工事中の生活動線の確保

• 工期の延長

と、芋づる式に作業が増えていきます。

ソフトウェアでも、まったく同じ連鎖が起きます。

「ある画面に項目を1つ増やしたい」という依頼から始まって、調べてみたら、

• そのデータは別の集計バッチでも使われていて、書き換えると集計が壊れる

• 連動している管理画面のCSV出力フォーマットも変える必要がある

• 過去のデータには新項目がないので、初期値の方針を決めないといけない

• 連携している外部システムにも仕様変更を伝える必要がある

最初の見積もりが「1時間で終わる」だったのに、調べた結果「2週間かかります」になる。これは、エンジニアが盛っているわけではなく、既存システムが既存システム同士でつながっているから、一箇所触ると他の箇所も動かさざるを得ないんです。

新規開発なら、まだなにともつながっていないので、こうした連鎖は起きづらいです。

対応コストは「直接の作業」だけじゃない

リフォームのコストは、解体と新しい部材の取り付けだけでは終わりません。

• 既存の壁紙を剥がす

• 出てきた古い電気配線を整理する

• 抜いた壁の代わりに梁を入れて構造を保つ

• 工事中の生活動線を確保する（住みながらリフォームする場合）

• 工事の前後で家具を動かす

• 近隣への挨拶や音への配慮をする

新築なら、空き地に建てるだけなので、こういう「既存をどかす・守る・つなぎ直す」作業は発生しません。

ソフトウェアの改修も同じで、「直接の作業」の周りに、たくさんの付随コストがぶら下がります。

新規開発なら「設計＋実装＋テスト」でほぼ完了します。でも、既存システムへの追加では、調査・既存への影響対策・データ移行・並行稼働・関係者調整が、それぞれ独立した重いコストとして乗ってきます。

いちばん厄介なのは「見積もりの精度」

そしてここが、経営者、マネージャーにとって本当に困る点です。

新築の見積もりは、比較的精度が高く、坪単価×坪数でだいたい出ます。±10〜20%くらいの誤差で収まります。

一方、リフォームの見積もりは、壁を開けてみないと正確には出せません。

「たぶんこれくらいです、ただし壁を開けて想定外のものが出てきたら追加で◯◯万円かかる可能性があります」と言われてしまうことがほとんどだと思います。

ソフトウェアでも同じです。

• 新規開発: 「3ヶ月でできます」と言って、おおむね3〜4ヶ月で終わる

• 既存システム改修: 「3ヶ月でできるかも、でも調べてみないとわからない、最悪6ヶ月以上」

「最悪6ヶ月って、それじゃ予算が組めない」と思うかもしれません。でも、それが既存システムを動かすときの現実です。

エンジニアが「やってみないとわからない」と言うのは、サボっているのではなく、まじめに見積もろうとするほど、誤差の幅を正直に伝えざるを得ないからです。

目に見える部分は、実はそんなに手間がかかっていない

リフォームでもソフトウェアでも、目に見えるところは、実はそんなに手間がかかっていません。手間がかかっているのは、目に見えない基盤部分のほうです。

家で言えば、

• 見えるところ: クロス、床材、キッチンの天板、ドア、照明

• 見えないところ: 配管、電気配線、断熱材、構造材、基礎

クロスを張り替えるのは数日で終わります。でも、壁の中の配管をやり直すのは、壁を壊すところから始まって、数週間かかります。

ソフトウェアでも、

• 見えるところ: ボタン、画面、メールの文面、表示する数字

• 見えないところ: データベースの構造、認証の仕組み、外部サービスとの連携、データの流れ

ボタンの色を変えるのは1時間で終わります。でも、データベースの構造を変えるのは、影響範囲を全部洗い出してから、数週間〜数ヶ月かかる仕事になる場合のあります。

「見えているもの」を基準にコストを判断すると、本当に手間がかかっている「見えていないもの」を見落とします。

実例： ワインと鍋にネット回線を引こうとしたら20万円超

僕が経営している「ワインと鍋」という飲食店があります。

このお店、実は固定のネット回線が引けていません。日々の決済などはホームルーター回線でやりくりしていて、安定性のために固定回線を引きたい、と思って業者に調査してもらいました。

返ってきた回答が、下記です。

※メンバーシップ加入もしくは購入いただけた方にはモザイクなしで画像を見ることができます。（続きも見れます）

有料部分では下記のようなことが書いてあります。

• 「あとで直せばいいでしょ」が一番高い

• だからこそ「配管の提案」が大事

• 「AIで開発コストが下がるなら、気にしなくていいのでは？」