■スクラムだけがアジャイルじゃない

『アジャイルソフトウェア開発宣言』の価値観に反対する人はほとんどいないと思う。

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

かつて、数々のアジャイルな開発手法が存在して（というか今も存在しており）、この宣言はそれらの開発者が集まって合意したものだ。

ところが、最近ではスクラムだけがもてはやされ、他の手法に全く触れられないことに違和感がある。

また、「うまくいかない原因の根本はそもそも開発チームの問題なんだっけ？」って問題そのものを議論せず、スクラムだけを導入すれば解決すると思い込まれていると思う。

スクラムへの違和感

私がスクラムについて違和感を持っているのは以下のような点だ。

• 良くも悪くも、スクラムは開発チーム以外の部分を変えなくても導入できてしまうように思う。もし外に問題があるとしても、その変革はあまり主張されていないし、スクラムマスター個人に任されている
• 自分の周囲では、実際に成功したチームがスクラムに準拠していないことが多い。最初はスクラムだったとしても、プロダクトオーナーが個人でなくなったりして柔軟に変化させている
• スクラムはスクラムガイドとその他ドキュメントが整備されている分、教条主義になりやすい。その内容も脱文脈化され「この部分を変えたらどういう悪影響があるのか」ということが分かりづらく、開発チームの変化を促さない
• Scrum Allianceがうさんくさく、資格ビジネスの側面も大きいんじゃないかと感じることがある。たしかにスクラムは他の手法（例えばXPやカンバン）に比べて商業的に成功しているが、流行っているプログラミング言語が良い言語とは限らないのと同じだ。またプログラミング言語よりチームごとの工夫や変更が簡単だし、重要だと思う
• プロダクトオーナーの役割が偉そう。結局トップダウンで意思決定してるのが気に食わない（※これは自分の性格の問題かもしれないｗ）

※ただし、開発チーム以外を変えなくても導入できるのはメリットでもあり、それでチームの負荷を下げつつ他の問題に対処するのは悪い手ではないと思う

一方で、例えばXPは「開発が成功するためにチーム内外に向けてなんでもやれ」という視点が強く、「ビジネス上と技術上の責任を分ける」などのアドバイスの章も用意されている。

ただその分「ここに注意せよ」くらいしか書かれておらず、結局どうやるかは自分たちで試行錯誤しなければならないことは変わりがないが。

スクラム（というか開発手法全般）を不適切に導入した後の最悪のケースは、本当は他の要因で問題が起きているのに、その分析が全く行われずに、開発チームにだけ際限のない改善が要求されることだ。

例えば「みんなリファクタリングをしなきゃいけないことに気づいており、それが評価されないから新規プロジェクトに力を入れざるを得ない状況だと知っているが、それを誰も口に出さない。その状態で正確な見積もりをしようとしたり、開発スピードだけ効率を上げようとする」という状況は誰もが身に覚えがあると思う。

主張したいこと

つまり、我々の所属するソフトウェア開発チームでは、目の前に存在する問題に対処してアジャイルチームになることが重要で、その方法はスクラムで主張されているような開発手法とは限らないし、むしろそのわかりやすさやきれいなドキュメントがミスリードである場合もある。

そのためには、まず現実の課題が何なのかしっかり把握して、フェアに議論することから始めるのが重要なんじゃないか。

参考文献

• Clean Agile 基本に立ち戻れ（isbn:4048930745）:「アジャイルは小規模なソフトウェア開発チームのためのもので、大規模アジャイルやソフトウェア以外への適用に違和感がある」「実践こそが大事でスクラムマスターが数週間の研修でできるようになるわけねえだろ」と批判している
• XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法（isbn:489471275X）: Clean Agileでは「XPがアジャイルの基本形で、他の手法はその派生だと捉えるのがいい」と解説されている。新版もあるが、Clean Agileの著者のおすすめはこっちらしい。割といいこと書いてる

Permalink | 記事への反応(1) | 09:20

ツイートシェア