プロダクト開発に関わっている皆さん、要求工学、ご存じですか？
プロダクト（製品・サービス）を開発すること自体には免許が不要なことから、多くの方は「ぬるっと」プロダクト開発（以下、単に開発とします）に参加するようになっていると思います。しかしながら、開発現場では様々な専門用語が用いられ、戸惑っている方も多いのではないでしょうか。
今回は、「実務における要求工学の実践」と題して、広範にわたる要求工学の領域のうち、言葉の定義や入門事項、精神論（？）に関して軽く触れてみたいと思います。
良くも悪くも素人解説なので、体系的に要求工学に触れてみたい方は、名古屋大学教授でNTTデータ・システム科学研究所長・同社フェローでもある山本先生の連載が非常にわかりやすく参考になるのでオススメします（この記事はリンク先とは一切関係は無いので予めご承知おきください）。
https://www.bcm.co.jp/site/youkyu/index.html
着目するテーマ
この記事では、開発の最初期である要求抽出・定義から設計までのプロセスに着目します。
要求工学における要求定義には様々な手法・モデルがありますが、実際実務でデファクトスタンダードとなっている手法は確立していないので、概ねどの手法においても共通した部分について解説タイと思います。
要求工学のDFと要求抽出
要求工学について始める前に、実務における要求工学がどのような状態か軽く解説します。これまで、開発のプロセスは、ユーザ（あるいは発注者であったり開発者本人であったりする）が持っている抽象化された要求を、コードやハードウェアとして具現化するプロセスとされてきました。このプロセスを成功させるために、エンジニア（あるいはテクニシャン）達は様々な手法をそれぞれのレイヤで考えてきました。より包括的なチーミング・プロジェクト開発モデルとして、ウォーターフォールモデルやアジャイル開発などはどなたも知るところだと思います。
一方で要求定義に関してのモデルをご存じの方はいらっしゃるでしょうか？要求工学を専門に研究している方でもなければ出てこない事が多いのではないでしょうか。かくいう私も要求工学の専門家ではないので一つもしませんし、ご存じの方に是非お教え頂きたいところです。
ただし、要求工学における顕在化プロセスについては一定の用語とフローが統一的に使われている事が多いです。例えば、「要求抽出」「合意形成」「要求定義」「要求仕様」「要求確認（レビュ）」「要件定義」「要件仕様」「設計」がそれにあたります。（抽象→顕在の順に単語を並べてあります）
しかしながら、「要求定義に必要な要求抽出に関して、手法を知っていますか？」と質問を変えると答えることが出来る方は多いのではないでしょうか。代表的な手法に以下があります。
- ブレインストーミングによる方法
- 資料収集及び現場観察による方法
- 会議による方法（Inquiry Cycle モデル）
- インタビューおよびアンケート法（質疑法）
- 目標分析法
- ユースケース・シナリオ・ユーザーストーリー法
- KJ法
- 手続き法（業務フロー分析、フローチャート法、産能大フローチャート法）
ぱっと答えられない方も一覧をみると、「ああ、やっている」と実感できるはずです。つまり、要求抽出にはある程度手法が確立しているとも言えます。
要求抽出の手法が明らかになったところで、ではDFはそこに存在しているでしょうか？
答えは否です。要求抽出は開発のより（顕在化手法における）上位行程においてそれぞれの事情に応じて工夫して手法を組み合わせたりカスタマイズする、単純に言えばオーダーメイドな手法が用いられているのが現状です。
要求工学の花形「要求定義」
さて、次に触れるのは要求定義です。要求定義は顕在化プロセスのうち、要求抽出の次に出てくるプロセスで、抽出された要求を言語化する過程です。前項で紹介した各種の手法で要求抽出すると手法に応じた結果（ホワイトボードの記録であったり議事録であったり）が得られます。しかしながらこれらは要求定義の過程を経ないとたんなる情報の整理であり、この状態では「要求」がなんであるか判然としません。そこで、要求定義では要求抽出した情報を一定のコンテクストに落とし込みます。
また、要求定義ではコンテクストへの落とし込みだけでなく、事項で説明する合意形成が含まれる事もあります。
頭を悩ませる「合意形成」
往々にして開発においては、理想と現実のジレンマに悩まされます。全ての要求が要件として定めることが出来れば良いのですが、コストやスケジュールなどのリソースの問題、テクニカルスキルの不足などの理由によりある程度要求抽出した要求を削った状態で開発の発注者と受注者間（あるいはディレクタ（や上流工程担当者）とディベロッパ（下流工程担当者）で合意形成が行われます。
しかし、この合意形成がスムーズにいく環境があるチームは幸いです。通常は両者間でお互いのタスクに関する理解および把握や、スキル水準の隔たりがあり合意形成は難航しがちです。
チームメンバにはそれぞれの役割が割付られていますが、これはスキル水準にばらつきがあるもしくは、メンバに専門性を持たせるために行われていることが多いです。フリーランスで１人で開発しているというの場合はソフトウェア開発の一部に限られるのではないでしょうか（建設業においていわゆる「一人親方」はあっても実際一人で作業はしない場合が多い）。
そんなチーム開発において合意形成に必要な一番のスキルはプレゼンテーションスキルです。いかに自分の持っている知識や思考を合意形成する相手に伝えていくかが重要で、口頭だけで済まされる場合もあれば、このために資料を作成することもあるでしょう。
（ちなみに筆者はこのプレゼンテーションスキルを備えるのが一番難しいと考えていて、未だに努力している立場です）
精神論になりますが、相手を納得させる事に主軸を置くのではなく、相手もこちらに妥協を求めてくること通常なので、お互いの妥協が釣り合う「着地点」を探すことに注力すると建設的になりやすいと考えています。
要件と仕様及び設計
さて、残りのプロセスを一気に整理していきます。ここまでは要求抽出を行い、要求を定義し、関係者が納得できる着地点を見つける合意形成を行ってきました。
合意形成が完了していると、プロダクトが開発終了時に満たすべき要件が定義できます。要件定義はより自然な文章で構成されることが一般で、「ユーザはXXXを用いてYYYすることができる」と条件とその結果だけの文章であることが多いように思います。ここで大事なのは必要以上の仕様をここに含めないということです。
例えば、「飲食客がゆったりと過ごせる空間」という要件は適切ですが、「照明にはAAA社のBB-0123を利用し、壁面クロスにはCCC社のDD-0123を使用したEEE社地区ランキングで飲食客がゆったりと過ごせる1位のカフェ」とするのは不適切です。要件はあくまでUX、ユーザストーリーベースで考え、それが完成してから仕様は別途検討すると出戻りが少なく、プロダクトが満たすべきゴールが誰にも明確になります（より技術専門性の少ないレイヤーでは要件に着目刷れば良いし、エンジニアは仕様に着目すればよくなる）。
仕様検討では、実際に利用するマテリアル、エレメント、テクニックを選定していきます。また、最終的にプロダクトが満たすべき要件仕様を作成します。要件仕様は端的に言えばスペックシートで、プロダクトにおいては取扱説明書や販促資料に添付されていることが普通です。ソフトウェア開発の一分野など特定の分野においては、スペックシートを作成しない場合もありますが、そういった場合でも類似の社内資料を用意している事が通常です。
要件仕様の作成のことを端的に要件定義という事もあります。要件定義は要求抽出から要件仕様の作成までの全工程を指すこともあり、どの意味を指しているかは開発チーム内で統一しておくとスムーズです。
要件定義が完了すると、設計を行う事が出来ます。製品の満たすべき機能や利用する各種要素が明確になっているからです。設計はそれぞれ製品によって工程が異なりますが、設計において無視してはならない一番重要な部分は「組み立て説明書」であるということです。現場作業を行う際に設計書を見ても作業内容が不明である（あるいは明瞭でない）という状態であるならば、それは設計書として詳細性に欠ける状態です。基本的に設計書は設計者がチームから離れたとしても、当初予定していた製品が完全に具現化されるレベルの詳細性と完全性を兼ねるものです。
開発見積もりについて
何か開発を行うときには大抵開発見積もりを行います。これは金額の見積もりだけでなく、併せて工数の見積もり、必要材料の見積もりなども含みます。
では、開発見積もりは要件定義や設計をどこまで手をつけて出すべきでしょうか？
これは非常に難しい問題です。設計まで完了したプロダクトの開発の見積もりは比較的容易です。逆に要件抽出も終わっていない開発の見積もりは非常に困難です（曖昧性がある）。しかしながら要件定義には通常工数がかかり、開発サイドとしては実際にプロダクトになるかどうか分からないものに工数をかけるのはリスクが高いのは火を見るより明らかです。一方で、曖昧な状態で見積もりをしてしまえば、顧客（あるいは発注者）へ後で見積もり変更を打診することになる可能性を秘めています。見積もり変更のリスクと見積もり工数をウエストしてしまうリスクを天秤にかけて判断をする必要があります。
私見ですが、通常は設計まで見積もり段階で行う必要は無く、要件定義まで済んでいれば概ね一般に必要とされる信頼性を持った見積もりができあがるような気がしています。逆に要件定義が済んでいない見積もりは往々にして後から工数が増えたり、工期が延びたり、追加コストが発生することが周囲では散見されます。見積もりの信頼性は開発の信頼性、延いてはチームや会社・組織の信頼性へ通じることが大きいですので、「たかが見積もり、されど見積もり」と捉えて取り組む必要がありそうです。
とはいえ、未知の開発の見積もりは膨大な工数がかかることが通常で、こういった場合には見積もり自体にもコストを発生させ、タスクとして受注してしまうことも良いと思います。結果、顧客が満足する見積もりでなくても、曖昧な見積もりで進めるよりは双方にとって良い着地点になるはずです。
逆に、既知でナレッジのスタックしてある見積もりは、見積もりをシステマチックにしていくことで信頼性を向上させ、工数をも削ることが可能です。
最後に
実務においては、抽象的な要求を具現化する準備をする要件定義、不確かな未来を予測する見積もり、いずれも要求工学で一定の研究成果が出ている分野です。（私見ですが）実際に開発するよりも不定で難しい、要求工学のタスク領域はタスクそのものの抽象性・曖昧性を減らし、タスクを実施する際の心理的安全性を高め、結果としての信頼性を勝ち取っていくべきではないでしょうか。
その為にも、要求工学を学ぶことは価値のあることと思います。