CCoE 連載　Vol.５ CCoEを組成する要件

CCoEを紐解いていく連載シリーズ第５回目は、引き続き株式会社 NTTデータの伊藤 利樹さんに解説いただきます。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

NTTデータの伊藤です。

前回は具体的なCCoEの成功例・失敗例についてお話させていただきました。

今回は、CCoEの運用フェーズごとに必須となる要件についてお話させていただきたいと思います。

 

１．CCoE　成長期／安定期　における要件

　これまでは、CCoEの＜立上げ期＞にフォーカスした内容をお伝えしてきました。ここからは＜成長期・安定期＞におけるCCoEに必要な要素についてご説明させていただきます。

　CCoEのミッションはクラウド推進および、その先にあるDXの達成です。継続的にクラウド推進することがCCoEのミッションとなります。具体的には以下5点を回していくことになります。

 

①教育コンテンツの充実

②クラウド利活用およびCCoEの認知度向上

③効果測定

④レガシーシステムとの調和（クラウド案件情報の収集）

⑤技術動向の調査とイグジットプラン

 

それぞれを見ていきましょう。

①教育コンテンツの充実

　継続的にDXを推進するためには、全社的なITリテラシの継続的な向上が不可欠です。

　教育コンテンツなので人事部を味方にする必要があります。人事部門を巻き込んで既存の教育コンテンツにクラウド系のトレーニングを盛り込んでいくと効果的です。

　具体的にはクラウドベンダの認定資格を取得給付金の対象とする。クラウド系のテクニカルトレーニングを社内研修制度に取り込む等が考えられます。世の中のデジタル活用事例をまとめて、研修コンテンツとして展開するのもよいでしょう。

 

　ビジネス部門のITリテラシ向上も検討する必要があります。ビジネス部門こそがデジタル活用の真のニーズを握っているのですが、日々の業務に追われて、デジタル系のインプットはなかなか難しいものです。

　この課題に向き合った、とあるCCoEの面白い取組に「誰もが知る業界の有名人を招聘し、ビジネス部門向けにデジタル活用事例をプレゼンする」というものがあります。

　超有名人のセミナーなので、忙しいビジネス部門でも応募が殺到し、みんな真剣に話を聞いてくれます。この積み重ねでビジネス部門の意識改革がされていきます。

　この方法はCCoEメンバの人脈に依存するのですが、世界中の人間は「知り合いの知り合い」といった関係をたどっていくと、5人の仲介者を経て、6人目でつながるといわれています。（6次の隔たり）その気になれば誰でも呼べるのかもしれません。

 

②クラウド利活用およびCCoEの認知度向上

　社内のクラウド利活用状況やCCoEの社内認知はとても重要です。

　マーケティングのフレームワークに、AIDMA、AISAS、AISCEASというものがあります。どれも最初なAttention（注意）、Interest（興味関心）から始まります。まずは知ってもらわなければ始まりません。クラウド利活用も同じです。

　まずはホームページを作りましょう。いわゆるCCoEのポータルサイトを開設し、社内利活用状況やクラウド利用時の手続き、手順、ノウハウなど必要な情報を掲載していきましょう。社内向けクラウド相談会の開催も非常に有効です。クラウド活用の事例がある程度まとまってきたら、外部講演を行うのも効果的です。外部講演は社外向けのプレゼンス向上だけではなく、社内への認知度向上にも有効です。例えば、クラウドベンダが定期的に開催するイベントのユーザ事例枠に出演します。そしてクラウドベンダとタッグを組んで、自社の役員をイベントに招待しましょう。講演の冒頭で挨拶してもらうと良いでしょう。すると、その役員は他社の出席者や講演を見た知り合いに質問されても大丈夫なように、講演内容をきちんと把握してくれるようになります。そして、周囲に説明して回ってくれ、気づけば強力なスポークスマンになってくれます。単純なブリーフィングより余程効果的です。

③効果測定

　クラウド利活用の効果測定は常に行い、定期的に経営層に報告しましょう。効果測定の定義は様々ですが、最低でも下記の数字は抑えておくと良いでしょう。

 

・オンプレミスとのコスト比較

　クラウドへ更改した案件の、オンプレ時代の総コストとクラウド後の総コストの比較情報

・新規案件の構築コスト比較

　新規案件をオンプレミスで構築した場合の見積と、クラウドで構築した実コストの比較情報

・システムごとの月間クラウド利用料

　利用当初から報告を意識して、案件ごとの利用料を追跡しやすいような設計を意識しましょう

 

④レガシーシステムとの調和（クラウド案件情報の収集）

　クラウド利用が進んでくるとオンプレミスシステムと連携するケースが出てきます。

ファイル連携のような軽微なものから、オンプレミスDBへの参照系APIをクラウドで構築する等の少し難易度のある話や、さらにクラウド側の運用をオンプレミスチームが引き継ぐといった複雑なものまで色々と発生します。ここで問題になるのが、アジャイル的な開発を進めるクラウドチームとウォーターフォール開発で進めるオンプレミスチーム両者の会話のプロトコルがかみ合わないことです。

　クラウドチームは引継ぎをライトに考えるケースが多いです。例えば設計概念と設計書と全体構成図、パラメーターシートで引継ぎをしようしますが、オンプレチームの文化と合いません。画面キャプチャ付きの構築手順書と、クラウドサービス自体の操作方法の伝授を求めます。クラウドチームからすると、譲歩して画面キャプチャ付きの構築手順書は良いが、クラウド自体の操作はこのシステムに関係ないので自学習で勉強するものであるべき、という文化です。

　オンプレミスチームはクラウドサービスをパッケージソフトのようなものと捉えています。このシステムを作る為に必要なパッケージソフトなのだから、使い方の説明は当然だろうと思っています。引継ぎに至るまでも細かなすれ違いは多く、互いに不満が溜まっていく一方です。

 

　このように、クラウドチームとオンプレミスチームで開発を進めると、様々な齟齬が発生するため、両方の開発手法・文化について理解しているメンバがプロジェクト内にいると良い効果をもたらします。CCoEは企画段階で、両方の開発に通じた有識者がプロジェクトに参画できるようにアドバイスできると良いでしょう。

 

　これを実現するために、クラウド案件の情報をなるべく早い段階で収集する仕組み作りが大切となってきます。クラウドを利用した開発を企画した際は必ずCCoEに連絡するような社内ルールにしたり、情報システム部門からクラウド案件を吸い上げる仕組みにすると良いでしょう。

 

⑤技術動向の調査とイグジットプラン

　メインフレームがオープンサーバになり、仮想化、クラウドへと進化していきました。今はクラウドが先端ですが、いつの日か次の技術が現れる可能性は充分にあります。

　CCoEはクラウド推進がミッションですが、クラウドを推奨してさえいれば良いわけではありません。オンプレミスが向いているシステムがあれば、オンプレミスを使うよう促すことも必要ですし、クラウドの次の到来に備えて、日々技術動向の調査を続けることが必要です。

　クラウドを盲信することなく、クラウドを推進する心構えが大切です。

　

２．最後に　結局は人

　前回までの連載で、個別最適が進んでいるとクラウド推進は難しいというお話をさせていただきました。これをCCoEという横串組織を作り、強力なリーダーが牽引することで対応していくのですが、そもそも、なぜセキュリティ部門のリーダーがリスクを極端に恐れるでしょうか？　なぜ情報システム部門や運用部門は競争原理の働かない環境で、新しいことに取り組む機会を持てないのでしょうか？　これは日本の人事制度にも深く問題があるように感じます。

　事故が起きた場合、経緯は問わずNGが付く文化、解雇はおろか降格制度も十分にない文化。

　このような状況を打破するためには、前回申し上げたとおり、自社内もしくは外部のスーパーマンに頼る必要があるのですが、本当に必要なのは人事制度の改善なのかもしれません。

 

いかがでしたでしょうか。

今回は成長期以後のCCoEに必要な機能を紹介させていただきました。

もちろんクラウド推進に必要な要素は状況により異なるため、上記以外にも自社に必要な要素を具備していく必要もあるかもしれません。自社に必要な要素と本連載を照らし合わせ、ぜひご参考にしていただければ幸いです。

最後まで読み進めていただき、有難うございました。

 

By 伊藤 利樹（株式会社 NTTデータ）