フェニックスプロジェクト研修から学んだDevOps導入支援で重要な3つのコト
はじめに
7/26の火曜日、ITプレナーズ様主催のフェニックスプロジェクト DevOpsシミュレーション研修（以下、フェニックスプロジェクト研修と呼びます）の無料体験会に参加させていただきました。
これから詳しく感想を述べていきますが、大変素晴らしい研修でした。
今回は、研修の感想と、研修から学んだDevOpsの実践および導入支援でとりわけ重要と感じた3つの気づきを共有します。
フェニックスプロジェクト研修とは
フェニックスプロジェクト研修は、DevOps導入を小説形式で描いた書籍『The DevOps 逆転だ！究極の継続的デリバリー』を基にした集合研修です。
研修の目的は、架空の自動車部品製造販売会社「パーツアンリミテッド」社のフェニックスプロジェクトを成功させ、低迷する売上と株価のV字回復を果たすこと。
研修では、四半期に対応する1時間のラウンドが4回繰り返されます。
参加者はIT運用担当VP（ヴァイスプレジデント）、CISO（情報セキュリティ責任者）、CFO（財務責任者）、アプリケーション開発担当、ITサービスサポート担当、リードエンジニアなどの役割をそれぞれ担当します。
※ITプレナーズ様のHPより引用
DevOpsの原則を適用し、多大な改善と事業価値を達成するためにこのような課題やチャレンジに立ち向かう組織を描いたのが、Gene Kim、Kevin Behr、George Spaffordの書いた「The Phoenix Project（邦題：The DevOps 逆転だ！究極の継続的デリバリー）」です。
フェニックスプロジェクトのシミュレーションは、この革新的な書籍をベースに構成されており、参加者自らが書籍の流れを体験できる内容です。本コースは、特定のシナリオに基づいて次々と発生する課題に対処しながらDevOpsの適用について学べる、1日間の実践的なコースです。参加者は4つのラウンドの中で課題に対処し、振り返り、改善を施すサイクルを行い、実務の精度を高めていきます。
感想
ネタバレを避けるため内容について詳しく書けませんが、フェニックスプロジェクト研修は、DevOpsの原則やプラクティスについての座学を受け、実践するためのグループワークをこなす、といったよくあるDevOpsの研修とは全く異なりました。
座学の代わりにメンバーに与えられるのは、悲惨な会社の状況、非常に複雑なシステムの仕様、そして、無謀と思われる目標売上と目標株価のみです。
さらに、研修開始後も、セキュリティインシデントやシステム障害などのトラブルがメンバーに絶え間なく襲いかかります。
実際に私たちは、1日という短い研修の中で、原作小説さながらの下記の事態を経験することになりました。
この状況の中、メンバーは、講師からのヘルプを受けながらも、自らの気づきに基づいて業務を改善することを求められます。
- 現場に仕事のやり方を押し付けようとする経営者
- 仕事の進め方を巡るメンバー同士の対立
- 与えられた役割が果たせないことに悩むメンバー
- 改善の試みが逆効果になり、悪化するチームの雰囲気
- 属人化に気づきつつも、目先の仕事に囚われるメンバー
自分自身も、普段頭では理解しているつもりだったDevOpsの原則やプラクティスについて、あらためて深く意識し、体得するきっかけとなりました。
ここから、特に印象的だった3つの気づきを共有します。
- チームで目標を深く共有すること
- 相手への敬意と丁寧な説明
- 実験と失敗からの学びを促す文化づくり
1. チームで目標を深く共有すること
売上と株価の目標を与えられた直後の第一ラウンド。
ラウンドが始まってすぐ、メンバー全員が目標を忘れ、目の前の機能のリリースに集中しました。
また、メンバーが各自の作業が最重要だと主張し、すぐに収集がつかなくなりました。
第一ラウンド終了時、全員であれほど忙しく動き回ったのにも関わらず、何の機能もリリースできず、待っていたのは悲惨な売上と利益でした。
第一ラウンドで痛感したのは、チームで目標を深く共有することの重要性です。
プロダクトのビジョンなどの目標を組織やチームが深く共有していないと、自身やチームの作業が最重要だという執着につながり、メンバーや組織間の協力を難しくすることを痛感しました。
さらに、どうしても現場は目の前の作業と与えられた役割に集中しがちなため、しつこいくらい繰り返し共有しなければ目標が浸透しないことも強く印象に残りました。
実際、組織の目標が現場に浸透していないお客様も珍しくありません。
今後の支援でも、これまで以上に目標の共有を促していきたいと思いました。
2. 相手への敬意と丁寧な説明
今回のチームメンバーは、DevOps実践者と非実践者、開発とビジネスが入り混じる構成でした。
第一ラウンド終了後のふりかえりで、このままでは最終的に悲惨な結果を迎えるという空気が漂い始めた時、普段からDevOpsを実践するあるメンバーが「先にテストしよう、役割に囚われずモブワークしよう」とDevOpsの方法論を強く主張しました。
主張は、すんなりと受け入れられるどころか、DevOps非実践者側から激しい反発を買いました。
その後、講師の助けを借りながら、真っ先に改善すべきは仕事の進め方ではなく、「参加者同士の相互理解とコミュニケーション」ということに気づいた私たち。
相手の話を最後まで聞く、さらに、何らかのアイデアを提案する際は、「アイデアでどのような課題が解決されるか」ということセットで話すようにコミュニケーションを改善し、私たちはようやく、第二ラウンドでモブワークを試すことに合意できたのです。
アジャイル導入を支援する中で、組織には様々な立場の人がおり、その原則やプラクティスを一方的に主張するのは悪手だということに気づきます。
今回の研修を通じて、DevOps導入でも同様に、相手への敬意と丁寧な説明が不可欠ということを再認識しました。
- 第二ラウンド後の売上と株価。ソロからモブワークに変え、大幅に売上と株価が向上
3. 実験と失敗からの学びを促す文化づくり
第二ラウンドで機能の開発方法を掴んだように思えた私たちは、作業を並列させてより多くの機能をリリースするために、再びモブからソロワークに戻すことにしました。
そうして迎えた第三ラウンド。
次第にメンバーどうしで声を掛け合うことが減り、困ったことがあっても声をあげられなくなり、結果、ほとんど機能がリリースできないままタイムアップを迎えました。
第二ラウンドで上昇した売上と株価は、第三ラウンドで再度下降トレンドに突入しました。
ここで印象的だったのは、第三ラウンド後のふりかえりです。
第二ラウンドで白熱した「ソロか？ モブか？」の議論は消え、次の第四ラウンドではモブワークに戻すことに全員で即座に合意しました。
メンバーは自らの実験と失敗から、「役割に囚われず協調する」というDevOpsの原則の重要性を身をもって深く学んだのです。
結果、第四ラウンドでは、モブワークを基本としつつも、経営層と現場の役割分担も自然に生まれ、（目標には及びませんでしたが）過去最高の売上高と株価で研修を終えることができました。
私のようなDevOps導入支援者は、教科書に書かれた原則やプラクティスと言った「正解」を伝えることを重視しがちです。
もちろん「正解」を伝えることは重要ですが、正解をただ伝えることよりも、実験による失敗から学ぶ方が遥かに学びが深い場合があることを研修は教えてくれました。
さらに、研修や原作小説からは、組織やプロダクトやメンバーは千差万別であり、DevOps導入の唯一の正解が無いことも併せて学びました。
今後は、正解を伝えること以上に「実験と失敗からの学びを促す文化づくり」を意識してDevOpsの支援に臨みたいと考えています。
おわりに
今回は、フェニックスプロジェクト DevOpsシミュレーション研修無料体験会の感想と、そこから学んだ3つの気づきを書きました。
休む暇も無いハードな研修でしたが、随所で講師のフォローが入るため、これからDevOpsを導入する方や、社内でDevOps導入を検討している方、DevOps導入後にうまくいかないとお悩みの方々に強くお勧めしたい研修です。
ITプレナーズ様、本当にありがとうございました!!
※フェニックスプロジェクト研修についてのお問い合わせは、以下よりお願いします。
https://www.itpreneurs.co.jp/training/tpp/
