LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

刷新するシステムの仕様書は、何年も前の版のまま更新されていない。業務部門に新しいシステムの要望を聞いても、「今と同じでいい」としか返ってこない——。システム刷新の現場では、こうした行き詰まりが起こりがちです。システム刷新の要件定義とは、いま動いているシステムと業務を把握したうえで、新しいシステムをどの業務に使い、どんな機能や性能を備えるかを決め、文書にまとめる工程です。

現行システムを調べる作業には、SES（技術者が客先で働く契約の形）で参画したエンジニアの力を借りやすい場面が多くあります。ただし万能ではなく、何を変えて何を残すかという判断までは任せられません。その判断には、業務を担う人の考えが要るためです。本記事では、システム刷新を担当する開発マネージャーに向けて、「現行どおり」が要件にならない理由、SESのエンジニアに頼みやすい作業、社内で決めること、進める手順、そして外部のエンジニアに頼むときに確認したい点を整理します。

システム刷新の要件定義とは

要件定義で決めることは、デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（DS-100）が分かりやすく整理しています。政府の情報システムづくりの共通ルールで、要件定義書には業務要件、機能要件、非機能要件、情報システムの実現案を書くと定めています。^*2 業務要件はシステムを使った業務の内容、機能要件はシステムが備える機能、非機能要件は性能や信頼性、データの移行など機能以外の条件、実現案はそれらをどんな構成で実現するかの案です。民間企業の刷新でも、この4つに分けておくと抜けを確かめやすくなります。

新しくシステムを作る場合と違い、刷新では、いま動いているシステムが出発点になります。IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」は、再構築のときの要件定義が難しい例として、業務やシステムを理解している人がいなくなり仕様が書けないこと、「現行踏襲」（今のシステムと同じにすること）というあいまいな要求になることを挙げています。そのうえで、現状の可視化や理解、変える変えないの判断を工夫する必要があるとしています。^*1

要件定義にかける期間の割合も、刷新と新規開発で大きくは変わりません。同じガイドがJUAS（情報システムを利用する企業の団体）の2016年の調査をもとに示した表では、要件定義から、発注側が最後に行う総合テストまでの工期のうち、要件定義が占める割合は、再開発・改修の43件で23.2%でした。新規開発の33件では21.8%です。^*1

なぜ「現行どおり」では決まらないのか

刷新の要件定義で、業務部門からいちばん出やすい要望が「今と同じでいい」です。IPAのガイドは、既存システムに変更がない部分が「現行踏襲」という安易な要求で片付けられがちだと指摘しています。ところが、同じにしたい中身を説明できる人が、社内にもう残っていないことがあります。

ガイドはさらに、「「現行どおり」という要求提示は、要件定義ではない。」と書いています。続けて、今の機能を具体的に書き出せないうちは、要件定義を終えられないとしています。^*1 「今と同じ」と書いただけの要件定義書を受け取った設計の担当者は、結局、動いているシステムを自分で調べ直すことになります。調べ直した結果が業務部門の考える「今と同じ」と違っていれば、そこで作り直しが起きます。

作り直しは、見つかるのが遅いほど重くなります。ガイドは、要件定義工程で気がついた修正の作業負荷は少ないものの、設計、実装、総合テスト、稼働後と工程が進むほど大きくなると述べています。現行の機能を言葉にする作業は、要件定義の段階で済ませておくのがいちばん負担が少ない、ということです。

SESのエンジニアに頼みやすい作業

資料も詳しい人も残っていないとき、手がかりになるのは動いているシステムそのものです。IPAのガイドは、勘どころ（ガイドが挙げる実務の要点）の一つ目に「現行システムから可視化する」を挙げ、実際に動いているシステムから動作を可視化することが現行分析の第一歩になるとしています。可視化できる情報として、次の6つを例に挙げています。^*1

• データモデル（データベースから）
• モジュール構成・クラス構成（プログラムコードから）
• 処理ロジック（プログラムコードから）
• ジョブスケジュール（ジョブ管理ツールの設定から）
• OS、ミドルウェア、ソフトウェア設定（設定ファイルから）
• 接続先システム情報（データ連携ツールの設定から）

データモデルはデータの項目とそのつながり、処理ロジックは処理の手順、ジョブスケジュールは夜間などに自動で動く処理の予定のことです。どれも、プログラムやデータベースを読める人でないと進まない作業です。現行システムと同じ言語やデータベースを扱った経験のあるSESのエンジニアに、まずこの作業を頼むと進めやすくなります。社内の担当者が日々の保守と並行して調べるより、調べる作業に時間を充てられる人がいるほうが早く進みます。

調べた結果は、詳しくない人でも読める形にしてもらいます。ガイドは二つ目の勘どころとして、詳しくない担当者でも理解できるよう、要点にしぼって全体像を文書にする必要があるとしています。例に挙がっているのは、システム同士のつながりを示すシステム間関連図、システム構成図、概念データモデル、画面の移り変わりを示す画面遷移図、業務スケジュールです。^*1 業務部門の人が見て「この処理は今も使っている」「この帳票はもう誰も見ていない」と答えられる図にしておくことが、次の段階の材料になります。

運用マニュアルや新人研修用の資料、部署ごとの担当業務を定めた規程など、社内に埋もれている資料を探す作業もガイドは勧めています。ただし、どの資料をエンジニアに見せてよいか、どの部署に保管されているかを知っているのは社内の人です。探す作業は頼めても、資料を出す手配は社内の仕事になります。

社内で決めること

現行システムから分かるのは、システムがどう動いているかまでです。ガイドも、なぜそうなっているかは分からなくても、どういう動作をしているかは可視化できると書いています。その処理がなぜ必要なのか、新しいシステムでも残すのかは、業務を担う人が判断することです。ガイドが三つ目以降の勘どころで、現行システムを操作して疑問点を記録すること、業務担当者へのインタビュー、実作業の観察を挙げているのはこのためです。

判断する人の組み合わせについて、DS-100は、機能要件、非機能要件、実現案を情報システム部門だけで決めるのではなく、業務を実施する部門などを含めたプロジェクトの体制全体で決めることが不可欠だとしています。^*2 民間企業に置き換えれば、情報システム部門と業務部門が一緒に決める、ということです。SESのエンジニアは判断の材料を出す役で、決めるのは社内の人です。

決めきれない点は、決めきれないまま書き残します。DS-100は、定義の時点で未確定な要件がリスク要因になり得ることに留意し、その旨を要件定義書で明らかにするよう求めています。あわせて、定義した内容を、必要性、網羅性、具体性、定量性、整合性、中立性、役割分担の明確性の観点から確かめるとしています。^*2 この7つは、社内で要件定義書を読み合わせるときの確認項目にそのまま使えます。

どう進めるのか

ここまでの内容を段階ごとに並べると、SESのエンジニアに頼む作業と社内で決めることは、次のように分けられます。

3つ目の仕分けでは、「残す」と決めた機能も、何を残すのかまで書きます。たとえば「月末の締め処理は、いま夜間に順番に動いている3本のジョブの処理内容と順番を残し、1つの機能にまとめる」と書けば、設計の担当者は何を作ればよいかが分かります。「締め処理は現行どおり」と書くのとは、後で調べ直す量が大きく違います。

4つ目の要件定義書では、DS-100が機能要件の項目として挙げる、機能、画面、帳票、データ、外部インタフェースの5つが下書きの枠組みになります。外部インタフェースについては、相手先の情報システム、送受信データ名、送受信タイミング、送受信の条件などを一覧にするとしています。^*2 1つ目の段階で、データ連携ツールの設定から接続先を調べてあれば、この一覧の大部分はそこから書けます。

つまずきやすい点

一つ目は、図を作った時点で現行の把握が終わったと考えてしまうことです。ガイドは、業務の流れを書き出して可視化するのは現行を理解する第一歩にすぎず、実際の業務担当者の作業と照らし合わせて確かめるよう勧めています。表の2つ目の段階を飛ばすと、システムには残っているのに業務では使っていない機能まで、新しいシステムに引き継ぐことになります。

二つ目は、非機能要件のうち、刷新に特有の項目を後回しにすることです。DS-100は非機能要件の項目として、本番環境への業務移行、システム移行、データ移行について移行時期、移行方式、移行対象、移行環境などを記載するとしています。^*2 古いシステムのデータをどこまで新しいシステムに移すかは、データベースを調べたエンジニアの材料がないと決められません。可視化の段階で、データの件数や保存期間も一緒に調べてもらっておくと、移行の要件を早く書けます。

三つ目は、調べた結果がエンジニア個人の手元にしか残らないことです。DS-100は、要件定義書が次の工程以降や後続のプロジェクトでも引き続き使われることに留意するよう求めています。作った図や一覧は、社内の共有の場所に置いてもらい、誰が見ても最新の版が分かるようにしておきます。参画したエンジニアが別の案件に移っても、刷新の要件定義を続けられるようにするためです。

外部のエンジニアに頼むときに確認しておきたい点

SESのエンジニアに現行の可視化を頼む前に、確かめておきたいのは3つです。まず、現行システムと同じ言語やデータベース、ジョブ管理ツールを扱った経験があるか。次に、既存のシステムを調べて資料にまとめた経験があるか。新しく作る開発の経験だけでは、読み解く作業に時間がかかることがあります。最後に、作ってもらう図や一覧の種類と形式を、参画の前に決めておけるかです。

社内の準備として、調べるための環境も用意しておきます。ガイドは、現行システムを実際に操作して確かめるとき、試験環境や擬似本番環境があればそれを使うほうが望ましいとしています。本番のデータベースに直接触れずに済む環境があれば、調べる作業の途中で本番のデータを書き換えてしまう事故を防げます。仕様書が古いまま残っているときの直し方は「レガシーの仕様書が古いときに引き継げる形へ直す4つの手順」で、社内の担当者がどこまで関わるかの決め方は「内製化支援の伴走、どこまで一緒にやるかは4つの段階」で扱っています。

まとめ：刷新の要件定義で確かめたい3つの点

SESのエンジニアとシステム刷新の要件定義を進めるうえで、確かめておきたい点は3つに整理できます。第一に、「現行どおり」で済ませず、残す機能も中身まで書くこと。第二に、現行システムを図と一覧にする作業はエンジニアに頼み、変える・残す・やめるの判断は情報システム部門と業務部門が一緒に行うこと。第三に、未確定の点と調べた結果を、社内で共有できる形で要件定義書に残すことです。この3点を踏まえておけば、「設計に入ってから、今と同じはずの機能が違っていると分かった」という事態を避けやすくなります。現行システムを読み解ける人が社内に見つからなければ、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（PDF）（https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf）。出典：独立行政法人情報処理推進機構 社会基盤センター（2019年）。1.1（再構築の難しさ）、1.2.4（再構築時の要件定義）、2.1.1（「現行どおり」という要求提示、表2.1 開発工程別工期比〔JUAS「ソフトウェアメトリックス調査2016」をもとに作成〕、非機能要求の重要性）、2.1（修正の作業負荷）、4.1.1 現状の把握（勘どころ①〜⑤）を参照（2026年9月確認）
2. *2　参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：2026年6月12日 デジタル社会推進会議幹事会決定。第3編第5章「要件定義」（要件定義書の記載内容、決定の主体、未確定な要件、確認の観点、機能要件・非機能要件の項目、システム方式の決定、要件定義書の調整・作成）を参照（2026年9月確認）

Tweet