「発見から納品へ：アジャイルなプロダクトの計画策定と分析」 [1]という書籍の著者の１人であるメアリー・ゴーマンさんがRegional Scrum Gathering Tokyo 2015での招待講演やトレーニングの実施のため、2015年3月に来日された際にオブジェクトの広場編集部が実施したインタビューを前後編の2回に分けてお届けします。後編では、「DtoD (Discover to Deliver) [2], [3]の実践」というテーマで藤井がお聞きした内容を紹介します。
DtoDの実践（続き）
DtoDのセッションの所要時間と効率化
藤井－ 次の質問は、DtoDのセッションにどの程度の時間を要するかというものです。特に事前ビューセッションのようなセッションにどの程度の時間を要するのでしょうか？半日要するのでしょうか？数時間で実施できるのでしょうか？
用語注：事前ビュー
事前ビューは、DtoDの3つのビューの1つであり、次のリリースを対象にする。事前ビューでは、次のリリースを対象にプロダクトのオプションを検討し、それらのオプションから優先度の高いストーリーを組み立てる。さらに得られたストーリーを見積もり、それらがリリースまでの期間内に開発できそうかを確認するとともに、ストーリーの業務等における妥当性を確認する。
メアリーさん－ 状況により変わります。3時間でセッションを実施したこともあります。それは、ある程度の期間、一緒に作業をしたチームについての話です。チームはドメイン知識を持っていました。また、環境と品質特性も分かっていました。選択の余地はありませんでした。従わなくてはならない会社の標準もありました。そこでは新たな発見はありませんでした。従わなければならないだけです。それで、7つの側面ではなく、5つの側面に減らすことができたのです。このセッションは、既存のプロダクトの拡張を対象にしていました。これらすべての要素で、セッションを大幅に短縮できたのです。
いいですか。新たなチームだったり、新たなプロダクトだったり、新たな技術があったりすれば、それらの要素すべてがセッションの時間に影響し得ます。それでもアジャイルでは、リリースは1か月か2か月分の価値に相当する作業です。そのような性質上、セッションを3, 4日も行わないでしょう。お役に立ちましたでしょうか？
藤井－ はい。
藤井－ 準備はセッションの時間の短縮に役立つのですよね？
メアリーさん－ そのとおりです。ファシリテーターとして、ご存じのようにエレンのことを私たちはファシリテーターの女王と呼んでいますが、我々はどの程度の準備が必要かを判断するための表を持っています。もしX名の人が1日のセッションに参加するならば、事前準備に多くの時間を費やすことになるでしょう。この事前準備は、ファシリテーターではなく、計画策定を支援する少数のメンバーで行うでしょう。
藤井－ なるほど。
メアリーさん－ チームが準備への事前の投資が必要なことを認識し、人々にそれを確約させることが重要です。
藤井－ 分かりました。
構造化された会話という言葉の由来
藤井－ 次に、調査、評価、確認のステップを「構造化された会話」と呼ぶ理由を教えてください。
用語注：構造化された会話
DtoDの事前ビュー等のセッションにおいて、プロダクトオプションを広く識別する「調査」ステップ、識別したプロダクトオプションの中で優先度の高いものを絞り込む「評価」ステップ、優先度の高いプロダクトオプションから組み立てたストーリーの妥当性を確認する「確認」ステップの3つのステップで検討を進めること。
メアリーさん－ そうですね。アジャイルなアプローチにおいて、ストーリーは会話することの約束です。
用語注：会話
（ユーザー）ストーリーの意図に合うソフトウェアの仕様を考案、理解するために行うプロダクトオーナーと開発者の間の質疑や相談のこと。
藤井－ そうですね。
メアリーさん－ 私たちは、会話がどんどん続いて、人々が会話を制御できなくなるというセッションを数多く経験しました。迷子になるのです。そして不満を抱きます。人々が立ち去ります。私たちは、人々が話をする適切な方法を提供しようとしたのです。人々が使うだろう１つのパターンがあります。そのパターンは、可能性、オプションを調査し、それを価値の高いものに絞り込み、その場から立ち去る前に自分たちの理解をしっかりと確認するというものです。
多くのチームが、構造化されていない会話で、調査に多くの時間を費やし、多くのストーリーを書きます。それで、数百のストーリーが得られるので、それらの価値を評価しようとします。そこからは、馬鹿げた状況が始まるだけです。そして、時間を使い切ってしまい、発言されたことを全員が理解しているかの確認は決して行われません。私たちは、これを素早く、再現可能で、パターン化されて人々が使えるものにしようとしたのです。私たちは、ロードマップ策定を使うのであれ、リリース計画策定やスプリント計画に使うのであれ、この方法があらゆるレベルで機能すると信じています。私たちは、自分たちが目にした人々の痛みを本当に感じたのです。私たちは、どうしたらこの人たちの会話を大幅に効率化する助けになり得るか？と考えて、構造を加えたのです。
藤井－ なるほど、分かりました。
ファシリテーターや分析者の役割や準備
藤井－ 次の質問は。DtoDにおいて通常、分析者がファシリテーターの役割を果たすのかというものです。この質問は、メアリーさんの（Regional Scrum Gathering Tokyo 2015での）ご講演とも関係しますね。
用語注：（Regional Scrum Gathering Tokyo 2015での）ご講演
講演タイトル「アジャイルな発見プラクティスを革新し、活性化させましょう (Innovate and Invigorate Your Agile Discovery Practices)」[4]。
メアリーさん－ はい、その通りですね。チームでよくあることですが、チームを見渡して「誰がファシリテートできるかしら？」というと、その人たちは分析者の方をよく見ます。分析者は通常ある程度のコミュニケーションスキルを備えているはずと思うからです。IIBA®の知識体系の抽出知識領域には、抽出のなんたるかと、抽出に使える9、10箇の異なる方法が記述されています。分析者は、ファシリテーションの方法を知っており、分析者のスキルの1つがファシリテーションだと期待されるのです。
用語注：IIBA®
“Internatonal Institute of Business Analysis®"の略称。ビジネス分析者の国際的なコミュニティーであり、BABoK (Business Analysis Body of Knowledge)を作成している団体として有名。
ビジネス分析者が調査、評価、確認に積極的に関与しなければならない点がチームにとってのリスクになります。ファシリテーターと分析者の両方になるのは非常に困難です。私が講演の中でお話しした事前ビューの作業に対して、その作業の間になんらかの種類のファシリテーションが必要になります。最低限、ファシリテートされたセッションを持ち、ある程度の作業を設計し、自分たちが使おうとしている議題にどの程度の時間を要するかを考えねばなりません。それらをすべてこなし、議題を管理し、人々が作業を行っているのを観察し、必要があれば物事を変えるのを助けるのです。オプションの調査に積極的に関与しながら、これを行うのは不可能です。
現在ビューでは、チームが解決でき、そのレベルでファシリテートします。チームは通常そのようなことを行うスキルを育んでいます。ビジネス分析者がリリース計画策定セッションをファシリテートしようとする場合には、１つ注意すべき点があります。それは、グループがビジネス分析者の分析者としての知識とスキルを利用することができないという点です。
用語注：現在ビュー
DtoDの3つのビューの1つで次回の反復（スプリント）を対象とする。現在ビューのセッションでは、次の反復で開発するプロダクトのオプションを検討し、それらのオプションから優先度の高いストーリーを組み立てる。さらに、優先度の高いストーリーに対する受け入れ基準を考案する。
藤井－ なるほど。
藤井－ 次の質問は、ファシリテーターの準備についてです。ファシリテーターがDtoDのセッションの前に価値観点やプロダクトオプションを検討する時間を多くとった方がよいのではないかと思います。プロダクトオプションを理解する必要はあるでしょうか？
メアリーさん－ オプションの識別はセッションで一般的に行われるので、事前で検討するのはオプションではなくてもよいかもしれません。事前準備の一部で一般として的なシナリオを考えてもよいでしょうし、それはとても助けになると思います。検討対象のプロダクトに関する5つか8つのシナリオがあれば、それらをオプションを考えるための出発点とすることができます。これとワラレベルの分析モデル、いくつかの簡単な例は役立つかもしれません。
用語注：ワラレベルの分析モデル
DtoDの本番のセッションの前に開催する事前検討のセッションで識別するたたき台レベルの分析モデルのこと。
最近、私がチームとともに事前作業を行った際に、重要な規制を選んでもらいました。その計画策定チームには1人の開発者も参加していました。彼は私たちが規制の詳しい情報にアクセスするのをとても簡単にしてくれました。議論しなければならない規制がたいへん多かったのです。彼は、それらの規制に関する情報を表示できるように整理してくれたので、何かを探そうとしたときに人々が机で待たなくてよかったのです。事前に行うことができる、いくつかのとても簡単なことで、DtoDセッションがとても効率的になるように確実にできます。
藤井－ 分かりました。
オプションボード
藤井－ 事前ビューと現在ビューのように異なるビューでは、プロダクトオプションの粒度が異なるということは理解していますが、この場合オプションボードはビュー毎に分けるべきでしょうか？
用語注：オプションボード
ビジョン、目的、目標の達成に寄与すると期待できる3つの価値観点と、プロダクトオプションを7つの側面で書き出す（描く）ためのボード。優先度の高いオプションに星印をつける。
メアリーさん－ さて、これは素晴らしい質問ね。全体ビューに対しては、これから述べるオプション１つです。
用語注：全体ビュー
全体ビューは、DtoDの3つのビューの1つであり、複数のリリースを対象にする。全体ビューでは、複数のリリースに渡ってソリューションをどのように発展させるかを検討する。
藤井－ ロードマップですか？
メアリーさん－ ロードマップでは、上の人たちがどんなものかが分かり、基本的に記憶し、組織によっては１年間残ってほしいものです。ある種凍結すると言ってもよいかもしれません。
チームがリリース計画策定の作業を行っている時には、チームはオプションボードを立てます。昨年、あるグループでこれから述べることを行いました。青いテープを取り上げて、青いテープを水平にオプションに貼り付けただけです。事前ビューのすべてのオプションがありましたが、青いテープの下には、特定のスプリントにおいて注目する価値の高いオプションだけを示したのです。こちらとあちら、右と左というように、2つの別々のボードを持つ代わりに、上と下に配置したのです。事前ビューのいくつかのモデルは、丸で囲んで「よし。事前ビューのこの部分をここから現在ビューに落とし込もう」と言いました。それらが見えることは助けになりました。上位レイヤーがここにあり、その下位レイヤーがここにあったのです。
藤井－ なるほど。面白いですね。
藤井－ プロダクトの開発サイクルを通じて、それらのオプションボードを更新すべきなのでしょうか？
メアリーさん－ これは本当に厳しい質問ですね。よく悩むのは、チームが同じ場所にいないとそれでオプションボードがさらに複雑になるということです。チームが同じ場所にいない場合、私たちはアジャイル流を好むので、誰かにオプションボード上のものをコピーしてもらい、それをなんらかのツールなどに入れさせたくはありません。私たちが求めているのは価値が高く、価値が高いと星印を付けたオプションです。
藤井－ そうだと思います。
メアリーさん－ これにより作業のスピードが上がり得ます。時々、少し掃除しなければならないことがあります。時として、チームへの支援を依頼された際に、チームからバックログに300箇のストーリーがあると言われることがあります。700箇を越えるストーリーがあったチームもいました。それらのストーリーを掃除することが私たちの仕事ではなかったので、これはとてもとても大変でした。これは、私たちがDtoDを実行する際に行いたいことと正反対です。ストーリーを書くだけのためや、より多くのストーリーを得ようとするためにストーリーを書きたくはありませんよね。オプションを理解して、ストーリーに対する価値の高いオプションだけを選びたいのです。
更新に関して言えば、星印がないオプションはそこに放置します。重要ではないからです。それらはプルされません。だから、ある程度取るに足らないのです。消すことになります。十分に重要であれば、復活するでしょう。そのまま残し続けようとすることはあまりないでしょう。残し続ければ「あぁ、これらの価値の低いオプションを管理しなければならないんだ」と繰り返し言う羽目に陥るからです。求めているものは価値だけであり、管理し、注目するものも高い価値です。時として、これを行うのが難しい人たちもいます。そのような人たちは、「おぉ、これをここに残さないと忘れてしまうよ」と言います。
繰り返しになりますが、これはチームの成熟度次第だと思います。私は、成熟度をチームがプロダクトをどの程度知っているかという意味で使っています。チームがプロダクトに通じていなければ、チームはより神経質になるでしょう。そうであれば、「これらすべてを残さねばならない」となるでしょう。
藤井－ 分かりました。
大規模アジャイル開発でのDtoDの活用
藤井－ 次の質問は、DtoDを複数のチームから成るような大規模アジャイル開発に適用することは可能かというものです。
メアリーさん－ その場合が、横断的な側面を理解しなければならない場合です。横断的という言葉により、環境について考えると、大規模なアジャイル開発でもチーム毎に環境が異なることはありません。それらのチームは、同じ開発環境、同じインフラを使わなければなりません。調達者にとって許容できる性能かどうかを知っていれば、品質特性も同じでなければならないという場合も多いでしょう。これらにおいて、特定のチームだけ別にはなりません。これが標準になるのです。それを明らかにし、共有し、理解するのです。
大規模チームにおいて、もう１つの非常に大事な側面はデータです。これらの異なる側面を横断したデータを理解しているかということです。ある種の制御という人たちもいます。そのため、回答は「適用可能」ということになります。それらのチーム間で共有することを明確にすれば、それらを重複したり、もっとひどい、衝突を免れるでしょう。それは、チーム間での環境がばらばらという状態です。
藤井－ 各チームはチーム毎にオプションボードを持つと理解していいのでしょうか？それでも、側面によってはそれらのオプションボード間で共通するものもあるのではないでしょうか。
メアリーさん－ そうです。事前ビューがあったとします。ここに事前ビューがあり、複数のチームが一緒になっていくつかのフィーチャーを作ろうとしているとします。そうであれば、スクラム・オブ・スクラムズとまったく同じです。オプションボードを立ち上げ、各チームの代表者が一緒に1つのオプションボードに向かい、共通なものを識別します。例えば、このプロダクトと4つのチームがあるとします。これらのチームは同時に作業を行わねばなりません。アクションやユーザーオプションのためであることが多いでしょう。あるグループは特定種類のユーザーに対応するかもしれません。
もう1つの分割方法として、いくつかのフィーチャーがあるとします。このチームはフィーチャーXを担当します。このチームはフィーチャーYを担当します。これらのチームで共有しなければならないのは、フィーチャーXとYを使う同じユーザーかもしれません。多くの場合、先にお話ししたようにデータを理解することはとてもとても大事です。「発見から納品へ」のセクション6に簡単なテクニックが記されています。相互作用マトリックスと呼ばれるものです。もちろんご存知ですよね？
用語注：フィーチャー
プロダクト（ソフトウェア）に対するストーリーよりも高いレベルの要求のこと。
藤井－ はい、CRUD表とも呼ばれています。
用語注：相互作用マトリックス、CRUD表
機能とエンティティーとの間の関係を作成(Create)、参照（Refer）、更新(Update)、削除（Delete)の4種類の関係で分類した表のこと。
メアリーさん－ その呼び方を好まない人たちもいるので、私たちは相互作用マトリックスと呼んでいます。特定の環境で、簡単なテクニックでチームを横断して「いいかね。そのデータを作るのは誰で、読むのは誰で、更新するのは誰だね」と言うだけです。これらのチームを横断して、とても大事な統合を行わなければなりません。これは、活動やアクションを考えるための助けにもなります。横断的に共有すべきものを見つける機会は複数あります。チームが最大限理解し、行わねばならないことに長じることができるようにするのです。
藤井－ 分かりました。
DtoDとサービスデザイン思考について
藤井－ 次の質問は、DtoDとサービスデザイン思考の間にどのような関係があるかというものです。
メアリーさん－ そうですね、素晴らしい質問です。サービスデザイン思考は顧客に焦点を合わせているので、ユーザー側面と考えることができます。これをさらに広げて、それらのユーザーがアクションにおいて持つインターフェイスを知りたいと思うかもしれません。それを認識し、そのカスタマージャーニーマップを描き、その種の背景調査を行うことができます。すべて、私たちも使うことができる素晴らしいテクニックです。顧客に非常に注目しており、そして相互作用するためのシームレスな方法を持っているのです。
サービスデザイン思考に欠けているのは、制御やルールのようなものかもしれません。サービスデザイン思考を行う場合に、通常それらを見つけません。環境について考え始めるかもしれませんが、品質特性を同じようにはオプションとして挙げないでしょう。顧客と顧客の体験についての非常に重要な洞察ですが、ソフトウェアの構築についてではありません。突き詰めると、DtoDで識別できるのは動くソフトウェアを納品するための価値の高いオプションなのです。
あなたと私が数か月前にメールをやり取りしたように、これら2つには相互にメリットがあると考えられます。サービスデザイン思考は、7つの側面のすべてを通じて様々なオプションを考えることでDtoDの恩恵を受けることができます。DtoDフレームワークは、突き詰めるとサービスデザイン思考でとても重要な顧客のタッチポイントを共同でデザインできるという点で恩恵を受けることができます。それらの間に相乗効果があります。
アジャイルの観点で難しいと思うのは、どれくらい早期にサービスデザイン思考を行い、どの時点でそれを止めるかという点です。UXとまったく同じです。実際のオプションを調査する前のどの時点かに行わねばなりません。「発見から納品へ」のセクション5にそのような考察が書かれています。行わなければならない事前準備が記してあります。両者を組み合わせると、とても強力です。
藤井－ DtoDとサービスデザイン思考を一緒に使っているような事例をご存知でしょうか？
メアリーさん－ いえ、現時点では知りません。私たちは、とても洗練されたUXを持つ多くの組織と仕事をしています。人々とUXとサービスデザイン思考は、とてもとても近いものです。世界でも大きな金融機関には、行動科学や工学の博士号を持っている人たちが実際にいますが、その人たちは自分たちのプロダクトを構築する際に顧客との相互作用や、自分たちがどのように目標を達成するかについてとてもとても明確に仕事をします。
私は、サービスデザイン思考が一般的な用語かどうか分かりません。しかし、実際に行われてきた作業の中では実践されているのではないかと思います。DtoDで私たちがお手伝いしている組織で、顧客やタッチポイントがすでにある程度探られていれば、そのような作業の多くを行おうとするのは、それらを組み合わせたいからです。こんな状況にはいますが、時として（サービスデザイン思考という）名前で混乱するのだと思います。
藤井－ そうですか。サービスデザイン思考はそんなに新たなものではなく、新たにブランディングしたものと捉えたり、組織によっては従来から使っているテクニックだったりしますよね。
メアリーさん－ そうです。（サービスデザイン思考の）書籍でさえ、書籍の内容の多くはこれらの異なるテクニックに割かれています。それらを一緒に見れるのはとてもよいと思いますが、時としてそれらの多くはすでに使ってきているものだったりします。
藤井－ よく分かりました。
DtoDとザックマンフレームワーク
藤井－ もう2点質問があります。そのうち1つは、私が最近、要求開発アライアンスというコミュニティーでDtoDの紹介をした時のコメントに関するものです。それは、DtoDのプロダクトオプションの7側面とザックマンフレームワークは似ているのではないかというものだったのですが、いかがでしょうか？
用語注：ザックマンフレームワーク
ジョン・A・ザックマン（John A. Zachman）が考案したエンタープライズアーキテクチャーを整理するための枠組みのこと。
メアリーさん－ それはお世辞ですね。私は、20年ほど前にザックマンフレームワークを使っていたのを記憶しています。私たちが、書籍の執筆を始めた際にザックマンフレームワークを意識していたとは言えないと思います。その点を調べたこともありません。しかし、エレンも私もIT分野での経験が多いので、両者に対応するものが多いことは確かだと思います。
過去参加したカンファレンスの1つでザックマンさんにお目にかかる機会がありましたので、このことを少しお話しました。あなたがサービスデザイン思考についてお話したように、私たちが行っていることの側面をおそらくより革新的な方法でなんらか整理できるようなものだったのだと思います。現在の世界やアジャイルにもっと適切なものかもしれません。本当に新しいというものはないのではないかと思います。それを如何に活用し、如何に究極的により良いコミュニケーションをとるかということです。
藤井－ 分かりました。
日本の印象
藤井－ 最後の質問は、これまでの質問とまったく異なるものです。メアリーさんは今回初めて日本に来られたと思いますが、日本にはどのような印象を持たれたでしょうか？旅行を楽しまれましたか？
メアリーさん－ 素晴らしいものでしたし、文化にとても感銘しました。あと、ご存じのように私の夫は芸術家です。私たちは、美しいものの価値を認める人たちのいる文化のある場所を訪れるのが大好きです。これまで楽しい時間を過ごしましたよ。また来たいですね。人々もとても親切です。もっと暖かい時候にぜひまた来たいです。少し寒かったので。東京はとても大きな都市です。とても大きい。エネルギーもあります。私はエネルギーを感じることができます。素晴らしいわ。
藤井－ 今日は長時間にわたるインタビューにお付き合いくださいましてありがとうございました。
最後に
本インタビューを実施したのは、2015年3月2日でした。インタビュー当日の午後、メアリーさんはRegional Scrum Gathering Tokyo 2015で招待講演をされた後に品川に戻り、夜に本インタビューを実施しました。慣れない外国での基調講演の疲れをみじんとも感じさせず、エネルギッシュに質問に回答して下さったメアリーさんの姿が印象的でした。
参考文献
[1] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプロダクトの計画策定と分析, BookWay, 2014
[2] DtoDに基づくアジャイル要求入門：https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroDtoD/
[3] DtoDの紹介ビデオ(日本語)：https://www.youtube.com/watch?v=YF0Kv4bRKbI&feature=youtu.be (短縮URL: https://youtu.be/YF0Kv4bRKbI)
[4] 「アジャイルな発見プラクティスを革新し、活性化させましょう (Innovate and Invigorate Your Agile Discovery Practices)」の講演資料：https://www.ogis-ri.co.jp/pickup/agile/docs/RSGT-Gorman-Jp.pdf