内製化できるなら、内製化した方が良い
受託開発の会社として、自分たちの首を絞めるような話から始めます。システム開発は、内製化できるのであれば内製化した方が良い——私はそう考えていますし、新規のお客様への営業の場でも、最初にそう説明しています。もし私がどこかの会社のシステム責任者なら、まず内製化できないかを考えます。
理由はスピードです。新しい機能が欲しいとき、改善したいとき、障害が起きたとき。そのすべてにおいて、外部に依頼するより自社で対応できる体制がある方が速いのは、当たり前のことだからです。
アクシアが創業以来一度も開発の仕事を下請けに出したことがないのも、実は同じ理由です。間に会社を挟むほど、対応のスピードは落ちる。私たちはそれをお客様との関係でやらないと決めているだけで、根っこにあるのは内製化をおすすめするのと同じ考え方です。
ただし、条件がひとつ ── 複数人体制を維持できること
内製化には、ひとつだけ譲れない条件があると考えています。継続的に複数人体制を維持できることです。
アクシアには「内製していたが、うまくいかない」というご相談が繰り返し寄せられます。お話を伺うと、トラブルのほとんどは同じところから始まっています。エンジニアが1人しかいないことです。1人体制は、業務の属人化、ドキュメントの不在、そして退職や病気で業務が止まるリスクを、構造として抱え込みます。うまく回っているように見えるのは「その時は」だけです。
これは、お客様に求めるだけの話ではありません。まったく同じ考えで、アクシアが開発や保守をお引き受けするときも、単独のエンジニアに任せることはせず、必ず複数人体制を組んでいます。1人体制のリスクを一番よく知っているのは、相談を受け続けてきた私たち自身だからです。
継続的に複数人体制を維持できるか？
条件の全体像や、実際にあった失敗の実例は、それぞれ記事で詳しく書いています：システム開発の内製化に必要な4つの条件／システム内製化の失敗パターン6選
生成AIで、境界線は確かに動いた
「AIがあれば、もう内製できるのでは？」——生成AIを使いこなしている経営者ほど、そう感じているはずです。この感覚は正しいと思います。非エンジニアがAIで作れる範囲は、本当に激増しました。個人で使う業務効率化のスクリプトなら、今日から作れますし、作るべきです。開発会社が止めるような話ではありません。
ただし、動いたのは境界線であって、境界線が消えたわけではありません。私はよく自転車と自動車に例えます。自転車は、自分で買って、自分でメンテナンスして乗ればいい。でも自動車には車検があり、プロの整備士による定期的なメンテナンスが前提になっています。チームで共有するツール、会社の基幹に関わるシステム、インターネットに公開するシステム——この領域は自動車です。作れるかどうかではなく、動かし続けられるか、トラブルが起きたときに対応できるかで考える必要があります。
これは、アクシアのAIに対する考え方と地続きの話です。AIにどれだけ任せても、結果の責任を取るのは人間であり、会社です。システムも同じで、作ることはAIに任せられても、責任を持って運用することは体制の問題として残ります。どこまでが自転車で、どこからが自動車なのかは、AIで非エンジニアの会社はどこまでシステム開発できるかで境界線を引いています。
「内製か外注か」の二択で考えなくていい
そして最近強く思うのは、内製か外注かを二択で考える必要はそもそもない、ということです。
AIを使える社内のメンバーが手を動かし、設計・セキュリティ・本番運用といった要所だけをプロのエンジニアが見る。そういう混成チームの組み方は、AI時代の現実解になり得ると考えています。全部を外注するより速く、全部を内製するより安全。内製化を目指す会社にとっては、体制が育つまでの現実的な通り道にもなります。
アクシアの月額制開発は、開発リソースを月額で確保して「外部に自社の開発チームを持つ」ような使い方ができるサービスです。いずれ内製化したいというお客様の、その途中を支える形のご相談も歓迎します。
これが、お客様にとって何を意味するか
アクシアは、内製化をおすすめする受託開発会社です。矛盾しているように聞こえるかもしれませんが、順番の問題だと思っています。お客様にとって一番良い体制を正直に言えない会社が、システムだけ誠実に作れるとは、私には思えないのです。
内製化できる体制があるなら、内製化してください。まだ無いなら、体制が育つまで私たちが開発と保守を引き受けます。内製化に向かう途中の伴走も、AIで作り始めたものの先が不安になったときの相談も歓迎です。どの形でも、最後に責任を持てるやり方を一緒に選ぶ——それがアクシアの内製化に対する考え方です。
