COLUMN コラム
最近「内製化」について書かれた記事を目にすることが多くなった。
たとえばこのような記事だ。
システム内製化はDXに必要？メリットやデメリット、実現への課題を解説
75%の企業が内製化に取り組む 上流工程の内製化を4割が志向
企業が内製化に失敗する3つの理由と、支援者に聞く「本当に大切なこと」
システム内製化とは？必要とされる背景やメリット、ポイントなどを紹介！
なぜDXで「内製化」が重要？いま、多くの企業が内製化に移行する理由とは
そこで、内製化について言及してみようと思う。
普段は結論を先に伝えないが、今回は結論を先に伝える。
「そんなバカな話はない」が私の結論です。
それでは、なぜそう結論づいたのか説明しよう。
内製化とは、どういう状態か？
そもそも内製化についてどういう状態を表しているのかをお伝えしよう。
内製化とは、システム開発および保守運用を自社で行うことである。
この反対を専門企業に外注することである。
至極簡単である。
では、なぜ内製化をしようと言っているのか？
言い分としてはシステム開発や保守運用を自分たちで行うことで、時代の流れに即座に対応できる環境を構築することができるためであるとしている。
私はIT関連のコンサル企業やSES企業の罠であるとしか見えないのだが、どうやらこういった言い分に「確かに！」と思ってしまう企業も少なからずいるようだ。
嘆かわしい。
話が逸れたので、戻す。
メリットとして挙げられるのはいくつかある。
たとえば
- 開発や対応の迅速化
- ブラックボックス化の防止
- 柔軟な開発体制の構築
- ナレッジやノウハウの蓄積
- 開発コストの低下
などである。
開発コストの低下以外は、内製化しても得ることができないと思うんだが、これらのどこがメリットなのだろうか？
と一蹴してしまうのは簡単だが、それぞれのメリットについて見ていこう。
内製化のメリットとは
以下は内製化と外注化で同じような条件にするために、外注化も保守運用の契約をしている状態である、と仮定する。
そうでなければ、公平に判断することができないからだ。
それでは、１つ１つ見ていこう。
１：開発や対応の迅速化
外注化していれば、開発をお願いする時に発注や調整の工数が発生するために迅速な対応ができない、としている。
保守運用をお願いしている以上、そういったことは発生しない。
もし新規で開発をお願いする場合、要件定義や基本設計書などのコミュニケーションが発生する。
それは、同じゴールを目指そうとする取り組みである。
これをショートカットできるのは内製化である。
そのため、「迅速な対応」が可能と言えば可能だが、失敗リスクは高くなる。
もし内製化した際もゴール設定をしっかりしようと取り組むと内製化も外注化もほぼ変わらないスピード感になる。
２：ブラックボックス化の防止
エンジニアを雇用して内製化するので、ホワイトボックスにされても意味不明なチンプンカンプンな言葉が出てくるだけで、会社経営に全く役に立たない。
トラブルが起きても即座に状況把握ができるのが内製化の強みだとしている記事が多いが、もし外注先が状況把握をレポートしてくれないなら、そんな外注先が悪いだけだ。
つまり、内製化しようがしまいが。ブラックボックス化するということである。
しかも、最近の開発事情では、他社のシステムを間借りすることが多い。
サーバーやAIも要は他人が作った作品である。
なので、システム開発をした時点でブラックボックスは不可避である。
内製化ならブラックボックスに「なりにくい」とするのは無理があるし、そう言っている方がいたらシステム開発の「シ」の字も知らない人だろう。
３：柔軟な開発体制の構築
細かな仕様変更や機能追加に柔軟に対応できるというメリットがある、とのことだが、それをやるとエンジニアはどんどん鬱憤が貯まって退職するので、止めた方がいい。
社内のことが分かっている。
業務理解が優れている。
だから、仕様変更や機能追加に柔軟に対応してくれる！
としている記事があるんだが、ひとこと言わせてくれ。
分かっているなら仕様変更や機能追加をエンジニアが勝手にやります。
仕様変更の事情なんて知らないし、最初から言えよって思う。
面倒な手続きが社内なら不要になるというのは夢物語で、不要になっていると思っているだけで、それはエンジニアの心の負担になっているだけである。
誰かが被害を被っていることを理解すべきだ。
４：ナレッジやノウハウの蓄積
内製化して得られるナレッジやノウハウを何に使うのか？
基本的に何も使わないし、エンジニア同士で共有し合うだけなので、特にこれがメリットになることはない。
「データ活用ができる」みたいなことを書いている記事があるが、それは「ナレッジ」でも「ノウハウ」でもない。
システム開発におけるナレッジやノウハウは、
- どのように依頼すればどういう結果になるのか？
- 開発した機能を通じて業務した結果、改善ポイントはどういうものがあるのか？
- エンジニアとコミュニケーションを取るために、どこ程度業務を棚卸すべきか？
といったことになる。
もちろん２C向けサービスを開発した場合は、上記以外にもユーザーの動きやリリースした機能などの反応なども獲得できる。
だが、これらは外注化しても同じである。
これらのデータはシステム開発上の結果ではなく、システム運用における結果になる。
つまり、データ活用は開発したシステムの結果である。
もっと分かりやすく言うと、車を作ることがシステム開発で、車に乗って海を見に行くのがデータ活用である。
内製化で蓄積できるノウハウなどは、車を作るノウハウに限定されることを理解すべきだ。
その先のことまでは責任を取れない。
こんなことを書いている人は、本当に「IT」を理解しているのだろうか？
悲しくなる。
５：開発コストの低下
唯一のメリットである。
外注化すると同じシステム開発でも３０００万くらいかかる（規模による）。
だが、内製化すると、費用を抑えることができるかもしれない。
この計算はエンジニア１人当たり５０万円として、３人のエンジニアを雇用していると換算し、１年間のプロジェクトとした場合である。
１人５０万円×３人＝１５０万円（月間）×１２か月＝１８００万円。
これに各種ライセンス費用が発生する。
サーバー費用で年間１２０万円として、サービス利用料で５０万円を見込んでみよう。
合計すると、２０００万円くらいになるだろうか。
１０００万円くらいは削減できる。
だが、保守運用もまた年間２０００万円かかる。
外注した場合も２０００万円くらいの保守運用費用でないと、開発コストが安いとは言えない。
もし外注した場合の保守運用が月間５０万円とか言い出すと、内製化するよりも外注化した場合の方が圧倒的な安さになる。
また、開発人員の削減を考えた時、社員として採用していた場合は解雇させるのに苦労する。
だが、外注化だったら契約を破棄してしまうだけで充分である。
このように総合的に判断すると、開発コストの低下もメリットなのかどうかは状況次第である。
次回に続く
今回のコラムはどうだっただろうか。
内製化について、内製化のメリットは全部メリットではない件について語った。
まだまだ語り足りないので、今回はこの辺にして次回また語っていく。
次回は
なぜ内製化が難しいとされているのか？
内製化の手段としてどういったものが注目されているのか？
ということについて語る予定である。
もし気になる方や内製化を検討している方は是非次回も楽しみにしていて欲しい。
さて、今回のコラムが何か気づきや学びになれば幸いである。
最新情報はスタンドエフエムで投稿している。
IT関連の話題を別角度から見てみたい
ITニュースを簡単に知りたい
IT化やDX化の話題を学びたい
自分の会社が効率化ができるか知りたい
自分の時間を大事にしたい
といった方は是非スタンドエフエムを覗いて欲しい。
それではまた次回のコラムでお会いしましょう。
