書籍："IMPACT MAPPING"

引き続き、最近読んだ書籍から。今日のお題は、Gojko Adzic氏の[www.amazon.co.jp/dp/0955683645:title="IMPACT MAPPING"]です。これは80ページほどの薄い本で、それほど難しいことが書かれているわけでもありません。
実は、そのエッセンス的なことは以下のサイトにもまとめられており、サンプルも見ることができます。

• Impact Mapping

IMPACT MAPとは何か

書籍のp.2には以下のような定義が載っています。

An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business peope. It is a mind-map grown during a discussion facilitated by answering the following four questions: WHY? WHO? HOW? WHAT?

要するに、GOAL(WHY?) - ACTORS(WHO?) - IMPACTS(HOW?) - DELIVERABLES(WHAT?)の階層で描かれたマインドマップといった感じでしょうか。

シンプルなツールでコミュニケーションを促進する

IMPACT MAPのよいところは、非常にシンプルであるということ。
実際に何かのツールを使って、ステークホルダーの合意形成をしたり、プロダクト/プロジェクトの定義をしたりする際に大切なのは、ツール自体がシンプルであるということだと思います。ツール自体がシンプルであるが故に、誰もがその検討プロセスに参加することができるし、ツールの習得そのものにコストをあまりかけることなく、実質的な中身の議論にフォーカスできるからです。
その意味では、このIMPACT MAPはかなり優れたもののような気がしています。

要求開発との親和性も高い？

かもしれませんね。
そのあたりをやる時のひきだしの一つに入れておきましょう。

Impact Mapping: Making a Big Impact with Software Products and Projects

プロダクト合気道（Product Aikido）

CPA GlobalのHead of Product Development FlowであるBob Marshall氏（twitterのアカウントで、 @flowchainsenseiと呼んだ方が馴染み深いかもしれません）が、CPA GlobalのProduct Developmentのマニュアルを公開しました。そのタイトルが"Product Aikido"です。
簡単な説明は、彼のブログエントリーをご参照ください。そこからpdfファイルをダウンロードして読むことができます。

• Product Aikido | Think Different

これがなかなか私のツボにハマったので、簡単にご紹介しておきます。

書いたのはRightshiftingやMarshall ModelのBob Marshall

いまさらBob Marshall氏についての説明などは不要だと思いますが、代わりに過去のこのブログで彼に関連したエントリーも書いていますので、ここにリンクを貼っておきます。

• RightshiftingとMarshall Model、あるいは組織のドレイファスモデル - Always All Ways
• カンファレンス再考 - Always All Ways

その彼が、プロダクト開発の社内マニュアルを書いて公開したというのだから、それだけで期待が高まりますよね。そして、まだ斜め読みしただけですが、期待を裏切らない内容です。

マニュアルというよりフィロソフィ（哲学）

彼はこの中でこの"Product Aikido"を指すのに、"Philosophy"とか"Doctrine"という言葉を使っています。なのでこれは単なるマニュアルというよりは、「プロダクト開発のこころ」とも言えるようなものではないかと思います。
というわけで、４章からなる全体の構成も、

1. The Nature of Product Development
2. The Theory of Product Development
3. Preparing for Product Development
4. The Conduct of Product Development

というように、プロダクト開発って何やねん？というところから始まっています。

なぜ「合気道」？

"Product Aikido"という名前にした理由については、末尾の奥付に以下のように説明されています。

The author chooses the name "Product Aikido" to reflect the role of spirit, especially harmony, which lies at the centre of effective product development. We might serve our purposes better if we regard entropy not an enemy, but rather as a wayward friend, with whom nevertheless we choose to dance.

が、もうちょっとイメージしやすいところでいえば、第１章にある以下の部分が、合気道のメタファーを使っている箇所としてわかりやすいかもしれません。

Product Development is fundamentally an interactive social process. We might imagine a randori situation (freestyle Aikido training) with a uke (receiver) and nage (thrower), each attempting moves and countermoves to try to defeat the other. Product development is thus a process of continuous adaptation to events, of give and take, simultaneous synthesis and dissolution.

心構えの書

つまり、これはプロダクト開発に取り組む上での「心構え」を記したものであるというのが私の印象です。したがって、前書きでも書かれているように、リファレンスマニュアルのように使うのではなく、最初から最後までじっくりと読んでみるのがよいのだと思います。
というわけで、昨日のエントリー（「オブジェクト指向のこころ」）に続く"こころ"シリーズ第２弾でした。

ハイブリッド型プロジェクトでのBAの身の処し方

昔のブログで、アジャイルなプロジェクトやチームにおけるBA（Business Analyst）の役割についてのいくつかの参考資料のまとめエントリを書いていました。

• Always All Ways: [IT] AgileにおけるBusiness Analyst

そこでピックアップした資料群は、どちらかというとトラディショナルなBAがアジャイルの文脈にどう対応していくかという観点のものが多かったと思います。しかしながら、現実にはもう少しハイブリッドな環境（←実際には過渡期を含めてこのような環境の中でどうしていくかというのは非常に大きな課題だと思っています）に直面することも多く、そこでどう考えるべきかということを、以下の記事を参考にして整理してみたいと思います。

• The 3 types of hybrid projects, and how they affect the business analyst's work

基本的にこの記事をベースに以下に展開していますが、元記事には執筆者の過去エントリや関連記事へのリンクなども豊富ですので、興味を持たれた方は是非、元記事をご覧になることをおすすめします。

TraditionalとAgileのハイブリッドの３形態

ハイブリッドなアプローチの是非については諸々議論のあるところだとは思いますが、一旦ここではその点については判断を留保しておきます。ただ、いずれにしても現実問題として世の中にはハイブリッドなアプローチを取らざるを得ない状況もあるだろうということを受け入れた上で、その中で最大限の成果を出すためにBAとしてどう身を処していくかというのが今回のポイントです。

上にリンクを貼り付けた記事の中では、ハイブリッド型のプロジェクトを３つの類型に分けています。

1. フランケンシュタイン型
2. 異種交配型
3. コンボ型

以下、それぞれについてその特徴とそこでのBAのあり方についてみていきましょう。

フランケンシュタイン型

これはあまり望ましくない形ではありますが、現実にはよくある（そしてみんなを悩ませる）かもしれない形ですね。
イメージとして言葉にすると、「今度のプロジェクトではアジャイル開発を採用するよ。でも、開発に着手する前にユーザから要件についてのサインオフをもらおうね。あ、それから、期限通りにすべての機能をリリースするのは必須ね！」みたいな感じのプロジェクト。ほんと、悪夢ですね。
こういうプロジェクトに放り込まれたBAの悲劇としては、

• アジャイルの名のもとに十分な時間を割り当てられない状態で、事前にすべての要件を詳細に定義するという非現実的な期待に応えなければならない
• 期限通りの全機能リリースをコミットさせられた開発チームが要件の変更を受け入れてくれない結果、ユーザのフラストレーションが溜まる（その板挟みになる）
• 結果として、ユーザやビジネスのニーズに応えられないということも含む全般的なプロジェクトリスクの増大

BAの身の処し方

フランケンシュタイン型のプロジェクトにおいては、BAとしてはそのリスクを叫び続けるくらいしかできることがありません。そんな中での一番の戦略は、最初からそんなプロジェクトにアサインされないようにすることです。

異種交配型

これは、トラディショナルとアジャイルが入り混じっているという点ではフランケンシュタイン型と同じですが、プラクティスの取捨選択において、インテグレイティブ・シンキング（Integrative Thinking）に基づいた考え方が適用されているという点で異なるアプローチとなります。
適切に「異種交配」が行われれば、BAとしてもその考え方に則って自分の身の処し方を考えることができます。基本的に、この考え方がうまくいく場合はイテレーションによるリズムの中で必要な要件を必要な時に定義し、またその優先順位を適宜見直していくことが可能になっていると思われます。

BAの身の処し方

このようなプロジェクトの中においては、BAとしてもトラディショナルなBAとアジャイルBAのやり方をうまく組み合わせて成果を出していくことが肝となります。たとえば、アジャイル型のユーザーストーリーやプロダクトバックログを作ることと、従来型の機能分割やデータモデリングをどう組み合わせていくか…など。
どうやったら最大の価値を生み出せるかということを考えて行動することが求められます。

コンボ型

これは大規模プロジェクトでよく見られるタイプのやつですね。アーキテクチャーとかセキュリティとかがっちりやりたいところはトラディショナルで、それ以外の要件の変動がありそうなところはアジャイルで、みたいな形。いわゆるWater-agile-fallってやつもこの分類に入るかもしれません。

BAの身の処し方

ここでは、計画駆動のフェーズとアジャイルなフェーズを分けて考えましょう。それぞれのフェーズによって求められる能力や必要な成果物のあり方、仕事のやり方が異なってきます。
従って、コンボ型プロジェクトの場合は、それぞれのフェーズによってそれに適したBAをアサインすることでより大きな成果が得られることもあるかもしれません。

まとめ

BABOKのAgile Extentionの話などもあるように、今後、アジャイル開発におけるBAの役割やあり方についての議論などもいろいろなされていくと思います。その一方で、現実にはトラディショナルとアジャイルの間にあるハイブリッドなプロジェクトも多々出てくるのではないかと思われます。良いものも悪いものも含めて。いずれにしてもフランケンシュタイン型は撲滅しなければならないと思いますが、そのためにも、このハイブリッドの３つの形を意識しながら、BAとしての現実解を探していきたいものです。

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

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自体もそれを具体化する手法のバリエーションあるいはレファレンスとして考えた場合には、より広い可能性をまだ持っているのではないでしょうか。

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

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

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

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

Scrumを教えるのに最適なフレームワークはScrum

Tobias Mayer氏が、「スクラムのワークショップにおける５つの『やってはいけない』」みたいなブログ・エントリを書いています。せっかくなので、その５つを見出しのみ抜粋してみると、

1. Don't plan the whole workshop.
2. Don't ask questions you already know the answer to.
3. Don't play games with predefined outcomes.
4. Don't answer questions.
5. Don't talk about yourself.

Top 5 Scrum Workshop Dont's

それぞれの内容については原文を見てくださいね。

Scrumを教えるためのフレームワーク

これらの５つのポイントはそれぞれ重要な示唆を含んでいるのですが、私自身は、この記事の中で最も重要なのは、"Scrumを教えるのに最適なフレームワークはScrumである"という点ではないかと思っています。

There is a great framework for teaching people about Scrum. It is called Scrum.
Top 5 Scrum Workshop Dont's

その根底にあるのは、Scrum（に限らずアジャイル開発全般的にそうだと思うのですが）が、複雑適応系（Complex Adaptive System）を扱うものであるということ。それを忘れると、本来ワークショップの中で気づき・考えるべき「不確実性にどう対応していくのか？」ということを体験できず、参加者はチグハグな印象を受けるだけでなく、場合によってはワークショップで最も気づいてほしいことに気づかずに間違った理解をしてしまいかねません。

フレームワークとワークショップのメタな関係

同じように考えると、要求開発を教えるためには要求開発的なファシリテーションでワークショップを進めるのが適しているように思いますし、その他同じようなことはいろいろなフレームワークや方法論に対しても言えるのではないでしょうか。
実際、例えば私自身は残念ながら参加できませんでしたが、Jeff Patton氏のCSPO研修ではセッションの進行自体をユーザーストーリーマッピングの手法を使ってやったような話も聞いています。
参考： Jeff Patton氏の “情熱プロダクトオーナーシップ” に参加しました #sgt2011 #CSPO | 世界のdaipresents

本質を理解すること

これらのことは、Scrumや要求開発（およびその他世の中のフレームワークや方法論、プロセスなどなんでも）を教えるにはまずなによりも、単なる表面的な知識や具体的なプラクティスだけでなく、その本質を理解していなければならないことを示しています。そして、それをワークショップの中で体現していくこと。これはしっかりと心に留めておきたいです。

参考（関連記事）

• Always All Ways: [IT] ScrumもKanbanも問題を解決してはくれないよ
• Always All Ways: [IT] 継続的改善フレームワークとしてのScrum
• 「要求開発の心」を活かすポイント - Always All Ways

ローカル・ナレッジを参照点として複雑適応系とダンスする要求開発

今朝の id:kent4989 氏のエントリにインスパイアされて、まとまりがないものの思うところを書いてみたいと思います。
元記事はこちら↓
ローカルな知としての要求開発 - 勘と経験と読経

まず最初に断っておきたいのは、氏が言わんとしていることはだいたい理解できるし、それを否定するつもりでこれを書いているわけではないということです。その上で、氏の論点が誤解されるおそれのありそうなところを自分なりに補足するとともに、自分の考えを後日見直すためにメモしておきたいといったところです。
注）本稿における「要求開発」は要求開発アライアンスが提唱するOpenthologyおよびそれをとりまくプラグインや派生する諸々を指しています。

工学的かどうかの話について

要求を工学的に扱えるかどうかとか、何をもって「工学」と称するかについては、実は私自身はあまり興味がないので、ここについてはさらりと流しておきたいと思います。（別に工学と呼ぼうが呼ぶまいが、それで世の中が良くなればそれでいいではないですか、と私なんかは思っちゃうわけです。）
ただ、ここで重要なのは、要求を扱うということがComplex Adaptive System（CAS: 複雑適応系）を扱っているということではないでしょうか。そう捉えると、id:kent4989 氏が引用している中にあるように「ビジネス活動における力学を知り、人間関係の調整能力なども身につけてゆく必要がある」というのは当たり前のことですよね。さらに言えば、ソフトウェア開発というものが人間によって行われる営みである以上、要求に関する部分だけではなくソフトウェア開発全体がCASであり、それに対してどう向き合うかということは常に考えていく必要があるのではないでしょうか。

ローカルな知

これについては、元記事を読んでから改めてさくっと調べたレベルの知識しか私にはありません。従って、間違って理解・解釈しているかもしれませんがご容赦ください。
id:kent4989 氏は、要求開発を「ローカルな知」と考えてはどうかと述べています。

人類学では「ローカルな知」というものがあるということを最近知ったのだけれども、要求開発はまさにこの「ローカルな知」にあたるのではないかと思っている。

技術者的な思考をすると、つい普遍的な方法論・メソドロジーを考えてしまいがちだ。しかし、ソフトウェアに関する企画や要件定義といった領域においてはもっと「ローカルな知」的な方式を見出していったほうが良いのではないだろうか。

ここでの氏の論旨は、要求開発が扱う対象が「ローカルな知」であるので、それを扱うには普遍的あるいは画一的な方法論では対処しきれないのではないか、ということではないかと私は勝手に理解しています。つまり、要求開発自体が「ローカルな知」ではなく、その対象とする要求そのものやその要求のソースとなる人や組織その他諸々が「ローカルな知」であるというわけです。
ただ、その「ローカルな知」と向き合うための方法が必ずしも「ローカル」であるべきかとか、だからと言って統一的・普遍的な方法論ができないかというと、そこはちょっと疑問です。
たとえば、池田光穂氏のウェブページを見ると、クリフォード・ギアーツのLocal Knowledgeについて以下のような説明が出てきています。

つまり、クリフォード・ギアツのいうローカル・ノレッジとは、決してたんじゅんに、局所的な知とか、文化相対主義的な意味での土着の知を直接示しているものではない。
ローカル・ノレッジ(という隠喩）の分析

むしろ、ローカルな知を参照点として、その知的想像力を駆使する民族誌や法の理解（＝抽象化された知的システムや、一般化と個別理解のせめぎ合いが見られる知的法廷における知の操作技法をめぐる議論）のあり方と、その知的源泉としての〈事実知〉や〈具体知〉のダイナミズムについて、考えようとしているのである。
ローカル・ノレッジ(という隠喩）の分析

結局のところ、われわれはローカル・ノレッジ以上のものを必要としているといってよい。われわれはローカル・ノレッジの多様性をその相互参照性に変える、つまり一方が暗くするのを他方が照らす方法を必要としているのだ。
ローカル・ノレッジ(という隠喩）の分析

誠に付け焼刃ではあるけれども、このあたりの記述を援用すると、要求開発に関しても、「ローカルな知」としての業務やビジネスや人・組織を参照点として、その多様性を相互参照性に変えて何らかの方法を生み出すのが、要求開発あるいはOpenthologyを考える我々の使命ではないかと思うのです。

ダンスすることはできる

要求開発を含むシステム開発が複雑適応系であるならば、それに対して我々がどう立ち向かうことができるかについては、Jurgen Appeloの"How to Change the World"の中でも引用されているDonella Meadowsの言葉をここで挙げておきたいと思います。

“We can't control systems or figure them out. But we can dance with them!”
Meadows, Donella. Thinking in Systems: A Primer. White River Junction, Vt: Chelsea Green Pub, 2008.

システムをコントロールしたりそれを完全に理解することはできませんが、それとダンスすることはできるのです。こちらの動きに対してシステムがどう反応するかを観察し、それに適応していくのです。その際に、取り扱うものが複雑適応系であるということとともに、その対象がローカル・ナレッジであることを理解しておくことが重要なのです。

Complex Adaptive System

ローカル・ノレッジ―解釈人類学論集 (岩波モダンクラシックス)

Thinking in Systems: A Primer

「要求開発の心」を活かすポイント

【おことわり】
この記事は、もともとエンジニア向けフリーペーパー"EM WEST"の連載記事「現場での要求開発のはじめ方」の第２回として書き下ろしたドラフトです。EM WEST Vol.3（だっけ？）の発行がまだ先になりそうなので、現時点でブログの方で番外編として公開してしまいます。また、この連載自体は、読者のみなさんに「要求開発」あるいは「要求開発アライアンス」が提唱するOpenthologyを、より身近に感じていただくために始めたものですが、その内容については私個人の見解も多分に含まれており、必ずしも要求開発アライアンスの公式見解ではないことをあらかじめご了承ください。

はじめに

要求開発に関してよくある質問の一つが、「何ができていたら『要求開発をやった（やっている）』と言えるの？」というものです。今回は、かなりの私見も含めてそのあたりについて語ってみたいと思います。

要求開発の心

要求開発宣言が出されたのが2003年12月、そしていわゆる「白本」と呼ばれている書籍「要求開発」（日経BP）の出版が2006年3月です。それから年月を経て、ビジネスを巡る環境も、要求開発に求められるものも大きく変わってきています。
単に「白本」に書かれたプロセスやプラクティスをなぞればそれが要求開発かというと、決してそうではないでしょう。私は以下のことが「要求開発の心」として重要なポイントであると考え、実践でも心がけています。
ポイント１： ３つのT
ポイント２： 開発者/エンジニアが主体的に関わる活動
それぞれについて以下に簡単に説明します。

３つのT

要求開発を支えるものとして次の３つが重要であり、これらを具現化するためにさまざまなプロセスやプラクティスを「現場のコンテキストに応じて」使い分けていくことこそが要求開発の本質なのではないかというのが、私が「３つのT」と名付けて提唱している仮説です。

Transparency（透明性）

モデルによる可視化、ステークホルダーの適切な巻き込み（コタツモデル）と適切なコミュニケーションなど。

Traceability（追跡可能性）

要求分析ツリーで要求の階層化・上位要求との関連の明確化、目的と手段の連鎖の可視化、各種モデル間の連携などにより、各個別要求事項の出自と正当性を明らかにしていくこと。

Triage（トリアージ）

要求をきちんと評価・分別・取捨選択して、制約の中で価値最大化を目指すこと。

開発者/エンジニアが主体的に関わる活動

前述の３つのTが３本の脚と考えた場合、それが支えるものは何でしょうか？私は、それこそが要求開発宣言の理念である「情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて『開発』されるべきものである」という考え方だと思います。
ここでは、敢えて「開発」という語を使ってシステム開発のアナロジーを、要求を創りだす活動に援用しているところがポイントです。また、要求開発が要求の可視化を行うに当たって当初よりUMLによるモデリングを取り入れて活用してきたことからも、この活動がいわゆるビジネスアナリストだけでなく、開発者/エンジニアが主体的に関わる活動を意図していることがわかると思います。

クラウド/アジャイル時代の要求開発

誤解のないように書いておきますが、「開発者/エンジニア主導」とはいえ、経営陣をはじめとするビジネスサイドや現場担当者などそれぞれのステークホルダーがそれぞれに重要な役割を果たすことは言うまでもありません。
ただ、昨今の状況を見ていると、この開発者/エンジニアが主体的に関わるという部分が、より重要な意味を持つようになってきているのではないかと思います。
その背景にあるのは、クラウドでありアジャイル開発です。従来から、要求開発では要求の実現可能性を探ったりするための「フロントローディング開発」や、開発者の知見をより価値の高い要求作りにフィードバックすることの有用性が言われていました。近年、クラウドコンピューティングの広まりにより今まで以上に実装レベルでの手探りの環境が整ってきていますし、アジャイル開発の普及によってより高い頻度でフィードバックループを回すことができるようになってきました。そこで重要となってくるのがそのメリットを最大化できるような開発者/エンジニアの存在なのです。

まとめ

少し話が横道にそれた部分もありますが、筆者の見解をまとめると、

• 「要求開発をやる」ということは要求開発宣言の理念を、要求開発の３つのTを通じて具現化したプロセスやプラクティスを実装することである
• その実践にあたっては、開発者/エンジニアの力をいかにうまく活用していくかというのがポイント

となります。
そして、それらの活動が「ビジネス価値」にもとづいたものであるべきだということは言うまでもありません。

【コラム： あれもこれも要求開発！？】
そこのあなた、「そうは言っても、仕事でシステム企画とか上流工程とかやってないし、要求開発なんてあまり関係ないなぁ。」と思っていませんか？いえいえ、そんなことはありません。あなたが実装を担当するエンジニアだとしたら、あなたの実装視点からのフィードバックは要求開発の重要な要素の一つです。アジャイルチームで開発している人が、最近流行（？）のインセプションデッキつくりに取り組んでいる時、それも要求開発です。もっと言えば、旅行の計画を立てるときも、晩ご飯の献立を考えるのも…あれもこれも要求開発！？結局は、要求開発も、”It’s All About Common Sense!”なのです。それをどういうふうに構造化し、実効性を持たせる工夫をするかというところでちょっとカッコつけてるだけなのです（笑）。

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