1. はじめに
こんにちは、エムティーアイ Advent Calendar 2024 12月16日担当の中居です。テスター、SM(スクラムマスター）をしています。
今回は、なぜスクラムが難しいのか？ についてまとめてみました。
スクラムガイド2017で「（スクラムとは）理解が容易、習得は困難」と記載されていました。
スクラムガイド2020では上記の文言は削除されましたが、SMとして「スクラムは素晴らしい」と推奨しつつ、「難しい」と頭を抱えることがあります。
ブログを書く機会をいただけたので、スクラムの「難しい」ポイントは何か？ を考えてまとめてみました。
2. そもそも難しい
抽象と具体の中間がない
アジャイルとスクラムの関係を下記の図にまとめました。
スクラムのベースにはアジャイルソフトウェア開発宣言がありますが、短く、抽象的です。
スクラムガイドはきわめてシンプルです。またあえてできるだけ指示をしていません。抽象的です。
抽象度・小や具体度・大といった抽象＝具体の中間がないため、抽象度・大の「アジャイルソフトウェア開発宣言」、抽象度・中の「スクラムガイド」を実践するとき、いきなり「プロジェクトでカスタマイズ・具体化」が必要になり、難易度が上がります。
初心者は「どこまでどれくらいどのようにカスタマイズすればいいのか？」と混乱します。ではノウハウがあればいいのか？ というと、複数の異なるプロジェクトの経験者がいるとカスタマイズや解釈について情報過多になります。
抽象を具体に落とし込むとき、どうカスタマイズするか？ というすり合わせが必要です。
スクラムができているかわからない
スクラムはさきほどの図では抽象度・中です。これとこれができていたらOKという「スクラムの完成」の具体的でわかりやすいチェックリストはありません。
「完成の定義」はスクラムでは重要ですが、スクラムそのものには「完成の定義」がないのです。
プロジェクトによって状況が違い、求められていることも違います。多様な状態に理論的かつフレキシブルに対応するため、スクラムガイドはあくまでフレームワークを示すのみです。
代償として、スクラムができているかわからず、「スクラムそのものの完成の定義もカスタマイズ？」（ベロシティを指標にする）、「スクラムガイドの記載を実施しさえすればOK？」（Do Agile）、などなど、ゾンビスクラムと呼ばれる状態になることがあります。
ではスクラムの完成はいつどうやってわかるのか？ というと、わたしの体験になってしまうのですが、違うプロジェクトにアサインされたあと、うまくいかなかったスプリントのあとで、「あのときは成功していたんだ」と比較してわかることはあります。
プロダクトゴール、スプリントゴールを達成するのは一つの目安ですが、ゴールの目標が低いとあっさり達成できてしまったり、達成後のレトロスペクティブで改善点が出てこなかったりと別の問題が出てくるのも、難しいところです。
なお、スクラムではない場合はスクラムガイドに明記されています。
3.なぜアジャイル/スクラムを薦めるか？
それでもアジャイル/スクラムを薦める理由は5つあります。
価値を届ける思想・開発プロセスとしてのアジャイル/スクラムのメリットは書籍でもネットでもたくさん情報がありますので、それ以外でアジャイル/スクラムのよいところを書いてみました。
アジャイル：（価値を届けるため）できないことはできないと認める
アジャイルでは、荒ぶる四天王（QCDS-品質、コスト、納期、スコープ）をすべて満たすことはできないと考え、これらの要素のトレードオフが必須です。 全員が「できないこと」を認め、では価値を届けるためにできることはなにか？ を考えるのは、成果に対して現実的かつ真摯な向き合い方です。
スクラム：難しいと認める
「スクラムは難しく、破壊的」 Ken Schwaber
ケン・シュエーバー自身が2006年とかなり前ですが、「難しい」と断言しています。
関連する議論はScrum.org で継続中のようです（Scrum is Hard and Disruptive #15 - Leadership is Essential）
スクラムは「難しいことをやっている」自覚は大事です。改善して学習して少しずつ軌道修正するのは、複雑な問題に適応して解決するためです。
進まない、蛇行する、ゴールへのスピードが一定にならない、それは難しいことをやっているからです。誰かが一気に解決できるものではなく、誰かが全部悪いわけでもありません。そもそも難しいんです。
難しいからうまくいかないことを認め、ではできることはなにか？ を考えるのがスクラムです。
開発実務者が考えている
アジャイルソフトウェア開発宣言の宣言者、スクラムガイドの著者はプロジェクト経験のある実務者です。
権威ある偉い誰かが「考えろ」「改善しろ」と命じたのではなく、実務者が「何のために開発するのか？」「価値とは何か？」「どうしたら価値を素早く届けられるか？」を考えて自発的に宣言とガイドを出しました。
仕事の意味を考え、問題提起し、問題解決のためになんらかの軸を作って改善する志が素晴らしいです。
フィードバックを歓迎している
ウォーターフォールは開発プロセスであり、根底にある思想はテイラー主義です。テイラー主義では、「人はリソース」、監督者は別です。完成は作る人ではない人が定義します。
スクラムは開発プロセスであり、根底にある思想はアジャイルソフトウェア開発宣言です。「人はリソースではなく」、完成は実務者（PO、開発者、SM）が決めます。
スクラムそのものの完成の定義はないので、監督されるリソースではない実務者が互いにフィードバックしつつ、目標へ軌道修正していきます。
そのため、ネガティブな意見もポジティブな意見も、改善のための情報として歓迎されます。
（ウォーターフォールとアジャイルが対比されることが多いので、思想とプロセスの関係を下記に整理してみました）
見えないものを可視化する
不安は目に見えません。目に見えないものは共有できず、対策を考えられません。
「夜も眠れない問題」＝不安の可視化は解決への一歩です。チームで不安・リスクを可視化し共有すれば、対策を考えることができます。
不安・リスクが全部あげられなくても、スナップショットでも、可視化できればチームでぐるぐると思い悩むことは減ります。
不安・リスク以外の目に見えないもの（互いへの期待、役割の内容、スキルの状況、などなど）にも可視化は有効です。
ひとりで行う可視化なら、ジャーナリング、ブレインダンプ、3行日記なども有効です。
おわりに
以上、いままでの体験から「なぜスクラムは難しいのか？」を考え、それでもアジャイル/スクラムを薦める理由を書いてみました。
この記事内のまとめや図は個人の思考の整理ですが、なにかのご参考になれば幸いです。
