ソフトウェア開発で最も難しいのは「何をつくるかを決める」という点だ。要求(Requirement)を適切に捉えることができなければ、「役に立たないソフトウェア」や「動かないソフトウェア」が出来ることになる。実際にソフトウェア開発プロジェクトの失敗要因の上位は企画・要件定義という調査も多い。逆に言えば、要求を適切に取り扱うことができるのであればソフトウェア開発プロジェクトの成功確率も上がる。そこで、要求の取扱いに関して様々な方法論やアプローチが提言されてきた。しかし、銀の弾丸はまだ見つかっていない。
要求は工学的に扱えるのか
要求の取扱いについては様々な方法論や対策が検討されてきた。
- 要求定義の方法論を知る【前編】 | 日経クロステック（xTECH）
- [Think IT] 第1回：要求定義方法論「MOYA」とは？ (1/3)
- NTTデータが上流工程の方法論を標準化 | 日経クロステック（xTECH）
- 刊行物・レポート
(BABOKをいれていないのは、私が不勉強だからということに加えて、ソフトウェア開発向けの方法論とは少し異なるという理解だから)
しかし、要求を扱うということは、ソフトウェアの世界の外側と向き合うことでもある。ということは、要求を真正面で工学的に（一つの統合論として）扱うということは難しいのではないかと思う。
世にあまたの要求工学手法が提案されているが、現実の世界は、単一の手法によって取り扱えるほど単純ではない。要求分析者を目指す技術者は、今後、多様な手法だけでなく、ビジネス活動における力学を知り、人間関係の調整能力なども身につけてゆく必要がある。言い換えれば、要求工学は、現実世界との接点に立つ技術であり、そこでは、技術は、それを使えば問題が解決するという単純な道具ではない。
国立情報学研究所 トップエスイープロジェクト 要求獲得・記述 平成２３年度シラバス
要件定義などは一種の「異種格闘技戦」だ。一つの様式やルールのもとでやっていくのは難しくて、相手（の業務分野や顧客像）にあわせて臨機応変に手持ちの技を繰り出していかないと立ち迎えないものだと思っている。
ローカルな知
要求開発は、前述の要求関連の方法論とは少し毛色が異なっている。主に取り扱っているのは合意形成であり、ビジネスモデリングなどの手法も含まれているけれども、あくまで合意形成のためのツールとしてである。（ちなみに策定者の言では「工学とは異なる」と聞いている。うろ覚えですが。）
もちろん要求開発も銀の弾丸ではなないし、特定のシチュエーションでしか効果がないものだと思う。00年代にトラブルの多かったエンタープライズ系の社内システム開発のような状況にはとてもフィットしている印象（要求開発のホームグラウンドについては後日また論じたい）。
むしろ、要求開発は特定のシチュエーションにおいては（合意形成といった）泥臭い現実と向き合っている点が強力であると考えている。
人類学では「ローカルな知」というものがあるということを最近知ったのだけれども、要求開発はまさにこの「ローカルな知」にあたるのではないかと思っている。
「ローカルな知」という言葉ですが、これはもともと人類学などで使われるようになった概念です。
科学が非常に体系的な、普遍性のある知を求めるのに対し、ある特定の領域で用いることのできる、実際の経験の中で見出されてきた知、というようなニュアンスのある言葉です。
もうダマされないための「科学」講義 (光文社新書)
技術者的な思考をすると、つい普遍的な方法論・メソドロジーを考えてしまいがちだ。しかし、ソフトウェアに関する企画や要件定義といった領域においてはもっと「ローカルな知」的な方式を見出していったほうが良いのではないだろうか。
