2013年3月23日土曜日

「内製化」という武器を手に入れる


「できることなら、内製化を進めたいと考えています。でも、なかなか簡単じゃありませんね。」

ある大手企業の情報システム部門長から、こんな言葉を聞かされました。

先週のブログで書きましたが、コスト、スピード、ガバナンスの三つの圧力は、内製化へのデマンドを底上げしているようです。しかし、現実には大きな壁が立ちはだかっています。

ここで改めて問いたいのは、「何のための内製化か?」ということです。内製化は手段であり、それ自身が目的ではありません。それにも関わらず、内製化=三つの圧力への対応という拙速な期待感のもとにモチベーションが働いているとすれば、本末転倒というほかありません。

多くの企業において、ITは本業ではなく情報システム部門は間接部門、裏方を支える役目であると認識されています。経営環境の不透明感が漂う中で、少しでもコストを押さえたいという経営からの圧力は日増しに高まっており、コストセンターである情報システム部門もまた例外ではありません。

「本業として稼ぎをあげない情報システム部門が、なぜそんなに外注に支払う必要があるのか。そもそもその単価は妥当なのか。自分たちでやれば、支払いも減るのではないか。」

ITを知らない経営からみれば、このような意識が働くのは当然のことだと言えるでしょう。また、情報システム部門にとっても、外注がいなくては回らないことはわかっていても、このような経営の圧力に対処できる説得力を持ちません。

確かに、外注費用の内訳や妥当性は曖昧です。行っている作業内容や成果というよりも、時間に対する対価です。また、その人がいなければ困るというような、属人的価値への対価でもあります。これを論理的に説明することは難しく、結局は、内製化の努力を示すことで、経営の期待に応えようというモチベーションが働くことになります。

時代をさかのぼれば、このような議論はこれまで何度となく繰り返されてきました。

そもそも、外注を前提とした仕事の進め方が定着してきたのは、情報システム部門が抱えるコスト圧力への対応策だったはずです。つまり、社員として間接要員を持つよりも外注したほうが、コストも安くつくからです。また、いつでも切れる安全弁であり、リスク回避の手段となります。

じゃあ、再び内製化に戻せばコスト削減が図れるかと言えば、既にそんなスキルは内部にはなく、リスクを背負うことには大きな覚悟がいるわけで、そう簡単ではないでしょう。

それでも、情報システム部門が「内製化」という言葉を使う背景には、後ろ向な捉え方ではありますが、ITベンダーにコスト削減を強要するための脅し文句であり、経営に対するアピールでしかないと、穿った見方をすることもできます。

しかし、これでは、本末転倒です。むしろ、内製化をITの戦略的価値を引き出す手段として活用するという視点が必要です。この視点を抜きにして、「内製化」を掲げても、そこに経営的価値を見いだすことはできません。

コスト、スピード、ガバナンスという三つの圧力の中で、コストへの対応としての内製化は、上記の通り、実りのあるものにはならないと思っています。残りの二つに価値を見いだすべきだと思います。

下のチャートをご覧ください。ガートナーのプレスリリースを参考にチャートにしたものです。



欧米の経営者は、もはやIT戦略と経営戦略を分けて考えてはいません。その結果、「ビジネスのあらゆるセグメントがデジタル化」する流れを生み出しています。我が国でもそういう意識を持つ経営者が増えつつあります。

私は、こういう状況の中、IT戦略と経営戦略を融合させる手段として、「内製化」を積極的に位置づけてゆくべきであろうと考えています。

つまり、ITに対するイニシアティブをユーザー自身が握るための手段としての「内製化」です。

自社の経営戦略や事業戦略をITで実現することを自ら担い、外注に丸投げして、コントロール不能に陥らないためのガバナンスを担保するための「内製化」です。

では、何を内製化するかです。

まずは企画や要件定義の内製化です。本来、業務の何を解決するのか、そのためにシステムとしてどのような機能が必要であり、技術に何を使うのかは、ユーザーの責務と言えるでしょう。

もし、ユーザーがITのトレンドに無知であり、企画もまとめられない、業務要件定義もシステム要件定義もできなければ、イニシアティブなどとれません。

「要件定義をやらせてもらえないと、見積もりはむつかしいですね。」というITベンダーの言葉に、それはそうだなぁと納得し、任せてしまうようでは、イニシアティブなどとれようはずはありません。結局は、「作ってみないと、いくらになるかわかりません。」になり、あなた任せで物事が進むようでは、ガバナンスが働くはずなどありません。

また、構築のフェーズにおいても、ユーザーが主導権を確保することが必要です。自分たちがプロマネを担い、そのためにも設計やコーティングを自ら手がけるべきです。

コードも読めず(あるいは、読もうとはせず)、想像力で適当なことを語り、上から目線でべき論を振りかざすプロマネでは、その役割を果たすことはできません。

ときどき聞く話ですが、こういうプロマネは自分の能力のなさを棚に上げ、うまく行かなかったことを外注の責任にする。そして、たとえそれが準委任契約であっても、自らの失敗を外注に穴埋めさせ、完成まで責任を負わせる。ITベンダーも、それまでの代金を人質にとられているので従わざるを得ない。これでは、現場のモチベーションなどあがるはずもなく、ますます事態を悪化させることになります。

何よりも最悪なのは、プログラムの中身がわからない訳ですから、自分たちだけでは保守ができません。結果、コントロール不能となり、ガバナンスを担保できない事態になります。

もちろん、不足の労力を外部に頼らなければ、システムの構築が成り立たちません。だからこそ、自らが積極的に開発に関与する体制を作り、ITベンダーと協調・協力するスキームを作る必要があります。

また、戦略的なシステムの構築には、ITベンダーとの関係ばかりでなく、エンド・ユーザーとの協調・協力をこれまでにも増して促進する必要があります。特に、要件が定まらない新しい事業への対応となると、アジャイル開発を適用し、リーンスタートアップ的なアプローチも模索すべきでしょう。そのためにも、情報システム部門が、積極的に開発に関与することは必須です。

システムの運用については、アプリケーション次第でしょう。基幹業務系であり、頻繁に運用が変わらないシステムについては、アウトソーシングやマネージド・サービスを活用し、運用の効率をあげてゆくべきだと思います。

ただ、エンド・ユーザー・ニーズの変化に即応が求められるEC系などの顧客向けサービス、BIやコラボレーションなどの情報系といったWebアプリケーションについては、開発と運用を一体で行う(DevOps)体制を築き、内部で運用する必要があるように思います。

システム基盤については、可能な限りクラウドにアウトソーシングすべきだと思います。その意図は、最新のテクノロジーの活用と共同利用によるコストパフォーマンスの向上です。

ミッション・クリティカルに対応できるクラウド・サービスも増えています。また、必要に応じて、プライベート・クラウドの構築も模索し、ハイブリッドな環境を構築するという選択もあります。

それらをうまく組み合わせ、最適なクラウド基盤を利用し、アジャイル(俊敏性)、スケール(規模の柔軟な伸縮性)、スピード(迅速性)を担保できる基盤を構築すべきだと思います。

---

「内製化」は、情報システム部門がイニシアティブをとるための手段を手に入れることです。そして、情報システム部門の戦略的価値を高めるための取り組みです。それは、同時に自らリスクを負うことへのコミットメントでもあります。

一方、ITベンダーは、このようなユーザー側の取り組みを支援してゆくべきでしょう。確かに、自分で自分の首を絞める話かもしれませんが、これがお客様の価値を高めるのであれば、積極的に提案し、支援すべきです。

幸いにも(?)、お客様に、内製化のスキルを持つ人材が不足しています。一方、ITベンダーにはそのスキルがあります。ニーズがあり、提供できるもがあるとすれば、ビジネスは成立します。

「まだしばらくはSIビジネスで食べてゆける。時間をかけて取り組めばいい。」などという希望的観測は、今年の桜ではありませんが、突然にして覆されます。

当然、収益モデルも変わるでしょう、スキル・ポートフォリオも変えなくてはなりません。また、営業マインドを変えてゆことも必要です。

情報システム部門も、ITベンダーも、ともに大きな変化の節目に立たされています。もちろん内製化だけで、この変化に対応することはできませんが、真剣に取り組むべきテーマのひとつではあるように思います。そして、その時間的余裕は、残されていないように思います。

「いつやるか?今でしょ!」

ご案内 --------


■ Facebookでご意見をお聞かせください。
 このページでは、ご覧頂いた皆さんのご意見だけではなく、「これ一枚シリーズ」など、最新ITトレンドについてのわかりやすい資料などを掲載しています。ご活用ください。


0 件のコメント: