「内製化あるある」を社内で集めてみた。

背景

サービス事業会社のシステム部門にて、「内製化プロジェクト」が発起されることがよくある。
とはいえ、なかなかうまくいかないのが実態。
そもそも成功事例が少ないと思われるが、いくら他の成功事例を見ても真似ても、各会社・各部署によって事例通りにいかないことが多々。
なので、まずは社内の「あるある」を集めてみた。

内製化の目的とは？

外注による開発コストを削減したい。
外注先の影響を受けず、開発スピードを向上したい。
社内メンバーのスキルを向上したい。
社内メンバーにプロフェッショナル意識を醸成させたい。
社内で開発・保守・運用できるようにしたい。
社内のみで品質を担保できるようにしたい。
社内で知識・技術を継承したい。
重要なナレッジの外部への流出を防止したい。

内製化が発起するタイミングは？

基盤再構築・リプレースのタイミングで発起することが多い。
開発支援している中で、最終的に内製化となるケースもある。
ほぼほぼトップダウンで降ってくる。

内製化がうまくいった理由は？

社内メンバーに高スキルの技術者がいて、技術的に理解し、内部に教示できることで、プロジェクトを牽引していた。

内製化がうまくいかなった理由は？

保守・運用業務などをやりながら、片手間で進めていたため、学習にコスト・時間がかかり過ぎた。
社内メンバーに技術者がいなかったため、学習にコスト・時間がかかり過ぎた。
社内メンバーに技術者がいなかったため、難易度がわからず、方針が定まらなかった。
要件に合ったスキルの人材を調達できなかったため、教育のコスト・期間が増えてしまった。
一部から内製化と考えていたら、やっていくうちに全体を内製化せざるを得ないような流れになってしまった。
社内メンバーの感想事例
- プログラミングがこんなに難しいとは思わなかった。
- ローコード開発と言ってもやはり難しい。
- 業務はわかるけど、システムはやっぱりわからない。

どうすれば内製化がうまくいくのか？

技術に触れたことがない人でも簡単にできるような仕組みやシステムの利用を考える。（但し、Kintoneでも難しかったという事例もある。）
技術者としてのベース教育を主眼に考え、システム全体を俯瞰する能力や処理の流れを考える能力を教育する。
社内メンバーが、チーム作業、役割分担、スケジュール、品質に対しての意識を変える。
トップ層の内製化に対しての意識改革する。
トップ層が内製化の意味をきちんと理解し、現場に伝えられるようにする。
開発会社を買収して社内開発というのはある意味手っ取り早い。
一部の内製化から小さな成功体験を積んでいく。（「ソフトウェアファースト」の考え方）
コストダウンを目的としない。
開発スピード向上やスキル向上、開発コストの削減、プロフェッショナル意識の醸成を、長期スパンのゴールに設定する。

内製化そのものを考え直すとしたら？

コストダウンが目的なら、内製化よりパッケージに寄せて、業務を変えていく。
世にあるサービスを組み合わせて実現できないか考える。
外製化を効率化する。
複数企業の外製要求をまとめて、共通プラットフォーム化する。

そもそも内製化って何だろう？

社内で実装・検証も含めて開発すべてをやることを意味することが多い。
社内でシステム要件を決められるようになる、ということも十分内製化と言える。

最後に

内製化はなかなかうまくいかない、というのはみな同じ認識だった。
トップダウンで始まることが多いため、トップ層の内製化理解は重要なポイントになると思われる。
一方で、どこまで内製化するのか、という観点を一番最初に検討することが必要なのかもしれない。

今度はポイントを絞りながら、もう少し深堀して考えてみようと思う。