文●小森 哲郎
構造的に問題を引き起こしやすいIT。その原因と対策を「7S」のフレームワークを使って多面的に捉えていくのがこの連載の趣旨である。今回は、Structure・System(組織機構・運営システム)から問題の原因を探っていこう。Structureとは、社内の責任権限の持ち方や組織図そのもので、Systemとは、意思決定のルールや制度など、組織の運営システムのことを指す。IT化は、システム部門、ユーザー部門、トップマネジメントが互いに連携し合いながら、立案、構築、運用、改善という一連の流れを推進していくものだ。これをどう進めていくべきか、というのが今回のテーマになる。
7S:経営における課題解決に取り組む際、Strategy(戦略)、Structure(組織機構)、System(運営システム)、Skill(組織能力)、Staff(人材)、Style(経営風土)、Shared Value(共通価値観)の7つの観点から、原因や解決策を多元的に捉えるための枠組み。
多くの企業が、IT化でトラブルを抱え込んでいる。この連載の第1回目で書いたように、「IT化=トラブルの温床」となりやすいのは、ITがそもそも構造的に問題を起こしやすいものだからだ。ITは一般的に分かりにくい。横文字が氾濫し、新しいテクノロジーが次々と登場してくるため、社内においてブラックボックス化しやすい。
たとえば、システム部門から社内システムを変更すると知らされても、ユーザー部門にとってはどう変更されるのか、通達内容が難解でさっぱり理解できない。理解できないから、聞きたくもなくなる。その状態のまま新システムの稼動にこぎつけても、「使い方がよく分からない」「使いにくい」といった不満がユーザー部門から噴出することになりかねない。
これは、ITが分かりにくいだけでなく、IT推進部門も社内でブラックボックス化してしまっているということだ。第3回(本誌10月号)のスキル・スタッフ編でもとりあげたが、ユーザー部門からシステム部門が見えず、システム部門もユーザー部門のニーズを汲み取れないことから問題が生じてくる。
見えないものを見えるようにするにはどうしたらいいか。埋没しているものを見えるようにするには、まずは組織的な位置付けを高くすることである。たとえば、IT推進部門をトップマネジメント直結の部門として「業務改革部門」とするのも一案だ。業務改革のためにITを入れるのだから、業務改革部隊とシステム部隊が混合チームになっているほうが、当然、理想的だ。
![]() |
|---|
| 図1:IT部門の組織的位置付けを上げる |
その場合、こうした部隊の親玉となるのがCIO(Chief Information Officer)である。システム部門の位置付けを上げたとしても、CIOの力量が不足していれば、業務改革のように大きな変化を伴う活動を切り盛りしていくことは難しい。CIOが、ITという切り口から、部門を越えて社内の業務改革を進められるような力量を持っていれば問題はない。しかし、このような本格的なCIOは数少なく、業務もシステムも両方とも分かる人というのは、ある意味スーパーマンである。そういう人材を見つけることが、ある意味「ミッション・インポッシブル」であり、現実味がないことが多い。
それでは次善策として、システムのことは分からないけれど事業は分かる人と、その逆の人のどちらをCIOに据えるべきかというと、実はシステムのプロでない人を選んだほうがいいと、今までの経験から言える。
CIOとは、会社の価値を上げようとするとき、「何をする必要があり、そのためにはITをどう使えばいいか」、という目でモノを見られる人である。そういう意味でのCIOは、日本ではほとんど育っていないのが現実だ。となれば、CIOに、事業部長職経験者を任命するというのは、かなりいい選択だ。事業部長であれば、「儲ける」という観点でトレーニングされており、技術・製造・販売、そして収益責任、事業計画など、すべてを視野に入れて動いている。システムのことは、後からでも勉強すればいい。
次ページ
事業部門にも説明責任を
付与し、「巻き込み」に追い込む