システムを内製化することについて
こんにちは!
ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤(やなぎさわ)です。
弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。
こちらの弊社運営サイト、「スタートアップ開発ラボ STaP(スタップ)」では、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。
さて、システムの内製化が昨今注目されており、実は検討中という経営者さんも多いのではないでしょうか。
しかし、安易なブームへの迎合は非常に危険です。そこで今回は、システムの内製化について見ていきたいと思います。
【確認!】システムの内製化とは?
内製化とは、一言で言えば、「システムを社内で制作できるように組織体制を変化すること」です。
ITに関する総合メディアである、アイティメディア株式会社のコラムニストである寺田雄一氏が2017年度のIT業界のキーワードとして三つの言葉を紹介しています。
一つ目が「人工知能」、二つ目が「クラウド」、そして三つ目が今回取り上げる「内製化」です。この三つの中でも、「内製化」が特に強いインパクトを持っていると氏はコラムで訴えています。
参照記事:
http://www.itmedia.co.jp/enterprise/articles/1701/25/news050.html
具体的なシステムの内製化の例として指摘しやすいのが金融機関各社です。
銀行でも保険会社でも証券会社でも良いですが、大手金融機関はグループ内に“〇〇総研”や“〇〇情報サービス”などのIT子会社を持っていることが多いです。
これらの多くは金融機関グループのためにシステム開発や保守・運用を担っており、理屈上はグループ外他社にお願いしなくても企画から設計、構築、運用、廃止といった一連のシステムライフサイクルを回せるため、完全な内製化の例と言えます。
ちなみに大手金融機関の子会社など、システムユーザー(利用企業)の系列にあるIT企業を特にユーザー系と呼びます。
逆に大手電機メーカーなどの系列のIT企業はベンダー系、ユーザー系でもベンダー系にも属さないIT企業は独立系と呼びます。
システム内製化の基本について理解したところで、なぜシステムを内製化するのか、その背景について見ていきましょう。
そもそもシステムを内製化する背景って?
なぜいまシステムの内製化に舵を切る企業が増えてきたのか、その背景を考えていきたいと思います。
システムを内製化する大きな2つの背景
多くの方が真っ先に考え付く理由としては以下にに挙げる①ではないでしょうか。
①自分たちが本当に求めているものは自分たちでないと実現化するのが難しい
金融機関がシステムを内製化している理由はまさにここにあります。
金融機関はATM一つとっても、ITシステムと密接に関係があります。
ITシステムの上で金融サービスは展開されており、ITシステムが金融機関の命運を握っていると言っても過言ではありません。
それなのに、ベンダーとの調整に難航した挙句、やっとできたと思ったら求めていたものと異なっていたという事態になれば経営上の致命傷にもなります。
実際、ATMの機能停止といったシステム側の「ちょっとしたミス」などで何人の銀行トップが頭を下げてきたことでしょう。
スピード感を持って本当に必要なシステムをクリティカルなタイミングで提供し、確実な運用・保守を維持するためには、システムを内製化するのが妥当である、という発想に金融機関が行き着くのは当然の流れと言えます。
②ロックイン効果の影響を縮小するため
また、金融機関を問わず大手企業が内製化を進める理由として、ロックイン効果の影響を縮小するため、というのも挙げられます。
まず、ロックイン効果とは、ユーザーがあるメーカーの商品を購入すると、買い替え時も同じメーカー製品を続けて購入することを指します。
イメージの湧きやすいように個人レベルで話をすると、スマートフォンを思い浮かべてください。
一度iPhoneを買った人は、買い替えの際、androidに乗り換えるよりiPhoneの新機種を購入することが多いでしょう。
その逆に、androidユーザーはiPhoneに乗り換えるよりandroidを購入することの方が多いはずです。
この際、購入者の心理として、androidユーザーはandroidを使っているうちにGoogleのサービスへの依存度が上がっており、今更Googleのサービスが十分に受けられないiPhoneに乗り換えたくない、というのがあるはずです。
ロックイン効果は消費者心理が生み出す当然の結果で、なにも問題ないように見えますが、本当はもっと良いものが他社から提供されているのに、思考停止で同じ製品を買ってしまうのです。
しかも比較検討されない(購入側にできる人材がいない)ことを良いことに、足元を見られて世間より高額な価格を提示されることもあるかもしれません。
これはシステム開発においても当てはまります。新技術への対応力も内製化の重要なポイントです。
新技術を導入したシステムを非内製化で他社に依頼すると、「まだ売り物にできるほど技術習得できていないので開発できない」と断られたり「新技術なので、その分コスト掛りますが良いですか?」と高額な見積もりが届くかもしれません。
さらに、新技術の導入で現在の問題点が改善されることを認知していても、リスク回避の観点から提案してこないIT企業も多いのではないでしょうか。
システムを内製化することによるメリット
システムの内製化が期待されているのはそれだけメリットがあるからです。
まずは、具体的にどのようなメリットがあるのかを見ていきましょう。
メリット①外注に比べて開発スピードが上がる
システム内製化のメリットのその一は、外注に比べてシステムが完成するまでのスピードが速くなる点です。
往々にして、システム開発は実際の開発に至る前の仕様策定、そして契約段階で多くの時間がかかります。
どんなものをいくらのコストで開発するのか明らかにすることは、依頼する側・される側双方にとって非常に重要なことですので、時間がかかるのはある程度は仕方がないところはあります。
しかし、契約書の記載内容の法務部確認など、システム開発にあまり関係がないところでのロスもあります。
内製化すれば、そういったロスが減り、外注時より開発速度が速くなります。
②コスト削減
また、システム開発においてもハードウェア導入などはともかく、基本的には人経費について追加の費用を必要としません。
しかも、開発速度の向上は結果的に、同じ期間に回せる案件数が増加することを意味します。
確かに内製化するということはシステム担当の自社従業員を雇用する、ということですので、案件ごとに都度つど契約していた外注に比べて、ドキュメント上では高額になるかもしれません。
しかし、結果的にコストパフォーマンスは外注時よりも良くなることが多いです。
更に外注先は「こういう問題があって困っています」と頼まれないと動かないし、動けません。
しかし、内製化していれば問題が顕在化する前に、社内のIT人材が問題に気が付き有効な対策を実施できるようになるかもしれません。
自社のシステムについて良く知っているので、単なる改善だけでなく、新技術の導入も含めてよりよいシステムに進化させるアイデアも出てくるでしょう。
非常にメリットのあるシステム内製化の動きですが、実はとても実現が難しいというのが現実なんです。
その理由居着いて見てみましょう。
システムの内製化が難しい理由
コインに表裏があるように、何事にもメリットがあればデメリットもあります。
ここでは、システム内製化のデメリット、難しい理由を見ていきます。
①人材の育成が難しい
なぜ、金融機関はシステムの内製化を実現するために本体とは別のIT子会社を作ったのでしょうか?答えは簡単です。
本体の銀行員とIT内製化に必要なITエンジニアはまったく別のキャリアを持つ人材で、一つの会社で同じように育成・運用するのが難しいからです。
営業職に分類される銀行員を、ある日突然、技術職に分類されるITエンジニアにするのは普通、難しいです。
これは金融機関に限りません。
ちょっとWindowsのショートカットキーを多く知って人をいきなりシステム担当者として責任を負わせるのはあまりに無責任です。
要件定義書などのシステム開発に必要なドキュメントの作成や、仕様策定ができる人材になるように既存要員を育成するか、外部から人材を獲得する必要があります。
更に言えば、一人IT人材を確保した後、その人にシステム周りの業務が属人化して離任時に困らないように、定期的な人材育成・確保が必要になります。
つまり、システム内製化のメリットの恩恵を受けるためには、それ相応の投資機関があり、根強さが必要になりますし、ある程度のコストもかかってしまうというのが現実です。
②採用がうまくいかない
なお、さらりとIT人材と言いましたが、非IT企業の場合「求めるIT人材の姿」がそもそも分からないということも往々にあります。
資格欄にいっぱいそれっぽい資格名が並んでいて、人当たりが良い人をなんとなく採用してしまったが、イマイチ上手くいかなかったという話を耳にすることもしばしばです。
そんなに採用は簡単ではありませんし、自分たちが欲しい時にうまく人材が集まるなんていうのは中々ないです。
それを教訓に、新規人材の採用よりも自社既存要員の育成を考えた方が良いという意見もあります。
社外から人材を招くにせよ、自社既存要員の活用にせよ、全てうちでやる、という発想はあまり賢明ではないように思います。
プロのITエンジニアで構成されているIT企業でないと難しいこともある、と割り切り「基本は自社、必要に応じてプロの手を借りる」くらいの感覚でいた方が結果的にうまくいきます。
システムの内製化の実態
さて、システムの内製化のメリット、普及しない理由を見てきましたが、最後に実態について見ていきましょう。
リスクが高い
システム内製化が注目される中で、当然のように人材争奪戦が起きています。
優秀な人材を外部から招き入れる一番手っ取り早い方法は報酬を高額にすることです。
結果、内製化でコスト削減を狙ったのに、内製化のための人材確保でコストが増加している奇妙な構図になっているのです。
しかも、他社から自社に来た人材が、自社から他社へ移動しないと言い切るのは難しく、三年経ってやっと軌道に乗りだしたら退職、ということも十分あり得ます。
開発スピードにそれほど効果を感じない
システムの内製化で開発スピード改善を期待していたのに、それほど効果を感じないという意見も多くあります。
内製化に舵を切ってから日が浅く、まだまだ組織作りも含めて試行錯誤中で効果を上げられていない、という例もありますが、それ以上に内製化に期待しすぎている方が多いです。
例えばシステムの企画です。他社と折衝していた時よりも、内製化で早くなるというのは嘘ではありません。
しかし、内製化しても実際の利用部署へのヒアリングや実際に必要な機能の洗い出しなどの調査そしてドキュメント化を行うので、一カ月かかったのが三日になるような劇的な変化はありません。
適宜外部要員を利用するならば最初から外注で良いという発想からか、100%自社要員で行おうとした結果、システム構築依頼や改善要求の数に対して、要員数不足、しかもそのメンバーも本来業務と兼務でシステム担当という状況で、かえって速度低下している例もあります。
まとめ
今回はシステムの内製化について見ていきました。
もはやビジネスと切っても切れないITシステムを自分たちで企画し開発していこうという発想は出てきて当然といえます。
確かに、システム内製化には魅力的なポイントがいくつもありましたが、人材確保・体制作りの面で苦労している企業が多いのも確かです。
安易に内製化ブームに乗っからず、自社の状況を応じた指針を策定するのが良いでしょう。