発見から納品へ~アジャイルなプロダクトの計画策定と分析~ を読んでみた
目次
- はじめに
-
Discover to Deliverって何？
- 書籍の内容まとめ
- 所感
はじめに
ビジネスの仮説検証のサイクルと、SW開発のサイクルの同期と結合について興味があったので、この本を読んでみました。
感想は、、、字が大きくて読みやすいです。
特にコアとなる２章、３章、４章は丁寧に説明されています。
また、ツールも多く紹介されており、ここからさらに広がると思います。
しかし、、、、
ちょっと分かりづらいところもあります。。。
要求を洗練し、結果から学びを得るプロセスと、計画を詳細化するプロセスの２つの時間軸があるからややこしいのかなぁ。。。
プロセスのIN、OUT、活動が分かりづらい。
登場する用語間の関係がわかりづらい。
さらに、事例で出てくる会社名や人物名も難しい。
これは僕の頭のせいかもしれないけど。
３回ほど読み返して、マインドマップにまとめて、やっと半分ぐらいわかってきました。（マインドマップの画像は、本ブログの最後に掲載しています。）
ということで、せっかく読んだので備忘録的に内容をまとようと思います。
まだ理解が追いついていないので、まとまりの無い文章になっています。
あらかじめご容赦ください。
もし、アドバイスなどありましたら、メールなどで直接かつコッソリと教えて頂けると幸いです。
また、本ブログには書籍の内容をまとめますが、Discover to Deliverの学習には 書籍以外にもオージス総研さんの文章や紹介ビデオを参考にしました。
（D to Dはオージスの藤井さんに教えてもらったのがきっかけで勉強したのでした）
参考文献へのリンクは許可を得ていないので掲載しませんが、ググればすぐに見つかります。
オージス藤井さんからお許しを頂きましたので、下記、オージスさんが公開されている資料へのリンクを掲載します。（2016/05/07）
「DtoDに基づくアジャイル要求入門」のHTML版とPDF版
http://www.ogis-ri.co.jp/otc/
http://www.ogis-ri.co.jp/
『書籍「発見から納品へ」の著者メアリー・ゴーマンさんへのインタビュー』
http://www.ogis-ri.co.jp/otc/hiroba/specials/MaryGorman/
一応、本家のURLも掲載しておきます。
http://www.discovertodeliver.com/
ただし、このブログでは書籍に記載してあることをベースに記載します。
なので、参考文献とは少し異なる見解があるかもしれません。
それは、きっと私の理解が追いついていないからなのだと思います。
（なお、本ブログに掲載している写真は全て「発見から納品へ:アジャイルなプロダクトの計画策定と分析」を撮影したものです。）
Discover to Deliverって何？
Lean Startupでいう「価値の仮説」と「成長の仮説」のうち、価値の仮説を対象としていると理解しました。
そして、価値のビジネスゴールを満たすために、プロダクトを持続的/継続的に成長させるためのフレームワークだと、理解しました。
Discover to Deliver (以降、D to D)の理念として、発見と納品の作業を組み合わせ、利害関係者が協調し、継続的にプロダクトを進化させるというのがあります。
このことから、利害関係者間での継続的な意思決定のフレームワークだとも言えると思います。
アジャイルチックにいうと、プロダクトバックログの作り方っていう方がしっくりくるかもしれません。
書籍の内容のまとめ
D to Dでは、ビジネスゴール（成果：ビジョン、目的、目標）を達成するためにプロダクトに求められる要求を、『構造化された会話』というフレームワークで特定します。
本ブログでは『構造化された会話』を用いた要求分析と洗練、計画へのマッピングのプロセスについて記載します。
なお、書籍にはフレームワークを実施する際の適応方法（５章）や、たくさんのプラクティスやツールについて（６章）も記載されています。
興味のある方はぜひ書籍をごらんください（宣伝しても僕にはメリットはありませんが）。
構造化された会話とは
D to Dでは、協調する利害関係者を顧客、業務、技術に分け、パートナーと呼びます。
これらのパートナーが構造化された会話というフレームワークを用いて、プロダクトに対する共通認識を持ち、検討し、要求と実施時期を決定します。
構造化された会話とは、調査、評価、確認のサイクルを繰り返すフレームワークで、D to Dのコアです。
パートナーは、プロダクトの発見から運用、教育まで、プロダクトライフサイクルが続く限り、構造化された会話を用いてプロダクトを継続的に成長させなければいけません。
下記２つの写真（特に下の方）が、D to Dのコアをよく表しています。
（書籍の写真を勝手に載せましたが、良いのかなぁ。。。怒られたら消します）
構造化された会話を調停し、最終的な意思決定を行う役割として、プロダクト擁護者という役割が置かれています。
プロダクト擁護者は、業務観点のメンバーであり、SCRUMでいうとProduct Ownerに相当します。
具体的なフレームワークの内容
それでは、『構造化された会話』に沿った要求分析と洗練、計画作成の流れをまとめてみます。
先の写真の通り、構造化された会話は「調査」、「評価」、「確認」で構成されています。
【調査】
各パートナーは成果（ビジネスゴール）をインプットとして、事実情報やサービスデザイン思考などの手法を用いて、プロダクトに求められる価値を考えます。
そして、その価値（目的）を達成する手段としてプロダクトオプションを考えます。
プロダクトオプションとは、潜在的なプロダクトへのニーズです。
D to Dではプロダクトオプションを考える際に、プロダクトを7つの側面で捉え、それぞれの側面について検討します。
プロダクトの７つの側面とは下記です。
- ユーザー：プロダクトと相互作用するターゲット
- インタフェース：プロダクトがユーザーやシステム、デバイスと相互作用する接地面
- アクション：プロダクトがユーザーに提供する機能
- データ：プロダクトに含まれる情報のリポジトリ
- 制御：プロダクト施行する制約
- 環境：プロダクトが適合する物理特性とプラットフォーム
- 品質特性：運用と開発が的確かを評価する基準となる特性
これら７つの側面は互いに関係しています。
例えば、ユーザーはインタフェースを通してプロダクトと作用しますし、アクションはデータにアクセスします。
書籍では、これら７側面の関係を可視化するツールとして「プロダクトの７側面のキャンパス」を紹介しています。
調査を通して、各パートナー毎の価値とプロダクトオプションが明らかにになりました。
【評価】
次に、各パートナーが求める価値（価値観点）を用いて、「調査」で定義した各プロダクトオプションを評価します。
プロダクトオプションの評価は、リスクや利点、依存関係を考慮した上で、プロダクトオプションの相対的な価値を比較し、判断します。
この「評価」を通して、各パートナー観点の価値や考え方を互いに共有することができます。
ちなみに価値とは、受取手（買い手）が対価や時間などのリソースと交換しても良いと判断するものです。
そして、顧客に対して価値の高い複数のプロダクトオプションのまとまり、凝集性の高い機能と使いやすさを提供する実現可能なオプションの組み合わせを考え、ビジネスゴールに対して確度の高い「ソリューション候補」を決定します。
評価の最後に、これらのソリューション候補を計画にマッピングします。
注）僕の理解では、『ソリューション候補』とはリリースするバージョンのテーマのことじゃないかと思います。つまり、プロダクトオプションはPBI(Product Backlog Item)で、ソリューション候補は『優先順位付けされたPBIのうち、特定のリリースに含むPBIをまとめたもの』じゃないかと思います。
ちなみに計画は次の３種類があります。
- 全体ビュー（ロードマップ相当）
- 事前ビュー（リリース計画相当）
- 現在ビュー（イテレーション計画相当）
なので、プロダクトオプション（要求）と受け入れ基準も、マッピングされる計画に応じて詳細度が異なります。
全体ビューではFeatureレベルですが、事前ビューではストーリーレベルになり、現在ビューでは受け入れ基準も含めて詳細で、工数付けされたストーリーになります。
つまり、プロダクトバックログには３つの計画ビューにまたがる要求（プロダクトオプション）が混在した状態になります。
【確認】
評価で決定したソリューション候補は、ビジネスゴール（成果）を満たす価値があると考えられた「仮説」 です。
この仮説が正しい事を検証し妥当性確認するために、受け入れ基準を用います。
納品前には、各パートナーの期待を満たしているかを受け入れ基準を用いて検証します。
そして納品後は、顧客の正しいニーズを満たし、ビジネスゴール（成果の目標）を達成しているかを妥当性確認します。
この結果から得た学びをフィードバックとして、プロダクトの継続的な成長につなげます。
このように、『構造化された会話』の調査、評価、確認のサイクルを通して、プロダクトを継続的に成長させるフレームワークがD to Dです。
ところで、僕は『構造化された会話』のフレームワークは必ずしも調査、評価、確認の順番で実施する必要はないのだと理解しました。
例えば『確認』という活動は、調査、評価のあとに必ず実施するものではなく、調査と評価を何度か実施した後に、１度だけ実施しても良いのだと思います。
もちろん、順番に行っても良いです。
所感
良いと思ったところは2つあります。
1つは、"パートナー"として開発サイド以外のメンバを明確にプロダクトライフサイクに巻き込んだことです。
もう１つは、ビジネス価値を起点とした要求分析のプロセスを示したことです。
まずは、１つ目。
パートナーについてです。
D to Dでは、ビジネス側（業務）の人も要求分析やAcceptance Criteria（受け入れ基準）の定義、計画に責任を持つようになっています。
パートナー間で協調して意思決定しなくてはいけませんので、業務の人は顧客（マーケティングや企画）の意見だけではなく技術（開発）の意見にも耳を傾けなければなりません。
その上で、ビジネスゴールに対して値打ちがあり、技術的にもROI的にも実現可能であることを合意した上で、開発に及ぶ意思決定を行わなければなりません。
そのため、開発者は実現技術や選択する技術の制限/制約、工数について、ビジネス側の人が理解できるように説明しないといけません。
ビジネス側の人はそれを理解しないといけないません。
これが協調作業で、共通認識を作るってことですね。
一方、開発側は単に要求を鵜呑みにするのではなく、ビジネスゴール、および、顧客やビジネス側の人が考える『価値』を十分に理解しなければいけません。
そのために、御用聞きのように要求を聞いているだけではなくビジネスゴールを達成するための本質的な課題を、顧客やビジネス側の人と一緒に考え、合意します。
このプロセスを通すことで、開発者は要求の真意を把握することができ、ビジネスゴールを意識した開発につながると思います。
もう１つは、要求分析のプロセスについてです。
これまで、ストーリーの表現方法や記述時の観点は形式化（3Cやユーザーストーリーカード、アジャイルモデリング等）されてきました。
また、ウィガースが言うような要求工学分野の手法やプロセスもありました。
ソフトウェア要求 : Karl.E.Wiegers, 渡部 洋子 : 本 : Amazon.co.jp
しかし、ビジネスの仮説検証とSW開発の仮説検証の全体を意識した上で、要求分析のプロセスを具体的に語ったフレームワークは珍しいんじゃないかと思います。
具体的にいうと、プロダクトオーナーの仕事の進め方を具体的に示したメソッドやフレームワークは少ないんじゃないかと思います（無知なだけかもしれませんので、誰か知ってたら教えてください） 。
そういう意味で、このフレームワークは参考になると思いました。
最後まで読んで頂き、ありがとうございました。
誤字脱字あればすいません。
また、認識がおかしいところやご意見があれば、メールなどでこっそり教えて頂けると幸いです。
