弛緩したスクラム (Shisūshita Sukuramu)

最近、多くのプロジェクトで耳にする問題があります。それはこのような状況です。

• 彼らはアジャイルプロセスを使用したいと考えており、スクラムを選択しました。
• 彼らはスクラムのプラクティス、そしておそらく原則も採用しました。
• しばらくすると、コードベースが混乱しているために進捗が遅くなります。

何が起こったかというと、彼らはソフトウェアの内部品質に十分な注意を払っていませんでした。そのミスを犯すと、新しい機能を追加するのが想像以上に難しくなり、生産性が低下することにすぐに気づきます。技術的負債 (Gijutsuteki fusai)を抱え込み、スクラムは膝が弱くなりました。（そして、本物のスクラムを経験したことがあるなら、それが悪いことだとわかるでしょう。）

スクラムについて言及したのは、この問題が発生した場合、スクラムがチームが従っている代表的なプロセスとして特に一般的であるように見えるためです。多くの人にとって、この状況はスクラムによって悪化します。なぜなら、スクラムはプロジェクト管理手法を中心としたプロセスであり、（たとえばエクストリームプログラミングとは対照的に）技術的なプラクティスを意図的に省略しているからです。

スクラムの擁護として、その範囲内に技術的なアクティビティが含まれていないからといって、それが重要ではないと結論付けるべきではないことを指摘しておくことが重要です。私が著名なスクラムマスターの話を聞いたときはいつでも、彼らはスクラムプロジェクトを成功させるためには優れた技術的なプラクティスが必要であることを常に強調していました。彼らはそれらの技術的なプラクティスがどのようなものであるべきかを義務付けていませんが、それらは必要です。結局のところ、プロジェクトは常に内部品質の悪さで問題を抱えています。スクラムの下で多くのプロジェクトが問題を抱えているという事実は、スクラムが現在非常に人気があるため、スクラム特有のことよりもその方が原因かもしれません。人気と意味の拡散 (imi no kakusan)は、一緒に起こりがちです。

では、どうすればよいのでしょうか？

スクラムコミュニティは、人々が強力な技術的プラクティスの重要性を理解するように、努力を倍増する必要があります。確かに、どのような種類のプロジェクトレビューにも、どのような種類の技術的プラクティスが存在するかの調査を含めるべきです。そのようなプロジェクトに関わっている場合、技術的な側面が軽視されている場合は、騒ぎを起こしてください。

スクラムを導入しようとしている場合は、技術的なプラクティスに十分な注意を払ってください。私たちはエクストリームプログラミングの多くのプラクティスを適用する傾向があり、それらはうまく適合します。XP実践者は、いくらか正当な理由で、スクラムはそれを機能させる技術的なプラクティスがないXPであると冗談を言います。皮肉はさておき、XPのプラクティスは良い出発点であり、何もせずにいるよりも間違いなくはるかに優れています。

私は常に、成功したり失敗したりするのは方法論ではなく、チームであることを指摘したいと思っています。プロセスの採用はチームのパフォーマンス向上に役立ちますが、最終的にはチームが重要であり、自分たちにとって有効なことを行う責任を負います。多くの弛緩したスクラムプロジェクトの実行は、スクラムの評判、そしておそらくより広いアジャイルの評判も損なうことは間違いありません。しかし、私は意味の拡散 (imi no kakusan)は避けられないものと考えているため、過度に心配していません。失敗するチームは、どのような方法論を誤用してもおそらく失敗し、成功するチームは良いアイデアに基づいてプラクティスを構築し、スクラムコミュニティの役割はこれらの良いアイデアを広く普及させることです。

多くの人が、リーンを次の大きなアジャイルなものとして見ています。しかし、リーンが人気になるほど、スクラムが現在直面しているのと同じ種類の問題に遭遇するでしょう。それはリーン（またはスクラム）が無価値であるという意味ではありません。それは単に、個人と相互作用はプロセスとツールよりも価値があることを思い出させてくれます。