基幹システム刷新の現状調査で、最初に確かめる5つのこと

基幹システムの刷新プロジェクトに参画すると、最初の数週間は現状調査に充てられることがよくあります。今のシステムが何をしていて、誰が使い、どこにつながっているのか。そこを押さえないまま新しい仕組みの話を始めると、要件定義や設計の途中で「その処理、今もあったんですか」という手戻りが起きます。

一方で、現状調査は終わりが見えにくい仕事です。設計書、運用手順書、障害の記録、過去のヒアリングメモと、読むものはいくらでも出てきます。限られた期間で何を先に確かめるかを決めておかないと、資料を読み込んだだけで調査期間が終わってしまいます。

この記事では、刷新プロジェクトの初期に上流の担当者が最初に確かめたい5つのことを、現場の場面とあわせて整理します。順番どおりに進める必要はありません。ただ、どれか一つでも抜けると、後の工程で必ず困る観点です。

業務とデータの流れを、一枚の図にできるか

最初に確かめたいのは、システムの機能一覧ではなく、業務とデータの流れです。受注から出荷、請求、入金まで。あるいは調達から生産、在庫、原価まで。どの業務でどのデータが生まれ、どこで書き換えられ、どこで使われているのかを、一枚の図にできるかどうかが出発点になります。

機能一覧から入ると、システムが持っている画面や帳票の数に目が行きます。しかし刷新で問われるのは、その業務を新しい仕組みでどう回すかです。機能の数を数えても、業務がつながって見えてこなければ、範囲の判断も移行の計画も立てられません。

たとえば、ヒアリングで「この画面では何をしますか」と聞くと、操作の説明が返ってきます。代わりに「この伝票はどこから来て、処理したあとはどこへ行きますか」と聞くと、前後の業務と担当者が見えてきます。受注データが営業部門の入力ではなく、取引先からのファイルで入ってくる。出荷後に物流部門が別のシステムへ打ち直している。こうした事実は、機能の説明からはまず出てきません。

あわせて、主要なマスタの持ち主も確かめておきます。品目、取引先、組織、勘定科目など、マスタを誰が登録し、誰が承認し、どのくらいの頻度で変わるのか。刷新ではマスタの持ち方を変えることが多く、ここがあいまいなままだと、データ移行の段階で大きく揉めます。

業務の流れを描くときは、月の中での波も聞いておきます。日々の受注処理は単純でも、月末の締めの前後だけ別の部署が加わり、確認や修正のやり取りが集中する、ということがあります。普段の流れだけを描くと、刷新後に一番負荷がかかる時期の業務が抜け落ちます。

気をつけたいのは、システムの外にある業務です。基幹システムから出力した表を表計算ソフトで加工し、別の部署にメールで送っている。そうした手作業は設計書には載っていません。しかし現場にとっては日々の仕事の一部で、刷新後になくなると困るものも混じっています。図を描くときは、システムの箱だけでなく、人の手作業も同じ線で描いておくと、抜けに気づきやすくなります。

周辺システムとの連携を、実際の動きから洗い出せているか

基幹システムは単独では動いていません。販売、生産、物流、会計、人事、取引先との受発注など、周辺のシステムと何本もの連携でつながっています。刷新で見落としやすく、後から見つかると影響が大きいのがこの連携です。

連携ごとに、少なくとも次の点を押さえておくと、後の設計で使える一覧になります。

• 相手のシステムと、その担当者（社内か、外部のベンダーか）
• データの向き（送るのか、受け取るのか、両方か）
• 方式（ファイル、API、データベースの直接参照など）
• 頻度とタイミング（随時、毎時、夜間、月次など）
• 止まったときに誰が気づき、どう再実行するか

たとえば、情シスから「連携一覧はあります」と表計算ファイルを渡される場面があります。ありがたい資料ですが、最後に更新されたのがいつかを確かめると、数年前で止まっていることも珍しくありません。そこで、ジョブ管理ツールに登録されている夜間処理の定義や、ファイル転送の設定、データベースに接続しているアカウントの一覧など、実際に動いているものと突き合わせます。

この突き合わせで出てくるのが、一覧に載っていない連携です。別の部署が集計のためにデータベースを直接読みに来ている。帳票ツールが夜中にデータを抽出している。部署で作った小さなツールが、基幹システムのテーブルを参照している。どれも正式な連携ではありませんが、刷新でデータベースの構造が変われば、そのまま動かなくなります。

連携先の担当者が社外にいる場合は、早めに窓口を確かめておきます。刷新に合わせて相手側の改修が必要になると、相手の予算や開発の時期とも調整が要るからです。調査の段階で「この連携は相手側の改修が要りそうだ」と見当をつけておくだけでも、計画の立て方が変わります。

連携の調査では、データ量と処理時間も一緒に見ておきます。夜間処理が朝の始業までにぎりぎり終わっている、という状態は珍しくありません。刷新で処理の順番や方式が変わると、その余裕がなくなることがあります。ジョブの実行記録から、毎日の開始と終了の時刻、月末や年度末に処理が長くなる日を拾っておくと、新しい仕組みの性能の条件を決めるときの材料になります。

個別に作り込んだ部分は、なぜ作られたのか

長く使われてきた基幹システムには、パッケージの標準機能に足した部分や、独自に作った画面・帳票・バッチが積み重なっています。刷新では、これをどこまで新しい仕組みに持っていくかが大きな論点になります。

ここで確かめたいのは、作り込みの量よりも、それぞれが作られた理由です。理由を聞いていくと、おおよそ三つに分かれます。今も業務上の意味がある違いを支えているもの。過去の組織や取引の事情で作られ、今は事情が変わっているもの。そして、作られたものの、もう誰も使っていないものです。

たとえば、利用ログが取れるなら、画面や帳票がこの一年でどれくらい使われたかを先に見ておきます。そのうえで、利用が少ないものについて「この帳票は、どなたが何に使っていますか」と聞きます。答えられる人がいない帳票は、刷新で持っていかない候補になります。逆に、年に一度しか使われないのに、決算や監査で欠かせない帳票もあります。回数だけで判断しないことが肝心です。

作り込みを、標準から外れた悪いものと決めつけないことも大切です。その会社の強みになっている業務のやり方を、システムで支えている場合があります。現状調査の段階では残す・やめるを決めきらず、理由と使われ方を事実として集めておく。判断は、業務部門の責任者と一緒に、刷新の方針に照らして行います。

もう一つ、作り込みの仕様を知っている人が誰かも書き留めておきます。担当者がすでに異動していたり、外部ベンダーの特定の人しか分からなかったりすると、移行のときに仕様を確かめる手段がなくなります。

運用の実態は、手順書どおりに回っているか

システムがどう作られているかと同じくらい、どう運用されているかを見ておく必要があります。刷新後の運用設計は、今の運用の実態を出発点にするしかないからです。

見ておきたいのは、たとえば次のような運用です。

• 夜間処理の監視と、異常終了したときの対応
• 月次・年次の締め処理と、その前後の作業
• マスタの登録・変更の手順と承認
• 利用者の追加・削除と権限の管理
• 問い合わせや障害の受付と記録

運用担当の方にヒアリングするときは、「手順書はありますか」より「先月、手でデータを直したことはありましたか」と聞くほうが、実態に近づけます。締めの前に毎月必ず発生する補正作業や、特定のエラーが出たときだけ行う手順など、手順書に載っていない作業が出てきます。そうした作業の多くは、システムの不具合や仕様の不足を人が埋めているものです。刷新の要件を考えるうえで、貴重な手がかりになります。

年に一度しか動かない処理にも注意が要ります。決算、棚卸、年度替わりのマスタ切り替え、税率や制度の変更への対応などです。調査の期間中に実際の作業を見られないことが多いため、前回の作業記録や、そのとき出た問い合わせを探しておきます。

運用担当の方は日々の業務で忙しく、まとまった時間をもらいにくいものです。障害の記録や問い合わせの履歴を先に読み、聞きたいことを絞ってから時間をもらうと、短いヒアリングでも中身が濃くなります。

契約と保守の期限は、いつ来るのか

技術や業務の調査に比べて後回しにされがちですが、契約と保守の期限は刷新の日程そのものを決めます。ハードウェアの保守終了、OSやミドルウェアのサポート期限、パッケージのライセンス、保守契約、データセンターや回線の契約。どれか一つが近いだけで、刷新の進め方の選択肢が変わります。

たとえば、サーバーの保守が切れるまでに新システムの稼働が間に合わない見込みなら、延長保守を買うのか、基盤だけ先に移すのか、刷新の範囲を絞って先に出すのかを考えることになります。期限を知らないまま理想の計画を描いても、後から引き直しになります。

契約書は、情シスではなく購買や法務の部署が持っていることがあります。期限だけでなく、自動更新の条件や、解約するときに何か月前までに通知が要るかも確かめておきます。通知の期限を過ぎると、使わない期間の費用まで払うことになりかねません。

現行システムの保守ベンダーとの関係も、この段階で見ておきたい点です。刷新ではデータの抽出や現行仕様の問い合わせなど、現行ベンダーの協力が欠かせない場面が多くあります。それが今の保守契約の範囲に入っているのか、別に依頼が要るのか。契約の読み方に迷うところは、自分で判断せず、法務や購買の担当者に確認を頼むのが確実です。

調べた結果を、判断に使える形で残す

5つの観点で調べたことは、刷新の方針を決める人が使える形で残します。分厚い報告書を作ることが目的ではありません。方針の判断に影響する事実を、すぐに読み取れるようにしておきます。

書き方で気をつけたいのは、次の三点です。

1. 確かめた事実と、推測を分けて書く。推測には「未確認」と付ける
2. 誰に、いつ聞いたか、どの資料で確かめたかを残す
3. 刷新の範囲や日程に影響するものを、冒頭にまとめる

たとえば、プロジェクトの定例で調査の途中経過を報告する場面を考えます。「連携は全部で何本です」と言い切ると、後から一覧にない連携が見つかったときに信頼を落とします。「ジョブ定義から確認できたのが何本、うち担当者への確認が済んだのが何本、未確認の候補が何本」と分けて伝えれば、聞く側も残りの作業量を判断できます。

図や一覧は、きれいに仕上げるより、関係者が直しやすい形を優先します。ヒアリングのたびに新しい事実が出てくるので、調査の途中で何度も書き換えることになります。版と更新日を入れ、前の版から何が変わったかを一言残しておくと、読む側も追いかけやすくなります。

未確認のまま残った事項は、一覧にして担当者と期日を決めておきます。現状調査は、すべてを調べ尽くしてから次に進むものではありません。分からないことを分からないと明示して、次の工程で確かめる段取りを組むことも、調査の成果の一つです。

最初の一週間で手をつけたいこと

刷新プロジェクトに入って最初の一週間は、資料を読む時間が大半になるはずです。そこで一つだけ先にやっておきたいのが、5つの観点ごとに「誰に聞けば分かるか」を書き出すことです。業務の流れなら各部門のどなたか。連携なら情シスのどの担当と、どの外部ベンダーか。契約なら購買か法務か。

聞く相手が見えると、ヒアリングの日程を早めに押さえられます。現状調査で時間を食うのは、資料を読むことより、話を聞くべき人の予定が合わないことのほうが多いものです。相手の一覧ができたら、プロジェクトの責任者に見せて抜けがないかを確かめてもらう。そこから調査を始めると、限られた期間でも、後の工程で困らない材料をそろえやすくなります。