参加してからだいぶ時間が経ってしまったのですが、2019/1/17-18に開催されたGabrielle Benefieldさんの、「Outcome Delivery Practitioner研修」に参加しました。
こちらは次回のもので、残席わずかだそうなので、気になる方はお早めに！
Gabrielleさんには、Regional Scrum Gathering Tokyo©︎（RSGT） 2019の基調講演でもお話いただきました（ご本人の希望で、特別にビデオを公開しています）。
Moubious Loopとは？
Gabrielleさんが提唱しているOutcome Delivery（OD）では、「Moubious Loop」というフレームワークを中心にプロダクト開発を進めていきます。「メビウスの輪」になぞらえたこのフレームワークは、チームの地図であり、道しるべとなります。
Mobius Outcome Delivery | Outcomes over Outputs
Outcome Deliveryはオープンソースで、上記サイトでスタートガイドやツールがダウンロードできます。
左側が「ディスカバリーループ」。つまり「なぜそのプロダクトを作るのか？」、「そのバリューは何か？」、「その計測指標はなにか？」を作るフェーズ。右側が「デリバリーループ」で、実際にプロダクトを届けていくフェーズです。左と右の間にある「オプションピボット」では、プロダクトを実現するときに、たくさんある実現方法の中から、現時点で“最適そう”なものを選んで、実際に届けて結果を計測し、その結果から別の実現方法を採用するか、ディスカバリーループに戻るかを判断します。
メビウスループの各フェーズで使えるツールがあり、その中からプロジェクトに必要なものを選び、高速にこの学習ループを回していきます。
RSGTの動画でも出でくる（東京の路線マップみたいなやつ）んですが、今は、プラクティスなり、フレームワークなり、プロダクト開発をする上で、方法論は飽和状態にあって、それらの点をつなぐようにしてシンプルな形にしたのがOutcome Deliveryだそうです。
大事なことは、ディスカバリー（所謂ビジネス寄り）の話と、デリバリーが一体となっていることだと思っています。Gabrielleさんも研修中言っていたのですが、結局、間違っているものをいくら正しく作ったってダメだよね、というお話です。
もう一つ大事なことは、きちんと計測すること。これが難しい。研修でも、プロダクトに対する「計測指標」を考えるのですが、プロダクトの目的が「ユーザを幸せにすること」だったら、その「幸せ」をどう計測する？幸せでない状態ってどのようにしたら分かる？という話があって、さぁ、何をどう計測するか...（腕組み）みたいな感じになってしまいました。まぁ、今は様々なデバイスもあって、昔よりはデータが収集しやすくなっているのかなと思っていますが、それでも適切な指標を選択するのは難しいですね。
研修のアジェンダ
手書き可愛い。。
こんな感じで、メビウスループを一通り体験します。
研修のメモより
個人的に心にのこった箇所です。
“Agile looks productive. Agile is for building right thing. Agile has to be more simple.“
私の経験上でも、左側のディスカバリーの話が置いてけぼりにされているか、もしくは“ビジネス側”と言って分断されていたりすることが多くてもやもやすることが多かったので、そうそう！って心の中で何度も頷きました。
”Keep asking the idea.“
ここでいうアイディアはプロダクトのアイディアなんですけど、常に原点（ディスカバリーループ）に戻って、「このプロダクトで実現したかったことは何か？」を問い続けなさい、と理解しています。しかも、この「メビウスの輪」に表現されている通り、プロダクト開発って永遠に終わらないのですよね。いい意味で。
”Before we start to develop something, we have to understand “Why?.“ At least, understand who, problem (why) and some outcomes.”
始める前に「なぜ？」をきちんと理解しなさい、ということでした。ODの中にもツールはあるけど、インセプションデッキみたいなものでもいいのかなと。
“Output is easier to measure. Outcome is difficult to find good measurements.”
「アウトプット」は、機能や、ストーリーポイント、時間などで、主にデリバリーループで計測するもの。「アウトカム」は、プロダクトの成果だから、計測指標自体を定義するのが難しい。アウトプットは測りやすいからみんなそっちを計測したがるんだけど、本当に計測しなければならないのはアウトカムの方だよね、ということでした。ほんとそう。
“Delivery is not about software development. This is not only for software development.”
エンジニアとしては、すぐ開発したくなってしまうけど。。ペーパープロトタイピングしてみたり、仮説を検証する方法はいろいろあるよね、という話。大事なのは、仮説を最短・最速で検証できる方法を選ぼうってこと。
さいごに
2日間の研修でしたが、想像以上に疲れました。プロダクトの価値の大事さ、計測の重要さなど、プロダクト開発にあたって大事なことを再確認できた研修でした。
ソフトウェア開発の文脈で語られていますが、ソフトウェア開発だけでなく、比較的どのようなプロダクト開発にも適用できるのではないかなーと思います。
