20年前の2004年ごろ「要求は開発するものである」という言説がソフトウェア開発の世界にあった。ちょっと思うことがあって、このテーゼについて勝手に振り返ってみたり考えたという話。
なお、この話は情報システム開発の、現在の文脈でいうならSoRに関するものである。SoEとかWeb開発、プロダクト開発の分野は関係ない話だと思っていただきたい。
「要求は開発するものである」というテーゼは要求開発アライアンスというコミュニティ（勉強会）で提言されていたもの。本家のサイトは停止してしまっているのだが資料はクリエイティブ・コモンズで公開されていたのでこちらの記事で紹介している。具体的にどのような記述だったのかを確認する際には参考にしていただきたい。
「要求は開発されるものである」とはどういうことか？
情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
これはストレートにいえば「ベンダーやコンサルに要件定義を丸投げするな」ということだ。この宣言が表明されたゼロ年代前半のIT業界では、プロジェクトマネジメントが注目されており、情報システムの構築に失敗するということは減ってきた時期であった（それ以前の時代では、システムがよく完成しなかった）。システムは一応完成するようになり、次はビジネス貢献度に注目が移ってきた。単に業務を電子化するだけのシステム化（今風に言えばデジタイゼーション）やユーザーの課題や要望を御用聞きスタイルで取り組むだけではダメで、ユーザーと開発者が「あーだこーだ」議論しながら要求そのものを作り出していくべきである、というのがこの宣言の趣旨だった。要件定義を単なる文書化プロセスではなく、利害関係者による創作プロセスであると捉えるべきなのだ。
当時見聞きした要件定義の失敗はこういったものがあった
- 経営の求める抜本的な業務改善がほとんど落とし込まれていない
- ビジネスの将来像を考えずに業務最適化した結果、新規ビジネスの足かせになった
- 部署ごとの要望を全部取り込んで、とても複雑で高価なシステムになった
- 現行システムの機能と帳票は全部移植した
- あらゆるイレギュラーケースに対応できるようにしたら構築費用が大きく増大した
- 思いつきの要望により作った機能が実際にはまったく使用されない
- 声の大きなパワーユーザーの言う通りにした結果、一般ユーザーには使えないシステムになった
こういったものを防止するために要求開発は宣言され、いろいろな議論が20年前から行われてきた。だが、しかし
あれ？ これ、いまでも起こっていない？
「要求は開発されているか？」
残念ながら、2024年の現代においても（企業情報システム開発の世界においては）「要求は定義するもの」という状況は変わっていない。
経産省で2018年に公開された「DXレポート」では以下のような問題提起がされている。
我が国においては、要件定義から請負契約を締結するケースも少なくない。これは、何を開発するかをベンダー企業に決めてくれと言っていることと同じである。ベンダー企業もそのまま要望を受け入れてしまっている。
このような状態のままでは、アジャイル開発のようにユーザ企業のコミットメントを強く求める開発方法を推進しようとしても無理がある。要件の詳細はベンダー企業と組んで一緒に作っていくとしても、要件を確定するのはユーザ企業であるべきことを認識する必要がある。
- DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省） 簡易版、2.４ ユーザ企業とベンダー企業との関係より
そして現在も主要な要求関連ガイドの多くは「要件定義」パラダイムのままなのである。つまり、要求は開発されていない！
「なぜ要求は開発されてこなかったのか？」
ここからは私論である。要求開発は（現在でも筆者は良いものだと思っているのだが）なぜ流行らなかったのだろうか。その理由について考えてみたい。
ターゲットを外していた説
要求開発宣言を丁寧に読めば理解できるのだが、この方法論は現代で言えば「SoR」のみを対象にした議論だった。しかし当時はSoE/SoRといった名称も発明されておらずソフトウェア開発全般の議論として捉えられていた印象がある。また時代的にはクラウドコンピューティングとアジャイル開発の発展時期であり、SoEの領域においては大きく開発方法論が変化していく時代でもあった。うまく適用範囲を限定することができなかったために、波に乗れなかったという可能性はあると思う。
ユーザーの真のニーズを外していた説
（実システムでの試行錯誤が許されないSoR的な企業情報システムにおいて）上流工程にて創発的に良い要求開発（要件定義）を行うアプローチは一見すると良いものに見える。しかし実際には
ユーザーは本当はそんなことをしたくなかった
という可能性もあったと思う。
- 自分が望んで担当になったわけではない
- より良いシステムを作りたいというよりは、失敗しなければ良い
- できればベンダーに外注したい
- 難しい作業にはできるだけ関わりたくない
じっさい、ゼロ年代後半というと、企業のシステム部門がすこし弱くなってきた時期でもあったと思う。ビジネス部門のユーザーであれば収益の向上などを目的にモチベーションはあったと思うが、「システムはシステム部門が担当」という役割分担の中で、あえてチャレンジングな要求開発のアプローチを取ろうとしたユーザーは多くなかったのではないかとも思う。
SIerのモチベーションも高くなかった説
一方でシステム開発を受注（受託）するSIerのモチベーションも当時は高くなかっただろうと思う。要求開発は難易度が高いことに加えて、うまく成功すれば（理論上は無駄がそぎ落とされて）システム開発の規模が減少する方法論であるからだ。悪名高い「人月商売」とすればハイリスクでデメリットが多いという点で、SIerの立場で要求開発を強く推進するメリットは（当時としては）低かったのではないかと思う。
米国発の方法論や標準に（文化的な理由で）呼応できなかった説
現代でも、ソフトウェア開発の方法論やスタンダードは米国発のものが多い。それらに対して、要求開発が異質のように見えたというのも流行らなかった理由の一つではないかと考えている。
ただこれは文化的な側面があって、米国発の方法論には書かれていないプラグマティズム的思想的な背景が原因ではないだろうか。つまり、米国発の方法論には（書かれていないけど）要求開発的な要素が含まれているのではないかと最近思うようになっている。
という態度が日本人は特に苦手だ。この態度が問題で、肩の力を抜けばうまくいくはずの要件定義が失敗しやすくなっているのではないか。
（なおプラグマティズムの問題は要求開発のみならず、ソフトウェア開発全般に影響しているとも考えている。もはや日本でもアジャイル開発が一般化しているが、これがうまくいっている要因のひとつに文化的障壁を超えてプラグマティズムを日本のエンジニアに注入できたということはいえないのだろうか。まあこれは別の話なので機会があれば別の記事で書く）
むすび：要求はやっぱり開発すべき
というわけで勝手に要求開発宣言について振り返ってみた。改めて考えてみると、要求開発が主流化しなかったのはかなり残念なことである。今回は取り上げていないが方法論としての難しさもある。しかしそれでも、（アジャイル開発宣言のパロディだとしても）要求開発宣言はいいことを言っていると思うし、改めて顧みられても良いと思うのだ。
ご意見があればX（Twitter）もしくははてなブックマークで言及いただきたい。最後までお読みいただきありがとうございます。
