はじめに
基幹システムの刷新プロジェクトを始めようとしたとき、最初にぶつかる壁が「現行システムが何をしているのか、誰も正確に把握していない」という問題です。長年運用してきたシステムほど、この「ブラックボックス化」が進んでいます。なぜこうした状態が生まれるのか、そして刷新プロジェクトを始める前に何ができるのかを整理します。
ブラックボックス化はどう進行するのか
システムが「ブラックボックス」になっていく過程には、いくつかの典型的な要因があります。
- 設計書が更新されていない：導入当初の設計書は存在するが、その後の度重なる改修が反映されておらず、実態とズレている
- 属人化した運用知識：「なぜこの処理がこの順番になっているのか」「このパラメータを変えると何が起きるのか」といった背景知識が、特定の担当者の頭の中にしか存在しない
- 担当者の異動・退職：システムを構築した当時の担当者や、長年保守してきた担当者が異動・退職し、知識の引き継ぎが不十分なまま時間が経過する
これらが重なると、「動いているから触らない」「触ると何が起きるかわからないので触れない」という状態に陥ります。刷新プロジェクトを始めようとした瞬間に、この「触れない」という状態そのものが最大のリスクになります。
刷新プロジェクトにおける具体的な弊害
ブラックボックス化した現行システムを前提に刷新プロジェクトを進めると、次のような弊害が生じます。
現行システムの仕様が正確に把握できないため、要件定義の段階で「現行システムがやっていること」を正しく洗い出せません。結果として、移行後に「この処理が抜けていた」という不具合が本番稼働後に発覚するリスクが高まります。また、見積もりの前提となる現行機能の規模感も不正確になり、基幹刷新の予算超過はなぜ起きるのかで触れるような想定外のコスト増加にもつながります。
ブラックボックス化を防ぐ・解消するための対策
すでにブラックボックス化が進んでいる場合でも、刷新プロジェクトを始める前に手を打てることがあります。
① 現行踏襲ではなく「現行把握」から始める
要件定義の初期フェーズを、要件を決める作業ではなく、現行システムの挙動を正確に洗い出す「現行把握」の作業として明確に位置づけます。ログ分析、画面・帳票の洗い出し、実際の運用担当者へのヒアリングを通じて、設計書に書かれていない「実態」を可視化します。
② 知識を持つ担当者が元気なうちに、対話形式で記録を残す
文書化を急ぐよりも先に、知識を持つ担当者へのヒアリングをできるだけ早く実施することが重要です。レガシーシステムの保守担当者が高齢化・退職するリスクへの備えでも触れていますが、この知識は時間が経つほど失われていくため、プロジェクトの優先度として高く位置づける必要があります。
③ マスタデータの整理と合わせて進める
ブラックボックス化は、システムのロジックだけでなく、マスタデータの意味づけにも及びます。マスタデータ整備を後回しにするとどうなるかで触れているとおり、コード体系や区分値の意味が失われている場合も多く、現行把握と合わせて整理しておくことをおすすめします。
まとめ
現行システムのブラックボックス化は、属人化した運用知識や担当者の異動・退職によって静かに進行します。刷新プロジェクトを始める前に、現行踏襲ではなく「現行把握」を独立した作業として位置づけ、知識を持つ担当者が元気なうちにヒアリングを進めることが、後の要件定義・移行フェーズでのトラブルを防ぐ鍵になります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント