この記事では2021年に閉鎖され、現在はアクセスできない要求開発アライアンスというコミュニティのサイトで公開されていた「要求開発宣言」を紹介する。もう一つの記事「要求開発宣言について振り返る 2024」のためのものでもある。『情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである』というコンセプトを中心に構成された宣言は現在でも興味深い。なお文中でも示されるがこの宣言は2004年（20年前！）になされたものであり、当然のことながら現在の状況や慣行とは相違する点がある。
参考
以下は要求開発アライアンスがクリエイティブ・コモンズ-帰属-2.5 (CC-by-2.5) で公開していた文書「Openthology 要求開発方法論【コンセプト編】」から、「3. 要求開発宣言」を抜き出したもの。
要求開発宣言
要求開発宣言は、システム開発の分野で 2002 年に発表された、アジャイル宣言にインスパイアされ、要求開発アライアンスの理事を中心としたメンバーにて 2004 年 12 月に採択された、要求開発の「こころ」といえるものです。当時のメンバーが今後学び・明らかにすべきことを明文化したものと言えます。要求開発宣言は、要求開発を実践する際に、実践者やコミュニティそして要求開発方法論策定チームが大切にすべきコンセプトです。要求開発方法論は、この基本コンセプトを元に策定されています。
要求開発宣言
私たちは、企業でのITシステム開発を通じて、「要求」に関して以下のことを学んだ。
- 情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
- 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
- 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
- ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
- 要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
- 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
私たちはこれらの気づきから、「要求開発」という新しい知的活動分野を創造し、それをみずから実践していく。その過程で獲得したナレッジをOpenthology（オープンソロジー）として体系化し、かつ、クリエイティブコモンズの下に公開・共有することで、同様の課題を持っている人々と、コミュニティ活動を通じて分かち合うことを決意する。
解説
要求開発宣言
情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
これが、要求開発宣言の中心文です。情報システム開発を行なう場合に、その入力となる「要求」を私たちはどのように扱っているのでしょうか。要求定義、要求収集、要求整理、などの言葉が使われていますが、これらの用語はあたかも、要求というものがそこに存在しているような錯覚を与えています。要求は「定義されたり、集められたり、整理されるのを待っている」ものではなく、私たちが意識的な活動を通じて「創り出す」ものです。この要求を創り出す活動を「要求開発」と呼ぶこととします。システム開発が「要求」を入力して「情報システム」を出力するものであるならば、要求開発とは「ビジネス価値」を入力して「要求」を出力する創造的活動です。このように要求を開発するものであると捉えることによって、要求が本来持っている難しさを想起させると同時に、私たちが経験してきた「システム開発」におけるアナロジーが援用できる、というメリットもあります。そう、要求は私たちが「開発する」ものなのです。ビジネス価値に基づいた正しい要求を開発しない限り、下流であるシステム開発は正しくないものを正しく作る無為な行為となってしまいます。
情報システムと業務活動との相互作用
情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
情報システムは、ビジネス価値向上の一手段であり、それそのものが単体で価値を持つわけではありません。情報システムのデザインは、業務プロセスという上位のデザインの一部であり、そこでは、人間の業務活動と情報システムが相互作用をすることによってはじめてビジネス価値の向上をもたらすものです。情報システムのみに関心を向けることは、まったくの局所最適であり、手段を目的化する間違いだと認識しましょう。そして、デザインされた業務プロセスが果たすべきビジネス価値に、私たちの目を向けましょう。
追跡可能性による説明可能性
情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
なぜ、この情報システムに投資するのでしょうか。この問いに答えるためには、システムに対する要求がいったいどこから出てきたのか、を常に明確にしておく必要があります。このシステムはどのようなビジネス価値に結びつくのか。また、それを実現する手段は何なのか。この目的・手段の構造は目的（WHY）方向の末端をビジネス価値とし、手段（HOW）方向の末端を情報システム（もしくはそれに対する要求）とするツーリー構造をなしています。この目的・手段連鎖が追跡可能（traceable）でなければ、間違った問題に答えようとしているのかもしれない、あるいは、目的を果たすために別の手段の方がよりコストが低く効果が高いかもしれない、という不安から逃れることはできません。さらに、ステークホルダーに対する説明責任も果たせません。私たちはなぜこの情報システムを作るのか。この問いに答えましょう。
ステークホルダーの合意形成
ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
要求開発は個人に閉じた活動ではありません。その情報システムが実現する業務プロセスの価値に関わるステークホルダーの「合意」こそが、要求の開発プロセスとして重要なのです。ここでのステークホルダーに、情報システムユーザー企業の経営者、エンドユーザ、情報システム部門、ビジネス部門、さらに、情報システムベンダーも含まれています。異種ステークホルダーの合意形成が、困難であることは言うまでもありません。しかし、だからこそ、そのプロセスを定義し、継続的に進めることが重要なのではないでしょうか。
継続的改善プロセス
要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
要求開発が複数のステークホルダー間の合意形成であることから、そのプロセスは一方向の命令統制ではなく、参加協調が必要でしょう。さらに、その合意は複数フェーズにまたがる多段階コミットとなります。このプロセスは、継続的改善や PDCA（Plan-Do-Check-Action）ループと相似形をなすものであり、徐々にゆるやかに合意をブートストラップしていくものです。これは、要求開発がブレークダウン型の情報流では作り出せないこと、そして、よりコミュニケーション重視の創発的な活動が重要であることを示しています。
モデルと可視化
「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
私たちは、情報システムの開発を長く経験してきました。そして、要求開発にシステム開発のアナロジーを当てはめることができると考えています。おりしも、オブジェクト指向開発方法論および UML が情報システム開発の標準となり、そのモデリング手法の体系ができあがりつつあります。これを援用することで、ビジネスそのものをもモデル化、可視化できると考えています。そして、要求開発においても、「見える」ということを第一義に重要としています。見えなければ合意形成はできません。見えなければ目的と手段は追跡できません。見えなければ説明できないのです。見えなければ継続的改善はできないのです。私たちは、要求開発の出発点を、このモデル化と可視化に置きます。
