CCoE 連載 Vol.3 なぜCCoEがクラウド活用に必要なのか

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

======================

NTTデータの伊藤です。普段はガバナンスを利かせてクラウド活用するためのコンサルティングをしたり、セキュアにクラウドを活用するための自社ソリューションを運営しています。

さて、前回までの遠山さんの連載では、DXにはクラウド活用が必須である点、そしてクラウド活用には下記の3点が重要と説明がありました。

①社内ルールの整備

②予防・発見・是正的統制の整備と活用バランスの調整

③クラウドサービスの進化への追従

今回はこれらを実施していくために、なぜCCoEが必要なのか、

なぜ情報システム部門だけで実現できないのか?について書きたいと思います。

 

1.なぜCCoEがクラウド活用に必要なのか 

 昨今、特にエンタープライズ企業におけるクラウド利活用のシーンにおいて、なぜこれほどまでにCCoEが有効だと言われているのでしょうか。

遠山さんが示唆したクラウド活用に欠かせない重要ポイント3点 のうち、<① 社内ルールの整備>をテーマに据えながら、CCoE設立の必要性について見ていきたいと思います。

(背景1)クラウド活用に向けては、高い確率で障壁が存在する

 <社内ルールの整備>とは、主に自社の既存のITルールにおけるセキュリティポリシーや運用プロセスをクラウド活用に合わせたものに整備していくことです。

  社内ルールと一言で言ってますが、思いつくままに並べるだけでも、次々と整理すべきものが出てきます。

  • システム開発ルール
  • システム運用ルール
  • クラウド利用ルール
  • 購買ルール
  • ユーザID管理

それぞれの主管部署と調整し、ルールを整え、形にし、決裁を取り、オフィシャルなルールとして告知していくのですが、そのためには既存のルール、社内手続き、そしてクラウド利用において気を付けるポイントを理解している必要があります。そして、主管部署は必ずしも協力的ではありません。よくある非協力的な例を4つ紹介します。

 

ケースa)ユーザID管理を拒否する運用部門

  オンプレミスシステムのユーザID管理は運用部門が実施しているので、クラウドのユーザIDも同様に管理してもらおうと話を持ち掛けたとしましょう。すると運用部門の担当者が「そもそもクラウドのユーザIDまで運用部門が管理すべきものなのか」と拒否するケースがよくあります。
それもそのはずで、運用部門の担当者は運用が増えても忙しくなるだけで、クラウドがもたらすビジネス効果をダイレクトに感じにくいかもしれません。運用業務は効率化され、少なければ少ないほど良いと考えている矢先にクラウドのID管理という業務が増えると捉えるのも無理はないでしょう。
私の経験では、1回目の打合せで運用部門で管理すべきと提案し、ご検討いただくことになったものの、2回目の打合せは突如キャンセルされてしまい、その担当者と連絡が付かなくなってしまったことがあります。依然、その企業ではクラウド活用が進んでいません。
そのような運用部門であっても、最終的には仲間にし、都度レクチャーし、クラウドID管理に必要な予算を確保し、管理が不安なくスタートできるように仕立てなければならないのです。

 

 

ケース b)思考停止するセキュリティ部門

おおよその企業における社内ルールの門番はセキュリティ部門ですが、セキュリティ部門からクラウド利用の許可を得ることは私の経験からも重要であり、大変でした。それもそのはず、クラウドを介したセキュリティ事故は確かに存在し、ニュースでも大きく取り上げられることが多いです。

 仮にあなたがセキュリティ部門の部長としましょう。任期は今年度いっぱいです。若いころから仕事詰めだった甲斐もあり、無事任期を終えれば役員への道も見えてくるころです。そんなところにクラウド利用の申請と社内ルール変更依頼がきました。つい先日も、クラウド絡みの個人情報漏洩の事故のニュースが報道されたばかりです。事故が起きれば役員どころではありません。さて、部長のあなたは本件を受理できるでしょうか?

 最低でもクラウド固有のリスクを分かりやすく的確に定義し、それを防ぐ対策を講じており、社内ルールに落とし込めていることを分かりやすく説明してもらわないと納得できないでしょう。

 

ケースc )コスト弾力性が無いシステム開発部門

情報システム部門にクラウドでのシステム開発を依頼したらオンプレミスで構築する場合の倍の見積が提示された。こんな話を経験上よく耳にします。今週は3回聞きました。

 高額となる理由は決まってこうです

  • やったことないのでリスクをたくさん積みました。
  • やったことないので学習コストと検証コストをたくさん積みました。
  • クラウド分からないからオンプレに誘導したいのでクラウドは高くしました。

 まず、学習コストや検証コストをユーザーに転化している時点で異常です。資本主義の競争の中では発生しえないお話ですが、競争がない環境の場合は起こりうる、起こりやすいと考えられます。情報システム部門(システム開発の子会社含む)は、そのような環境下に存在することが多いのです。

 社内でシステム開発の案件が常に存在し、競争せずともビジネスが成り立つ環境です。これでは自己研鑽により新技術を習得するモチベーションが湧かなくても無理はありません。社会主義が衰退した理由と非常に似ています。

競争の原理が働かないと、勤労意欲は減退し、生産性が低下して停滞するのです。

 

ケースd )個別採算性がもたらす不幸

以前とある企業の情報システム部門からこんな問い合わせを受けました。

「ビジネス部門がクラウド使いたいと言ってきていて、大変困っている。以前導入した仮想化基盤の償却が終わってないので、今はクラウドをやりたくない。クラウド化を拒否するための情報をくれないだろうか?」

これは通常おかしな話です。購入済みの資産を利用することでコストメリットが出るのであれば、それで話はおしまいです。しかし、話をよくよく聞いてみると、部門ごとの独立採算性を取っており、仮想化基盤への投資は情報システム部門として行っている。ビジネス部門が仮想化基盤を利用する際に、社内取引で利用料を徴収する。

一方、ビジネス部門としては、仮想化基盤の利用料よりもクラウドの利用料の方が安価なのでクラウドを使いたい。という構図でした。予算の縦割りにより生まれた不幸というわけです。

運用量増加を拒む運用部門、リスクを取りたくないセキュリティ部門、競争がなく新技術取得のモチベーションがない情報システム部門、個別採算性がもたらす不幸について、自身の経験から例を挙げさせていただきました。いずれの話も全社目線からするとNGではありますが、それぞれ個別組織の論理を見ていくと、正論だけではなかなか話が進まないのはご理解いただけたかと思います。組織の縦割化が進んでいるほどこの傾向が強くなるでしょう。

(背景2)障壁突破を担うヒトとそれを受け入れる活動スキームとして

個別の障壁を突破し、全社最適の目線で会話をするためには、複数組織を横串にして会話することや、経営層による高い目線と後押しが重要となってきます。当然ですがクラウドに関する知識も必要です。既存の情報システム部門のみ、で突破できるでしょうか?

 もちろん突破できる能力を持つ卓越した情報システム部門もあるでしょう。そのような企業にはCCoEは不要です。正確にはCCoEの機能を情報システム部門が包含している状態です。しかし、多くの企業において情報システム部門だけでの突破は難しく、ルール整備はおろかクラウド推進自体が停まってしまいます。

 そこでCCoEの出番です。クラウド有識者やステークホルダーが集まり、経営サイドがスポンサーとなり全社最適な議論をしていくワーキング・グループ。それが初期のCCoEの形であり、障壁突破に有効な処方箋となるのです。

 

(背景3)ユーザー部門・IT部門双方のDXモチベーションをリードするコーディネーターとして

 さて、いよいよクラウド利用のためのディスカッションやルール整備が始まりました。

しかし、「DXのモチベーション」なく、情報システム部門やリスク管理部門のステークホルダーだけでクラウド利用の整備を進めると、極端にセキュリティに重きを置いたルールが出来てしまいがちです。セキュリティと利便性はトレードオフですが、情報システム部門やリスク管理部門は自らがDXの主体ではなくクラウドを使うわけでもないので、リスクをコントロールしようとするあまり、どうしてもユーザー部門の利便性を置き去りにしてしまいがちです。

 その結果、強固すぎて使い勝手が悪いセキュリティルールや、大量かつ効果がないクラウドチェックリストが生まれ、ユーザを辟易させてしまうケースは、これまで数多く目にしてきました。

遠山さんの連載で重要とされた、「②予防・発見・是正的統制の整備と活用バランスの調整」も「DXのモチベーション」なく、情報セキュリティ部門とリスク管理部門の論理で進めると極端に守り重視な調整がされます。

 

 例えば予防的統制では、ユーザにどれくらいクラウドの操作を解放することができるか、がポイントになるのですが、最も極端な例ではユーザは一切クラウドの操作はできない&クラウドの操作は全て情報システム部門に申請して依頼せよ。となってしまいます。

リスク管理側の視点では、全てコントロールできるのですから良いでしょう。しかし、ちょっと設定を変えるだけでも申請書を出し、レビューをし、変更してもらえるのは数日後・・・では、トライアンドエラーやアジャイル開発など夢の世界です。

クラウドを活用する大きな目的として、ビジネスのアジリティを得ることがありますが、このケースではそれが完全に無くなっています。

 強固すぎるセキュリティルール、大量な形式だけのチェックリスト、不自由な操作権限・・・そんな環境で、ユーザー部門は果たしてクラウドを使おうとするモチベーションが保てるでしょうか?

セキュリティと利便性のバランスを取った現実的な落としどころを見出すためには、「そんな仕様では利用に向かない」とエビデンスと知識をベースにした声で、しっかりと訴える事ができる存在が不可欠なのです。  

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

今回はクラウド活用におけるCCoEの有効性と初期のCCoEに必要なポイントについてお話させていただきました。

一方で、CCoEには数々の成功例と失敗例があります。クラウド活用が進んできた昨今のCCoEの在り方について、次回の連載でお話させていただきます。

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

 

By 伊藤 利樹(株式会社 NTTデータ)

 

最新ポスト