カットオーバー時のトラブル発生要因の検証観点（７）～ システム構築段階において ② ～
前回、各部門の役割という観点で「１．推進母体の明確化」「２．現場部門への当事者意識の醸成」「３．情報システム部門の取り組み姿勢」の３点から考察しました。以下にその考察観点を示します。
【前回の主要観点】
■推進母体（最終責任元）を、「新システム稼動恩恵享受部門（現場）」とすることが望ましいということ。
■現場部門（現業担務者）に対し、「当事者意識」を醸成するための取り組みを継続し続けるということ。
■情報システム部門として、「３現主義 の徹底」「全体を俯瞰する立ち位置」、良い意味での「お節介」を実践すべきということ。
今回は、その続きとしてプロジェクト運営を円滑に推進するための取り組み意識と、それを支えるための体制作りに求められる考え方という観点で、「４．推進上で意識し取り組むべきこと」「５．開発体制作り」という２点から考察したいと思います。
尚、これまでの主要な課題についても、参考として最下部に再掲 ししておきます。
４．推進上で意識し取り組むべきこと
システム構築プロジェクトにおいて、少しでも円滑に推進するために求められるべき取り組みとして、主に「スケジュール設定の仕方」、「会議体設定とその運営の在り方」、そして「推進にあたって取るべき立ち位置（情報システム部門の）」という３つの観点が重要と考えています。
特に、その取り組みにあたって「トラブルを未然に防ぐ」「トラブルの芽を内在させない」ということに留意していたかが、ポイントになると考えています。
■スケジュール設定
・当たり前のことですが、「全体スケジュール（大線表）」から「詳細スケジュール」に至るまで、ブレイクダウンされていること。
・詳細スケジュールは、「２～３日単位」での作業（項目）分割を行うように設定されていること。（１週間は、長いと思え）
・このスケジュールで、「熟せる、充分である」というコンセンサスが得られていること。得られる努力を惜しまないこと。（納得感）
・システム構築においては、共通的・基本的なことであるが「造って魂を入れず」といったことが無いように、常に進捗状況をフォローし続けること。
■会議体に関して
・ステークホルダーレベルごとの会議体が、設定がされていること。（開催間隔、開催ルール、推進役の設定）
・「形式的、惰性的」にならない、しない工夫を常に意識して取り組むこと。（緊張感の醸成、持続）
・３現主義に基づかない報告は、「差し戻す気概」を持つこと。（報告レベル、報告の仕方の共通化を図る）
・計画、予定に遅延、またはその懸念が察せられた時、担当者、担当部門だけに任すことなく、その場で対応策を明確化し、対応期限を設定すること。（実施責任者、フォロー責任者を明確にし、次回報告とはしないこと）
■推進者という立場について
・常に、各作業内容を確実に遂行する、させる責任を負っていることを自覚した行動を取ること。
・「実行させる」ことが役割であり、「やってくれるハズ」「やっているハズ」といった、憶測や希望的な観測は捨てること。（３現主義に徹すること）
・その為には、「重箱の隅を突っつく」「組織間・会社間の壁を超える」「不安に思ったことは徹底的に潰す」などといったことに対し、躊躇する気持ちを排除し取り組むこと。
【共通的に求められる取り組み】
■「スケジュール」、「報告書」が出ているから「安心」といった気持にならないこと。
■特に、スケジュール、役割分担ができたことで、これでうまく進むだろうといったような意識にならないこと。
■常に、ウォッチング、フォローしていく行動を徹底すること。
■それぞれの立場に配慮しつつ、気づいた人が「立場を超えて」発言できる、する環境を醸成すること。（無意味に、空気を読まないこと）
・他部門、他グループの問題だと考えないこと。
・「他部門」「ベンダー」を動かすための方策を常に考えておくこと。（誰だったら、どうやったら動かせるか）
■課題に気づいた時、判明した時、「その時点」で関係者と解決策を検討し、結論を出すスピード感を持ち続けること。
■スケジュールに「詰まった時」、遅れを取り戻すのに「個人の気合」に走らない、頼らない環境作りを徹底すること。
５．開発・運用体制作り
作業内容、工程フェーズごとに体制を用意することは当然のことと思いますが、その際、単に「役割分担」に終始し、「業務影響度合い（現在の業務内容との相違レベル）」や、「個々人の現業持ち分」といったことまで考慮された体制作りがされることは稀なのではないでしょうか。
特に、今回の事例のように情報システム部門が「開発の一部分を受け持つ」というような場合、自部門の力量を理解（実力が分かっている）しているが故に、そして「この人物ならなんとかやってくれるだろう」的な思いに駆られて設定してしまうということがあるかもしれません。
しかし、体制作りを行う際にはどれだけニュートラルに臨めるか、臨むかが、重要なポイントとなるでしょう。さらに、カットオーバー時のトラブルを最小限に留めるためには、「新システム導入による業務の変更規模、展開規模（拠点数、対象人数）」に見合った、現場の「運用テスト、操作・運用教育」を十分に行える「体制、期間」を確保することが重要であると考えています。
■展開規模に関する対応（準備、教育、支援体制）
・「業務の全面改訂、数百人規模の教育・機器展開」に対応する体制を整備するにあたり、常に最悪の状況を想定した「設計」をすること。（常にトラブルが起こることを前提とした取り組み）
・余裕ある「教育期間」「テスト期間」を確保すること。
・現場支援部隊の体制を確保すること。（作る際は、現場部門に任せっきりにしないこと）
・現場統括部門に対し、「助言する」という立場だけにならないこと。（実行させる算段まで行うこと）
■開発システムの自部門（情シス）による、併行開発に関する対応
・ベンダーとの関係性をベースに、プロパー体制を整備すること。
・自部門開発分に関して、ベンダーと同じ対応環境作りを行うこと。（なあなあ感を一掃した枠組み作り）
・現業負担との兼ね合いを考慮すること。（過負荷を見過ごさないこと）
・自身（個人）の問題だということに帰結させないこと。（オーバーワークにしない割り当て）
■運用テストフェーズ重視の対応（期間、規模、深度の確保）
・カットオーバータイミング（稼働日）を変更することに躊躇しないこと。（現行業務改革の場合などは特に）
・運用テストフェーズ（現場運用を想定した、最終テスト）における期間は、十分確保すること。（前工程の影響回避）
・現場統括部門によるインストラクター要員の育成を図ること。（稼働時、現場問い合わせ対応窓口へ移行）
・現場要員教育期間、回数を十分確保すること。（現業との調整を確実に行い、現業に引っ張られないこと）
・現場教育で使われるデータ（情報）を、運用テストフェーズでも加えられるように事前に設計しておくこと。
【共通的に求められる取り組み】
■上記事項を「理想論」として排除しないこと。
■問題を指摘する人材を疎んじないこと。（「めんどくさいやつ」という発想をしないこと）
■やってみないと分からない的発想の横行を防ぐこと。
■スケジュールの見直し、進言する「勇気」をもつこと。（相手・会議の「空気」を読まないこと）
■３現主義に徹すること。（報告、指摘、進言事項）
＊１：３現主義
「現場」、「現実」、「現物」の3点を徹底した取り組み
＊２：主要な課題（再掲）
① 情報システム部門の役割、職務職責を実践しえたか？関係者の中で、共有化されていたか？（構築推進、検証責任）
② 「コンサルタントの構築工程継続支援」と「外部PMO要員投入」は活かせたか？（有効性、実効性）
③ 現場部門（事業部門）の役割、職務職責は明確であったか？意識付け、教育は充分であったか？（実務稼動責任）
④ 開発ベンダーとの関係性（委託範囲、テスト・検証方法、切り分け等）は、適切、妥当なものであったか？（信頼性、協調性）
⑤ 本システムを構築することへの「社内コンセンサス」は、十分であったか？（現場組織・要員カルチャー）
以上、２回にわたり、「システム構築段階に求められる対応取り組み」ということについて考察してきました。何といっても、システムを造り上げるのは「人」であるということを忘れないことが肝要だと考えています。
システム構築に関わる方々は概ね組織人である限り、ある程度の「しがらみ」の中で折り合いをつけなければならないということからは、避けて通れないことではあると思います。だからこそ、出来るだけ「ニュートラル」に思考し、行動することが重要になると考えています。
次回は、本テーマの最終回として、「カットオーバー時にトラブルを起こさないシステム構築に臨むにあたって」ということについて、「まとめ」ておきたいと思います。