スクラムを導入したのに、なぜ組織は変わらないのか
デイリースタンドアップ、スプリントプランニング、レトロスペクティブ。スクラムのフレームワークは完全に導入した。チームは毎日15分のスタンドアップをしているし、2週間ごとにふりかえりとカイゼンアイテムの特定をしている。でも、何かが違う。現場は相変わらず「忙しい」と言い続け、部門間の壁は高いままで、意思決定のスピードは上がらない。
アジャイルやスクラムを始めたばかりのチームや組織において、このような状況に心当たりがあるのではないでしょうか。問題は、フレームワークそのものではありません。
ここで私たちが直面しているのは、技術的課題と適応課題を取り違えているという、より根本的な問題です。
技術的課題と適応課題
この概念は、ハーバード大学のロナルド・ハイフェッツ氏が提唱したリーダーシップ理論に基づいています。
技術的課題
- 問題が明確で、解決策がすでに存在する
- 専門家が答えを持っている
- 既存の知識やスキルで対処できる
- 実装すれば解決する
例えば、サーバーがダウンした場合は再起動すればいい。コードにバグがあれば修正すればいい。こういった課題は技術的課題です。
適応課題
- 問題が複雑で、既存の解決策では対処できない
- 答えは誰も持っていない
- 人々の価値観、信念、行動様式の変化が必要
- 実装だけでは解決しない
例えば、部門間の対立、意思決定の遅さ、心理的安全性の欠如。こういった課題は適応課題です。
決定的な違いは何か
技術的課題は「やり方」の問題です。一方、適応課題は「あり方」の問題なのです。
ケーススタディ:バックログが「作業の羅列」から抜け出せない
たとえば、次のようなプロダクトバックログを見かけることがあります。
□ ログイン機能の設計書作成
□ ログイン機能の実装
□ ログイン機能のテスト
□ 変更承認会議の資料作成
□ 変更承認取得
□ リリース作業
見た目としては、優先順位順に並んでいたり、一つのスプリントに収まるように仕事が細分化されていたりするかもしれません。スクラムで定義されたバックログとしては正しいと言えるでしょう。
でもこれは、本来の「ユーザー価値を届けるための単位」ではなくウォーターフォールのWBSをスプリントに押し込んだだけの構造ともいえるでしょう。
この状態のままのバックログを扱うと、いくつかの問題が想像されます。例えば、作業の引継ぎが多く発生したり、最後のバックログを完了できないとスプリントでユーザー価値を届けるインクリメントを出せなかったりするでしょう。スプリントゴールに集中できていれば良いですが、このような状況では難しいかもしれません。
技術的課題として扱うと...
アジャイルの書籍などをあたると、ユーザーストーリー形式で書くと良い、といったことが書いてあります。
そこで、まずは以下のような対応をすることになるでしょう。
- 「ユーザーストーリーの書き方」の研修を実施する
- 「[ユーザー]として、[機能]したい。[価値]だからだ。」のテンプレートを配布する
- バックログリファインメントの時間を増やす
- 良いユーザーストーリーの例を見せる
こういったアプローチは正しい時もあるでしょう。しかし、ただ書き方を教えるだけでは、バックログは変わらないのです。
場合によっては、こんなバックログになるかもしれません。
□ 開発者として、ログイン機能の基本設計書が欲しい。なぜなら、その後の開発実装に進むことができるからだ。
□ テスターとして、ログイン機能をテストしたい。なぜなら、仕様通りに動作することを確認して品質を担保するためだ。
□ 担当者として、変更承認会議のための資料を用意したい。なぜなら、関係者が承認可否を判断できる情報を提示するためだ。
......
なぜでしょうか。
なぜ変わらないのか
チームに尋ねてみます。「なぜ設計書作成が必要なのですか」
すると、こんな答えが返ってきます。
「品質を担保するためです。設計書がなければ、誰が何を作っているのか分からなくなります。テストも網羅的にできません。変更承認がなければ、本番環境が不安定になります。アジャイルだからといって品質を落とすわけにはいかないんです」
この言葉に嘘はなく、誠実な品質への真摯な想いがあります。
しかし、ここに大きな前提が隠れています。
「品質 = プロセス」という等式
- 品質を保つには、詳細な設計書が必要だ
- 品質を保つには、独立したテストフェーズが必要だ
- 品質を保つには、承認プロセスが必要だ
- 品質を保つには、フェーズゲートが必要だ
そして、この等式の裏には、もう一つの信念があります。
「アジャイル = 品質を犠牲にした速さ」という誤解
スクラムのプラクティスを導入しても、「品質のために必要なプロセス」は変えられない。バックログはユーザーストーリーの"形"にはなっても、その中身は「設計→実装→テスト→承認」という作業のシーケンスのままなのです。
なぜこれが適応課題なのか
技術的課題と適応課題を見分けるポイントがあります。
技術的課題 | 適応課題 |
---|---|
専門家が答えを持っている | 誰も答えを持っていない |
やり方を変えれば解決する | あり方を変える必要がある |
抵抗は少ない | 強い抵抗がある |
バックログが作業の羅列になる問題は、明らかに適応課題です。
- ユーザーストーリーの書き方は教えられる(技術的)
- しかし「品質とは何か」「品質をどう作るのか」という信念は変えられない(適応的)
より深刻なのは、この信念が組織全体に根を張っていることです。
- QA部門のアイデンティティは「独立したテストフェーズ」に依存している
- 管理職の役割は「承認」によって定義されている
- プロジェクト管理の仕組みは「フェーズゲート」を前提に設計されている
つまり、バックログを変えることは、組織の構造、役割、アイデンティティを変えることなのです。
だから、「ユーザーストーリーの書き方研修」では何も変わりません。これは技術的課題ではなく、適応課題だからです。
適応課題へのアプローチ
適応課題に正しい唯一の解決策やベストプラクティスはありません。なぜなら、答えは現場にいる人々の中からしか生まれないからです。適応課題を解き組織を変化に導くためには、人々が自ら答えを見つけるプロセスを支援することが必要です。
1. 前提を問い直す対話
まず、「品質 = このプロセス」という等式を揺さぶります。ただし、正面から否定してしまうと逆効果になることもあるので注意が必要です。
効果的な問いかけの例:
- 「設計書があれば、品質は保証されていますか」
- 「これまで本番障害が起きたとき、設計書があったのに起きたのはなぜでしょう」
- 「変更承認を通過したリリースで、問題が起きたことはありませんか」
- 「テストフェーズで見つかる不具合と、本番で見つかる不具合、どちらが多いですか」
ここで大切なのは、プロセスを攻撃するのではなく、現実を直視することです。
多くの場合、こんな気づきが生まれます。
- 「設計書があっても、実装とズレていることがある」
- 「承認プロセスは通っても、実は誰もちゃんと読んでいない」
- 「テストフェーズで品質が作られたのではなく、前フェーズの欠陥を発見しているだけだった」
2. 小さな実験を設計する
対話だけでは不十分です。新しいやり方を体験する必要があります。
たとえば、こんな実験を提案します。
「次のスプリントで、1つだけユーザー価値で書かれたバックログアイテムを試してみませんか」
重要なのは:
- 小さく始める:全部を変えようとしない
- 安全に失敗できる:実験であることを明確にする
- 比較可能にする:従来のやり方と何が違うか観察する
そして、実験の中で新しい問いを投げかけます。
「設計書がなくても、どうやって品質を作れるでしょうか」
ぜひ、チームに考えてもらいましょう。
- ペアプログラミングで設計をリアルタイムで共有できないか
- 自動テストでドキュメントの役割を果たせないか
- レビューをもっと早いタイミングでできないか
もちろん、こういったプラクティスには事前の知識も重要です。
そのためには一緒に手を動かしたり、背中を押してあげたりすることも必要になるでしょう。
3. 学習のサイクルを回す
実験をしたら、ふりかえります。検査と適応です。
- 「設計書なしでやってみて、どうでしたか」
- 「品質は落ちましたか。それとも変わりませんでしたか」
- 「何が不安でしたか。その不安は現実になりましたか」
この問いかけを通じて、チームは自分たちの経験から学びます。そして、新しい「品質の作り方」を発見していくのです。
まとめ
スクラムなどのフレームワークは強力なツールです。しかし、研修の提供やなぞるだけの機械的な導入といった技術的な「やり方」のアプローチだけでは、組織変革という「あり方」にアプローチする適応課題を解くことはできません。
組織の深いところに根付く
- 「品質とは何か」という定義
- 「仕事とはこういうものだ」という信念
- 「私たちの役割はこうあるべきだ」というアイデンティティ
こういった組織のあり方は、プラクティスの導入では変わりません。
人々が自ら問い直し、実験し、学び、新しいあり方を見つけていく、こういった適応課題へのアプローチが組織を変えるのです。
参考文献・リンク
- スクラムガイド2020:https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
- Adaptive Leadership: Making Progress on Intractable Challenges:https://learn.hms.harvard.edu/insights/all-insights/adaptive-leadership-making-progress-intractable-challenges

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。