有名な開発フレームワーク”スクラム”が、現代のアジャイル開発にもたらした貢献は多くの人が認めるところだと思います。
私自身も、スクラムの思想である「経験主義」「リーン思考」に強く影響を受けた人間の一人です。
私はスクラムの考え方自体はかなり好きですが、唯一賛成できない点があります。
それは『スクラムの一部を変えたものはスクラムと呼ばない』というルールです。
スクラムガイドには以下のように記載されています。
最後に
スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。
おそらくスクラムガイドの著者は「正確な”スクラム”の定義とはなにか？」を示すためにこの記載を入れたのだと思います。
しかしこの記載があることで、スクラムの理論を熱心に勉強した人やスクラムを教えることを飯の種にしている人が、いくつかのプラクティスが抜けているだけで「それはスクラムではない」と指摘しているケースを見かけることがあります。
たいていの場合スクラムは杓子定規にそのまま守るより各現場にフィットするようカスタマイズしたほうが効果を発揮すると思います。
スクラムの定義を厳密に守るのに傾倒することは本質から外れており、エンジニアリングプロセスの創造性を阻害する行動です。
米国生まれの流行りのフレームワークに盲目的に乗っかるのではなく、開発プロセスは自分たちの頭で考え改善していくべきです。
この記事では『スクラムは積極的にカスタマイズして使うべき』だと考える理由について説明します。
厳密なスクラムの利点・欠点
厳密なスクラムについて一言で個人的感想を言うと、『現場目線というよりは経営陣などマネジメント層が喜ぶフレームワークだな』です。
スクラムはマネジメントフレームワークとしては非常に優秀で、一連のプロセスを守ることで、「属人性排除」「人的トラブル低減」「新人教育」「精度高いプロジェクト管理」などが勝手に実現されます。
運用に時間がかかるという大きなデメリットはありつつも、開発組織が非常に管理しやすくなりスケールもしやすくなるため、マネジメントに喜ばれるフレームワークです。
なぜなら組織として開発を「安定的に」「トラブルなく」「見積もり精度高く」遂行し続けることができ、チームメンバーの入れ替わりにも強く、また組織拡大によりチーム数を増やす場合でも（同じフレームワークで運用していれば）スケールしやすいためです。
一方で現場目線（イチ開発者目線）で言うと、スクラムの運用に時間が取られすぎだと感じます。
スクラムでは透明性を担保するためにスプリントゴールやバックログアイテムの定義・見積もり・実現方法などについて、チームメンバーでガッチリ詳細まで合意する必要があります。
そのため長いMTGが必要だったり、仕様や受け入れ条件などドキュメントをきっちりと整備する必要があるため、とにかく時間がかかります。
特にコードをガッツリ書きたい人やスピーディに機能開発をしていきたい人にとっては、間接業務ばかりしてコーディングという直接的な生産活動に携われないことは、自身の手足が縛られているような感覚でしょう。
また現場目線でいうと、スプリントゴールまでの詳細な進捗を毎朝どんなときも事細かに共有し続けるのは、少し息苦しく感じます。
皆がゴールにコミットし進捗を日次で詳細に共有するスタイルは、ムダなくゴールに向かうことができるスタイルではあるのですが、創造的な試みや日常の細かな改善がおざなりになりやすい点に注意が必要です。
長期的に続けるのであればゆとりが欲しいなと個人的には感じてしまいます。
個々人の裁量である程度は自由に使える時間があり、その中でちょっと気づいた箇所をリファクタリングしたり、イノベーティブな試みを検証したり、調べものをじっくりしたりといったスプリントゴールから外れるようなこともしていいんじゃないかと思っています。
こういったゆとりは、仕事の緩急という意味でのメリハリにもつながり、体調のコンディションをいい状態に保ち続けるのにもつながります。
例えば私がいるチームでは『20%ボーイスカウトルール』というものがあり、最大20%程度であれば自己裁量でリファクタリング・テストコード・ドキュメント整備・ライブラリアップデートなどに時間をかけても良いルールがあります。
本家のスクラムに厳密に従うと、こういったゆとりは入れづらいのではないかと思います。
※ コード含めあらゆる環境をクリーンにリファクタリングし続けることで生産性を高く保つ考え方については以下記事でも紹介しました。
おわりに
というわけで「厳密なスクラムを実践するのではなく、スクラムライクなオリジナルの制度を皆それぞれのチームに合った形で考えればいいじゃないか！」というテーマについて書きました。
スクラムを構成する諸要素はすごく効果的なものが多く、またスクラムの背景思想も素晴らしいので、初めの一歩としてスクラムをまず初めに原典にそって厳密に実践してみること自体は悪いことではないと思います。
しかしスクラムの基本的な型を学んだのであれば、それを厳密に守り続けるのではなく、どんどん応用していったほうが生産的で創造的なチームになるのではないかと思います。
