システムやサービス開発の土台となる要件定義。単にユーザーや関係者の要望をリストアップするだけでは、要件定義はうまくいきません。彼らが本当に求めているものを見極めて、間違いのない優先順位を付けていくことが最も重要です。では、どうしたら彼らが納得する要件定義を実現できるのでしょうか。要件定義の成功に不可欠な「4つのポイント」を詳しく解説します。
管理職の仕事とは、関係者全員の要求を洗い出すこと
第4話で概観した通り、ソフトウェア開発の最初のフェーズが要件定義です。
要件定義は、開発プロジェクト全体においてきわめて重要な位置を占めます。プロジェクトのビジョンや目的を明らかにし（そのソフトウェアを作ることによって自分たちは何を達成したいか、ユーザーにどんな価値を提供したいか）、機能・要件を具体的に定める（どの機能が必要か、どういうユーザー体験を提供したいか）ことで、プロジェクトの方向性を決定づけるからです。
プロジェクトの進行計画やスケジュール、必要なリソース、コストはすべて、決定された要件定義をもとに見積もられます。「犬小屋を建てる」という要件が決まってはじめて、「2、3日で建てられます。材料は木。大工は1人で十分で、費用は3万円です」という見通しがつくのと同じです。
要件定義で重要なのは、目指すゴールについて関係者全員の認識をすり合わせることです。「犬小屋を建てる」とみんなで決めたはずなのに、「一軒家を建てる」と思い込んでいる人や、「私は高層ビルを建てたい」と要求を押し通そうとする人がいると、あらゆる場面で認識の齟齬や衝突が起こり、プロジェクトの歯車が狂います。
こうした事態を避けるため、プロジェクトリーダーである管理職が取り組むべきひとつ目のポイントは、各ステークホルダーとの調整役を担い、関係者全員の要求を洗い出すことです。
私がオススメしている方法は以下の通りです。まず、プロジェクトの立ち上げ段階で企画書を作成するときに、ステークホルダー全体を整理したシートを作成します。「○○部門と△△部門と□□部門が今回改修対象のシステムを利用している。Aさんは○○部門のプロジェクト担当者だが、○○部門の意思決定者はB部長。予算決定権限があるのは経理部門で……」というように、各ステークホルダーをリストアップし、各関係者の役割や責任範囲を整理します。
次に、主要ステークホルダーが参加する、プロジェクト専用の会議体を設定します。ステークホルダー同士でコミュニケーションができるようにするのが目的です。最初のミーティングでプロジェクトの全体像と各ステークホルダーの役割や責任範囲を明確化しましょう。その後、各ステークホルダーが持つ要求を引き出して文書化し、全ステークホルダーの要求をリスト化します。
ステークホルダーと密にコミュニケーションをとれば、プロジェクトに対するオーナーシップも強化できます。中華料理店でチャーハンを注文するような気軽さで「あとはよろしく」と要件定義を丸投げした人が、開発の最終段階になって「思っていたのと違う」と不満を言ってくることは珍しくありません。自分たちが要件を決定する立場だという当事者意識を関係者全員に持ってもらうことで、「チャーハンを頼んだのにラーメンが出てきた」というクレームを回避することができます。
