スクラムを採用するべきでない7つの理由(翻訳)

こんにちは。mofmofの英語できない勢筆頭の岩井が英語に親しもうと思って、最近見かけたスクラム記事を翻訳してみました。雰囲気で訳してしまった部分もありますので、ご指摘等いただけましたら幸いです。なお文中丸括弧で括られた部分は訳者補足部分です。

著者はWillem-Jan Ageling氏で、原文はこちら7 reasons not to use Scrum

では以下翻訳です。


スクラムは全ての問題に通用すると考える人がいる。多くの人がスクラムの流行に乗っかっている。しかしスクラムはいかなる環境でも最適解となるようなものではない。スクラムが適さないであろう7つの例を紹介しよう。

1. 取り組む物事があまり複雑ではない

スクラムの定義はこうだ:

“複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。”—スクラムガイド 日本語版より

複雑な環境下では少し先の未来すら見通すことはできないだろう。チームも、技術も、要望も、市場も、何もかも変化していく。スプリントを計画することはとても難しい。(だけど、)たぶん2〜3スプリントの間に何をすることが重要なのかは考えつくかもしれないね。これが複雑な環境下において、小さなステップを踏んで検査と適応をしたい理由だ。

何が次に最も高い価値をもたらすのかという最新の成果と知見によって、次のスプリントのゴールと計画が決まる。

あなたはこれから数ヶ月の間に起こることを知っている?環境は見通せる?そうであるなら、あなたは複雑な環境で仕事をしていない。つまり、あなたの仕事にスクラムは適していないということだ。

2. スクラムチームの環境が経験主義の結果を受け入れない

よし、仕事が複雑だとしよう。でも、あなたの会社が、なにか新しいことが判明したときに、計画を適応させるよりも計画に従うことにこだわるようなところではない?新しく見つけた複雑性を、価値ある学びでなくリスクとみなす?

2つのシチュエーションを考えてみよう。

  • ステークホルダーが、スプリントバックログの変更を受け入れない。それがスプリントのゴールに到達するためのチャンスを大きくするような変更であっても。
  • ステークホルダーが、スプリントの間にあなたの学びを受け入れない。それは次のスプリントでの仕事に影響があるであろう学びだった。

もしあなたがステークホルダーによって経験的なやり方を邪魔されたり、経験から得たものによって今後のあり方を変える機会がないようであれば - スクラムに取り組むべきではない。あなたを傷つけるだけに終わるだろう。

3. スプリント終了時にリリース判断可能なプロダクトインクリメント(リリース可能な状態の製品)を配信する方法がない

“スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。”—スクラムガイド 日本語版より

もし1ヶ月以内に利用可能かつリリース判断可能なプロダクトインクリメントを配信する方法がないなら、検査するものは何もない。これが意味することは、インクリメントに基づいてプロダクトバックログを適応させる方法がないということである。それではスクラムである意味がない。

そうは言っても - 多くの人はとりわけ最初のスプリントでは取り掛かり中のインクリメントを配信することができないという。多くの場合彼らは思考方法を根本的に変える必要がある。

たいていは、どんなに小さいものであったとしても、インクリメントを配信する方法はあるのだということは確かだ。

4. チームを自己組織化することが不可能

“スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。”—スクラムガイド 日本語版より

もし会社が、チーム自身が最善の成果を出す方法を決めることを許さないなら、スクラムは適していない。
スクラムは、チームが何かをするときに指示を受けること意図していない。

他にも考慮するべきことがある:
もしチームが同じスプリントゴールに共に向かって仕事をすることができないのであれば - 例えば彼らがそれぞれサイロ(家畜飼料・穀物などの貯蔵庫。居場所が分離されていることの例)の中で仕事をしていて、一緒に仕事をするための技術的手段がないため - 同様に自己組織化されたテームを持つことはできない。

チームはどのようにスプリントゴールまで到達するか決定する力を与えられるべきだし、メンバー同士が密接して仕事することが可能であるべきだ。

5. スクラムマスターが組織を変えることを許されていない

“スクラムマスターは、さまざまな形で組織を支援する。[中略] スクラムチームの生産性を高めるような変化を促す。”—スクラムガイド 日本語版より

スクラムの鍵となる側面の一つは、チームが自分たちの働き方を共に継続的に改善することができるというものである。多くの場合、そういった改善はチーム外からもたらされるものを変えることによってのみ達成される。例えば:

  • スクラムチームの足を引っ張る手続き
  • チームにネガティブな影響を与える、スクラムチーム外の人々の振る舞い
  • チームのパフォーマンスを改善することができる技術的な問題

スクラムマスター、もしくはスクラムチームの誰かがこれらの変更を実現する支援が許されていないとき、スクラムは向いていない。

6. スクラムチームが自由にスクラムの価値基準を容認することができない

“スクラムチームが、確約(commitment)・勇気(courage)・集中(focus)・公開(openness)・尊敬(respect)の価値基準を取り入れ、それらを実践するとき、スクラムの柱(透明性・検査・適応)は現実のものとなり、あらゆる人に対する信頼が築かれる。”—スクラムガイド 日本語版より

スクラムの価値基準を容認せず、チームに悪影響を与えかねない多くのやり方が存在する。いくつか例を挙げよう。

  • スプリントバックログに集中することが許されていないために、スクラムチームのゴールを確約することができない。
  • 開発チームは、チームを邪魔する障害を公にする勇気を持つことで罰せられる。
  • 個々人は、自身のスプリントバックログのアイテムを終わらせるための課題をオープンにすることを歓迎されない。
  • スクラムチームが自身の業務遂行能力への敬意を得られない。

スクラムチームはスクラムの価値基準を容認する/できるべきである。これなくして十二分に機能するチームは実現不可能だ。

7. ステークホルダーがスプリントレビューに一切参加しない

“スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。”—スクラムガイド 日本語版より

ステークホルダーがスプリントレビューに参加することは非常に重要だ。彼らは、スプリントで完了したことに対する価値あるフィードバックと次のスプリントで何を行うかに関するアイデアを提供するだろう。この検査と適応の時間は、スクラムが得意とする複雑な環境において非常に重要である。

もしあなたが、ステークホルダーがスプリントレビューに参加しないような状況にいるならば、何がこのイベントの焦点となるのだろう?また、もしスプリントレビューに価値がないのなら、何がスクラムを行うことの価値になるのだろう?

まとめ

“スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークである。”—スクラムガイド 日本語版より

もしあなたがこのような状況でないなら - 環境が複雑でないなら -、スクラムは選択するフレームワークではない。

そして- スクラムは、役割・技能・イベントとルールのセットを持っている。これらは「スクラム」を望むのであればすべて要求される。スクラムはあなたの組織を破壊しうる。スクラムはとても変わった働き方を紹介する。
もしこの記事に記載されている内容に喜んで取り組むことができるのなら、ゆっくりと、でも確実に、スクラムがどのようにあなたの成功を支援してくれるのか気付くだろう。しかし、もしこれに取り組むことに注力できないのであれば、スクラムを採用しない方が良い。

訳者まとめ

スクラムの強みを発揮するためにはこういう状況は望ましくないよねという風な、アンチパターンを語る形式でスクラムの強みを紹介する内容になっていましたね。

大前提として、ソフトウェア開発はたいていめちゃくちゃ複雑だと思っています。作ってほしい人と作る人が無形のものの認識を共有しなきゃいけないし、開発業務だって増改築前提で一部屋一部屋家を作っていくようなものだし、しかも作ったあとで使う人からの要望や不満に対応していく必要があります。

その上で満たすべきは「チームが自律的であること」「ステークホルダーが積極的に参加すること」となるでしょう。さらに、例えばmofmofが得意とする新規開発案件であれば、リーンスタートアップの思考を乗せてプロジェクトを進めます。

リーンキャンバス テンプレート

あなたのビジネスの構造がわかる 一枚のテンプレート【無料】

ダウンロード →
インセプションデッキ テンプレート

インセプションデッキの要点を解説 テンプレート付き実践ガイド【無料】

ダウンロード →
記事の作成者・監修者
Railsエンジニアです。ものづくりの人として成長するためにSIerからmofmofにやってきました。プロダクトに関わる全ての人を喜ばせたい。卓球室のある家を建てるのが夢。
記事の作成者・監修者
Railsエンジニアです。ものづくりの人として成長するためにSIerからmofmofにやってきました。プロダクトに関わる全ての人を喜ばせたい。卓球室のある家を建てるのが夢。