システム発注者側が要件定義の際に実施すべきことやポイントを解説
目次
この記事で理解できること
本記事では、新システムの導入や既存システムの刷新に向けて、発注先のシステム開発会社が決まり、システム開発会社と実施する要件定義フェーズにおいて発注者側として実施すべきことや意識すべきポイントを解説いたします。
システム開発会社に発注した後、発注者側はシステム開発会社側任せにしてよいわけではありません。システム開発会社に任せきりにせず、今後自分たちで使うシステムを完成させるために、適切な情報を伝える必要があります。
特に、パッケージを導入する場合の要件定義の内容や進め方は、スクラッチ開発の際の要件定義とは異なり、パッケージの機能をベースに要件を検討することになります。
システム発注プロセスの中での位置づけ
本記事では、システム発注プロセスにおいて、「④要件定義」を解説します。
システム開発会社への発注後、発注者側と開発者側が一緒に取り組むフェーズです。
システム発注プロセスの全体について把握しておきたい方、前フェーズの「要求仕様策定・システム開発会社選定」について実施内容やポイントを知りたい方は、こちらの記事をご覧ください。
「要件定義」フェーズの進め方の全体像
本記事で紹介する要件定義フェーズは、以下の図のように進めていきます。
システム開発会社とプロジェクトを開始する
まずは、要件定義の業務に着手する前に、発注者側とシステム開発会社の間で、プロジェクトの計画やプロジェクト管理の方法を検討し合意します。
プロジェクト実施計画・プロジェクト管理要領を具体化する
既に自社内で作成をした「システム導入/刷新計画書」や、発注先を選定する際にシステム開発会社から受領した提案書をもとに、「プロジェクト実施計画」と「プロジェクト管理要領」を具体化します。
それぞれ、以下のような要素から構成されます。
- プロジェクト実施計画
要件定義フェーズにおけるプロジェクト体制、スケジュール、会議体計画、成果物イメージなど
- プロジェクト管理要領
WBSやガントチャート、課題管理表、タスク管理表、各種管理資料の運用方法、コミュニケーション方法など
プロジェクトのキックオフ会議を実施する
プロジェクト実施計画やプロジェクト管理要領が具体化できれば、それらの内容を合意してプロジェクトをスタートするために、関係者を集めてキックオフ会議を実施しましょう。
キックオフ会議では、プロジェクト体制に含まれる関係者同士の顔合わせを行い、プロジェクト実施計画やプロジェクト実施要領の認識合わせを行います。
パッケージをベースに要件を検討する
パッケージを導入する場合、基本的にはパッケージをベースにして要件を検討します。
Fit＆Gap分析を実施する
自社内で検討していた新システムの機能要求が、システム開発会社の提供するパッケージとどれぐらい適合（Fit）しており、適合していない（Gapがある）場合はどのような対応をとるのかを検討します。
方法としては、新システムを使うことになる業務担当者が実際のパッケージ製品を操作し、パッケージの標準として想定している業務フローで、自社の業務が遂行できるかどうかを確認します。これまで検討してきた機能要求をベースに一つ一つ確認をしていき、機能要求とパッケージ製品の差異（Gap）を洗い出します。
実際にシステムを触って確認を行うことが重要になるため、システム開発会社に対しては、要件定義用の環境を構築してもらうように事前に依頼しておきましょう。
また、システムの非機能要件についても、これまで発注者側で検討してきた非機能要求仕様をもとにシステム開発会社と調整をして、非機能要件として策定します。パッケージの場合、システム開発会社が約款や利用規約のひな形を用意している場合が多いため、ひな形の中で個別に調整したい点を協議します。
Gapへの対応策を検討する
前述のFit＆Gap分析で洗い出されたGap事項を整理し、優先度の高いGap事項については、アドオン開発を検討します。
※アドオン開発とは、標準のパッケージ発注者側の仕様に応じた独自の機能を追加するために開発することです。（パッケージが持つ標準機能には手を入れません）
システム開発会社に対して、アドオン開発規模の見積もりを依頼し、受領した見積もり結果も考慮した上で、Gap事項への対処方法を「①運用での対処」「②BPR（既存業務自体を変革する）」「③アドオン開発」の3つのいずれかに仕分けします。
また、非機能要求でのGap事項については、発注者側からの要求水準を緩和する、もしくは他の方法でカバーする方法がないか検討します。
アドオン開発事項の要件定義を行う
アドオン開発を実施することになった場合、その領域については必要な機能を定義して、要件定義を実施します。
ここで検討した要件定義内容をインプットとして、システム開発会社にて後続の実装フェーズにおける開発費用の見積もりを行います。
BPR検討計画を作成する
BPR（ビジネス・プロセス・リエンジニアリング）で対処する方針となったGap事項については、BPRを進めるにあたり、業務設計の担当者や業務設計を検討するスケジュールなどを策定し、BPR検討計画を作成します。
※BPRとは、既存業務のプロセスを根本から見直して再設計することです。BPRについては、以下の記事で詳しく解説していますのでぜひご覧ください。
非機能要件（プロジェクト推進）を調整し確定する
プロジェクトの推進に関する非機能要求についてもシステム開発会社と調整を行い、非機能要件として確定させます。内容としては、テスト、移行、引継ぎ、教育、運用、保守、プロジェクト管理などです。
プロジェクト推進に関する非機能要件は、発注者側が事業特性や自社のルール、業務やシステムの特性に応じて検討することが基本であるため、システム開発会社の提供するパッケージにあわせて要求を決めていくということができません。
特に、「テスト」、「移行」については、相互に検討内容を反映させながら注意して検討を行っていきます。
テスト全体方針書を作成する
プロジェクトの要件や移行方針書を踏まえ、今回のパッケージ導入におけるテスト全体方針書（各テスト工程の定義、実施者、テストデータの準備方法、使用環境など）を、発注者側とシステム開発会社が共同で作成します。
特に、発注者側は、受け入れテストなどの部分の検討を主に実施します。
テスト全体方針書を作る目的は、システム開発会社ごとに各テスト工程の定義や考え方が異なるためです。一致した定義は存在しておらず、また、パッケージへのアドオン開発の範囲によってテストの内容が異なるため、プロジェクトごとに検討する必要があります。
移行方針書を作成する
プロジェクトの要件やテスト全体方針書を踏まえ、移行方針書（データ移行範囲、教育のタイミング、現行システムの停止や新システムの稼働タイミング、移行時の役割分担など含む）を作成し、発注者側とシステム開発会社で内容を合意しましょう。
他システムと連携するための要件を定義する
また、導入しようとしている新システムが、社内にある他のシステムと連携する場合、システム間での連携内容（連携タイミングや、データ形式など）を定義します。（これを、「外部インターフェース」の定義と呼びます。）
社内の連携先の他システムの担当者には、後続の実装フェーズやテストフェーズでもテスト用のデータを提供してもらうなど対応してもらうことが増えるため、協力を仰ぎましょう。
後続の「実装」フェーズを具体化する
最後は、上記の検討を実施し作成された、「アドオン開発事項の要件定義書」「テスト全体方針書」「移行方針書」「外部インターフェイス定義書」を踏まえ、後続の実装フェーズのWBSを具体化して、要件定義フェーズは終了となります。
次の実装フェーズについても、以下の記事で解説しています。ぜひ続けてお読みください。
この記事の編集者
GPTech編集者
IT調達ナビの運営会社である、（株）グローバル・パートナーズ・テクノロジーに新卒入社。 ITコンサルティング業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するというメディア運営業務にも携わる。
