はじめに
「スクラム」を採用している現場が増えてきました。私のところにもご相談、導入支援、研修のお声がけもコンスタントにいただけることからもその様子は伺うことができます。
しかしながら、「スクラム」の用語を利用しただけだったり、「スクラム」の一部を省略したり、はたまた「スクラム」の一部だけを利用したりしているケースも多数あると感じています。それこそ、ほとんどがこれらなのではないかという錯覚すらします。
スクラムはフレームワーク
さて、スクラムについては、スクラムガイドでも以下のように言及されています。
スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の⽬的
スクラムガイド 2020年11月版
があり、スクラムで実現される全体的な価値や結果に⽋かせないものとなっている。スクラム
の核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わな
かったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラム
が役に⽴たなくなることさえある。
スクラムは、開発プロセスではなくフレームワークです。フレームワークとは、『星の王子さま』の著者であるアントワーヌ・ド・サン＝テグジュペリの言葉を思い浮かべます。
完璧とは、付け加えるものがなくなったときではなく、削るものがなくなったときのことである。
アントワーヌ・ド・サン＝テグジュペリ
スクラムとは、まさにこの「削るものがなくなったとき」なのです。
スクラムは、複雑な問題に取り組むフレームワークで、そのベースには、経験主義（Empiricism）という科学的な思考とアプローチがあります。これにより、「何がわからないのか、わかるまでわからない」に対応することができます。
これをスクラムのホワイトペーパーでは、以下の図で示しています。
非常に不確実で、不安定な中で、スクラムチームとして安定するものを設けて変化に適応するための優れた枠組みをスクラムは提供してくれています。
スクラムでは、提供可能なインクリメントを常に用意することで、まだ終えていない作業のリスク（未完成作業のリスク）と予測可能性の最大化を図っています。
スクラムを用いる「動機」
したがって、スクラムの一部を削ったり、一部分だけを利用したりするということは、上述したことが実現できなくなるといってもいいのです。もちろん、一部を削ったり、一部分だけを利用したりしても、一定の効果は見込まれることでしょう。しかし、そこで得た効果は最初に望んだものであったのか、今一度、立ち返ってみる必要があります。
そもそもアジャイルやスクラムに取り組むには「動機」があり、従来のアプローチ（プロセス、規約、制約、意思決定、作業の方法など）では適応できないからのはずです。そうでないならば、従来のアプローチでさっさと成功すればいいのですから。
すると、スクラムの部分利用で得られた効果が、もともとの「動機」に対して効果的であったのかは検査しなければなりません。この場合は、スクラムの部分利用からだいぶ経過してからになるため、本来の「動機」に対する検査ではなく、現状の妥協に対する検査となることが多くなります。
これはとてもとてももったいないと感じています。
ただでさえ、複雑な問題に取り組んでいるのに、余計に複雑なものをしょいこんで辛くなっているとしたらそれは…
スクラムと ScrumBut
スクラムは、世界中で広く採用され、実施されています。それだけ、成功もそして、それ以上に失敗もたくさんあり、それらがカンファレンスやブログ記事などで共有されています。未成熟な業界においてここまで情報が流通しているフレームワークはそう多くはありません。そのスクラム自体の検査（裏返すと、自分たちの従来のやり方や、従来の文化が変化に適応できるのかといった検査）をせずに、一部を削ったり、部分的に利用しては機会損失になるのではないでしょうか。
- スクラムのやり方が、従来と合わないから、スクラムの一部を利用する
- スクラムを実践できるかわからないから、従来のやり方と混ぜてリスクを回避したい
- スクラムをステークホルダーまで理解させるのは大変だから、従来のやり方との妥協点で着地したい
どれも、素直で仕方がない理由に思えますし、心情は理解できます。しかしながら、本来の目的から逸脱してしまっていることで、目的を達成できないリスクを背負い込んでいることを忘れてしまってもいいわけでないでしょう。
スクラムのもつフレームワークとしての特性を利用して、自分たちの従来のやり方、文化、目的を達成するためには従来のものに対して、何を残し、何を変えなければならないのかを検査する方が得策でないかと考えます。
スクラムを採用し、取り組もうとしている現場でよく起きることとして、以下がでてきます。
- 会議体が増えたので減らしたい（デイリースクラムを隔日にする、スプリントレビューを2回に1回にするとか…）
もともと開催していた会議にどれだけ意義があったのかから検査しましょう。会議体が増えたではなく、不要な会議を減らす機会と捉えましょう。 - プロダクトオーナーが忙しいから、代理プロダクトオーナーを置こう（POが発注者側にいないといけないと決めつけている、POが忙しいから機能しないのは仕方がないと諦めている…）
POは開発者が生み出す価値を最大化する人です。そこに集中できない忙しさは何かを検査すべきです。POの仕事を代理する前に、POではなくてもできる仕事を他者に任せPOに集中できるようにした方がよいのではないでしょうか。また、POは自分の仕事を他者に委ねることもできます（丸投げじゃなく）。 - 開発する能力が足りてないからミニウォーターフォールでスタートしたい
開発する能力が足りていないと最初からわかっていることは素晴らしいことなので（本当に足りてないのでしょうかね？）その問題を解決するための能力をまずは借りてきてもいいでしょう。そしてスクラムチームで実践できるようになっていけばいいだけです。事実がわかれば、何をすべきかはわかってきます。少なくとも実験はできるので検査はできるようになります。
スクラムチームの効果性について、関連事項は、研究レポートとしてまとめられています。このことからも、変化に適応するには、スクラムチームが如何にスクラムを実践できるかがプロダクトやステークホルダーの成功に寄与するかは逆説的に示せていると言えるでしょう。
スクラムからはじめるわけ
従来型の引力に吸い寄せられてしまう気持ちは痛いほどわかりますが、「何をすべきか」に常に立ちかえられるようにしておきたいところです。
その際に、スクラムチームだけでは難しい側面もでてきることでしょう。そこはマネジメントの出番です。リーダーとして、マネジメントは環境を整えることができます。従来のやり方との調整やスクラムの理解の促進などをスクラムマスターとともに推進していけるのか、それとも反対勢力の代表格となるかの分かれ目となります。そのために『リーダーのための「スクラムガイド」手引き』を翻訳しました。
スクラムチームが効果的であるかを測る指針は、すでに示されています。こちらを参考にし、組織にとって何が必要か、現在はどうなのか、今後どうしていくべきかを検討することができます。
最後に、それでも「スクラムが合わない」と検査できたならば、他の方法を使えばいいだけです。ひょっとしたら、「従来のアプローチが一番よかった！」と再認識できるかもしれません。
ゾンビスクラムやメカニカルスクラムでは意味がない
では、スクラムのフレームワークにしたがっていればいいのかというとそうではありません。よくあるゾンビ化、メカニカル化には以下があります：
- プロダクトオーナーとスクラムマスターと開発者を「役割」として割り当てようぜ
これらは「役割」ではなく、「責任（責務）」です。役割として《分断》しないでください。スクラムチームは、同じ目的に向かっていく『チーム』です。 - プロダクトオーナーは、ユーザー側からだそうぜ
ユーザー側でもいいですが、スクラムチームの一員として同じ目的に向かっていけますか？目的が異なっていたり、たまにやってくる人だったら、それは「ステークホルダー」としてみるほうがよくないですか？ - きちんと毎日デイリースクラムやっていますよ
なんのためにデイリースクラムをやっていますか？集まればいいですか？ひょっとしたら計画の進捗を確認していたりしませんか？デイリースクラムはスプリントゴールに向かって検査し、適応させる機会です。 - 障害物は、スプリントレトロスペクティブで話し合えばいいよね
目の前に問題があり、今対処すべきことをスプリントレトロスペクティブまで棚上げしていませんか？今やった方がいいなら、検査し適応すればいいだけです。スクラムのイベントは「最低限の検査と適応の機会」です。意味もなく待つ必要はありません。 - あらかじめ決まったスケジュールと機能は決まっているさて、どうしよう
無理なものは無理と理由を含めて示しましょう（透明性）。または、そのスケジュールと機能の意図を確認しましょう。無理は斑になり、無駄を生み出します。無理してゴミを量産することは誰も望んでいないはずです。きちんと伝えて、良い方向に変化する機会を逃さないでください。
「なんでスクラムなんだろう？」「あれ？ちょっとわからない」といった機会を見逃さないでください。スクラム自体もですし、プロダクト、チーム、組織のこれらを炙り出し、共有し、議論し、検査と適応することを忘れないでください。決してこれらを「大人なんだから」、「多分自分だけ」と飲み込まないでください。飲み込んだら、それが地獄の始まりになるかもしれません。
