カットオーバー時のトラブル発生要因の検証観点（６）～ システム構築段階において ① ～
これまで５回にわたり、カットオーバー時からトラブル発生要因になりうる検証・検討ポイントについて考察してきました。特に、各登場人物（関係部門）の関係性という観点を軸に、意識するべき観点、課題について挙げてきました。それは何といっても、最終的にシステムを造り上げるのは「人」である、ということを忘れてはならないと考えているからです。
ここで、これまで課題として考察してきた観点について、以下にまとめておきます。
【主要な課題】
① 情報システム部門の役割、職務職責を実践しえたか？関係者の中で、共有化されていたか？（構築推進、検証責任）
② 「コンサルタントの構築工程継続支援」と「外部PMO要員投入」は活かせたか？（有効性、実効性）
③ 現場部門（事業部門）の役割、職務職責は明確であったか？意識付け、教育は充分であったか？（実務稼動責任）
④ 開発ベンダーとの関係性（委託範囲、テスト・検証方法、切り分け等）は、適切、妥当なものであったか？（信頼性、協調性）
⑤ 本システムを構築することへの「社内コンセンサス」は、十分であったか？（現場組織・要員カルチャー）
本稿では、上記の課題を受け、システム構築の際に「求めること」「確立しておくべきこと」という観点で、２回に分けて考察したいと思います。
１．推進母体の明確化
まずは構築するシステムに対して、「誰が最終責任を持つのか」ということを明確にすることが、プロジェクトを推進する上で最も重要なことであることは言うまでもありません。単に、プロジェクト進行をスムーズにするだけではなく、課題に直面した場合の早期解決を図るためにも不可欠なことと考えています。
■構築しようとしている「仕組み」の利活用部門の方々（現場部門の人達）に、自分たちの業務拡大、業務効率化のために必要不可欠なものであるという「共通認識」が醸成されていること。（自分たちが作り上げるべき仕組み
であることの認識徹底）
■当該現業部門に何としても成功させるという気概が醸成されていること。
■「業務」と「システム」は表裏一体のものであるという認識の共有化を図ること。
【求められる取り組み】
・稼動のための推進母体（最終責任元）を「対象現業部門」とすること。（恩恵享受部門が責任を持つ）
・「現業部門」の責任者は、開発期間中「本システムの稼働」を主担務とすることが望ましい。（現業優先意識を払拭すること。情報システム部門に「移籍」して指揮をとることがベスト）
・経営層に、どのような情況下でも、ざっくばらんに話が出来る相手を作ること。（モノを言える人、理解者を作る）
２．現業部門への当事者意識の醸成
実際にシステムを活用するのは、現場部門です。「上から言われたから」ではなく、「自分たちの業務をよりよくするためには」という観点での参画が必要です。特に、この成否はカットオーバー時にトラブル大きな要因の一つと考えています。
■当該現業部門は、構築しようとしている「仕組み」の基本構想、ならびに構築すべきシステムを十分理解し、現場での活用イメージを共有化していること。（活用部門の理解が最優先）
■「現場統括部門」に、現場に対し自信をもって説明し、推進し得る意識が醸成されていること。（現場納得性）
【求められる取り組み】
・開発期間中、折を見て「現場部門」に対する情報発信を行うこと。（構築するシステムの「ＰＲ」による、使う側に対する意識付け徹底）
・稼働に向けた「教育」において、現場拠点数、人数を考慮した十分な時間を確保すること。（拙速感排除、自信の醸成）
・定着するまで、十分な支援体制を確保すること。（トラブルを想定した迅速な対応）
・現場部門におけるインストラクターを整備すること。（現場感覚で、対応できる要員の育成）
３．情報システム部門の姿勢（関わり方）
情報システム部門は、本システムの構築に責務を負うことはもちろん、各部門、関係者との調整役であるとともに、自部門開発担当分の推進に加え、日々のシステム運用・保守対応などの実践も求められます。ご承知の通り、その役割は多岐に渡ることから、自部門内のやり繰りを如何に実践し得るかも、重要なポイントになります。
【対現業部門（現場統括部門）】
■当該現業部門と「密な連携」を作ること。（コミュニケーション、意思疎通、実行性の担保等への注力）
■責任元を明確化すること。（現場統括部門の責任者が移籍できない場合でも、稼動責任者が最終責任者）
・稼動責任：業務内容、運営、教育、定着などは「現場統括部門責任」
・構築責任：システム構築に関わることは「情報システム部門責任」
■現業との平行作業になることから、常に「現業の状況が優先されること」を前提とした、取り組み方、作業負荷の可能性を考慮すること。
【対自部門（情報システム部門内）】
■自部門開発分があることによる担当負担を考慮した、現業担務分担の見直しを行うこと。（現業務との優先度配慮）
■現業務を持ちながら対応することに対し、常に「現業を優先せざるを得ないこと」を前提とすること。（フォロー体制、スケジュール、作業負荷などへの配慮）
■チーム編成（タスクフォース的な方式も含む）を取る際、チーム、リーダー間のコミュニケーション、意思疎通、実行性の担保のための仕組みを作ること。
【対ベンダー】
■ベンダーとの役割分担は、基本契約条項によるが、根本的なところは「人と人」に帰結することを常に意識すること。
■リーダー、責任者の取り組み姿勢を常に意識すること。（杓子定規だけでは立ち行かないことの認識）
■リーダー、責任者とのコミュニケーション、意思疎通、実行性の担保などに注力すること。（信頼感の醸成）
■統制するのは、自分たちである（情シス）ということを、常に意識すること。（任せっきりにしないこと）
【外部支援者（外部コンサルタント、外部ＰＭＯなど）】
■自社プロパーでは出来ない事が何なのかを明確にし、それを明示しておくこと。（外部要員活用事由の明確化）
■自社プロパーでしか出来ないこと、やらなければならないことを明確にし、それに注力すること。（委託内容の明確化）
■自部門内での位置づけ、立場を明確にしておくこと。（部門内（員）における役割認識共有化）
■外部支援者の取り組み姿勢を常に確認すること。（杓子定規な対応だけでは立ち行かないことの確認）
■外部支援者とのコミュニケーション、意思疎通、実行性の担保などに注力すること。（信頼感の醸成）
■外部支援者はあくまで「支援者」であり、実行する（動かす）のは自社の仕事であるということを意識すること。
【共通的に求められる取り組み】
・関係者の作業状況、その実態について、タイムリーに共有化すること。
・共有は「３現主義」に徹し、出来る限り「定量的」な表現を求めること。
・その状況、実態に「懸念」が生じた際、自分の立ち位置を超えた踏み込み（進言）を行うこと。（相手の状況、立場を慮ってしまう風潮の払拭）
・良い意味での「おせっかい」を奨励する環境の整備を行うこと。（「必要なことは臆せずに言う」という意識醸成）
今回は、３つの観点で、システム構築に関する取り組みについて考察しました。
次回は、「推進上の行動様式」と「開発体制作り」について、考察したいと思います。