高度になるIT、問われる組織の能力

ここ最近は、クラウドにまつわるセキュリティ事故の話が目立っていたように感じました。

例えば、セールスフォース・ドットコム(以下、SFDC)が提供するクラウドサービスを使う複数の企業において、第三者が非公開情報にアクセスできてしまう状態になっていた問題。この問題では、名のとおった大企業、情報セキュリティに関しては高い管理知識を有するはずのIT企業などが、挙って同じ問題に陥ったことを公表しました。

SFDCに関連した問題のほかにも、グーグルが提供するクラウドサービスを利用する企業で内部の業務連絡のやり取りが気付かぬうちにオープンになっていた問題、某キャッシュレス決済事業者における加盟店情報約2007万件の漏えい事件、なども報道されていました。

上記で取り上げた問題に共通する要因は、「設定ミス」です。設定の不備によって、本来公開してはいけない情報が一般公開設定となり、インターネットから閲覧可能な状態となっていた、というわけです。

一般に、クラウドサービスを利用するにあたっては、さまざまな設定を利用者の責任の下で実施することになっています。従って、設定にまつわる障害や事故は利用者側の問題として扱われるのが通例です。

ただし、今回のSFDCの問題は、利用者の対応の甘さに全面的な責任があるとは必ずしも言えない面があるように、わたしは感じます。というのも、設定不備の原因となったのがSFDC側による機能のバージョンアップにあるからです。約5年前に行われた機能追加にその火種があり、その際に、新機能の導入により適切な権限設定をしなければ情報漏えいにつながる可能性が生じたといいます。その旨の情報が利用者に適切に提供されていなかったのではないか、そもそもSFDCはそのような脆弱な設定になり得ることを予測していなかったのではないか、という声が少なからずあるとのことです。

つまり、知らぬ間に外部のアクセスを許す状態になっていたという利用者が大勢いたということであり、それは利用者側の「設定ミス」として片付けられるものなのか、という認識が生まれるわけです。至って自然な考えではないかと思われます。

しかしながらこのような状況を踏まえてもなお、結局は利用者が被害や影響を受ける立場になることに変わりはないのが実情です。クラウドサービスは、提供者側の都合でアップデートや機能追加が頻繁に行われます。それが良さであるという評価も一方ではあります。クラウドを利用するということはつまり、利用者が提供者に振り回される面がある、という理解が必要なのです。

設定ミスは人為的なミスなのだから、使う側が気を付ければよいことではないか、と思うかもしれません。実際に使ってみればわかることですが、クラウドサービスは、使い込もうとするほど、または機能が豊富で高度な要求を実現できるものほど、設定は単純では無くなっていきます。利用者側にも、それなりの「ユーザーレベルの高さ」が要求されるのが実態です。それはある意味、当然のことでもあります。

先日セキュリティの専門家から話を聞きましたが、サイバー攻撃の攻撃者がどのような攻撃手法を好んで選択するのかというと、端的に言えばコストパフォーマンスが高い手法が優先されるといいます。かつては多かった、自らの技術を誇示したい攻撃者というのは近年ではほぼ皆無で、手っ取り早く価値の高い情報を搾取し、お金に変えることを目的にしているのです。そのとき、一番コスパが高い狙い目というのが、実は設定ミスや運用ミスを突くことだと指摘していました。

クラウドは利用のハードルが低く、その気になれば利用の幅をいかようにも広げられる面があります。一昔前なら何千万円と支払わなければ手に入れられなかったような技術を、月数千円程度で利用できるようになっています。技術的に出来ないことは、もはやほとんどありません。これは、ITの急速な技術進化の賜物です。

ただし、利用する側にそれを操れるだけの組織的能力があるのかどうか。利用する企業は常にこの点を、自問自答する必要があります。能力を持たざる企業に高度なITが使いこなせないのは、プリウスに乗っていたドライバーが今日からF1カーを乗りこなそうと思ってもできないのと同じです。

特に中堅中小企業は、ITにかかる組織の整備が脆弱な傾向があります。クラウドをどんどん使おうとするわりにIT担当者は兼務しかいない、でいいのか?経営者の方々には、自社で何らかのITを使おうとするなら、まずは組織能力を問い直すこと、いかに整備を進めるか考えること、をお勧めしたいと思います。そうでなければ、安易な設定ミスにより足元をすくわれるリスクを抱えることになります。

デジタル化を始める前に、経営者にやめてほしいこと

いざデジタル化を本気で考えようとなった時、その会社の経営者が真っ先に考えやすいのは、ITをリードしてくれる人材を外から採用しようとすることです。

特に中堅以下の企業で、これまでITに “本気で” 取り組んでこなかった場合、社内にそれにふさわしい人材が不在であることが多くあります。育てようにもポテンシャルのある人材はいないし、いたとしても今度は育成ができる人材がいない。それであれば、いわゆるプロ人材か、大手で活躍するなど優秀な経歴を持った即戦力人材を取り込みたい。そう考えるわけです。

無理のないことです。ただし、この際に経営者がやってはいけないことがあります。それは、日本の経営者に顕著にみられる悪しき習性、「丸投げ」です。

「丸投げ」する経営者は、いわゆるプロのIT人材を雇うと、あとはその人物にITは全て任せてしまえばよいと考えます。なんとなくやりたい(が特に本気度が高いわけでもない)と思っていることだけ伝え、「何とかしてもらいたい」程度の指示しかしません。

つまり、経営者が課すITに対する要求は、ほとんどゼロ。ポリシーも指針も特になし。読んでほしいのは空気くらい、と言ったところでしょうか。

そうなると、任されたほうのプロ人材はどうするか。自分の好きなようにデジタル化を進めていきます。

「自分の好きなように」というのは、具体的には人によって異なるわけですが、ひとつ言えるのは、その企業の目指す姿を深掘りしてそれを強化しよう、支援しよう、とは ”考えない” ことです。まず、わかりやすい成果を出すこと、その次に、先進事例で取り上げられそうなネタに取り組むこと、それによってマスコミに取り上げられて有名になること。あわよくば何かの賞でももらえたら最高。およそそんなような方向で物事を進めるでしょう。

そうして出来上がるシステム基盤は、なんだか成果は出たようだけれど、そのプロ人材でしかコントロール不能で、周りにはよくわからないものになります。

このような取り組みを進めて「実績」を挙げた当のプロ人材は、自らの市場価値を高められて満足し、ほかの企業にまた転職していきます。そして残されたシステム基盤を、残った人材でメンテナンスし使いこなしていくことになります。それが難しいこと、会社がそのシステムに何となく引きずられていること、そんな負の側面は、社内で徐々に実感されていきます。

ここまでお話ししたシナリオは、外部人材を採用した場合の典型例のひとつです(ほかにもありますが、明るい話はあまりありません)。元々、経営者はプロ人材を雇ってデジタル化を進めようとしました。そんな経営者にとって、これで何が変革できたと言えるでしょうか。

実は、何も変わっていません。もしかすると、余計な資産を背負ってしまってマイナスかもしれません。しかしその要因は、丸投げした時点でつくられています。IT専門人材の問題なのではなく、経営者の問題なのです。

この「丸投げ」問題は、実はITだけでなく、営業、財務、商品企画、生産、広報など、あらゆる業務分野で起こっていることです。それもそのはずで、同様な考え方でプロ人材に丸投げすれば、他の業務でも同じシナリオになります。それにより、経営は現場のことがよくわからず、現場は自分の持ち場のことしかわからず、それぞれが個別のやり方に固執する部分最適が横行する会社となります。

そういう会社は、デジタル化を考える以前に、経営者が一念発起して社内を変え、全体を俯瞰し統率できる立場を取り戻す必要があります。それができていないなら、どんなプロ人材を入れようが、どんなシステムを導入しようが、ビジネスに永続的な進化をもたらすことはありません。

デジタル化を始めるなら、まず経営者が「丸投げしない」と心に誓うことから始めていただきたいのです。デジタル化について自ら徹底して考え抜き、自らが思うデジタル化を、自分が主導して進める。そういうポリシーを持ってから、人選していただきたいと願っています。

アフターコロナでは「ジョブ型雇用」なのか

アフターコロナにおける企業のスタイルとして、ジョブ型雇用も話題になっているようです。複数の大手企業が本格的にジョブ型雇用を実践すると宣言したといいます。

ジョブ型雇用というのは、職務記述書(ジョブディスクリプション)によって職務内容や期待する業務成果を規定し、それに基づいて社員が業務を遂行するという雇用形態で、欧米では一般的なスタイルとされています。そのジョブディスクリプションに基づいて、報酬も決定されます。

労働時間よりも成果によって評価を行おうとする流れにおいて、ジョブ型雇用というのはそれにフィットするように感じられるかもしれません。しかし、6月のコラムで論じた通り、成果主義に基づく制度にするなら的確な業務分解と設計が必要であり、同様のことがジョブ型雇用にも当てはまります。

加えて、ジョブ型雇用には、従来の日本型雇用スタイルでは考えもしなかった負の側面があることも念頭に置いて、その是非を議論すべきです。

例えば、あるITエンジニアをシステム開発要員として採用したとします。この人材をジョブ型雇用で採用した場合、ジョブディスクリプションには、従事してほしい開発分野や職務レベルに関して詳細な記述が盛り込まれ、会社と当人の間で合意が取られます。一種の契約です。

ご承知のとおり、ITの分野はシステム開発以外にも、システム企画・システム運用・技術調査・研究等々と幅広いものがあります。開発の分野だけでも、専門により細かい分解が可能です。

将来は社内のITリーダーになってもらおうと考えた時、日本の会社の管理職層のほとんどは候補の社員に対し、俯瞰できるだけの幅の広い経験を有することを重視するでしょう。会社によっては、技術だけでなく営業も経験してほしい、という意向を持つことも珍しくありません。

日本型の雇用スタイルなら、このような人事異動はなんら問題ありません。ところが、ジョブ型では問題になります。採用した人材は、ジョブディスクリプションの記述に基づいて職務を遂行しますが、それは裏を返せば、規定外の職務には一切対応しないということでもあります。先述のとおり、ジョブディスクリプションは契約です。その人材は、ジョブディスクリプションを盾に、異動を断ることができるのです。外国人社員ですと、実際にそうします。

ジョブ型雇用は、実力と経験を一定以上兼ね備えた、いわばプロ向けの制度です。プロは、成果で評価されます。プロは、成績が悪ければ報酬も減額になりますし、戦力外通告もありえます。その意味では、管理職やビジネスリーダークラスの人材、または特化した専門性を有する職種に対してであれば、機能する制度であるといえます。

一方で、まだ育成段階で安定した成果を企業にもたらすのは困難である若年層の社員に向いている制度ではありません。もし無理やり適用すれば、狭い領域の仕事しか知らない人材しか育成されないうえ、社内ではジョブローテーションがまるで成立しない状態になるでしょう。それはつまり、仕事が人に紐づく属人化の進行を意味します。属人化が進行した業務は、その担当者がいなくなることが経営リスクになります。

また、有能な人材を採用するならジョブ型雇用だ、というような論調も一部で見受けられますが、そういう考えもまた短絡的だと、わたしは思います。

ジョブ型雇用とはひとつの方法論であり、本来は、国籍も経歴も関係なく、社員が実績と努力次第で自ら望むポジションを得られる公平な人事制度を構築することが大きな目的になっています。有能な人材が興味を示してくれるかどうかは、本来その会社の事業や仕事が魅力的かどうかなわけで、ジョブ型雇用であることは2番目以降の理由にしかならないはずです。ましてや、報酬に惹かれて採用を決めるような人材は、数年もすれば報酬をネタにして他の会社に転職していくでしょう。

いかなる場合でも、先立つものは「どうあるべきか」「どうありたいか」という具体的な意志であって、ジョブ型か否かといった方法論やソリューションではありません。方法論など、自らの意志に従って好きなように使い分ければよいことです。

人材は、ビジネスのしくみをドライブする存在です。どれだけ素晴らしいしくみをデザインできても、それをドライブできなければ、仕組みは無用の長物と化します。マスコミに振り回されることなく、まずは人材に対する自らの考えを見える化するところから始めることをお勧めしたいと思います。そのうえでフィットするなら、ジョブ型はあり、ということになるでしょう。

蛇足ですが、去る6月24日に、ファーストリテイリングの柳井正会長兼社長が、京都大学における医学研究に個人として総額100億円を寄付すると発表しました。欧米では、大物の事業家や経済人が何億ドルという自己資産を新型コロナ対策に寄付する動きが多くあります。こうしたことなら、素直に欧米のマネをしてほしいと思う次第です。

情報セキュリティの責任を負うのは、誰か

最近も、防衛産業を担う複数の大手企業で、情報漏えいの可能性がある不正アクセスがあったことが公表されました。それらの企業のなかには、防衛産業を担うと同時に、情報セキュリティに関連したソリューションも販売しているところがあります。いわば、情報セキュリティ対策の面ではトップクラスの組織であったはずです。そうした企業でも不正アクセスにもろさがあるという現実を、再び突き付けられたと感じます。

つまり、「攻撃されれば成功されてしまう確率は高い」という前提で、モノを考える必要があります。

そんな中で、気になる記事を見かけました。米国と英国での調査だということですが、企業のCISO(最高情報セキュリティ責任者)は強いストレスにさらされ、休日でも気持ちが休まらず、結果として健康を害する人も少なくなく、平均在任期間は26カ月だった、という内容です。

記事では、CISOの仕事の現実を、次のように表現しています。

(記事からの引用)
現在のCISOの仕事は、低予算で、労働時間は長く、経営陣に対する発言力も小さく、雇用できる訓練された専門家は減る一方で、しかもサイバー攻撃に対抗できるインフラを十分に整えられないストレスに恒常的に晒され、常に新たな脅威のプレッシャーを受けている。そして、よい仕事をしても褒められることがない一方で、何かが起これば全責任を負わされるという過酷なものだ。

日本の中堅中小企業で、CISOを置いているところは、ほとんどないだろうと推察します。ということは、上記のような役割を担うのは社長自身であると言えます。その場合、平時は上記のような窮屈さもストレスもプレッシャーも感じないでしょうが、いざ情報セキュリティに関する問題が明るみに出れば、途端に「全責任を負わされる」という状況になるでしょう。

だからといって、「では責任を負ってもらえる専門人材を雇えばよい」という発想もまた、問題があるわけです。情報セキュリティの問題を、特定の責任者が全責任を負う問題に帰結させるべきではありません。わたしは2014年に、ベネッセコーポレーションで大規模な個人情報漏えい事件が発覚した際に、この点について当コラムで指摘をしました。同社でもこの事件の際、当時のCIOが責任を取って辞任しています。

先に申しあげたとおり、「攻撃されれば成功されてしまう確率は高い、という前提で、モノを考える必要がある」のです。どんなに実績がある優秀な情報セキュリティ人材を採用しようが、これは同じです。

情報セキュリティ対策を整備するなら、その体制や各種の具体策は、社長以下「組織」の総意で立案し合意するように検討を推進するべきだろうと思います。

具体的な対策を立案するにあたって、それをリードする専門人材は必要でしょう。ただし、立案する対策に責任を持つのはあくまで組織であって特定の責任者に帰属させない、例えば委員会組織をつくってそこで議論と承認を行い、責任は委員会組織で持つようにする、という体制にするべきです。そしてそれを明確に社内に示し、関係者には無用なストレスを感じることなく従事してもらいます。

一方で、「攻撃されれば成功されてしまう確率は高い、という前提で、モノを考える」とすれば、どのレベルまで対策を高度に整備すれば必要十分なのか、も課題になりやすいかもしれません。

この点についてわたしは、その会社なりに徹底的に考えたことが対外的に説明できるならそれで十分、と考えます。何らかの攻撃をされ、何らかのリスクが現実のものとなり、対外的に公表や謝罪をする必要が発生した時、会社は説明責任を求められます。このときに対策の努力を認めてもらえるだけの説明ができるかどうか、という判断基準です。

事故が起こった以上は、批判は免れないでしょう。しかしその際に、「無策で穴だらけだった」と思われるか、「できることはすべてやっていたが不十分な点があった」と思われるかでは、雲泥の差があります。また、考え抜かれた対策がすでにあるのなら、その問題点を認識して補う行動もしやすいものです。逆に、たいして考え抜かれていないなら、有事の際に素早い対応はできず、傷口はさらに広がります。

大事故になればなるほど、社会的な影響が大きな事故であるほど、CISOがいようがいまいが、説明責任は社長自身が果たさなければなりません。それは、過去の大企業での情報セキュリティ事故における、記者会見の報道などを見てもわかることでしょう。そのとき、言いよどむことのない説明を行うことができるのか。経営者の方々には、このような視点で自社の情報セキュリティの体制と対策を、見つめていただければと思います。

「ベンダー丸投げ」と「経営丸投げ」

情報システム開発のお作法で忌み嫌われるもののひとつに、「ベンダー丸投げ」というものがあります。

これは端的に言えば、発注側がIT業者にシステム開発を委託するにあたって、自らは主体的に関与せず、開発方針や要求もあいまいな状態で、自身が本来すべき仕事でさえもIT業者に「丸投げ」してやらせることを意味します。その結果として出来上がる情報システムは、言わずもがなですが、発注側にとって満足のいかないものになります。質の悪い発注者ですと、その原因は自らにあるにもかかわらず、IT業者側の能力不足にしたがります。

わたしは今の仕事を始めるまでは、これはIT業界特有の話かと思っていました。しかし、多くの事例を見るにつけ、経営の分野でも似たようなことがあると知りました。

企業において、経営者は人を雇います。企業が成長し、組織力が必要になれば、人材が必要になることは必然です。経営者が人に任せるというのは、当前に行われる行為です。

ただし、人に任せる際に、任せようとする側に要求されることがあります。それは、任せる側が何を実現したいのかというポリシーの立案能力と、それを周囲が理解できるように伝える伝達力です。冒頭の「ベンダー丸投げ」においても、発注側に欠けている能力は、大きく分けてこの二つです。

経営者にも、丸投げするタイプがいます。自分では能力的に難しい分野のことを、自分の仕事ではないとして、担える人材を採用し、担当させます。もちろん、優秀な人材を採用して任せることに何の問題もありません。積極的にそうすべきです。ただし、自分はわからないからと言って何のポリシーも示さず、結果やプロセスのモニタリングもまともにしないとすれば、それは冒頭の「ベンダー丸投げ」と同質です。

ポリシーを打ち立て、それをうまく表現して伝える力は、経営者やリーダーにとって死活的に必要な能力だとわたしは考えます。これを疎かにしたまま、人を雇って担当させることを続けるとどうなるか。任された人は従うべき指針が曖昧なので、自分の考えを主体に物事を推進しますが、その人は大抵、ビジネスの全体を俯瞰して見られません。従って、組織は部分最適の道へ進んでいきます。

実は、部分最適な組織でも、優秀な人材を抱えられたなら、売上はそこそこ上がります。そのため、何の問題も感じない経営者も多いようです。ただしそういう企業は、経営者の潜在意識にあった売上目標に達したり、マスコミに取り上げられてチヤホヤされるにようなったあたりから、あまり伸びなくなります。そして、伸びていない理由が思い当りません。

一方、目標の基準を、自分が実現したい理想が顧客や社会に認められたのか、というようなことに置いている経営者は、そこそこ売り上げが上がったくらいでは満足しません。そういう経営者は、自分が実現したい商品やサービスが本当に提供できているかにこだわっているからです。どこまで行っても、改善の糸口を思いつきます。

またそういう経営者ほど、任せた他人がやっている仕事を、全体俯瞰の視点で厳しく見極めます。ただし、ブレない軸を持っているので、任されている側は、何をすれば高く評価され、何をしたら怒られるのか、わかりやすいのです。

そういう企業が築き上げるビジネスシステムは、他にはないものになります。

能力のある人材に頼るのはもっともなことです。ただし、際立つ企業のリーダーを見ていると、設けた柵の中で「放牧」はすれども「放任」はしていません。全体のうちのどの部分を切り離し、そこにどのような成果を求めるのか、任せる側がこれを意図的にデザインしないとすれば、やはりそれは、スジのとおった意志のない「丸投げ」なのです。

 

大事なのはCIOなのか、CDOなのか

最近、CDO(Chief Digital Officer)という役職が話題に上るのを見かけます。この役職を置く大手企業がいくつか出てきているそうです。

CDOは、わたしの認識が正しければ、IT 系の大手リサーチ会社である米ガートナーが提唱し始めた役職名で、簡単に言えば、企業においてビジネスのデジタル化を推進する責任をもつ経営幹部と位置づけれられています。

これに関連するところでは従来から CIO という役職があり、CIO が IT に関する領域の責任を持つとされていました。そこにまた、CDO なる役職名が登場し、何がどう異なるのか、きちんと理解しておく必要があるのか、自社に必要なのか、よくわからない経営者の方もいるのではないでしょうか。

結論から申し上げれば、他人との会話にお付き合いできる程度に知っておけば十分だと、わたしは思います。業界お得意の話題づくりに振り回されるのは、本質的ではありません。

一般的な説明においては、まず CIO は、企業が従来から管理してきたバックエンドの情報システムを中心に、その運営に責任を持つものとされています。かたや CDO は、顧客に向けたフロントエンドに注目し、デジタル化による顧客体験を提供する「(広義での)サービス」を提供するシステムを構成し、その運営に責任を持つというイメージで語られています。

ここからはわたしの個人的な見解ですが、CIO とは、Chief Information Officer の略であるのが一般的とされますが、同時に Chief Innovation Officer とも言えるとされていました。そして、CDO という言葉が出てくる以前においては、いま CDO が司るとされている領域の活動には、CIO が貢献することが期待されていました。

ところが、現実の CIO がそのようなイノベーティブな成果を実現するケースはほとんど見受けられませんでした。こと日本においては、CIO と呼ばれながら、例えば実は経営会議のメンバーではない等、情報システム部長と変わらないような職務権限であるケースも多かったように思われます。そもそも「CIO」という役職名が企業にそれほど広がらず、IT 関係の幹部を紹介する際にマスコミも苦し紛れに「実質的な CIO」などと称する例もよく見かけます。

CIO って結局は IT 部門の責任者なのね、という、本当はそんなはずではなかった認識が定着する一方で、やはりビジネスの本質的な領域への IT の浸食は止まりませんでした。新興企業を中心に、デジタル的な思考をベースとしたビジネス基盤で事業を展開するケースが後を絶ちません。おそらく今後、それが当たり前になるでしょう。

そうした中で出てきたのが、CDO です。根底には、従来型の情報システム整備の考え方と、デジタルビジネス推進の考え方は、同じにはできないという主張があります。この主張については、わたしが以前にブログで記したとおり、認識が確定しているわけではありません。

こうして考えてみると、要するに重要なことは、企業自身が、自社のデジタルの責任者にどのような活動で成果を挙げてもらうのかを明確にし、その役割と権限をその企業なりに定義することではないかと思います。それさえできていれば、CIO でも CDO でも、IT 責任者でも、それこそ CEO でも、名前など何でも構わないのではないでしょうか。

会社の基幹機能をどのようにカテゴライズし、幹部が会社のどのような基幹機能を担うのか。デジタルはそこにどう絡むのか。これを考えるほうが、より本質に近づくはずです。トレンディなことばを気にしすぎるのは、もうやめましょう。それでメディアに乗っかりたいのなら別ですが。

CxO人材が欲しい会社が、考えるべきこと

最近、あるスタートアップ企業が躍進しているという話を聞きました。

その企業は、当初は事業の拡大にいろいろと苦労していたそうですが、あるとき大手企業の幹部OBを紹介され、その人物に経営に参画してもらうことになりました。それをきっかけに、その人物が培った人脈をフル活用して次々と人が人を呼び、最近では大手企業との提携話が面白いように決まっていく状態になっているようです。

経営者ご自身の人徳もあろうかと思いますが、こうしたパターンは、スタートアップがいわゆる「1→10」に成長していくシナリオとして典型的かつ有力なものだと思います。

こうした事例もあるためか、多くの企業で経営者が幹部人材を探すとき、およそ重視するのが「前職での地位」や「持っている人脈」です。

それはそれで、特に営業面では重要な経歴だろうと思いますが、ことCOO、CIO、CTO、CDOのような幹部であれば、ステータスだけで善し悪しを判断するのは慎重であるべきではないかと思います。

業務構造の変革、システムの適用、それに伴う技術の採用、というのは、素晴らしい経歴があればできるというものではありません。経営者のツルの一声で始めたIT導入がおよそすごい成果にはならない例が多いことからも、これは明らかです。

このコラムでも何度も申し上げていますが、ビジネスを強くするには、慎重かつ緻密に、ビジネスのしくみをデザインすることが必要です。こうしたデザインを実行するには、社外の競争環境のみならず、社内の業務環境や企業文化を熟知していることが求められるのは、言うまでもありません。

ですから、外部から来た人材は、まず社内を知ることから始める必要があります。わたしなども、初めて関わるお客さまのところでまずすることは、社内の各部門を回って話を聞き、情報を集めて現状を知ることです。

結構地道で泥臭い作業ですが、欠かすことはできません。なぜなら、自分の目で現場の現実を見ないかぎり、真の課題は理解できないからです。誤解を恐れずに言えば、現場で働く方たちの「ことば」さえ信じないこともあります。時に、言っていることと実際にやっていることが異なる場合もあるからです。

業務やシステムを管轄する幹部に求められる力とは、こうした実地での情報収集、状況把握、現状分析、技術への知見などを総合し、その企業が目指す方針を実現できるビジネスのしくみをデザインする能力、さらにそれを実現まで持っていける能力ではないでしょうか。

この能力は、前職の地位や人脈が保証してくれるものではありません。かりに実績があるとしても、その実績を挙げるに至った経緯をよく聞いてみる必要があるだろうと思います。単に誰かの言うとおりにしただけかもしれません。

また、特に技術、ITといった分野は、デザインの意識が低い人ほど技術的な「理想」を追い求めてしまいがちであることも、よく念頭に置くべきだと思います。

最近ですと、「ビッグデータ」とか「AI」の経験を持つ専門人材が欲しい、という話を小耳にはさむことがありますが、危険な例です。ITはある意味、その道に明るい人間にとってはわりに手柄を立てやすい分野とも考えられます。そのようにして採用した外部招へいの幹部は、その分野だけで自分の存在価値を示そうと動くでしょう。しかし、技術にフォーカスするのみでビジネスのしくみを緻密にデザインしようとはしないときに、または全体俯瞰でしくみを考えている人が会社に誰もいないときに、それはその企業にとって、どこか歯車のずれた取り組みになっていくことが往々にしてあります。あるITを導入してはみたけれど、現場が使いこなせずに結局お荷物になったというような話、聞いたことがないでしょうか。

そして、その問題に最初のうちは誰も気づきません。

くどいようですが、業務改革やシステム導入では、あらゆる観点から理想と現実をうまく埋める「デザイン」が、最も大切です。CxOを探すのなら、そういうことを重視し、偏りのない知見を発揮できる人物かどうかを、ぜひ見抜いてください。

足りないIT人材、差を生む行動

先日、大学で受け持っている講義で、ITを活かしてビジネスをリードできる企画人材は社会的に不足していること、そうした人材は探してもなかなかいないので、難しくても企業内で育てていくことが必要、と話したところ、ある学生(といっても社会人の学生です)が、「そもそも人材が不足している中で、そういった人材を育成出来る人が企業内にいるのでしょうか」と質問をしました。

おそらく多くの企業の経営層も彼と同じような発想をしているのではないだろうか、と思いました。

人材不足は、日本に限ったことではありません。欧米に比べて日本の企業はITが遅れているという論調は、よくマスコミの報道で見受けられます。確かにそういう側面はあると、わたしも感じます。ただし、欧米の企業は日本と同じことで悩んではいない、というわけではないようです。

例えば欧州に関しては、こんな記事が出ていました。

「最近の調査・研究では、ヨーロッパのIT分野におけるリーダーの指導者としての素養・力量はかなり低い、という結果」
「国家レベルでこの問題に適切に取り組まなければ、EUのICTの専門家は2020年には82万5000人が不足すると試算」
「欧州の多くのビジネススクールや大学が「eリーダーシップ」養成のプロジェクトを検討している」

米国に関しても、社会的に人材は足りているという話はあまり聞きません。例えば、こんなデータがあります。

「(CIOに調査した結果)39%がデータ分析スキルが自社に不足していると回答、続いて32%がプロマネ、28%がビジネスアナリシス、27%がサイバーセキュリティと回答」

つまり、人材は世界中で不足しているのです。

必要であるにもかかわらずこれだけ不足しているからこそ、自分で考えて実際に行動を起こしている企業が先を行っている、ということではないでしょうか。

経営者であれば、担当者と違ってさまざまな手を打てる力を持っているはずです。人材そのものを調達するなら、雇用、コンサル、業務提携、時限的に委託、いろいろあります。

いまスキルがなくてもやる気はある人材がいるのなら、幸運です。世の中にはシステム企画のうえで参考になるフレームワークや標準もいろいろ公開されていますから、そういった情報を知って、社内に勉強を促すこともできます。

最もまずいのは、ビジネスとITは直接絡まないという、致命的な誤解です。ITには一切頼らない、という奇特な決意をしている企業でない限り、ITと関わりが不要な企業は、現代では存在しえません。

そうであるなら、自社で使うITは「使える情報システム」にしたいはずです。ところが、自社にとって「使える情報システム」というのは、自社が実践するビジネスの仕組みからしか生まれないのです。

そして結局のところ、自社のビジネスを進化させる企画力を持つには、いまの自社のビジネスの仕組みが可視化できることがキモで、これができるのは社内の人材だけです。だから、社内の人材が自分でシステムの絵を描けなければ、将来が危ういわけです。

ビジネスを洗練させていくうえでどれだけ仕組みやシステムが重要であるか、それに対してITがどれだけのポテンシャルを持つと考えるか、という認識の差が、何らかの手を打つという行動の差を生むのだろうと思います。

冒頭の質問をした学生には、「育てるのが簡単でないことは講義でも述べている通りですが、そこで思考停止するかどうかが分岐点」だと回答しました。

会社でやったらダメな「議論」

最近、「議論」ということばによって人が抱くイメージについて、考えることがありました。

わたしは大学で講義を担当していますが、そのなかで「議論」をしようとすると、恐れる人、そうでなくても少なくとも緊張する人が多くいることを感じています。意見を交わそうとすると非常に遠慮がちになるし、説明が不十分な点を問うとすぐに撤回するし、さらにはそれ以前に反応しようとしない人もいます。時々ですが、それとは逆にこちらと”戦おう”とする勇敢な?人もいます。

これはマスコミの影響が非常に大きいのではないかと、わたしは考えています。識者と言われる人々がエンドレスで言い合いする”朝まで○テレビ”のような「議論」、与野党が激しく対立するところだけフォーカスする国会での「議論」、ソーシャルメディアでの発言をきっかけに炎上騒ぎになる「議論」。メディアでは、およそこんな「議論」ばかり取り上げられているように思います。

それらを目にすることで、「議論」とはああいう知識の弱肉強食合戦のようなものだと考えて、恐れたり関わりたがらなかったりという反応になるのではないか。そんなことを考えています。

わたしの考えでは、論破されるか合意するかに関わらず、意見を交わした結果として最終的に何の納得も得られない「議論」は、議論とは言えません。したがって、マスコミがこぞって取り上げるような前記のものは「議論」ではありません。テレビでやってもらうのは一向にかまいませんが、会社でそのような議論をやったら絶対にダメです。

しかし、会社の中であっても、あるものが欠けていると、実にカンタンに「マスコミが好む議論」が会社でも展開されてしまいます。関係者間で意見の対立が起き、侃々諤々の主導権争いをするも折り合わず、最後は社内政治で決まる、というような、「それなら最初から議論する必要はないだろう」というような話です。

その「あるもの」とは、関係者間での共通認識です。

会社であれば、「当社はどういうビジネスを展開して発展していきたいのか」「お客さまにどういう価値を提供したいのか」「どういう行動により社会の役に立とうとするのか」といったものが共通認識になりえるものでしょう。ミッション、ビジョン、といえば聞こえがいいですが、それよりもさらに理解を具体化したものでなければ不十分だと思います。

こういうものがあることで、関係者間で「我々はどうあるべきか」「何を成し遂げるべきなのか」「どのような仕組みを実現すべきなのか」という認識が共通化されるわけです。

いわゆる「マスコミが好む議論」には、この共通認識が参加者の間にありません。場合によっては、それを互いに持とうとしません。だから、エンドレスで議論しても結論がないのです。

こうした共通認識のないまま、例えば「クラウドはどうするか」という「議論」を会社で行ったなら、クラウドはやるべきだという勢力と、クラウドは慎重に扱うべきだという勢力が、真っ向から対立する構図になり、最後は声の大きなほうが勝つでしょう。それはまったく本質的な結論ではありません。その会社のやりたいビジネスに照らし合わせた時に、クラウドはどう活かせるのか、自分たちの役に立つのか。そういう議論をすることが、意味のある結論を導く唯一の道ではないでしょうか。

当然のことですが、この共通認識を持つにあたっては、経営者もそこに参加していなければなりません。それが意識的にできているなら、たとえよくわからないITの話を持って来られても、なにも恐れることはないはずです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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