スクラムの「うまくいかない」はなぜ？組織や関係性に隠れた課題を探る

関西のスクラム・アジャイルコミュニティを牽引してきた「スクラム道関西」。2012年の設立以来、現場のリアルな葛藤を安心して分かち合える場として、これまで170回以上の「オープン・ジャム（定期開催している参加者同士の対話イベント）」を開催してきました。

「デイリースクラムが15分で終わらない」「スクラムマスターが何もしてくれない」……。

コミュニティの中心メンバーであるAkiさん（@spring_aki）・山根英次さん（@e_yamane）・増田謙太郎さん（@scrummasudar）のもとには、現場の切実な悩みが絶えず寄せられています。

本記事では、スクラムの手順や進め方を解説するのではなく、そうした悩みの背景にある組織構造や関係性、期待値のズレに焦点を当てます。

一見すると個人のスキルや手法の問題に見える相談も、掘り下げてみると、その裏に別の背景が隠れていることが少なくありません。スクラム実践者の悩みに寄り添い続けてきた3人に、その向き合い方を伺いました。

孤軍奮闘の時代から、組織で成果を問われる時代へ
「デイリースクラムが15分で終わらない」の裏に本当の原因がある
「スクラムマスターが何もしてくれない」という誤解の本質
「ブリリアント・ジャークがいる」がレッテル貼りになっていないか
「スクラムがうまくいかない」には伸びしろがある
「許容可能な損失」を積み重ねながら、道を見つけていく
【合わせて読みたい】「うまくいかない」現場と向き合う

出演者 — 「スクラム道関西」のコアメンバーである3人。（左から）Akiさん、山根さん、増田さん

孤軍奮闘の時代から、組織で成果を問われる時代へ

── そもそも「スクラム道関西」はどのようなきっかけからスタートしたのですか。

Akiさん（以下、Aki）　複数人で立ち上げたのですが、私の動機は自分がスクラムを学びたいけれど、周囲に学ぶ場がなかったので「それなら作ればいい」というシンプルなものです。

共に立ち上げた仲間と一緒に学び、関西圏でもスクラムに取り組む人がもっと増えればいいなという気持ちからでした。

当時はまだ、首都圏に比べて関西圏でスクラムやアジャイルに取り組んでいる人はあまりおらず、だからこそ集まって話そう、という感じでした。

── その頃に比べ、アジャイルやスクラムを巡る状況は様変わりしているでしょうか。

山根英次さん（以下、山根）　アジャイルやスクラムという言葉を「知らない」という人は、だいぶ減ったんじゃないでしょうか。組織の中で「アジャイルやスクラムに取り組もう」という声が出てくるくらいには、広まってきた感覚があります。

増田謙太郎さん（以下、増田）　そうですね。最近では企業の新卒研修の一環として、「スクラムを教えてほしい」というお話を頂くこともあるほど、組織主導での推進が増えているように思います。

── そうした変化に伴って、スクラム道関西で共有される悩み事も変わってきましたか。

山根　2010年代は、手法を面白そうだと感じた個人が「どうスクラムを始めればいいのかな」と悩むケースが多かったです。

それが最近は、「組織としてスクラムをやりたいけれど、スクラムガイドを参考に進めていてもなかなかしっくりこない」といった話が増えてきました。

増田　同感です。自分は2015年から専任スクラムマスターとして活動してきましたが、当初は、自分一人、あるいは共感してくれる数人のチームが主となり、「どうすれば会社の中に導入し、定着させられるか」という議論がほとんどでした。

導入自体のハードルが下がった今では、「どうすれば組織の枠組みの中で期待される効果を出せるのか」という、より実践的なフェーズの悩みをよく聞くようになりました。

「デイリースクラムが15分で終わらない」の裏に本当の原因がある

── 最近の「オープン・ジャム」では、どのような質問が寄せられることが多いのでしょうか。

山根　初期の頃は「デイリースクラムが15分で終わりません」といった質問がありましたが、最近はむしろ、チームの内と外との関係性やインタラクション、ステークホルダーとの関わり方で悩んでいるといった話題が多いように思います。

Aki　以前に比べて、技術やチームの話にとどまらず、組織やステークホルダーマネジメントのようにより広範な話もよく聞くようになりました。一方で「上司がリファクタリングを認めてくれない」といった、以前から変わらない悩みもあります。

また、「プロダクトオーナーやスクラムマスターが機能していない」という悩みも、継続的に寄せられる印象がありますね。

山根　こうした表層的な課題を解決すること自体は、そんなに難しくないと思っています。ただ問題は解決できても、チームの状態が何も改善されていなかったり、他のところで新たな問題が次々と発生したりして、本質的な解決につながらないことがすごく多いんです。

ですから、せっかくオープン・ジャムに足を運んでいただいているので、一緒に対話をしながら「本当に困っている原因は何か」「これを解決したらどうなるのか」を深掘りするようにしています。

増田　本当にその通りですね。掘り下げていくと、実は全然違うところに根本的な課題があったというのはよくありますね。

Aki　例えば「デイリースクラムが15分で終わらない」問題に対しても、強制的に時間を切るなど、やりようはいくらでもあるかもしれません。

けれど、「そもそもなぜ15分を超えるのか」を聞いていくと、プランを立てていなかったり、「なぜこれを作るのかが分からない」といったプロダクトの目的を理解していないために、会話のたびに背景説明に時間がかかっていたり、そもそも納得感のあるプロダクトバックログアイテムになっていなかったりすることがあります。

結局、「なぜ困っているのか」「その問題が発生している根本原因はなんなのか」「その問題は本当に問題なのか」などを深掘りしていかなければ、どの部分を適切に手当すべきかが分からないと思います。

「スクラムマスターが何もしてくれない」という誤解の本質

── 他の悩みでも、そうした組織や関係性の問題が背景にあるのでしょうか。

Aki　そうですね。例えば「組織から『アジャイルを推進したい』と言われても、それが推進できる体制になっていない」とか、「『推進したい』と言っている人たちがスタートさせるだけのアジャイルの知識を持っていない」「『推進したい』と言いながらトレーニングなどに予算を割り当てず、組織としてのサポートがない」といった話を聞くこともあります。

こうしたケースで厄介なのは、周囲との関係性やビジネスプレッシャー、組織の構造が絡んでくると、「こうすればいい」という単純な答えが出しにくくなることです。

── 個別の背景や関係者との関係性があるから、一筋縄ではいかないのですね。

Aki　よく思うのは、相談に来られる方と、組織との間で、アジャイルやスクラムを推進する際の期待値に大きなギャップがあるまま進行してしまうとより状況が難しくなっていく、ということです。周囲とのミスマッチを抱えたまま進めても不幸なことが起き続けますよね。

アジャイルソフトウェア開発宣言にも、スクラムガイドにも、こうした組織や関係性の問題への答えは原則としては示されていても、個別の状況にどう当てはめるかまでは書かれていません。だからこそ、まず「この人の状況はどうなっているのか」を丁寧に聞くことから始めます。その対話の中で、複数の問題が絡んでいて、「実はこちらを先に解決した方がいい」という本質的なポイントが見えてくることが多いんです。

山根　その組織とのズレが分かりやすく出てしまうのが、「プロダクトオーナー（PO）に決定権がない」、あるいは「単に仕様をとりまとめるだけの存在になっている」という問題です。ですが、これは個人の問題ではないので、「じゃあ、POの役割を別の人に交代しよう」としたところで、根本的な解決にはなりません。

根本にあるのは、プロダクトの開発部隊とマネジメント部隊がすっぱり分かれている組織の壁です。組織を越境して何かをしようとするとパワーが必要ですし、ジョブディスクリプションを変に尊重し過ぎて、お互いの領域に立ち入るのを自重してしまう。

「考える役割」と「作る役割」が構造的に分断されていて、チーム全体でプロダクトについて考えながら作っていくような協働のスタートラインに立つのが難しい現場は多いと感じます。

増田　そうした組織の構造や評価の歪みが分かりやすく出てしまうのが、まさに「スクラムマスター（SM）の成果が見えにくい」という悩みですね。

エンジニアやプロダクトオーナーに比べて、アウトプットが分かりづらいので、上司や周囲とあらかじめ期待値をすり合わせておかないと立ち位置が崩れやすい。これもやはり、根本的には組織や文化に遡る問題だと思います。

山根　だからといって、スクラムマスターが「この作業はあなたがやってね」とあれこれ指図すると、一時的には成果を出しているように見えても、もはやスクラムマスターとしては機能していません。

「サーバント・リーダー」という言葉があるように、指示を出すのではなく、チームが自律的に動けるよう一歩引いて支援する。ただ、その姿勢が周囲から「何もしない人」に見えかねないのは悩ましいところですね。

Aki　そうですね、指示したり管理統制を効かせたりするよりも、周囲との意思疎通を促すためにあえてクリティカルな質問を投げかけたり、スクラムチームとステークホルダーとの対話を支援したりして、チームが自律的に動けるよう支えていくのが本来の仕事だと思います。

ただ、こうした働きかけは表に見える成果物として残りにくいので、続けていくと「あのスクラムマスターは何もしてくれないな」と誤解されるかもしれません。それでも、そこはレトロスペクティブ（ふりかえり）などでスクラムマスターの考えや活動を共有して目線を揃えていけばいいはずです。

「ブリリアント・ジャークがいる」がレッテル貼りになっていないか

── 最近の相談で印象に残っているテーマはありますか。

山根　実際、オープン・ジャムでは個人の振る舞いに関する相談も寄せられます。記憶に新しいところでは、「チームにブリリアント・ジャークがいて困っている」という相談がありました。

※編注：ブリリアント・ジャーク（Brilliant Jerk）とは、優秀で圧倒的な成果を出すが、協調性がなく周囲に悪影響を与える人のこと

一見すると特定の個人の問題のように見えますが、実はこれも組織の課題として向き合うべきテーマです。

増田　おそらくそうした問題が浮上するチームは、特定の人に業務が集中していたり、その人がいないと回らない状態になっていたりするケースも少なくありません。そうした意味では、組織としての脆弱性が表面化しているとも言えると思います。

Aki　チームに悪影響のあるコミュニケーションをとる人が一人いるだけで、チームの成果が著しく損なわれることが研究で示されています (Felps et al. 2006) 。この研究者が後に語ったエピソードでは、一つのグループだけ例外的に成果が落ちず、そのグループには質問を投げかけ、全員を巻き込み、対立を和らげる優れたリーダー役のメンバーがいたという話がありました。つまり、問題は「その人がいるかどうか」だけでなく、周囲の関わり方によっても変わりうるわけです。

私は「ブリリアント・ジャーク」のようなラベルを安易に使うことには慎重でいたいと思っています。

── それはどういうことでしょうか。

Aki　そうした相談を受けたとき、まず「どのような文脈でその人を見ているのか」を聞くようにしています。その対話の中で、一つの出来事だけで見方が固定されていたことに気付くきっかけになることもあります。

違う例ですが、周りが活発なコミュニケーションを好む中で、その人はただ「静かに仕事をしたい」だけかもしれない。それを「空気が読めない」と見ていた、ということもあるわけです。問題に名前をつけると分かった気になれますが、その言葉の裏には関係性のズレ、期待値の違い、組織の構造といった別の要因が隠れていることが少なくありません。

だからこそ、ラベルで片付けるのではなく、その見方そのものを問い直すこと。そして、それぞれの特性を踏まえた上で、チームとしてどう機能していくかを互いに考えていくこと。この2つが問われているのだと思っています。

「スクラムがうまくいかない」には伸びしろがある

── スクラムに関する悩み事というのは、すっきり解決しないものなのですね。

増田　プロジェクトやプロダクト開発にスクラムを適用すれば、それだけでうまくいくというわけではありません。

私がスクラムマスター研修を受けたときに、ある講師の方が言っていた「スクラムとは問題を発見するフレームワークであり、その問題を解決するのは人だ」という言葉が、印象に残っていて、大切にしています。

スクラムを取り入れたら、隠れていた問題がたくさん出てくるんですよ。その気づき自体が財産であり、改善していく活動そのものがスクラムだと思います。

「問題が次々と出てきて、うまくいかない」という現場ほど、実はスクラムが効果的に機能しているんだ、とよくお伝えしています。

山根　実は、「早い段階で問題が分かる」ということ自体がチームにとって大きなメリットなんです。最初に問題が分かっていれば、後になって問題が噴出するのとは異なり、手の打ちようがあります。

逆に、毎回全てがうまくいっているチームの方が不自然かもしれません。それは、スクラムガイドにある「複雑な問題」ではなく、比較的解決しやすい問題に取り組んでいる可能性もあります。ですから、うまくいっていないことを恥じる必要はなくて、むしろ「伸びしろがいっぱいある」と伝えたいですね。

── とはいえ、現場で「うまくいっていない」と認めるのは、なかなか勇気が必要ですよね。

山根　はい。ですので、スクラムチームを支援するときには、スクラムチームから「疲れた」とか「しんどい」と言ったネガティブな発言をしてもいい場になるように心がけています。

こうしたネガティブな言葉が出てこないと、かえって負の重力がかかって、本当に苦しくなってしまいます。

変に動きが取れなくなるぐらいだったら、「うまくいっていない」「失敗してしまった」と言い合える状況をつくり、そこから「みんなで話し合おう」「何が起きたか分析して、学ぼう」と話せるようになることが大切だと思います。

Aki　スクラムは、チームが検査と適応を繰り返しながら、プロセスの問題を浮かび上がらせていくフレームワークであり、チームがどれだけ学びを蓄えられたかが大事なんですよね。ですから、失敗したとか、関係性がうまくいっていないと分かるのも一つの重要な情報です。ちゃんとやっているからこそ問題が見えてきて、しんどいわけですよね。

そこから「どう工夫すれば疲弊せず、継続的に安定して価値の高いものを出しやすくなるのか」を学んでいくためのフレームワークとして認知し、使っていけばいいと思います。ただ、これは決して「みんなで楽しく、衝突なく、馴れ合いに流されていく」という単に衝突を避けることだけを目的とした状態とは違います。

「許容可能な損失」を積み重ねながら、道を見つけていく

── 最後に、スクラムに取り組もうと考えている方々へのメッセージをお願いします。

山根　以前に比べると、困ったときや悩んだときに相談できる場は増えています。ですから、まずは失敗してもいいから新しいことに取り組み、かつ一人で悩まず、その結果をいろいろなコミュニティに持ち寄ることで知見が得られると思います。

まずは外部の人よりも、さまざまなコンテキストを理解できる社内の人たちとスクラムガイドを読みながら、一緒に戦ってくれる仲間を作っていければいいと思います。

増田　中の人と一緒にできるのは理想的ですが、社内にたくさんスクラムマスターがいる会社はまだまだ少ないです。他の会社で同じような職務やロールで働いている人たちとコミュニケーションを取ることも非常に大事だと思います。

本やWebメディアから学べることも多々ありますが、「どれがいいんだろう」と迷ったときに、一緒に考えてくれるような文化が「スクラム道関西」のようなコミュニティにはあり、それこそが価値だと思います。

Aki　自分が言いたいのは、「何のためにやろうとしているのか」を常に問い続けてほしいということです。スクラムやアジャイルをやること自体が目的ではなく、その先に「不安なく最良のパフォーマンスで良いものを楽しく作りたい」「誰かの役に立つモノを作りたい」といった実現したいことがあるはずです。すぐに分かることでもないので、やりながら、そのことを考え続けてほしいなと思っています。

それから、人間は誰しも失敗を避けたがるし、特に、大きな損失は避けたがると思います。アジャイルやスクラムのいいところは、「これくらいだったら失敗しても痛手ではない」という許容可能な損失を積み重ねていけることです。

ちょっとチャレンジしてみて、うまくいけばもっと進めればいいし、ダメだったらちょっと引いてみる。そのくらいの小さな検査と適応をたくさん繰り返すことで、たくさんの道が見えてきます。

プロダクト開発に限らず、人生においても、程よいチャレンジを意図的に重ねていってほしいなと思います。