Agile Leadership Summit 19 その1 (memo)
Agile Leadership Summit 19
運営委員として参加しました。
基調講演
瀬谷さんの紛争予防のお話し。
凄く良かった。
既存の組織や文化をどのように変えるか。
この点で規模や危機感の差はあるものの、既存組織のアジャイルリーダーが行う組織変革の参考になる事が多々ある。
紛争地において和解が万人に受け入れられる訳ではない。
一年後の幸せよりも明日生きられるかに関心があるひとに、中長期的な話をしても聞き入れてもらえない。
なので、まずは目先の課題を解決する。
和解を持ちかけても、家族を殺された人は受け入れない。
なので、初めは和解という言葉を使わない。
例えば、殴り合ったり殺しあったりするよりはマシなのでこうしよう、という提案をする。
農耕や加工など、技術を用いた支援を行い約束を守るという信頼を構築する。
小競り合いが起こった際に瀬谷さん達の教育を受けた現地の若者が仲裁を行う。
そうする事で、争いよりも話し合いの方が自分たちにメリットがある事がわかる。そうなると、自発的にやろうと言う活動になる。
飴と鞭を使い分ける
アフガニスタンでは司令官にVISAの発行や外国での医療享受を支援した。
一方で、期限を決めて部隊を解除する事を課した。
そして、司令官には自治体や政党を組織し、立候補する事を勧めた。
また、女性平等を訴え、大臣など権力のある方を呼んで女性平等を訴えてもらう。
これを繰り返すと、長老も女性平等な発言を行うようになる。
そうすると、地域が注目されたり民衆からの指示が上がり、長老のメリットが上がる。そうなると、長老たちが自律的に女性平等になる。
いかにして自律させるか。
現地の人に紛争解決の方法や予防、対処を教え、ソーシャルワーカーも育成する。
支援者がやる事と現地の人が出来る事を見極め、出来るだけ現地の人が自律的にできるようにする。
その為の人材育成をする。
テロの予防
若者がテロに参画するまでには段階がある。
心に隙間ができた時にテロリストの動画や宣伝を見る。
1年ほどかけて過激化する
両親や先生は異変に気付いている。
しかし、見過ごされている。
そこで、そう言った兆候を見過ごさないように支援者に問題をシェアし、予防につなげる。
ティールとmanagement3.0が老舗企業に浸透しない理由
ティール組織やmanagement3.0は良いと思う。
https://shuchi.php.co.jp/the21/detail/6479
僕はmanagement3.0のファシリテーターでもあるし。
けど、既存の歴史ある組織にはティールどころかグリーンにするのも不可能なんじゃないかな。
歴史のある組織ではヒエラルキーの上層は大体50代後半で、例えばあと3年で定年の人が自分の立場を捨てて会社を変えられるか？
僕なら逃げ切りたいとおもっちゃうもんな。
定年が70歳になっても同じだと思う。
一度得た既得権益や立場やプライドと、これまで常識だった企業人としての考え方は変えられないんじゃないかなぁ。
実際、僕も柔軟ではなくなってきている気がするし。
ヒエラルキーな組織でかつサラリーマンという意識を持つ人が大半である以上、上司の顔を見て仕事をするのは仕方ないし、軍隊組織としては上司の指示に従うのが良い。
けど、有事でないのにそのスタイルは、当たり前のように人の自由と幸せを奪うと思われる。
なので、ティールやmanagement3.0が注目されるのだと思う。
リンスタやデザイン思考みたいな比較的プロセスや工学よりのアプローチは理論もビジネスとの関係も分かりやすく、受け入れられやすい。
しかし、ティールとかmanagement3.0みたいな成果が分かりづらいものは、トップには感覚的に受け入れられても、成果を求められる中間層には受け入れられづらいよなぁ。
その中でも会社を変えようと頑張る事と、そんな面倒な事はやめて既にティールな組織でやりたい事をやるのはどちらが良いのか。
断然後者な気がするなぁ。
Agile Japan 2018
こんにちは。
せっかく参加したので備忘録としてレポートを残しておきます。
Agile Japan 2018 ~Why Agile ~ 2018/07/19
総括：
参加者550名以上。初参加者400名以上とのこと。
発表者は、事例紹介以外あまり変わらない印象。
大企業への導入事例やチームビルディング、ファシリテーション(人系)の内容が多かったような。
それだけエンタープライズでの採用が進んでいるのかと感じる。
基調講演は2つ。モブプロの生みの親であるWoodyさんと、 日本交通/Japan Taxiの川鍋さん。
どちらも面白かった。
ここにはWoodyさんの話を詳細に書き留めておきます。
基調講演のWoodyさんのモブプロのはなし
Woody Zuill氏はモブプロを通して最適な仕事の進め方について話された。
モブプロのメリットは心理的安全もさることながら、個人、チーム、リーンな仕事の進め方の各フローを最適にすること。
例えば、開発中に自分たちでは決定できない事が起きた場合は待ち状態が発生する。
その間は、他の作業を進める。
一見効率的（稼働率が高く）に見えるが、このラウンドロビンは在庫を増やしてしまう。
つまり、大きな手戻りになる可能性があり、リーンではない。
モブプロはこのような無駄をなくしている。
全員が一つの事に集中し、やりきることで、チームメンバの脳内CIができている状態をつくっている。
とのこと。
モブが最適などうかはおいといて、自工程完結の話なんだろうなぁと思った。
(ちなみに、翌日のエンタープライズ・アジャイル勉強会で原田騎郎氏もおっしゃっていた)
Woodyさんの講演で特に印象的だったのは
「モブプロでどれぐらい生産性が上がったのかとよく聞かれるが、
生産性とは何か？重要か？
あなたが言っている生産性はINに対するOUTの量であり、
正しいやり方で正しいOUTを 出しているかは分からない。
生産性よりも効果的な仕事を阻害する要因が取り除かれたという
効果の方が重要だと思う。
モブプロでは、最適な仕事を阻害する要因をすべて取り除く
効果があることが示されている。」
ということ。
まったくおっしゃる通り。
生産性おじさんに聞かせてあげたい。
無駄なものを短時間でたくさん作る無駄に気付かないとね。
所感：
物凄く共感する。
これまでのプロセス品質でモノゴトを評価しようとする考え方が、
日本の老舗大企業がソフトウェア中心にシフトするのが難しい 原因の1つかと思う。
ところで、Woodyさんの英語はものすごく難しく聞こえた。
まだまだ英語力が足りない！
PUBGのVCで頑張らねば！
最後に：
最後のセッションで木下さん、川端さん、前川さん、細谷さんの公開ディスカッションがあった。
みんなに共通していたのが、XPが基点であることと、アジャイルを前面にだしていないことだった。
共感するとともに、やっぱり僕があまり得意じゃないのは「アジャイル、アジャイルっていう人」だったんだなぁと再認識しました。
また、IBMの松永さんの講演の中で、
「DX時代においてアジャイルは必須。
これからは技術力がモノをいう時代になる」
とお話しされていました。
これもまた激しく共感。
不確定な技術、探索する顧客/市場価値。
このような状況では変化に対応し、タイムリーに価値提供できることが競争力になる。
この翌日と翌々日は、今年から実行委員をさせて頂いているエンタープライズ・アジャイル勉強会に出席。
初日にはWoodyさんもこられたし、2日間で色んな人と色んなことを議論できた。
これはまた別な投稿で記録します。
書きなぐりですいません。
バイナラ
ラナイバ
「9つの質問」 ~HONDAの技術革新を支えた"超"目標達成法~ を読んでみた
HONDAの技術革新を支えた〝超〟目標達成法「9つの質問」
単行本（ソフトカバー） – 2016/3/26
https://www.amazon.co.jp/dp/4782534396
こんにちは。
こんばんは。
おはようございます。
今日からGolden Weekに入りました。
Golden Weekは、
普段行けないところに旅行したり、
釣りをしまくったり、
お昼からお酒をらっぱ飲みしたり、
したいです。
Golden Week前には、具体的に何をしようかあれこれ考えます。
どこに旅行に行こうか、何泊しようか、何を食べようか、、、
そこで、ふと。。。
GWをどのように過ごすことができれば、僕はHappyなのかなぁ。
何をもとめているのかなぁ。
根底にあるものは何なんだろうか。
（実際、そこまで深くは考えませんがw）
この本では、根本的な問題のことを「ラストプロブレム」とよんでいます。
そして、ラストプロブレムを発見し、分析し、それがラストプロブレムであることを検証し、対策を打ちます。
そのための手法が書かれた本です。
そこで、せっかく読んだので、簡単にまとめを書きたいと思います。
あくまでも僕の備忘録が目的ですので、文章の読みづらさや誤字脱字はご勘弁ください。
目次
- はじめに
-
概要
- 内容のまとめ
- 所感
はじめに
書評の前に「xxxの ９つの質問」って、他にも結構あります。
ぐぐってみると、「本音が分かる ９つの質問」とか「売り上げをあげる ９つの質問」とか、出てきます。
もしかすると、「９つ」って数はよく使われるんですかね。
人間工学とか、そいう観点で何か意味があるのかもしれません。
無知で申し訳ないですが、もしご存知の方がいらっしゃったら教えてください。
さて、この本では99%の不可能を可能にする1%の思考法が紹介されています
この思考法は、ホンダが数々の不可能を可能にしてきた背景にある
問題解決のスキル（思考法）をベースにしているとのことです。
それを製造業以外にも適用できるように、シンプルに「９つの質問」としてまとめたのが、この本の内容です。
問題をハイスピードに解決することを特徴としています。
ちなみに、本の中では読者がピンときやすいように、恋愛に例えた解説が多くされています。
また、各質問や手法ごとに事例も紹介されています。
それもあり、内容自体は理解はしやすいと思います。
概要
この本では、「本当の問題」（本の中では「ラストプロブレム」と言ってます）をAs Is To Beの分析や、問題の細分化などの手法を使うことで特定します。
その上で、ラストプロブレムを仮定します。
そして、その仮定（仮説）の正しさを実測した結果やデータに照らしあわせて検証し、対策を打ちます。
このサイクルだけ説明するとありきたりな仮説検証アプローチですが、書籍には具体的な実施手法、STEP、モデルの書き方が書かれてあります。
内容のまとめ
まずは、この本のベースになっているTQM(Total Quarity Management)の大きな流れを示します。
- テーマの選定
- 現状把握
- 現状の解析
- 要因分析
- 対策の立案
- 対策の実施
- 効果の確認
この流れをシンプルかつ簡単に行えるように、９つの質問としてまとめられています。
9つの質問というよりは、9段階のプロセスフローって感じです。
各アクティビティ毎に実施STEPが解説されています。
ガイドラインみたいなものですね。
それと、実施するための図やモデルなど、便利ツールと表記法が紹介されています。
// TODO 特にきになった質問とSTEPを３つほど記載する。
最後まで読んで頂き、ありがとうございました。
ご指摘、アドバイス、分かりづらい表現、誤字脱字など、
ツッコミがありましたら、こっそり、優しく、教えて頂けると幸いです。
では、良い休日を！
ラ・ナ・イ・バ
バ・イ・ナ・ラ
Agile Japan 16 に参加しちゃった
アジャイル・ジャパン 2016に参加しました。
資料
http://www.agilejapan.org/program.html
基調講演はJOE JUSTICEさんのSCRUM for H/Wのはなし。
ソラコムの玉川さんの話し。
どちらも面白かった。
玉川さんが同世代ってことにびっくりしました。
各セッションについては、それぞれ興味深かったしおもしろかったです。
内容については、公式レポートが出ているので、そちらをご参考に。
http://www.manaslink.com/aj2016
参加して、驚いたことが２つありました。
今回のブログではそれについて書こうと思います。
驚いたことその1
イベントが企業向けでした。
アジャイルの集まりというと、若手エンジニアの発散の場みたいなイメージがあったけど、スーツの人がとても多くいました。
年齢も僕より上の方がたくさんいました。
品質保証に関連するセッションが多く、入門編みたいなのは少ないイメージでした。
『理屈と基本はわかった。具体的にうちでやるにはどうすれば良い？』ってのが、世の中の多くの人の関心事なのかな？
ある程度の規模と歴史がある組織では、品質保証は真っ先に挙がる課題の１つだと思います。
ここ数年、エンタープライズ・アジャイルが話題に挙がっています。
それも、大きな組織が部分導入から全社導入へとフェーズが移っているからかな。
だからスーツの人が多いのかな。
なんてことを思いました。
思ってた雰囲気と違って驚きました。
ただ、、、、
イベントのしめくくりは「愛は勝つ」を「アジャイルは勝つ」に替えた替え歌を合唱するという、当初思ってた通りのアジャイルな集まりになっていました。。。
僕は「精神論じゃないんだ！」と言いながら「楽しければアジャイルだ！」的な精神論を語るアジャイル教が苦手でした。
特に13,4年前にLean SW開発だXPだSCRUMだって言ってたコミュニティは、新興宗教みたいで苦手でした。
もちろん、Lean SW開発やXPやSCRUM、その他のメソッドやフレームワークの考え方はすごく分かるし、良いと思っていました。
新興宗教的なのりが苦手なだけで。
チェンジビジョンで働くモチベーションの１つは、あえて自分が毛嫌いしている場に飛び込むってのもありました。
その頃はアジャイル信者に負けないために、アジャイルの本をたくさん読んだなあ〜
懐かしい〜
なので、今の組織でアンチアジャイルみたいな人の気持ちも多少わかります。
僕はアンチアジャイルでもアジャイル信者でもなく、良いものを作ってたくさんお金をもらいたいだけですが。
そのための良い方法があれば、そんなのは手段なのでなんでも取り入れます。
驚いたことその2
とにかく知り合いが多かった。
豆蔵や永和さん、オージスさんがスポサーについているので、久しぶりに誰かに会えるかなぁとは思っていましたが、予想以上に多かった。
登壇されている方も知り合いが多くてびっくりしました。
コンサルを売りにしている会社で、しかもアジャイルに精通している会社ってなるとすごく世界が狭くなるんだと思いました。
アジャイルを扱う人や会社は、オブジェクト指向を広めていたコミュニティや会社がほとんどなので、当然といえば当然か。。。
おかげさまで、1人で参加したのにいつも誰かと一緒にいることができました。
お昼も永和の方とご一緒させていただき、とても楽しかたです。
ということで、２つの驚きをつらつら書きました。
Agile Japan 2016の内容にはほとんど関係ない話でした。
色んな人に久々にあえて、同窓会みたいで純粋に楽しかったです。
ありがとうございました。
ラナイバ
バイナラ
プロジェクト デザイン パターンを読んでみた
プロジェクト・デザイン・パターン 企画・プロデュース・新規事業に携わる人のための企画のコツ32
仕事でも新規事業を考えるみたいなことに関わっているので、参考になればなぁと思い読んでみました。
結論から言うと、ページ数が少なく読みやすく、分かりやすい本でした。
なので、気になる方は是非読んでみてください。
ストーリーとは別に、 具体的な企画創出の手法なんかを織り交ぜたサンプルが書いてあるとさらに良かったなぁと思いました。
「あるある」のストーリーのあとにそれを汎化したパターンを紹介するという構成なので、気になるところから読めます。
新規事業の企画をする場合の着眼から立案、プロジェクトの体制づくりと運用、
日頃の心がけなど３２のパターンで示しています。
せっかく読んだので面白かったパターンと気になることを備忘録的に残しておこうと思います。
あくまでも備忘録なので、認識が間違えていたらすいません。
いつもの通り、ご意見・ご指摘・アドバイスがある場合は、個人的にこっそり、かつ、優しく教えていただけると嬉しいです。
ちなみに今回は（も？）かなりの散文です。
構成も稚拙なのであしからず。
概要
書籍の中でも記載されていますが、パターンなので手順やマニュアルではありません。「あるある」の対策を共有するために「言葉」にしたものです。
本の構成は「あるあるストーリー」があり、それに対するパターンが1個以上書いてあるという構成です。
パターン化されているのもあって、Fearless Changeに似た感じですね。
内容は読みやすくて良いのですが、できればパターンを実行する際に使う企画のメソッドや手法、ツールみたいなものをもう少し具体的に知りたかったなぁ。
パターンの概念は理解できるけど、再現するツールがないといった感じ。
それは別途、デザイン思考とかそれ系のもので学べってことですね。
パターンは32個あり、5つのカテゴリーに分類されています。
CORE（哲学）、LEARN（情報収集のコツ）、CREATE（企画作成のコツ）、LIVE（企画人として生きるコツ）、PLEASURE（もう1つの企画の考え方）です。
面白かったパターン
個人的に「あるある」を強く感じたパターンを3つあげます。
- 相談の順番（CREATE No.16）
これは「あるある」ですね。
僕のような打たれ弱いあまちゃんには大事なパターンです。
相談の順番を間違えると、ガクってなっちゃいますので。
このパターンを僕の考えを例にして書いてみます。
アイデア発案当初、自信が持てないアイデアの場合は特に、僕はまず賛成意見やポジティブ意見を聞いて自信をつけたいと考えます。
それに発案当初はアイデアの説明も下手なので、つたない説明でも聞こうとしてくれる人に相談する方が気が楽です。
説明の練習にもなりますし。
説明がある程度できるようになりアイデアに自信がもてるようになってから、ガツンと指摘してくれる人に相談します。
自分とは別の観点や気付いていなかった弱点を鋭く指摘してもらうことで、アイデアの成長につなげようと考えます。
ただ、その頃にはアイデアへの自信もあります。
なので、意見を受け入れるか否かを自分で判断する精神力がついています。
あまりにも憶測ベースの否定意見であったり、そもそも基礎知識がなさすぎて話にならない意見の場合は、本当に参考程度に考えます。
これが、自信がない時点で同じことを言われると「うぅぅぅぅ〜そういう見方もあるかぁ〜」となってしまい、あーだこーだ考える時間ばっかり増えちゃいます。
なので、相談の順番はかなり大事。
ただ、人の意見よりも客観的な事実データが一番大事だと思います。
人の意見を聞くのはあくまでも参考（と言うと、誰も教えてくれなくなりますが）として、ベースは事実データで判断するように心がけています。
- 愛着が生まれる余地（CREATE No.17）
パターンの内容は、クライアントに隙のない企画をみせるよりも少しすきがあるぐらいの方が、クライアントも一緒に考えられて企画に愛着をもてるようになるといったものです。
これは、今の会社に入社してからずっと思っていたことです。
H/Wを主体に作ってきたメーカーは似た感じなのかもしれませんが、分業化がなされています。
企画 -> 開発 -> 品質保障 -> 運用
-> 販売
みたいな感じ。
もちろん開発の中でも、H/W、メカ、エレキ、S/Wのように分かれます。
さらにS/W開発の中でも基盤S/W開発、アプリ開発といったように分かれます。
何が分かれているかというと、セクションが分かれているのです。
これじゃあ品証や運用の人はコスト意識も製品への愛情もわかないよなぁ〜〜〜
企画はもちろん最後まで携わるとして、品証や運用はもっと早期から開発に参加すれば良いのになぁって思ってました。
同じことを言っているかもしれませんが、多能工なチームとかDevOpsとか、そんなことを言いたいわけじゃありません。
言いたいことは、チームの中に品証や運用の役割を担うってことじゃなく、一緒に考えれば良いってことです。
そのためのチーム構成とか開発モデルとか、そんなのはなんでも良いのです。
今のバトンリレーのような進め方だとサービスの開発はうまくいかないよって思っています。
もちろん事業採算やROIの観点で、企画から運用までをちゃんと把握・管理する人は必要だと思います。
トヨタでいう主査みたいな人。
しかし、いま言いたいことはそういうことではなく。。。
品証はお客さんに近い立場にいるわけで、色んな製品を見てきています。
どんなクレームがくるのかもよく知っています。
なので、顧客課題に対して最適なソリューションになっているかという観点から仕様に対して意見できるし、テスト容易性の高い仕様って観点でも貢献できる。
運用担当者はいわずもがな。
事業採算にみあった運用ができるようにインフラやシステム設計、運用設計に参加すべきだと思います。
DevOpsって言いたいわけじゃなくて、ROIを最大化するために必要な運用機能や仕組みをアーキテクチャに織り込むために、運用担当者の知見が必要なのです。
繰り返しますが、これってアジャイルだとかDevOpsだとかそんなことじゃなくて、愛着をもって製品を開発するという意味で、どんな開発モデルでも有益だと思うのです。
品証の人が自分の子供に「これってお父さんが作ったんだぜ」って言えるのって、格好良いと思うんですよね。
プログラムを書くだけが開発じゃないと思うのです。
（開発者はプログラムをかけないとダメですが）
こういうのって、これまでの僕のソフトウェア開発人生では当たり前だった気がします。
きっと、WEBアプリの開発なんかのソフトウェア開発に関わられている多くの方にとっても当たり前なんじゃないでしょうか。
しかし、H/Wが主流だったメーカーになると、おなじように分業化が進んでいる企業が多いんじゃないかなぁ。
そんな組織でサービスの開発に関わると、僕と同じことを思うんじゃないかなぁ。
- 楽しい記憶（PLEASURE No.32）
ありがちですがこれは大事ですね。
一緒に仕事をして楽しかったと思えると、作ったものへの愛着も増します。
また一緒に仕事をしたいとか、あの時と同じように楽しくしたいとか、前向きな考えになります。
自分のことをふりかえると、最初の会社、豆蔵時代、チェンジビジョン時代と、とても良い経験をさせていただきました。
もちろん、今の会社でもすごく良い経験をさせて頂いています。
そんな中でも、あの時期は最高に楽しかった！というのが何度かあります。
それは、すべて先輩方と仲間のおかです。
楽しい記憶があれば、またその時みたいな仕事がしたいと思います。
その時の先輩や仲間のように振る舞えるようになりたいと思います。
そのために、自分を高める努力をします。
そのために、仲間を作り、周りを巻き込もうとします。
そして環境を変革します。
そして、楽しかった時間と同じかそれ以上の時間をまた過ごすことができたら最高です。
これはすべて「楽しい記憶」に起因します。
もしこれまでに「楽しい記憶」を経験できていない人は、ある程度で見限って自分がいる環境をドラスティックに変える（つまり転職する）のもありかもしれません。
一緒に仕事をした方々の「楽し記憶」 に残れるよう精進しようなんて思う今日この頃です。
ということで、だらだらと思ったことを書きました。
ちょっとまとまりがないので読みづらいですが、個人の備忘録ということでご勘弁を。
ありがとうございました。
ラナイバ
バイナラ
発見から納品へ~アジャイルなプロダクトの計画策定と分析~ を読んでみた
目次
- はじめに
-
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開発の仮説検証の全体を意識した上で、要求分析のプロセスを具体的に語ったフレームワークは珍しいんじゃないかと思います。
具体的にいうと、プロダクトオーナーの仕事の進め方を具体的に示したメソッドやフレームワークは少ないんじゃないかと思います（無知なだけかもしれませんので、誰か知ってたら教えてください） 。
そういう意味で、このフレームワークは参考になると思いました。
最後まで読んで頂き、ありがとうございました。
誤字脱字あればすいません。
また、認識がおかしいところやご意見があれば、メールなどでこっそり教えて頂けると幸いです。
