内製化を巡る議論で〜内製化リスク再考。ノイラートの船にどう乗るのか？

　諸般の事情で、内製化について各企業さんやお客さんに聞いて回る事が多くなりました。そのあたりで、2013年現在の企業の内製化についての志向や、現状・思うところを記録として残しておきます。

・前提いわゆるエンタープライズ系を対象にしています。いわゆるWeb系は対象ではないです。安定性よりもスピードに対する要求が強いWeb系では内製化が出来ていない段階で、既にスタートアップのスピードで競合に対してビハインドになります。内製化は必須でしょうし、実際そうなっています。とはいえ、それはフロントのみで、バックエンドは結局従来のSI屋さんに丸投げ状態のところもありますので、そう一概に分類もできないのが現状ではありますが・・とりあえずいわゆるエンタープライズとWeb系は明らかに状況が違うので議論としては分けておきます。

・内製化に対するスタンス正直、ちょっとビックリするぐらい内製化に対するスタンスはポジティブではあります。一時期のアウトソーシング＋パッケージ至上主義一色の流行から見るとさすがに隔世の感があります。そしてビックリするほどに出来ていません。内製化については「やりたいが、できていない」というのがほぼ例外のないユーザーさんの事情ですね。
　これがいいのかどうか、というのは議論が百出するところです。

内製化はなぜ必要で、何が問題なのか？
　まずはSIの惨状については以下にまとめていますが、状況はあまり変わってません。
　「SI屋さんとSIと、直近の課題について」
　http://d.hatena.ne.jp/okachimachiorz/20120311/1331467375

よって、ある程度の自衛措置として内製化は実際にやっておかないとシステムリスクが増大しますが、問題点もかなりあります。
　この辺は、一度まとめてあります。
「システムはどこまで内製化できるか」
　http://d.hatena.ne.jp/okachimachiorz/20111030/1319976727

　この中でも書いていますが、個人的にシステムの内製化時点でもっとも課題になるのは、内製化のための体制を持ったときの、その体制とその企業の文化とモチベーションとのギャップだと思っています。これは多分カタがつかないでしょう。システムを内製化するのであれば、ある程度の「自社のビジネスの主戦力ではない人材」を社内に抱えることになります。彼らのモチベーションや、もっている文化は、大抵は会社のもっているビジネスの方向性やエートスとは合わないことが多いです。このミスマッチが顕在化するリスクはどうしても発生します。そもそもユーザー企業においては「ITは本業ではない」という点は消し去ることのできない本質的な問題であり、どうひっくり返ってもこの部分は解決しません。現状の産業構造のあり方ではなかなか解決する糸口がないでしょう。

　とはいえ、自己防衛的なある程度の内製化はユーザー企業においては、なんにしろ取り組まないといけない課題の一つです。もっとも、これは内製化というよりもITにおけるガバナンスの獲得という意味合いの方も強いのも実態ではあります。底流にはベンダーがオールリスクをとれない以上、早急にガバナンスを取り戻し自社システムの「自律性」を確保することは避けられないという点もあります。
　さて、内製化しないことのリスクはほぼ自明ですが、その逆についても思うところを考えておきます。

内製化のリスク

・人材の固定化
これはどこまで行ってもITはブラックボックスという性格と相俟って、ユーザー企業で人を抱えた場合は必ず、その人材は固定化します。割と簡単に、しかも例外なく「そのシステムは、そいつ（または特定のチーム）しか中身がわからない」という状態になります。こういった場合はIT系の人材は通常の人事ローテーションに入れにくく、さらに固定化に拍車がかかります。この辺りはどこも頭が痛いでしょう。人材の固定化は効率性や意思伝達のスピードが向上するというメリットはありますが、どうしても発想の転換や新規性への挑戦についてネガティブになる部分は強くなります。
　もともとはこのリスクを避けるために、アウトソーシングやパッケージを導入という代替案を模索したのが過去の実態ではありますが、結論からみると「只の問題の先送り」になってしまった感もあります。

・結局、中身が本当に把握できているのかが、社内の部外者からは見えにくい
　ITは非常にコスト構造が見えにくい仕組みです。特にこれだけハードが陳腐化し、サービス化が進んで行くと、結果として、部外者から見ると、どれだけ人手がかかったという人月ベースに近い形でしかコストが把握ができないという結果になります。
　さらに、生産効率性はそもそもIT屋でも把握がしづらいのが現状です。外側からは「まったくわからない」というのが実態でしょう。少ないコードで、もっとも柔軟かつ堅牢に処理をするプログラムがいろいろな意味でもっとも価値が高いのですが、ごてごての重装備の無駄コードの山の方が時間もかかって、高そうに見えるというのは、残念ながら一般的です。
　フロントの役員といったマネージメントからすると、この事情は理解しろ、という方に難があります。コスト問題でもめ出すと大抵の場合は、「そもそもそのシステムはウチのいるのか」->「そもそもそういった人材はウチに必要なのか？」という事になりかねません。外注である場合は、「んじゃー取り替えますか？」という検討も出来なくはないですが、内製化の方針でもめると、なにかとややこしいことになります。
　ITのように透明性が只でさえ低く、本業でないところに、物と人材を抱えるというのは、社内政治リスクとしては非常に大きいことになります。要は中身がわからない金食い虫など放り出してしまえ、という議論が常に発生するリスクがあるということです。「あなた方、それは言ってる事が一年前とあまりに違いませんか？」ということが、普通にしかもサラッと出てくるところ厳しいです。

・技術の陳腐化
　これは内製化が通常であった汎用機時代と同じ轍を踏む可能性があるということです。
　IT技術は、インターネットやクラウドといった環境、タブレットやスマホといったデバイス、音声認識や高度なシミュレーションの高速実行といった技術的進歩を見ていると、現状では一種の万能感があるとは思います。こんなことまでできるようになったのかと。しかし残念ながら、理論的な研究から見ると、正直まったくといってほど理想にはほど遠いです。その意味では、ITは言われているほど万能ではないですし、逆に言えば、今後の技術革新は、まだまだいくらでも生まれる余地はありますし、実際生まれるでしょう。
　ただし、そういった技術革新は、高度な専門性と地道なR&Dと端からは荒唐無稽に見える試行錯誤の結果から生まれて実現されます。ユーザー企業の情報システム部で生まれることは、やはり基本的に無理です。（勿論例外はあります。）少なくとも、「会社の業績が悪いので、本業ではないITは人員削除をしますよ」と簡単に軸がぶれる日本の会社組織では、相当に無理です。
　しかも、さらに、このような技術発展は、外部との人材や創発的な意見交換から生まれます。閉鎖的な空間から生まれることはなかなか難しいですね。

　しばしば「内製化に成功した！」という企業の実態を拝見することもありますが、残念ながら有り体にいうとたこつぼ状態です。他の技術とのベンチマークすらフェアにできていません。まずもって外部の最新の研究成果はまったくと言って良いほど取り入れられてません。さすがに10数年前の技術の劣化版をベースに「ウチは内製化に成功して、コストが下がりました、凄いでしょう！」と臆面も無く見せられると、言葉に詰まります。
　特にマスコミが内製化に成功しましたという喧伝するところの実態を見ると、内製化が果たして正解なのか？ということに疑問もわき上がるのも事実です。

・以上の内製化のリスクをどう軽減するか
これは非常にハードルが高いです。基本的に人材の交流性・流動性をある程度高めて行く必要があるでしょう。以下思う事をまとめます。あくまで個人の意見ですよ。

1.まずとにかく考え方を柔軟にもつ
内製化に正解はありません。「内製化が出来た」と仮に思うのであれば、それは多分その時点で「失敗」でしょう。結局は、内製化の行く先が、「様々なリスク管理のバランスの維持」ということに帰着するのであれば、常に微妙にバランスを取っているという状態が正解なのでしょう。つまりそれは視点を変えれば正解にも不正解にも見える状態を常に保つ、という柔軟性が必要ということにもなります。

2. 常にリスク管理の視点をもつ
ユーザー企業様においては、「ユーザー企業の本質はITではない」という本音と「ITは企業の背骨である」という建前の、シーソーゲームと常につきあうということを自覚することが絶対条件でしょう。これはハードルが高い。シーソーゲームは相互の重さが正確にわかっていることが前提です。会社の役員が全員IT音痴になったとたんに成立しないゲームではなかなか辛い。
　予算・リスク・人材・方向性を見極めながら、一定のガバナンスを保ちつつ、できあがる端からブラックボックスになるシステムを常に解体していくという仕事を今のCIOや情報システム部の部長さんたちは引き受けなければいけません。

3. 単一の構成要素でできた組織は、単一のショックに弱いという自覚を持つ
　最近の例でいうと、「全部仮想化したら仮想化サーバーが即死して全滅した」というのが実例になりますね。翻ってみれば全面的に開発言語を移行するようなことも同じでしょう。これはハード・ソフトはもちろんのこと、組織構成の人員の単一性の問題にも突き当たります。COBOLの人ばかりいたので人員配置で全部Javaな人にしました、というのは同じことの繰り返しになってしまいます。
　ただし、多様性を保つということは、逆に言うと追加的なコストを負担する、ということにもなります。先のコストが肥大化しないよう、今のコストで償却するということです。これはまぁ普通のサラリーマンにはハードルが高い。とはいえ対策をやっていかないと単に地雷ネタを抱えるだけです。

4. システムはユーザーにとっては「ノイラートの船」ですよ
ベンダーとユーザーの最大のポジションの違いはこれになります。つまり大海原のど真ん中で自分で自分の乗っている船を修理して長い航海をしていく必要があるということです。これは内製化という側面に焦点をあてると、その様な物理的なたとえのみならず、積み重ねてきた基盤・経験・知識・人材を、を作り直しながらやっていかねねばならないという意味で、「まさにノイラートの船」でしょう。

絶えず自力で作り替える、それも人も物も組織も含めて、その上その作業そのものが常に政治リスクに晒される、こういったバランスを保つことが内製化のなのでしょう。非常にコストが高いですね。とはいえ、いままでノーリスク思考で、リスクをSI屋さんに丸投げしていたツケですよ、と言われてしまえば、そうですが。