フェニックスプロジェクトワークショップとは
「The Phoenix Project」を題材としたワークショップです。ITプレナーズジャパン様が主催しており、聴講者として参加しました。
ITプレナーズでは大体毎月行っているものの、毎回満席とのこと。すごいですね。
このワークショップは、100回以上実践している企業もあるとのことです。これもすごい。
今回の参加者層は、アジャイルまたはDevOpsというワードに普段から何かしら触れている、IT企業のメンバーたち9名です。
前回、カオス回こと「アジャイルコーチ編」にて自身が参加してきました。
今回は、チームが形成されるときにどのようなバイアスが働くのか、どういうところに躓きやすいのか、というのを知るため、聴講者として参加しました。
ワークショップの内容について
詳細な内容は「フェニックスプロジェクトワークショップ 社内実施レポート #devops #agile #PhoenixProject - CREATIONLINE,INC.」に記載されていますので、興味がある方はそちらをご参照ください。
本記事では、この回がどんな風に進んでいったかを時系列順にレポートします。
ワークショップの内容に関してはネタバレは含みませんが、学びに関してネタバレを含みます。ネタバレを嫌う方はご注意ください
このワークショップは1から4のラウンドで構成されます。
ラウンドを繰り返しながら、プロダクトを開発していくゲームとなっています。
ラウンド毎に出来事を綴ります。
ラウンド0
0.1. 始まる前
全員が顔見知りじゃない状態からのスタート（当たり前ですね）。
机には役職の札が載っていて、ファシリテーターは不在です。
「どこに座ればいいの？」状態から始まります。どこに座るのも自由で、あまり情報は交換されない状態。
「役割決まってるんですか？」
「えっ、この役割やったことないけど大丈夫かなぁ」
みたいな会話が少しずつ行われていきます。
写真：自由席、とだけ書かれた会場。
恐らくですが、意図的に会話が発生しにくい状況を作り出しているのかと思われました。
サイロ化からどううまく抜け出すか、というのもこのワークショップの目的の1つでもあると思いますので、強制的に会話が起こりにくい状態を作る。こういった場作りもあるんですね。面白いです。
0.2. アイスブレイク
会場説明を挟みつつ、名前、仕事、趣味を一人一人共有します。少しずつ笑いは入りつつだが、まだまだ硬い雰囲気です。
本来は12人で行うワークショップですが、今回は10人。
想定人数に足りないため、一部のメンバーにはロールを兼務してもらうことになりました。
0.3. イントロダクション
「使う道具は日本語があえて分かりづらくしている」のでコミュニケーションちゃんとしてねということが暗に伝えられます。
実際の仕事でも、共通言語が出来ていなくてコミュニケーションがうまくいかない、ということはよくあります。それをゲームとして表現した結果だと思われます。こちらの仕組みは非常に上手いと感じていました。
体制図が説明されつつ、「CIO」が任命されます。今後、このCIOが最初から最後までチームを牽引していくこととなりました。
0.4. ゲーム説明&ルール確認
グランドルールとして3つが入念に伝えられます。
- 制限時間は絶対守ること
- 工数（ゲーム上の制約）を守ること
- トレーニングカード（ゲーム上の制約）の使い方を守ること
です。（※ネタバレを防ぐため工数とトレーニングカードについては詳細を述べません）
このグランドルールはいろんなところで講師から口に出され、「3つのルールを守ってくれればいい」という話を何度もされていました。
特に1つ目は、今後厳しくチェックされ実施されていくことになります。
【開始0分】
まず、全員でルールを確認して準備する時間が20分与えられます。講師からの説明はあまりなく、何か聞かれても「カードに書いています」という返答。
「各ラウンドで何をしなければならないか」という質問に対しては「あなた達次第です」と幅をもたせた回答です。
**誰も、何も教えてくれない。**ビジネスに近い状況でワークショップがスタートします。
そして混乱からのスタート。みんな「わからん！」から始まります。
進行は講師からCIOにバトンが渡され、個別に持っている情報を読み始めました。
写真：個別で読み始める
ここから先はチームの自発的な動きに注目して書いていきます。
【開始3分】
席をくっつけるという活動が開始3分で行われ、誰がどんな役割を持つのかが徐々に共有されていきます。
写真：席がくっつけられ始めた様子。CIOがリードして「各役割をみんなで確認しよう」という言葉から始まりました。
「リードエンジニア」役の方から「ルールが分からないから素振りしてみよう」という言葉も出てきます。まずは流れを作ってみてから考えよう、という思惑のようです。
これ以降のワークショップは、先ほどのCIO役とリードエンジニア役の2人が合わせて、チームをリードしていくこととなります。
【開始5分】
しばらくは個別で読んでいる人もいましたが、全員で何をすべきかがわかった順番に共有されていきます。
【開始10分】
役割を超えて説明を見ている人もいれば、個別で見ることに頑張っている人もいます。
役割ごとにやることの大きさが違うため、情報を吸収するのに時間がかかる人もいます。
【開始13分】
問題（ゲームの中のイベント）がチームに発生。
CIOやリードエンジニアが一度時間を止め、問題の共有とともに、「フェニックスプロジェクトとは何か」という目標共有がされていきます。
【開始19分】
プロダクト開発に必要なインフラの情報が共有されます。
また、終了ギリギリで発生している問題が共有されました。
ラウンド1
1.1. Plan
混乱の中での15分のPlanフェーズが開始されました。
しばらくは準備時間の混乱のまま、進んでいきます。
【開始8分】
8分経過したところで、「ITテストチーム」の制約が共有されます。
CFO役がラウンドごとの目標を書き出したり...（あれ？これ私がやったとき共有されなかったぞ）
10分後にまた新しい問題が共有されたり...
チームの安定を崩すようなタイミングでどんどん問題が投入されます。
全部やろうとしても工数がハマらないことが分かり、「優先順位を付けなければ」「工数を見える化しなければ」という話になっていきました。
混乱し続けたままPlanは終了です。
現段階では、リードエンジニア役とCIO役以外は全体への共有が少なく、情報が閉じている感じがしていました。
1.2. DO
15分間のDOがスタートです。
【開始1分】
問題解決のための制約が一覧化されます。
「変更がある場合は声に出して変更を」ということが、5分経過時にCIOから発令されます。
CIOは常にいろんなところに動き、全体の状況を見るようにしている様子が見えました。
机の上に制約（工数）が可視化され、実施するタスクがだんだん見えていきます。
【開始9分】
『今後のボトルネックになりそうなものはどこだ』という話も出てきました。
【開始11分】
現状だと目標に達成しないことが判明します。どれを取捨選択するか、が検討されます。
【開始14分】
残り1分で、タスクをカードの上に乗せて
**『一回失敗してみよう』『やってみてから結果を見て考えよう』**という話が出てきました。
1.3. ふりかえり
問題は解決しなかったものの、1つの機能をデプロイ成功。
最初に講師主導で事実やよかった点を共有していきます。
- 机の移動
- デプロイできた
- 役割を理解できた
- 他の役割の理解
- Dev&Opsのコミュニケーションができていた
ふりかえりの時間はなんでもやってもいい時間。3つのルールを破らなければOK。
自分たちで30分のふりかえり時間を設定し、カイゼンタイム。
**何が原因で問題が解決できなかったのか？**を話し合い開始。
制約（工数）を考えるためには、もっとコミュニケーションしないといけないということも判明しました。
「役割と責任を明確に分解して、誰がどこに集中するかを決めよう。ただ、タスクを実施する流れがウォーターフォールになってしまっては、これから増える情報に対応できない。そのため、優先順位を付けていかないといけない。この優先順位って誰がいつ決めればいいのか...？」
この話が紛糾していきます。
ふりかえりの中では喋る人はほぼ固定。まだ全体の理解が追いついていない人もいる模様。
優先順位の決め方も以下のように合意されました。
①「ゲームのミッションへの貢献度」で決める
②問題が来たら「売り上げへの影響」で決める
上記の合意に対して、「優先順位を決めるまでもなく、問題はすぐに解決したい」という意見も出ます。
人によって価値観が違うことも見えてきます。面白いですね。
そして、優先順位を決め、タスクを消化し、できたらテスト担当に声をかける、というプロセスが生まれます。
『あまりプロセスを難しくしすぎると失敗しやすくなる』というアドバイスも講師から入ります。
また、問題が発生した場合はすぐに全員手を止めて話を聞く、というルールが追加されます。
プロセスは可視化され、その通りに進めていくことになりました。
ラウンド2
2.1. Plan
【開始0分】
全員で問題や追加要件を読み上げている間に、矢継ぎ早に問題が追加されていきます。
優先順位決めるためだけに、10分が費やされていきます。
【開始10分】
10分で一旦止めて、よし進めようとしたところでまた問題発生。講師がチームを考えさせ続けます。
問題を共有し終わったら、動き出します。
再度動き出し始めてからは速い。役割が決まってるためです。
テーブルの上に情報が載せきれず、床に情報を広げる人が出てきました。
2.2. Do
【開始4分】
実現する要件が多くなってきて、チェックすべきものも同様に多くなっているきます。
このタイミングでもチームに問題が発覚します。「リードエンジニア」の工数（制約）がボトルネックになっていたのです。
ボトルネック解消のために対策を施そうとするものの、対策そのものが全体の工数に収まらない...！
このような悩み、どこの現場でも起こりうることではないでしょうか。
【開始11分】
影響が軽微な問題が発生。すぐに共有されて、対応しないことが合意されます。
ギリギリまでやるタスクが決まらず、合意に至らないまま、終了。
2.3. ふりかえり(前半)
まずは事実の確認です。
【やったこと】
- プロセスを決めた
- 役割と責任を決めた
- 何かあったら声を出して止める
- プロセスが変わったので、やり方を変えた
これらのカイゼンが効果があったかというと…
結果は、売り上げも株価も減少でした。
【よかったこと】
- 課題が適切に共有された
- 課題がいっぱい降ってくることがわかった
- 可視化レベルがあがった。チェックサムOKが可視化された
- 工数の確認ができた
- 「構成確認」は完ぺきだったが、掛け持ちのため負荷が高い
- チェックは全員でやったが、できていない工程も
【いまひとつだったもの】
- 優先順位を全員で決めて止まっていた。優先順位上位のものを決めたら、動く、というのでもいいかもしれない
- プロジェクトごとに並べてみないと分からないことが多かった。複数の軸をどうやって使うかを考えないといけない
- 何が終わったかという可視化が出来ていない
- 問題がどんどん降ってきて、情報が増えた時に、全部机の上に表現できなくなる
Lunch
ここでランチを挟みます。
カオス会ではみんなでワイワイ話していましたが、この回は皆さん個別で食べに行ったようです。
2.3. ふりかえり(後半)
ランチ後のカイゼンタイム。
床メソッドを知っている人もいて、「床使ってみませんか」という発言が。
そして床へ...
床メソッドが広がっていく。
15分間床の整理が終わったら、CIO主導でこれまで各自が集めてきた情報の整理が行われていきます。
壁には、チェックサムの状況が可視化されました。
CIOから『作業をする前に声がけする』というのも共有されました。
床の使い方が共有され、Planスタート！
ラウンド3
3.1. Plan
作る要件が1分程度で決めて、行動に入っていきます。床だけでなく、ホワイトボードにはテストの制約が可視化され、一つ一つタスクを潰していく形へと変わっていきました。
テストの制約がOKになったものに付箋がつけられたり、複数人でチェックするようにしたり、と自然とチームができて進むようになってきます。
床で可視性が最高レベルまで上がると状況把握が一気に進みますね。
3.2. Do
時間が少なくなってきたところで問題が発生しても、すぐに問題が共有されて解決に動いていくように変化しました。
社長（講師）がいなくなったタイミングで『あのドア開かないようにしませんか？そうすれば新しい問題は起こりません』といった冗談が言われたり、要件が完成するたびに拍手が生まれたり、と心に余裕ができてきたようです。
チームは加速していきます。
要件を外そう、としたときに自然とカードを裏返しして表現したり、という機転も利くようになってきました。
写真：カードを裏返すメソッド
3.3. ふりかえり
【よかったこと】
- テスト工程の最適化
- 床による見える化（環境改善）
- 全員が動き続けている状態になった
- 自律型になった/多機能型になった
- リードタイムが早くなった
- 適宜ゴールの共有
成功に転じたことで、ふりかえりにて「カイゼン」が起こりにくくなってしまったように思います。
「何かを変えていこう」というよりも、「そのまま行こう」というような空気が流れていました。
プロセスをカイゼンするという話よりも、ゴールを達成するためにどうやって要件を実現するか、という方向の話が強くなっており、進め方のカイゼンは起こりませんでした。
ビジネス側にボトルネックは移動する、といってもまだその段階ではなかったように思います。
なお、結局この話も中途半端で終わってしまっています。
ふりかえりの時間ではカイゼンは行われず、プロダクトの作成が始まってしまいました。
ラウンド4
4.1. Plan
自然と役割が分かれ、3ラウンド目と同じ進め方で進んでいきます。
作業になっており、カイゼンもなく、特筆すべき事項はありません。
4.2. Do
10分ほど余り、やることがなくなってしまった様子を見て、講師から制限解除（後述）。
CIOから「残った要件について見積もりして考えてみるか」という提案があったものの、みんな疲れているのか、「現状でいいよね」ということになり終了しました。
この提案がつぶされたのは、個人的に非常に残念でした。
総ふりかえり
メンバーのふりかえりのまとめです。
- なぜ相手が出来ないのか、には相手にも背景や事情があることを知った。それを可視化したい。
- ビジネスの目標を見える化することで出来ることがある。組織の目標を可視化していきたい。
- チームとしての目的やミッションを共有して、それを果たしていくということを体験できた。
- DevOpsがビジネスサイドにどうインパクトを与えていくか、というのを考えていきたい。
- AgileやDevOpsを体験するというのがとても大事だと思った
- 開発目線でのDevOpsしか見ていなかったので、得るものがあった。まずは話すところから始めたい
- 自分のチーム内だけでのカイゼンはやっていたが、関係者と話してボトルネックを洗い出すのをやっていなかった。自分のチーム以外とも会話してみたい
- 実際に生まれる価値（金額）を考えながら仕事を進めるのは現場では難しいが、やる必要があると感じた
所感
チームが徐々に変化していく様子を見ていくことが出来ました。
今回はアジャイルを普段からやっている2人（CIO役、リードエンジニア役）がチームをリード・ファシリテートし、チームが良い方向へ向かっていきました。外からリードする人（CIO）、中からリードする人（リードエンジニア）の両面が合わさり、カイゼンのタイミングでいい変化が起こせていたのかなと思います。
また、ラウンドを経るごとに参加者同士のコミュニケーションが活性化し、情報の伝達が早くなっていくのを感じることが出来ました。
コミュニケーションが劇的に向上したのは床での可視化をした3ラウンド目から。
情報の透明性が保たれ、スピードが上がり、成功体験をしてからチームが活性化しています。
まずは可視化から始める、というのはよいパターンなのでしょうね。
また、悪いパターンとして、物事がうまく行き始めたときにカイゼンがストップしてしまったり、よりよい成果を求めようとする姿勢がチームとして途切れてしまう、というのもみることが出来ました。
チームのゴールやミッションを達成出来ていないにも関わらず、いい方向に転じたときにそれで満足してしまう。
これは何かしらのバイアスがあるのかもしれません。チームや組織で動く以上、注意しなければならないことでしょう。
モヤモヤした点
- 講師が学びを先取りして言っていたり、参加者の発言を途中で遮って言い換えをして伝えたい単語に無理やり結びつけていることが多く、学びを押し付けている感じがしてしまいました。ファシリテーターとしてのスタンスの違いなのでしょうけど...。
- ふりかえり中の講師のリードが強すぎて、誘導されている感じを強く受けました。
- 3ラウンド目のふりかえりでのカイゼンがなくスキップされてしまいました。スキップせずに、カイゼンに向かうようにファシリテートすべきだったのでは、と思います。
- 4ラウンド目で時間が余ったのですが、そこで講師側からの大幅な緩和処置が（本来は事前のラウンドでタスクが出来ていないと解除されない制限が解除）。制限が解除されたとしてもやることは作業の延長であるなら、時間と制約の中で、ほかに出来ることはないかを全員で検討するほうが実際のプロジェクトに近く、学びが多いのではないか、と感じていました。一部のメンバーはちゃぶ台をひっくり返されて白けてしまった人もいたのでは...。
まとめ
チームがどのように変化していくのか、というのを客観的に見つめていくよい機会でした。
カイゼンが止まる原因も1つ分かったので、いい知識を得られました。