大きな手戻りを避けつつ、60点の要件定義をすばやく合意したい

私はシステム開発の仕事をはじめてから23年目だが、直近10年はクライアントワークとしてプログラミングや実装は行っていない。顧客から「現状の問題・課題は何か」「どんなシステムが必要か」を聞き出し、情報を整理し、エンジニアと調整している。いわゆる要件定義が主な仕事だ。

要件定義を初めて担当した際は、プロジェクトで用意されたテンプレートを必死で埋めたが、多くの抜け漏れがあり、質は低かった。その後、さまざまな場で学び、今では当時うまく書けなかった理由がわかる（ケースもある）。

この記事は、要件定義をうまく進められなかった当時の自分に向けて書く。

補足1
要件定義は発注側の責務かもしれないが、ここでは実体験ベースでシステム開発の上流工程としてエンジニアが実施することを想定する。

補足2
ここで言うシステムとは、ソフトウェアやアプリケーションを組み合わせた「情報システム」を指す。

はじめに

まずは、今の私が重要だと思う以下の3つを、10年前の自分に伝えたい。

• 完璧を目指さない
• すばやく・小さく合意を繰り返す
• 具体例で話す

1つ目は「完璧な要件定義は存在しない」と知ること。情報システムのような無形の商品をオーダーメイドで発注する場合、顧客が100点の要望を出せるわけがない。100点を目指すと、枝葉にこだわりがちになり、話が本質から外れる。そこで、60点を目標に100%の力で進める。

2つ目は、数か月かけて作成した分厚い書類で合意しようとしないこと。膨大な文書の正しさや整合性を顧客に保証させるのは合理的ではない。最低週1回の打ち合わせで、少しずつ理解を深め、対象を広げ、合意を積み重ねることが大切だ。

3つ目は、要件の分析で作成した図やモデルなどの抽象的な情報を顧客との合意に使わない。分析する際に抽象化し、顧客と話す際は必ず具体化する。抽象的な会話に慣れていない顧客は多いので、具体化しないと認識がずれる。

要件定義とは

定義

要件定義の一般的な解釈として「共通フレーム2013」から引用する。

要件定義は，これから実現する組織や業務を定義し，その業務に使用されるシステムの機能・動作・インタフェース・性能・運用条件や，現行の業務・システムからの移行，必要な環境などを定義することで開発対象のシステムや制約条件を具体的に明示していく作業である。

引用元：共通フレーム2013「第４部プロセス解説及び適用とテーラリング（修正）／1. 2テクニカルプロセス（2.）」

これが間違っているとは思わないが、もう少し俯瞰したい。そこで、ITコーディネータのフレームワークである「IT経営推進プロセスガイドライン Ver.3.1（PGL）」をベースに以下のように考えた。

PGLでは、経営戦略を実現するために「業務改革」と「IT戦略」を両輪とする。要件定義の目的は、この2つを「つなぐ」ことであり、そのためには相互にフィードバックを必要とする。経営戦略や業務改革から一方的に「やりたいこと」を伝え、IT戦略を進めるだけでは不足している。

なお、一般的に要件定義には非機能要件や移行要件も含むが、ここではスコープ外とする。ここでの要件定義の議論に、アーキテクチャや非機能要件は入れない。別で考える。ただし、要件定義の議論には早い段階からアーキテクトはもちろん、デザイナーやテスターも合流して欲しい。

60点の要件定義

要件を抜け漏れなく網羅することは不可能に近いため、最初から要件定義の完成度の目標を60点とする。60点の要件定義で動作するシステムを作り、できるだけ早い段階で顧客にデモを見せ、追加の要望を出してもらうことが重要だ。

ちなみに最初から100点を目指すと、顧客は「必要かもしれない」要件を大量に出してくる（顧客としては、そうせざるを得ない）。そうなると、システム稼働後に使われない謎機能が大量に出来上がる。

大きな手戻り

60点の要件定義を目指すのは枝葉を後回しにしたいからであるが、大きな手戻りは避けたい。大きな手戻りを避けるためには、以下の2つが重要である。

• ステークホルダーの把握
• 用語の概念整理

1つ目は、ステークホルダーを把握しておくこと。要件出しはステークホルダーが起点なので、ステークホルダーのもれは、致命的な要件もれに直結する。水平（部門や担当業務）と垂直（現場担当者から決裁者）して洗い出す。

2つ目は、用語の概念を整理しておくこと。同じ言葉でも、業種や業界が違えば定義が異なることも多い。特に用語間の関係性が重要である。用語の思い込みはデータ構成の誤りにつながり、システムの画面構成にも影響する。いずれの構成も変更する手間は大きい。

要件定義のプロセス

要件定義は、As-Is（現状）分析、To-Be（目指すべき状態）分析、それらのまとめの順に進める。まとめでは、As-IsとTo-Beのギャップ分析や他システムとの関連図の作成、移行要件の整理、顧客と合意するための資料準備などを行う。

以降、特に重要なポイントにしぼって、いくつか簡単に触れる。

インプットすべき『情報』

要件定義がうまくいかない場合、インプットが不足していることが多い。新規案件に着手する際には、顧客からのヒアリング前に、最低限以下の情報をインプットしておくことが求められる。

• 業界の情報
  • 業界に関する一般知識
  • 職種に関する一般知識
  • 関係しそうな法令・法規
• 顧客企業内の情報
  • Webサイト
  • 組織図
  • 業務プロセス
  • 既存システムに関する情報（システム構成図など）

書籍を2-3冊読めば最低限の業界知識は把握できる。あとは顧客のWebサイトや組織図などで顧客企業内の現状を知る。特に組織図が大事で、必ず見せてもらうようリクエストする。

『概念マップ』で用語の理解を合わせる

概念マップは、用語（概念）の関係性をクラス図の形で表したもので、プロジェクトで使う言葉を整理するために作る。特に用語間の多重度が重要で、手戻りを避けたいデータ構成や画面構成に大きく影響する。

『RDRA』で軽量に分析する

RDRA（読み：ラドラ）は、モデルベースのビジネスとシステムの可視化手法で、要件定義時の分析手段として愛用している。この手法では大量のドキュメントを作成することなく、UMLベースのモデルを使って軽量に分析することを目指している。

『画面スケッチ』で合意を重ねる

モデルベースのRDRAは、便利だが表現が抽象的なので、読み取る側にもリテラシーが求められる。多くの顧客にとってモデルは読み取りづらいものなので、私は合意に画面スケッチを使う。スケッチには、具体的なUIに必要だと考えている項目とボタンを並べ、必要なら文章で補足する。画面に表示するデータを一意に特定するキー項目は、必ず確認したい。スケッチは修正を前提としたいのでシンプルなものとし、デザイン（意匠）には凝らない。

成果物は顧客と合意してから作成したい

10年前の私のように、プロジェクトで用意されたテンプレートを埋めようとすると失敗する。テンプレートを埋めることが目的となるからだ。

重要なのは、決められた成果物を作成することではなく、大きな手戻りになりそうな顧客との認識齟齬を見つけることだ。そのためには、分析や検討が60%程度終わった要件定義で細かく何度もクライアントと合意する。60％という数字に特に意味はない。40％でも50％でもいい。とにかく、完成したドキュメントのレビューを受けるという姿勢でなく、対話をくり返し、認識の相違を洗い出し、合意を積み重ねていくべきだ。

納品するために企業やプロジェクトで決まった成果物のフォーマットが必要なら、最後にまとめればいい。

まとめ（by ChatGPT）

要件定義のプロセスは、プロジェクトの成功にとって不可欠だが、その完璧を目指すことは現実的ではない。本記事で挙げた経験則から学べる重要なポイントは、繰り返しによる早期の合意形成と、顧客との認識の齟齬を可能な限り早期に解消することに尽きる。具体的なステップとして、抽象的なモデルよりも具体的な画面スケッチを活用し、要件の「60点」を目標に設定することで、不必要な機能の過剰な追加を防ぎながらも、根本的なニーズを満たすシステムを構築できる。

また、大規模な手戻りを避けるためには、ステークホルダーの適切な把握と用語の明確化が重要だ。要件定義の早い段階で関連人物や用語の整理を行い、定期的なレビューと調整を行うことで、プロジェクトの滞りない進行を確保することができる。

最終的に、成果物の作成はプロジェクトの終盤に集中するべきであり、それまでのプロセスは顧客との密接なコミュニケーションと合意形成に重点を置くべきだ。このアプローチにより、顧客との信頼関係を築きつつ、効果的にプロジェクトを推進することが可能となる。これが、現代のシステム開発において要件定義が果たすべき役割であり、その達成に向けての最良の戦略である。