Always All Ways

Apologies, Glances and Messed Up Chances

要求開発を語るときの心地悪さとその原因

id:kent4989さんのエントリに反応しつつ、また少し要求開発界(?)を盛り上げてみましょうか。
元エントリは、こちら↓
要求開発のホームグラウンドについての考察 - 勘と経験と読経

この中で彼は、要求開発の適用範囲は限られており以下のような領域がその「ホームグラウンド」である、としています。

  • 複雑度が高いエンタープライズ系のシステム
  • (人系を含む)ビジネスシステムのリプレース
  • 対象企業の規模は大きめ

今回はことさらそれに異を唱えるというよりも、世間で「要求開発」が語られるとき、あるいは自分自身が「要求開発」を語るときの、なんというか落ち着かない感じというか、ムズムズ感というか、えも言われぬ心地悪さについてちょっとだけ述べてみたいと思います。
なお、改めて言うまでもないことですが、ここで書いていることは筆者の個人的な見解であり、要求開発アライアンスをはじめいかなる団体その他の意見も代表しているものではありません。

「要求開発」って特別な言葉なの?

id:kent4989さんのエントリでは、「要求開発」という言葉がいわゆる要求開発アライアンスが提唱する要求開発宣言の理念に基づく手法、より具体的にはOpenthology 0.6および1.0(いわゆる要求開発の「白本」)あたりを指していると思います。世間的にも(あくまで日本限定ではありますが)、要求開発アライアンスの活動をご存知の方は「要求開発」と聞くとまずそれを思い浮かべるでしょう。
しかしながら、世の中には(どちらが先とか後とかは置いときますが)それ以外でも「要求開発」という用語は使われているわけですね。
たとえば書籍のタイトルだけを見てみても、(これは同じ要求開発アライアンスの安井理事が書かれたのでほぼ同じ仲間と思ってよいと思いますが)要求開発の「黒本」もありますし、翻訳本ではKarl E. Wiegersの「要求開発と要求管理」もあります。そして、英語で「要求開発」に相当するのは"Requirements Development"ですが、これはCMMIの中にも出てきますね(ただし、日本語訳は「要件開発」です。)
ちなみに余談ですが、Wiegersの本の原題は"MORE ABOUT SOFTWARE REQUIREMENTS"ということで、"Requirements Development"とタイトルがついているわけではないです。ただ、Wiegersの功績は、単なる要求の収集(Gathering)というのをやめて要求の引き出し(Elicitation)というのを使い始めたことだと言われています。(参考: ビジネスアナリシス/BABOK(R): 参考文献解説No.001:『要求開発と要求管理』
少し横道に逸れましたが、要するに、「要求開発」という言葉は要求開発アライアンス以外でも使われており、何を指しているのかを明確にして話をしないとなんとなく気持ち悪いわけです。

要求開発 ≠ Openthology

では、要求開発アライアンスの言っている要求開発とは何でしょう?
白本の「はじめに」では次のように書かれています。

筆者らが言う「要求開発」は、システムが実現すべき要求を能動的に開発する活動である。

一方で、Openthologyとは何かと言えば、「要求開発アライアンスが策定した要求開発方法論」です。
この違いがわかるでしょうか?
これは言うなれば、「アジャイル開発」という概念と個別の「アジャイル開発方法論/プロセス/フレームワーク」との関係と同じなのです。乱暴に言ってしまえば、アジャイル・マニフェストの理念に基づいたやり方はすべて「アジャイル開発」で、具体的なやり方については、XPとかScrumとかChrystalとかいろいろあると。同様に要求開発宣言の理念に基づいたやり方はすべて「要求開発」で、具体的なやり方の一つとしてOpenthologyというのがあると考えればよいのではないでしょうか?ですので、私自身は、Openthology以外にも要求開発方法論はあっても良いと思っています。今現在具体的な名前がついて世にでているものとしては、豆蔵のenThologyや、匠 Business Placeの匠メソッドあたりが相当するのではないでしょうか。
要求開発の話をするときには、「要求開発」の話をしているのか「Openthology」の話をしているのかを区別しなければいけないということですね。

Openthologyとは?

ではさらにここで突っ込んで、Openthologyとは何なのかということを整理しておきたいと思います。これについては、外に対して正式な発信があったかどうかは定かではないので、知る人ぞ知る情報かもしれません。なのでここでどこまで書いていい話なのかはわかりませんが、特に伏せておく話ではないと思いますので書いてしまいましょう!
実は、2009年11月11日の理事会において、Openthologyの位置づけが変更されています。(えぇぇぇっ!?)
背景としては、それまでは要求開発アライアンスの活動趣旨が「要求開発のプロセスや手法の標準化」だったのですが、それ以降は「要求開発に関連するプロセスや手法の共有」に変わったというのがあります。ですので、それまでOpenthology 1.0として有形化されていたものは、Openthologyレファレンス1.0となり、今後有形化されて出てくるものはOpenthologyレファレンスx.xとなります。これにより、標準なのかどうかという固い縛りでのハードルの高さはなくなり、もう少しゆるくその時点でのベストプラクティス的に共有したいものを共有してお役立ち感を出そうという方向になったわけです。(まぁ、今のところまだそういうのも出てきてないわけですけれども。)

改めて要求開発のホームグラウンドについて

これらを踏まえて、私がid:kent4989さんのエントリを見て感じたことを整理すると、

  • 確かにid:kent4989さんがエントリ中で「要求開発」と呼んでいるのがOpenthology 0.6や1.0を指すのであれば、その策定当時に対象とされていた業務/システムや、モデル中心のそのアプローチなどから、特にフルセットで適用できる領域は限定的に捉えた方がいいでしょう。(方法論や手法に無理をさせてはいけない!)
  • 但し、要求開発を上で整理したような概念で捉え、また、Openthology自体もそれを具体化する手法のバリエーションあるいはレファレンスとして考えた場合には、より広い可能性をまだ持っているのではないでしょうか。

ということです。
つまり、このあたりの議論は、「要求開発をこう定義したらこうなんだけど、こういう風に捉えるとこうなる」というような話なので、そこの認識を合わせてからでないと議論が噛み合ないということです。

要求開発~価値ある要求を導き出すプロセスとモデリング

要求開発~価値ある要求を導き出すプロセスとモデリング

  • 作者: 山岸耕二,安井昌男,萩本順三,河野正幸,野田伊佐夫,平鍋健児,細川努,依田智夫,[要求開発アライアンス]
  • 出版社/メーカー: 日経BP
  • 発売日: 2006/03/02
  • メディア: 単行本
  • クリック: 13回
  • この商品を含むブログ (18件) を見る

戦略的「要求開発」のススメ (PM magazine)

戦略的「要求開発」のススメ (PM magazine)


要求開発と要求管理―顧客の声を引き出すには

要求開発と要求管理―顧客の声を引き出すには