こんにちは。kintone開発チームの天野(@ama_ch)です。3ヶ月ほど前からスクラムマスターを始めました。
10/18(金)に@ryuzeeさんにサイボウズ東京オフィスにお越しいただき、kintone開発チームのメンバーでスクラムトレーニングを受講しました。
きっかけ
私が開発しているkintoneはクラウドサービスですが、サイボウズはパッケージ製品の開発でスタートした歴史があり、開発プロセスにもパッケージ時代の習慣が強く残っていました。
- 長大な要件リスト
- 実装と試験工程の分断
- 開発後期での手戻り
- etc...
もちろんこれまで手をこまねいていた訳ではなく、開発チーム内では次のような活動に取り組んできました。
- タイムボックス(イテレーション)を区切った開発
- テスト自動化の推進
- ビルドパイプラインの構築
- 開発者環境への継続的デリバリー
- ふりかえり
- KAIZEN DAY, KAIZEN合宿
しかしこうした活動の対象範囲は工程全体から見ると一部でしかなく、なかなか工程全体を改善することができていませんでした。最近はNecoプロジェクトといった開発主導の興味深いプロジェクトも進行する一方で、プロダクト開発チームはいわゆるウォータースクラムフォールの状態が続いていました。
https://www.scrumalliance.org/community/articles/2015/june/water-scrum-fal
自分がプロダクト開発チームの一員として、どうすれば開発プロセスを改善してユーザーに価値を届けることができるのか。開発プロセスやチーム文化について学んだ結果、スクラムをきちんと学んで実践することで実現できるのではないかという考えに至りました。
トレーニングプログラムの選定
当初は私が認定スクラムマスター(CSM)研修を受けようと考えていたのですが、
- 費用が高い(1名で約30万円)
- 普及のためにもチーム全員で受講したい
という理由で見送りました。チーム全員で受講可能なトレーニングプログラムとして、ryuzeeさんにお願いすることになりました。
実施したトレーニング内容
当日はryuzeeさんにサイボウズ東京オフィスにお越しいただき、1日かけて次のような内容でトレーニングを実施しました。
- アジャイル基礎
- 紙飛行機ワークショップ
- スクラム解説
- マルチタスクワークショップ
- 要求分析ワークショップ
- 質疑応答
設営中
当日は社内のテレビ会議システムでトレーニングの様子を中継し、大阪オフィスのメンバー数名がリモートで聴講しました。
座学
座学は午前と午後で大きく2つに分かれていました。
- アジャイル開発の基礎
- スクラム解説
座学で使用したスライドと似たものがryuzee.comのトレーニング概要ページにあります。
参加者のアジャイルやスクラムの理解度にはかなりバラつきがありましたが、基礎的なところから丁寧に解説してもらうことで1日で共通の理解を作ることができました。気軽に質問ができる空気だったので、基礎が理解できているメンバーは積極的に現場への適用方法を質問して理解を深めることができたのも良かったです。
後半のスクラム解説時に、スクラムマスターとは何かを説明するために下記の動画を上映しました。
Super Scrum Master - the power of scrum- 日本語字幕版
これが非常に分かりやすく、参加者に好評でした。その後も社内で他チームのメンバーに説明するために使われるなど、意外な広がりを見せております。
紙飛行機ワークショップ
トレーニングの中では複数回のワークショップを実施しました。中でも最初に行った紙飛行機ワークショップが印象的だったのでご紹介します。
- 5人のチームを作成
- 「1人で連続して折ってはいけない」などのルールに従いチームで紙飛行機を制作
- 3m飛んだ紙飛行機の数を競う
- 1回の制作をスプリントに見立て、見積もり→計画→制作→ふりかえりを実施する
- スプリントを4回繰り返す
製作中
最初はなかなか紙飛行機が飛ばず苦労したチームが多かったのですが、スプリントを繰り返すうちにだんだんと飛ぶようになり、見積もりの精度も改善したことが実感できました。
結果
またこのワークショップの教訓として、「明示されていないルールは破って構わない」というものがありました。例えば飛行機の発射場から遠いチームは不利なので近くに発射場を作るといった工夫です(残念ながらワークショップ中は気付きませんでしたが)。
感想
全体を通して非常に濃いトレーニングで、参加したメンバーの満足度も高かったです。
スクラムは理解は容易で習得は困難と言われますが、私自身も例に漏れず実践にあたり疑問に持っていたことが沢山ありました。ryuzeeさんに直接相談することで、チームのコンテキストに合わせて「こういう場合はどうするか」というケーススタディが深掘りできたのがとても良かったです。
ワークショップでは計画・ふりかえりのサイクルを回す重要性や、マルチタスクが与える悪影響など、アジャイルの前提となる重要な原則を学ぶことができました。
トレーニング後の変化
トレーニングを受けて終了ではなく、トレーニングがどのような行動の変化に繋がったかが重要です。現在も改善の途中ですが、その後起きた変化にも触れておきます。
色々なところで仕事の進め方について議論が生じるようになった
一番大きい変化として感じたのはこれでした。今までもそれぞれが頑張っていましたが、スクラムというお手本がインプットされたことで、色々なところでスクラムと照らし合わせて仕事の進め方について議論が生じるようになりました。
- バックログの書き方はこれでいいか
- スプリントプランニングのやり方は問題ないか
- 調査タスクはどう扱うべきか
- 不具合改修のあるべき姿はどんなものか
Readyの定義を作った
トレーニング前に「プランニング期間に何をすべきかが分かりにくい」という問題について議論しており、ちょうど良かったのでトレーニングで学んだReadyの定義を作ってみることにしました。
作ったばかりでまだ運用できていませんが、共通認識を得ることができたため今後取り掛かるアイテムの曖昧さはだいぶ軽減できるのではないかと期待しています。
Readyの定義についてはryuzeeさんご本人の解説記事が参考になります。
プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話 | Ryuzee.com
プロダクトバックログ改善プロジェクトが始まった
数年前から使っているkintoneで作ったバックログアプリが使いにくく、スクラムで期待するプロダクトバックログの役割が果たせていないことが分かりました。トレーニング後の議論でもここを問題視した意見が多かったため、プロダクトバックログを改善することが決まりました。
こちらも実際に改善するのはこれからですが、トレーニングによって共通の問題意識を作ることができ、改善のための一歩を踏み出すことができたのは非常に大きな成果だと考えています。
他にもたくさん
他にも多くの変化が起きています。この流れを維持して、変化を促進していきたいですね。
- バックログリファインメントをやることになった
- PMがスプリントレビューを主催するようになった
- スプリントプランニングで作業時間の見積もりをした
- 全体的に時間を守る意識が高まった
- スクラムマスター紹介ビデオが流行った
まとめ
開発プロセスを改善するためにryuzeeさんにスクラムトレーニングを実施していただきました。トレーニングをきっかけに良い変化が起きつつあります。スクラムマスターとして、この変化を後押しして価値のあるプロダクトを世に届けるチーム文化を作っていきたいと思います。
サイボウズは、開発プロセスも自分たちで議論して改善していくことができる開発文化を作ることができる環境です。
価値あるコードを書きたい方はぜひサイボウズへ！
cybozu.co.jp
