SI業界で起きているデッドロック

先週末土曜に久しぶりの通常開催版となったEmerging Technology研究会にて、頭に汗をかく議論に参加してきた。テーマはいつかどこかでやらなければとなっていたSIビジネスの今後について。当日の簡単な感想と参加者のエントリクリップはこちらでまとめているので、個別参照頂くとして、幾つか論点を絞って追記を。

参加者は大きいところにちょっと偏りがあるとはいえ、
　・SIer
　・ソフトベンダー
　・サービスベンダー（ネットの）
　・コンサルファーム
　・メディア
と周辺領域も含めて充実したやりとりとなった。
　
　
SIのI
　
シンプルに考えると、そもそものSIビジネスの存在価値はSIのIにある。インテグレーション。プログラム開発を行うことももちろんあるが、ハードやデバイス、アプリケーションを適時組み合わせて足りない部分を足し（ソフトに限らず、場合によってはハードの調整も行い）、顧客の要望に沿ったシステムを提供することが根っことなる。調整統合するのは二つ、１）機器間の相互運用性・稼動確認、２）顧客要望とシステムの刷り合わせ。狭義には前者が組織のコアスキルとなり、後者は上流への進出、ソリューションビジネスの展開、コンサルティング領域への進出といった形で強化が図られている。

「SIビジネスの現在、あるいはSIer2.0」と題した先のエントリで、

SIのSは、実際の現場でServerなのか、Systemなのか、Serviceなのか。

と前者の入れ替わり可能性について触れたが”I”については、基本としては変わることはない。もちろん、業態転換してしまった場合についてはその限りではない。
　
話題としては、一日一麺で整理されているように、

・ユーザのグローバル化への対応
・中国、インドのオフショアの影響
・提供者、利用者間でのスピード感のずれ／欠如
・オープンソースモデルの展開の難しさ
・コンサルと SIer の関係のねじれ
・中間経路の中抜き
・人材育成で抱える問題
・外部知識の組織化
・水平分業化による各レイヤーの乖離
・通信事業者はダークサイドだ！
・プライシングの問題
・発注する側の力量

ということで、「SI ビジネスにいると一度は目にした or 耳にしたことがあるテーマが目白押し」。モジュールやアーキテクチャーの変化といった全体構造の変化についてはさほどサポートされませんでしたが、残りは終わった後のお昼の時間に出た、「そもそもプレイヤーが多すぎるのでは」という話も含めてあらかた出たでしょう。
　
　
サービスの取引
　
話の根っこを辿っていくと、arclamp.jpの鈴木さんも大きく取り上げていますが、

　いろいろな議論があったのですが落ちていく先は同じで成果報酬の話でしょうか。特にモノに落ちない成果、いわゆるコンサルや調整などです。

サービスの取引をどう価値付けするか。

おそらく、これは発注側のユーザー企業の理解度の問題、反対側で提案力などと良く括られるSIerのサービス定義能力の問題、合わせて両者のコミュニケーションの問題というところで、取引の形がが本来やり取りされているものでは無くなっているというのがまず出てくるところ。余分なハードウェアを買わせるSIｅｒがいるという話はあちこちで聞くが、話の細部を手繰っていくと開発プロジェクトの費用がシステム規模に比べて妙に安かったりと何か別の理由があるものです。本来支払われるものが回収できなかった場合、なんとか費用回収しようとするのが普通です。

次に、おそらくこちらの方が更に根深くなるのでしょうが、組織設計と人員配置が本来の付加価値とズレてしまうこと。飯田さんが「Globalization 3.0」と「SI 2.0」 -- ET研に参加して」にて

そして、きつい一言はSI関連のM&Aを手掛けているという方から。驚くことにというか、当然のこととしてというか、極論すればSIerのバリュエーションは社員数で決まると。そしてその成長は、社員数がどれだけ増やせるか、つまり採用計画で決まると。つまり、投資の観点からするとそのくらい評価の軸が見え難いビジネス形態であるということになる。

と一番外側のValuationの話としてひとつ引かれていきますが、本来必要な人をプロジェクトにも配置出来ない＝本来のValueが出せない＝お客さんも巡り巡っていいシステムと体制を受け取ることが出来ないという構図に行き着くこととなる。SIerの収益力とユーザー企業側の事業執行能力どちらも頭打つデッドロックに陥ることとなる。

おそらく、小規模な新規参入の容易さを考えると、プレイヤー数の減少が自然と起きることはないことだろう。SI子会社の取り扱いなど、各社のグループ戦略がひとつひとつ塗り換わるくらいが現実的に思える。
　
　
プロジェクトの勘所
　
サービス取引については根っこにある問題と言えるが、実際にどう定義して提供するのかとなると、個人的に勘所と見ているのは最上流の要件定義、もしくは更に手前の事業戦略側でテクノロジーに落とす領域がきっちり見えているかとなる。

結局、プロジェクトがうまくいくかどうかは「どんなシステムをどう作るのか」という事が現実的であるかに掛かっています。上流で言えばステークホルダー間を調整したり、問題点を明確にしたり。開発現場であれば、良い方式設計を行い良いリソースを集める。

プロジェクト発注後の上流フェーズ、もしくは発注前の発注条件の整理（もちろん、サービス領域になる）に力を入れられるか。

良いベンダー選定をすればいいという単純なものではなく、発注前の整理が肝になることが良くあるため、RFPをきっちり作るといったことでは全ては解決されない。プロジェクトのRFPを見ていると、その前の事業の前提にチェックを入れたくなるのは、良くあるケースである。また、情報系に長けているトップ企業はすべからくこの上流の組織能力が高い。

足りない組織能力は獲得するか、補助的に外部発注して獲得するしかない。前者は膨大な人員とコストがかかる。後者については、筋の良いコンサルタントを見つけ出して取引維持することとなる。

出来なかった場合の結果は先日もまとめたがそう難しくない。

情報インフラに乗っかっている事業体にも関わらず、技術から出てくる打ち手と制約が上手く戦略レベルに落とし込まれていないケースは珍しくない。ネット企業でも、両者が適切に繋がっているケースはそう多くないのかもしれない（という話は神原さんとも先日していた）。

両者が繋がらないと事業サイクルに無駄が出るか、戦略が最適化されず空回りして成長性に縛りが入るか、最悪の場合はバランスを崩して破綻する。

競争上不利になるだけである。
　
　
さて最後に
　
このSI業界でのサービス取引の話、ハードウェアを媒体の枠だと捉えたら広告業界にも持っていけやしないだろうか？　あちこちで業界構造問題を聞いているともっと幅広い領域でのポイントのように思えてくる。