IT部門の組織変革ファシリテーション事例【住友ベークライト株式会社様】

This post is also written in the following language: English (英語)

若手次世代リーダーを巻き込んだ変革のディスカッション

ナレッジサインでは、さまざまな組織に対して組織変革ファシリテーションのお手伝いをおり、『企業のIT部門の変革』も多く手がけています。
今回は、ナレッジサインがお手伝いした、住友ベークライト株式会社様のIT部門の変革について、情報システム部長の林史郎様のインタビューを交え、詳しくご紹介していきます。

昨今、特にビジネスのデジタル化に伴い、IT部門は、デジタルビジネスの立ち上げなど、より事業価値向上へと役割をシフトすべきであると言われています。
“待ち”の姿勢でとにかくQCDに優れたITを提供する「守りのIT」から、もっと積極的に提案し、業務プロセス改革や競争優位をもたらすITを提供する「攻めのIT」への転換。日本企業の多くのIT部門は、今なおこのような課題に直面しています。
IT部門が役割を変革し、その期待に応えていくためには、以下のことが必要です。

・どのように変わるのか、変革のめざす姿を具体化する
・めざす姿に向けた実行プランを描く
・強いリーダーシップでプランを実行していく
・環境変化や実行の進捗度合いに応じて迅速に改善アクションをしていく

ナレッジサインでは、IT部門トップや、幹部層を対象にしたファシリテーションを行い、上記に挙げたプランの具体化、実行・モニタリングの支援などをお手伝いしています。

住友ベークライト様では、2014年4月からIT部長および若手リーダーからなる6名の変革委員メンバーを対象に、2か月間、計8回のファシリテーションを行い、今後のIT部門の役割変革に向けて10のアクティビティーを挙げ、具体的な施策を決定しました。
そこから毎年、変革プランを着実に実行し、成果を出しておられます。

インタビュー

●お客様:住友ベークライト株式会社
●ファシリテーション期間:2014年4月~5月
●ワークショップ回数:8回
●対象:IT部長、課長、若手リーダーの方々 計6名
●目的:今後5年スパンでIT部門の役割をどう変化させるのか、何に取り組んでいくのか。そのために、組織のしくみや人材育成にどのように取り組んでいくのか、具体的な実行策をプランニングする。
●インタビュー対象:住友ベークライト株式会社 情報システム部長 兼住ベ情報システム株式会社 取締役 林 史郎様
●聞き手:株式会社ナレッジサイン 組織変革ファシリテーター 吉岡英幸

― まずは、IT部門の変革プランを策定しようと考えられた背景をお聞かせください。

林様:当社は、IT子会社の住ベ情報システムにIT部員が80名ほどおり、実質的にその80名が、住友ベークライトのIT部門という形です。さらに、国内の主要な工場には、工場担当のIT部員が駐在しており、各工場がIT予算を持ち、工場担当に直接IT化の依頼をするという体制でした。
インフラ、セキュリティや、全社で利用するシステムは、IT部門が業務主管部門と協力して、全社的な標準化を進めていましたが、依然として現場の発言力が大きく、個別最適なシステムが多くを占める状況でした。

2014年から吉岡さんにお手伝いいただいたのですが、ちょうどそのころは、数年をかけてメインフレームからオープンシステムへの切り替えを最優先課題として進めていた時期で、やるべき仕事の見極め、そして移行完了後のIT組織の姿、次世代に向けた役割を具体的に考え始めていた時期でもありました。

― 実は、本格的なファシリテーションに入る前に、そのようなビジョンについて林部長と私でディスカッションをし、めざす姿に向けた課題も、林部長の中でほぼ明確になっていることを確認していました。ですから、後は林部長と私で実務的なプランニングを進める、という方法もあったわけですが、あえて若手リーダーを巻き込んで、じっくりと時間をかけてファシリテーションをしていきました。

林様:変革を実行していくにあたって、次の世代のコミットは必須です。私が一人で引っ張るだけでなく、みんなで一緒に考えることで、変革のアクションに巻き込みたいと思いました。
関わったメンバー6人のうち3人は、比較的若手であり、本人たちも「なぜ自分がこんな重要な役割に選ばれたのか?」という思いがあったと思いますが、その後の成長を見ると、あえて彼らを巻き込んだことは成功だったと確信しています。

実際のファシリテーションは、2~3時間のワークショップを2か月間の間に計8回行いました。全8回のワークショップは、【図1】にあるように、「めざす姿と重点テーマの確認」、「重点テーマをActivity化」、そして「各Activityの行動計画立案」という大きく3つのフェーズに分かれています。

フェーズ1では、IT部門として、どのような姿をめざしたいのか、そのためにはどんな課題が横たわっているのかを、メンバー6名でじっくりと議論しました。

【図1】組織変革ファシリテーションのステップ

自分たちのめざす姿を明確にする

組織変革のファシリテーションにおいて、自分たちのビジョン、ありたい姿を描くことが重要な出発点になり、まずはビジョン、ミッション、バリューとして明文化することからスタートするケースが多くあります。
しかし、今回のファシリテーションでは、あえてビジョン、ミッション、バリューの明文化は、一番最後にしました。

これは、これまでのIT部門の組織変革の経験から来る反省で、ビジョン、ミッション、バリューを最初に創ると、なんとなくキレイな言葉を創ることが目的になり、本当に自分たちがやりたいこと、やりたくないことが反映されていないことが多いからです。

そこで、まず最初に、
・今できていること(自分を褒めてあげたいこと)
・今できていないこと(自分を褒められないこと)

という視点で、できていること、できていないことを挙げていただきました。
このときに重要なのは、何が問題かを明確にすることです。そこで、問題認識におけるファシリテーションのメソッドの一つである「ないないづくし」という手法で、できていないことについては、語尾に「~ない」をつけて、不足しているものを明確にしていきました。

そうして、いくつかの不足しているものが浮かび上がってきました。そうして、めざす姿と、その実現のための課題をマッピングしていきました。【図2】のように、さまざまな課題が複合的にどのように影響し合うのかをマッピングして理解することで、変革のための具体的な活動、Activityが明確になっていきます。

【図2】めざす姿に向けた課題のマッピング

IT組織変革のための10のActivity

計8回にわたるワークショップのフェーズ1では、めざす姿と、めざす姿実現に向けた課題が見えてきました。
次のフェーズ2では、変革のために、何に取り組むのか、具体的なActivityを明確にしてきました。【図2】で描いた課題マップをもとに、課題を「標準化/ガバナンス」、「人材育成/モチベーション」、「IT化計画/経験設計」など、6つのカテゴリーに分け、具体的に何をしていくのか、【図3】のように計10のActivityを設定しました。

【図3】IT組織変革のための10のActivity

A1.IT化案件のレビューのしくみ/レビュー体制づくり
A2.ITの品質基準(レビュー基準)づくり
A3.プロジェクトの成果を褒めるしくみづくり
A4.IT部門からの社内への発信
A5.外部交流の活発化
A6.キャリアプランニングの支援
A7.IT化計画とプロジェクトへの人材アサイン計画
A8.ジョブローテーションの具体策
A9.次世代リーダー育成
A10:時間を作るための業務改革

これらは相互に関連し合うActivityですが、核となるのは、やはり
A1.IT化案件のレビューのしくみ/レビュー体制づくり
A2.ITの品質基準(レビュー基準)づくり
になります。

インタビュー

― IT化案件のレビューの体制を作っていくというのは、具体的にはどういうことですか?

林様:これまでは、テクニカルな面では、メインフレームのオープン化、業務支援の面では、各拠点の要望に沿ったシステムの構築が目の前の課題としてあり、それをこなすことで精一杯でしたが、IT部門として「全社のITはこうあるべき」という明確なビジョンが不足していました。
ともすれば、各拠点の欲しいシステムを要望されるままに作る結果となることもあり、横展開できるのか、本当に必要なものなのか、ということを吟味する視点が欠けたまま、結果的に個別最適なシステム、あるいは、あまり使われないシステムがどんどん増えていく状態になっていました。
また、それぞれが属人的なやり方でシステム構築に携わることもあり、組織としての技術ノウハウも蓄積されていませんでした。

そこで、何のためのシステムを作るのか、どのような方法論で作るのか、どのような手順で企画から実装までを進めるのか、我々のシステム構築における、核となる考え方を「レビュー基準」として明確化し、骨の折れる作業ですが、これからのシステム化案件すべてに対して、きちんとレビューしていく体制を実行することにしました。

レビュー体制づくりとしては、システムを企画する段階と、システムを導入した後のレビューに力を入れました。
システム化の目的とは何か、本当に必要なシステムなのか、システムによって実現することは何か。これらを企画時に明確にするとともに、導入後に、本当に企画時の目的を達しているのか、レビューすることが重要です。
まずシステム企画時には、月2回「レビュー委員会」というものを設け、すべてのシステム案件は、企画段階でIT部長を含めたレビュー委員のレビューを受け、承認を受けないと、開発フェーズには進めないことにしました。

― レビュー委員会は、どのような方で構成されているのですか?

林様:各拠点のグループリーダー7名になります。

― レビュー委員会では、どれぐらいのシステム化案件をレビューしているのですか?

林様:レビュー委員会の導入から2年半で、計40回、105件のシステム化案件を企画段階でレビューしてきました。そのうち再レビューとなったものが8件、完全に企画中止となったものが2件ですね。

― レビューの承認率は高い方ですね。

林様:レビュー委員会への答申前に各拠点のグループリーダが事前レビューすることにより、答申に持ち込める内容か、判断が入っていることが、スクリーニングに繋がっています。レビュー委員会を始めてから、ユーザー部門とIT部門の担当者が、システム化の企画時に以前よりもしっかりと議論するようになりました。

システム企画時には、「目的」、「システム化の目標」、「業務へのインパクト」などと言ったシステム化の必要性だけでなく、「その案件を通しての成長要素は何か」ということもシステム企画書に盛り込んでいます。

これらは、そのまま現場で議論するためのアジェンダとなり、必然的に、何のためにシステムが必要なのか、システムによってビジネスで何をめざすのか、それによってどんな効果があるのか、といった本質的な議論が現場で行われるようになったのです。

プロジェクト成果発表会で、導入後のユーザー評価と自身の成長をふり返る

システム導入後の評価も重要です。ともすれば無事カットーバーして、安定稼働すればシステム開発の目標は達成されたように見なされがちですが、本当にシステム導入の価値があったのかをきちんと評価しないといけません。

ここでは、
・ユーザーの評価はどうか
・プロジェクトを通して何を学んだか

の2つの視点で、システム導入をふり返ることにしました。

そこで、プロジェクト成果発表会というものを実施することにしました。四半期に一度、それまで関わったプロジェクトの主なものふり返って、どのような苦労があったのか、どのような創意工夫でそれを乗り越えたのか、そこから何を学んだのかを発表するのです。
そして、優れたプロジェクトに対して、チーム単位で表彰をします。

インタビュー― このような成果発表会を実施したことで、IT部員にはどのような影響がありましたか。

林様:モチベーションが上がることに期待しています。自分たちの仕事の成果を褒めてもらえるわけですから。

― そのようにモチベーションを高めるために工夫したこととは、どのようなことでしょうか。

林様:批判は一切しないこととしました。成果発表会は褒める場であって、批判をする場ではありません。それを徹底しています。ですから、みんな一生懸命褒めるポイントを探します。

― 他にも何か良い効果がありますか。

林様:成果発表会自体が、プレゼンテーションスキルを鍛える場になっていることですね。成果を出すことと、それを上手に発表することは違いますので、成果を上手にアピールするためには、プレゼンテーションスキルが求められます。これは、ユーザー部門とコミュニケーションしていくためにも重要な部分です。成果発表会は、プレゼンテーションスキルを鍛える良い機会になっています。

「A4.IT部門からの社内への発信」では、隔月でIT広報誌を発行し、事業部門に配信しています。これは、常々IT部門からの発信が少ないという指摘を受け、IT部門の存在感を高めることと、事業部門のITに対する関心を高めてもらうことが目的です。
社内の業務システムについての紹介や、最新のITトレンド、ITデバイスの解説など、単なるIT部門の業務紹介に終わらず、ユーザー目線で役立つ情報を提供しようとしています。

この広報誌は電子メディアとして隔月で配信しているのですが、毎号の編集をIT部員にローテーションで担当させ、IT部長と相談してテーマを決定し、内容の編集は担当者にまかせます。広報誌の編集を通じて、事業部門に伝えるということを学ばせようとしているのです。

能力開発支援がマネージャーの役割であると再認識させる

IT部門における人材育成は、基本的にプロジェクトの経験がベースになります。
住友ベークライト様では、人材のキャリアを大きく、技術エキスパートと、プロジェクトリーダーの2つの方向に分け、どのようなプロジェクトを通して育成していくのか、プロジェクト経験をベースにした能力開発プランをデザインしようとしています。

【図4】のマトリスクのように、プロジェクトを、システムの目的の面で「業務プロセス改革・事業価値の向上」、「インフラの整備」に分け、また、プロジェクトの性質を育成の視点で「技術エキスパート育成」、「プロジェクトリーダー育成」という軸で分類し、プロジェクトをマッピングし、その中で計画的なプロジェクトアサインをしようとしています。

【図4】プロジェクトアサインを考えるマトリクス

このような考え方にもとづいて、一人一人の能力開発プランを考えるのがマネージャーの役割です。これは、企業のIT部門全体に言えることですが、若手人材の能力開発にマネージャーがきちんとコミットできているケースは多くありません。

住友ベークライト様でも、定期的に業務目標の面談をしていますが、実施度合には濃淡がありました。そこで、部下の能力開発プランを一緒に考えるという目的を強く意識した部下との面談を義務づけることにしました。

全社的なIT開発の優先順位があるため、実際には、プロジェクトアサイン計画通りに人材をアサインするのは難しいことです。しかし、上司と部下で能力開発計画を共有し、議論するベースができたことで、若手人材にとっては、自分のキャリアと向き合うことができるようになりました。

インタビュー

― これまでも部下との面談というのはあったのですか。

林様:一部社員に対しては、定期的に業務目標面談を実施していますが、部下のキャリアについてじっくりと対話するということはありませんでした。部下の能力開発プランをしっかりと考えて、対話していくことは初めてと言えます。

― スタートに当たって工夫されたことはありますか。

林様:最初は「何を話したらいいのかわからない」というマネージャーの声が多くありました。ですから、私の方で、面談の目的、聞き出し方のテクニックに至るまで書き込んだ面談ガイドラインのようなものを作り、マネージャーに配布しました。
そして、最初にマネージャー全員で集まり、意識を共有したうえで、ひと通り面談が終わったあとに、結果の共有もしました。

― 面談の実施は徹底しておられるのですね。

林様:みんなまじめなので、そこはきちっとやりますし、面談結果のアンケートも部員に対して実施しています。ただ、そこでは「本音で話せた」という結果が出ても、違う場所で意見を聞いてみると、それまで表に出ていなかった本音が出てくることがあるので、常に気をつけないといけません。


― 林部長の強いリーダーシップで、決めた各Activityをほとんど実施し、変革を継続されていることに正直驚いています。

林様:私のリーダーシップだけではなく、それを支援する各拠点グループリーダーのおかげです。また、愚直なことが当社の取り柄なので、決まったことは皆まじめに継続してくれます(笑)。

― 林部長にとって、このような組織改革のファシリテーションの価値とはどのようなものでしょうか。

林様:そうですね。これからのことを考えると、IT組織の改革が必要だと、同じ思いを持つメンバーがいました。ただ、どこから手をつけるべきか、どのように進めていくか、その方法論を整理し切れていなかったので、それを整理できたことと、キーになるメンバーをうまく巻き込んで進めていけたことに関しては、ファシリテーターの力を借りれたことが大きかったですね。

CASES/INSIGHTS/EVENTS