アンチパターン “ゴールが延び続けるスクラム”
チームやプロジェクトを率いる立場で意識していることの1つに、「メンバーがタスクをやり切ったと継続的に感じられる仕組み作り」がある。特にスクラムを採用している場合は ”前に進んでいる感” を継続的に醸成していく事も欠かしてはいけないと思っている。ただ現実にはこの観点は悪気なく疎かになってしまうケースが（自他共に）多いという感覚がある。
Pull Requestレビューを例にしてみる。2週間スプリントのアジャイルチームでとあるプロジェクトの主担当として開発をリードしているエンジニア氏。仕様検討・周囲との調整・実装を頑張ってPull Request作成まで漕ぎ着けた。エンジニアは一旦ココで”仮達成感”に浸る（と、個人的に思っている）。そしてレビュワーにレビューを依頼して、反応を待つ。のだが。。。
スプリント1: 「進捗してます」
「pullreqレビューをassignされたエンジニア程、別件で忙しい」
そうです（※RIP志村けんで）。何故かpullreqレビューをassignされるエンジニアは基本的に他の仕事で忙しいケースが多い。古代ナントカ帝国が起源とされるこの謎は、hoge万年経過した今もその根本原因が解明されておらず、その謎を探るべく我々取材班はアマゾンの奥地へとry。
時は流れ2020年春、都内某所では「レビュワーが忙しくて、なかなかレビューが進まない」というシーンが再現されてしまっている。主担当氏は忙しいレビュワーに「まだ〜、まだ〜」と駄々をこね続ける訳にもいかず、別タスクや改修タスクを片付けながらレビューを待つ。
迎えたスプリントレビューの場で、主担当氏は「◯◯案件についてですが、実装は完了してpullreqレビュー待ち。というステータスです」と報告する。
レビュワー氏「（あ、忘れてた…）」
スクラムマスター？氏「りょーかーい」
スプリント2: 「進捗して、、、ますかね？」
そうしてレビューを待っている最中、とある要件追加が発生した。もし私がPM or リーダーの立場なら、このタイミングで「まず仕上がってるpullreqのレビュー → mergeを終わらせられないか？」と主担当氏に持ちかけるだろう。pullreqの現状からの換算でdiffが+30%レベル、それなりの規模の追加実装となるが、まだリリース前という事もあり先延ばしにする強い理由が見当たらず、当初リリース予定日を目指して追加実装する事となった。主担当氏は当初リリース予定日の達成可能性を探りつつ、追加実装を始める。
同じタイミングでようやくレビューに着手できる時間が取れたレビュワー氏、待たせてしまった分を取り返すべくレビューを進める。のだが、レビューの最中リアルタイムに大規模なcommitが1つ2つ…と重なってくる。投下したレビューコメントが無慈悲に “outdated” のアイコンと共にアップデートされる。訝しみつつ空気を読んだレビュワー氏は、
との迷言を残し、assignされたレビューを垂直落下式ブレーンバスターでPENDINGする。
迎えたスプリントレビューの場、主担当氏はdiffだけ膨らんでレビューが進んでいないpullreqを眺めつつも「◯◯案件についてですが、、もうすぐ追加実装も完了見込みです。pullreqレビューは引き続き待ちというステータスです」と報告する。
レビュワー氏「（えっ？）」
スクラムマスター？氏「りょーかーい」
スプリント3: 「進捗ダメです」
追加実装も目処が立ちつつ並行してレビューを待っている頃、社内で「共通huga」なるライブラリが今後の全社統一方針という立て付けでリリースされた。「現在開発中のプロジェクトに於いても、特段の理由が無い限りは踏襲をお願いします」との社内通達。「うわっ、、このタイミングかよ。。。」という心の声に蓋をしつつ、進捗と納期のあいだでエンヤを熱唱しながらリスケの絵を描く主担当氏。
が、このプロジェクトでは「レビューが始まっているpullreqに修正を重ねつつ追加対応を行う」という運びとなった、としよう。<s>使い方がよく分からない</s> 共通hugaなるものへの対応をpullreqに粛々と重ねていく主担当氏。この時点でdiffの規模は当初から+70%程度まで膨らんでしまっている。スプリント1で感じた”仮達成感”など最早微塵も残っておらず、42.195kmのマラソンを42.194kmまで走りきった地点で「どこでもドア〜」という大山のぶ代のダミ声と共にスタート地点にワープで引きずり戻された気分である。そうして主担当氏が修正を積み重ねていくpullreqの通知を、希望入団枠( ) という選ばれし者の立場でメールにて受け取り続けるレビュワー氏。
迎えたスプリントレビューの場、主担当氏は吐血しながら対応中の共通huga対応が所々に混ざり始めているpullreqを手に取りつつ「殿、、、◯◯案件についてでござりまするが、、あっ、違、、◯◯案件についてですが、共通huga対応にちょっと手こずっておりまして、進捗が芳しくありません。来週前半にはpullreqレビューも可能な状態になる見込みです。レビュワーさん、申し訳ありませんがレビューの方ちょっとお急ぎ目でお願いします！（( ｰ`дｰ´)ｷﾘｯ」
レビュワー氏「（( ｰ`дｰ´)ｷﾘｯ とは？）」
スクラムマスター？氏「（あれ？順調って言うてなかったっけ？） りょーかーい」
スプリント4: 「すみませんすみません」
共通hugaライブラリへの対応もようやく目処が立ち始めた頃、PdMから「営業から◯◯という機能が欲しいって話が挙がってまして、どうにかリリースにねじ込めないっすかね？」という相談（という名のオブラートに包まれた実質作業依頼）が飛び込んでくる。
※これ以降は筆者号泣の為、執筆中止
レビュワー氏「（いつ終わるねんこの実装…）」
スクラムマスター？安西先生「諦めたらそこで試合終了や！助けられる事があったら幾らでも言うてくれ！」
ゴールテープは適度な距離感で設置する
チームの力やアウトプット最大化に責任がある立場（≒スクラムマスター）の場合、極力マクロな視点でプロジェクト全体を俯瞰しようとしてしまうし、それ自体は間違ってはいない。ただ森ばかり見て木を見ないでいると、コツコツと木に水をやり続けている立場への配慮がどうしても疎かになってしまいがちになる。
“実装が膨らみ続けて終わりが見えないpullreqレビュー” というテーマを例にしてみたが、この例に限らず、スクラムで細かくスプリントを切ってゴール設定しているようなプロジェクトならば、スプリント毎に各メンバーが何らかのゴールテープを切れるような配慮を意識した方が良い。スプリントレビューの度に「開発が遅れています」という報告をメンバーにさせ続けてしまうような運営は疲弊とモチベーション低下を加速させてしまうし、疲弊感が漂うレビューの場に於いては知識の共有やコードのセキュリティ向上といったpullreqに期待される効果を削がれてしまう。
もしゴールテープの場所を後ろにずらさざるを得ないような話が湧いてきたら、ずらすのではなく「増やす」手立てを考えてみると良さそう。
自戒を込めて
