新しいソフトウェア開発手法を導入することは、「変化を受け入れたがらない」といったものから「誤った導入方法」ようなものまで幅広く、いくつもの失敗へと繋がる課題がある。Cesario Ramo氏とEelco Gravendeel氏は、アジャイルジャーナル(リンク)の連載記事の中で (リンク) (リンク) (リンク)、スクラムで仕事をしている時であったり、さまざまな組織にスクラムを導入した時に気付いた課題について語っている。スクラムを導入する組織的な計画にとって、こういった課題に関する知識とそれを乗り越える戦略が、導入プロセスを容易にするとしている。なかでも主な課題とその解決策として以下のものを挙げている。
- 組織的な学習をしていない – ふりかえりのフィードバックが出なかったり、プロセスが改善できるように組み入れられていない時に起きる。理想を言えば、全てのフィードバックは最終的にアクションアイテムに落ちるべきだ。こういったアクションアイテムは、プロジェクトに影響を与えようともチームで取り上げ、組織に影響があろうともメタスクラムマスタが取り上げるべきだ。
- 信頼関係の欠如 – こういった環境では、人はしばしば失敗を隠すようになり、意見は共有されず、意志決定は遅れがちになる。解決方法は、ポジティブなフィードバックが起きる環境を構築することだ。会話がやりとりされるさまざまな場面で、情報発信器を使用することでそれを実現することができる。
- 何が問題なのか理解とせず、スクラムを応急的に用いること – 誇大広告に惑わされて、新しい手法を導入すべきではない。組織というものは、期待値と測定基準を定めるべきだ。「現在のプロセスを損ねているのはどこなのか？」「何が損失を引き起こしているか？」「損失が止まった時、自分たちが出来ることは何か？」こういった質問に答えることは、客観的な期待値と測定基準を定める手助けになるはずだ。
- 資質に問題のあるプロダクトオーナー – こういったプロダクトオーナー達は、効果的に行動するだけの知識、あるいは権限を持っていない。 最悪のケースでは双方が無いこともある。翼をもがれたプロダクトオーナーは、すばやい決定を下すだけの能力が不足しているので、結果的にチームのベロシティを損ねることになる。
- アジャイルを厳密、かつ型通りに"しか"できない – スクラムは簡潔なプロセスだが、複雑な行動パターンを持っている。ある組織でうまくいくものが、別の組織ではうまくいかないこともある。型通りに"しか"やらない場合、全てのシナリオで役に立つとは言えない。スクラムは、一度その手法を理解した上で、組織が必要としている方法でカスタマイズする必要がある。
- 組織がスクラムプロジェクトを取り囲むように整備されていない – スクラムを導入しているチームは分散して仕事することはできない。チームが成功するには、他の様々なチームとふれあっている必要がある。営業とマーケティングと緊密な連携はプロダクトの独立性に必要だし、テストと設計チームと緊密な連携はチームの一員として巻き込む為に必要だ。そして、経営陣との緊密な連携はプロジェクトをトラッキングしレポートする新しい手段と考えることもできる。新しい手法の周りにチームを配置し、全ての部署を巻き込むことで、スクラムをイチ早くそして簡単に導入することができる。
- メタスクラムマスタの不在 – プロジェクトレベルで動いているスクラムマスタでは、全ての障害を解決できるわけではない。スクラムによって浮き彫りにされるものの中には、プロジェクトを横断して解決する必要がある、組織のレベルの障害もある。この場合は、上級管理職がメタスクラムマスタの役割を演じ、解決までに要する時間とROIを目に見える形にした上で、障害を解決する必要がある。
- 試したがりの口実としてスクラムを使う – こういった行いは、新しい手法を採用するという名目で、すでにある良いプラクティスを放り出すようなものだ。スクラムは、非効率的なものや問題を素早く表面化する手助けとなる。重要なのは、あらかじめ最適化してしまうのではなく、問題が表面化するのを待ち、それから取り組むことだ。
- アジャイルをあなどっている – アジャイルの根底にある考え方はシンプルだが、実際に実行するのは難しい。一番よい方法は、アジャイルコーチがチームを支援することだ。熱心なアジャイル推進派達が組織にいることで、様々なレベルで訓練された人々がアジャイルを伝道し、ワークショップを行い、スクラムマスターをコーチするようになる。これが、スクラムの導入において最も重要な要素となっている。
Cesario氏とEelco氏は、組織の中にいる人は、新しい手法に対して多くの疑念を持つだろうと言っている。導入を成功に導くためには、こういった疑念を適切に解決する必要がある。
彼らによると、
結局疑問はこういったものにつきます。計画と見積りはどう対処すればいいの？どうやって見通しをたてるの？アジャイルの契約はどう運用するの？デッドラインは確定できるの？アーキテクチャはどうしたらいい、放っておいても明確になるものなの？要件定義と開発とテストを同時に行うなんて可能なの？バカにするな！！どうやって効果測定したらよいの？あと、どうやって価値に基づいて要求を優先度付けするつもりなの？それから、PDCAってのがあるんだけど、これはどうすべきなの？アジャイルでやったら高くつくんじゃない？
こういった質問にうまく答えられないと、プレッシャーがかかった時に、いつもやっている仕事のやり方に戻ってしまいかねないのです。最初に見受けられるのは、品質が下落とテストする努力の放棄です。また、いつのまにか元通りのコマンドコントロール型の管理手順になってしまっています。結果的にモラルが欠落し、ベロシティもガタ落ちになり、プロジェクトではスクラムの導入が中止になり、さらに混迷の度を深めていきます。
このように、新しい手法を導入することは、複合的な課題を孕んでいる。重要なのは、より大きな全体像と、実現しなければいけないメリットに焦点を当てることだ。これは、持続的な学習と順応能力を文化として組織に根付かせることでしか為し得ることはできないだろう。
原文はこちらです：http://www.infoq.com/news/2008/12/scrum-adoption-challenges