データ活用「やる、やらない」の経営判断を誤ると、どうなるか(中)

前回のコラムで、ほとんどの企業は、ビジネスをドライブするうえでデータ分析をそれほど重要とは見ていない、または少なくとも過去においては重要と見ていなかった企業であり、その中でデータ分析に取り組んで成功したと言える企業にはパターンが2つある、と述べました。今回は引き続いて、その2つのパターンのお話から始めます。

成功例といえるパターンのうちのひとつは、ビジネスが停滞または危機に瀕するような状態に陥った結果、改革の活路として徹底した品質管理・事業管理を目指すことになり、その原動力としてデータを活用したケース。もうひとつは、現場で始めたデータ分析の具体的な効果を経営層が高く評価する結果となって組織に定着したケースです。

前者のケースの場合は、結果としてトップダウンになり、組織を横断した取り組みとなるので、英知をうまく結集できれば成功に至ります。経営層に危機感が強い、またはデータを適用しようとする分野に経営層がもともと明るい、といった場合は、成功率が高まるように見受けられます。

後者のケースの場合ですが、実際にこのカタチで成功する企業は、なかなか数は多くありません。たいていの場合、データ活用をやってみようとしつつも、ボトムアップになるため社内でなかなか盛り上がらずに苦労しています。

ボトムアップで成功している企業で特徴的なのは、データ活用を試そうとするチームが、IT部門に近いところにあることだと見ています。IT部門が全社横断でデータを閲覧できるという強みをうまく生かし、業務部門をうまく巻き込んで、分析のみならずその成果を使ってもらえる仕組みをつくり上げられると、成功につながっているようです。

一方で、データ活用を試そうとするチームがマーケティング部門に近いところにあると、Web や EC 以外では顕著な成功例がなかなかありません。マーケティング部門が孤軍奮闘するも、他部門はあまり乗ってこないか受け身である様子が見受けられます。

データ分析は、分析力が重要であることは言うまでもありませんが、むしろ、その分析結果を踏まえて業務に埋め込み仕組み化する能力が、さらに重要になります。この能力の確立には、業務を横断してデータ活用の意義を共有し協力しあう体制が不可欠で、取り組みに対して相互に責任を持つ意識も重要です。

それができていない組織ではデータ分析をドライブする力に欠けてしまい、投下できる組織リソースにも欠けるため、まずは小さく始めて小さく成功しようとアプローチするのはいいけれどなかなか大きく広がらない、という印象です。スモールスタートが、スモールなままで成長しないのです。Web や EC でうまくいくのは、取り組みがITの領域でほぼ閉じるからと言えるでしょう。

興味深いのは、同じ業種で似たようなものを売っている企業間で比較しても、データ重視とそうでない企業があり、社内でのデータ分析に対する取り組みかたが見事なまでに異なることがある点です。例えば、同じ業種の企業のマスマーケティングにおいて、かたや華々しい成果を挙げてマスコミに大々的に取り上げられる一方、かたや「小さく始めて広げていくしかない」と頑張ってトライするけれど盛り上がらず、街に出て話題をつくろうと思っても理解してもらえず、顧客データの獲得どころか逆に街の人に「何やっているんですか?」と聞かれてしまう、といった具合です。

くり返しになりますが、ビジネスにおけるデータ活用は、統計的スキルや分析ツールの運用能力があることが必要十分なのではなく、分析した結果を現場が活用できる仕組みに昇華させる取り組みがさらに重要です。つまり、組織横断で行動できるかどうかがカギになっているわけです。関心のある人材のみで推進するボトムアップでは、データ分析活用の場合、すぐに限界が来ます。

このようなことが、データ分析活用の成功ケース・停滞ケースを総合的に概観してみると分かってきました。情報システム活用も同様なところがありますが、データ分析活用はその傾向がよりセンシティブであると思われます。

では、結局のところ、データ分析を企業にとって有用な施策とするにはどう対応すべきのか、次回のコラムでまとめてみたいと思います。

システムのオーナーシップは、だれが持つべきか

先日、ある大手企業のCIOのインタビュー記事を読みました。

その方は就任早々、システムのオーナーシップはIT部門で持つことにしたのだそうです。

いわく、各部門が個別にシステムを持っている状態で、たとえ無駄や重複があってもどこかの部門が自ら「統合しよう」とは言い出さない。IT部門がオーナーなら、それが言い出せる。ワークスタイルを変えるべき場合でも、それを言い出して推進する部門はいない。IT部門が全体俯瞰する立場なら、それを言い出せるのだ、と。

記事の解釈違いがなければ、IT部門がオーナーシップをとる理由は、会社を全体俯瞰して全体最適なシステムをスピード感を持って整備するため、と要約できます。

「オーナーシップ」ということばは、少し広い概念を示す言葉であるように、わたしは感じています。このことばを考えるとき、念頭に置くべきことは2つあると思います。

ひとつは、業務構造デザインに対するオーナーシップ。もうひとつは、システム導入に対する成果責任のオーナーシップです。

業務構造デザインのオーナーシップとは、つまり、業務のあり方を全体最適に維持する責任を意味します。このオーナーシップの持たせかたはさまざまです。業務プロセス改革を推進する専任部門を設置するケース、各業務部門が参加する部門横断の検討委員会組織を設けるケースなど。珍しいケースでは、業務部門とIT部門の統括責任者としてCPO(Chief Process Officer)を置く企業もあります。CPOが業務最適化の指揮を執る、という、大変わかりやすい手法です。

ただ、どのパターンにしてもいえることは、業務にもITにもバランスよく牽制が利くような体制を採っている、ということです。

一方、システム導入の成果責任のオーナーシップについては、システムを利用する業務部門が、予算権限も含めて責任を持つのが主流です。

従来は、このオーナーシップはIT部門が持つのが通常でした。しかしその結果、システムを利用する側である業務部門が、システム導入にあたって主体的に行動しない傾向が顕著になりました。いわゆる「丸投げ」です。結果として、システム導入のコスト意識なくあれもこれもと要求し、結果として作りこんだ機能の多くが実際には使われない、またはシステムの機能を使いこなせない、という事態が問題視されるようになりました。

システムというのは、導入するのが「結果」なのではなく、使って成果を出すのが「結果」です。使うのが業務部門なのであれば、成果責任は業務部門が最終的に負うべきであるし、使う側が成果を出しやすいように最初から主導すべきである、そう考えられるようになったのです。

組織設計のあり方は、企業文化などの関係もあり、一概に最適な手法を語ることはできません。ただし、体制のパターンに対するメリットやデメリットは、他社事例から学べるところがたくさんあります。これはもちろん、その施策や責任者のことばを表面的に理解するのではなく、背景や本質を読み取るということです。

特に、ある企業が体制を採った後、数年経ってどうなったかまでを知ると、興味深い知見を得られることがあると思います。

その社外取締役、なぜ置いたのか

過酷な条件で従業員を労働させていたとして、アルバイトが大量離反するなど問題になったゼンショーホールディングス。問題発覚後、同社は第三者委員会を設置、7月末に調査報告書が同社に提出されました。

その報告書によって現場の厳しい労働実態が明らかになったのは周知のとおりですが、合わせて、トップレベルでの管理体制にも、問題の焦点が向けられています。

報告書によれば、現場からの勤務実態の報告や、退職者が続出している状況は、事業部門レベルでは把握していたようです。しかしこうした情報は、取締役レベルにはまったく上がらない状況だったとされています。

同社には社外取締役が置かれていました。本来、社外取締役は、専門的な知見や経験を活かし、外部の視点で会社の運営に貢献するのが役割です。社外取締役には、内部の人間が悪しき環境に慣れきって麻痺してしまっている場面でモノ申す役割が期待されます。しかしながら同社では前記のような状況だったため、社外取締役もこうした情報を把握できなかったということです。つまり、「外部の目も利かない」状態でした。

このような事態が明らかになると、その企業における「仕組みに対するこだわりの浅さ」が、残念ながら見えてしまいます。

社外取締役の設置は、ここ最近では一種のブームになっているようで、多くの企業が設置を検討し、実際に設置しています。外部の目を置くことは大いに有効でしょう。また、2015年4月に施行予定の改正会社法では、選任しない大企業には株主総会でその理由の説明を義務づけています。事実上義務付けられることから、今後もこのトレンドは続くと思われます。

どなたかとのお付き合いの都合だとか、もしくは株主向けに見た目がよいなどの理由なら話にもなりませんが、本来、社外取締役を置くのだとしたら、そこには目的がなければなりません。社外取締役は、その目的のもと、社内でなんらかの役割と働きを占めるはずです。そして彼らに期待される役割と働きがあるのであれば、それはなんらかの仕組みの一端をなしているはずです。

そうした仕組みのないところに、ただポストだけを置いたところで、意味を成すはずがありません。

社外取締役に外部専門家の視点と役割を期待するとしましょう。それなら、彼らによいアウトプットを出してもらうために、どうやって彼らにインプットするのかを考える必要があります。彼らの知見を効果的に引き出すには、適切な情報が必要です。そのためには、社内の取り組みや状況が明確に伝わるような仕組みを用意し、鮮度の高い情報が抜かりなく共有可能な状態が要求されます。さらに言えば、社外取締役が発したフィードバックを現場にインプットし、具体的な対応をモニタする仕組みも重要です。

これらができてはじめて、ご参画願うことができるのではないでしょうか。

ゼンショーの事例を聞くと、社外取締役設置の目的にかなう仕組みを整えることなく、単に任命して取締役会への出席をお願いしただけに過ぎなかったのではないかと思えてなりません。

およそ強い企業とは、所作のすべてに意味があり、なぜかを問えば「そこまで考えているとはすごい」と言われるほどの回答をする企業ではないでしょうか。どの世界においても、およそ優れたプロフェッショナルにはそのような特性があるように感じます。

セキュリティ問題発覚=責任者辞任、でいいのか

7月初旬に発覚し大きく報道された、ベネッセコーポレーションの顧客情報漏えい事件。漏えいの規模は2000万件以上、4000万人~5000万人が対象になるということで、世間にこれだけの動揺が広がったのは無理もないでしょう。

すでに、同社のシステム開発・運用を手掛けるグループ会社・シンフォームの業務委託先の元社員が、不正競争防止法違反の容疑で逮捕され、容疑を認めているということです。犯行の手口も明らかになってきており、犯人は自身のスマートフォンに顧客情報をコピーして持ち出したとされています。

ベネッセコーポレーションでは、他の多くの企業と同様に、社内端末に対するUSBメモリーの接続を禁止する対策を取っていたようです。しかしながら、スマートフォンを外部ストレージとして使用した場合に、多くはUSBメモリーと同等の振る舞いをするところを、犯人のスマートフォンはUSBメモリーと同類のデバイスとしてふるまわず、接続制限が効かなかったと推定されています。

こうしたスマートフォンによる抜け穴は、専門家の間でさえも昨年から話題になり始めていたものでした。この方面の技術動向にくわしい人材でない限り、知らなかったとしても不思議ではありません。すでに対処ができている企業も、まだ少ないと思われます。

それほどに微妙な個所に脆弱性があり、それが今回悪用されたということです。

わたしが気になったのは、この件を受けて、漏えい発覚直後に、本件の責任を取るかたちでベネッセコーポレーションのCIOの辞任が発表されたことです。

確かに、この事件が社会に与えた影響は甚大です。しかし、こと情報セキュリティの問題においては、そうだからといって辞任するのが真っ当というものではないと、わたしは考えています。

情報セキュリティのリスクは、どれだけ対策しても、残念ながらゼロにはなりません。したがって、どれだけ優れた対策を、どれだけ費用をかけて行っていたとしても、事故は発生しえます。今回の問題などは、推定どおりだとすれば「最近までは存在しなかった脅威」が原因ですが、こういうことは将来にも起こりえます。

また特に、内部犯行の防止対策には、限界があるのが現実です。たとえて言うなら、ご自分の自宅の空き巣対策にはある程度の防止策はとれても、家族のだれかが家の貴重品を持ち逃げするのは防ぎにくい、ということに似ています。

もちろん、内部犯行の対策としてできることはあり、情報資産の重要度に合わせてそうした対策は実行すべきです。重要度が高いのなら、技術動向にも感度を高めるべきでしょう。その点で、同社には不備があったのは疑いの余地がありません。

ただし、その不備がどの程度のレベルの不手際なのかは、実際に行われていた措置の内容に依ります。つまり、同社のような規模、かつ同社のように重要な顧客情報を取り扱う事業者であれば絶対確実に実施すべきと、客観的にそう判断される事項が実は行われていなかったのだとしたら、または守る体制の整備をする義務を著しく怠ったと認定されるなら、それはエグゼクティブの責任問題になるということです。

一方、そうではなく、事件発覚前に行われていた情報セキュリティ対策が他と比べてそん色がなかったものの、その穴をかいくぐって犯行が行われてしまったとしたらどうでしょうか。それもエグゼクティブの責任問題だとしていたら、ロシアンルーレットのようにいつか必ず「責任」を取らされることになる情報セキュリティ責任者のなり手は、おそらくいなくなるだろうと思います。

重要なのは、情報セキュリティに知見のある人物が、権限を持って組織をリードし、顧客や社外に明確に説明できる情報セキュリティ対策を実行し、継続して改善を推進することです。事件や事故が起こるたびに責任者が辞任するのでは、組織が混乱するだけで、余計に脆弱になる可能性さえあります。

マスコミや、いわゆる識者と呼ばれる人たちは、多くの場合結果論だけで評価します。問題が発生したのだから、「問題がない」とは言わないでしょう。あとから批判されたくなくて辞めるかどうかは、会社や責任者本人の判断です。しかしわたし個人は、自社が行ってきた取組みをきちんと外部に説明する責任を果たせるよう努めてきたのなら、短絡的に辞任という判断につなげてほしくはありません。特に大手がそういう判断をすると、「事件発生=辞任」という悪しき前例になりかねません。

また、経営者は、情報セキュリティの対策に十分な関心を普段から寄せているでしょうか。そろそろ経営者には部下に対して、「うちの会社は大丈夫か」と聞くのではなく、「うちの会社はどう対応しているのか」と聞いてほしいと、常々思っています。

ITを使いたおす組織のしくみに、通すべきスジ

たまたまなのかもしれませんが、ここ最近「組織のありかた」に関する記事や論考をよく目にしています。

ビジネス分野でいえば、「イノベーションを創出する組織とはどういうものか」「人材育成とは」「リーダーシップとは」 といった類のもの、IT の分野では 「ビジネスに貢献する IT 部門のありかた」「業務部門との人材交流の方法論」 といった類のものです。

わたしの関心分野は 「ビジネスの仕組み」 であり、そのなかには組織の仕組みも含まれますので、とても興味のある話です。こと IT 部門のありかたに関しては、さまざまな取り組み事例があって興味深いものがあります。

同業種であっても、企業ごとに社内環境も文化も異なります。そうなれば、組織づくりのアプローチにしても採用する手法にしても、それぞれの企業で独自に工夫が必要です。組織づくりの方法に、マニュアルや教科書のようなベストプラクティスがないのは、ある意味当然だと思います。

しかし、さまざまな事例を見ていると、うまく組織設計できている企業は、ビジネスとの連動を主眼に組織を最適化させるというポリシーが明確だと感じます。いくらベストプラクティスがないとは言っても、組織デザインの工夫の根底にある思想については、どのような環境や条件であれ、いかにビジネスをうまくオペレートするか、いかに顧客にうまく価値提供をするか、という筋が通っていることが重要です。

IT 部門のありかたに関する論調を読んでいると、次のように考える向きも見かけます。

従来の IT 部門は、汎用業務を支える業務システムを管轄してきました。一方で、ここ最近要求が高くなっている「ビジネスに役立つ情報システム」は、顧客へのサービスを提供するシステムです。汎用業務の情報システムとは毛色が異なるし、既存のシステム運用だけで IT 部門の手はいっぱいです。だから、別の部門を設置し、サービスをつかさどるシステムを運用すべきだ、というものです。

これはこれで、間違った考えだとは思いません。ただし、勘違いしてはならないのは、汎用業務を担う既存の情報システムもまた、本来は 「サービス提供のためのシステム」 であることです。上記でいう 「ビジネスに役立つ情報システム」 との違いは利用者の差、つまり、社外の顧客が使うのか、社内の従業員が使うのか、の差です。

どちらのシステムにしても、それぞれを使う利用者へ何らかの価値提供を行う必要がある。また社内の従業員が仕事をする目的は、直接か間接かの違いはあれど、社外の顧客への価値提供のためであるはず。そう考えたとき、管掌は別々にするとしても、どこか根底でつながっている部分があるはずなのです。

グランドデザインを描いて、そこを見出さない限り、サービス系システムと汎用業務系システムは、まったくの別物として社内に認識され、一貫した思想がなく運用されることになります。それは必ず、ビジネスの全体的なパフォーマンスの非効率につながります。

「IT はビジネスに貢献するべきだ」という議論に合わせて、「ビジネスアナリストが必要だ」ともよく言われます。

この指摘をする人の意見を掘り下げて聞いてみると、およそその人材が満たそうとする領域は  「対象とする個別業務の分析ニーズ」 のように、わたしには聞こえています。

それよりもむしろ重要なのは、その企業が手掛けるビジネスのグランドデザインが描け、そこから個別業務までブレークダウンしていけるビジネスアナリストなのではないかと、わたしは考えています。

組織設計、IT 部門のありかた、必要な人材。一見するとスジの異なる分野に思えて、実際は同じスジが通っている。そんなふうに見るべきではないでしょうか。

「標的型攻撃は防げない」は、セールストークではない

先日、データセンター事業を営む友人から、外部からのサイバーアタックの実態について話を聞く機会がありました。

わたしも情報セキュリティの分野に関しては、ポリシー策定や体制作りのお手伝いをすることがあり、知見や現状に対する認識は持っているつもりですが、それでもなお、その話は衝撃的な内容でした。

あまり詳しくは紹介できないのですが、ひとことで表現するなら、「そこまで洗練されているのか」という印象です。

狙った対象がどんなシステムを所有しているのかを走査してプロファイリングする。不正ログインを試みるにあたって、攻撃相手に気付かれないように十分に時間をあけてログインを試行する。攻撃相手の回線帯域をすべて使い果たすような一斉アクセスを行う。Webサイトに入力フォームを見つけたら、脆弱性をつく攻撃を試みる。攻撃元がランダムに見えるようにアクセスを試みてブロックされることを防ぐ。

こうした行為が「すべて自動で、無差別に行われているように見える」と、友人は語っていました。

ここ最近、情報セキュリティの専門家が、「標的型攻撃においては、狙われたらほとんど防ぎきれるものではない」という趣旨の発言をたびたびしています。実態を聞いて改めて、これはまったく大げさな言い回しではないと、再認識することができたと感じます。

ユーザーの立場ではこうした脅威に対し、予防策としてはきわめて当たり前の対策しか取れません。例えば、パスワードは十分な強度のものを使う、そして定期的に変更する、使用するシステムの脆弱性はアップデートにより最新を保って排除する、余計なシステムは動かさない、ファイアウォールやアンチウイルスなど当たり前のことは必ず適用する、等です。当たり前とはいえ、これらは実際に大きな効果があるので、もれなく実施するべきです。

ただしそのうえで、「カギはきちんとかけたとして、それでも破られたらどうするか」という事後対策もまた、十分考えて整備しておく必要があります。この対策には、攻撃を検知できる手法や攻撃に対応できる技術、また反応できる体制が必要です。そのスキルがないのなら、それを持つパートナーを探しておくことも、取るべきアクションのひとつになります。

特に重要なのは、「体制づくり」です。

前記の話をしてくれた友人は、実際に攻撃を受けた企業でも、まったくその実感がわかず、適切な対応の指示をしないようなCIOが、実際にいたというエピソードも話していました。CIOであるにもかかわらず信じられないことですが、意識が低く知識もないと基本的な反応さえできないという、典型例ではないでしょうか。それはまるで、急病人が目の前に倒れているのに救急車を呼ぶことを思いつかない、というのに似ていると感じます。

 

トラブル事例で痛感する、「ガバナンス」の意味(2011年12月)

先日、わたしが参加しているある勉強会で、なかなか聞けない貴重なお話をうかがいました。システム委託開発でのトラブルが訴訟にまで発展したケースに関するもので、その経緯を当事者であった方が直接お話しされたのです。

この事例では、契約書に対する相互の認識が不明確であったがゆえにトラブルに収拾がつかず、最終的には互いに提訴しあう形で裁判になりました。いま係争中のスルガ銀行と日本 IBM との裁判と、かなり似ています。

わたしがこの話の中で気になったことのひとつに、「業界経験のないベンダーに任せてしまった」というものがありました。このユーザー企業は、委託ベンダー側に自社の業界でのシステム開発経験がないことを知っていたのに、結果的にはコスト重視で発注してしまったとのことでした。

なぜ経験のないベンダーを選定してしまったのかと聞くと、

「本当は開発せずに既存ソフトの移行だけで済まそうと計画していたところ、実はコストが予想以上にかかることがわかり、上層から開発に切り替えるよう言われてしまった」

「別に大規模プロジェクトが社内で並行しており、新たなプロジェクトが突然降って湧いても、そこに割ける社内の人員がいなかった」

「対象のシステムは保守期限が迫っており、時間がなかった」

との回答が返ってきました。

想定外の、やむにやまれぬ事情があったというわけです。ただ、わたしは一方で、この話を聞いて、意思決定プロセス設計の盲点と難しさを感じました。

このケースでは、もともとコストも時間もかけない「ソフト移行」という方法を採ろうとしていました。ところがそれでは予想外にコストがかかるということがわかり、計画は突如として「ソフト開発」に変更されたわけです。この際に、「上層が『開発』するよう判断」したということですが、この判断は結果的には誤りでした。

通常の意思決定のプロセスであれば、プロジェクト推進可否の決定は、戦略委員会や PMO のような合議制の組織を母体にして、コストパフォーマンスはもちろん、プロジェクトリスク、組織リソース、納期順守、ベンダー評価など、さまざまな視点から評価を行うものです。こうした評価を行っていれば、「大規模プロジェクトが並行しているからリソースが足りない」ことも、「保守期限に間に合わせる必要性」も、「ベンダーリスクの高さ」も、検討の俎上に載っていたはずです。

このプロセスが、「突然の計画変更」かつ「時間がない」という事情で、実施されませんでした。わたしが想像するに、「上層による開発の判断」というのは、おそらく特定の人物の(言い方は少々悪いですが)独断であったのではないでしょうか。

こうした課題は、いわゆる「ガバナンス」の問題です。「ガバナンス」を設ける意味は、「透明性の確保」「判断スピードの速さ」「判断の安定化」といったことにあると思います。

つまり、どんな課題に対しても関係者のだれもが同じ判断をスピード感を持って下せる、という状態をつくり出すのが「ガバナンス」を設ける目的だということです。

もちろん、場合によってはスピード重視で即決判断が必要な場面もあります。ただ、人間は合理性よりも面倒の回避を優先するところがあります。それを許すと判断が偏ったり不正確になるリスクがありますから、即決判断する場合も、その条件と責任の所在を仕組み化します。実際、CEO による即決のプロセスをガバナンスに組み込んでいる事例もあります。

ガバナンスというと何か堅苦しいものと考えてしまいがちですが、本来は、「組織にとって最も有効なオプションを迅速に選択するための手法」なのです。逆に、ガバナンスを「面倒なもの」と捉える環境ができてしまうと、判断を間違う確率は高まります。

このあたりは、J-SOX に対する考え方も同じです。J-SOX を会計監査上のルールとしてやむを得ない対応事項と捉えれば、面倒が先に立ちます。一方、J-SOX を「正確な財務集計をハイスピードに行うための仕組みづくり」と捉えれば、モチベーションが変わってこないでしょうか。

今回話をうかがった裁判のケースでも、いったんは通過した意思決定プロセスにもう一度乗せて判断していれば、訴訟によって膨大なエネルギーとリソースをそがれることは、そもそもなかったかもしれません。もちろん、結果論ではありますが。