2025年6月に個人事業主として独立し、2026年1月に初めて確定申告（青色申告）を提出した。
組織を離れてつくづく感じるのは、サラリーマン時代には見えていなかったものが、独立するとよく見えてくるということだ。
会社はエンジニアの給料の「倍」を払っている
個人事業主になると、社会保険料を全額自分で払うことになる。健康保険、年金、それに消費税の申告まで。組織にいたときはほとんど意識していなかったが、これが想像以上に重い負担だ。
一般に、会社は社員に支払う給料の倍近くをさまざまなかたちで負担しているといわれる。月給50万円のエンジニアがいれば、会社の実質的な人件費は100万円前後になる計算だ。健康保険・厚生年金の会社負担分、交通費、福利厚生、オフィスコスト……それらをすべて合算すれば、社員一人を雇うコストがいかに大きいかがわかる。
ソフトウェア開発プロジェクトにエンジニアが10人いれば、それだけで月1,000万円が飛んでいく。1年続ければ1億2,000万円だ。
サラリーマンエンジニアはこの現実をほとんど知らない。自分の給与明細しか見えていないからだ。しかし経営者や独立した事業主の目線で見れば、人件費はプロジェクトコストの大部分を占める最大の変動費である。この非対称な認識が、後述する「なぜ組織はAI活用に遅れるのか」という問題の根っこにある。
ソフトハウスの利益構造はなぜ脆いのか
製造業と比較するとわかりやすい。
製造業は、設計・開発の投資を一度やり切ってしまえば、あとは設計図通りに量産するだけで利益が積み上がる。売れれば売れるほど一製品あたりのコストは下がり、利益率は上がっていく。もちろん、商品に魅力がなければ売れないし、営業も必要だ。しかし「仕組みが動いていれば利益が出る」という構造が製造業には存在する。
ところがソフトハウスは根本的に違う。利益を生み出す源泉はエンジニアそのものであり、エンジニアが手を動かさない限り、何も生まれない。受注が増えれば人を増やすしかなく、人が増えればコミュニケーションコストが増え、むしろ効率が落ちる。製造業のように「黙っていても利益が出る仕組み」が、ソフトハウスには存在しない。
メーカーはこれまで、製品を売ることで得た利益の一部を、新製品の開発費としてソフトハウスに支払うかたちで産業を回してきた。そのほとんどが人件費だ。ソフトハウスにとっても、エンジニアの稼働率こそが売上の源泉であり、人を増やすことが成長の唯一の手段だった。
この構造は長らく変わらなかった。しかしAIの登場によって、その前提が崩れ始めている。
大規模プロジェクトを、今やり直したら
前職では、大規模なクラウドサービスの開発を数年間にわたってPMとしてマネジメントした経験がある。プロジェクトの規模は相当なものであり、外注費の大半がソフトハウスへの人件費だった。
プロジェクトが大きくなるほど、打合せ・仕様確認・修正依頼のラウンドトリップが増える。関わるエンジニアやステークホルダが増えれば増えるほど、コミュニケーションコストが膨らみ、開発効率はどんどん落ちていった。これはソフトウェア開発の構造的な問題であり、当時はそれ以外の選択肢がなかった。
そのプロジェクトを、今のAIを使ってやり直せたなら——開発費は10分の1以下、期間は半分以下にできたと確信している。
これは感覚的な数字ではない。PMとして全工程を見てきたからこそ言える数字だ。もちろん、プロジェクトの規模や性質、ドメインの複雑さによって結果は大きく異なる。しかし少なくとも、コミュニケーションコストが支配的だった開発においては、この肌感覚には根拠がある。
実際、最近、個人事業として、データベース・バックエンド・フロントエンドを連携するWebサービスをClaudeを使って開発した。開発期間は約3週間、Claudeに使った費用は約300ドルだ。想定していた機能はほぼすべて実装できた。
このサービスを外部の開発会社に委託した場合の見積もりをAIに試算させると、「エンジニア1名体制で3〜5ヶ月、費用は約500万円」という答えが返ってきた。コミュニケーションコスト——打合せ・仕様確認・修正依頼のラウンドトリップ——が大きな時間的オーバーヘッドになるからだ。これが外注の現実だ。
ちなみに、WEBシステムのモックアップを作るのに、エンジニア数人で一ヶ月かかっていたものが、今ではAIに何を作りたいかをきちんと説明できれば1時間もかからずに出来上がる。これを実際に体験したとき、「この変化に対応できない組織は10年後に競争に負ける」と直感した。
AIを使いこなすのは「誰でも」ではない
ただし、誤解してほしくない点がある。
AIにコードを書かせるだけなら、確かに誰でもできる。しかしそれだけでは、システムはじわじわとデグレードしていく。修正指示を闇雲に出し続けると、AIは整合性を失い、コードは壊れていく。どれだけ優秀なAIであっても、的確な指示がなければデグレードは避けられない。
AIを使いこなすには、ソフトウェアエンジニアリングの基礎と、プロジェクト成功の経験が必要だ。要求仕様の定義、各種設計書の作成とアップデート、テスト計画、構成管理、チェンジコントロール——これらを的確に指示できなければ、AIは力を発揮しない。それどころか、指示の仕方次第でシステムを壊す存在になる。
デグレードを防ぐためには、設計書を作成し、常にアップデートしておき、AIに指示を出す前に「まずこれを読め、そのうえで進めろ」と釘を刺す必要がある。成功したソフトウェア開発のアプローチや、過去の失敗から得た教訓をAIにあらかじめ伝えておくことが、品質を守る唯一の方法だ。
つまり、人間のソフトウェアプロジェクトにおける成功と失敗の経験を持っていない人間には、AIへの的確な指示は出せない。AIは道具であり、使い手の経験値がそのまま出力品質に直結する。
逆に言えば、それがきちんとできていれば、開発効率は圧倒的に上がり、品質の高い設計ができる。AIは経験ある人間の思考を増幅させる道具として、これ以上ないポテンシャルを持っている。
ここで言う「経験」とは、単に年数ではない。ソフトウェア工学という、過去数十年にわたるエンジニアたちの叡智の結集を、どれだけ自分のものにしているかだ。
要求分析、アーキテクチャ設計、品質保証、リスク管理——これらはソフトウェア工学が長い試行錯誤の末に体系化してきた知識だ。AIはその膨大な知識を学習データとして取り込んでいる。しかし、AIが持つ知識を引き出し、正しい方向に使うためには、人間側がその体系を理解していなければならない。ソフトウェア工学を知らない人間がAIに指示を出しても、AIの能力の表面しか使えない。
筆者自身、30年以上にわたって組織の外のコミュニティで一流のエンジニアたちと交流を続けてきた。そこで培ったのは、特定の技術や言語の知識ではなく、「ソフトウェア開発とはどうあるべきか」という考え方の軸だ。その軸があるからこそ、AIへの指示が的確になる。AIは膨大なソフトウェア工学の知識を取り込んでいる。それを引き出せるかどうかは、指示する人間の側にかかっている。
AIと付き合う上での「失敗談」
AIを使った開発は順調なことばかりではない。実際に経験した落とし穴を一つ紹介しておく。
AIのコンテキストウィンドウ（一回のチャットで扱える情報量）は年々拡大しており、最新モデルでは数十万トークン規模になっている。しかし、開発が長期化するにつれて、膨大なやり取りの中から何が重要かをAIが適切に判断し続けることには、現時点では限界がある。不必要な情報が混在すると、肝心の指示への集中が乱れ、整合性の取れないコードを生成したり、すでに決まっていたはずの仕様を無視した実装をしてきたりする。
これを防ぐには、新しいチャットを適切なタイミングで始めることが重要だ。そのためには、これまでやってきたことのエッセンスを仕様書や作業ログとして記録しておき、新しいチャットの冒頭でそれを読み込ませるという習慣が必要になる。
これはソフトウェア開発における構成管理やドキュメント管理の重要性と、本質的に同じ話だ。人間のチームでも、引き継ぎ資料がなければ新しいメンバーはゼロから学び直すことになる。AIも同じだ。記録を残す習慣がないエンジニアは、AIを使っても同じ失敗を繰り返すことになる。
AIを過信してはいけない
AIの可能性を語ってきたが、同時にリスクについても触れておかなければならない。
AIはもっともらしい嘘をつく。これは比喩ではなく、LLM（大規模言語モデル）の構造的な特性だ。ハルシネーションと呼ばれるこの現象では、AIが存在しない関数を平然と使ったコードを生成したり、古いバージョンのAPIを正しいものとして提示したり、文脈を取り違えたまま実装を進めたりする。そしてその出力は、表面上は非常に「それらしく」見える。
経験のないエンジニアがAIのアウトプットをそのまま信じてしまうのは、この「それらしさ」に騙されるからだ。AIの出力を鵜呑みにせず、自分の経験と知識でクリティカルに検証できる能力が、AI使いには不可欠だ。
AIはあくまで道具であり、最終的な判断と責任は人間にある。この原則を忘れたとき、AIは強力な助っ人から危険な存在に変わる。
最強の組み合わせは「経験者×AI」である
では、誰がAIを使いこなせるのか。
それは、製品開発や事業開発の成功体験と失敗体験を持つ経験者だ。顧客ニーズを把握し、事業計画を立て、開発プロジェクト全体を俯瞰できる人間が1人と、AIおよびAIを扱えるエンジニアが1人いれば、かつての大人数チームを凌駕する開発が可能になる。その2役を1人が兼ねられれば、さらに強い。
ここで注目したいのが、リタイアしたベテランの価値が急上昇するだろうという点だ。
特定ドメインでの製品開発・事業開発を長年経験してきた人材は、もはやソースコードを書く必要がない。AIやAI使いのエンジニアに対して的確な指示を出せればいい。かつては「現役を退いた」とみなされていた経験者が、AI時代の最重要リソースになりうる。経験と知識こそが、AIを正しい方向に導く羅針盤だからだ。
そういった人材をうまく確保し、組織内のAI使いエンジニアをプロジェクトに参加させて経験を積ませることができる組織が、次の競争を生き残る。
AIにできないこと
ここまでAIの可能性を語ってきたが、AIにできないことも明確にしておきたい。
AIは、コードを書き、設計を考え、文書を作ることはできる。しかし、人と人をつなぎ、組織をまたいで合意を形成し、実行可能な提案を引き出すことは、AIには代替できない。
定年退職前の5年間、筆者が心血を注いだのはまさにそこだった。開発部門と品質部門、事業部門と技術部門、社内と社外——それぞれの立場と論理を持つ人間の間に入り、横串を刺して、「それぞれが納得でき、かつ実現可能な提案」を形にする仕事だ。これは、どれだけAIが賢くなっても、人間にしかできない。
AIは「答え」を出すことが得意だ。しかし組織の中での意思決定は、正しい答えを出すことよりも、関係者を動かすことのほうがはるかに難しい。その現場の政治、感情、組織の力学を読みながら動ける人間が、AI時代にもっとも価値を持つ人材の一つだと思っている。
ベテランの価値は、知識やスキルだけではない。人と組織を動かしてきた経験そのものが、AIには持てない固有の資産なのだ。
ゼロから新人を育てている場合ではない
日本ではいまだに新卒一括採用が主流だ。プログラミング経験ゼロの新人を数年かけてOJTで育て、一人前になるまで何年、場合によっては何十年もかかる。
一方、過去のソフトウェア開発の叡智を集積したAIエキスパートを、月数万円のサブスクで使える時代が来ている。
この非対称性は致命的だ。
スキルゼロの新人を何年もかけて育成しているコストと時間を、AIとベテランの組み合わせに投資した競合他社が先行すれば、価格でも開発スピードでも太刀打ちできなくなる。
ただし、AI使いとなるエンジニアもまた育成が必要だという点は忘れてはならない。AIの特性を把握したうえで、AIのアウトプットに対して的確に修正指示を出せるスキルは、一朝一夕では身につかない。
そのための育成方法として、筆者が有効だと考えるのはPBL（Project Based Learning）だ。無茶だと思っても、実際の製品やサービス開発を新人エンジニア複数人とAIの組み合わせでやりきらせる。途中でベテランが定期的にレビューを入れ、方向を修正する。教科書で学ぶのではなく、実際のプロジェクトで成功と失敗を経験させることで初めて、AIへの的確な指示が出せるエンジニアが育つ。
試行錯誤しながらもゴールを目指す自立したエンジニアでなければ、良いAI使いにはなれない。残念ながら、日本の教育環境はこの点で不利だ。知識詰め込みの画一教育では、創造性や自立した思考は育ちにくい。学校でそれができないのならば、企業側で育てるしかない。そのコストと時間を惜しむ組織は、AI時代の競争から脱落していくだろう。
エンジニア自身が損をしないために
このブログで一貫して言いたいのは、エンジニアがやり甲斐のある仕事をし、高いスキルを持って正当に評価される世界を目指してほしいということだ。
AI時代において、その実現を阻む最大のリスクは「AIに使われるエンジニア」になってしまうことだ。AIが出してくるアウトプットを検証もせずに右から左に流すだけの存在になれば、エンジニアとしての価値は急速に失われる。
逆に、AIを使いこなし、ソフトウェア工学の知識をAIへの指示に変換し、プロジェクト全体を俯瞰できるエンジニアの価値は、AI時代にこそ上がる。単純な実装作業はAIに任せ、自分はより高度な判断と設計に集中できるからだ。
AIを道具として使いこなすエンジニアになるか、AIに代替される存在になるか——その分岐点は、ソフトウェア工学の基礎を学び、実プロジェクトで経験を積む努力を続けるかどうかにかかっている。
AI時代は、スキルの高いエンジニアにとってむしろ追い風だ。問題は、その追い風に乗れる準備ができているかどうかだ。
ソフトウェア開発のサイクルが変わる
AIの活用が進むと、開発サイクルそのものが変わる。
これまで1つの機能を追加・修正・検証・バリデーションするまでに半年かかっていたものが、AIを活用することで1ヶ月程度に短縮できる感覚がある。ソフトウェアのアップデートサイクルが年1回から四半期に1回になれば、それだけで競合他社との明確な差別化になる。営業が顧客にアピールできる材料も増える。
開発費の削減よりも、むしろこの開発スピードへのインパクトのほうが、競争優位に与える影響は大きいかもしれない。製品開発には多くの人間が関わるため、コミュニケーションコストが劇的に減るわけではない。しかし、ソフトウェア開発の部分だけでも大幅に短縮できれば、製品全体の競争力は根本から変わる。
経営層が気づくかどうかが、生死を分ける
技術の話をしているようで、これは本質的には経営の話だ。
AI時代に対応できない組織は、10年後には競争に敗れ始める。問題は技術でも予算でもなく、経営層がこの変化に気づき、組織再編に踏み出せるかどうかだ。
少数精鋭＋AI＋ベテランの知見という組み合わせに再編できた組織が生き残り、旧来の大人数・長期育成モデルから抜けられなかった組織が淘汰される——そういう時代が、静かに、しかし確実に始まっている。
組織は永遠にベテランエンジニアをキープし続けることはできない。だからこそ、今この瞬間に、経験者の知見とAIを組み合わせる仕組みを作り始めた組織が、次の10年を制するのだと思う。
