動かないカンバンを動かすために取り組んできたこと

はじめに

この記事では私が所属しているチームで１年半ほどスクラム運営を改善してきたことについてまとめます。

チームについて

前提として私の所属しているチームは以下のようなものです。

• 社内インフラの導入・運用や、開発プロセスの改善といったことを目標にしているチーム
• コードを書く業務もありますが、それ以外の文書を作成することも多い。
• チームのサイズはマネージャ含めて4-6人程度
• 基本的にリモートワークをしている

スクラムの開始

チームが発足した当初、マネージャ（筆者とは別の人物です）がスクラムの資格を持っているということもあり、カンバンを利用したスクラム形式でタスクを進めていくことにしました。とはいえ、他のメンバーはアジャイルやスクラムに詳しいわけではなかったので、スクラムガイドを読み合わせてスクラムについて勉強しながら以下のようなスクラムルールを定めました。

• スプリントは２週間にする
• 2日に一度デイリー（？）スクラムを行う
• スプリントの開始時にプランニング、終了時に振り返り（スプリントレビューではない）を行う
• スクラムマスターやプロダクトオーナーを明確にしない
• チケットはGitHub Issues, カンバンはZenHubを利用する

今にして思えばなんちゃってスクラムもいいところですが、以下のような事情がありました。

• 1週間ではまともな進捗が出ないことが多い
• 業務上他部署とのミーティングが多く、リモートワーク主体ということもあり、同期イベントは最小限にしたい
• 並行して複数のプロジェクトを走らせる必要があり、それぞれ属人化もしているので専任のスクラムマスターやプロダクトオーナーを設けている余裕がない
• プロジェクトごとにステークホルダーが異なるため、まとめてスプリントレビューを開催できない

本当になんでスクラムやっているんだろう、という感じもしますが、それぞれの業務を変えることはすぐにはできないのでスクラムの方を合わせるしかないのです。

動かないカンバン、見えない進捗

さてそのように始めたスクラムなのですが、なかなかうまくはいきませんでした。

話すことがないデイリー

スクラムあるあるだと思うのですが、なかなかデイリーでの報告がうまくいきませんでした。
よくあるデイリーの例だと

Aさん「昨日は〇〇に取り組んでいました、特に課題はないです」
Bさん「昨日は□□に取り組んでいました。ちょっと遅れています」
Cさん「(ry

のような感じでした。業務が属人化しており、デイリーで報告しても特に解決策がうまれるわけではないので、報告するインセンティブが生まれにくいのです。

動かないカンバン

カンバン上でのチケットも基本的にはIn Progressにあるまま、完了まで特に更新がないということもよくあり、そのタスクがどの程度進んでいるのかがあまり他のメンバーに分かりにくい状態でした。
また、スクラムの途中で差し込みのタスクが発生して、カンバンに載せないままその作業をしているということもよくありました。

その結果、全然チケットが動かず、次のスプリントに持ち越し続けることが続いたり、何もないところから急に完了ステータスのチケットが積まれたりいて、なかなかカンバンを有効活用することができませんでした。

積読と化したプロダクトバックログ

メンバーが気づいたタイミングでプロダクトバックログに積むということを続けていたのですが、プロダクトオーナーが不在だったため、バックログのチケットが積み上がっていくだけで、整理がされておらず、スプリントプランニング時にプロダクトバックログを掘り返してスプリントバックログに積むという事態になっていました。徐々にやりたいけれど永遠に手をつけられないチケットが増えていきました。

改善の取り組み

スクラムがうまく回っていないという認識はチーム内で共有されていたので、スプリントごとの振り返りの時間でどのようにスクラムを改善できるのか話し合い、できるところから進めていきました。

うまくいったこと

モブプロの導入

チケットの属人化を解消するためにデイリーの後にチームメンバーが集まって詰まっているところを解消するモブプロの時間を作りました。モブプロを導入したことで、技術的なトラブル解消、文書のアウトライン作成、成果物のレビューの時間を短縮することができました。また、チーム内のコミュニケーションが増えたのも良かったと思います。

スプリントを１週間に短縮

初めは２週間だったスプリントですが、軌道修正を頻繁に行うために１週間に短縮しました。
これによって一時的に１スプリントで終わらないチケットも増えましたが、次第にチケットの粒度を細かくするようになり、１週間でもある程度の見える進捗が生まれるようになりました。

対応待ち状態の可視化

チケットがカンバン上で動かない原因の一つに、他部署のアクションがブロッカーになっているということがありました。他部署の進捗をコントロールすることはできないので自チームのパフォーマンス計測に影響が出ないようにしたいです。

そのため、Waitingカラムをカンバンに追加し、他部署の対応待ちとなった時点でWaiting状態に移し、そのチケットはそのスプリントのゴールから除外することにしました。
これにより、各自がどのタスクに取り組んでいるのかがより分かりやすくなりました。
また、他部署への依頼が集中しすぎないよう、一つの部署に複数の依頼を投げている場合、どの優先度で各依頼を解決すべきかチーム内で調整して依頼先のマネージャに伝えるようにしました。

差し込み案件の把握

私たちのチームでは、他部署から問い合わせによる差し込み業務が発生することがあります。例えば開発インフラのアドミン業務やインシデント対応、CICD設計の相談などです。
これらの業務はスプリント開始時には予測できず、スプリントのゴールを達成できない大きな要因となっていました。

そのため、差し込みチケットには「差し込み」というラベルをつけることとし、スプリントごとに何件の差込チケットが発生したかを計測することで、プランニング時にどの程度のバッファを用意しておけばよいか予測できるようにしました。

チケット起票フローの見直し

１週間でスプリントを回すためにはタスクを細かく分割してチケット化する必要があります。そうすると１週間で10-20枚くらいのチケットを起票するのですが、もともとは以下のような手順で起票していました。

1. カンバンの画面からチケットを起票する
2. 後で完了条件とタスクリストを書く
3. Epicや担当者、ストーリーポイントを埋める

このやり方だと、タイトルだけ起票したまま放置することが多く、デイリーでそのタスクがあとどのくらいで終わるのか分かりにくいという問題点がありました。

そのため、GitHubのIssueのテンプレート機能をつかって、テンプレートを指定した起票リンクをスラックチャンネルにブックマークするようにして以下の手順でチケットを起票するようにしました。

1. ブックマークからチケット起票リンクを開く
2. フォームに完了条件やタスクリストを埋めて起票する
3. あとでEpicや担当者、ストーリーポイントを埋める

という手順になり、起票した時点で最低限の項目は埋まっているため、少ない手間でチケットの内容を充実させることができました。

レビュープロセスの可視化

スクラムをうまく回すために、レビューを頻繁に行うことは重要です。
レビューによって各メンバーがどのように考えているか明確になり、フィードバックを受けて成果物を改善することができます。しかし実際にはレビューリクエストを投げてもなかなかレビューしてもらえないということがよくありました。そのため、まずは計測をするためにコードレビューのワークフローをSlackのワークフロービルダーを使って定義しました。ワークフロービルダーを用いた理由は、ソースコードに限らず、作成したスライドや文書などのレビューも同じワークフローでできるようにするためです。

1. [申請者] PRを作成したのち、Slackのワークフローを起票する
2. [申請者] フォームにPRのURLなどを入力し送信する
3. [申請者] カンバン上でチケットを「In Review」にする
4. [ワークフロービルダー] スプレッドシートにフォームデータを追記する
5. [レビュワー] ワークフロービルダーから通知を受けてコードレビューし、完了したらワークフローの承認ボタンを押す
6. [ワークフロービルダー] スプレッドシート上のステータスを更新する

このようにすることでスプレッドシート上でレビュー状況を確認することができるようになり、日時で未完了のコードレビューをリマインドすることで、毎日レビューリクエストを確認し滞留を減らすことができました。
また、最終的にはスプレッドシートのデータからLookerStudioでダッシュボードを作成し、レビューのリードタイムの分布や、コードレビューの作成量やレビュー量を人毎に確認できるようになりました。

レビュープロセスを作ったことで、デイリーでのレビュー依頼やリマインドのようなコミュニケーションコストが減り、小さな成果物でもチーム全体で頻繁に確認しあうようになりました。

レビュープロセスの見直し

レビュープロセスを運用してみると、PR作成で多くの修正コメントがついた場合にPR作成者の作業待ちなのか、レビュー待ちなのか分かりにくいという問題点がありました。そのため、コードレビューのプロセスを見直し、レビュワーがコメントをつけた時点でレビュー完了とし、修正コメントがついた場合はチケットのステータスを「In Review」から「In Progress」に戻すという運用に変えました。

この変更によって「In Reviewにあるもの」＝「レビュー待ち」であり、カンバン上での確認が簡単になりました。スプレッドシート上でのレビューの滞留も3-4日から1-2日となり、コードレビューを依頼されたら手が開き次第みてコメントをつける、という運用ができるようになってきました。

プロジェクトごとのオーナーとプロジェクトゴール設定

私たちのチームで複数のプロジェクトを並行して走らせています。しかしプロジェクト全体を俯瞰して優先度を決める役割の人を（リソースの問題で）アサインできていません。そうするとタスクはひたすらこなしているのにプロジェクトとしてはうまく進んでいないという問題がありました。そのため、以下のように運用を変更しました。

• 各プロジェクトにオーナーをアサインする
• オーナーは担当プロダクトのバックログ整理に責任を負う
• 月に一回程度、チーム全体でプロジェクトの振り返りを行い、次の月の目標を立てる

このようにすることで、プロジェクトの進み具合がわかるようになり、「このプロジェクトのマイルストーンを達成したいからこのスプリントでは優先して取り組みたい」と言った話をプランニング時にできるようになりました。

（まだ）うまくいっていないこと

属人化の解消

いくつかのプロジェクトでは属人化が解消されていないため、同じカンバンを共有しているものの、スクラムでやるメリットを得られていないことがあります。属人化を解消するには業務手順書を作成したりOJTでキャッチアップしたりと無視できないコストがかかり、プロジェクトを進めながら属人化を解消するのは容易ではありません。
解消の道筋を立てるため、スプリントで一定の工数を確保して業務ドキュメントの作成を進めたり、チームで議論したりしています。

定量的な見積もりに基づくロードマップ

スプリントでベロシティを計測し、その値自体は安定してきています。一方で将来の見通しという意味では一ヶ月の見通しを立てていますが、あくまで経験と勘によるもので、ストーリーポイントを用いた定量的な見積もりはできていません。メンバーが徐々にスクラムに慣れてきていた今後、小さめのプロジェクトから始めていきたいです。

終わりに

スクラムを始めて一年半ほどですが、なかなか理想のスクラムには辿り着かないものです。スクラムによって生産性が上がったかというと、そこまで劇的な変化はないなというのが率直な感想です。
一方で、働きやすさやチームの安定感という意味ではスクラムの効果はよく出ていると思います。改善を進めたことでカンバンがよく動くようになりましたし、カンバンから各メンバーの状態が読み取れるようになり、より有機的に立ち回ることができるようになりました。

スプリントごとに振り返りを行い、運用方法の改善を根気強く進めていくことで理想のスクラムに近づいていくのだと思います。ここで紹介した運用方法が誰かの参考になれば幸いです。