前回、システム開発の内製化のメリットについて書きました。
開発の内製化指向がもたらすメリットとは？
今回は内製化を進めるためのアプローチについて書きたいと思います。
多くの会社がいきなり内製化はできないので、ステップを踏んで進めることになります。そのステップについて説明していきます。
第一ステップ「内製化に適したシステム群の定義」
はじめに、システム特性によって内製化すべき、委託すべき、を考える必要があります。つまり「内製化に適したシステム群とそうでないシステム群を定義する」のです。
全てのシステムを内製化する必要もないでしょう。前回書いたように、「スピード重視」「変更などの柔軟性ニーズが高い」システム群を内製化の対象とすべきでしょう。例えばAPQCで定義している業務プロセス群で考えると、「OPERATING PROCESSES」エリアを担うシステムになるでしょう。
APQC PROCESS FRAMEWORK
第二ステップ「一括請負からの脱却」
次に体制面についてです。内製化できる要員がいない場合は、外部のエンジニアを派遣契約のような契約で招き入れ、社員のごとく動いてもらうことです。一括請負によって、プロジェクト責任全てを外部に委託するのではなく、プロジェクト責任は自ら負います。それだけでなく、プロジェクト管理責任、設計責任、実装責任など、すべて自社が負うわけです。
このステップがとても重要だと思っています。多くの企業は作る部分を委託しているように見えて、実は責任を外部に負わせているのです。特注品の何かを作ってもらって、自分たちは使うだけのユーザだという意識が強いのです。
自社の経営を左右するITシステムなのですから、責任はシステム部門が負うべきです。スキル的、稼働的に足りない部分をカバーできる「人」を調達すればよいのです。
実な私はこのステップまでできれば「内製化」と呼んでも良いと思っているのです。厳密には外部リソースを使っているので内製化ではありませんが、内製化と同等のメリットが生めるはずです。
第三ステップ「アーキテクトの育成」
外部の優秀なエンジニアに来てもらって、内部でしっかりと責任を持ってプロジェクトができるようになると、複数システムにおける標準化を考える必要がでてきます。外部の優秀なエンジニアにはできるだけプログラム開発部分をお願いして、全体アーキテクチャや設計は社員が行えるようにしていきます。そうすると外部からのエンジニアの調達もプログラマーのみで良くなるため、調達コストも低くなってきます。また、技術やプログラミング言語にはトレンドがありますので、その部分に強く依存するところは外部からの調達にしておくことで、必要な時期に必要な人材を確保することができます。全体アーキテクチャや設計はプログラミング言語に依存しにくい部分ですので、その部分を社員がしっかり把握してドライブできることが重要です。
第四ステップ「内製化の完成」
いよいよ、全ての内製化の段階になります。しかし、全て内製化する必要はあるでしょうか？私が理想としている内製化は第三ステップまでで十分ですし、第三ステップまでがバランスが良いと思っています。
NCDCでは内製化支援のコンサルティングを行ってきています。具体的には、第二ステップでの変革部分のサポートと第三ステップでの全体アーキテクチャや設計のスキル移管を行っています。NCDCも外部リソースの一つとして、第二ステップでは、プロジェクト管理手法や開発プロセス策定支援のために社員のごとくプロジェクトに入っていきますし、第三ステップでは社員のごとくアーキテクトして各プロジェクトのレビューを行ない、同時に将来のアーキテクト候補の方にレクチャーを行っています。
完全内製化ではなく、作る責任を自社に戻し、外部リソースを上手く使うことが良いシステムを作る上でのポイントだと思っています。
早津俊秀
