要件定義が先か、要求分析が先か？

筆者は就職して約20年、一貫してソフトウェア開発の業務に関わってきた。研究や試作、性能改善などの為のものではなく、要求仕様に従って開発して最後ば残バグを0件にする、言わば品質の作り込みと品質確保を目的とするものである。
そのようなソフトウェア開発では、開発プロセスの定義が必須である。筆者も、ある時は実開発者として開発プロセスに従って作業し、ある時は外注管理担当として開発プロセスに則っているかを点検し、ある時はリーダーとしてプロセス改善に取り組み、ある時は間接業務担当として開発プロセスが崩壊してデスマーチとなる様子を眺めてきた。設計やソースコードよりも開発プロセスを最も意識して会社人生を過ごしてきたと言って過言ではない。

複数の開発プロセスを見てきて、用語の違いや揺れはかなりあったが、大体、ウォーターフォールモデル（及びスパイラルモデルの１サイクル）の開発フェーズは次のように分けられると理解してきた。

要件定義
ユーザー／顧客の言葉で、ソフトウェアに求められる要件を記述する
要求分析
ソフトウェアの仕様が一意に解釈される、完成したソフトウェアが要求を満たすかどうかを客観的に評価できる、要求仕様書を作成する
システム設計／方式設計
全体のモジュール分割、モジュールのI/F仕様（静的構造）やタスク分割（動的構造）、メモリ割り当てなど、ソフトウェア全体のトップレベルの基本設計を、プログラミング言語に依存しないレベルで行う
プログラム設計／モジュール設計／詳細設計
プログラミング言語に依存するレベルの設計やモジュールの内部設計を行う
実装
プログラムのコーディングを行う
単体テスト／モジュールテスト
モジュール内部の実装を踏まえた、網羅的なテストを行う
プログラム設計／モジュール設計／詳細設計に対応する
結合テスト
結合相手のモジュールがI/F仕様を満たしているかなどをテストする
システム設計／方式設計に対応する
システムテスト
ソフトウェア全体が要求仕様を満たしているかどうかをテストする

このように理解してきて、これまで実務上不都合はほとんど無かった。

たまに「要求分析」が「要件定義」より先になっている開発プロセスを見かけたが、たまたま、一般的な何かに基づいて作成されたように見えない、特定の会社が独自に考えたように見えるものばかりだったので、それを作った人の理解不足、きっとユーザーの「要求」を「分析」してシステムの「要件」を「定義」するという発想で字面だけで決めたものだろうと思っていた。

しかし、特にここ3年くらい、様々な企業が作成する資料で、「要求分析」が「要件定義」より先になっている開発プロセスをいくつも目にするようになって、気になるようになった。

そこで、ちょっとソフトウェア開発プロセスの「要件定義」と「要求分析」の使われ方について調べてみた。


［事例１］https://www.ipa.go.jp/files/000053941.pdf
IPA（情報処理推進機構）のサイトにある、この資料でも、「要求分析」→「要件定義」の順になっている。さらに「要求分析」→「要求定義」→「要件分析」→「要件定義」とも書かれていて、この一連の活動の成果物が要件定義書となっている。
要求分析は「顧客の要求」を分析するフェーズで、要件定義がシステムの要件を定義するフェーズという意図らしい。

［事例２］ESPR Ver.2.0
IPA/SECが作成した、ESPR（組込みソフトウェア向け開発プロセスガイド） Ver.2.0では「システム要求定義」「ソフトウェア要求定義」という言葉を使っている。開始条件として、それぞれ「製品企画として、エンドユーザーニーズが明確になっている」「製品仕様として、取説レベルの内容は決まっている前提になっている」とあり、出力はそれぞれシステム要求仕様書／ソフトウェア要求仕様書である。

［事例３］https://www.ogis-ri.co.jp/otc/hiroba/technical/RequirementsAnalysis/pdf/RequirementsAnalysis.pdf
オージス総研のサイトにある、この2007年くらいの記事では、「要求定義」の成果物が要求仕様書と書かれており、「要求定義」が要求分析を含むものと解釈できる。

［事例４］http://isw3.naist.jp/IS/TechReport/report/2011002.pdf
このレポートには「要求分析」の後に「要件定義」のように見える図があるが、本文は「要件定義」が「要件分析」／「要求分析」を含む前提で書かれている。

［事例５］JIS X 0160
ISO/IEC 15288の「利害関係者要件定義」→「要件分析」が、JIS X 0160では「利害関係者要求事項定義」→「システム要求事項分析」に対応すると書かれている。
「システム要求事項分析」の中に「要求事項の仕様化」があり、要求仕様書という言葉は使われていないが、次のフェーズが方式設計なので、このフェーズで要求仕様書が作成されるものと思われる。

［事例６］PMBOK(5th Edition)
"Collect Requirements"の次が"Define Scope"となっている。"Define Scope"において、specificationの類の単語は出て来ない。

［事例７］SWEBOK V3.0
"Requirements Elicitation"（要求抽出）
"Requirements Analysis"（要求分析）
"Requirements Specification"（要求仕様記述）
の順になっている。

［事例８］SDEM
よく知られた富士通のソフトウェア開発プロセスであるSDEMでは、「要件定義」という言葉が使われ、このフェーズが要求分析や要求仕様書作成を含むようである。


まず、「要求定義」や「要件分析」といった用語の揺れがあるが、筆者の理解では、開発プロセスの文脈において「要件」と「要求」の違いはほとんど無い。日本語的には、「要件」はシステムが満たすべきもので「要求」はユーザーが求めるものという印象があるが、元々はどちらも英語のrequirementを訳したものであり、「要件」＝「要求仕様」だと思っている。「要件」は"requisite"だ、と書かれたのを何かで読んだことがあるが、筆者は英語の文献で"requisite"を目にしたことがない。
通常、"requirement"の訳は「要求」なので、表記の統一を目指せば「要件定義」は「要求定義」になるだろうが、筆者としては「要件定義」の方が日本語として自然だと思うし、Googleで調べても圧倒的に多い。

［事例１］では「要求分析」→「要求定義」→「要件分析」→「要件定義」となっているが、しかもこの一連のフェーズの成果物が要求仕様書の前段階の要件定義書だと、果たしてこれで要求分析と要件定義は明確に区別できるのだろうか？
筆者の感覚では、システムの動作仕様が一意に解釈される仕様書を作成するフェーズより前のフェーズはいくら分解しても無意味だと思う。そもそも分解したフェーズの完了基準を明確に一般化できないであろう。抽象レベルに差をつけるのであれば、結論ありきで逆算して段階的に抽象化する、無意味な工数を発生させるだけだと思う。

［事例６］も、日本語訳すれば"Collect Requirements"は「要求分析」、"Define Scope"は「要件定義」という感じなので、「要求分析」→「要件定義」であるが、同様に"Define Scope"のoutputが仕様書ではなく「要件定義書」という感じで、その先にも仕様を作成するフェーズが見当たらないので、そのままソフトウェアの開発プロセスとしては使えない。

［事例２］［事例５］は要求仕様書を作成するフェーズの前にもユーザーの要求を扱うフェーズがあって、「要求定義」「要件分析」「システム要求事項分析」というフェーズで要求仕様書を作成している。

［事例３］［事例４］［事例８］はユーザーの要求を扱うフェーズが１つで、その大括りな「要求定義」「要件定義」というフェーズで要求分析を行い、要求仕様書を作成する。

［事例７］は要求仕様書を作成するフェーズの前に「要求分析」のフェーズがあるので、「要求分析」の成果物は、要求仕様書ではなく、要件定義書に相当するものだと思う。
ただ、少なくとも"Requirements Specification"を「要件定義」と訳す人はいないと思うので、［事例３］［事例４］［事例８］と同様、これらを含む大括りなフェーズの中に「要件分析」と「要求仕様書記述」があると解釈するのが妥当だろう。

こうして見ると、「要求分析」→「要件定義」の順の開発プロセスでは大体要求仕様作成、つまりソフトウェアの設計フェーズへのインプット作成まで行っていないので、何かソフトウェア開発とは異なるものを対象にしているのかも知れない。
もし「要件定義」という名前のフェーズで要求仕様書を作成するのであれば、名前からしておそらくそのフェーズで要求仕様書の前段階である要件定義書に相当するものも作成するだろうから、「要件定義」の前に似たような目的のフェーズは必要ないと思う。

筆者が冒頭で示したような、要件定義書作成フェーズと要求仕様書作成フェーズが大きく分かれているプロセスは、［事例２］［事例５］のように近いものがいくつかあったが、要求仕様書を作成するフェーズの名称として「要求分析」が使われているケースは、上記の事例以外も含めて１つも見つからなかったので、「要件定義」→「要求分析」も一般的ではないようだ。筆者が最初の10年居た会社で外注管理の為に読みまくった開発プロセスには間違いなく「要求分析」と書かれていたので、個人的にショックである。そういえば、確か過去に要求仕様書作成フェーズの名前を「要求仕様」としていた開発プロセスがあり、当時はネーミングセンスが無いなあと思っていたが、今改めて考えると、よく体を表している名前だ。

最も一般的なのは、［事例３］［事例４］［事例７］［事例８］のように、要求仕様書作成をゴールとする要件定義フェーズが要求分析を含む開発プロセスのようだ。確かに、要求仕様書作成に限らず、その前の要件定義書を作成する上でも要求分析と呼ぶべき作業は必ずあるので、不自然さが無く、これが妥当だと思った。