スクラム開発に関する所感
先日、Scrum Allianceの認定スクラムマスターの資格を取得しました。
こちらの資格は定められた何らかの講習を受けた後、1時間の試験を受けることで取得できるものです。
上のツイートでは言いたい放題できるとイキり散らかしていますが、実際にはこの資格の上位にあるものがまだ２つもあるのでまだまだ先は長いです。
まあ、上位の資格を取得する予定も今のところないのですが…
正直なところ、スクラムに限らずこういう方法論の話には基本的に懐疑的で、以前はそういうものを積極的に勉強することはあえてしていませんでした。
実際にスクラムコーチがやってきてレクチャーをしてもらうという機会もあったのですが、正直言っていることとしては当たり前のことしか言っていないなあという印象でした。
しかしながら、周りの人を見ていると自分が当たり前だと思ったことが案外当たり前でなかったりということに気がつき、その自分の中の当たり前の感覚を正確に言語化して再現性を高めるという事自体は大事なのではないかと感じまはじめました。
また、自分の感覚のベースとなっているのはわずか２社での経験でしかないので、より多くの経験に支えられているであろうスクラムの理論を学ぶことは十分に意義があると思い今回資格取得をすることにしました。
スクラムとアジャイル
スクラムはアジャイル開発の一つの方法論です。つまり、アジャイル開発という哲学を実践するための方法論がスクラムです。
アジャイルソフトウェア開発はアジャイルソフトウェア開発宣言に基づく開発手法の総称です。
スクラムについてはスクラムガイドというのが公開されていて、その最新版は2020年にリリースされています。
今回はスクラムとアジャイルの詳細については深く突っ込まないでおきます
スクラムの実践は難しい
スクラムは軽量なフレームワークを謳っていますが、厳格に運用しようとすると非常に難しい場面によく遭遇します。
一番わかり易いのはプロダクトバックログアイテムの粒度です。
各プロダクトバックログアイテムは1スプリント内に完了しないとならないと定義されかつ、完了した時点でレビュー可能な状態でなければならないとされています。
1スプリント内に完了しないようなアイテムは分割して1スプリント内に完了可能な粒度にする必要があります。
しかし、分割したアイテムもまた完了した時点でレビュー可能な状態になっていなければならないので、単なる途中経過報告しかできないとかは許されません。
現実には、このような分割が不可能でかつ1スプリント内で完了しないようなアイテムが存在することが多々あります。
これを厳格に実践してしまうとすぐに終わるような簡単な改善アイテムばかりのみを取り掛かることになり、本質的な問題に取り組めないという状態に陥りかねません。
また、スクラムの実践にはチーム全員が高いモチベーションで取り組むことが求められます。
このような状況をつくりだすのはスクラムマスターの責任であるとされていますが、チーム内のそれぞれ得意・不得意がある中で実現していくのはかなり難しいです。
では、難しい箇所をいい塩梅で避けてスクラムを部分的に実践すればいいのでは、ということになりそうですが、一般的にはスクラムを部分的に実践しても意義がないとされています。
また、世の中のスクラムコーチと言われている人にも実践という部分となるとおや？っとなることを言っている場合もあります。
例えば、プロジェクト管理ツールとして有名なJiraですが、これはアジャイル開発に向いていないと主張している人が一定数います。
しかし、私の前職ではJiraを使ってアジャイルな開発を行っていましたし、今思い返してもむしろJiraはスクラム開発を助けるものとしては価値のあるツールに思えます。
では一部のスクラムコーチがなぜJiraを使うべきではないと主張するのか実際に聞いたところ、どうやらJiraの機能であるバーンダウンチャートだかなんだかの機能がスクラムの理論に反しているということらしいです。
が、自分はそんな機能を使ったことはおろか、そんな機能があることすら知りませんでした。Jiraのコア機能でない部分を持ち上げてJiraを叩いていたということのようです。
多分、その人がコンサルしたチームで恐ろしいJiraの使い方をしていて、それがトラウマになってJiraが悪いみたいな話が広がってしまったのだと思います。
スクラムとどう向き合うべきか
ここまでの話はスクラムは非現実的で使えないものだとか、スクラムコーチはいい加減で信用できないとかそういうことを主張したいわけではありません。
今回の研修や資格勉強を通じてスクラムとアジャイルの理論・背景を学んだのですが、それ自体は非常に有意義ではありました。
また、今いる会社ではスクラムコーチによる支援を受けてスクラムの実践をしているのですが、やはりコーチが入る前と後ではチームの動き方が変わり良くなってきたと感じています。
主張したいこととしては、盲目的にスクラムというものを信じるのではなく、その背後にある理論・背景を理解しつつこういうプラクティスを実践していくのがよいのではということです。
また、スクラムコーチや他のSNSとかで評価されているような人の意見でも、たしかに豊富な経験に裏打ちされた提案をされているのだとは思いますが、必ずしも自分たちが抱えている問題に沿ったものとは限らないので、自分たちの問題の本質はどこにあるのかを正確に見抜く必要があります。
先程例に出した大きいアイテムに着手できない問題ですが、スクラムがこのような厳しい制約を課しているのは、このような長期間フィードバックがかからない状態や余計な機能を作り込んでしまうというリスクを回避するというのが背景にあります。
このようなリスクと天秤にかけて、それでもやらないといけない・リターンが十分に大きいといった場合は勇気をもって取り組むといった動きをするのがよさそうです。
逆にスクラムのフレームワークに固執し、そういうアイテムを永遠と先送りしたり無理に分割してしまうことは、価値のあるソフトウェアから遠ざかったり、逆に無駄な機能を作り込むといったことを引き起こしかねません。これでは本末転倒です。
スクラムの提唱するフレームワークは当然理由があって設計されいて非常に有用ではあるわけですが、絶対神聖視してしまうというのは逆効果になりかねないのではないかと思います。
これを機にスクラムに興味が出てきた方は、ぜひ認定スクラムマスターの資格に挑戦してみては…と言いたいところですが、この資格取得はその前の講習が必要なのもあり結構バカにならない金額がかかります（私の場合は会社が負担してくれました。サンキュー弊社）。
ということで、まずはとっかかりとしてスクラムガイドやIPAの出しているこちらの開発宣言の読みとき方を読んでみるとよいと思います。
自分はこれからスクラムマスターとかを任される（まあ実質的に近い役割をやっていたりはしますが…）とかそういうキャリアに進んでいくことが確定したわけではないのですが、まあ一応一通りスクラムの理論は学習したということで、なにかお役に立てそうなことがあればお気軽にお声がけください。
Discussion