要件定義で意識すること — ファイルサーバー移行を例にした実践ガイド

概要

Classmethodコンサルタントによる要件定義の実務ノウハウ集。IPAガイドでは言語化されていない「感覚的な判断」を、ファイルサーバー移行プロジェクトを例に具体的な要件例まで落とし込んだ記事。

一次ソース

• 要件定義をするときに意識していることをまとめてみた（Classmethod DevelopersIO）

主なポイント

基本姿勢

• 目的・ゴールを最初に設定: スコープの無限拡大（スコープクリープ）を防ぐ起点になる
• 要望 ≠ 要件: ステークホルダーの要望をそのまま要件にしない。本当に必要か丁寧に検討する
• 「やらないこと」も明記: やることだけでなく除外スコープを書くことで、後から「なぜやってくれなかったのか」を防ぐ

要件の質を高める工夫

• Howでなく目的を抽象化: 「Xツールを使いたい」ではなく「ファイル共有を安全に行いたい」と目的で書く → 実装手段の柔軟性が生まれる
• 現物を触って認識を合わせる: 言葉だけの確認は認識齟齬の温床。プロトタイプ・現行システムを共に触る
• 要求として出ていない要素も引き出す: 担当者が気づいていない暗黙の前提を掘り起こす

QCDトレードオフ

• 品質・コスト・スケジュールは常に連動: 一方を上げれば他方に影響する。トレードオフを可視化してステークホルダーに選ばせる
• 要件の量と深さの調整: 「プロジェクト規模・顧客特性・重要度を加味して認識齟齬リスクが最小限となる程度」に調整する — 過大も過小も失敗につながる

ファイルサーバー移行で必要な要件の領域

実務で見るポイント

1. 「やらないこと」の一覧は受け入れテストのチェックリスト: 後工程の品質確認に流用できる
2. 要件の粒度チェック: 「同じ粒度で書かれているか」を一覧で並べて確認すると齟齬が見つかりやすい
3. ゴール設定の副作用: プロジェクト目的を明確にすることで、途中の優先度判断もぶれなくなる