トレンドでもあり経営層にもキャッチーなDX。企画構想での夢広がる未来感は、実行計画では単なるシステム刷新プロジェクトにトーンダウンして、いざ実行フェーズに入ると予定通りに進まない。2025年の崖は、面白いように目の前で起きています。
トップダウンで推進しても立ちはだかる現場の抵抗と現行システムの見えない仕様の壁にぶつかり、経営層の思いが現場に届く時にはDXパワーは減衰しています。
最初から現場の抵抗を見据えて「現行システムをベースにしつつ現場の意見とデジタル要素を取り入れて・・・」などといった良く言えば全方位的、悪く言えば中途半端な進め方をすれば、普通のシステム開発よりも遥かに難しいプロジェクトとなり、デジタル化の実現はさらに遠のきます。
DXというトレンドワードと2025年の崖の脅威が重なることで、システム開発の現場は盛り上がりと燃え盛りが同時多発しています。
目次 [非表示]
現場はDXの言葉に騙されない
老朽化や償却を理由にしたシステム刷新は、IT部門の都合によるものであり、ユーザー部門には全く価値のないものです。そのためIT部門としては、あの手この手を使ってシステム刷新をプランニングしようとして、今もっとも有力なその手がDXです。
製造業だと工場のパワーは非常に強く、生産に影響を及ぼせば供給が止まり、ひいては売上減少に繋がり業績に打撃を与えます。万一不良品によるリコールを起こせば大問題となるため、メリットもないのに生産にリスクを負う活動に前向きに協力するユーザーはまずいません。
DXを謳った企画がマネジメントに承認されてもユーザーにメリットがなければ実行フェーズで苦しむことは明らかです。
DXが単なるシステム刷新へ
DXの名の通り変革としてゼロから検討するコンセプトで、いまの業務のやり方と現行システムで実現していることを捨てられたら良いですが、なかなか難しいのが実情です。
企画や計画段階でゼロベース思考や現行リセットといった方針を打ち出しても、ユーザーとの合意形成は曖昧で、いざ蓋を開けてみたら現行ベースの検討ということは実際に良くあります。トップダウンでの強力な推進を試みても、ユーザーは今の課題を解決するメリットを求めて現行をベースに考え、推進サイドは現場の発言力と抵抗感に屈して、当初の企画からデジタルの言葉は薄れていきます。
結局は、現行システム調査を行い、既存の設計書が無ければリバースして現行仕様を起こし、そこに新規要件を追加すると言った単なるシステム刷新プロジェクトの定番作業が待ち受けています。
現行システム調査は難航
古いシステムの場合、稼働当初からの有識者は一人もおらず、継ぎ接ぎだらけで保守要員も理解は断片的、設計書も存在しない状況は普通にあります。
現行システム調査を行ったところ、バッチ機能が今でも毎日動作しているのに誰が何のために使っているのかわからない。ソースを解析してもログと出力データを確認しても目的はわからず、新システムで必要かどうか判断がつかない。新業務フローに登場しないからと言って、この機能が必要ないとは現場も言い切れず困った状況です。
必要性を判断するために機能を停止して実害がないか影響を確認する。そのために停止とリカバリの手順を作って、テスト環境で停止前後のデータ断面を比較して、停止直後のフォロー体制を確保する。
こう言った全く費用対効果のない作業が実際に発生しています。
クリティカルな業務システムであればあるほど、また古いシステムになればなるほど、この不毛な調査作業が発生し、いつまで経っても調査が終わらないという状況になりがちです。
現行調査に見切りをつけて甘く実施した結果、総合テストやユーザー受入テストで障害が出まくり調査をやり直すという途轍もない手戻りを経験すると、実行部隊は現行調査を充分以上にしっかりやるべきだと主張しますが、経営層や企画構想チームには時間とお金をかける重要性を理解されません。このギャップはなかなか埋めがたく、経営層による実行フェーズの軽視こそが2025年の崖の本質的な課題なのかもしれません。
現行整理は多面的に
DXに限らずシステム刷新では現行システム機能を漏れなく調査することが重要です。設計書がない場合は、ソースを解析し、ソースすらない場合はログを一つ一つ調査するなどの地を這うような作業が必要となります。効率的に調査したいと考えがちですが、ブラックボックス化している古いシステムでは、設計書もソースも言い伝えも何もかも信用できないため、ユーザーと運用担当者へのヒアリング、ソース解析、ログ調査、ジョブネットやスケジューラーの確認など様々な事実を洗い出し、多面的に整理して行くことが大切です。
言わば検算のようなものです。この検算的作業には時間がかかるため、計画時点から盛り込んでおかなければ、現行調査の作業は終わらないか、完全に洗い出したとは言えない状況で次工程に進むことになります。我慢に耐えきれずに工程を進めてしまえば、常に現行調査を並行で行う非効率な進め方と手戻りリスクが付きまとう終わりの見えない旅が始まります。
現行データは厄介
現行資産には、アプリケーション機能だけでなくデータも含まれます。業務システムでは、過去データを見たい、仕掛中のデータを新しいシステムに移行して業務の続きをしたいなどの要件が普通にあるため、DXといっても現行データを捨て去ることはほぼ不可能です。
そのため、現行データを新システムへ移す作業が必要となりますが、現行システムが古ければ古いほど、このデータ移行は厄介です。
古いシステムの場合、データ量が多いことに加えて、稼働当初は使っていたが今は使わなくなっている不要データ、過去にテスト的に使った不正データなどがたんまり紛れ込んでいます。機能のようにゼロイチで必要性を決められるものではないため、データ移行の中で課題を一つ一つ潰していかなければいけない大変さがあります。
データ移行を軽視すると致命傷を負う
DXに限らずシステム刷新においてデータ移行は重要なタスクです。
はじめから重要性を認識していないと、なかなか移行タスクが日の目を見ることはなく、どんどん後回しにされて気が付いた時にはプロジェクト推進に致命傷を負わせることになります。
・突然クリティカルパスに躍り出る
データ移行は、現行システムのデータを新システムに移すことなので、新システムの仕様が決まらないとデータ移行の仕様も決まりません。新システムの本体機能の設計が完了した後にデータ移行の設計を開始するため、本体機能の設計や開発が遅れると、玉突きでデータ移行も遅れます。本体機能を優先した結果、本体はなんとか間に合ったけど移行が間に合わず、プロジェクト終盤になって移行タスクが突然クリティカルパスに躍り出るというのは、よくある話です。
・テストケースから漏れる
総合テストでは、画面から入力したデータ、他システムから流入したデータ、移行データなどのデータバリエーションで検証を行います。他システムからの流入データを画面で更新するケースなどデータバリエーションとオペレーションを組み合わせてテストケースを洗い出していきますが、このデータバリエーションから移行データが漏れると、ほぼすべてのケースで漏れが発生します。UATでもこの漏れに気が付かず本番リリースをしてしまえば、考えるだけでも恐ろしい結果が待ち受けています。
・時間がかかる
データ移行に物理的にすごく時間がかかることがあります。データ量が膨大であったり、処理が複雑で移行プログラムの性能が出なかったり、クラウドのためネットワーク回線がボトルネックになったりと理由は様々ですが、移行時間を算出するタイミングが遅くなると、本番導入に間に合わない可能性もあります。
IT部門も敵では為す術なし
大企業では、ユーザー部門のパワーが強くIT部門は弱い立場であることがいまだに多いです。そのためシステム開発プロジェクトでは、ユーザーの抵抗が当たり前のリスクと課題に挙がります。
これまでに幾度となくシステム開発で協力を押し付けたあげく、劇的な利便性の向上もないどころか導入期限も守れず品質もずたぼろでは、ユーザーの信頼を失うのも当然です。
DXプロジェクトでも、この状況は容易に想像できるはずにもかかわらず、実行フェーズの推進をベンダーに任せて、計画通りに進まなければベンダーのせいにするIT部門は、推進の壁を高くする存在でしかありません。
ベンダー管理だけをやってきたIT部門は業務理解も開発知識も乏しいうえにDXとなれば勘所も陥りがちな罠も知るはずもなく、より存在意義が薄れてしまいます。
ユーザーからもIT部門からも敵同然の態度を取られては三つ巴の戦いとなってしまい、そもそも難題なDXが円滑に進むわけはなく、誰も得をしない三方悪しの結果が待ち受けています。せめてIT部門はベンダーの味方となって、出来ればユーザーの協力も前向きに得て、三位一体で推進したいものです。
まとめ
デジタルネイティブな組織やデジタル世代の社員割合が高い会社では、DXが次々と推進される一方で、旧態依然な大企業では遅々として進まず、その開きは拡大する一方です。多くの大企業では、DX以前に重厚長大な現行システムに手を焼き、構想から5年や10年掛かりで刷新しても、完遂した時にはもはや古いシステムとなっている悲しい現実が待っています。なんとかそのサイクルを早めようとしても、現場の抵抗によってなかなか進みません。
断捨離のできない人の家がごみ屋敷になるのと同じように、ときめきのない現行システムを捨てきれない企業は、2025年にはさらに高くなった崖の上に立っているのかもしれません。
効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！
