2020-03-07 DevLOVE300 Journey #DevLOVE
2020/03/07 に開催された DevLOVE300 Journey のイベントレポートです。
●イベント概要
300回目の再会と、新たな旅立ちをともに！
2008年6月21日より始めたDevLOVEは実に300回目を迎えるに至りました。
1回目は、2008年12月17日 DevLOVE Bridge から、
100回目を、2012年12月15日 DevLOVE 2012Conference で、
200回目を、2017年6月18日 DevLOVE200 Bridge でそれぞれ迎えました。
300回目は、2020年3月7日 DevLOVE300 Journey です。
これまで数々のDevLOVEを重ねてきました。2008年にたった2人からはじめた時、まさかこのコミュニティが12年続き、300回を数えることになるとは想像もしていませんでした(100回目を越えたあたりで既に想像を越えてきています)。ふと考えたことがあります。「この旅はどこへたどり着くのだろうか？」と。
もう、とっくにたどり着いているといえるでしょうし、まだまだ旅の途中にあるとも言えます。この旅がどこに向かい、いまどこにあるのかは、DevLOVEに関わった人たちそれぞれによって異なります。コミュニティの役割とは、そうしたそれぞれの旅の途中にある人たちがひと所に集まる「理由」を作り出すことにあるように思います。
ときに同じ旅程を行き、またときに別れ、それぞれの旅を続ける。立ち止まるときも勿論あるし、また誰かと再び歩み始めることもある。そうやって私たちは、向かいつづけているのです。コミュニティとは、約束してなくても再会ができる場所。300回目の再会と、新たな旅立ちを。むかえましょう。
この場作りに力を寄せてくださった人たちに感謝を込めて。
300回目は、ファウンダが務めさせていただきます。
■対談: カイゼン・ジャーニー 〜 たった1人からはじめて、「越境」するチームをつくるまで〜
市谷 聡啓さん [DevLOVE オーガナイザー / 株式会社エナジャイル]
新井 剛さん [株式会社エナジャイル]
●カイゼン・ジャーニーの話は3つ
・書籍 カイゼン・ジャーニー
・片瀬アナザーストーリー
・ちひろ物語
●カイゼン・ジャーニー CJM
●会社とコミュニティの違い
意思決定、こぼれ球を拾っていくスピードの速さをどう感じる？
・PLAIDさんの現場
セキュリティ組とかが回っている
これは好きなことをやっているからなのかも
●会社を出ていく前にやっておくべきこと
会社はもっと自由に行き来してよいのでは
会社はやめなくても良いのでは？
辞めはしたけど個人事業主で関わったりしている
・やっておくべきことは、ないのかも
現場が回るようにはするのは前提で
やっておいた方が良いと感じるものを
●2人目の見つけ方、3人目の見つけ方
・2人で活動している中で、3〜10人くらいが一気にくる
2人目は意識するけど、3人目は意識しなくて良いかも
●経営者になる、ハンドルを握ったほうが良いと思う人は？
・経営者になる は、必ずやったほうが良い
副業でも良い
仕事を立ち上げて、回していく
この中でしか出会えない経験がある
気に入らなければ辞めたら良い
●コミュニティ活動を持続するために必要なことは？
・人のときを想う
●DevLOVEはどこへたどり着くのだろう？
・コンセプトを決めて進んでいる、どこにたどり着くのかは分からない
・出会った人々からいろいろなことを吸収して変わっていく
●DevLOVEならではの世界
・扱うテーマの幅の広さ
・市谷さんが絡まないイベントもあるがコンセプトに沿って動いている
・越境というコンセプト
●カイゼン・ジャーニーが意味するものは
・どんな受け止め方をしてもらえるか分からなかった
・いろいろな声をもらったものが答えなのかもしれない
・カイゼンジャーニーは何かといえば、自分の人生
・自分の人生は何かを問いかける存在
■正しいものを正しくつくる 〜プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 〜
市谷 聡啓さん [DevLOVE オーガナイザー / 株式会社エナジャイル]
●自己紹介
・what doing
越境をエナジャイズするジャーニー
越境する人をエナジャイズしています
・仕事
DX支援: プロダクトづくり、組織改革の支援
仮説検証、アジャイル開発の実践支援
・書籍
カイゼン・ジャーニー
正しいものを正しくつくる
チーム・ジャーニー
●われわれが挑戦していることは？
・不確実性の高いプロダクト開発
プロダクト開発につきもの
領域を選ばない
・誰かのためにつくる
ユーザー、顧客
自分以外の誰か
という時点で不確実性と向き合う
・SoEだから不確実性が高い
SoRだから不確実性が高くない
という2元論で説明する時代は終わった
・SoRに蓋をして先に進むことはできなくなった
10〜20年 知る人ぞ知るな基幹システム
どうしてもSoRに踏み込む必要がある
SoRを調べる活動は探索
●人間の普段の行為をデジタルに置き換えよう、ではなく
どうトランスフォーミングできるかという検証
・エクスペリエンスの再定義
・正しい筋道も筋書きもない中で進む
・状況や問題に仮設を立て、検証し
分かったことに基づいてプロダクトを実装する
●仮説検証型アジャイル開発
・仮説 = 前提 + 仮定 + 期待結果
前提
前年は10%伸びた
事実
期待結果
今年は20%の伸びが期待できる
仮定
リーチしていない顧客がいる
広告投資を50%増やすため
・事実が少ないほど、仮定が多い
・仮定を減らし、事実を増やす
・事実の根拠
データ（定量、定性）
知見(既知の事実、経験値)
・データによる理由付けが不可欠
・知見が全体の速度を上げる
・事実を増やすとは？
情報を増やして、理解を得ること
情報 x 解釈 → 理解 → 事実
・誤った理解は、間違った前提になってしまう
・解釈を鍛える必要がある
正しい理解を得るために
これまで獲得した知識 と 検証結果の学び
・検証結果 → 合意形成 → 意思決定
全ての箇所で謝る可能性がある
チームで学び、練度を高めていく必要がある
・一つのパターンとして
仮説検証型アジャイル開発
正しいものを探す → MVP特定 → 正しくつくる
●仮説検証の「例」
・仮説検証 1週目: PSfit
絞り込むより、理解するための検証
仮定立案: 仮説キャンバス
探索的検証: 顧客インタビュー
仮説の修正
・仮説検証 2週目: PSfit
被験者にイメージを深めてもらう
イメージ制作: ストーリーボード
イメージを伴う検証: 顧客インタビュー
仮説の修正
・仮説検証 3週目: PSfit
被験者に操作でイメージを深めてもらう
プロトタイプ制作: NoCode Prototyping
操作を伴う検証: プロトタイプ検証
仮説の修正
・仮説検証 4週目: PSfit + チャネル検証など
被験者に利用体験してもらい評価
MVP特定と開発: ユーザー行動フロー
利用体験を伴う検証: MVP検証
仮説の修正
・仮説には構造がある
か → かた → かたち
課題仮説 → 機能仮説 → 形態仮説
本質的な課題 → 課題の解決手段 → 手段を利用可能にする
・検証目的の度合いが異なる
・仮説検証 5週目: PMfit
UXの推敲
アーリーなユーザーから、ユーザーの裾野を広げる
課題が切実なので多少使いにくくても使われる
より伝えることを丁寧に
PRだけでなく、プロダクトの表現そのものも
利用体験を頭を何度も繰り返し「つるつる」を目指す
・PSfitはあるが、広がっていかないの解釈
PSfitしていないとしてしまうことがある
相手からどう見えて、どう感じているかを考える
●仮説検証型アジャイル開発の戦略
・分からないことを分かるようにする
分かったことに基づいて、つくる
・われわれは、どこまで変化に適応できるか？
分からないことが分かる → やらねばならないことが増える
・学びが不確実性を連れてくる
プランニングがくずれます
採用技術が変わります
・変化を受け止められる余白をつくりながら
短いタイムボックスの中での確実性は高める
余白をつくりながら、やりきる
長距離ではわからないことも、1週間先なら分かる
・プロジェクトレベル: 余白の戦略
調整、期間、受け入れの余白
・スプリントレベル: スプリント強度を高める戦術
背骨駆動開発
状況をクリーンに保つ5つの条件をやってみる
受け入れ条件
ベロシティを計測し安定させている
受け入れテストを実施
振り返り
実運用相当のデータが揃っている
・複数スプリントレベル: 全体への共通理解を滑る作戦
自分たちの活動に作戦名をつける
期間のミッションが明確になる
基準が分かるから、チームが自律的に動こえるように
・すでにあるプロダクトでの仮説検証
デュアルトラック・アジャイル
開発スプリントと仮説検証の活動が並行して進む
開発→検証→学習結果を開発にサイクルさせる
別で動いているので、同期が必要
同期が空きすぎると、学習不全の負債が貯まる
・仮説検証リードを置く
適切な練度のメンターを外部から呼ぶ
・チームで学ぶ機会を段階的につくる
イベントベースの検証
●プロダクトづくりで間違いやすいのは、意思決定や行動
・良かれと思って進んでいるから気づきにくい
・気づいていないことに気づくためには
問い続けることで、自分たちに傾向を与える
自分たちに考えさせる
●正しいものを正しくつくれているか？
・絶対的に正しいものはないことが前提
・これに答えようとすることが、自分たちに考えさせる
■チーム・ジャーニー 〜逆境を越える、変化に強いチームをつくりあげるまで〜
市谷 聡啓さん [DevLOVE オーガナイザー / 株式会社エナジャイル]
●不確実性との戦い
・ずっとこのことに向き合っている
アジャイル開発にリンクしている印象
・不確実性はやっかいなもの
できればない方が良いと思われがち
回避するべきではない
・混沌を引き寄せるもの
プロダクトの未来を変える可能性でもある
●明日を変えるために、不確実性を引き寄せる
・分からないことを分かるようにする
一方で、分からないことを増やす
・多様性を高める
・いろんな解釈の人が集まっていると、選択肢が増える
増やした上で検証していくのがセットベース
●重奏型仮説検証
・第1段階 仮説の外在化
構想がプロダクトオーナーの中にある
解釈を一方的に伝える
仮説キャンバスで外在化
意見を誰でも表明できる
・プロダクトオーナーの視座をプロダクトの上限にしない
プロダクトオーナーは一人
上限はあっという間に来てしまう
ものすごい知見を持っていますな人は少ない
・プロダクトオーナーを民主化しよう
一人の視座、視野から
チームの視座、視野へ
・第2段階 仮説検証の重奏化
共通理解は必要
個々人の仮説を持つ
チームでの仮説を磨いていく
・チーム or POを仮説検証に巻き込むために、段階を踏む
第1ジャーニー: 事前学習
第2ジャーニー: イベントベースの検証
第3ジャーニー: 継続的な検証活動
・エンジニア、PO双方から、どう巻き込むかを相談された
どちらにも良いものをつくりたいをいう思いがある
巻き込んでいくべき
・相手のナラティブを知ろうとする
どういう経緯でここにいるのかを知ろうとする
お互いがそれぞれを知ろうとする
・チームが進むためには、一つのことに合意しなければならない？
合意形成は唯一を選ぶものではない
ばらばらのままの合意形成
多様な解釈を活かしていく
・ワンライナーキャンバス
仮説を立てるのにハードルがあるならワンライナーではじめる
●多様性の次に目指すのは機動性
・多様な解釈で、いろんな仮説を持つと情報が増える
分かったことを反映するのが半年後です。では問題
即応性を上げる ただし、全体性を見失わずに
・段階の設計
ウォーターフォールをやめた結果、
段階の発想がなくなってしまったのかもしれない
目的地を見立て、たどり着くために必要な状態を言語化
進めて分かったことから、構想自体を変化させる
目的地自体も通過点
●段階（ジャーニー）のアウトプット
・チームとプロダクト
・最初から理想が見えるわけではない
・ジャーニー
= 段階的発展
= 進化
当事者として意志のある進化をしくむ
変化に適応していく
●リーン・ジャーニー・スタイル
・セットベース
リーン製品開発の概念
多様性で選択肢を広げる
・スタイル
唯一の解というわけではない
・チーム・ジャーニーのストーリーもこの流れ
目的地を見定める
ジャーニーを設計
ジャーニーのミッション定義
ジャーニーバックログプランニング
チームのファースト選択
チームのフォーメーションを変更
ジャーニーの推敲
ジャーニーのふりかえり、むきなおり
・根底にあるのはアジャイル
少しずつ繰り返しながら形づくる
・繰り返し = イテレーティブ
人は、反復で動きやすくなる
・少しずつ = インクリメンタル
チームもプロダクトも
・段階的に = ジャーニー
仮説検証、プロトタイプ、MVP
●プロダクト・ジャーニー
・仮説検証型アジャイル開発も一つ
仮説検証
MVP選定
アジャイル開発
・傾きの問題
新しい取り組みをするときの、理想的な状態との変化量
これまで が引き寄せる重力を突破できない
変化格差を段階でなめらかにする
・段階のイメージを一旦言語化することで前に進んでいく
●チーム・ジャーニー
・カイゼン・ジャーニーもこの流れ
活動の見える化
スクラムに取り組む
仮説検証に取り組む
・目的地までの傾きが急勾配にならないように設計
・過去をふりかえり、未来にむきなおる
●DX・ジャーニー
・Digital Transformation
現場と経営の変革意思が噛み合う、惑星直列的なチャンス
現場で、いくらアジャイルと言っても通じなかった
トップダウンの変革が、空を切り続けた
→共通の危機感にたどり着いた
・逆二項対立作戦
SoEの仮説検証
局所的SoE開発
SoRとの連携強化
●ジャーニーは重なり合う
プロダクト・ジャーニー
チーム・ジャーニー
DX・ジャーニー
●ともに考え、ともにつくる
・このあり方の先にあるもの
・問題
分断が二項対立をつくる
変化格差
→お互いの関係性に意味を見つける
・われわれはなぜここにいるのか？
お互いのナラティブがあるが
なぜここにいて、何をしようとしているのか
自分自身のミッションと役割を
問い直し続ける必要がある
●私自身のジャーニー
・国/自治体、大企業、地方アトツギ
・これまでの日本の社会インフラをつくってきた
この人達が逆境にある
だからトランスフォーメーションが必要
→逆境からの越境
・明日の不確実性を引き寄せるために
分からないことを増やしたい
・20代、30代ではなく
今の自分だからできること、やるべきことがある
・油まみれの逆境からの越境はおじさんが進めて
もう少しきれいにして若い人に渡したい
Redesign Journey
新たな境界でまた。会えることを。
■対談: 3つの書籍の連続した物語性や執筆の裏側
市谷 聡啓さん [DevLOVE オーガナイザー / 株式会社エナジャイル]
新井 剛さん [株式会社エナジャイル]
●出発のための3つの問い
・自分はなぜここにいるのか？
・私たちは何をする者たちなのか？
・そのために何を大事にするのか？
●「俺たちはやれる」感を演出すること。1dayで合宿。
・自分たちの状態はわかりにくい
・意図的にやれる感、やれてるよねをつくっていく
●僕は状況とは真逆になぜか自信が湧いてくるのを感じた
・チームが絡み合わない状態で、コンフリクト自体が起きない
チームが同期するようになり、課題が出てくるようになった
大丈夫ではないが、状態が進んだ
・課題が見えるようになって、戦えるようになった感覚
●一撃の言葉
・君が知っていることはなんだ
・なんなの、これ。ごっこじゃん。
・誤った民主主義、個人商店状態、塹壕状態、烏合の衆状態、仲良しこよし状態
自分自身もこれを経験してきた
仲良しこよし は、ないかな
●新しい言葉のひらめき方は？
・定期的に実施している
自分の経験を棚卸し
学びを概念化
概念に名前をつけること
・自分で言葉をつくると独りよがりになる
わかり合えなくなってくる
でも、自分たちの中では、コンテキストが共有される
外から見たらなんだかわからないので、丁寧に伝える必要がある
●KJ-TJ比較
・「えらい遅くなってすんませんな。」
意図的に揃えた
西方登場！感
・「こんなんでは、ダメだぞ。」
意図的に揃えた
状況の違いを楽しんでほしい
●3つの書籍で変わらなかったこと
・図を作るのが大変
デザイナとエンジニアが噛み合わないのと同じ感じ
●こんな問題に遭遇したら、ここを読め
・見える化、カイゼン
カイゼン・ジャーニー
・仮説検証
正しいものを正しくつくる
・プロジェクトに必須な段階の考え方
チーム・ジャーニー
●スクラムとは？
・スクラムとは呼べないのではないか？
だから、なんだ？
・それって、スクラムなんですかねー？
だから、なんだ？
●アジャイルとは？
・目の前の最適化はプロダクトづくりでありがち
そこをどうにかしたい
・新しい言葉をつくるのもつながってくる
共通の言語
●守破離
・カイゼンジャーニーは自分の人生の話に近い
・みんなジャーニーしている
切り取ったら書籍になったり
共有していけたら良いね
●「正しいものを正しくつくっているか？」で逆に失ったものは？
・自分たちで考え続け、動き続ける言葉
全員がついてこられるわけではない
・ともに考え、ともにつくれているか？は、ここへの問いでもある
大切なメンバーが去っていくときに、考えさせられた
●新作の構想は？
・KJ最終話→ZDRR、DRR最終話→TJ、TJ最終話→？
・KJの第3部にあるはずだった内容？
・組織の変革を描きたい
●合意形成を誤るパターンの失敗はどう学び、次に活かす？
・相手が何を大事にしているかわからない
・少し見せて反応を見るというのは大切
●プロダクトとチームを両方とも成長させていくための
むきなおりのやり方は？
・チーム、プロダクトでいっぺんにやらずに、段階を経る
・到達したい目的地の解像度を上げる
・アウトプットとアウトカムの二項対立は避ける
アウトカムは到達すべき
アウトプットは出せないと始まらない
・両方同時は難しいのでファーストを決める
●チーム・ジャーニーの設計は、どうしたら良いのだろう？
・そんなに難しいことではないですよ
・小学校のサッカーチームの運営に似ている
はじめて全国大会に行ったとき
子どもたち、親、コーチ陣だれもわからない
このときの学びが組織にいかされている
・目的地を置く→バックキャストで考える
・1スプリントやって分かることもある
自分も再定義の旅に出ていくタイミング
「それぞれの現場でがんばれ！」をお互いに言いあいたい
お互いにがんばりましょう！
■感想
・情報 × 解釈 → 理解 → 前提 の関連
・前提 → 仮定 → 期待結果 の仮説構造
・仮説検証の構造と検証目的の紐付け
・整理した仮説検証の構造と、多様性、合意形成の紐付け
の図解が、わかりやすくて驚きました！
書籍をまたいだ観点での整理、すてきですねー
個人的に、DXは、データを活用して
・Developer Experience をすべての職種に適用した Employee Experience
・これを従業員だけでなく経営にも適用した Executive Experience
・複数のプロダクトのUXや顧客接点をまたいだ Customer Experience
・増えるパートナーや、その先の顧客を含めた Stakeholder Experience
関わるすべての人の体験、生まれるナラティブとどう向き合っていくかの活動だと捉えています。「エクスペリエンスの再定義と、そこへのトランスフォーメーション」と捉える見方に共感しました！
この国のこれからをワクワクできるものにしていきたいですね！
300回記念おめでとうございます！
市谷さん、新井さん、上野さん、加藤さん、ありがとうございましたー
いいなと思ったら応援しよう！
