システムリプレースの要件定義とは？現行調査と移行の決め方

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

システムリプレースの要件定義とは？新しく作る時と違うところ

リプレースとは、今使っているシステムを新しいシステムに入れ替えることです。

保守の期限が近づいた、使い勝手が業務に合わなくなった、作った人がいなくて直せない、などがきっかけになりますよね。

リプレースでも、要件定義（RD：Requirements Definition）で決めることの基本は変わりません。

ただ、今のシステムがあるぶん、新しく作る時にはない作業が加わるんです。

要件定義の基本から確かめたい方は、要件定義とは？意味をわかりやすく解説を先に読んでみてください。

「今と同じでいい」が危ない理由

リプレースの会議で、「機能は今と同じでいいので」と言われること、よくありますよね。

一見わかりやすい要件ですが、この一言にはいくつかの問題が隠れています。

さらに、今の機能の中には、もう誰も使っていないものや、業務に合わなくなったものも混ざっています。

それをそのまま新しいシステムに持っていくと、費用をかけて要らない機能を作り直すことにもなりかねません。

「今ある機能をそのまま」に頼らない、現行調査のチェックリスト

現行調査とは、今のシステムが何をしていて、誰がどう使っているかを調べる作業です。

リプレースの要件定義は、この現行調査の深さで出来が大きく変わります。

特に見落としやすいのが、夜間や月末に自動で動いている処理と、利用部門がシステムの外で補っている作業です。

どちらも画面には出てこないので、画面を一つずつ見ていくだけでは見つかりません。

表に出ていない処理を見つける聞き方

『画面を全部見たから大丈夫』と思っていても、抜けていることがあります。

利用部門には、画面の使い方ではなく、業務の流れに沿って聞いてみるのがおすすめです。

「月末の締めの日は、システムを使ってどんな作業をしていますか？」と開発側が聞きます。

「締めの翌朝に、システムから届く一覧を表計算ソフトに貼って、部長に送っています」と利用部門が答えます。

この答えから、「締めの夜に自動で一覧を作る処理」と「表計算ソフトで補っている作業」の2つが見えてきます。

設計書が古い、または無い時の調べ方

長く使ってきたシステムほど、設計書が今の中身と合っていないことがよくあります。

設計書が無い、あっても古いという場合は、次の順で調べていくと進めやすくなります。

全部を調べきれない時は、業務への影響が大きいところから順番に調べましょう。

機能だけでなく、品質の実績も調べておく

現行調査というと機能に目が行きがちですが、今のシステムがどのくらいの品質で動いているかも大事な材料です。

リプレースの後に「前より遅くなった」と言われるのは、今の速さを誰も測っていなかった時によく起きますよね。

今の数字がそろっていれば、新しいシステムの非機能要件を、根拠を持って決められます。

今の業務と目指す業務を比べる方法は、要件定義の業務分析（As-Is/To-Be）で詳しく解説しています。

機能ごとに「残す・やめる・変える」を決める

現行調査が終わったら、集めた機能を一つずつ判断していきます。

ここでは架空の題材として、「顧客ごとの契約と保守の期限を管理している社内の契約管理システムを入れ替える場合」で書いてみます。

「やめる」と判断した機能は、その理由と、判断した人も書き残しておきましょう。

後から「あの機能はどこへいったの？」と聞かれた時に、すぐに答えられます。

判断に迷う機能はどう扱う？

『使っている人が少ないけれど、無くすと困る人がいるかも…』と迷う機能もありますよね。

迷う機能は、その場で決めずに、使っている人に直接聞いてから決めるのがおすすめです。

移行要件定義：システム移行とデータ移行で決めること

システム移行の要件定義は、今のシステムから新しいシステムへ、業務とデータを移すための条件を決めることです。

その中でも、データ移行の要件定義は特に細かく決める必要があります。

『データは機械的に移せるのでは？』と思う方も多いはずです。

ただ、長く使ってきたシステムのデータには、表記の揺れや、入力の決まりが途中で変わった跡が残っています。変換のルールを決めずに移すと、新しいシステムで検索できないデータが出てきてしまいます。

移行の要件定義の進め方

6番目の「戻す条件」は、つい後回しにされがちです。

切替の当日に問題が出た時、その場で判断するのは難しいので、要件定義の段階で決めておきましょう。

移行の作業は、誰が何を受け持つ？

データ移行では、発注側と開発側の受け持ちがあいまいになりやすいです。

『データを移すのは開発側の仕事でしょう？』と思われがちですが、データの中身を判断できるのは発注側なんです。

受け持ちは会社や契約の形で変わりますが、要件定義の段階で表にして合意しておくと、切替の直前に慌てずに済みます。

切替の時期は、業務の都合から決める

切替日は、システムの都合だけでなく、業務の都合から決めることが大事です。

例えば、締めの処理の途中で切り替えると、今のシステムと新しいシステムにデータが分かれてしまいますよね。

締めが終わった直後や、業務が少ない時期など、利用部門と相談して決めてみてください。

インフラ側の移行の条件は、インフラエンジニアの要件定義で扱っています。

システム改修とリプレース、どちらで進める？

システム改修の要件定義と、リプレースの要件定義は、進め方が少し違います。

改修は、今のシステムを生かしたまま、一部の機能を直したり足したりすることです。

改修の要件定義で特に大事なのは、直す部分がつながっている他の機能への影響を調べることです。

「この画面に項目を一つ足すだけ」のつもりが、帳票や他のシステムへの受け渡しまで直す必要があった、ということはよくあります。

改修の要件定義で書いておくこと

改修の要件定義は、リプレースより範囲が小さいぶん、書く項目を絞り込めます。

ただ、小さな改修ほど口頭のやり取りだけで進みやすく、後から「そんな話だったかな」となりがちです。

例えば「契約の一覧に担当者の欄を足す」改修なら、一覧を使った帳票や、他のシステムに渡すデータにも担当者を足すのかまで書いておきましょう。

どちらで進めるかは費用とも関わるので、見積もりの読み方は要件定義の費用相場も参考にしてみてください。

新しい業務システムを入れる時の進め方は、システム導入・構築の要件定義で解説しています。

よくある相談に答えます

改修や保守の仕事でも、要件定義の力はつく？

今のシステムの改修や保守の仕事が中心で、要件定義の経験が積めるか不安、という相談があります。

結論から言うと、改修の仕事は要件定義の力をつける場としてとても向いています。

改修の依頼を受けた時に、「何のために直すのか」「どこまで影響するか」を自分で確かめて書く習慣をつけてみてください。

今のシステムの中身を知っている人は、リプレースの現行調査でも頼りにされる存在になります。

元請けの要件定義書をもとに作る時、どこまで確かめる？

元請けが作った要件定義書や設計書をもとに、開発以降を担当する立場で悩む声もあります。

受け取った要件定義書に、リプレースの場合は「今と同じ」とだけ書かれた箇所がないかを確かめてみてください。

もしあれば、今のシステムのどの機能のことか、作業を始める前に質問しておくのがおすすめです。

疑問を早めに出すことは、相手を疑うことではなく、手戻りを防ぐための確認なんです。

リプレースのスケジュールを根拠を持って立てたい

システム開発全体のスケジュールを、根拠を持って立てられるようになりたい、という相談もよく見かけます。

リプレースの場合、スケジュールの根拠になるのは、現行調査で数えた機能の数と、移すデータの量です。

『経験が浅いから、根拠なんて出せない…』と思うかもしれません。

まずは、この記事の棚卸しの表と移行の表を埋めて、「何をどれだけやるか」を数で見える形にしてみてください。それだけでも、周りと話す時の根拠になります！

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

インフラエンジニアの要件定義とは？基盤で決めることを6項目で

要件定義のAs-Is/To-Be分析とは？業務分析のやり方と記入表