（2）愛のないプロダクト

　委託先もビジネスである以上、「これも、あれも、それも」と機能を盛り込んだ提案をする。発注側がITオンチだと、言われるがままになってしまう。

　内製であれば後々の運用や改善のしやすさまで考慮して細部を詰めるが、「納めて終わり」の委託開発では納期が最優先となりがちだ。その結果、「とりあえず動くもの」が納品されるケースもある。納品後にユーザーが使いにくいと嘆こうが、直しづらいと悩もうが、それは「契約外」の話になってしまう。

（3）無難な選択を繰り返し、低位安定に甘んじる

　これまで多くの大企業は、外部委託によって巧妙にリスクを回避してきた。要は、システムがダウンしても「SIerの責任だ」と被害者面ができる。すると委託先も、そんなことが起きないように無難なやり方しかしなくなる。両者が保身に走った結果、誰も挑戦しない「低位安定型」に陥ってしまったのが日本の現状だ。これでは世界で戦えるはずがない。

（4）失ったノウハウ、残ったのは技術負債

　外部委託先に丸投げでは、組織内にノウハウが蓄積されない。それに人材流動性の高いIT業界では、委託先の担当者が何年も同じ会社にいるとは限らない。結果として、誰も理解できないブラックボックスが形成されていく。

価値のあるソフトを作るために、どこを内製化すべき？

　これらを避けるために内製化は有効だが、「全てを内製化すべき」というわけではない。及川氏は、「ログハウスは初心者でも頑張れば作れるが、高層ビルは建てられない」と例示し、戦略的選択の重要性を強調した。特に企画・設計といった頭脳にあたる領域と、ユーザー体験に直結する領域は、真っ先に内製化が必要だという。

　一方で、及川氏は「頭脳にあたる設計は内製で、プログラミングは『誰でもできるから』と外部委託を選ぶ企業が多いが、このアプローチにも問題がある」と指摘する。

　仮に新人エンジニアが3年間プログラミングを経験し、その後"昇進"して設計業務に移ったとする。技術は日々進化し、廃れていく。20年後にはベテラン設計者かもしれないが、プログラミングや実装に関する知識は3年目当時のままの可能性がある。古い知識で設計すれば、完成した瞬間から時代遅れの技術負債になりかねない。

「作っているのはソフトウェアではなく、価値そのものだ。自分たちが創造したい価値のために、何を自分たちの手でやるべきか考えることが重要だ」（及川氏）