本日、「フェニックスプロジェクト」という名前の研修に参加してきました。
内容としては、以下の「ジーン・キム」氏の書籍「The Phoenix Project(邦題:The DevOps 逆転だ！究極の継続的デリバリー)」に記載のあるような内容を 実際に参加者に役割を割り当て、ロールプレイしていく、というものです。
「The DevOps 逆転だ！究極の継続デリバリー」のamazonへのリンク
なので、実際に参加しよう！と思われる方は、基本的にネタバレになるので 読まずに参加されるほうが楽しめると思います。
あんまり詳しく書くとまずいので、ここでは、ざっくりとした概要と研修を受講した感想を書きたいと思います。
見返してみると結構ネタバレ要素がありました。ご了承ください。
研修の概要
参加メンバーは、各々別の役割に割り当てられる。
- CEO
- CISO
- CFO
- 営業部長
- 人事【←私が選んだ役割】
- エンジニア部門リーダー(なんとかVPでしたが失念…)
- アプリケーションエンジニア
- ITサポート
- リードエンジニア(細かい名前は違ったはず…技術リーダー的な人)
- テストエンジニア
- 変更管理
各々の手元には、カードが配られる。
- カードの種類や内容は、各役割によってさまざま。
- 共通するのは、各々の役割を示した大きなカード。結構重要な情報が書かれている。(手元にあるのは自分の役割説明のカードだけ）
- 経営層よりの役割には「〇〇機能追加」とか。それをやったらいくらプラスとか、いつまでにやらないと継続マイナスとか。
- 現場よりの役割には、「〇〇メンテナンス」とか。それの工数何点、とか。サーバシステムのバージョン情報とか。
- 人事の役割には、「給与システム更新」とか「社員増員」とか。
カードは、突然ファシリテーションされてる方から渡されたりする。(期の途中とか、終了直前とかにも容赦なく降ってくる)
- トラブル系のカードとか
- CEOからのメールとか
- 逆に、状況を改善できるチャンスカードとか（期が変わったり、特定の条件を満たさないと出てこないカードもあり。）
各々の役割には、その期間内に稼働できる最大の工数が決められている。
しっかり他の人の役割も読まないと把握できない稼働があったりする（自分のだけ読んでても気がつけない）→この時点から情報共有が重要
研修の時間を4期に分けて、1期ごとに、その期に完了できたプロジェクトに応じて、売り上げ/株価が変動する
- 最初に売り上げ目標を提示され、4期完了後にそれらを達成することが目標
- 期の中も、大きく4つのフェーズに分かれる。それらを繰り返していくイメージ。
- 準備(ふりかえり、改善)
- 計画(どのような方針で進めるかなどの話し合い)
- 実行(実施する想定のプロジェクトを選択して、動かしてみて問題ないかなどを試算・チェックし、実際に実施するプロジェクトを選択する）
- 採点・成績発表・講評
感想
普段は開発部門にいないこともあり、アジャイル開発というものには本以外では触れることはありませんでしたが、 実際に現場にいるような雰囲気でシミュレーションをすることができました。
役割としては【人事】という、比較的現場とは縁遠そうな役割を選択してみて、 普段と違う視点で見た時にどのように見えるのか、ということを体験しようと考えてみました。
詳細は記載しませんが、人事部門に配られるカードは 「プロジェクトを上手く進めるためのカード」というよりは 「外的要因などで発生する機能追加などのトリガーを引くカード」であり、 「このカード出すと現場から嫌われそうだけど、これやらないと売り上げ落ちるんだよな」とか 「このカード出さないと今後の会社運営ができないんだよな」とか思いながら、 【今期は申し訳ないけどこれをやりたい！】などと主張したりしていました。 実際の人事部門の方々も、そういった悩みはあるんだろうなあと、 これまであまり協力的ではなかったことを反省したりもしました。
参加者の方々は、アジャイル開発を現在進行形でやっている人、過去にやってみて失敗した人、全く経験がない人など 様々な職種・経験値の人が参加していましたが、皆さんそれぞれ楽しんで積極的に参加されている印象でした。 振り返りなどの際に、経験者の方々から出てくる発言などは、実際の経験からくる改善案などが多かったのですが、 毎回改善してもよくならない部分があったりすると、うまくアジャイルを回すには本当に準備・計画・改善が重要なんだなあと感じました。 最終的には、振り返りなどは定着したものの、効率よくウォーターフォールを回した、という形で終わってしまったように思います。
同研修は、特にこれからアジャイルを進めていこう！という中で、始める前に体験をしてみたり、 今実際にアジャイルをやっているけどうまくいかないな、という人たちが新たな気付きを得るためには、 非常に有用な研修だと思いました。興味のある方は研修を開催されている業者さん（今回はSB C&Sさんホスト）にお声がけしてみてください。
得られたこと
可視化(カンバン)の重要性の実感
普段がインフラ屋さんの仕事なのですが、これまでカンバンを活用するようなことはあまりありませんでした。 ただ、短納期でクリティカルパスがきわどかったり、多くの人が関わる大型プロジェクトでは、活用する価値はありそうだなと思いました。
【7/28追記 大型、と書きましたが小規模チームでも可視化の重要性は変わらないな、と思いました。書いてた当時は研修の実態はもっと大規模組織だろうと勝手に補完してましたが、少なくとも3人以上くらいなら可視化も十分に意味があると思いました。】
これまでは割とPM/PLの個人スキルで回していた感が強いので、それは「ほかの人には全体は見えていない」ということでもあるのかなあと。 「なんで動いてくれないんだろう」とか思っていても「動ける材料（情報）がない」という状態だったように思い、 成長の芽を摘んでいることにもつながるなあと、色々と反省するところがあります。
役員層から降りてくる方針に対して具体的なKPIを提示して意思統一をはかったりすることも、 達成目標が明確になるという意味で非常に重要に感じました。 また、「RACIチャート」という道具も教えていただきました。 これは、役割やプロセスごとの責任モデルを明確する、というものです。 これも非常に参考になったので、カンバンと合わせて使ってみたいと思いました。 詳細については、以下のページをご参照ください。
できるチャンスがあれば、インフラ系でも色々と実践してみようと思います。
明日からやること
工数には限度があり、それがボトルネックになっては折角の計画も水の泡です。 もちろん、それがすべて、というつもりは毛頭ありませんが、 やはり手動でやるのではなく、「自動化」というものは非常に重要だと思います。 特に、世の中の発展が早くなり、顧客の要求の変化が激しい現代においては、 特に重要になってくるファクターだと思いました。
今はAnsibleに傾いているところはありますが、ほかにも様々な分野に目を向けてみたいと改めて思いました。
【7/28追記 カイゼン・ジャーニーを読んでいても、会社のレポート書いていても、やはり手段よりも可視化のほうが先だなと思いました。個人として実現手段を追いかけるのは変わりませんが、仕事では可視化とふりかえりを始めていきたいと思いました。】
反省点
与えられた役割について
私の役割と、もう一つの役割カードには、予め通期の事業計画的な内容が記されていました。 ただ、最初に配られた目に見えるカードに集中してしまい、事業計画の実施そのものの検討が疎かになっていました。 これも仕掛けの一部だと思うのですが、執行部系は目に見えているものだけに踊らされずに、今後のロードマップをしっかり見据えた上で、早い段階でそれを皆に共有すればまた違った結果になったのではないかなあと思います。
全体的な進行について
ファシリテーターの方が色々とアドバイスをくれたり、メインで引っ張ってくれた方がいたりと、前に進むこと自体は出来たのですが、例えば最後の期では、若干ツールに踊らされていた感もありますし、リーダーの進め方に関しても、ちょっと待って、と言うことはできたはずです。
目的は、目標の達成であって、ツールの導入、活用ではないわけで。
このあたりもansible活用を含む実際のdevops現場で起こりがちな話なんだろうなあと思いました。
振り返りの目的は、立ち止まって冷静にこれまでのこと、これからのことを考えること。
個人として新しいツールそのものが大好きなので、割と陥りがちだなと改めて反省しました。
本当に必要なのは何か。場合によってはアジャイルも向いていなかった、もとのやり方で進めよう、というのも答えの一つとしてあるはずです。
見極めって大事だなと思いました。
本音
色々とansible他の学習をしてはいるものの、手を動かす時間が取れていないのが実情です。 これは、自分の性格上、やはりざっくりとでもスケジュールを決めないと進まないだろうなあと思います。 せめて四半期ごとの目標は立てて、無理のない範囲で時間を作って取り組んでいこうと思います。
