スクラムマスターの重要な仕事。ブロック、引き算とアンラーン

この記事はスクラムマスター Advent Calendar 2025の2日目です。

昨日はEmiさんのスクラムマスターにとっての「回復の場」としてのコミュニティです
明日はこいずみさんです。

スクラムマスターとしてスクラムチームを見ていく上で「それをやったらスクラムじゃなくなる！」という "改善提案" をされる方とよく出会います。
本人は善意の上で言っているのかもしれません。
しかしそれをやったらもうスクラムの根本がひっくり返されてしまいます。

そういうときは勇気を持って断らねばなりません。
特にチームに根付いているスクラムプラクティスをひっくり返そうとされた時は尚更です。

今回の記事において問題としているのはスクラムマスターがいるスクラムチームの話です。
ゆるっとしたアジャイルならアジャイル宣誓の定義やチームのお約束ごとに反しない限りはスクラムでなくなる改善提案でもなんでも容れればいいと思います。
でもスクラムマスターはチームのスクラムに責任を持つ立場の役割です。
スクラムマスターを置いているチームであれば、スクラムでなくなる提案を受け入れてはいけません。
経営陣が一度スクラムで行くと決めてスクラムマスターを任命しているのですから、腰を据えて組織改革に取り組む必要があります。

例：チーム内からの"改善提案"

開発メンバーの方がこうおっしゃられることがあります。

• 相対見積（ポイントによる見積）ってしっくりこないんです
  • 人日換算の方が確実にスケジュールを読めますよね？
• タスクやバックログアイテムのAssigneeのところ、誰か一人を割り当てたほうがよくないですか？
• こうした方が{リソース効率的に}効率がいいですよ
• バックログアイテムのポイントを日付換算できるようにしたら生産性を計測できますよ！

スクラムマスターとしてはそういう提案はBlockしないといけません。
特に今回の場合根付いているプラクティスをひっくり返そうとしているわけで、ポイントによる相対見積を人日換算の見積に置き換えようとする動きなどは断固としてBlockしなければいけません。

またその権限が必要である場合経営陣やCTOなどにAskしてでももらわねばなりません。

引き算

チームをスクラムから従来のシーケンシャルな開発に戻そうとする "改善提案" のブロックの話をしましたが、スクラムマスターは引き算も覚えなければいけません。
スクラムを機能させようとするとチームの外と話をする機会が増えます
（スクラムマスターのレベル1~3のように）

ギチギチに詰まった中期の開発スケジュールのガントチャートでチームの今後の予定が組まれているとスクラムなど機能すべくもありません。
また「一度開発すると決めたプロジェクトは必ずリリースされる」というような原則もスクラムが機能することを阻害します。

スクラムマスターは、スクラムを機能させることに責任を持たねばならない立場である以上そういったチーム外にあるスクラムを機能させない要素を「引き算」していかなければなりません。
もちろんそういった「スクラムを機能させない要素」は今まで果たしてきた役割や必要とされた理由があります。
引き算するからにはスクラムチームが信用を勝ち取り、代替となる要素に置き換え、経営陣やステークホルダーが同様の便益を得られるよう責任を持つ必要があります。

アンラーン

Ver.7以降のPMBOKをご覧ください。
従来型開発はWBSを根幹としています。
つまり大きなプロジェクトを詳細に分解し、明らかにして見積もることでプロジェクトをマネジメントしようとしています。

一方でスクラムは経験主義とリーン思考に基づいています。

従来型開発とスクラムはコンフリクトする考え方です。

また従来型開発しか知らない人は「今まで自分がやってきたやり方」に自信を持っていますし成功体験に裏打ちされた固執もあります。
しかしコンフリクトするしスクラムでいく以上は従来型開発の概念をアンラーンしてもらう必要があります。
締切駆動開発やガントチャート至上主義や、タスクやチケットを1人に責任を負わせようとする考え方などです。

しかし人は変化を嫌います。他人に強要される変化は特に嫌います。
なので他人にアンラーンをするよう強要してはいけません。
そう促し、納得してもらい、行動してもらうことはセオリーです。
アンラーンに応じないのなら異動という手段を選ぶ場合もあるでしょう。

スクラムマスターに求められるチェンジエージェントとは綺麗事ではありません。
スクラムマスターである以上覚悟を持つ必要があります。

スクラムによる組織の改善とは「足し算」だけではない

従来型開発をスクラムに切り替える過程で多数の新しいプラクティスが導入されます。
またふりかえりのたびに改善アクションが提案されるでしょう。

しかしこれらを際限なく取り入れることは間違っています。
また従来型開発で行われていたやり方をできるだけ現行保障の気持ちで残していくことはスクラムを機能不全に陥らせる要因です。

昭和の大政治家、田中角栄と大平正芳が囲むすき焼きの例を出しましょう。
二人は辛党と甘党なので醤油と砂糖を際限なく鍋に入れていきます。
砂糖と醤油の塩はある程度は打ち消し合うのですが、とんでもなく健康に悪い代物になりますし、なによりどれだけ高級牛肉を入れようと味が台無しになるそうです。

つまりこれです。（漫画「角栄に花束を」より）

同じようにスクラムと相反する従来型開発の要素を常に足し算して混ぜ混ぜしたら、お互いのメリットを打ち消し合う上に大量のデメリットが発生し、何より台無しになります。

経営陣が一度スクラムで行くと決めてスクラムマスターを任命しているのですから、腰を据えて組織改革に取り組む必要があります。
それはつまり、従来型への退行のブロック、スクラムとコンフリクトする要素の引き算、今までのやり方のアンラーンが含まれます。

最後に

中には「ぼくは新しいやり方を学びたくない、やり慣れたやり方でやりたい」という気持ちを善意の提案で包んで見せたり、適当な理屈をつけてスクラムのやり方を無効化させて締切で縛ることにより開発チームに確実に納期を約束させつつリソースを効率よく使えると考えているクレバーな方も会社にはおられます。
しかし人の心を読む術を持たない人々にとって心の底からの改善の提案、怠惰、納期駆動とリソース効率への信仰を見分ける術はありません。
ですのでスクラムマスターとしてはスクラムを無効化させようという動きに関しては抵抗せねばなりません。

アジャイルやスクラムとは碁のようなものです。
シーケンシャルなやり方で前後を囲まれるとアジャイルなやり方は機能しなくなります。
シーケンシャルなやり方を差し込んでくる動きはスクラムを機能不全に陥らせるベストプラクティスです。
だからスクラムマスターは抵抗する必要があるのです。

えてしてそれは経営陣や偉い人からの不興を買うことにもなるでしょう。
しかし昔偉い人が言いました
「いつでも首を賭ける覚悟を持つべきだ」