The Phoenix Project : 自社の情報システムの開発・運営を体験するワークショップ

ITプレナーズさんで主催しているDevOpsの体験型研修がありまして、見学させていただきました。

この研修はオランダに本拠をおく GamingWorks 社が開発したワークショップをITプレナーズさんが日本語化(のお手伝い)をしたものです。GamingWorks 社はAgileやプロマネ向けのゲーム形式研修を手がけているようなので、今後の拡充が期待されます。

https://www.gamingworks.nl/business-simulations/the-phoenix-project/

継続的デリバリーの先の世界

ここでいう DevOpsについては、Phoenix Project を参考にしていただくとよいかと思います。当初の DevOps の定義はインフラやデプロイの自動化を中心に考えられたものですが、サイロ化が進行した会社が本当に変化のスピードを上げるためには、組織間の連携や会社全体のプロセス見直しが必要、ということになり、こちらを取り扱う本が多くなっています。

The DevOps 逆転だ!

The DevOps ハンドブック 理論・原則・実践のすべて

改善すると次の壁が見えてくる

アジャイル開発の現場では、チーム開発をはじめてしばらくやっていると、だんだんデプロイが問題なくなり、次は開発や品質がボトルネックになり、そこも改善していくと、次はプロダクトオーナーが問題になる(バックログがジリ貧)、というのが黄金パターンのように感じます。得意なところ、手の届くところから初めていくと、だんだんその先にボトルネックが移動していくんですね。

以下の例は私が一時期やっていた流れなのですが、このパターンは多いかなと思います。

1. バージョン管理や開発環境を整備して、常時結合をする。
2. インフラを整備し、デプロイを自動化し、開発環境と本番環境の差異を縮める。
3. 開発の人員安定化とスキル習熟が進み、品質が安定化する。
4. プロダクトバックログの洗練が進む。不要なものを積み込む習慣がなくなる。新たな要望に即応できるようになる。
5. 新しいビジネス施策に人員追加なしで対応できるようになる。イノベーションに継続的に対応できるようになる。

自分のチームがうまくいったあとにぶつかる壁

後半で特に大事になってくるのが組織内の連携です。連携というと「みんなでやる」感じに聞こえるかもしれませんが、実際のところは全員にお願いして「気持ちよく動いてもらうように計らう」動きが必要になります。相手を尊敬・理解して、こちらを信じてもらって、自律的に動いてもらう。この部分は、なかなか外部のコーチには難しくて、社内の人の信頼貯金を試されるところかなと思います。

もし自分自身や仲間が十分な信頼貯金を持っていれば、バリューストリームマップのワークショップをしてデプロイや運用のムダをみんなで省くように改善を進めていく、とか選択肢が見えてくるのですが、信頼貯金がないとなかなかうまく始めにくいです。

業務ITシステムを題材に

人事システム、給与システムやPOSシステムなど、実際によくある業務ITシステムを題材に、全社のプロジェクトを進めるのがワークショップの本線です。

さまざまな役割の人と一緒に体験する

ワークショップのいいところは、自分だけでなく、他の人も一緒に参加できるところです。一人だけ研修を受けて他の人に全部伝えるのはかなり無理ゲーですので、関係者と一緒に参加して、やりながら実際の打ち手を考えていくことができれば、高速にトライアンドエラーを繰り返すことができるようになります。組織の課題は組織ごとに違いますので、それぞれで試行するしかありません。

共犯関係を作る

実践的なワークショップを一緒に体験し、議論したり苦労したりすると、共犯関係ができます。同じ場所で同じことを学んで、語り合った仲というのは、その人が会社にいる限り、宝になるでしょう。私たち vs あの人たち、ではなく、問題 vs 私たちの関係になりやすくなります。

お金のことを考える

あと、これは日本の開発コミュニティの特徴なのかなと思いますが、お金の流れを把握していない時があります。マネジメントですら企業会計がわかってない人も結構いるので、なかなか難しいところなのですが、売上とコストは連動しているものなので、感覚を掴んで、施策を人任せ(またはブラックボックス)にせず、一緒に考えていける組織文化を育めれば、より健全に経営できるようになるのではないかと思います。

役割に分かれて実際にITプロジェクトを進行していく

CFOの視点としてどうしていくか？必要な情報システムの予算配分や、当面のプロジェクト進行をどうしていくのか。みんなの意見がどうか。役割分担を変えるとどのように次のイテレーションでのアウトプットが変化するか、優先順位を変えるべきか、各役割に分かれて議論しながら進めていきます。

タイムボックス: 計画とふりかえりの力

ワークショップでは定期的に計画とふりかえりを入れていきます。次にどのような優先順位で進めるのか、前のイテレーションの結果を受けてもっとよくできるところはどこか。

まや、最後に全体のふりかえりを通じて、今日何を学んだのか、持って帰れるものはなにかを話し合います。

緊急の問題に対処し、計画に反映する

プロジェクトが無風で進むことはほとんどありません。問題が起きた時こそ、組織の力が試されるともいえます。緊急の作業を、計画していた作業とどうバランスするのか。どのように意思決定していくのか、練習していきます。しかも障害というのは重なるもので...。時間は刻々と過ぎていき、議論する時間も、対応する時間を削っていきます。なにを諦め、なにを守るのか....。

「ooとxxはやめることになりました」「えっ？なになに？じゃあ、aa は？」「それは残るみたいです」「わっ、残り5分」「はーい、まとめまーす。aaとbbは残します」「えっと、それでも溢れてます」「おっと、どうしようか」

とにかく歩き回る、とにかく声をかける

一つの部屋でワークショップで、部署間のコミュニケーションをシミュレートします。

情報は足で集める...というのは昔から言われることですが、リアルタイムで起きている課題に複数の担当間で調整しながら対応するには、歩き回って情報を見回し、声をかけて情報を確認するのが一番早く、必然的に歩き回って話し合いながら進みます。

全体ふりかえりで学びを確認する

最後に全体ふりかえりで今日の学びを確認をします。見学した回では、以下のような意見が出ていました。

• 「ふりかえりはやっていたが、ファシリテートや質問で深掘りすることができていなかったことに気づいた」
• 「他の担当に対して、上から目線でなく、相手の立場に立ってコミュニケーションすることの重要性を再認識した。」
• 「監査対応や標準化の意味がわかった」
• 「システム投資にビジネス側の視点を入れることが重要だと思った」
• 「3回目のイテレーションで、進め方を見直して改善を考えることができた」
• 「IT部門に勤務しているが、ユーザー部門に参加してほしい」
• 「ビジネス部門、IT部門、管理部門でどのように同期を取るのかがわかった」
• 「仕事を進めるのが楽しいって思えた。これが働き方改革なのでは」

いつも一緒に仕事していない他部門の人と話し合うきっかけとしてもいいでしょう。意外と議論やファシリテートが上手い同僚を発見することになるかもしれません。

技術的負債の根源にある相互無理解をつぶす

技術的負債が多くなるのは、開発者以上に、マネジメントが無理解であることが原因だということが多いのではないかと思います。解消するためのコストを取りにくい、評価されにくい、理解されない。その結果、次の手が打ちにくくなってしまうのですが、その領域に詳しくない人にはぱっと見、わからないものです(基礎的理解がない人に、わかるように説明することも難しいものです)。その辺りをちゃんと見抜く眼力や、他の専門家たちとの人間関係を築いていくことが重要になってきます。

さまざまな視点で組織を見直そう

一歩引いたところから、いくつかの視点を取り入れて、自分たちの現状を見つめ直すために、こうした研修やワークショップに参加する機会をぜひ利用していただければと思います。

おまけ : 組織で新しいことを進めたい方へ

組織内でさまざまな人を巻き込んでいくなら、この本がバイブルだと思っています。モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary の Chris Lucian さんもオススメしてました！

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

電子版が出てました！

Fearless Changeアジャイルに効く〜アイデアを組織に広めるための48のパターン【電子書籍】[ Mary Lynn Manns ]

なお、研修の問い合わせ先はこちらだそうです。

講師育成含めた研修受講にご興味がある方

株式会社ITプレナーズジャパン・アジアパシフィック

https://www.itpreneurs.co.jp/contact-us/

純粋な研修受講にご興味がある方

クリエーションライン株式会社

https://www.creationline.com/contact