不安ゾーンにいた開発チームがラーニングゾーンに入るまで

はじめに

こんにちは。@oturu333 です。私はフリーランスエンジニアとしてモチベーションクラウドの開発チームに参画しています。

もともとEMをやっていたので、参画当初よりEM業務（組織やプロセスの改善など）に携わらせていただき、現在は複数ある開発チームの1つのPO業務も経験させていただいています。

今回はそのチームが2ヶ月で「不安ゾーン」を抜け「ラーニングゾーン」に入っていったお話をしたいと思います。

最初「自分たちは何でも屋なんで」と言っていたhotfixチームが、スクラムを取り入れ「もっとベロシティを上げられないか」「仕事を楽しめている」と言えるチームになるまでを語ります。

「不安ゾーン」「ラーニングゾーン」については、以下のブログが参考になります。

 

note.mu

「hotfixチーム」と言われたチーム

モチベーションクラウドには複数の開発チームがあり、それぞれのチームに名前を付ける文化があります。現在私が所属しているチームにも「ドラゴンハント」というチーム名がありました。

そのチームは当初「バグを直す」「お客様からのお問い合わせに対応する」ことをミッションとして与えられたチームでした。

バグをドラゴンと呼ぶあれで「ドラゴンハント」というチーム名になっています。

 

しかし「ドラゴンハント」というチーム名がありながら「hotfixチーム」と呼ばれることがありました。

まさに当初のドラゴンハントチームは「hotfixチーム」でした。

学びはなく、ただ期日通りバグを直すことにコミットし、チームは不安ゾーンのど真ん中でした。

そんな中、そのチームにPO補佐としてジョインすることとなりました。

タスク管理ツールの導入と状況の可視化

私がジョインしたときには、バグをスプレッドシートで管理していました。

過去はプロジェクト管理ツールを使っていましたが、諸々の事情で一時的にスプレッドシートで管理しているということでした。

スプレッドシートは秘伝のタレ状態。

• スプレッドシートを把握しているのがPOのみ
• POは進捗状況の把握だけで精一杯
• 内容がわからない
• エンジニアはスプレッドシートを更新したくないのでGitHub Issueとの二重管理
• 二重管理によるヌケモレ、ステータスの差分が散見
• 進捗共有のためのMTGに1h / 日を費やす

そこでまずは新たなプロジェクト管理ツールの導入を提案し、せっせと移行作業に勤しみつつ、運用プロセスを設定しました。

チームリーダー就任

2018年末くらいから、ドラゴンハントチームのチームリーダーとなりました。

プロジェクト管理ツールの移行完了から半月ほどで進捗把握秘伝のタレ問題は解消し、進捗共有MTGは 15〜30m / 日 というところまで抑えられるようになりました。

テクニカルサポートチームとの連携もスムーズになり、管理にかかる工数も徐々に減っていきました。

エンジニアもスプレッドシートを離れられた喜びに満ち溢れました。

それまでチームメンバーは流動的でしたが、1月よりチームメンバーも固定化され、以前のような大混乱期は越えられました。

 

この時期にはそれまで明確なログを残すこともしていなかったのを是正していました。

「ちゃんとログを残そう。ログを残せば良いことがある」。そのくらいの進捗でした。

チームビルディングワーク

1月22日（Slack漁った）、やっとチームのキックオフMTGをすることができました。

キックオフでやったことはマシュマロ・チャレンジと、「自分のキーワードを50出してみよう」というアクティビティです。

キーワードのアクティビティは以下を参考にしました。

gendai.ismedia.jp

 

マシュマロ・チャレンジにおいては終了後に組織の三要素の話に触れ、チームには共通の目的が必要だよね！このチームの目的ってみんななんだと思う？という問いかけをしました。

共通の目的のアップデート

チームメンバーそれぞれに「このチームの目的は何だと思う？」と問いかけたところ、以下のような回答が多かったです。

• バグを直す
• 何でも屋

そこに今自分たちが苦労している原因の根本であるプロセス、組織の改善を組み込むことを提案しました。

バグをなくすには、ただ直すだけではなくバグが起きにくい環境をつくらなくてはいけない。

属人化を解消しないといつまでもチャレンジができない。

共通の目的は「開発チームの『当たり前水準』を上げ、安定した運用をするための土台を作る」としました。

共通の目的をコミットメント化

• 開発プロセスを改善し、1回 / 月のリリースをデイリーでやれるようにすること
• スクラムを安定稼働させること
• 個人依存した作業を撲滅すること

などを盛り込み、それらを3ヶ月で達成するようマイルストーンを置きました。

厳しいかなぁと思いましたがチーム全員の合意を取ることができました。

hotfixから恒久対応へ

共通の目的を高く置いたことで「とりあえず」という思考がなくなり、

「こういう依頼が来ているんですが、このように対応したほうが良いと思う」

「この作業は手戻りが多いから、フォーマットを作ってスムーズに連携したい」

そのような会話が出てくるようになりました。

「スクラムブートキャンプ」輪読会の実施

これまでもモチベーションクラウドではスクラムを取り入れてきましたが、ドラゴンハントチームではまだやっていませんでした。（hotfixだったので）

あえて輪読会を行ったのは以下のよううな理由です。

• あらためてドラゴンハントチームでスクラムを取り入れるにあたって、共通の認識を持ってスタートしたい
• 自分たちはどのようにやっていくかを考えたい
• 会議体、ロールなどが形骸化しないように「目的」を捉えよう

ロール、会議体ごとにセクションを分け、それぞれ発表資料を作成し、LTしました。

 

そこでこれまでリーダーと自称していた私の業務が、スクラムを取り入れるとなるとPO兼SM兼開発チームという状態になってしまうことが議題となり、SMを他のメンバーがやると挙手してくれました。

そして私はPO兼開発チームとなりました。

SMとなった彼はスムーズに業務を進行するためのbotの作成などをすぐにやってくれました。

デイリーでのProblem収集

輪読会の中でSMから「Problemは一週間またなくてもいつでも言えば良いじゃない」という提案がありました。そうだなと。「フライングKPT」と呼んでいます（Kないですが）

思い立ったときにSlackからつぶやいてスプレッドシートに連携。スプリントレトロスペクティブで振り返るという手法を取り入れています。

忘れないうちにあがるのでたくさんあがってとても良いと思っています。

ここで収集したProblemからTry（解決）を探していくことにしています。

FDL

この記事を書こうと思ったのは、スプリントレトロスペクティブで「ファン・ダン・ラーン」をやってみたことがきっかけです。

qiita.com

フライングKPTとは別にこれをやってみようと思ったのは、チーム状況が良いのはなんとなく分かっているので、こういう明るい振り返り手法を取り入れてみようと思ったからです（あと、個人的な趣味と興味です）。

 

ファン・ダン・ラーンをやり、その中からKeepしたいことを抽出してネクストアクションを作ろうとしました。

では、KPTやれば良いじゃん！となるかもしれませんが、大きな違いはファン・ダン・ラーンをやると、チーム状況が可視化できることです。

• ファン & ダン & ラーン（ど真ん中）が多い = ラーニングゾーン
• ファンに絡む物が多い = 仕事を楽しめている、心理的安全性が高い、チームの雰囲気が良い
• ダンだけのものが少ない = ただただ作業が完了するだけではない（以前のhotfixチームではない）

また、 ファン・ダン・ラーンを経てKeepを抽出しようと提案したときに以下のような発言がありました。

• 以前と違って考えて仕事ができているから、学びがある

• もっとベロシティを上げられないか、もっと工夫できないか

Keepを出そうと思ったら、ポジティブなTryが生まれました。そしてすぐに着手。

ファン・ダン・ラーンをやったらうまく行くというわけではありませんが、今のチーム状況にはマッチしたのかなと考えています。

この1ヶ月強で起きた大きな変化を振り返る

「何でも屋のhotfixチーム」から「当たり前水準を上げるチーム」へ。

自分がやったことは共通の目的をアップデートしてファシリテーションをしただけですが、メンバーが大きく変化してくれました。

ファン・ダン・ラーンをやってみて、それを強く実感し、全部をまとめてみたくなりました。

今はプロセス改善が短期ゴールですが、今後CREチームにスケールしていけたら良いなと思っています。