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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Want to の目標と、Hope to の目標

システムの構築とはつまり、ビジネスを実行するうえで「実現したい」と思っていることを実際にカタチにすることだと思います。

これは、多くの人にとって容易なことではありません。例えば、他人から「あなたの考えを文章にしてください」と言われたり、「あなたの頭に思い浮かんでいることを絵にしてください」と言われたりすると面食らう人が多いと思いますが、それと本質は似ていると思います。

それほどに大きなエネルギーをもって推進する必要がある取組みなだけに、その実現を本気で追求する意思と環境が必要になります。このとき重要なカギを握るのが、経営トップの「本気度」です。

経営トップになれるような頭のいい人や経験値の高い人は、「目標は何か」「何がしたいか」と聞かれると、大変きれいな回答をします。ただし、皮肉を言うつもりはありませんが、それらの回答の「本気度」には、多くの場合温度差があるものです。

コーチングなどにも応用されている行動心理の世界では、人間が持つ目標には3種類あると言われているようです。

ひとつは、Hope to の目標。「~したいな」「できたらいいな」というレベルの目標です。この目標は、確かに本人の望みではあるものの、その本気度はあまり高くありません。「できたらいいな」は「できなくてもまあいいや」ということでもあるのです。ですので、困難に立ち向かってでも、少々痛い投資をしてでも、とにかく実現したいかというと、否というのがホンネです。

ふたつ目は、Have to の目標。これは、自ら望んでいるわけではなく、環境や制約の要因から「~しなければならない」という必要に迫られた目標です。つまり、単なる義務感で目指している目標なのであって、本心では気が進んでいません。コミットメントのレベルは実はあまり高くないのですが、しかたなく力を入れて実行します。そのため、終わってしまえばそれまで。それ以上の改善や発展は望めません。

最後が、Want to の目標。自分はこうなりたい、これを実現したい、と積極的に望んでいる、最も意識の高いレベルの目標です。この目標を持つ人は、それを実現するために日々考え、困難を乗り越えて実行しようとします。放っておいても勝手にコトを進めていきますし、実現した後は別の課題を見つけてさらに発展させようともします。

こうして見比べてみると一目瞭然だと思います。本気の目標なのは、Want to の目標だけなのです。

システム整備の推進、または情報セキュリティマネジメントの整備を推進していくうえで、経営トップがその課題に対して Want to の目標を見据えて部下に指示をしているのであれば、これほど推進しやすい環境はありません。部下のみなさんがきちんと力を発揮するのみです。

一方、経営トップがその課題の克服を Hope to の目標として捉えているとすれば、システムの具体化が進むにつれてどんどん熱が冷めていき、推進力が萎えていきます。もうすこし率直に言えば、丸投げ状態になっていきます。

ビジネスを発展させるシナリオを描き実行を指示するはずの経営トップがこのような状態でシステム化を推進しても、ビジネスに資するよいシステムにはおよそなりません。特に一旦トラブルに陥ると、「誰が決めるんだ」というような話になりやすく、抱えなくてもよい困難を抱えやすくもなるのです。

その意味でも、経営トップは、本気の目標は熱を持って、その実現に向けたストーリーを語らなければなりません。一方で CIO や情報システムの技術者には、経営側の「本気度」を見極める能力が要求されることになります。

本気かどうかがわからないときは、経営側のアクションや判断が必要になる話を、具体的に掘り下げてどんどんしてみることです。本気でない場合は考えが浅いですから、だんだんとその話をすることに気が向かない雰囲気になっていきます。「そんなのおまえが提案しろ」と言い出したら、アヤシイと思ってください。

 

業務変革・イノベーションを阻む最大のカベ

業務変革やイノベーションを組織的に実践していくうえで、一番のカベとなるものは何だと思いますか?

推進する人材、資金、ノウハウ、いろいろ要素はありますが、一番の障害になりやすいのは、その企業の社風や企業文化ではないかとわたしは思います。

以前、業務変革とシステム改善の相談を受けて、ある中堅企業に面会にうかがったことがあります。その企業はフランチャイズ形式で店舗を全国に展開している企業でした。

その席でわたしは、業務の見直しと改善を図るなら全社レベルで業務プロセスを一度整理するのがよいと、助言しました。そうすると、先方の役員はこのような趣旨のことを述べました。「店舗の業務に問題があることは把握している。調べる必要はない。それに本社には店舗サイドを管理できるほど人数がいないので、店舗のことは考えなくともよい。本社の業務だけを改善したい。」

本社の業務にすでにいろいろな課題が表面化している状態であったため、目の前の課題を解決したい気持ちはよくわかりました。しかしこの考え方のままで改善を進めても、本当の問題が現場(つまり店舗)にあると、問題は本当の意味で解決しません。

本社にしか目を向けなければ店舗の問題は見えず、本社だけを治すことで店舗側に別の支障が出る可能性もあります。そして店舗の業務に支障が出れば、ビジネスにマイナスの影響が出るわけです。

したがって、社内的な都合だけでフォーカスを絞るような考え方では、問題の核心を押さえてビジネスに好影響を与えるような業務改善は困難です。

問題がある場合、その問題は表面に見えているよりも、その奥に隠れていることのほうが多いものです。簡単に解決策が見出せない問題ほど、解決のカギは、その企業の常識や習慣に根差したところにある可能性が高くなります。そうした当たり前と思い込んでいる部分に目を向けて自らを変えられる意思が、特に経営層にない場合、業務変革やイノベーションはかなり困難になってしまうのです。

わたしのようなコンサルタントでも、こうした潜在意識を変えていただくように働きかけるのは、企業に入り込む前のご相談の段階ではほとんどファクトを握っていないために、大変困難なのが実情です。ただ、丁寧に説明することで、逆に「とても勉強になった」と感謝していただけるケースもありますので、ひとまずトライするようにはしています。