カットオーバー時のトラブル発生要因の検証（８）～ システム構築に臨むにあたって（まとめ）

７回に渡り、システム稼働におけるトラブルを少しでも減らし、影響を最小限に留めるようにするための取り組みとして、「１．推進母体の明確化」「２．現場部門への当事者意識の醸成」「３．情報システム部門の取り組み姿勢」「４．推進上で意識し取り組むべきこと」「５．開発体制作り」の５点から考察してきました。今一度ここでその取り組むべき主要観点を、以下にまとめます。

【取り組むべき主要観点】
■推進母体（最終責任元）を「新システム稼動恩恵享受部門（現場）」とすることが望ましいということ。
■現場部門（現業担務者）に対し「当事者意識」を醸成する取り組みを継続し続けること。
■情報システム部門として、「３現主義　＊１の徹底」「全体・俯瞰的な立ち位置」、「良い意味でのお節介」を実践すること。
■問題を指摘する人材を疎んじないこと。（「めんどくさいやつ」という発想をしないこと）
■スケジュールに「詰まった時」、遅れを取り戻すのに「個人の気合」に走らない、頼らない環境作りを徹底すること。
■スケジュールの見直し、進言する「勇気」をもつこと。（相手・会議中の「空気」を読まないこと）
■体制作りを行う際、できるだけニュートラルに臨むこと。
■課題に気付いた時、判明した時、「その時点」で関係者と解決策を検討し、結論を出すスピード感を持ち続けること。
■上記事項を「理想論」として排除しないこと。

最終回の今回は、これまでも何度も紹介してきた「システム開発者に期待する行動様式」ということについて、改めて示しておきたいと思います。

＊１：３現主義　
「現場」、「現実」、「現物」の3点を徹底した取り組み

１．開発の基本は「人」

開発の推進にあたって、一般的にマネジメントのための「ツール群」や「手法」、「やるべきこと」などについては、広く提供・明示され、その適用についても実践が進んでいます。しかし、技術論が進むことで「本質的に開発は人による」という、基本的なことを失念してしまう人材が増える傾向も。「字面通りやってさえいれば」「型通りやれば」うまく行くはずという発想に。さらに、開発工程別スケジュールを策定する場合、「ノンリスクで行く」といった発想で作る傾向になっているのではないかとも考えています。
特に、スケジュール計画などは、推進責任者のこれまでの「経験値」「経験則」で策定されることが多いいと思います。しかし、考慮すべき要件でありながら、何故かこれまでのトラブル事項や手戻り要因、個人の現況などを考慮し、明示することは少ない（無い）というのが実情ではないでしょうか。
日本人の性格かもしれませんが、「始まる（開発が）前から、後ろ向きな発言、指摘事項などを明示することへの忌避感」があるのではないかと考えています。（けして後ろ向きなことではないのですが）
「最初からトラブルが起こることを前提にしているのか」とか、「自信が無いのか」とか、「プロだったらリスクは抑えられるはず」等々、「うまく行かなかったら」を前提に考えると責められる傾向があり、リスクを「事前」に明示することがなかなか出来ない、しないという環境下に置かれているのではないでしょうか。

というように、プロジェクト推進においてさえ「人の性格、気質、空気感」が大きく影響をしてしまうものと考えています。

２．「しがらみ」からの解放

前回、システム構築に関わる方々は概ね組織人であり、ある程度の「しがらみ」の中で折り合いをつけることは避けて通れないと述べました。だからこそ、プロジェクト推進にあたっては出来るだけ「ニュートラル」に思考し、行動できるかが重要だと考えています。

特に、

■「運用テスト、操作・運用教育」フェーズにおいて、「業務変更規模、展開規模（拠点数、対象人数）」、「業務影響度合い（現在の業務内容との相違レベル）」に見合った十分行な体制、期間が組まれているかを検証する時、現場部門が仕切る取り決めだから、口を出すのを控えてしまうこと。（現場統括部門とのしがらみ）

■開発の一部分を自社システム部門が受け持つような場合、自部門の「力量理解（実力が分かっている）」、「特定個人依存」、「個人別の現業持ち分に目をつぶった役割付与」といったような自部門人材のことだからという発想になること。（情報システム部門内の甘え、しがらみ）

■委託したベンダーや社内要員補完のための外部要員（今回はコンサルとPMO委託）に対し、会社として、自社担当として長い付き合いがあるという期待感からくる、これくらいは事情を察して「やってくれるハズ」」的な希望的観測をすること。（付き合い上の甘え、しがらみ）

といったようなことは、よく散見されるのではないでしょうか。

カットオーバー時のトラブルを削減するには、こうした諸々のしがらみから来る考え方、意識を切り捨てられるかに掛かっていると言っても過言ではないでしょう。

３．「想定されるリスク」の検証

システム構築の推進にあたって、「トラブルを未然に防ぐ」「トラブルの芽を内在させない」ということが重要であるということは、これまでも述べてきました。その実現のためには、考えられるリスクを明確化し、その対処方法、工数、人材などについて、事前に検証しておく行動を取ることが必要であると考えています。

ただ項番１と同様、事前にリスクを精査することに対し、「起こらないかもしれない」ことに時間と工数を掛けることを面倒と考える傾向が見受けられることも否めません。またリスク対策を考えることで工数、コストが膨らんでしまうように思ってしまうことも、後ろ向きになる要因の一つと言えるでしょう。

どうしたら、こうした考えを「一掃することが出来るのか」を検証することが、トラブル防止やトラブル対応の早期対処に重要であると考えます。

４．期待される行動様式

そこで、システム構築に携わる人材はどうあるべきか、どう行動すべきかということについて、今一度「期待される行動様式」としてまとめておきたいと思います。　

　【システム開発者に求められる期待行動様式】
■気づいたことは、その時、その場で伝える（発言する）こと
■立ち位置（役職、部門、チーム）を超えても進言すること
■突っ込まないといけない時に、突っ込むこと（不要な忖度回避）　
■相手の事情を忖度して、あきらめないこと（実行性の担保を取ること）
■常に全体を俯瞰しながら行動すること（自分の位置づけを常に確認）
■常に何事にも注意を欠かさないこと（些細な事だと思わないこと）
■何事も、他人事（他チーム、他部門の事）と考えないこと
■自分のことを棚に上げられること（正論を語ること）
■「リスク回避」は、「やらないことでは無い」と考えること
■「出来ない」ではなく「出来るようにするには」と考えること

そして、常に「謙虚」であること

以上、「カットオーバー時のトラブル発生要因の検証」ということで、８回にわたり考察してきました。ここで考察した事項は、カットオーバー時だけに関わることではないことは、おわかりだと思います。

組織として必要なことは、基本的な「手法、技法、ツール」の適用を理解させた上で、より「人的な素養面の育成（行動様式）」に注力することが、今、求められていることだと考えています。

「仏《＊２》をつくって、魂|＊３入れず」といったシステムにしないためにも、今一度、振り返ってみて欲しいと思います。

今後の「システム構築、推進」に際して、再検証する材料の一つとしてもらえれば幸いです。

＊２：手法・技法（ツール含む）に沿っていれば出来るハズという考え
＊３：実効性の担保、実現（甘え、しがらみを超えて）