CoE…出来ないなぁ

余り日本のIT業界で聞かない言葉に「CoE（Center of Excellence）」があります。
Wikiでは「日本では、組織横断的専門集団、組織横断的研究拠点などの意で用いられる場合が多い」と説明されていますが、欧米の大企業ではIT部門を中心にITベンダーの専門家が参画した組織形態になっています。
このCoEを通じ、企業内の課題に対してアイデアを持ち寄り改善に繋げていきます。

私の知る範囲では、こう言ったIT部門では自社での開発や管理も行っていることもありCoE自体は、フラットな立場で意見交換や要件集約が行われているようです。
このような「流れ」を考えると、日本では中々根付かない形式に思えます。

まず、お客様とのフラットな意見交換が難しい実態を上げざるを得ません。中小規模の企業ではIT部門がIT企画機能だけを持っている事が従来から少なくなかったと思うのですが、最近では大きな企業でも実態は企画あるいは管理が中心になり、企業内での課題をITに落とし込む（この表現からして…よろしく無いんですが）段階でお客様は行司のような立ち位置で、ベンダー間の話し合いになってしまう事が多いと思うのです。更には、お客様不在でPMOとして雇用された人たちが行司になり、お客様は結果の報告を受けると言う姿すら少なく有りません。

大昔の話で恐縮ですが、それでも「温故知新」として自分の戒めにしていることがあります。それは「お客様以上に業務を理解している人はいない」と言う若かりし頃に出会った上司の言葉です。「お前たちはシステムの専門家にはなれる。けれどもお客様の業務はお客様が一番知っているんだ」と。年を重ねるに従い、この言葉に疑念や同意を繰り返してきました。が、一つ一つの事柄に照らし合わせてみると、哲学として理解しておくべきことだと信じています。

まず、お客様の業務課題が例えば「早期にWebチャネルを立ち上げたい」だとしましょう。Webプログラミングの経験があれば、恐らく「できます」と言えるレベルの案件でしょう。しかし、
・既存のWebサイトなどとの標準化、統一性は？
・ユーザIDやIDに紐付いた行動履歴の活用は？
・Webで表示する過去の取引情報の抽出は？
・エンドユーザの登録は？
・ログイン方式は？
・セキュリティは？
・アクセスコントロールは？
・アウトバウンドや通知の実装方式は？
・レスポンスやキャパシティプランニングは？
・保守のポリシーは？
・OSやDBなど稼動する基盤の要件は？
とザックリと挙げても、これだけの事がお客様の要望を汲み上げつつ決めていかなければなりません。
時々「プロだったら、相性が良さそうなところで見積もってよ」という言葉も聞きます（本当に）。
でも、開発では連携対象のシステムを知っておかなければ、定義すらできません。また、稼動後に「そんなつもりじゃ」と言われるような事態は避けておきたいのですから、適当に見繕って構築することはプロだからこそ避けたいのではないでしょうか？
（当然、目安として提示する事とは違う意味で書いています）

また効率化や調達コストの削減と言うメリットから、どの企業でもマルチベンダーと言われるように、各所各所に色々なベンダーが納入や維持管理に入っている分業体制が出来上がっています。更にはDoAや密結合と言われるようなシステムの内実を把握しなければ連携の方式や対象業務、また実際に連携するデータが理解できないケースも少なくない上に、その定義を文書化した内容と実際に稼動しているシステムの現実とに乖離があるケースも多いのです。
本来、こう言った悲劇的な状況が生まれないように管理を（司る）する事がお客様の肝要だと思いますし、この事が出来てこそ先ほど書いたように「業務はお客様が一番知っている」と言う状況になるのですね。
ところが現実は、そうなっていない事が少なくない。「じゃぁ、どうすんの？」と言う素朴な疑問が一つは「提案時のフィージビリティスタディ」であり、プロジェクトキックオフ後の「要件定義-現状調査」になるのです。上手いIT会社なら、どちらの選択肢をとっても「課金」の対象となります。「おい、提案時の活動だったら無償前提だろ」と言われそうですが、これも大きくは二つのオプションがあり、一つは「有償で調査します」と言う場合、そして「（工数を混ぜ込んで、プロジェクト見積を作成するヨ）」と言う設定があります。
当然、後者はプロジェクト契約ができない場合は『取りっぱぐれ』になるリスクはあるのですが、営業活動などで面倒な提案を一つ減らせるというリスクの代替となるので、意外に多用されるパターンのような多い気がします。逆に言えば、契約前から綿密な提案活動ができる関係性が構築できている事が、このオプションの大前提ですから、リスクが比較的小さいと言えるのでしょう。

ただ、いずれのケースを取ってみても「お客様が業務を一番知っている」場面には行き着いていませんね。IT企業側が本当に為すべきこと「知識保有者を活性化させる」ことにあるのです。
先ほど「Webプログラミングの経験があれば」と書きました。が、あくまでプログラミングです。列挙した要望として汲み上げるべき事柄はプログラミング以前に把握していなければならない事ですね。つまり、Webチャネルに必要な要素を理解しているIT企業が「これだけの事を決めていくんです。そのため、各項目を質問表や打ち合わせで確認したいのですが、御社で知見や決定権のある方に確認をいただけますか？」と伝えなければなりません。
そう、一つの企業でも「お客様」と言う概念や人格は多岐に亘るのです。ですから営業の方などに多いのですが「お客様が判らないと言っているから」を言い訳に使われてしまうのですが、これは「お客様」の中でもカウンターの役割を担っている方が判らないのか？それとも、対象の専門領域の知識を持っている人が判らないのか？あるいは、お客様の法人全体、実働しているITベンダーでも把握していないのか。と、様々な理解ができるのです。この理解が曖昧なまま「判らないなら仕方ない」とすると、プロジェクト工数が（悪い想像に基づいて）膨らんでいきます。
逆にカウンター以外の専門家にも連携が上手く出来始めると「やっぱりお客様が一番良く知っている」と言う状況ができていくのです。

さて、CoEに話を戻します。
CoEのメンバーは、お客さまとITベンダーが構成します。ITベンダーから参加するメンバーは常駐や頻繁な訪問、実装活動などで各々が担当するお客様システムについて理解しています。と言う前提があります。こうなるとお客様からの「こんな要望が業務から出てきている」、あるいはベンダー側から「こういった製品を導入することで、他社では効率改善ができている」と言った意見交換を行うようです。その事で業務の専門家とITの専門家がお客様の状況に会った改善策を練っていくのですね。これはマルチベンダーの中でも行われており、練り上げられたソリューション案に対して、各々が担当する領域を明確化していく訳です。この状況であれば、お客様も常にいる環境で次の一手が決められていき、業務部門や経営部門が納得するIT構築ができるわけです。
この「納得」。「IT戦略」と言い換えると判りやすいでしょうか？