「スクラムを導入して半年が経った。定例イベントは実施しているし、現場も以前より頻繁に話し合っている。それでも、開発のスピードも顧客への提供価値も、期待したほど変わっていない」

アジャイル導入後、このような停滞を感じる管理職は少なくありません。そのとき、現場の理解不足や実践不足を疑い、研修の追加やスクラムイベントの徹底を求めたくなるかもしれません。

しかし、チームがどれほど努力しても、チームの権限では取り除けない障害があります。現場だけにアジャイルを任せることは、変える力を渡さないまま、成果だけを求めることになりかねません。

スクラムを導入しても成果につながらない

スクラムには、短い期間で計画し、実行し、成果を確認し、改善するための仕組みがあります。正しく活用すれば、変化へ柔軟に対応しながら、顧客に価値を届けやすくなります。

一方で、デイリースクラムやスプリントレビューを実施するだけで、組織全体の仕事の進め方まで自動的に変わるわけではありません。

例えば、チームが二週間で新機能を完成させても、リリース承認に一か月かかれば、顧客へ価値を届けるスピードは上がりません。レビューで顧客の反応を得ても、年度初めに決めた計画の変更が認められなければ、学びを次の行動に生かせません。

この状態でチームのベロシティだけを測り、「もっと速く開発してほしい」と求めても、成果にはつながらないでしょう。部分的な仕事の速さではなく、アイデアが顧客価値になるまでの流れ全体を見る必要があります。

チームの外にある三つの障害

アジャイルチームを停滞させる代表的な障害が、承認の遅さ、部門間の分断、そして兼務です。

第一に、承認の遅さです。チームが自律的に判断できる範囲が狭く、細かな変更にも複数階層の承認が必要なら、短いサイクルで学習する利点は失われます。承認待ちの間、仕事は進まず、顧客から得た新鮮な情報も古くなっていきます。

第二に、部門間の分断です。企画、開発、品質保証、運用などが別々の目標で評価され、仕事を順番に受け渡していると、問題が起きた際に協力するより責任範囲を守る行動が優先されます。顧客への価値提供という共通の目的より、各部門の都合が強くなるためです。

さらに深刻なのが、「引き渡しの無駄」です。部門が分かれていると、仕事の背景や顧客の意図について一緒に考える機会が少なく、以前のコラムで触れたチームの「共通理解」が育ちません。そのため、引き渡すたびに説明や確認が必要になり、認識のずれによる手戻りも起こりやすくなります。

引き渡した仕事が、すぐに次の工程で始まるとも限りません。兼務によって一人ひとりの稼働率を高めると、引き渡し先の担当者も別の仕事で手いっぱいになります。受け渡された仕事は相手の手が空くまでキューに入り、作業される時間よりも待っている時間のほうが長くなります。

各部門や個人が忙しく働いているにもかかわらず、顧客へ価値が届くまでの時間は長くなる。これは、部分ごとの稼働率を優先した結果、仕事全体の流れが悪くなっている状態です。

第三に、兼務です。メンバーが複数のプロジェクトを行き来すれば、優先順位の衝突や作業切り替えが増えます。チームが困っているときに助け合い、改善に取り組む時間も失われます。個人の稼働率は高く見えても、チームとして仕事を完了させる力は下がってしまいます。

これらはいずれも、現場のスクラムマスターやメンバーだけでは解決しにくい問題です。

チームの問題に見えて、実は組織の問題

成果が出ないとき、その原因は目につきやすい現場へ向けられがちです。「計画の精度が低い」「主体性が足りない」「他部門との調整が弱い」といった指摘です。

しかし、計画を何度立て直しても急な割り込みが上層部から入るなら、問題は計画能力ではありません。チームに主体性を求めながら重要な判断権を与えていないなら、問題はメンバーの姿勢ではありません。他部門との協力が進まない背景に、部門ごとに競合する目標や評価制度があるなら、調整力だけでの解決には限界があります。

チームの行動は、組織の構造や制度から強い影響を受けます。現場で繰り返し発生する問題は、個人の能力ではなく、その行動を生み出す仕組みに目を向ける合図です。

管理職には、チームを評価する前に「この問題を生み出している組織上の条件はないか」と問い直す姿勢が求められます。

管理職・経営層に求められる支援

アジャイルにおける管理職・経営層の役割は、現場へ手法を導入させて進捗を監視することではありません。チームが顧客価値へ集中し、学びながら判断できる環境を整えることです。

まず、チームが自分たちで決められる範囲を明確にし、不要な承認を減らします。すべてを任せるのではなく、目的、守るべき制約、期待する成果を示したうえで、実現方法の判断をチームへ委ねます。

次に、部門を越えた共通目標を設定し、必要な専門性をチームの近くに置きます。問題が起きるたびに部門間で交渉するのではなく、顧客価値を届けるために協力できる関係と仕組みをつくります。

さらに、優先順位を整理し、安定したチームが一つの目標へ集中できるようにします。新しい依頼を追加するときには、何をやめるのかも同時に決めなければなりません。

そして、現場から報告される障害を、失敗の報告ではなく改善の材料として扱います。率直に問題を話したチームが不利益を受ける環境では、本当に必要な情報は経営層まで届きません。

アジャイル導入後の停滞は、必ずしも失敗を意味しません。それまで見えにくかった組織の問題が、短いサイクルによって明らかになったとも考えられます。

現場に「もっとアジャイルに」と求める前に、組織自身が変化を妨げていないかを確かめる。チームと組織が一緒に学び、改善を続けるとき、アジャイルは初めて成果につながります。