SAP導入プロジェクトにおける要件定義フェーズ｜位置づけや流れを解説！

今回はSAP導入時の最上流工程である、要件定義フェーズについて解説します。SAP導入プロジェクトに関わるコンサルタントとして必須である、要件定義フェーズの流れや具体的な実施内容・成果物について理解を深めるための一助となりましたら幸いです。

要件定義フェーズは、SAP導入時の最上流フェーズに当たります。

今回の記事では、要件定義フェーズの流れや具体的な実施内容を解説します。
要件定義フェーズで、どのように業務/システム要件が明確化されるかに焦点を当ててみていきましょう。

SAP導入における要件定義フェーズの位置付け

SAPの導入プロジェクトは、V字モデルで進みます。

V字モデルとは、SAP導入の流れにおける後半のテスト工程が、前半の開発工程に対応していることを表したモデルです。 V字左側上部の「構想策定フェーズ」から下のほうへと順に設計工程が進み、「設計フェーズ」まで完了します。その後、「実現フェーズ」をスタート地点としてテスト工程が進み、V字の右側上部の「稼働後支援フェーズ」へと移っていきます。

要件定義フェーズは、V字モデルの最上流に位置します。要求分析と要件定義を行うことで、PJの目的を実現するための業務/システム要件とPJスコープの明確化が目的です。

要件定義フェーズ実施の流れ

要件定義フェーズには、要求分析と要件定義の２ステップがあります。
この2ステップを通じて業務/システム要件とPJスコープが明確化されます。

要求分析では、クライアントが基幹システムに対して何を求めているのかという「要求」を明らかにしていきます。
具体的には、クライアントへのインタビューで受け取った要望について、定められた判断基準やコンサルタントとして蓄積している知見をもとに評価し、明確化します。

インタビューでは、経営陣、現場などさまざまな立場の方から幅広くニーズや期待を伺います。インタビューによって受け取る要望は偏っていたり、粒度にばらつきがあったり、不正確であったりします。それらの雑多な要望を、コンサルタントとしてのノウハウや知見を活かして具体化・整理します。

要件定義では、導入するSAPで実現することを決めます。
要求をさらに具体化・整理し、抜け漏れや曖昧性がない要件に落とし込みます。関係者で合意済みの文書として要件定義書を作成することで、要件定義フェーズは完了となります。
なお、クライアントのニーズと異なる要件を実現しても価値にはつながらないため、要件について抜け漏れないメンバーで合意することは非常に重要です。　

※要望・要求・要件の違い（カッコ内は例）
要望：抽象的な実現したいこと。（おなかが空いたからカレーが食べたい）
要求：要望を優先度や制約を考慮して具体化・整理したもの。（大盛りがないため揚げ物で満足感を得たい、エビアレルギーのためエビは食べられない）
要件：要求をさらに具体化・整理したもの。抜け、漏れ、曖昧性がない状態。（ポークカレー、フライ盛り合わせをトッピング、エビフライは抜き）

要件定義フェーズで実施する内容

要件定義フェーズのゴールは、先述の通り関係者が合意した要件定義書の完成です。要件定義書では、PJのゴールやスコープが明確になっていることが必要です。
ゴール達成のために、以下の６ステップを実施します。
①〜③で業務要件定義がなされた後、④〜⑤でシステム要件定義が実施され、⑥で合意をとることで、業務要件定義書やシステム要件定義書といった成果物が完成します。

①As-Is分析

As-Is分析では、現行の業務プロセス/システムの把握と、課題や改善点の洗い出しを実施します。具体的な実施内容は、各部門の関係者へのインタビューや関係者とのワークショップを通じて情報を収集し、業務フロー図を作成します。

この段階で作成する業務フロー図は、後の要件抽出に強く結びついています。
そのため、一部の意見やデータに基づいた業務フローとならないよう十分な注意が必要です。
また、現状の非効率な部分や役割分担が不明瞭な部分の見落としにつながるため、パターンに抜け漏れのない業務フローを作成しましょう。

②業務要件定義

業務要件定義では、To-Be業務プロセスの設計を行い、SAPで実現する業務要件を明確にします。
具体的には、関係者と壁打ちをしながらTo-Be業務フロー図を作成します。このステップでは、成果物として業務要件定義書を作成します。

このステップのポイントは解像度を意識することです。
例えば、曖昧で具体性に欠けた不明確な業務要件定義により、後工程の方向性が当初の方向性からぶれてしまうことがあります。

また、実現可能性を意識することも重要です。費用や時間を度外視した多すぎる要件を定義したことが原因で、要件を完了できないケースがあります。

③ウォークスルー

ウォークスルーでは、要件の詳細を確認し、PJ担当者・技術チーム・ユーザー・ステークホルダーなどすべての関係者と合意をとります。
具体的には、要件定義書を共有して説明し、質疑応答を実施します。
この際に出た要件に関するクライアントからのFBは記録し、要件定義書へ反映します。

この段階では、確認を網羅的かつ偏りなく実施することが重要です。
一部の視点に偏ったり、十分な時間を確保できずに網羅的な調査ができなかったりすると、潜在的なエラーや問題点の見落としにつながってしまいます。

④システム要件定義

システム要件定義では、業務要件を満たすための機能要件/非機能要件、技術要件などの定義を行います。
具体的には、業務要件定義書をもとにして技術チームなどと相談しつつシステム間連携やデータフローを図示します。
このステップでは、成果物としてシステム要件定義書を作成します。

この段階では、業務要件定義と同様に、解像度を意識することが必要です。例えば、曖昧で具体性に欠けたシステム要件定義は、後から仕様書の修正が頻発するリスクを高めてしまいます。

また、要件の実現可能性も重要です。業務要件を満たすために過剰な技術要求をしてしまうと、要件を完了できないことがあります。

⑤プロトタイプ作成

プロトタイプ作成では、主要機能の実装と、ユーザーからのFBの収集・要件への反映を行います。

この段階で気をつけるべきポイントの一つは、実際の使用感を得られるプロトタイプを作成することです。機能が限定されていて実際の使用感が得られないプロトタイプを作成してしまうと、主要機能の改善に繋げることができなくなってしまいます。

また、逆にプロトタイプ作成に過度のリソースを投入し、他のフェーズに影響を及ぼすこともあります。作成するプロトタイプの目的を明確に持った上でスコープや完成度を決め、それにあったリソース配分が重要になります。

⑥要件合意

要件合意では、すべての要件の承認と確定を行います。
具体的には、要件レビューと修正・承認を実施しますが、その中で関係者間での調整が必要になります。
このステップを通じて、共通理解を形成し、関係者の認識齟齬によるプロジェクトリスクを最小化することを目指します。

この段階で重要なことは、すべてのステークホルダーと各日に合意を取り、文書として残すことです。
一部のステークホルダーで認識齟齬があり合意に曖昧さが残ってしまったり、要件合意文書に不備があったりすると、後から誤解やトラブルが発生する要因になります。

定義が必要な代表的要件

要件定義フェーズで定義が必要な要件は、大きく業務要件とシステム要件に分類できます。

業務要件とは、To-Beで実現するべき要件のうち、業務観点のものだけを指します。業務パターン別の業務フローや業務ルールとして具体化されます。
業務要件には、業務プロセスに対する要件のみならず、データやレポートに対して業務上実現が必要な事項も含まれます。

システム要件とは、業務要件を満たすために、システムが満たすべき具体的な条件を指します。システム要件はさらに、機能要件、非機能要件、技術要件に分けられます。

代表的要件の必要項目を把握して漏れなく要件定義を実施することは、手戻りによる工数増大を防ぐことにつながります。

まとめ

• 要件定義フェーズのゴールは、PJ目的を実現するための業務/システム要件とPJスコープの明確化

• 要件定義フェーズの成果物は、PJ関係者全員で確実に合意済みの要件定義書

• 要件定義での定義内容は、 PJの目的達成のための業務要件定義と、業務要件を満たすためのシステム要件定義の2種類

• システム面・業務面ともに網羅的に明確に行うことが重要で、業務要件定義→システム要件定義の順で実施

今回は一般的な要件定義フェーズの流れをご紹介しました。しかし厳密には、SAPのソリューションによって要件定義フェーズの手法が異なることが一般的です。

以下では、実際に使える、SAP COの要件定義書を添付します。