「発見から納品へ：アジャイルなプロダクトの計画策定と分析」 [1]という書籍の著者の１人であるメアリー・ゴーマンさんがRegional Scrum Gathering Tokyo 2015での招待講演やトレーニングの実施のため、2015年3月に来日された際にオブジェクトの広場編集部が実施したインタビューを前後編の2回に分けてお届けします。前編では、「ユーザーとその要求を理解する」というテーマで大西がお聞きした内容と、「DtoD (Discover to Deliver) [2], [3]の実践」というテーマで藤井がお聞きした内容を紹介します。
ユーザーとその要求を理解する
ユーザーと遠く離れた場合の要求把握方法
大西－ 私は技術者であり、私の役割はプロダクトに新しいフィーチャー（機能）を追加することです。私は、ユーザーにとっての価値を議論する打ち合わせに時々参加しなければならないのですが、私は通常、実際のユーザーからは遠く離れており、ユーザーの実際の要求や価値をあまり知りません。どうやったら、私がユーザーにとっての価値を見つけるプロセスに関与できるのでしょうか？関与するための、より良いプロセスがあるでしょうか？あるいは、機能追加や、ユーザーにとっての価値を知っている人達と連携することに専念すべきでしょうか？
メアリーさん－ だれがお客様ですか？
大西－ 空港、学校、病院などの内線システムを作っている会社です。この内線システムをインターネットにつなぎ、リモート制御や監視を行っています。そのため、実際のユーザーは、空港、学校、病院などで働いている人達です。
藤井－ 彼はIoTのプロジェクトに携わっています。
用語注：IoT
“Internet of Things"の略。インターネットに接続された機器とクラウドなどを経由した通信で制御やデータ収集を行うシステムのこと。「もののインターネット」と呼ばれることもある。
メアリーさん－ IoTということは機械と機械が連携し合うようなシステムですね。
まずユーザーのペルソナを作成したらよいかもしれません。ペルソナは知っていますよね。典型的なペルソナを理解するために、ユーザーが行うこと、教育レベル、技術に対する経験を考えます。それにより、彼らがどんな人達であるか頭の中で想像する上での助けになります。
理想的には、現場に行き、少数のユーザーにインタビューし、彼らがシステムを使う様子を観察する方が良いかもしれません。その一環として、ユーザーの価値に対する感覚を得ることができるかもしれません。それは時として単に「自分達の仕事をもっと楽にしたい」とか「私は間違いを犯すのが怖いので間違いを犯したくない。私を守って欲しい」ということかもしれません。これらは定量的に測れるものではありません。しかし、それを理解すれば、あなたの設計に徐々に良い影響を及ぼすでしょう。このプロダクトを使うであろう人達を理解することは本当に助けになります。それを学ぶために可能なことを行えば、ユーザーがフィーチャー（機能）を必要とする理由を理解し、そのフィーチャーを使う目的が理解できます。
私たちは、人間が介在しない状況でもDtoDを実際に使ったことがあります。システム間連携のようなものです。その場合に、我々が立ち戻ったのはシステム間のインターフェイスがある理由でした。時として、どこかにある人がいて、その人が何かを必要としていることを突き止めるのに1つ、2つレベルを遡らなければなりません。それらの断片すべてをつなぎ合わせなければならないのです。それで、我々がプロダクトを作らねばならない理由の基本的な理解に遡れるのです。この説明がお役に立ったかどうかわかりませんが。
用語注：DtoD
"Discover to Deliver"の略。「発見から納品へ：アジャイルなプロダクトの計画策定と分析」という書籍で提案されたアジャイルな計画策定と分析のためのフレームワークを意味する。
大西－ はい、参考になりました。
メアリーさん－ もう1つは、バリューストリームマップを描くという方法です。バリューストリームマップを御存じですか？
用語注：バリューストリームマップ
顧客から注文や依頼を受けた以降、注文や依頼されたものを納品するまでの一連の作業の流れを図で表したもの。各作業の実行時間に含まれる価値を生み出すための時間とそうでない時間を明らかにすることで、注文や依頼から納品までのサイクル時間を短縮するための手がかりを得るために用いる。
大西－ はい、名前は知っています。
メアリーさん－ そうですか。バリューストリームマップについてあまり堅苦しく考えてなくても大丈夫です。特別な記法も必要ありません。
編集部注：
バリューストリームマップの話はこの先でいったん途切れ、2つ先の見出しのところで復活します。
ユーザーの理解が大事
メアリーさん－ あるソフトウェアを作ろうとした人達についてお話をしたいと思います。そのソフトウェアは、全面的にデータ分析のためのものでした。その開発者たちは、データウェアハウスと分析を作っているだけだと思っていましたし、そのことにチームが専念していました。開発者は全員どのようにデータを格納し、それらをどのように出力し、性能その他のことに関心を寄せていました。そこに、プロダクトオーナーを招いたのです。プロダクトオーナーは3名おり、彼らへのヒアリングを通してソフトウェアには2種類のユーザーがいることが分かりました。1種類目のユーザーは新規に採用された分析者であり、業務経験はありませんでした。そして、2種類目のユーザーには15年間の業務経験がありました。
あるユーザーが15年間業務を経験しており、別のユーザーが未経験ということを、なぜ配慮する必要があるのでしょうか？開発者がデータ問合せのインターフェイスをデザインする際に、15年間の業務経験を持っているユーザーは、データを熟知しており、結果を即座に表示する以外のことは必要ありませんでした。新たに採用された人は、翌年副社長になりたいと思っていました。このユーザーは自分が欲しい結果を得る最もシンプルな方法を望んでいました。15年の業務経験を持つユーザーにとっては不要な支援を必要としていたのです。プロダクトオーナーは、第1リリースでどちらのユーザーをサポートすべきかを選択せねばなりません。それが転換点(pivotal)になります。これが、計画策定で劇的な違いを生みます。その日の前日までは、そのようなことを全然分かっていませんでした。このプロダクトを使わなければならない病院の人達のことを知りませんでした。このようなことが、本当に助けになりえるのです。
バリューストリームマップの終端を認識する
メアリーさん－ 私の（バリューストリームマップの）話が終わって無くてごめんなさい。ソフトウェアを作ろうとしている人達のバリューストリームマップの話に戻ります。
プロダクトオーナーが2人、開発者が2人の2チームに対してワークショップで意図的に同じバリューストリームマップを描いてもらったことがあります。両チームとも、バリューストリームマップが分析者のところで止まっていたのはおもしろかったです。まさにそこだったのです。分析者は政府からデータを入手し、分析環境を作り、そのデータを分析します。でも、そこで終わりではないのです。最終的には病院の管理者と役員にデータが渡り、彼らが決断を下すのです。最終決断を行う人達まで届くソフトウェアではありませんでした。分析者がプロダクトを使ってすべての作業を行い、管理者と役員にアドバイスを行わなければなりませんでした。
これがバリューストリームマップです。そうですよね？これでソフトウェアの作り方は変わったでしょうか？残念ながら変わりませんでした。開発したものは変わったでしょうか？ある程度変わりました。確実に分析者がより速く仕事を行うために十分なものを提供しなければならなかったのです。次に述べるような判断を行わねばなりませんでした。データ構造をどのように組織化し、データウェアハウスをどのように構築するかということですが、分析者を知ることでそれらを調整しなければなりませんでした。それはおかしな話です。この人達全員がバリューストリームマップの本当の終端を認識していなかったのです。
繰り返しになりますが、サービスデザイン思考のようなツールはこのような状況での助けにはならないでしょう。サービスデザイン思考は、このレベルまでバリューストリーム全体を鳥瞰させてくれないでしょう。サービスデザイン思考は、顧客のタッチポイントを明らかにし、病院の分析者はそのタッチポイントに触れるかもしれません。しかし、次のレベルまでは到達できないのです。
大西－ ありがとうございました。
大事な問題に気づくためには
大西－ 基本的な質問ですが、私たちはより詳細なレベルの問題や性能のような問題に対処しているので、最も大事な問題がなんであるかを見失う場合があります。最も大事な問題にどうしたら気付くことができるのでしょうか？
メアリーさん－ 明確に定義された目標はあるでしょうか？
大西－ 目標はあります。
メアリーさん－ 測定可能な目標はあるでしょうか？
大西－ お客様にはビジネス目標があると思うのですが、我々の同僚はそれを知りません。
メアリーさん－ これはよくある状況です。テスト担当者、QA担当者が目標を聞いたことがないという例をお話しました。DtoD本のビジネス価値モデルで、右上にはビジョン、目的、目標で構成されるビジネスモデルがありますが、含めなかったものもあります。ここには、リスク、仮説、費用が記されるべきです。これらすべては、あるオプションが他のオプションよりも重要であるかを判断するために用いられるものです。それらのオプションは（ビジョン等に）整合し、特定の測定可能な目標に関連づけられなければなりません。
そのため、最低限、測定可能な目標があるべきです。また、明確に定義されたリスクがあるべきです。さらに、費用に対する感覚があるべきです。そうですよね。それらが判断の頼りになるでしょう。5つのオプションがあるとしましょう。これらのオプションの中で、このリリースの目標を達成する助けになるのは1つか2つかもしれませんよね。これが価値です。説明がややこしくなったらごめんなさい。ビジネス目標と技術的な側面とのバランスを取らねばなりません。技術的負債という表現を使いますか？
用語注：オプション
プロダクトを構成する要素の選択肢を意味する。例えば、プロダクトが備えるべきと考える機能の選択肢はプロダクトオプションである。DtoDでは、機能を含む 7 つの側面でオプションを考え、それらのオプションの中で優先度が高いものをプロダクト擁護者という役割の人が選択する。
大西－ 使います。
メアリーさん－ そうですか。ビジネス側の人はビジネス価値がもっとも高いという理由で、オプション4を選択するという場面で技術的負債を理解しなければなりません。これをリリースで使いたいという場合です。リードアーキテクトは、「申し訳ありません。これをやるとなると、それをもっと後に調整しなければなりません。これを開発するための準備がまだできていません。しかし、これが大事だと思われるのであれば、それは私たちが将来負債を返済しなければならないということになります」と言うでしょう。
価値を考えるのは、より難しくなりますよね。ビジネス価値があります。技術的な価値を考えると、そのオプション4を待った方がよいかもしれません。ビジネス側の人が「競争、または法規制のためにこれを今作らねばならない」というのであれば、これは一緒に判断することになります。その結果、ビジネスと業務の人が、「コストとリスクを認識したが、他の要因も考えてこれを開発しようと思う」と言うことになるかもしれません。
これは大きな判断です。私たちが、透明性のある判断を下すための明確に定義された、なんらかの方法を持ちたい理由であり、これにより人々が後で「これらの要因のためにこの判断を下したのだ」と示して言うことができます。あるお客様で、信頼が取れていなかったために、この広範な判断を下した理由を文書化しなければなりませんでした。信頼が取れていなかったために、私が判断したのですが、その判断を弁護しなければならなかったのです。あなたの状況がこのようなものではないことをお祈りします。
大西－ ありがとうございました。
DtoDの実践
価値観点を理解するためのよい方法
藤井－ 価値観点は、DtoDの中心的な概念の1つだと理解しています。その一方で、新しい概念なのでその意味を理解するのに苦労する人達もいます。それらの人達が、価値観点をもっと理解するためのよいお考えや方法はありますでしょうか？
用語注：価値観点
価値観点は、開発対象のプロダクト、システム、サービスに対して顧客、業務、技術の立場の人達が得たいと思う価値を意味する。
メアリーさん－ 時として難しいですね。それらの人達が例を聞くことが助けになると思います。例えば、…ビジネス上のスポンサーを考えてみましょう。私たちは、それらの人達がビジョン、目的、目標を明確に述べているということをはっきりさせたいのです。知りたいことはそれらにつけ加わるようなものです。それは、往々にして本質的な側面になりえます。（会社の）評判を気にかけているかもしれません。評判を守ることは、目標や目的にはできないでしょう。価値観点は、本当は付加的な次元なのです。
用語注：目的、目標
ビジョンで述べたプロダクト、システム、サービスで達成したいビジネス上の目的と目標を意味する。目的は、達成したいことを定性的に表現したもので、目標は達成の有無を客観的に判断できるような定量的な目標である。
私たちがしたいのは、人々がそれを見つけるようにすることです。「なぜ」と問いかけることにより行う場合が多いでしょう。例えば、ある顧客について話をしているとし、その人が「そう、レポートが欲しい」と言ったとします。この人は管理職で「私にはレポートが必要なんだ」と言う場合です。これはフィーチャー（機能）だと思うので、「なんでレポートが必要なのですか？」と聞きます。それを受けて何回かやり取りを繰り返すと、その人たちが「そうだね、情報が必要なんだ」と言うので、さらに「なぜ情報が必要なのですか？」と聞くと、「タイムリーな判断を下したいからなんだ」ということが分かったりします。
藤井－ なるほど。
メアリーさん－ そうなので、価値観点は時としてより広く、プロダクト自身を越えた広がりを持ち得ます。もっとも良いアドバイスはとてもはっきりしていると思います。私たちにはビジネス価値モデルがあるのです。それらの上に、ビジョン、目的、目標があるのです。だから、それらの繰り返しではなく、それら両者が異なることを理解する必要があります。繰り返しになりますが、なぜをはっきりさせるように求めることで、別のレベルに至ることができます。
藤井－ 分かりました。価値観点は、フィーチャー（機能）と、ビジョン、目的、目標の間にあるものなのですね。例えば、「売り上げをX%増やす」というような目標があるとすれば、その目標を達成するために顧客に何か価値を提供しなければなりません。これが価値観点ですね。
メアリーさん－ ある意味ではそうです。あなたの例を使うとすると、次の四半期に売り上げをX%増やさねばならない場合、どのようにそれを達成するでしょうか。価値観点は、ビジョン、目的、目標と整合しているべきです。それらに結び付かないものを出したいとは思わないでしょう。フィーチャー（機能）は、目的と目標を達成するための手段なのです。
あまり良い回答ではないように思いますが、実際のプロダクトを相手にすると、人々が口に出したり、そのように表現しない場面に遭遇します。それは、管理職がコストに敏感で何か確実なものを欲しがるような時です。
価値観点のもう１つの例として、コールセンターで、ある業務に従事している人を支援するプロダクトを作ろうとしている場合を考えます。この場合の価値観点の1つは、「このプロダクトでより賢明だと思われたい」であるかもしれません。
藤井－ なるほど。
メアリーさん－ でもこれは目標ではありません。目的の主要な目標ではありません。フィーチャー（機能）ではありません。これは、個人がどう感じるかということです。そして、このように内在的で、しばしば分かりづらい要素がありますが、これを理解しないと、他の基準を満たすにも関わらず、「うーん、このプロダクトはあまり好きじゃないなぁ」と思わせてしまうようなソフトウェアを開発してしまうリスクを招いてしまいます。
とっても難しいので、私は全リリースでこれを行わなくてもよいと言います。価値観点を探すと、それらの価値観点は、リリース毎には変わらないかもしれない、人々のプロダクトの受け止め方を含んでいます。そうなので、そのような価値観点の理解に努力すると、その努力は報われます。時間とともに、その見返りが得られるでしょう。
プロダクト擁護者の教育
藤井－ 分かりました。次の質問に移りましょう。DtoDでは、プロダクト擁護者が重要な役割を果たすと考えられます。DtoDをうまく適用するためには、DtoDのなんたるかやDtoDではどのような種類のサイクルを経るかをプロダクト擁護者に教育した方がよいのでしょうか？
用語注：プロダクト擁護者
プロダクト擁護者は、スクラムにおけるプロダクトオーナーのように開発するバックログ項目の優先度を決める役割で、通常業務側の人（DtoDでは業務パートナーと呼ぶ）が担う。
メアリーさん－ 私たちの経験では、プロダクト擁護者がDtoDのなんたるかを一般的に理解することは有効です。プロダクト擁護者には、いくつかの備えが必要です。その1つは、プロダクト擁護者が業務と技術と積極的に連携し、しっかりとすべての声に耳を傾けねばならないということです。業務だけではダメです。どちらかと言えば、そのことを理解してもらい、投じなければならない時間を予期してもらうということだと思います。それは、どのような開発チームであれ、自分達が開発を進める際にプロダクト擁護者と話ができることを望むのと変わりがありません。
あなたの質問に対する具体的な回答だと思うのはプロダクト擁護者向けの例を持ち、その人達に7つの側面を見せることです。そして、その人たちのプロダクトに対して「これがユーザーの例です」とか、「これがデータの例です」とか、「これが制御の例です」とかを示し、これらがなんであるかを学ぶために一緒に検討しなければならないことを示すのです。表面的なレベルで基本的な種類の例です。
もう１つあります、拓さん。プロダクト擁護者がオプションを検討することを理解すると大きな助けになると思います。それらのオプションを調査し、それらの評価をリードしなければならないということに備えるという自分達の責務を理解してもらうということです。
藤井－ なるほど。
メアリーさん－ その責務を果たす方法を学ぶのを助けるのです。時として、1、2時間で説明できることもあります。私の経験では、半日程度のワークショップを開催し、プロダクト擁護者にも参加してもらえば、トレーニングを必ずしも受けなくてもよくなります。
ビジネス側の人で、業務分析を行っている人は通常自分達の経験を活用します。開発者やテスト担当者の何名かは、モデルを書くことになるのでトレーニングを受けます。プロダクト擁護者は、これらの人達が自分達の検討を助けてくれることを前向きに頼りにすればよいだけです。
チーム全体への教育として時として有効なのは短い振り返りです。どのように検討が進みましたか？問題があったのはどこですか？１時間程度作業を止めることができるのであれば、さらに進歩するための方法をいくつか見つけることができるでしょう。自分達が現在直面している課題をそれらの人達が正しく理解すれば、新しいことに取り組むことにさらに前向きになるでしょう。そこで、価値のスライスを考えるという経験をすることを導くのです。これは通常とても強力です。
用語注：価値のスライス
価値のスライスは、（ユーザー）ストーリーを意味する。プロダクトが価値を提供すると考えた場合は、（ユーザー）ストーリーはその価値を薄切りしたものと捉えることができる。
プロダクト擁護者の判断を速める方法
藤井－ 分かりました。私は、プロダクト擁護者の判断のスピードが少し心配で、それがDtoDのセッションのスピードに影響するのではないかと心配しています。プロダクト擁護者の判断をどのように速めることができるでしょうか？単にプッシュするだけでしょうか？
用語注：DtoDのセッション
7つの側面でプロダクトオプションを考え、優先度の高いオプションの組み合わせで開発対象の（ユーザー）ストーリーを考案するセッションを意味する。
メアリーさん－ そっと押してあげることだと私は思います。これらのセッションを進行する場合は、常に事前準備を行うことが前提になります。理想的には、2,3名の少人数で事前準備を行います。そのため、白紙からのスタートにはなりません。
藤井－ なるほど。
メアリーさん－ そうなんです。事前準備は、よく「ワラのモデル」という呼び方で言いはやされます。この表現を使いますか？「ワラのモデル」です。3匹の子豚のお話を知っていますか？
藤井－ はい、ワラの家ですね。
メアリーさん－ そう、ワラの家とレンガの家ですよね。事前準備は、ワラの家になることを意図しているのです。人々がその一部を取り上げて、変更したり、何でもできますよね。このモデルは、人々の出発点を提供し、DtoDセッションに備えるためのものです。これは、先に行う価値があります。7,8名の人達が集まっているので、すぐにそれらの人達の生産性が高くしたいですよね。
藤井－ そうだと思います。
メアリーさん－ これにより作業のスピードが上がり得ます。時々、少し掃除しなければならないことがあります。時として、チームへの支援を依頼された際に、チームからバックログに300箇のストーリーがあると言われることがあります。700箇を越えるストーリーがあったチームもいました。それらのストーリーを掃除することが私たちの仕事ではなかったので、これはとてもとても大変でした。これは、私たちがDtoDを実行する際に行いたいことと正反対です。ストーリーを書くだけのためや、より多くのストーリーを得ようとするためにストーリーを書きたくはありませんよね。オプションを理解して、ストーリーに対する価値の高いオプションだけを選びたいのです。
あなたの質問から少し外れてしまいましたが、チームがある程度の期間作業を行ってきたのであれば、我々ができることはせいぜいチームにすべてストーリーがあることを敬意を持って理解することという場合があります。それから、「それらから2,3ストーリーを選んでください」と言い、チームの他の人達に「これらのストーリーを取り上げ、それらがストーリーとして適切な種類であることを確認しましょう」と言ってもらいたいと思います。そのように私たちはセッションを開始します。セッションに、すべてのストーリーを持ちこみたくないからです。
質問を頂いたセッションを可能な限り効率的に実施するための方法に関することはいくつかあります。セッションが止まらないと困ります。そのためには、非常にはっきりとした区切りを設定します。なんらかのワラのモデルを用意します。その場に適切な人達に参加してもらいます。私は、ある不可欠な特定分野の専門家が欠席していることが判明した時に(DtoDの)発見セッションを実際にキャンセルしたことがあります。適切な人達がその場に参加しないと前進できません。それは失礼なことであり、時間の無駄です。
藤井－ 分かりました。とても参考になります。
メアリーさん－ よかった。
前編の最後に
インタビューの後編では、DtoDセッションの所要時間、分析者の役割、オプションボードの運用、大規模アジャイル開発へのDtoDの適用、DtoDとサービスデザイン思考の関係について伺ったお話を掲載する予定です。
参考文献
[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)