シリーズについて：「職場の暗号辞典」は、エンジニアが職場で使う言葉の「本当の意味」を翻訳するシリーズです。
- Vol.1：設計レビュー編
- Vol.2：コードレビュー編
- Vol.3：障害対応・振り返り編
- Vol.4：スプリント・スクラムイベント編（本記事）
- Vol.5：1on1編
- Vol.6：採用面接編
- Vol.7：見積もり編
- Vol.8：技術選定編
はじめに
スクラムは、チームが効率よく動くための「フレームワーク」のはずです。
しかし現実には、スプリントプランニングで「入れられそうです」と言ったタスクがスプリント末に「持ち越し」になり、レトロスペクティブで「改善します」と言ったことが次のレトロスペクティブでも同じように挙がる——そういうループを経験したことがある人は少なくないはずです。
スクラムの場でも、やはり独自の言語体系があります。「スプリントに入れられそう」「ベロシティが低い」「技術的負債の解消」——これらの言葉の本当の意味を翻訳していきます。
翻訳辞典：スプリント・スクラムイベント編
「スプリントに入れられそうです」
翻訳： 自信はないが、Noとは言いにくい雰囲気です
スプリントプランニングの場で最も危険な言葉です。「入れられそう」というのは「入れられる」でも「難しい」でもない、意図的に曖昧に残された返答です。
このフレーズが出やすい状況は2つあります。1つは本当に見積もりが難しいケース。もう1つは「Noと言いにくい場の圧力」があるケース。プロダクトオーナーや上司が「これ今スプリントに入れたい」と言っているとき、「入れられそうです」は「断れないけど自信はない」の表現です。
スプリントが終わる頃、「入れられそう」と言ったタスクの半分くらいが「持ち越し」になっているとしたら、このパターンが起きています。
対処法： 「入れられそう」が出たら「ポイントはいくつで、今スプリントの残キャパはどのくらいですか？」と数字で確認する。感覚ではなく計算で「入る・入らない」を判断する文化にする。
「ポイントの見積もりが難しい」
翻訳： やったことがないので怖い、または要件がまだ決まっていない
ストーリーポイントの見積もりが難しいケースには、主に2つのパターンがあります。
1つは技術的な不確実性が高いケース。「〇〇のAPIを使ったことがない」「DBのスキーマがどうなるかまだわからない」など、調べてみないとわからないことが多いとき。この場合は「スパイク（調査タスク）」として先にポイントを積み、調査後に改めて見積もるのが正しい対処です。
もう1つは要件が曖昧なケース。「なんとなくこんな機能が欲しい」という状態では、どんな実装が必要かわからないので当然ポイントが出ません。この場合、見積もりを無理に出しても精度が低いまま進みます。
対処法： 「見積もりが難しい」と感じたら「スパイクにしますか？それとも要件を詰めてから次のスプリントに入れますか？」と判断を促す。無理に見積もらないことも選択肢です。
「ベロシティが低い」
翻訳： ① 見積もりが甘かった、または ② 想定外の割り込みがあった、または ③ 両方
「ベロシティが低い」という言葉は、問題の結果を描写していますが、原因を語っていません。同じ「ベロシティが低い」でも、対処法は全然違います。
- 見積もりが甘かった場合： プランニングの精度を上げる（見積もりを複数人でやる、過去の類似タスクと比較するなど）
- 割り込みが多かった場合： スプリント中の割り込みをどう扱うかのルールを作る（バッファを設ける、割り込みは別トラックで管理するなど）
- タスクの依存関係で詰まった場合： 依存関係の解消を前のスプリントでやっておく
「ベロシティが低い」だけでレトロスペクティブを終えると、次のスプリントも同じことが起きます。
対処法： 「なぜベロシティが低かったか」を具体的に掘る。見積もりミス・割り込み・ブロッカーのどれかを特定し、それぞれに対策を打つ。
「技術的負債の解消」
翻訳： なんかコードが全体的につらい、でも何から手をつければいいかわからない
「技術的負債の解消」というタスクがバックログに積まれたとき、それが実際に完了することは稀です。なぜかというと、「技術的負債の解消」という粒度では大きすぎて「終わった」と言える状態が定義できないからです。
本来、技術的負債は「〇〇のモジュールの責務が分離できていないので、次の機能追加のたびに影響範囲が広がる」という具体的な問題のはずです。それが「なんかつらい」という漠然とした感覚のまま「技術的負債の解消」というタスクに変換されると、誰も触れない幽霊タスクになります。
対処法： 「技術的負債の解消」をバックログに入れるときは「〇〇ファイルの〇〇関数をリファクタする（完了条件：テストカバレッジ〇〇%以上）」のように、対象・作業・完了条件を具体的に書く。大きすぎるなら小さく分割する。
「次のスプリントに持ち越します」
翻訳： 永遠に後回しになる予感がしています
「持ち越し」は一度や二度なら正常なスクラムの調整です。しかし同じタスクが2〜3スプリントにわたって持ち越されているとしたら、それはスクラムの問題ではなく「そのタスクには構造的に手がつけられない理由がある」サインです。
よくある原因：
- 実は誰もやりたくないタスクである
- 依存する別のタスクが終わっていない
- 要件が決まっておらず、触ると泥沼になる気がする
- 優先度が高いと言われているが、いつも他のタスクに押し出される
「持ち越します」と言うたびにバックログの中で沈んでいくタスクを、たまに引き上げて「このタスク、本当にやるのか？やらないなら消そうか？」と判断することが大事です。
対処法： 3スプリント以上持ち越されているタスクは「この問題の根本は何か？今やる必要があるか？」を議論して、やる・やらない・分割するのどれかに判断を下す。バックログの棚卸しを定期的に行う。
「定義完了（DoD）を確認しましょう」
翻訳： 本当に終わっていますか？
スプリントレビューの直前に出やすい言葉です。「DoD（Definition of Done）」はチームで決めた「完了の条件」であり、これを持ち出すということは「完了と言っているが、条件を満たしていないのではないか」という疑義があるということです。
よくある「完了してない完了」の例：
- 実装はしたがテストを書いていない
- ステージングで確認したが本番デプロイはしていない
- レビューが通っていない
- ドキュメントを更新していない
DoDが形骸化しているチームでは、このフレーズが出るたびに「まあ、今回は……」という例外処理が起きます。例外が積み重なると、DoDは「参考程度の目安」になります。
対処法： DoDはスプリントの最初に全員で確認する。「今回のスプリントでDoDを緩める場合はどういうケースか」を事前に決めておくと、例外処理の基準が明確になります。
「デイリーで共有します」
翻訳： 今は詳しく話したくない（または、話す時間を確保できていない）
デイリースクラムで「それはデイリーで共有します」と言われるとき、2つのパターンがあります。
1つは本当に「デイリーで話す方が効率的」なケース。1対1で解決できない問題を全員に共有する必要があるとき。もう1つは「今この場で詳しく話すと長くなる」「まだ自分の中で整理できていない」というケースです。
デイリーが毎回15分を超えているチームは、後者のパターンが多い可能性があります。デイリーは「今日やること・昨日やったこと・ブロッカー」を共有する場であって、問題解決の場ではないはずです。
対処法： デイリーで議論が始まったら「その話は今日の午後に別でしましょう」と切り上げる役割をチームで決めておく。デイリーを15分以内に収める文化が、全員の負担を下げます。
「バックログを整理しましょう」
翻訳： バックログが増えすぎて誰も全体を把握していません
バックログリファインメントの場で出るこのフレーズは、「今のバックログは機能していない」という宣言です。
健全なバックログは「優先度がついていて、上位のものは詳細が書かれていて、すぐにスプリントに入れられる状態」です。しかし放置されたバックログは「1年前のアイデアと今週の緊急タスクが混在し、誰が書いたかもわからないチケットが100件以上ある」状態になります。
バックログリファインメントを定期的にやらないチームは、スプリントプランニングのたびに「このチケット、まだやるんでしたっけ？」という確認に時間を取られます。
対処法： 2週間スプリントなら、週1回30分程度のバックログリファインメントをカレンダーに固定する。古いチケット（3ヶ月以上動きがないもの）は積極的にクローズかアーカイブする。バックログは「やりたいことリスト」ではなく「やると決めたことリスト」として管理する。
なぜスクラムの言葉は暗号になるのか
スクラムは「透明性・検査・適応」を原則とするフレームワークです。言葉を曖昧にすることは、この透明性の原則と矛盾します。
それでも暗号が生まれるのは、スクラムが見通せない未来に対してコミットメントを求める場だからです。「このスプリントで何を完了させるか」を宣言することは、プレッシャーを伴います。そのプレッシャーを和らげるために「入れられそう」という言葉が生まれ、「難しい」を直接言えない文化の中で「見積もりが難しい」という表現が生まれます。
スクラムがうまく機能しているチームは、「Noと言える」「わからないと言える」「失敗を次に活かせる」文化がある。これはフレームワークではなく、文化の問題です。
スクラムの暗号を減らすために
スプリントプランニングで：
- 「入れられそう」を「数字で確認する」文化にする（キャパシティとポイントを比較する）
- Noと言えるチームを作る（「今スプリントには入れられません、理由は〇〇です」が普通に言える状態）
- 見積もりが難しいものはスパイクに変換する判断をすぐに下せるようにする
レトロスペクティブで：
- 「改善します」は「誰が・いつまでに・何を」まで決めてから終わる
- 「ベロシティが低い」の原因を毎回掘り下げて、パターンを見つける
- 同じ課題が繰り返し出るときは、実行されていない理由を議論する
おわりに
スクラムの言葉を翻訳すると、多くが「不確実性への対処」と「コミットメントへのプレッシャー」から来ていることがわかります。
スクラムはそれ自体が目的ではなく、チームがうまく動くための手段です。フレームワークを守ることより、フレームワークが本来解決しようとしている問題——コミュニケーションの透明性と、チームの持続的な改善——に目を向けることの方が大切かもしれません。
シリーズ「職場の暗号辞典」はVol.4で一旦完結です。
Vol.1〜4で翻訳してきた言葉に共通していたのは、「直接言えない状況」と「それでも前に進もうとする意志」のせめぎ合いでした。暗号が生まれるのは、多くの場合、誰かの悪意ではなく、人間関係と不確実性への誠実な対処の結果です。
翻訳できるようになることと、翻訳が必要ない職場を作ることの、両方を目指していきたいものです。
シリーズ一覧：職場の暗号辞典
- Vol.1：設計レビュー編
- Vol.2：コードレビュー編
- Vol.3：障害対応・振り返り編
- Vol.4：スプリント・スクラムイベント編（本記事）
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。