システムはどこまで内製化できるか

どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかったのだが、今後は必ず留意すべき事情ではなると思う。要は「外に出しても、まともにつくってくれなくなった」という超後ろ向きの要因が内製化の議論を後押ししている。

まず、エンドユーザーにおけるシステムの内製化の方向については、個人的には賛成。ただし「できるかぎり」という大きな留保条件をつけた上で。その上で、上から下までつくるべきか?ということについては反対。理由は簡単で「できないから」ということにつきます。できない理由は簡単で、一義的にはそれほど人数や特に人材をユーザーサイドは抱えることはできないから。システムを上から下までつくるのであれば、それ相当の人員を抱える必要がある。エンドユーザー企業においては、本業のコストの圧縮で、本業のオペレーションの人員コストですら削減圧力があるなかで、間接部門のITサイドの人員はとても確保はできない。しかも、通常の企業の間接部門はWeb系の企業とちがって、直接の収益に影響するところではないので、人員を抱えることの経営陣への説得は非常に困難になる。

ではどうしましょうか?ということは、もう数十年も話されていて、今のところ適当な解決案がない。要するにユーザー企業では抱えるITの人員には限界があるということは前提にしなくはいけないということになる。これはもうずっと前提になっている。すなわち、上から下までエンドユーザーの独力でシステムを内製化するには限界が当然ある、というのがまずは現実になっている。

まず議論はすっとばして、内製化が可能かどうかのキー・ポイントは、結論からいうと、「企業としての文化」と「モチベーション」になっていると思う。もちろん前提として、そもそも間接部門の人員を抱えられるキャパシティがあるか、という問題が根底にあるが、キャパシティがあってもガバナンスがまったく効いていないところもあれば、キャパシティがそれほどないにもかかわらず、ガバナンスを維持して”内製化”に近い成果を出しているところもある。その大きな違いは、「企業としての文化」と「モチベーション」に見える。

もっとも、大抵の企業ではITに関しては、「企業としての文化」と「モチベーション」の維持・更新はできていない。そのような企業は優秀なITの人材は抱えられない。内製可能か不可能か?という問題は最終的には抱える人員のITスキルに依存する。キャパの問題ではない。日本の大抵の企業では、ことITに関しては、内製のある種の前提になる優秀な人員の確保は極めて困難であることが多い。

この問題は根が深い。今の日本の経営陣の基本的なスタンスは一般化すれば、「ITは経営の背骨である。ITがしっかりしていない企業は早晩衰退する」という考えと「うちの本業はITではない」という考え方のふたつに収斂されるでしょう。んで、まぁ大抵は整理しないままで二つを標榜します。冷静に考えなくても、単純に投資の優先度を考えればすぐに決定は迫られるわけですが、整理をしていないので、普通にアドホックな選択を行うことになりがち。いずれにしろ、結論的にはITへの投資は継続的に行われるものではないということになることが多い。その結末は、「そんなところには外部から優秀なITの人材は集まりません」ということになる。

仕方がないので、社内の優秀そうな人間をIT系にあてるようにはすることが通常の対応になる。しかし、いかんせん経営側の基本スタンスがぶれるのと、そもそも人員が「自分たちはITをやるためにこの会社に来たわけではない」というスタンスが多いので、モチベーションの維持が困難になる。ユーザー企業側として、人数を絞りつつ、かつ人員のローテーションを組みながら、ITの企画・開発・運用を管理し、かつモチベーションを維持していかなければならない。これは困難を極める。さらにいうと、間接部門でも、ある種の専門性が必要なIT部門は、社内でのプレゼンスの取り方を間違えると、あっという間に社内政治のネタにされるので、どうにも動けない。コストを削減して、適切に業務向けにITをアレンジするのは、ドメインを知った上での内製化が最良の策であることは、誰でもわかることだが、上記の状態では無理。「内製化」というのは聞こえは良いが、そこで仕事をするのは「人間」だ、という視点が抜けた内製化は、どうしてもうまく行かない。

・・・されど外に投げたところでまともにできない、という状況もちょくちょく出てくれば内製化の必要性も高まる。そんな状況で、ユーザー企業のIT部門についてのそれぞれの位置付けについて、いろんな角度から、それぞれから見てみることも必要でしょう。まずは圧倒的に不利な状況から、どれだけ内製化が可能か?または、内製化を同じ効果を出せるのか?ということがポイントになる。

企業のIT部門の役割は大きく、三つに分かれる。それぞれ企画・開発・インフラ運用となる。それぞれで内製化、いわゆるインハウスがどこまでできるか、すべきか、ということを考えてみる。

企画一般にIT企画と言われる部門というか、セクションというか、「機能」になる。特に業務改革を志向して、既存のシステムのあり方にメスを入れ、よりIT投資が有効になるように投資自体を決定する。さすがにこの部分はユーザー企業主導がおおい。この部分にベンダーのコンサルを入れることもあるが、そのまま開発につながったりすれば、あからさまに利益相反が発生するし、そもそもビジネス自体を知らないコンサルが多いので、あまり有効ではない。仮にコンサルを入れるのであれば、社内の”抵抗勢力”にぶつけるための必要悪としての税金であり、そのような使い方が結果として多い。この部分まで”外だし”をしてしまう場合は、結果としてベンダーやコンサルの食い物になってしまっているケースが、残念ながら多い。

いずれにしろ、この部分は内製化は必須と言える。ここができないようでは企業としてはお仕舞いに近い。今時ITなしで業務が回る事はほとんどないので、その辺を理解していない企業は皆無のはず。ITが本業ではない、とはいえ企業インフラの企画に無頓着では、企業活動全般に支障がでるか、極めて高コストになる。IT企画の内製化には、企画力をもつ人材が必要であるが、担当のモチベーションも高く維持する事ができることに加えて、マンパワーは不要なので、人員の維持も可能である。ここは特に異論もない。

開発もっとも議論になるのはこの部分。いわゆる内製化の焦点は言ってみれば「開発」をどうするか?に議論が集約される。ここでは「開発」は実際にシステムの要件定義をして、設計・実装リリースを行う機能と定義しておく。まず、前提として内製化のメリット・デメリットを明確にしておく。「内製化」のメリットはビジネスの環境変化に対応することについての意思決定・実行が素早く行えるということ。インハウスであれば、システムの中身や変更方法はわかっているので、変化に対応しやすい。逆にデメリットは、人員を抱えることへの固定費増となる。他に種々デメリットはあるのだが、とりあえずコストが一番大きい。

まずは要件定義。
ここは凄い誤解が発生する。要件の定義が原則として発注者が責任をもって行うのが基本だ。要件定義は「何が、このシステムに必要(=要件)ですか?を明確にする(=定義)ところ」なので、基本はユーザーの責務になる。ただし、どうやれば(どう表現すれば)いいかよくわからんので、ベンダーさんに助けてもらいましょうという事がまずは、“べき論”になる。(よって、大抵の要件定義の契約は委任のはずです。よくベンダーさんでも、要件定義はうちがやらないと構築の見積もりができない、というところが有りますが、そういうところは、結局、最後は「作ってみないと見積もりはできません」ってことになるので、廃業した方がいいと思います。基本設計と要件定義を勘違いしている。)尚、ユーザーさんも要件はわかっていない、という議論もあるが、それには組しない。

まず、ここの「内製化」は可能です。エンドユーザーが押さえるべき人材はまずはここです。要件定義の実行には、本来はマンパワーは必要ありません。したがって固定費用が発生するわけではありません。人材の確保は外ではなく、中から選抜すべきです。できそうな人材は以下のとおり

1. 業務経験があること。
2. 知らないのであれば、自分で調べるということができること。
3. 最低限のコミュニケーションがとれること。
4. 兼任でないこと。
5. 最低限のITの「素養」があること。

経験的に優先度は上から順です。逆ではありません。ただ、大体において上記の1−3を満たした段階で、どこかの重要なセクションの管理職以上になっているケースが多いですね。

厳密に言うと要件定義も業務要件定義とシステム要件定義がありますが、特に前者はユーザーのメンバーで行えるのであれば、行うべきです。システム要件定義は、方向性の適正性が維持できれば良いので、適当なサンプル実装ができて、あとは自力で調べるという気合いが(チームとして)あればぎりぎりなんとかなります。まぁ限界はありますが。

つぎに設計・実装
基本的に設計と実装は一体なので、設計がインハウスで実装が外部ということは基本的にはないです。結論から言うと、実装の内製化は無理なので、その結果設計の内製化も無理です。次善策として、どれだけ設計に、エンドユーザーが関与できるか?ということになります。

まず実装:
なぜ、実装が無理かちゃんと議論した方がいいと思っています。特に、コード自動生成ツールやシェルでなんでもできる風潮も、しばし見ますが、そういった銀の弾丸で実装の内製化ができることはありません。まず、話をいわゆる業務系に限定します。(R&Dと言った試験運転系は内製化が可能です。)業務系システムの実装の特徴は大きく以下の二つになります。その結果として、内製化が難しいということが言いたい。

1 業務系実装は、業務例外処理・エラートラップや例外処理・パフォーマンス向上策実装が実装全体の3割〜5割を占める。この手の部分は、うまく実装をしないとメンテナンスが不能になる。正常系だけであれば、コードの自動生成やシェルだけの処理でなんとかなる。しかし、異常系処理の記述ノウハウは単社の経験で培われるものではなく、相当の経験とかなりのトレーニングが必要であり、その上、ある程度のチームビルディングも必要になる。

2 実装は腐る。したがって定期的に書き換え・メンテナンスを行う必要ある。どのようなシステムもプラットフォーム依存性は確実にある。ハード・ソフトを含めたプラットフォームの向上は、良い悪いは別として、進化をする。すべてとは言わないが有る程度の追随は必要になる。追従をまったく行わない場合は不必要はコストを負担することになる。古い実装が残っているという指摘もあるとは思うが、これは、「実装は腐っているが、文書化されていない設計が桎梏のごとく、実装にへばりついている」からに過ぎない。実装の腐っている部分を適切に抽出し、設計思想と「分離」した上で、再実装していく技能は、通常のプログラムコードを書く以上の力量が必要であり、相当の訓練と経験が必要である。でないと、いちいち全部作りなおしになる。

では、上記の技能がある人材(またはグループ)が抱えられば、内製化できるか?という話になりますが、はい、できますよ。確実にできます。ただし、その人材やグループを維持できる、コスト的なキャパ、企業文化、そして、彼らのモチベーションを保持できますか?ということになります。一刀両断するようで申し訳ないですが、同じIT屋の中ですら、上記の異常系処理や設計思想と実装の分離維持ができる人材は稀少です。繰り言になりますが、内製化云々はツールではなく、人の問題です。

そして設計:
さてここです。基本的に実装はユーザーでは維持できないので、その実装の前提になる設計も通常であれば、ユーザーでの実行も困難です。しかしながら、設計は本来は可能であればインハウスがベスト。なぜかというと、実は設計がもっとも「残る」からです。正の資産になることもあれば、負の負債になることもあります。プログラムを記述する時に、どのような意図で、どのような背景において、なぜこの実装を選択したのか?そもそもどこまでの例外を想定しているのか?こういったものが設計になります。細かい実装のライン毎の解説になることもあれば、大きなブループリントになることもあります。機械的UML書いたり、エクセル書いたりすることが設計ではないです。いずれにしろ、プログラムの土台となる「考え方」に近いです。(まぁ、こういう考え方のないプログラムもあることはあるのですが・・・まぁ別の話題なので・・)

具合が悪いことに、こういった設計は基本的に明文化されていない場合には負債として残ることの方がおおい。考え方を明文化して、共有することで開発投資のポータビリティはあがりますし、環境変化にも対応することが可能になります。なので、この設計の部分はユーザーが内製して、「見える形」にしておくことがもっとも大切です。(変な自動生成ツールに投資する金があったら、設計のできる人材抱えるほうがよほど投資の効率はいいです。)

ただし、設計は構築につながる部分が多いので、そのつなぎ方が「政治的」に難しい。設計と実装は基本的には一体です。実装できない設計というのも、必ずあるので・・・。基本的に設計ユーザー・実装ベンダーという構図は(今のところは)成立しません。なので、設計・実装がベンダーという図式で、どこまでユーザーサイドで内製に近いところまで、設計に関与できるか?がポイントです。これは非常に難しいw。(こんな面倒なことをやるぐらいなら、ベンダーを会社ごと買ったほうがいんじゃね?的な発想もなくはないですが・・)

どうするか?まぁどうしようもないですが・・・まず基本はベンダーとの協調体制をちゃんととることです。はっきりさせるのは、「設計にユーザーが関与することが、構築にメリットがある、ということを構築者(ベンダー)に実感させる」ことです。・・・そんなことはできるわきゃねーだろ、ってのが普通のベンダーの意見ですよ。念のため。

一応、ユーザーさんがやってはいけないことは以下です。
・俺様発注者モード全開
・お金の交渉権ゼロなのにやたら詰め込む
・経験のないことを割と適当な想像でしゃべる
・コードを読んだことが一度もない、読もうともしない
・人とモノの区別がつかない

やるべきことは以下です。
・相手の立場にたって考えて、話す。
・基本的にSIのコストはずべて「時間」に還元されます。なので、如何に「工数=時間」がトータルで削減されるか?ということを考える。
・想像ではなく、事実と経験と論理で話す。
・技術を理解しようと努める。
・ベンダーも人間ですよ、ということを理解する

以上をやったうえで、ベンダー様にお願いするというスタンスで、かつ具体的にベンダーの工数が削減されるようにドライブしたうえで、一緒に設計していく、というスタンスが望ましいです。「お金を払ってこれですか?」というのはわかりますが、これが現実です。

(あと、ついでにベンダーにも言いたいけど、できもしないのにできるとか言わないでください。あとPM以上はたまにはコード書くか、設計ぐらいしてください。社内で会議ばかりやる暇があるなら、現場に出てメンバーと話してください。お客さんの方を向いてください。だれからお金もらっているのか自覚してください。以上です。)

運用とインフラ
次の運用とインフラですが、これは一部の社会インフラ系の企業は別として、確実に外に調達すべきです。ネットが前提になっている現在のインフラ・テクノロジーは進歩の一途です。ミドルレイヤー層以下は、苛烈な開発競争が世界中で繰り広げられています。ここはコンピューター・サイエンスを前提として、教育・経験がある人間でなければ参入すらできません。残念ながらにユーザー企業が内製するとかいう次元ではありません。ただし、一部の社会インフラ系の企業は、頑張るしかないですね・・・。このミドルウェア以下の技術開発・特許争奪戦に追いつけないようでは、最後はコスト負担だけがのしかかることになります。まぁ顧客に付け替えればそれでよし、というスタンスもあるでしょうが・・・ここは書きたいことはかなりあるのですがまたの機会に。個人的には応援しています。

結論みたいなもの
結論的には、いわゆる上流から下流にかけて、内製化の方向に進めていくというのがユーザーの方策になると思います。いずれにしろ、内製化=人の維持になるので、当然、企業文化やモチベーションが大きく影響します。それがわからずに、ツールだけでできるような考え方ではうまく行かないでしょう。・・でもこれは冷静に考えてみれば、別にITに限らない話ではあります。ある組織が、自分の専業でない仕事を内製しようとしたら、どうなりますか?異口同音に「そりゃ、誰がどうやるか、どういう組織にするか、だろ」って言うと思います。要は、そういうことです。