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

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

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

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

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

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

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

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

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

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

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

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

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