勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

実践要件定義入門

Requirement Developments

最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。

目次

要件定義以前

要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。

要件定義の進め方

IPAユーザのための要件定義ガイドをベースにする

前編にも書いたが、わたしはIPAユーザのための要件定義ガイド（第２版）をリファレンスにすることをお勧めしている。これでいいんだよ。

ユーザのための要件定義ガイド第2版

ユーザのための要件定義ガイド第2版

Amazon
便宜的にAmazonのリンクを置いておくが、以下のサイトでPDF版のダウンロードも出来る。

決め過ぎない

要件定義でもっとも難しいのはこの「決め過ぎない」ということだ。要件定義が不十分であってもダメだが、やりすぎてもダメなのである。ただし、どこまでやれば良いかという基準があるわけでもない。要件定義のバイブルでもある「ソフトウェア要求　第3版」では以下のように書かれている。

要求分析の中で重要なのは、概要レベルの要求を分解して、それを明確化し具体化できるだけの詳細を明らかにすることである。「要求は、どこまで詳細であるべきか？」、これはよく聞かれる質問だが、唯一の正解はない。開発チームの知識と経験に基づいて、誤解されるリスクを最小化できる程度の詳細を提供する。要求の問題に関して継続的に話し合える機会が少ないほど、要求セットをより詳細に記録する必要がある。開発者が、要求を満たす方法をいくつか考えつき、そのすべてが受け入れ可能なら、具体度と詳細度はほぼ適切だと言える。以下の場合には、より詳細にしなければならない。

では、どの程度やれば、ちょうどよいのだろうか。だいたい、この程度が妥当と考えている。

  • 要件定義後の活動（一般的には設計など）の指針であって、指示にはなっていないこと
    • 前述の「ソフトウェア要求　第3版」の引用にあるように、開発者が要求実現方法を複数検討することが出来る程度の曖昧さが必要である
    • 具体的な仕様を決定しすぎてはいけない（なぜなら、システム開発を進めていく中で仕様は変化や進化していくことが多いからである。要件定義で具体的な仕様を記述しすぎてしまうと、後でより良い仕様が発見されても取り込まれなくなってしまう）
    • 要件定義の終了後、（要求の追加変更以外で）作成したドキュメント類の変更が出来る限り少なくなるように書かれた要件定義が、よい要件定義ともいえる（ほどほどに具体的で、ほどほどに抽象的）
  • 要件定義後の作業の規模がざっくり計画できる（見積もれる）程度には具体化されていること
    • 議論の余地がありそうだが、インターフェースの数（UI、レポート、API、その他）やバッチ処理等の概数、連携対象システム数などは明らかにしておきたい（ただし要件定義時点の試算であり確定としないほうがよい）
    • この表現はSIer臭が強いが「見積もれる程度には具体的に」「数えられるものが、数えられる程度に」

まあ、明確な基準は存在しないので最後は経験的に判断しなければならないだろう。やりすぎを防ぐためには「分析地獄」というアンチパターンを見ておくと良いかもしれない。

機能を定義するのではなく、機能要件を定義する

機能を定義するのは設計であり、要件定義では機能要件を定義するべきだ（ただし例外はある。後述する）。

  • いわゆるユースケース、またはユーザーストーリーという形式を取るべきだ
  • 例えば「ログイン画面」という機能について定義するのではなく「ログインする」という要求について定義しなければならない
    • どうして後者を取るべきなのかというと、機能（前者）はシステム／プロダクト中心の発想であるからダメなのだ。まだ存在しないシステムを中心に検討すると目的や利用者の視点が失われることがある
    • 機能要件（後者）であれば主語はユーザーとなる。ユーザーが何を成し遂げるべきか、それがすなわち要求である

なお例外はあって、ある種のシステム／プロダクトを分析する際にはこのアプローチはうまくいかない。またもや「ソフトウェア要求　第3版」から抜粋しておこう。

たとえば、バッチプロセス、計算集中型のシステム、業務分析、データウェアハウスなどのアプリケーションでは、ほんの少しのユースケースしか出ないだろう。この種のアプリケーションの複雑性は、実施する計算や、発見して使用するデータや、作成する報告書にあり、ユーザーとシステムの相互作用にあるのではない。　ユースケースやユーザーストーリーは、多くの組込みシステムやその他のリアルタイムシステムの仕様作成にも向いていない。

言い換えると、システムと人間がたくさんの相互作用を行うシステムだったら、ユースケース等を使って要件定義をしたほうが良いということになる。

関係者をすべて洗い出す

要件定義は利害関係者の要件を洗出して整理し定義するプロセスである（あたりまえだ）。ということは、利害関係者すべての要求を確認しなければならない。よって、関係者をすべて洗い出す必要がある。

  • 前項の「機能を定義するのではなく、機能要件を定義する」理由とも関係する。機能（例えば「ログイン画面」）のことばかり検討していると、利用者のことが軽視されることがある
    • ひとくくりにシステムの利用者を「ユーザー」とするのが一番まずい。「担当者」や「承認者」とか、「企画部門」とか「〇〇部署」などを分類しなければいけない。この分析を怠ると、要件の聞き忘れがおこる（そうすると、後でだいたいひどい目にあう）
  • 利害関係者を洗い出したら、「利害関係者の代弁者」も決定するとよい。そして、利害関係者または代弁者がすべて要件定義セッションに参加しないと、要件は漏れる。例えば経理部門が関係やであれば直接または「経理部門の代弁者」に話を聞かなければならないからだ

利用者マニュアルの目次が作れるようになっているか

良質な要件定義のアウトプットは、そのままマニュアルの目次に変換できる。そうなっていない要件定義はよろしくない。

《ダメな例》

  • ログイン機能
  • 一覧画面
  • 入力画面
  • 確認画面

《良い例》

  • ログインする
  • 登録内容の一覧を確認する
  • データを入力する
  • 入力したデータを確認する

おわかりいただけたであろうか……
なおマニュアルの目次が作れるということは、テストシナリオも作れるということでもある。

ビジネス要件定義

前提事項、制約事項とリスクを定義する

要件定義は（新しいことを考えるという意味で）本質的には愉しく、そして発見された要求について深掘り、詳細化する方向に向かいやすい。結果として前提事項や制約事項、リスクなどの洗出しが軽視されやすい。ここには大きな落とし穴がある。

  • ここでいう制約事項は法令、商慣習、予算や特定技術採用、技術人材、再利用素材などである。他にもあるかもしれない
  • 確定できない制約事項は仮決めを行うこととなり、それが前提事項となる
  • リスクは発生するかもしれない将来の予測である（なお、リスクに対しては対策も考えておくべきである）

前提事項、制約事項とリスクは全ての利害関係者に確認する必要がある。忘れないようにしよう

優先順位の決定を忘れずに

省略されがちであるが、要求に優先順位を付けることを漏らさないべきである。

要件定義において抽出されたすべての要求（手段）を実現することができるプロジェクトは稀である。膨らむ要求を限られた工期やコストの範囲に抑え込むためにも、要求には優先順位をつけて、効果の薄い要求や贅沢な要求は捨てる選択をしなければならない。また、昨今では、リーンスタート的な発想で、最低限必要な機能でまずリリースして使用してもらい、実績を評価して徐々に成長させていく（もしくは止める）手法のシステム開発を選択する場合もある。いずれにしても、どの要求は先送りできるのかを判断できるようにしておく必要がある。

要求に対する優先順位付けについては上記の通りであるが、優先順位を付けることは言葉通り以上の意味を持つということも理解しておくと良い。

要求に優先順位を付けると、目標が競合していることがわかったり、衝突を解決したり、段階的またはインクリメンタルな引き渡しを計画したり、スコープクリープをコントロールしたり、必要なトレードオフを決定したりするときに役立つ。

「全部が最優先」「全てマスト」と言いたい気持ちをぐっとこらえて、要求の順位付けについて考えよう。

システム化要件定義

不安定な要件を構造で支える

本質的に、ITシステムやソフトウェアの要件は不安定なものである（実体のある建築物やプロダクトに比べて、物理的制約を受けないため）。だから様々な工夫をしてこの不安定な要件を支える必要がある。様々な手法が存在するが、基本的には要件を構造的に強化しようとしているものだ。

  • ダイアグラムの利用
  • 複数の視点での要件の整理
    • （IPAユーザのための要件定義ガイドに即せば） プロセスの観点と、データの観点、その相互関係を整理することがビジネス要件の安定性を高めている。システム要件については機能要件とデータ要件をCRUD表で整理することで安定性を高めている
  • 機能要件と非機能要件の関係性も同じで、非機能要件によって機能要件の不安定さをカバーするのである

個人的に好きな組み合わせはユースケース記述（棒人間図ではなく文章で表現するもの）、フロー図、概念データモデル、ビジネスルールの4点の組み合わせだ。ただこれは手慣れたツールというだけで深い意味はない

  • 複数の機能要件（ユースケース）に登場する要件はビジネスルールにまとめる。これにより、機能要件間の一貫性を保ちやすくする
  • 機能要件間の連続性をフロー図で確保する。フロー図をなぞる事で全体の正しさが確認できるようになる
  • 機能要件とデータモデルの整合性を見ることによって、データ観点の見落としや矛盾を見つける

例えばこんなイメージ

とりあえず言いたいことを書いてみたが、だいぶ長くなってしまった。言いたい事は一通り書いたつもりだが、また何か思いついたら書こうと思う。
フィードバックやツッコミはX（旧Twitter）かはてなブックマークあたりでどうぞ。

おまけ：本記事の元ネタ

本記事の作成にあたっては、10年程前まで幹事をやっていた上流工程勉強会コミュニティで諸先輩からいただいた様々なコメント、あとは趣味的に読み続けている要件定義周辺の書籍を参考にしている。思い出せるものを列挙しておくが、古い本も多いので注意していただきたい。