スクラムでぶち当たる壁
これは自分の経験から生じた話
ここに書くことは自分の経験から生まれたもので、あまり一般論ではところがあるかもしれない。
参考になる部分もあるかもしれないが、多くの場合そっくりそのままはまることはないと思うので、その点ご注意。
銀の弾丸など無い
アジャイル界隈ではよく言われている話だ。
アジャイルやスクラムは銀の弾丸ではない。
こういうとき、そもそもそれは何なのか？ きちんと理解した方がその後の誤解を生じさせづらくなるので、ちょっと書いておこう。
概ね間違っていることは書いていないはずなのでWikipediaを参照する。
転じて、通常の手段では対処が厄介な対象を、たった一撃で葬るもの、という比喩表現として用いられる場合が多い。例えば、ある事象に対する対処の決め手や特効薬、あるいはスポーツで相手チームのエース選手を封じ込める選手などを表現する場合に用いられる。また、ソフトウェア工学では、OS/360の開発で苦闘したフレデリック・ブルックスが、『人月の神話』（原書:1975年）において「『どんな場合であれ通用する』ような、『万能な解決策』は存在しない」というたとえとして「銀の弾などない」と述べた例がよく引き合いに出され、しばしばある種の企業の広告などに見られるそのような主張に対して言われる言葉になっている。
おおそうなのか、人月の神話で書かれてたのか、知らんかった（笑）
人月の神話もとても大事なことが書かれていてもはや古典クラスの本だが今でも通用する話は多いので読んで損はないと思う。
閑話休題。
さて、アジャイルやスクラムが銀の弾丸ではないとはどういうことかというと、
それを導入しさえすれば万事可決、とはならない
ということだ。
スクラムはそれが強く示されている。スクラムの定義にはこう書かれている。
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
とりあえず試してみていいよ、でも実践する人たちの集合知が大事なので、意図的に不完全な書き方になってるよ、実践者の関係性や相互作用をガイドするものだよ、色々なプロセス、技法、手法を加えたり、既存のものをなくしちゃってもいいんだよ、みたいな感じだ。
良く言えば柔軟であり、悪く言えば中途半端だ（笑）
でも中途半端といっても中身はとてつもなくシンプルで導入しやすいものになっている。ここが極めて重要だ。
PMBOK第7版なんて、6版からかなりページ数が減ったとはいえ、それでも274ページもある。対してスクラムガイドはたったの18ページだ。
とりあえず試す、でもそれは銀の弾丸ではない。
これを忘れてはいけないのだが……案外難しい。
スクラムを失敗させるアンチパターン
様々な失敗例がある。自分も経験したこともあるし、経験したことがないものもある。そういったものを全て紹介するわけにもいかないので、とりあえずはキレイにまとまっている記事を紹介させていただこう。
ryuzeeさんにはいつもお世話になっている。有用な記事をいつもありがとう。
組織の壁
アンチパターンや誤解が数多くあるが、その内のひとつとして、
アジャイルは開発現場だけのもの
という考え方があると思う。アジャイルは開発現場のものに違いないが、だけのものではない。これは組織で取り組むべきものだ。
他の会社だとこ組織も交えてアジャイルが推進されているところもあるだろう。けど多くはアジャイルと組織は分断されているところの方が大多数なのではないかと思う。
今の環境でもそういった分断を感じさせることが多い。いくつか例を挙げてみよう。
役員など上層部が自分たちはアジャイルとは関係ないと思っている
都度都度スケジュールに沿ってリリースさえできてればアジャイルでしょう？ といった浅い考え
プロダクトオーナー？ 開発現場にオーナーなんぞ任せてなるものかという、言葉のみの印象だけで否定されれる
マネージャーが全部細かいところまでチェックする。しかしマネージャーは時間がないのでまとめて見せにいったりする必要があったり、思いつきをガンガン言われるマイクロマネジメントがある
幸いにも自分の携わるチームはわりとスクラムができていると思っている。課題は山積みだがそれでもスクラムイベントの意義は果たされている。とくにふりかえりが蔑ろにされず行えていることが素晴らしい。
その反面、組織から得られる理解が極めて浅い。「自由にやっていいよ」という体のいい言葉はあれど、理解をしようとする動きはほぼ皆無と言っていい。
例えば自分は現在、プロダクトオーナーという役割を率先してこなそうとしているが、その意志はあまり尊重されておらず、責任だけがつきまとい意思決定権はほぼゼロである。
これはスクラムガイドのプロダクトオーナーにある項目からは明確に反している。とはいうものの、「だからダメだ」と決めつけられるものでもない。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。
プロダクトと組織は切っても切り離せない。プロダクトの価値を最大限高めるためにはチームの力だけではダメで、多くの関係者の協力が必要になってくる。それは組織がこなすべき領域であり、だからこそ組織としてアジャイルにどう取り組むのか考えて動かないといけないと思っている。
組織内の多くのチームから「スクラムでやりたい」「XPを取りれたい」といった話が出てくる、ということは何かしらそこに課題があるはずで、その解消のためには組織がアジャイルを理解し行動できる状況が理想だ。そのためにはマネージャーの動きが重要になってくるだろう。
とはいえ、チームは組織の考え方に寄り添う必要もまたあるわけで、極端な話、組織側が「我々はアジャイルはやりません」ともし明言すれば、それに沿わざるを得ない。それによって組織に残るか、去るかというのは当人次第だ。
それ以前に問題だと思うのは「自由にやっていい」というだけで、一緒に取り組むという姿勢や、組織側の考え方を明確に伝えないまま、雰囲気で進めている状況だ。
上の例でいえば、プロダクトオーナーの決定の重要性が理解されていない組織の中でどうやって立ち回ればいいのかを考えないといけない。スクラムガイドに書いてあるとおりにできないからダメだ、と決めつけてしまっては前へ進めない。おそらく他の手法を試そうとしても別の壁に当たって進めなくなる可能性が高い。
ここを打破するのはとてつもなく大変だ。特に組織からの理解がなかったり浅かったりするとものすごいエネルギーを必要とする。どうすればいいのかという答えは今いる自分の環境ではまだ全然見い出せていない。
でもひとつ確かなことは、ここに切り込んでいくべき役割がスクラムマスター、ということだ。
スクラムマスターについては、スクラムガイドにはこういった一文が書いてある。
スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
（中略）
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。
2020年11月の版からこのように書かれており、「誰もやりたがらんぞこれ！」って思ったものだ（笑）
組織からの理解があろうとなかろうと、スクラムマスターは多方面に活動しなければならない。理解されていなければ理解してもらえるように、理解されているのであればより良くするために。
しかも銀の弾丸は無いので、環境に合わせて柔軟に試行錯誤しながら前に進むように周囲を巻き込んでいかないといけない。
いやぁ大変だ（笑）
肝要なのはスクラムマスターの立ち回り
スクラムはシンプルなので「とりあえずやってみよう」というだけならわりと簡単だ。デイリースクラム、プランニング、レビュー、ふりかえり等々やってみようと思えば結構できる。
ただし、それを効果的効率的にやろうとすると途端に難しくなってくる。開始当初のチーム内でこのあたりの理解を得て少しずつ良くなっていけるように立ち回るだけでも大変だ。
そしてそこを乗り越えても、次は組織の壁にぶち当たる。機能の明確なリリース日を強く求められたり、人月計算でチームのボリュームが図られたり、チームではなく個々の人員を増やしたり減らしたりという調整がなされたり、ウォーターフォール的なカッチリとした計画とそれに基づく進行を求められ、にもかかわらず仕様の変更は常に発生し……等々のアジャイルの考え方からのズレを感じたり、逸脱している話がそこかしこで起こる。
スクラムにせよ他の開発手法にせよ、こういったいわゆる「常識」に対する対策を講じて立ち回らなければ、アンチパターンに陥っていき「この手法は使えない」といった意見が生じ始め失敗する。
そうならないように、あるいは部分的にそうなってしまったときの軌道修正をする人がスクラムマスターだ。スクラムマスターが取り組むべきことは極めて重要な要素になってくる。新しい考え方ややり方を行おうとしたとき、それがすんなり通ることはまずない。
スクラムを例に挙げているが、この考え方はおそらくスクラムに限らず有用だと思う。
正気を保とう
LeSSについて書かれた本「大規模スクラム Large-Scale Scrum(LeSS)」には、
スクラムマスターのサバイバルガイド
という項がある。そこに「正気を保つ」ことについての重要性とガイドが書かれている。
LeSSのスクラムマスターとして、組織を変更する必要がありますが、権限は持っていません。これは良いことです。人々は行っていることが正しいと信じているため、変化することを納得させる必要があります。しかし、組織の変化に影響を与えるのはふつうによくあることではありません。あなたがどれほど頑張っても、反対の方向に変化します。どうやって生き残ればよいのか、という疑問が湧いてきます。組織内で生き生きとした状態を保つには、次のような特性が必要です。
・忍耐と低い期待
・永続性
・勇気
・ユーモアのセンス
・寛容と謙虚
特性の各項目は、実際の本ではより詳細が書かれている。概ね「勇気を持って取り組み、永続的に、忍耐強く、変化を提案しよう、思い描いたものと異なる愚策になったら笑ってスルーしよう」みたいなことが書かれている。
LeSSではないとしても、現場で耐え忍んでいるスクラムマスターがいらっしゃればぜひ手にとってこの項だけでも読んでみるといいと思う。
一歩ずつ、少しずつ
ここ数年、アジャイルの考え方に基づきスクラムやLeSSを推進しているが、まー色々なところで思ったようにいかない。開発チームにやってもらいたいことを実現するためにはPOを説得しないといけないなんて誰も思ってなく、「いつになったら要望を叶えてくれるの？」といった催促だらけだ。
ステークホルダーは強い意思決定権とマイクロマネジメントでコントロール化に置こうとしつつ、その上でメンバからの自主的な動きを強く求めてくる。さらに重要な情報は隠されているので、ある日突然それが表面化して対策に追われ、スプリントに致命的な影響が生じる。
現場は現場で「それやる意味あります？」といった意見が平然と出たり（そういう意見が出ることそのものは悪いことではないが、前向きさが無いとツライ）、各スクラムイベントで決まった人しか話さなかったり、その割に裏で反対意見を言い合っていたり、ファシリテート役がただ書いてあることを話すだけで議論や相談に積極さがなかったり。
頭を抱えることは日常茶飯事だ。
杓子定規的にアジャイルソフトウェア開発宣言やスクラムガイドを読んでもらうだけでは全然足りない。多くの人々はその必要性を感じていないからまともに読んでくれないし、読んでくれたとしても直接的な課題解決に繋がることは少ないので「ふーん、それで？」で終わる。必要性を感じてくれている人も、案外読み込んでなかったりするから、理解が浅く「どうすればいいのか」というところまで踏み込んで考えきれないことも多い。なにせ業務で忙しい。
それでも少しずつ前に進むためにできることをコツコツやっていくしかない。
この記事が気に入ったらサポートをしてみませんか？