はじめに
こんにちは。スピーダ事業Product Teamの中嶋です。
今年のはじめから先月まで、大阪拠点の開発チームでお仕事をしていました。約半年ぶりに東京拠点での開発に戻り、どんなことがやれるのか少し楽しみにしている自分がいます。
さて、私たちProduct Teamでは、どこのチームでも1週間に1回ふりかえりを行っています。基本的には1週間というタイムボックスをふりかえり、その中で見つけた課題について深掘りし、アクションを立てて終わります*1。
ふりかえりのテーマはその都度その場で見つけて深掘りしていくのですが、大阪拠点の開発チームで、あえて「アジャイルのプラクティス」にテーマを絞ったふりかえりをやってみたところ、普段とは違う発見がありました。今回はそのことを書いてみようと思います。
実施するに至った背景
Product Teamにおけるふりかえり
まず、多くのチームが実践している基本的なふりかえりの型について、簡単にお話しします。
1週間のふりかえりは1時間と決めています。その時間の中で情報収集のアクティビティを行い、チームメンバーがそれぞれ付箋を出します。収集した中から一番関心の高いテーマを決め、それについてどんな要因があったのかを深掘っていきます*2。
その他、Product Teamにおけるふりかえりのカルチャーについては、以下の記事にも書かれていますのでよかったら読んでみてください。
大阪チームの状況
次に、大阪拠点の開発チーム（以下、大阪チーム）の状況を簡単に説明します。
大阪チームはまだ4人1チームのみという小規模体制で、私が所属していたタイミングでは以下のメンバー構成でした。
- ユーザベース歴6年目の私
- 私とほぼ同期のメンバー
- 去年10月にJoinしたメンバー
- 今年1月にJoinしたメンバー
10月と1月にJoinしたばかりの2人は、以前は別の現場でエンジニアをされていましたが、アジャイルな開発に対しての知見はそこまで多くなく、XPを常に実践している環境に私目線からだと不慣れな様子でした。
Product TeamにJoinしたメンバーは、初日からチームに入ってユーザーストーリーを取り、一緒に他のメンバーとペアプロを始めます。 その中で必要な環境のセットアップやTDDやペアプロの実践の仕方を見せてもらったり教えてもらったりしながら学んでいくことになります。
大阪チームでもそれは変わらず、一緒にペアプロをしながらアジャイルのプラクティスを毎日のように伝えていきました。その甲斐あって、ペアプロやTDDといった日常的によく使うプラクティスを一緒に実践していけるようになりました。
日常に溶け込みすぎたプラクティス
他方、数ヶ月経ってみて、ちらほらと気になることも増えてきました。
1日以上コミット&プッシュしていない
あるユーザーストーリーの開発を進めているとき、1日以上コミットをしていない状況が何回か続きました。
私たちは素早くユーザーに価値を届けるためにトランクベース開発を行っています。
ブランチを分ける運用をしないので、こまめにコミット・プッシュをしてCI/CDを動かして、ちゃんとビルドできることやテストが通ることを確認したいわけです。
1日以上コミットしていないということは、その間に隣のペアや他のチームがmainブランチへ開発したものをどんどん統合していくので、コンフリクトが起きるリスクが高まっていきます。また、コード差分が大きいと、何かしら問題が起きた時（ビルドができない、テストが通らない）に原因を調査するのにも時間が掛かりやすくなります。
（もちろん、ユーザーストーリー自体が大きくて滞留してしまっているという課題もあります）
パイプラインを回したら、すぐ別のストーリーに着手しがちになる
あるユーザーストーリーの開発が終わりコードをプッシュしてから、CI/CDを動かすのですが、動かした瞬間に別のストーリーを取ったり別のことをし始めることを何回か見かけました。
自分のやれることを探す姿勢は良いと思いますが、それは無闇に自分たちのコンテキストスイッチを増やすことに繋がります。
私たちは早く始めるより、早く終わらせることを大事にしています。いわゆるフロー効率を高めるといっても差し支えないと思いますが、ペアプロやカンバンでWIP制限を設けているのは、そういった効果を期待してのことでもあります。
だからこそ待ち時間を減らすために、ビルドやテスト実行を早くする・CI/CDの実行を早くするという10分ビルドのプラクティスを実践することが求められます。
パイプラインが長すぎて待てないというのは、それだけフィードバックが遅くなっているというサインだと考えます。
小出しに伝えていくだけでは足りない
上記で挙げた例以外にも色々あったりするのですが、これら一つひとつはとても小さなプラクティスです。
ペアプロやTDDのようにわかりやすいものではありませんが、こうした小さくてもアジャイルの価値観に基づく考え方・習慣はとても大切です。
そしてこれらは、コミットする・ビルドを待つといった日常の開発動作そのものに溶け込んでいます。溶け込んでいるがゆえに、「ちゃんとできているか？」と立ち止まって確認する機会はほとんどありません。
実際、週次のふりかえりをやっていても、それらが話し合うテーマとして取り上げられることは少ない印象でした。
それよりも関心のあるテーマが多かったというのが理由になるのですが、そもそもそういうプラクティスを知らないだけではないか。知ってるけど、うまく現実世界のエピソードと紐付いていないのではないかと思うようになりました。
アジャイルのプラクティスの説明は、入社してからのオンボーディングで伝えたり、ペアプロをやる中で都度伝えていくことはやっていました。
ただ、人は一度にすべてを覚えられるわけじゃないですし、日々開発をしている最中で伝えられても他の膨大な情報（開発で使用する技術・ユーザーストーリーにまつわるコンテキスト）に押し流されて忘れてしまうこともあるでしょう。
プラクティスの意味を考え、それを自分たちのチーム活動のエピソードと紐付けて腹落ちさせる時間が必要だと考えました。
それがアジャイルのプラクティスをテーマにしたふりかえりを実践しようと思った背景になります。
どのようにやったか
特別な時間を確保したわけではなく、いつもの週次ふりかえりの1時間枠をそのまま使いました。進め方は以下のとおりです。
- 『Clean Agile』*3に描かれているサークルオブライフの図とプラクティス名を、ホワイトボードに書き出す
- それぞれのプラクティスについて、「良かったこと」と「のびしろ」*4の付箋を出していく（ここまでが情報収集）
- メンバーそれぞれが気になっている付箋を1枚ずつピックアップし、リーンコーヒー*5形式で話す
- 話した中で次の週で実践できそうなアクションを決める
※以下、サークルオブライフの図（「エクストリームプログラミング―基本に立ち戻れ―」発表資料（28ページ）から引用）
普段のふりかえりとの違いは、情報収集の起点が「1週間の出来事」ではなく「プラクティスの一覧」になっていることです。目の前にプラクティスの名前が並んでいるので、「そういえばこれ、最近できてないよね」という気づきが引き出されやすくなります。
実際に出てきた付箋には、こんなものがありました。
- カンバンにあるTodo全体を見切れていないときがあり、優先度決めが不完全？（計画ゲーム）
- コードのプッシュ頻度が低めがち（継続的インテグレーション）
- 実装から書き始めてしまう（テスト駆動開発）
普段の週次のふりかえりでは出ていない付箋が出てきたり、ふりかえりをしながら「メタファーって？」「計画ゲームはプランニングのことでOK？」など質問が飛んでいるのが新鮮でした。
工夫したこと
情報収集の方法
情報収集ではサークルオブライフの絵を使いましたが、これはチームメンバーにとってわかりやすければ何でも良いと思っています。
最初はXP白本*6のプラクティスを列挙しようと思いましたが、導出プラクティスまで書こうとするとそれなりに数があるのと、ビジネス・チーム・エンジニアのプラクティスの関係性をわかりやすく表現しているサークルオブライフの方がふりかえりの情報収集としてはやりやすいだろうと思って選んでいます。
リーンコーヒーで対話の場をつくる
普段の週次のふりかえりでは、何かしら課題があってなぜそうなっているのか？というテーマが多いため、なぜなぜ分析を使って根本原因を探ることをやっています。
ただ今回はあえてリーンコーヒーという形でなるべく口頭で対話をする形にしました。
もともとは、実はそこまでプラクティスが腹落ちしてないのではないかという仮説から出発したふりかえりです。
なので、言葉として知っているプラクティスを、自分たちの開発活動のエピソードと紐付けること。よくわからないプラクティスがあれば質問したり教え合うこと。それらを主体にできれば良いと考えました。
ふりかえりの場でやりましたが、実際はワークに近い感じだったかなと思います。
効果：いつもと違う課題が見えてきた
やってみて一番の収穫は、普段の週次ふりかえりでは出てこなかった切り口の課題が見つかったことです。
リーンコーヒーで盛り上がったトピックのひとつが、先ほどの付箋の例にも挙げた「Todo全体を見切れていない」から発展した、カンバンについての話でした。
- カンバンにいろんな付箋が多く貼られていて、わかりづらい
- 結局どれが自分たちにとって優先なのかが、パッと見でわからない
カンバンは毎日目にしているものなのに、「1週間の出来事」を起点にしたふりかえりでは不思議と話題に上がってきませんでした。プラクティスの一覧を眺めるという切り口にしたことによる効果だと思っています。
このトピックからは、カンバンを整理・再設計するというアクションを立てました。その際、他のチームがどういうカンバン運用をしているのかをFigJam*7で見て回り、良さそうなものを参考にして自分たちのカンバンに取り入れています。
まとめ
今回は「アジャイルのプラクティス」というテーマに絞ったふりかえりを紹介しました。
Product Teamでは他にも、これまで書いたコードについてふりかえる「プログラミングふりかえり」という場を設けています。
1週間というタイムボックスから自由にテーマを見つけるふりかえりも好きなのですが、テーマをあらかじめ絞ることで、日常に溶け込んで見えづらくなったものを議論の俎上に載せられるのは、テーマを絞ったふりかえりならではの良さだと感じました。
特に、チームができて間もなかったり、アジャイルな開発にまだ慣れていないメンバーが多い（半数以上いるような）チームでは、プラクティスの実践度を定期的に棚卸しする機会として、一度やってみる価値があると思います。
読んでいただき、ありがとうございました。
🎓 学生の方へ | 1day インターンイベント開催！
Speeda ソフトウェアエンジニア職 のインターンイベントを開催します！
Speedaプロダクトチームではアジャイル開発手法の一種であるXP（エクストリームプログラミング）を実践しており、今回のインターンではプラクティスの中でも特徴的なペアプログラミングをみなさんに体験していただきます！
チーム開発を更に深めることができるペアプログラミングの経験は我々の文化を体験することや、今後のエンジニアとしての活動の幅を広げるきっかけになると思います。
少しでもご興味をお持ちいただけた方は、ぜひお気軽にエントリーください。
*1:クォーターごとに、チームで立てたOKRについてのふりかえりも行っています
*2:深掘るテーマは必ずしも課題だけではなく、上手くいったことをより強化するにはどうするか、という視点でテーマを決めるチームもあります
*3:Robert C. Martin著『Clean Agile 基本に立ち戻れ』。XPのプラクティス群が「サークルオブライフ」という図で紹介されています
*4:現状はまだ物足りなく、伸ばす余地があるところを前向きに呼ぶための言葉として使っています
*5:トピックごとに時間を区切って対話し、時間が来たら「続けるか、次の話題に移るか」を参加者の投票で決める進め方
*6:Kent Beck著『エクストリームプログラミング』の通称
*7:オンラインホワイトボードツール。Product Teamの多くのチームがカンバンをFigJam上で運用しています
