フェニックスプロジェクトワークショップとは

「The Phoenix Project」を題材としたワークショップです。CREATIONLINE,INC. さんが主催しており、今回はお誘いを受けて行ってきました。

普段の参加者層は、企業向けでこれからアジャイルやDevOpsを始めようとしている／検討している人たちとのことですが、今回はアジャイルコーチ編。
普段からアジャイルコーチやコンサルティングなどを生業にしている人たち12人が参加者です。どうなるのかわくわくしながら参加しましたが、想像通りカオスの様相となりましたので、そちらもお伝えできればと思います。

ワークショップの内容について

内容は「フェニックスプロジェクトワークショップ社内実施レポート #devops #agile #PhoenixProject - CREATIONLINE,INC.」に記載されていますので、省きます。

他の方のレポートも面白いです。

気づきに関して多少のネタバレを含みますので、これからこのワークショップに参加する可能性があり、ネタバレを嫌うかたは、ご了承ください。内容についてのネタバレは避けています。

ワークショップの様子と、気付き

このワークショップは4ラウンドで行います。
4ラウンドでどれだけの成果を上げることができるのか、というゲームのゴールが提示され、始めることになります。
ラウンドごとに様子を記載しつつ、学びや気づきも併記していきたいと思います。
「他の参加者層の動き方と今回のどこが違っていたのか」というのもファシリテーターからフィードバックを貰っているため、差分も意識しながら書いてみようと思います。

ラウンド0

0-1 自己紹介

まずは自己紹介から。
名前、普段の仕事、開発経験、ワークショップへの期待、という質問に答えていく形式ですが、この自己紹介が長い。多分、企業でやると一人一分くらいでサクッと終わりそうなものですが、参加者12名がほぼ顔見知りであり、各々がツッコミ・ボケをして笑いを生み出しつつ進めていきます。
自己紹介から、場の安全性の高さが保証されており、非常に進めやすい雰囲気で進められていきました。
かくいう私は黄色い服を着ていなかったのですが、「なんで黄色くないんですか」というツッコミを受けました。もちろん黄色い服は持っていたのであとで着替えました。互いの特性を知り合っている、というのも場の安全性の高さにつながっています。
ちなみに、この場に参加されていた長沢さんとは唯一直接話したことがなかった（気がする）ので、人となりが知れて少し嬉しかったです。

0-2 ゲーム説明

ファシリテーターである笹さん(@sasakendayo)からゲームの説明が行われます。

そもそもCEOが建てた目標がムリゲーで、「そんな計画を立てるCEOが悪い！」「そうだそうだ！」みたいなゲームの前提を否定するヤジが出たりするのもいい雰囲気です。

各自、一人一人にロールが設定されており、ロールごとに渡される情報が違います。まずはその情報を読み込む時間。私は「アプリ開発者」でした。
といっても役割に渡されてる情報が膨大で全部の把握は難しい、というのと、「どうせ役割に固執してたらうまくいかない」というワークショップの意図をくみ取っている人が多かったのか、ゲーム開始時点で役割は「なかったもの」になります。これは後述。

読み込んでいる時間の中でも「難しい」「情報多すぎてワケワカンナイ」という独り言が皆に聞こえるように方々から発せられていたため、「あー、みんなも同じ状態なんだなー」ということがすぐにわかります。
ちなみに、私は隣のやっとむさん(@yattom)に「この情報あります？」みたいな雑談をしたら、ファシリテーターに「今はやめてください」と止められました。「今は」ってことは、あとで共有しないとうまくいかないように仕組まれてるんだなーと邪推もしたりしていました。

ラウンド1

説明もほどほどに、ラウンド1が開始されます。
最初はコの字型に机が配置されていました。ちょっとわかりづらいけど、真ん中が離れている状態です。
意図的に会話が発生しづらくなる席配置にしているというファシリテーター側の意図を感じ取ったので、それを壊したくなりますよね。

「じゃあ始めてください」という宣言の後、開始0秒で机を動かし始める参加者たち。私も無言で机を真ん中につけようと動きましたし、やっとむさんも「じゃあ机真ん中に集めましょう」という声かけをしたり。このファシリテーターや全員に対して許可を求めるな謝罪せよ精神で動く、というのが素晴らしいです。情報は自分のもとに貯めていても価値がなく、共有しないと始まらないというのを暗黙的に考えて（無意識に当たり前にやっている人も多そうですが）情報を初手から開示して共有するところが、今回ならではだったようです。

また、ゲームが開始した瞬間に役割がなくなりました。役割の札はまとめて重ねられ（哀れ）端に置かれ、役割の説明のボードは一か所にまとめられます。
役割を超えてコミュニケーションするというのも、情報が足りないカオスな状態での１つの解なのかもしれません。

ラウンド1では以下のような会話が起こりました。

ゴールは何か
バリューストリームはどうなってるか
ボトルネックはどこか

また、以下のようなカイゼンが行われます。

関連する情報を一か所に集約しよう
ラウンド1はわからない情報が多いから失敗して学習しよう
どうなったらリリース成功になるかわからないから、とりあえずやってみよう。結果を見てからカイゼンしよう
カード（情報）は一人で持たないようにしよう
困ったら手を挙げて発言し、みんな聞こう
今の問題をカンバンで表現

序盤は12人で情報共有をしつつ、作業は2～4名のクラスタで勝手に分かれて行っていた点です。全員で進めることは効率が悪い、かつ一人で作業をするのも全体最適に向かわないという感覚を皆が持っているためか、一人だけで作業をすることはなく、勝手にペアが出来上がって作業を進めていました。
各自持っている情報を左右で共有しつつ、分からないものがあればすぐに全体に聞く。情報が足りないカオスな状態だと私も認識していたので、うまくやるよりも全体を見ることに集中していました。

また、CEOから問題となる新しい情報が連携された時にも、すぐに全員が手を止め共有します。即時共有、というのが瞬間的にできるのがいいところですね。

この回独特だなぁと思ったのは、人の動き方です。
テーブルで作業をやっていると、どうしてもテーブルが見えずあふれてしまう状況が起こります。そういう人は一歩離れて全体を眺めてみたり、時間を確認したり、というスクラムマスター的な動きが自然と起こっていたように思います。

ちょっと会話につかれた人がファシリテーション側の空いているスペースに立って、全体を眺める。私も数回やった気がします。空いているところに向かったり、「どこが余裕なさそうかなー」と考えてみたり。
また、面白いなと思ったのはタイムキーパー不在なのに全員が時間を把握している、というところ。
ワークショップでよくあるのは、誰かがタイムキーパー役をやって残り時間を発声します。大体１ラウンド目にタイムキーパーに失敗して、ファシリテーターから指摘が入ってカイゼンされたりするものです（私自身、わざと失敗させて気付かせるという手を使うことがあります）。
今回は、ちょっと手が空いた人が時間を確認して、「あとXX分」と勝手に発言していきます。残り時間がわからない、という状況に基本的に陥ることはなく、残り時間に応じてリリースに向けて動き方をそれぞれが変えていたように思います。

ちなみに、私が勝手にやっていたのは、ワークスペースの確保。
壁側に椅子や荷物が置かれていたのですが、壁側を利用しやすいように空いた時間を利用して椅子や荷物を勝手に移動していました。（許可を求めるな謝罪せよ精神）
机上のゴミを片づけたり、道具を移動したりも暇なときにやっていました。
作業場が綺麗だと生産性も上がりやすいし何よりも私が汚いのがイヤなので勝手にやっていました。
そういう感じで、各々が空き時間は割と自由に動いていたのではないでしょうか。

ラウンド1が終わるころには、ホワイトボードにバリューストリームが記載されていました。いつの間に。

ラウンド1の実行フェーズが終わると、ふりかえりの時間です。
ふりかえりの時にはチームの問題は何かを全員でピックアップし、重要なものから順にカイゼンしていきます。

誰がどの役割かを忘れているので、みんなが役割カードを持たされます。シュール。
後ろのホワイトボードにはバリューストリームが。

ファシリテーターの笹さんが事実整理をするための質問をしてくれていた、、のですが、「XXX…はやってますね」「やってるね」みたいな、事実確認になっていました。
普段はファシリテーター主導で、事実を思い出しつつ、カイゼンポイントを出していくようです。
今回は参加者が勝手に動いて、問題を洗い出して、カイゼンしていっていました。ファシリテーター泣かせだなぁと感じていました。

ラウンド1で「テスト」チームがボトルネックだということがわかり、テストチームに渡されていた情報カードを川口さんがコンビニにコピーしに行った、というのがハイライト。
テストチームはもともと2人ペアでいろいろなチェックをしてくれていたのですが、人が足りない、もう1ペア作ろう、という話も出て、テストチーム×2のWIP=2仕様に。ついでに作業は全員ペア以上で、という話も出てきます。

ふりかえりの中で感じたのは、究極の心理的安全性はこういうものなのだ、ということ。
それぞれが意見を尊重しつつも、ダメだと思ったらダメとすぐに宣言できる。そして合理性や残り時間を判断し、即時決断が下される。発言をするのに許可は必要なく、誰かが発言しようとしたら話をやめて全員が聞く。
仕事の仲間よりもきっと互いの内面は知らないのでしょうけれど、共通の目的のために動いており、多人数でのワークのときにどう動いたら効果的かがわかっている。そして、やりたいことが違うとしても、正解かどうかは全員がわかっているわけではないので、Roman Voting（賛成/反対）によってさっさと決断して、やってみてダメだったらすぐカイゼンすればいい。そういう意識でどんどんカイゼンが進みます。
仕事上ではなかなか作り出せないレベルの心理的安全性だと思います。

ラウンド2

ラウンド1終了時点で、どうすればリリースできるのか、というのも（想定通り）予想できるようになりました。その結果を踏まえつつ、ラウンド2です。
ちなみに、ラウンド2開始前に、CEOから「残業をしていたのが監査にバレ、その分作業時間を5分削らなければならない」と言われました。終了後の結果確認中が15分の休憩時間だったのですが、そこでみんなでカイゼンの話をしていたためだそうです。「休憩しながら雑談していただけなのに」「仕事じゃないのに」とヤジが飛びましたが通りませんでした。無念。

作業時間が削られつつ、情報は増えます。情報が増えたので、机も増えます。情報量に応じて、情報の置き場所が変化していきます。
作業中に提案されたこととして許可なしにカード（情報）を移動しないというものも。ワークをしながら適宜カイゼンが進んでいきます。

予想通り、このワークショップのコアとなる要件も降ってきますが、それをするためにはCEOに許可をしてもらわないといけない。「これが実現されないとファシリテーター側は困るだろうな」という悪戯心が働いたのは私だけじゃないはず。実際、この要件が実現されることはありませんでした。要件の優先順位はCFOに任せていたのですが、わざと落としたんだろうなーとも思います。だって落としたら面白そうじゃないですか。

各々がクラスタで作業をしつつ、手の空いた人は他の所へ飛んでいきます。そうして全体を少しずつ把握しつつ、自分たちの作業に集中する。全体最適と個別最適が同時に行われ始めていたのだと思います。個別のクラスタ内での作業に集中しつつも、クラスタ間で必要な情報を連携。問題が発生したら即時全体連携。

開発の流れが出来上がってきたところで、リリースするためのビジネスの優先順位を考える作業にボトルネックが移動したことに気づいていきます。
結果として、コアとなる要件は落とし、問題の解消にとどまってしまいます。判断は要件実現側のクラスタに任せていましたが、その判断結果自体は口頭で全員に共有され、全員が合意していました。

ラウンド2のふりかえりでは以下のようなカイゼンが行われます。

バリューストリームに合わせてカードの置き場所をカイゼン
ボトルネックがビジネス側（優先順位の確定や最終決定）に移動したため、そちらに人を入れる
テーブルだと可視性が低いので、床にカードを置く
全体のWIPがわかりづらいので、表示する。WIP=2にする

こうしてカイゼンを行った結果、こうなりました。

床、というのがなかなか出ない発想だと思います。
私もその発想はありませんでした…。
カイゼンの結果もうまくいくかわからないので、実際に１つのプロダクトを作ってみて（流してみて）うまくいくか確認したりして、次のラウンドに挑みます。

バリューストリームのうち、誰がどこの担当になるのか、も瞬間的に決まります。多分10秒くらいで決まりました。もともとの役割のことは無視して、得意なところに入ります。
そして、各担当は2名以上。自然とペアになります。

ラウンド3

ここからはラウンド2までの見えなかった状況に打って変わり、「作業」へとなっていきました。
ビジネス側で要件を決め、開発側がペア作業でどんどん要求を実現する。そして、テストが最終確認をし、またビジネス側が何をリリースするかを決めていく。
ふりかえり時点ではWIP=2を想定していましたが、自然と開発側のWIP=1（一個流し）になり、テストがWIP=2に。そして、開発側は4段階に分かれていたのですが、それぞれが手が空いたら左右を手伝うというサシミ構造に。自然と全体最適につながる形で機能が実装されていきます。

終わりも見えてきてワーク中に写真を撮る人も増えてきます。

1ラウンドで10個機能を開発したものの、リリース側の制約ですべてはリリースできず。開発スピードとしては十分なものとなりましたが、キャパシティを決める側にボトルネックが移動します。

このキャパシティも、ビジネス側で実現したい要件を決める際には、すぐにはわからないようなワーク設計になっています。開発を実現して初めて、必要なリソースが判明するのです。
この段階で十分すぎる開発速度になっているため、すべてのバックログを実現してしまう方向になりました。
必要なリソースをテスト終了段階で付箋で明らかにする方法を編み出し、つぎのスプリントに備えます。
もちろんカイゼンをテストしていくうえで、実際のバックログを１つ消化しながらうまくいくかを確認します。

そして、カイゼンしながら最終的なワークスペースが作成されていきます。

ラウンド4

そして、最終ラウンド。
ここまでくるともはや完全に流し作業です。
1つの開発は15秒程度で完了し、すべての要件を食い尽くすまで8分程度。
開発時間のうち、開発・テストサイドの人間は20分程度暇になってしまったため、ビジネスサイドに協力していきます。
実現する可能性のあるバックログをすべてリリース手前まで持ってきて、リソースも判明している状態だからこそ、ビジネス目標を達成するためにどのプロダクトをリリースするかを取捨選択する余裕が生まれます。実プロジェクトでも、超高速な開発ができるようになると、ROIをどうするかを開発チーム含む全員で考えるようになる（余裕ができてくる）、ということの暗示なのかもしれません。

CEOから無茶ぶりされたビジネス目標を達成するためにどうやったら（どうやって穴を潜り抜けたら）いけるか、を全員で探したり、CEOにキャパシティを上げるための相談をしたり。有意義な時間の使い方をして、終了です。

全体のふりかえり

「DevOpsについて何かわかりましたか？」という質問に関しては正直NOです。
ここまでに述べた動きや文化的なものもすべて含めてDevOpsであるとすれば、当たり前のことを当たり前のようにできるチームはDevOpsなんだろうなーと感じました。
「DevOpsってツールを入れればいいんでしょう？」という人たちへの気づきを促すにはいいワークショップなのだろうと思います。

今回はファシリテーターはゲームマスター的な動き方しかしていなかった（というか参加者のせいでできなかったのもありそう）ので、ほかの参加者層のときにどんな指摘をするのか、というのも最後に見せてもらいましたが、最初の1-2ラウンドでほとんど話題に出てカイゼンに回していたのもこのメンバーならではなんだろうなぁと思います。

問題は、ここで行ったワークを、ほかの場でどう再現するか、というところ。
知っているだけでなく、うまく伝えることができ、そして相手の心と体を動かすことができて初めてよいコーチ。
実際の現場でも、上記を問題意識に持ちつつ、カイゼンの輪を広げていければと思います。

全体を通しての学び

床最強説
めんどくさい人たちが集まると自律的に動いて自然と面白い成果が出る

お疲れさまでした！

（レポート）フェニックスプロジェクトワークショップ アジャイルコーチ編