カットオーバー時のトラブル発生要因の検証（３）　～　現場統括部門、経営層との関係性について　～

カットオーバー時のトラブル発生要因について、前回、前々回と「情報システム部門」での検証観点を見てきました。そこで今回第3回は、「現業統括部門（本部機構）、経営層」との関係性という視点で、検証・検討ポイントを考察したいと思います。　(＊１に、プロジェクト概要を再掲しておきます)

既に企業経営、業務運営において「コンピュータシステムが不可欠である」ということは、誰も否定しないことだと思います。ただ「システムを構築する」ということになると、「それは情報システム部門の役割」であるとされ、経営層・現場の中には「情報システム部門が作ってくれて、提供されるもの」と思っている方々が、まだまだ多いのではないかと考えています。システムの利用を享受するハズの経営層・現場の方々が、ことシステムを構築するということに対しては、第三者感覚が残っている（心の奥底で）のではないでしょうか。
順調なシステム稼働に向けては、システム部門と経営・現場部門との「意識ギャップ、期待度ギャップ」をどのように埋めるべきかということが特に重要な課題だと考えています。

【現場統括部門、経営層との検証ポイント】

システムの開発・導入にあたり、情報システム部門としての役割・責任範囲を明確にすることは当然のことと受け止めていると思いますが、今後は経営・現場部門の各関係者の「役割・責任範囲」も事前に明確化・共有化し、その実効性について検証することが必須になっていると考えています。決して形式的　＊２ なこととしてでは無く。
本稿では、情報システム部門が経営・現場部門を如何に「その気」にさせ、「巻き込めたか」がキーの一つであり、その視点から検証観点を以下に考察したいと思います。

１．現場統括部門との関係性について

■新システムの利益享受（業務効率化、顧客サービス向上）部門としての推進意識は、十分醸成されていたか
・システム構想立案時での現場統括部門の関わり方は主体的であったか。
・システム構想、システム計画時点での現場統括部門の「理解度・納得度」は、十分だったか。
・システム定着（現場への）は、現場統括部門の責任であるとの意識は醸成されていたか。

■基本構想に基づく、システム計画、RFP（Request For Proposal） 策定・評価時の関与度は適切だったか
・情報システム部門が主体で行っていなかったか。
・現場統括部門をどの程度巻き込んでいたか。
・現場統括部門とどの程度語り合い、今回の取り組みに込められた「思い」を共有したか。
・双方「理解している、したハズ」という思い込みはなかったか。
・特に、情報システム部門にその傾向は無かったか。

■現場統括部門としての体制は、充分であったか（実効性の担保）
・現場教育（業務運営、システム利用等）、拠点数、システム教育対象者数に関する規模認識は、十分であったか。
・現業業務との兼ね合い（現業務を続けながら、間でシステム教育）は、十分に計画されていたか。
・情報システム部門、現場統括部門における教育、問い合わせ体制は、充分であったか。（規模に対する、取り組み感覚が認識出来ていたか）
・現場統括部門の責任者に、大規模展開と言うことに対しての知見はあったか。（伝授したか、理解に努めたか）

■実効性において任せっきりにしていなかったか（進捗に関する踏み込み）
・情報システム部門としての進捗支援の在り方は、十分検証・検討されていたか。
・進捗に不安を感じた際、現場統括部門の問題だと割り切ってしまわなかったか。(自身も追われている)
・「任した、任された」ということから、問題を予見した時に「口を出すのを控える」という風潮、空気感は無かったか。
・積極的に、支援体制を組もうとしたか。

■現場統括部門と情報システム部門の役割関係性は適切であったか
・２頭立て運営体制になっていなかったか。
・指示命令系統は、明確であったか。（最終決定権限はどちらだったか）

２．経営層との関係性について

■基本構想に基づく、システム計画、RFP（Request For Proposal） 策定・評価時の関与度、理解度は適切だったか
・情報システム部門が主体で行ってしまわなかったか。（報告中心ではなかったか）
・経営層と、どの程度語り合い、今回の取り組みに込められた「思い」を共有し得たか、努めたか。
・双方「理解した、したハズ」という思い込みはなかったか。
・特に、情報システム部門にその傾向は無かったか。

■進捗における「巻き込み方」は、理にかなっていたか
・報告するだけになっていなかったか。
・経営層をどの程度巻き込んだか、巻き込めたか。
・経営層における「支援体制」を組めていたか。
・システム開発の進捗に対し、どのような進言をしたか。
・現場統括部門担当分に遅れが出ていた際、適切な進言を行ったか。
・現場統括部門の過負荷解消に対する進言は、十分であったか。

■報告時における「回答」は、適切だったか
・報告時、課題、進言に対して、経営層から適切な回答は得られていたか。
・進言に対する「真剣度」は、本物　＊３だったか。
・「仕方がない」と思ったことはないか。
・会議などで、玉虫色やなあなあの結論となった場合、そのまま受け入れてしまわなかったか。
・それを、そのままにしたことは無かったか。

＊１：検証用のプロジェクト概要

■対象業務及びシステム
・売場、モバイル販売会計システム（売上管理）、顧客サービス系仕組みの改革（サービス向上、業務効率化）
・現場（拠点）は、全国３０００ヶ所以上（一斉稼働を目指す）
■プロジェクトの体制
実業企業における「情報システム部門」を主体とした開発体制で推進。
①上流工程
・コンサルティング企業A社の下で、業務改革基本構想を策定した。
・その基本構想を基に、経営層・現場統括部門に業務改革事項を説明し、システム化の了解を得る。
・カットオーバーは、一斉とした。
②システム開発
開発にあたり、社内推進体制の脆弱性を懸念し、外部に開発マネージメントを委託した（ＰＭＯ（ProjectManagement Officer）を情報システム部門配下で）。
また、既存システムとの連携や構築システムの特性を考慮し、それぞれに担当会社を選定した。
・既存の稼動システムとの連携・・・既存ホスト構築・運用Ｂ社
・タブレット型業務システム（改革対象システム）・・・開発担当Ｃ社
・売上管理システム（所謂ＰＯＳ（レジ）システム）・・・担当Ｄ社
・ＰＭＯ　　　　　　　　　　　　　　　　　　　　・・・担当Ｅ社
・自社の情報システム部門でも、一部開発を受け持つ。
③現場教育、業務運用面
・現場統括部門を設定し、全面的に推進を委ねる。
・情報システム部門は、システム面での協力・支援体制で臨む。

＊２：形式的
プロジェクト体制図や、役割・責任分担表などが作成されていれば、ただそれだけで安心してしまう傾向。書いたら安心してしまい、実践時にはあまり振り返らず、それを盾に「要請する」ことは少ない。（日本人気質？）

＊３：本物とは
不退転の決意で臨んでいたか。得たい回答が得られなかった場合の対処施策について、どの程度真剣に考えて臨んだか。サラリーマン気質になっていなかったか。

以上、情報システム部門と経営層、現場統括部門との関係性の観点から、その検討・検証ポイントについて紹介しました。
一言で経営・現場に「その気にさせる」といっても、様々な事象や度合いがあると思います。ただ、今後はその調整までもがこれからのシステム開発における情報システム部門の主要な役割の一つと言えるということです。

次回は、「コンサル・PMO」との関係性という観点から、検証・検討ポイントについて考察したいと思います。