内製はメリットが大きいけどデメリットも大きい

内製は正義？

「これからのデジタル時代、システムは内製が基本だ！」

そうインタビューで答える経営層やCIOの記事が、やたら目立つようになりました。記事を読み進めると『世の中の動きや市場に柔軟かつスピーディに対応するためには「システム内製」しかない。そのために、情シス要員を大幅に増員する。IT開発人材を大量に採用するために待遇改善を行う』といった内容でした。

さらに『こんなに内製率が低いのは日本だけで、欧米は内製が基本。このままだと日本はグローバル競争で置いていかれる』とのこと。

複数のメディアで同じような記事をみると、あたかも「内製は正義」のように感じてしまいます。IT人材を囲い込んで「情シスを大所帯にできた企業が勝つ！」みたいな論調です。

内製をしていない会社は、大きく不安になってきます。

はたして、世の中の情シスは、すべて「内製」を目指していくべきなのでしょうか？

内製の大きなメリット

まず、あらためて内製の「メリット」を整理していきます。

① スピードと柔軟性

当たり前ですが、外注の場合、ベンダーと自社で会社が異なります。そのため、正式にコミュニケーションをとるための会議が増え、時間がかかります。また、仕様変更には追加費用がかかるため、慎重にならざるを得ません。
これが内製の場合、社員という身内のため、コミュニケーションはとりやすく、直接指示もできます。仕様変更の場合でも、契約縛りや追加費用の手続きがなく、意思決定がしやすくなります。社内で現場と開発が一体となり、すばやく、臨機応変にシステム開発を進めることができます。

② 開発コスト削減

外注の場合、「人月単価」で開発費用がかかります。開発エンジニアで月あたり数十万円、上級SEだと百数十万円、プロジェクトマネージャーやコンサルタントだとそれ以上にかかります。システム開発の規模が数十人月だと数千万円、数百人月だと数億円かかるということです。
この開発要員を自社で雇用した場合、つまり社員化した場合、費用を大幅に圧縮できます。福利厚生や残業代、採用コストなどを加味したとしても、総額ではかなり低く抑えることができます。
例えば、人月100万円の人材は、外注だと年間1200万円かかります。この人材は、ベンダーからもらう年収としては、おそらく500万円〜700万円です。この人材を年収800万円で引き抜いてしまえば、年間400万円が浮く計算となります。大型プロジェクトになれば、人数分の掛け算となり、かなりのコスト削減となります。

③ 開発ノウハウ蓄積

外注の場合、開発ノウハウはベンダーに溜まります。最終成果物こそユーザーが受け取りますが、その途中過程はなにも残りません。途中プロセスはすべて「ブラックボックス」となります。
内製の場合、当然苦労しますが、そのプロセスすべてが「血肉」となり、社内にノウハウが溜まります。そのプロセスを経験した人材も成長し、次回はもっと上手くやれるようになります。場数を踏めば踏むほどノウハウが溜まるため、生産性は上がり、品質も向上して、「好循環」となります。
また、独自性の高いビジネスモデルや商品開発においては、ノウハウの流出を防ぎ、競争力の強化にもつながります。

このようにメリットを並べてみると、やっぱり「内製は正義」と感じてしまいますよね。

内製の大きなデメリット

しかし、私は内製には大きな「デメリット」もあると考えます。それを整理してみましょう。

① 緊張感の欠如

社内で開発を続けると、どうしても緊張感が緩んでしまいます。もちろん、最初はみんなヤル気に満ち溢れていますが、そのペースのままだと途中でガス欠してしまいます。
そうならないように「上がしっかり圧力をかければいいじゃないか」と思われるかもしれませんが、行き過ぎるとメンタル不調で社員が壊れてしまいます。あるいは、そうなる前に逃げられて、貴重な人材が他社に流出してしまいます。社内でプレッシャーをかけるには、限界があるということです。
また、マイペースを好むメンバーは「安全地帯」に逃げ込み、ダラダラと仕事をするようになります。自分は忙しいという「演出スキル」だけが上達していきます。その結果、生産性と品質とモラルが下がってしまいます。
一方で、外注の場合は「契約」による縛りがあります。遅延でも起きようものなら、ベンダー側は大きな赤字となってしまいます。それゆえ、ベンダー社内では猛烈なプレッシャーの中、遅延なく品質も確保し、進めようとします。たとえ欠員がでようが、代わりをつれてきて、任務を全うします。
そもそもベンダーにとって、プロジェクトは「有期性」があり、明確に終わる時期が見えています。プロジェクトが終われば、少しゆっくりできます。だから、一時的にピークが来ても踏ん張れるのです。
また、現場ユーザーも、社員には気を使って言いにくいことでも、ベンダーには遠慮なく要求を突き付けられます。
自社とベンダーの間にある「境界線」は、実は悪いことばかりではありません。ビジネスは、契約によって成り立つ側面があります。

② ムダにスクラッチ開発

IT開発人材を大量に雇用した場合、最大のリスクは「社内失業」です。会社に在籍しているけれど、開発案件がなくて時間をもてあますことです。その人たちの人件費は、ドブにお金を捨てるようなものです。そのため「空き工数」が出ないように開発タスクをどんどん割り当てていきます。多少、優先順位の低い開発であっても、暇になるよりはるかにマシです。
ところが、そのような開発タスクの割り当てが行き過ぎると、余計なものまで開発してしまいます。市場には便利なクラウドサービス（SaaS）やパッケージツールが溢れているのに、それらを使う機会を自ら捨ててしまうのです。
SaaSは、即時にシステムを入手でき、ビジネスの機会損失を防ぐことができます。また、パッケージシステムには、業務を「標準化」する力があります。標準化することで、誰もが結果を出しやすくなり、「再現性」が高まります。再現性が高まるからこそ、組織を「拡張」できるのです。
内製は、これらの長所をすべて手放してしまうのです。必要以上にIT開発人材を採用し、情シスが大所帯になればなるほど、この沼にはまっていきます。
ちなみに、欧米では前提が異なります。余剰人員は、会社都合で減らすことができます。日本とは前提が大きく異なるのに、内製の話題だけ切り取って追随しようとするのは、無理があると思います。

③ 技術の陳腐化

開発人材には、それぞれ得意なプログラミング言語があります。古くは、COBOL、C言語、Java、PHPなどがあり、最近ではPython、Go、Rustなどです。
現在、「レガシーシステム」として問題になっているのは、COBOLやC言語などで書かれたシステムが今なお現役で稼働していることです。これらの言語を使える技術者のほとんどが「定年退職」を迎え、メンテナンスが困難になっているからです。
もし、現在雇用している人材がJavaだけに特化しているのであれば、内製システムはJavaで作られていくことでしょう。AIを活用するためにPythonを使ったり、マイクロサービスやコンテナ技術を取り入れるためにGoを使ったりしたくても、すぐに対応するのは難しいでしょう。
とはいえ、大量の人材を社内失業させることは許されません。Java人材の稼働を最大化するため、Javaで作れるだけ作っていきます。
このようにして、十年後の「技術的負債」を抱えたシステムがどんどん生み出されていくのです。
内製は、なにもプログラム言語に限った話ではありません。最近はノーコード・ローコード開発も流行っています。特定のノーコードツールに特化し、そこに強い人材を集めれば、急速にシステム化は進められることでしょう。
しかし、ノーコードはプログラム言語よりも、さらに応用性が低いといえます。ノーコードツールは個々にクセが強いため、他のシステムやサービスに移植したくても、困難を極めます。まさに「ロックイン」状態です。さらに特定のノーコード開発に特化した人材は、なかなか別のシステム開発にシフトもできないでしょう。
このように、開発人材を大量に抱える場合、その人材が開発可能なシステムに偏っていきます。外注とは異なり、別の技術をもった社員にチェンジすることができません。そのため、多少陳腐化しても、その技術で開発し続けるしかないのです。それは十年後の「負の遺産」を生み続けることになります。
しかし、現時点では、そのことに気づけません。技術トレンドは、グラデーションで少しずつ変わっていくからです。でも、長期でみると確実に変わっています。気づけば、最新の技術に追随できず、競争力を失っていくことになりかねません。
中長期では、社員の「スキルシフト」が有効でしょう。しかし、気長に待てない現実があります。社内失業によるコストインパクトが大きすぎて、とりあえず稼働を埋めざるを得ない葛藤と向き合うことになります。

ハイブリッド戦略

内製には「大きなメリット」と「大きなデメリット」があることを整理しました。

では、それをふまえて、内製はどう考えればいいのでしょうか？

情シスの基本戦略は、内製と外注の「ハイブリッド」なのです。

社内の全システムを内製か外注かの「ゼロイチ」ではなく、各領域ごとに見極めることが重要です。それぞれのメリットを享受し、オイシイトコ取りするのです。

では、どのようにハイブリッド戦略を立てていくのか？

今回のコラムは長くなってしまったので、次回に続きを考えていきたいと思います。

貴社の情シスは、内製についてどのような戦略を立てていますでしょうか？

（続きはこちら↓）
情シスの内製・外注のハイブリッド戦略