要件定義の進め方を定める！要件定義計画策定のやり方を解説します。

企画構想フェーズでの承認が通り、ベンダーへの発注や社内要員調整等が完了したら、システム導入の工程が本格的にスタートします。
そして、システム導入工程において最初にやるべきタスクは「要件定義」です。要件定義とはユーザ（発注者）の現行業務や実現したい要望などをヒアリングし、あるべき姿を実現するためにどのような機能を持ったシステムを構築していくかを検討していくフェーズです。
当記事では要件定義フェーズの進め方を定める「要件定義計画策定」について解説していきます。

要件定義フェーズの実行計画を策定する目的と内容
まとめ

要件定義フェーズの実行計画を策定する目的と内容

どのフェーズにおいても作業を開始する前に、実行計画を策定することが重要になりますが、その目的は要件定義に参画するメンバー全員の足並みを揃え、各種タスクをスケジュール通りに推進・管理していくためです。
この目的を果たすために、要件定義を行うために必要な計画は以下のような内容を策定します。

要件定義の基本方針を定義する
要件定義を実施する体制・役割を定義する
要件定義のスケジュールを定義する
要件定義対象の業務範囲を定義する
要件定義で作成する成果物を定義する
成果物の管理ルールを定義する

要件定義の方針を定義する

まず最初に策定するべきは、要件定義の基本方針です。パッケージシステムを導入する場合の基本方針は大きく2つに分けられます。
1つはパッケージを業務に合わせてカスタマイズしていく方針、もう1つがパッケージに合わせて業務を変えていく方針です。
この2つの方針は、対象の業務がその事業の競争の源泉になっているかどうかで使い分けることができます。
競争の源泉になっている業務に対して、グローバルスタンダードを取り入れたパッケージを導入し、システムに合わせて業務を変えてしまうと、競争力が失われてしまう可能性があります。
一方、競争の源泉ではないのにも関わらず、業務を変更しないでパッケージシステムをカスタマイズしてしまうと、イニシャルコストやランニングコストが一気に高くなってしまいます。
また、パッケージシステムを使う利点の1つである、ベンダーによるシステムのアップデートを受けることが難しくなってしまいます。

要件定義を行う前に、上記のような基本方針を定めることで、プロジェクトメンバーがどういう軸で要件出しすればいいかが定まりますので、必ず設定し周知するようにしましょう。

体制・役割を定義する

要件定義は開発ベンダーが主体となって行うフェーズではありません。ユーザ（発注者）が主体となり新しい業務そのものや、その業務に必要となる機能などを決めていきます。
そのため、ユーザ側の体制構築と役割の定義が重要なります。もちろんユーザ側だけでなく、ベンダー側の体制・役割の定義も必要になります。
ユーザ側の体制を作るときは以下のようなポイントがあります。

業務を熟知するキーユーザを参画させる
システム導入によって不利益を被るユーザを積極的に参画させる
若手を積極的に参画させる

１つ目の業務を熟知しているユーザを参画させるというポイントは言うまでもありませんが、このキーユーザがどれだけプロジェクトに参画できるかにシステム導入の成否がかかっています。
過去のプロジェクトで見ても、キーユーザのプロジェクトへの稼働率が極端に低いプロジェクトは、高確率で炎上し、システム導入は失敗する傾向にあります。
通常業務もあり調整が難しいところではありますが、特に要件定義フェーズでは重要なポイントとなりますので可能な限り100％に近い稼働率でアサインできるようにしていきましょう。

２つ目のシステム導入によって不利益を被るユーザを積極的に参加させるという点についてですが、新しいシステムの導入には大なり小なり不利益を被ることになるユーザが現れます。
不利益を被るというのは、新しいシステムの導入により、これまで行なっていた業務が変わってしまうため、その業務の担当者としては慣れていた仕事を手放さなければいけなくなることを言っています。
そう言ったユーザを積極的にプロジェクトに参画させ、業務改革の当事者として活動してもらうこともプロジェクトを円滑に進めるためのテクニックになります。

3つ目の若手を積極的に参画させるというポイントについてですが、構築したシステムをより長く使っていくのは若手です。その若手がシステムの構築に携わることで、引継ぎの手間も解消され、継続的により高い効果を得ることができます。
また、分からないことも多い若手ですが、プロジェクトに参画させることで自分たちの業務内容や仕事の進め方などを理解することができます。
プロジェクトマネージャーや先輩社員は苦労する点も多くなりますが、将来的にはその若手に仕事を任せることができるようになる為、積極的にアサインするようにしましょう。

要件定義のスケジュールを定義する

要件定義フェーズで行われる主な工程は以下の通りです。

ASIS分析・整理
TOBE設計・合意
要件定義
ステコミ承認

上記の各工程ごとに、いつまでに完了する予定かを明確にしていきます。
マスタースケジュールを立てる時は、まずチームごとに策定し、その後全チームで前後関係に不備がないかを確認しながら整合性を合わせていきましょう。

マスタースケジュールの作成が完了したら、続けてWBSも作成していきます。
WBSは各工程を成果物の単位までブレイクダウンしたもので、誰が何をいつまでにどれくらいの工数で対応するかを明確にしていきます。
各チームはこのWBSを確認しながら進捗管理を行い、成果物を作成していくことになるため、できるだけ無駄のない正確なWBSを作ることが求められます。

業務範囲を定義する

システム導入プロジェクトは、実際に行われている業務や現在使われているシステムが視点となるため、現状の業務やシステムのどこまでがプロジェクトの範囲となるかを明確にする必要があります。
そのため、要件定義フェーズの計画書には業務上のスコープとシステム上のスコープを明記することが重要になります。

業務スコープは販売領域や調達領域、会計領域といったように、いま自分たちが行っている業務の全体を明示して、どこまでの業務領域を範囲とするかを定義します。
また、会計領域の中には債権債務や固定資産、外貨取引などのサブ領域があります。
会計領域の中にはどのような業務が何が含まれるのかをサブ領域単位に区切って、スコープを定義するようにしましょう。

システムスコープは各業務でどのようなシステムが使われているかを明示して、どこまでを範囲とするかを定義します。
会計領域の中に決済システムや債権債務管理システムがあったり、生産領域に生産計画システムや計量システムがあったりします。
今自分たちが実際の業務で使用しているすべてのシステムを明示したうえで、今回のプロジェクトはどこまでの範囲を対象とするかを定義することで、要件定義におけるディスカッションのやり易さが格段に向上します。

要件定義で作成する成果物を定義する

要件定義で作成される成果物として「要件定義書」がありますが、この要件定義書に記載されるべき主な内容は以下の通りです。

プロジェクトの概要と目的
システム導入後の業務フロー
データフロー図
機能・非機能要件一覧
画面・帳票一覧
追加開発一覧
システム構成図

上記はあくまで一例に過ぎないため、本当に必要な成果物はプロジェクトやシステムの特性によって変わってきます。
また、計画策定の時点で成果物を定めたとしても、進めていくうえで新たに必要な成果物が出てきたり、逆に不要な成果物が出てくる可能性もあります。
そのため、成果物を最初に定義しきることは難しいところがありますが、要件定義に参画するプロジェクトメンバーに何を作ればいいのかをイメージさせるためにも、計画書にはできる限り想定成果物を明示するようにしましょう。

成果物の管理ルールを定義する

要件定義では「要件定義書」というものを作りますが、作成方法に明確な決まりがあるわけではありません。
チームをコントロールするプロジェクトマネージャーやPMOのやり方によって成果物の管理方法は様々ですが、重要なのは最初に成果物の管理ルールを明確にし、メンバー全員が納得感をもってルールに従うことです。
なぜ、成果物の管理ルールを明確にすることが重要かというと、システム導入プロジェクトでは様々な役割をもったメンバーが様々な成果物を作成するためです。
作成者が個々に好き勝手成果物を作ると、レビューや見返すときなどに非常にやり辛くなります。
また、作成したものはシステム導入のノウハウとして自社に生涯残り続けます。
そういう時に、ルール無いの管理体制で作られた成果物は、作った本人もどこに何が書かれているか分からなくなります。
成果物の管理ルールは、成果物を作成し始めてしまうとルール化することが難しくなるため、必ず計画策定の段階で検討するようにしましょう。

成果物の管理ルールとして定める主要な内容は以下の通りです。
※自社標準がある場合は、その内容を確認しプロジェクトに適用できるようにテーラリングを行ってルールを定めるようにしましょう。