【デブサミ】チーム・ジャーニー(体験)|レポートにしてみました!
デブサミに行ってきました!
Developers Summit 2020(通称:デブサミ)は「ともにつくる」をテーマにホテル雅叙園東京にて2020年2月13日・14日の2日間開催でした。
システム(ソフトウェア)開発、特にアジャイルに携わっている身としては、2日間連続で入り浸りたかったのですが、なんとか一番行きたかった市谷聡啓さんの「チーム・ジャーニー」セッションだけは行くことができました。
(実はデブサミ申し込みのときにはすでに満席となっており諦めていたのですが、市谷さんのTwitterにて増席のお知らせを見て、さくっとセッションを変更したのでした。笑)
さて、本記事は「チーム・ジャーニー ~逆境を越える変化に強いチームをつくりあげるまで~(市谷 聡啓[DevLOVE])の体験レポートとなります。
市谷聡啓さんはDevLOVEのファウンダーでもあり、何度かイベントにも参加させていただき存じ上げていました。前著の「正しいものを正しくつくる」もKindle版を読破しており、考え方と価値観についても尊敬しています。
講演資料はSlideShareにて
ちなみに資料は親切にSlideShareにて公開されていますのでぜひご覧ください。
デブサミ会場は「ホテル雅叙園東京」
会場は「ホテル雅叙園東京」となっており、JR目黒駅から徒歩7分程度となります。
道のり途中の下り坂が急傾斜であるため、足腰がしっかりしている方でないともう少し時間がかかるかもしれません。
※お目当のセッションが始まる15分前までにはJR目黒駅に着いておきたいところです。
![hotel-gajoen-tokyo](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_1-1024x768.jpg)
雅叙園の中は広いため、会場の受付までは5分程度歩きます。
受付の皆さんは時期が時期であるため全員マスクを着用されています。
![uketsuke](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_4-768x1024.jpg)
「受付開始が9時30分で席は先着順」とアナウンスされていたため、受付開始の5分ぐらい前に到着しましたが、受付していただくことができ、会場の舞扇(まいおうぎ)に入ることができました。
※下の写真のように入場した際は数名しかおりませんでしが、始まるころは多くのゲストで賑わっています。
会場の入り口ではしっかりと、どのセッションを予約していたかを目視チェックされ、参加証のバーコードでピッと読み取られるため、セキュリティがしっかりしている印象を受けます。
![maiogi](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_2-1024x768.jpg)
セッションの開始は10時であり、あと30分ほど時間があったためぷらぷらとお散歩をしています。
ギルドワークスさんのブースでチラシをいただいたり、書籍コーナーに立ち寄ったりして会場の舞扇に戻ります。
![guild-woks](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_3-768x1024.jpg)
「チーム・ジャーニー」セッション
セッションのテーマは「チーム・ジャーニー」で講演者の市谷さんが著者である同名の書籍をひっさげているものとなります。
![ichitani](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_5-1024x768.jpg)
45分間のセッションを勝手に私なりに解釈したものが下記となります。
※私の解釈が不要な方はSlideShareの資料のみを信じてください。笑
プロダクト開発の最大の難関は「不確実性との戦い」である
プロダクトの絶対的な正解がないことによって、関係者がそれぞれ勝手な期待をしてしまい、意思決定や合意形成がなかなかできません。
自分の保身のために都合よく解釈する人もいて、人によって言うことが違うという状態になってしまうと、そのプロダクトは方向性さえも定まらなくなるでしょう。
いろんな手法や技術があるが、理解不足や練度不足で成果にならない
こちらは耳が痛くなります。つまり、スクラムやXP等のアジャイル手法や、リーン・スタートアップ、デザイン思考にしても、急に新たな方法論を導入しようとしても、それぞれに対する本質的な理解がなかったり、実践経験のあるメンバーがいないとうまくいかないということですね。
そして不確実性との戦いというのはプロダクト開発のみならず、DXという組織変革の文脈でも同じとのことです。
いきなりPOを含めたスクラムを始めようとすると失敗する
- 理想的な姿になるための変化量は大きく(変化に求められる傾きが急すぎる)、現実との乖離が大きい。
- 分断により2項対立世界(これまでと新たな)が生まれる(アジャイル VS ウォーターフォール など)。
- 変化格差にどう適応するのか。
- 段階(ジャーニー)を設計して少しずつ形づくる(アジャイルに)ことで変化量をなめらかにする。
- 段階によって2項対立が招いた「全体性の欠如」を解決したい。
- いきなり古(いにしえ)のSoRをアジャイルに変えるのは無謀。
DXだ、アジャイルだという言葉に踊らされて、急に大きく変えようとすると変化量が大きすぎて、対立も生まれてうまくいかないということです。「スクラム」というアジャイル開発手法も広まってきておりますが、しっかりとやるにはやはり大変難しい。SoRをいきなりアジャイルに変えるのは無謀だと言い切っています。
ハレーションが生まれても強力に推進しないと変わらないのでは?という考え方もありますが、それを許容できる組織は少ないのかもしれません。
そのため、段階(ジャーニー)が必要とのことです。
言葉を言い換えると、フェーズごとにロードマップ(アウトカムベース)を描くということかと思います。
急に理想を追い求めてもうまくいかないため、段階(ジャーニー)を踏む
- 少しずつ繰り返しながら形づくる(アジャイル)。
- まずは開発の見える化をはじめる。
- 朝会、ふりかえりなどをひとりから始める。
- そしてふたり。そしてチームへ。
- そうして、カイゼンのサイクルが回るようになってからPOとスクラム。かんばん方式でも良いでしょう。
- そのスクラムがうまく回るようになってきたら、次のステージ(ジャーニー)として、どうやってプロダクトバックログをつくればいいのか?
- 「仮説検証+アジャイル開発」のステージに登っていく。
「アジャイルとは何か?」について諸説ありますが、「カイゼンし続けている状態」であるという考え方があります。「Do Agile」ではなく「Be Agile」という言葉を聞いたことがある方がいるかもしれません。つまりカイゼンのサイクルを回しているということです。
また、「スクラム」の3原則に「透明性」「検査」「適応」があります。「透明性」を「見える化」と表現されているように思えます。
「カイゼンのサイクルを回す、見える化」と考えるとスクラムを知らなくても、誰しもが必要なもの、実践可能なものと思えるでしょう。そして、それの実践が継続できると、POを巻き込んだスクラムのベースができあがっている状態となります。
そのスクラムチームができあがると、次にプロダクトバックログ(何を開発するか)の仮説検証に入ることができます。
ユーザーリサーチなどをしたことがないチームに対して、いきなり仮説検証をさせることは無理があるのです。
自分たちの構想(意思や希望)を言語化する
- ああ、そうそう、と言えるように。
- 現実を進めた結果からわかったことに基づいて、構想自体を変化させる。
- 目的地自体も通過点でしかない。次のジャーニーへ。
- 構想の段階の青写真は当事者に方向性を与える
- チームとステークホルダーとともに「理解」と「意思決定」を共通にして歩み進む。
- チームのミッションとプロダクトのミッションの段階をもうける
段階(ジャーニー)ごとに構想を言語化し、関係者間で当たり前のように理解し合える状態になれると、ベクトルを合わせることができます。そして、その構想自体も一度立てたら終わりなのではなく、新たに分かったことをインプットに変化させる。
これはスクラムの3原則の「検査」と「適応」に近い考え方です。
「構想」を立てて、それと現実とのギャップを「検査」し、チームが「構想」に向けて「適応」するだけでなく、「構想」自体もより良いものに変化させる上に、終わりなどないということです。
全ての粒度の問題を1週間のスプリントと単一のリストだけで解決するのは無理がある
- ジャーニーの時間は必要に応じて可変にする、チームのスプリント期間は固定でよい
- チームはスプリントでよいが組織はそれではできない
アジャイル開発は1〜4週間単位のスプリント(イテレーション)を回しますが、組織など大きなものを変えようとする場合は、より長い期間を設けます。ただ、チームはリズムを重視してスプリント期間は固定でよいです。
プロダクトよりチームというアウトプットを重視してジャーニーの中で育てていく
- チーム・ジャーニーも適当にやっていると、結果も適当になるため丁寧にやっていく必要がある
- 関係者みなが当事者として「意思のある進化」を仕組む。適当な進化ではなく。
プロジェクトが忙しい場合にプロダクトのものづくりばかりに目が行ってしまうことがありますが、チーム自体もゴールでありアルプットであるという考え方です。
私も良いプロダクトは良いチームから生まれると思っています。
そして、適当にやると適当な結果になるのも明らかです。アジャイルだから、というよくわからない理由でいきあたりばったりではうまくいきません。
チーム、DX(組織変革)、プロダクトのそれぞれにジャーニーを持つ
- インクリメンタル(少しずつ)、イテレーティブ(繰り返し)、ジャーニー(段階的)に形づくる
- リーン製品開発のセットベース(様々な可能性を検証して絞り込む)で多様性を利用して選択肢を広げてポイントベースでアウトプットを絞り込む。
- 段階的な設計によって当事者の意思決定を形にしていく。
- 変化に適応するために、ミッション、フォーメーション、チームの主義さえも動的に選択していく。
チーム、組織変革、プロダクトを一緒くたにするのではなく、それぞれに対して構想を立ててジャーニーを進めるという考え方はスッキリします。それぞれジャーニーに必要な期間も異なるでしょう。
プロダクトオーナーの視座をプロダクトの上限(ボトルネック)にしてはいけない
- 重層的仮説検証にてプロダクトオーナーの仮説を外在化することで可視化できチームが意見を言えるようになる(最初に一歩)
- プロダクトオーナーの民主化(PO一人からチームの視座、視野へ)。プロダクトの不確実性に立ち向かうために。
- 重層的仮説検証も、事前学習、イベントベースの検証、継続的な検証活動。
- 意味あるものをつくりたいという思いにプロダクトオーナーと開発者という区別はない。全員もっていい。
スクラムではプロダクトオーナーは1人と定義されておりますが、仮説検証やプロダクトバックログ作成を全て任せるのは現実的ではありません。そして、プロダクトオーナー自体も練度が様々であり、プロダクトオーナーの練度が低いからプロダクトもいまいちになる、というのは残念です。
その、いわゆるプロダクトオーナーに期待する役割をチームに広げることで、よりよいプロダクトを開発できるようにする、ということです。
チームの合意はあるけれど、個々の仮説を持つ
ここは目から鱗でした。
チームとしては構想や方向性をひとつにするが、個々人は仮説を持つ、つまり違う考え方をしていて良いということです。
ひとはそれぞれパーソナリティが異なるため、考え方を同じにするのは無理があると思っていましたので。
むしろ、それぞれがよりよいプロダクトは何か?と常に考えることで、変化に柔軟に対応できるでしょう。そこにはもちろん、誰しもが意見を言える心理的安全性がある前提となります。
ともに考え、ともにつくる
- 自分自身のミッションと役割を問い直し続ける必要がある。
- 専門性(プログラマー、デザイナー、プロマネ)を磨いていくのはよいが、だからこの役割がこう、というのはどうなのか?プロダクトづくりでは適応できない。自分の役割の中の最適化になってしまう。自分の外は関係ないとなってしまう。それなら、そういう役割にしなければいい。もう少し解像度の高い役割があるはず、そうでないと重ならない。
- 固定的な役割も局面によっては必要だが、学びを中心にすることにより重きを置く。
自分の役割がこうだから、私はこの範囲だけ考えて仕事すればいい、という考え方ではダメなんです。
よりよいプロダクトは何か?と常に考え、それを達成するために、いまのチームメンバーの中で自分が何をするのが一番良いのかを考える必要があるということです。
プロジェクトは常に変化していて、いつ想定外のことが起きるか分かりません。そのような状況の中で、チームのそれぞれが固定化した役割の殻に閉じこもってしまうと、必ずや重要なことがポテンヒットのように落ちていきます。それが続くと結果がどうなるかは目に見えます。
あなたは何をする人なのですか
- この問いに答えることは自分の役割の再定義となる。
- でもこのタフな問いは難しい。いつもいつもこの問いに答えられるわけではない。というのは事実。
- だからこそ「チーム」が助けとなり、「ともに在る誰か」がいるから自分が何をすべきなのか理解できる。
- だから「チーム・ジャーニー」という本を書く必要があった。
- ともに考え、ともにつくるという考え方が必要。
- ともに越えられる!
急に「あなたは何をする人なのですか?」と問われたら答えに窮するひとが多いかと思います。
私も困ります。
ですが、この難しい問いの答えを考えることが、結局はよいプロダクトにするために必要なことです。
そして、自分だけが頑張ればいいのではなく、他者がいるから自分の役割を理解できるという考え方がとても素晴らしいです。ひとりで仕事をしているわけではない。チームの中で、ステークホルダーと共にプロダクトを作り上げるんです。それぞれがもっているパーソナリティもスキルも異なる中で、よりよいプロダクト構想も変化する中で、今の自分がどいう役割をこなすことが最善か…
これを一人ひとりが実践できたらとても素敵なことだと思います。
![ともに考え、ともにつくる](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_6-1024x768.jpg)
セッション後の帰り
会場を後にした私は、感動が冷めやまぬまま書籍コーナーに行き、「チーム・ジャーニー」の書籍を買い求めるのでした。
2020年2月17日発売予定が先行で発売しており、しかも10%OFFとなっておりました。
※書籍コーナーにはたくさんの数が置いてあったように見えましたが、完売したとのことです。
![TEAM JOURNEY](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_8-768x1024.jpg)
上の写真のようにSHOEISHAの手提げに入れていただけました。
その後、会議の予定があったため職場に急いで戻らなければならなかったのですが、雅叙園の中庭に立ち寄り、10秒ほど滝を眺めて、雅叙園を後にしました。
過去、百段階段に足を運んだことがあり、その際に立ち寄ったこの滝に癒された記憶が深く残っており、時間がない中でも足が向かいました。
![](https://agile-ninja.net/wp-content/uploads/2020/02/IMG_7-1024x768.jpg)
日々忙しく目の前のことを頑張るのはとても良いことだと思っていますが、アウトプットばかりだといつか枯渇してしまう気がします。こうして良質なインプットを定期的に取り入れられると、結果的にアウトプットの質も上がってくるだろうと思います。
重要で急ぎなことの合間に、重要で急ぎでない時間を取り入れていきたいです。
※TEAM JOURNEY(チーム・ジャーニー)読破し記事にしました!