InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

スクラム導入時の課題

作者 Vikas Hazrati , 翻訳者 近藤 修平 - (株)永和システムマネジメント 投稿日 2009年1月5日

セクション
プロセス/プラクティス
トピック
Agile ,
Agileの採用
タグ
Scrum

新しいソフトウェア開発手法を導入することは、「変化を受け入れたがらない」といったものから「誤った導入方法」ようなものまで幅広く、いくつもの失敗へと繋がる課題がある。Cesario Ramo氏とEelco Gravendeel氏は、アジャイルジャーナル(リンク)の連載記事の中で (リンク) (リンク) (リンク)、スクラムで仕事をしている時であったり、さまざまな組織にスクラムを導入した時に気付いた課題について語っている。スクラムを導入する組織的な計画にとって、こういった課題に関する知識とそれを乗り越える戦略が、導入プロセスを容易にするとしている。なかでも主な課題とその解決策として以下のものを挙げている。

  1. 組織的な学習をしていない – ふりかえりのフィードバックが出なかったり、プロセスが改善できるように組み入れられていない時に起きる。理想を言えば、全てのフィードバックは最終的にアクションアイテムに落ちるべきだ。こういったアクションアイテムは、プロジェクトに影響を与えようともチームで取り上げ、組織に影響があろうともメタスクラムマスタが取り上げるべきだ。
  2. 信頼関係の欠如 – こういった環境では、人はしばしば失敗を隠すようになり、意見は共有されず、意志決定は遅れがちになる。解決方法は、ポジティブなフィードバックが起きる環境を構築することだ。会話がやりとりされるさまざまな場面で、情報発信器を使用することでそれを実現することができる。
  3.  何が問題なのか理解とせず、スクラムを応急的に用いること – 誇大広告に惑わされて、新しい手法を導入すべきではない。組織というものは、期待値と測定基準を定めるべきだ。「現在のプロセスを損ねているのはどこなのか?」「何が損失を引き起こしているか?」「損失が止まった時、自分たちが出来ることは何か?」こういった質問に答えることは、客観的な期待値と測定基準を定める手助けになるはずだ。
  4.  資質に問題のあるプロダクトオーナー – こういったプロダクトオーナー達は、効果的に行動するだけの知識、あるいは権限を持っていない。 最悪のケースでは双方が無いこともある。翼をもがれたプロダクトオーナーは、すばやい決定を下すだけの能力が不足しているので、結果的にチームのベロシティを損ねることになる。
  5. アジャイルを厳密、かつ型通りに"しか"できない – スクラムは簡潔なプロセスだが、複雑な行動パターンを持っている。ある組織でうまくいくものが、別の組織ではうまくいかないこともある。型通りに"しか"やらない場合、全てのシナリオで役に立つとは言えない。スクラムは、一度その手法を理解した上で、組織が必要としている方法でカスタマイズする必要がある。
  6. 組織がスクラムプロジェクトを取り囲むように整備されていない – スクラムを導入しているチームは分散して仕事することはできない。チームが成功するには、他の様々なチームとふれあっている必要がある。営業とマーケティングと緊密な連携はプロダクトの独立性に必要だし、テストと設計チームと緊密な連携はチームの一員として巻き込む為に必要だ。そして、経営陣との緊密な連携はプロジェクトをトラッキングしレポートする新しい手段と考えることもできる。新しい手法の周りにチームを配置し、全ての部署を巻き込むことで、スクラムをイチ早くそして簡単に導入することができる。
  7. メタスクラムマスタの不在 – プロジェクトレベルで動いているスクラムマスタでは、全ての障害を解決できるわけではない。スクラムによって浮き彫りにされるものの中には、プロジェクトを横断して解決する必要がある、組織のレベルの障害もある。この場合は、上級管理職がメタスクラムマスタの役割を演じ、解決までに要する時間とROIを目に見える形にした上で、障害を解決する必要がある。
  8. 試したがりの口実としてスクラムを使う –  こういった行いは、新しい手法を採用するという名目で、すでにある良いプラクティスを放り出すようなものだ。スクラムは、非効率的なものや問題を素早く表面化する手助けとなる。重要なのは、あらかじめ最適化してしまうのではなく、問題が表面化するのを待ち、それから取り組むことだ。
  9. アジャイルをあなどっている – アジャイルの根底にある考え方はシンプルだが、実際に実行するのは難しい。一番よい方法は、アジャイルコーチがチームを支援することだ。熱心なアジャイル推進派達が組織にいることで、様々なレベルで訓練された人々がアジャイルを伝道し、ワークショップを行い、スクラムマスターをコーチするようになる。これが、スクラムの導入において最も重要な要素となっている。

Cesario氏とEelco氏は、組織の中にいる人は、新しい手法に対して多くの疑念を持つだろうと言っている。導入を成功に導くためには、こういった疑念を適切に解決する必要がある。

彼らによると、

結局疑問はこういったものにつきます。計画と見積りはどう対処すればいいの?どうやって見通しをたてるの?アジャイルの契約はどう運用するの?デッドラインは確定できるの?アーキテクチャはどうしたらいい、放っておいても明確になるものなの?要件定義と開発とテストを同時に行うなんて可能なの?バカにするな!!どうやって効果測定したらよいの?あと、どうやって価値に基づいて要求を優先度付けするつもりなの?それから、PDCAってのがあるんだけど、これはどうすべきなの?アジャイルでやったら高くつくんじゃない?

こういった質問にうまく答えられないと、プレッシャーがかかった時に、いつもやっている仕事のやり方に戻ってしまいかねないのです。最初に見受けられるのは、品質が下落とテストする努力の放棄です。また、いつのまにか元通りのコマンドコントロール型の管理手順になってしまっています。結果的にモラルが欠落し、ベロシティもガタ落ちになり、プロジェクトではスクラムの導入が中止になり、さらに混迷の度を深めていきます。

このように、新しい手法を導入することは、複合的な課題を孕んでいる。重要なのは、より大きな全体像と、実現しなければいけないメリットに焦点を当てることだ。これは、持続的な学習と順応能力を文化として組織に根付かせることでしか為し得ることはできないだろう。

 

原文はこちらです:http://www.infoq.com/news/2008/12/scrum-adoption-challenges

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。