【アジャイルFAQ 第12回】もう割り込みに振り回されない！アジャイル現場の”計画の守り方”FAQ？

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。
 前回の持ち越しに続いて、計画を裏切るもうひとつの常連、割り込みの話です。第2回で「第12回あたりでまとめて扱う」と予告した、記録のとり方・当番制・受付の一本化を、ここで扱います。

 障害対応、他部署からの問い合わせ、上司経由の「ちょっとこれ調べて」…スプリント計画には載っていない仕事が、毎スプリント確実にやってきます。計画はいつも侵食され、スプリントゴールは絵に描いた餅に終わっています。
 割り込みを「なかったこと」にせず、スクラムの運用に組み込む方法はありますか？

 あります。まずは、この質問に付きものの三つの疑問から片づけます。

• 割り込みは毎回違う顔で来る。予測のしようがないのではないか
• 割り込みを計画に入れたら、計画分がその分減る。それは「負け」ではないか
• 断る権限はチームにない。結局、来たものは受けるしかないのではないか

 一つずつ答えます。

• 割り込みは、一件一件は予測できませんが、総量は、ある幅に収まっていることが少なくありません。記録すればパターンが見つかります。
• 割り込みの分だけ計画を減らすのは、負けではなく、実態に即した計画になっただけです。
• 断る権限がチームにない——これは、その通りです。自己組織化という言葉が白々しく聞こえるほど、現場のチームに与えられている権限は多くありません。だからこそ断る役割を仕組みに持たせます。

 要点は3つです。第一に、計測すること。第二に、実績に基づいて最初から割り込み枠を計画に組み込むこと。第三に、割り込みの受け方を設計すること。全員がいつでも受ける体制は、全員の集中を壊す最悪の設計です。

 研修で、「スプリントの計画は守るもの」「スプリント中の変更はスプリントゴールを危うくする」と教わった方（あるいは、「そのように理解した」方）は多いと思います。そのとき、こんな疑問を持ちませんでしたか？

• 本番障害が起きても「スプリント中なので来週」と言えというのか
• 割り込みを全部バックログに積んで次スプリントに回したら、依頼元が納得しない
• 教科書の言う「守れるスプリント」は、割り込みのない現場の話ではないのか

 この三つは、私が支援先で最もよく聞く反論でもあります。答えから言うと、**守るべきなのは「計画」ではなく「計画の立て方」**です。障害は受ける、ただし枠の中で。全部を次スプリントに回すのではなく、緊急度で仕分ける。そして教科書のスプリントは割り込みがない前提ではなく、割り込みが計画に織り込まれている前提。この答えに至る道筋を、割り込みのアンチパターンから順にたどりましょう。

 割り込みに悩むチームには、いくつかのアンチパターンがあります。一つでも当てはまれば、この記事は役に立つはずです。

その１：想定外型——最もよく見かける型です。スプリント計画のとき、割り込みがゼロである前提でキャパシティを見積もる。過去10スプリント、割り込みがゼロだったことは一度もないのに、です。今回は本番障害、前回は他部署からのデータ抽出依頼、その前は営業からの緊急調査。個別の顔に惑わされて、総量が一定の幅に収まっていることを見落とし、「毎回、想定外に苦しむ」という矛盾した状態が常態化します。

その２：直撃型——割り込みの依頼が、たまたま声をかけやすい人、たまたま前回対応した人に直接届く型です。特定の人の計画だけが繰り返し崩壊し、その人はいつまでも計画分を達成できなくなります。しかも全員が「いつ割り込まれるか分からない」状態に置かれるため、チーム全体から「集中する時間」が奪われてしまいます。

その３：全部緊急型——依頼が「今すぐ」の顔で来て、そのまま「今すぐ」として処理される型です。記録を取ると、「今すぐ」と言われた依頼のかなりの部分が、実は今スプリントでなくてよいものだと分かります。緊急度を判定する関門がないので、依頼元の声の大きさが優先順位になります。

その４：自腹型——割り込みを受けても計画分を減らさず、残業と休日で帳尻を合わせる型です。表向きの計画は守られ、ベロシティは安定して見えます。数ヶ月は持ちますが、疲弊と離脱で終わります。マネジメント層からは「割り込みがあっても回るチーム」に見えるので、対策の必要性が最も見えにくい型です。

 この四つは、一つの前提の違う表れ方です。**「割り込みは例外だ」**という前提です。例外なら計画には入れず（想定外）、来たものは受けた人がそのまま片づけ（直撃）、例外なのだから緊急として扱い（全部緊急）、対応した分は計画の外で吸収する（自腹）。どれも、この前提からは筋の通った対応として出てきます。

 ここから、三つの疑問への答えです。

 まず、本番障害が起きても来週と言えというのか。言いません。障害は受けます。ただし、受ける分をあらかじめ枠として計画に持っておく。割り込み枠はキャパシティの話であって、本番障害の対応で緊急変更の手続きが要るなら、手続きは省略せずに踏み、その対応工数をあらかじめ確保された割り込み枠から取り崩します。枠があれば、障害対応は「計画を壊す事件」ではなく「枠の中で受ける想定内の仕事」になります。

 次に、全部を次スプリントに回したら依頼元が納得しないのではないか。全部を回すのではありません。緊急度で仕分けます。本当に今すぐのものは枠で受け、そうでないものはバックログに積んで次スプリントの候補にする。この仕分けがあると、依頼元との会話は「受けるか断るか」から「いつやるか」に変わります。ほとんどの場合、納得しないのは断られたときであって、日程を示されたときではありません。

 そして、教科書のスプリントは割り込みのない現場の話ではないか。違います。教科書が言う「計画を守る」は、割り込みのない前提ではなく、割り込みを見込んだ計画を立てる前提です。守るべきなのは、計画に載せた項目の一覧ではなく、実態に基づいて計画を立てるという立て方のほうです。割り込みが実測で3割なら、その3割を最初から計画の外に見込んでおく。それが「守れる計画」です。

 なぜ「割り込みは例外だ」と扱ってしまうのか。割り込みは、一件一件を見れば毎回違う顔をしているからです。個別には突発でも、総量としてはある幅に収まる——これが割り込みの典型的な姿ですが、個別の顔が強烈なので、総量に目が行きません。
 もうひとつ、割り込みはチームの外の組織構造——サポート体制の不備、他部署との役割分担の曖昧さ、エスカレーションルートの未整備——がチームの中に流れ込んでくる現象であり、チームには「本来うちの仕事ではない」という感覚があります。その感覚が「例外」という扱いを正当化します。誰かの怠慢ではなく、構造の話です。

 対して、本来の割り込みはどう扱うものか。経験主義の手順に、そのまま乗せれば足ります。

• まず割り込みを一件ずつ記録して、総量と発生元とキャパシティに占める割合を見る（観測）。
• 次に「たまたま今回多かった」を疑い、総量が本当に一定の幅に収まっているか、発生元に偏りはないか、本当に緊急だったのは何割かを確かめる（検査）。
• そのうえで、実績の比率で計画枠を決め、受け方を設計し、発生元に応じて割り込みそのものを減らす投資を打つ（適応）。

 この順に並べると、想定外型がどこを飛ばしているかがはっきりします。観測がないので、毎回「今回は特別」で終わり、検査も適応も始まらない。「例外として都度さばく」をやめ、「定数として計画に織り込み、受け方を設計する」に切り替える。この見方の転換が、処方の効き目を決めます。

 当番制や受付経路の形は、現場ごとに違って構いません。気をつけたいのは「枠を取りました」で止まることです。それは、枠が実態と合っているかを誰も見ていない想定外型の変種です。試したあとは、計画分が守れるようになったか、割り込みの総量そのものが減り始めたかで見極めてください。

まず1〜2スプリント、記録する
 対処より先に計測です。割り込みが来たら、内容・所要時間・発生元・本当に今すぐ必要だったか、を一行記録します。ツールは何でもいい、付箋でも表計算でも構いません。2スプリント分たまれば、「うちの割り込みは平均でキャパシティの◯%」「発生元の上位は△△部と本番監視」という実像が出ます。この数字が、以降のすべての交渉と設計の土台になります。

実績比率で「割り込み枠」を確保する
 実績が30%なら、スプリントの3割は割り込みのために空けておきます。ここで一つ注意があります。ベロシティで計画しているなら、割り込みの分はすでに実績の中に入っています。第9回・第10回で見たとおり、ベロシティは会議も割り込みも含んだ観測値です。そこからさらに3割を引けば、二重に引くことになります。枠を取るとは、その見えない差し引きを、見える形にすることです。時間や人日で積む現場なら、キャパシティの7割で積む。ベロシティで積む現場なら、割り込みを計画分とは別に記録しておく。そうすれば、割り込みの比率が変わったときに、ベロシティの増減のどこまでが割り込みのせいなのかが分かります。
 割り込み枠は使い切らなければ儲けもので、前倒しで次の候補に着手すればいい。逆に枠を超えた場合は、超えた事実を記録してPOと共有し、スプリントゴールへの影響を判断してもらいます。「計画が割り込みで壊れた」から「割り込みが枠を超えたので調整した」へ。同じ出来事でも、後者はコントロールされた運用です。

当番制で被害を局所化する
 スプリントごとに割り込み対応の当番（1〜2名）を決め、依頼の一次受けをすべて当番に集約します。当番は計画作業をほぼ持たず、割り込みがない時間は小さな改善タスクや翌スプリントの準備に充てる。他のメンバーは割り込みから遮断され、集中して計画分を進める。当番はローテーションし、特定の人への集中と属人化を防ぎます。「全員が薄く邪魔される」よりも「1人が引き受けて、他は守られる」ほうが、チーム全体の完成量は増えます。

受付の門を一本化し、緊急度の判定を入れる
 依頼の受付経路を一本化し（当番宛、または専用チャンネル）、「本当に今すぐか、次スプリントのバックログでよいか」の判定を挟んでください。この判定と交渉はPOの仕事です。開発者が個別に「断る」のは負担が大きすぎます。断る役割を仕組みに持たせることが肝心です。そしてこの門は、依頼する側の協力があって初めて機能します。チームは受付を一本化して一次応答の早さを約束し、依頼側は経路を守って「いつまでに・なぜ」を一言添える。どちらか片方だけでは、門はすぐに迂回されます。

割り込みが過半を占めるなら、フレームワークを再考する
 実測の結果、割り込みが恒常的に50%を超えているなら、そのチームの主業務には「フロー型」の進め方の方が合うでしょう。第2回で述べた通り、スプリントという固定の箱にこだわらず、カンバンの併用や移行を真面目に検討してください。スクラムは手段であり、実態に合わない箱を守ること自体には何の価値もありません。

 割り込みは、チームの外の組織構造がチームの中に流れ込んでくる現象です。根本原因はチームの外にあり、チーム内の工夫だけでは完全には消えません。だからこそ、どの時代のどのチームも同じ悩みを抱えます。

 しかし、だからといって無力ではありません。計測は交渉の武器になり、枠は計画を守り、当番は集中を守ります。そして「割り込みの◯割は△△部からの定型的な問い合わせ」というデータは、FAQの整備や様々な自動化、セルフサービス化という、割り込みそのものを減らす投資の根拠になります。外から来る問題にも、内側から打てる手は思いのほか多いのです。割り込みが記録され、枠と実績が比べられ、発生元ごとの対策が議題に上がっているかどうか。この三つが揃っているかが、このチームが割り込みを定数として扱えているかの目安になります。

次回: 「POが多忙でチームに来ません」