IT部門の組織変革ファシリテーション事例【住友ベークライト株式会社様】　PART2　IT企画から導入後の成果報告までを通してレビューを徹底する

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

住友ベークライト様では、2014年4月からIT部長および若手リーダーからなる6名の変革委員メンバーを対象に、2か月間、計8回のファシリテーションを行い、今後のIT部門の役割変革に向けて10のアクティビティーを挙げ、具体的な施策を決定しました。
そこから、約2年半。変革プランを着実に実行し、成果を出しておられます。
本事例紹介では、変革プランニングから、実際の変革実行のプロセスについて、PART1,PART2,PART3の3部構成で詳しく紹介していきます。
PART2では、IT部門変革に向けた具体的な取り組みをどのように具体化していったのか、ご紹介します。

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

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

PART1でご紹介したように、IT部門変革ファシリテーションの計8回にわたるワークショップのフェーズ1では、めざす姿と、めざす姿実現に向けた課題が見えてきました。

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

【図1】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はこうあるべき」という明確なビジョンが不足していました。

ともすれば、各拠点の欲しいシステムを要望されるままに作る結果となることもあり、横展開できるのか、本当に必要なものなのか、ということを吟味する視点が欠けたまま、結果的に個別最適なシステム、あるいは、あまり使われないシステムがどんどん増えていく状態になっていました。

また、それぞれが属人的なやり方でシステム構築に携わることもあり、組織としての技術ノウハウも蓄積されていませんでした。

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

IT企画の1つ1つの案件に対して、レビュー委員会で企画内容を吟味する

レビュー体制づくりとしては、システムを企画する段階と、システムを導入した後のレビューに力を入れました。
システム化の目的とは何か、本当に必要なシステムなのか、システムによって実現することは何か。これらを企画時に明確にするとともに、導入後に、本当に企画時の目的を達しているのか、レビューすることが重要です。

まずシステム企画時には、月2回「レビュー委員会」というものを設け、すべてのシステム案件は、企画段階でIT部長を含めたレビュー委員のレビューを受け、承認を受けないと、開発フェーズには進めないことにしました。

【インタビュー】―　レビュー委員会は、どのような方で構成されているのですか？

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

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

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

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

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

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

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

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

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

ここでは、
・ユーザーの評価はどうか
・プロジェクトを通して何を学んだか
の2つの視点で、システム導入をふり返ることにしました。

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

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

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

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

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

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

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

※PART1「めざす変革の姿を明確にする」はこちら
※PART3「決めたことは着実に継続していく中で成長がある」はこちら

NEWS/CASE STUDIES/INSIGHT