InfoQ

InfoQ

News

マイブックマーク

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

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

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

Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法

作者 Jacky Li , 翻訳者 近藤 修平 - (株)永和システムマネジメント 投稿日 2008年11月10日

セクション
プロセス/プラクティス,
設計/アーキテクチャ
トピック
Agile ,
Agileの採用 ,
トレーニング/認証
タグ
Scrum ,
批判

InfoQチャイナのJacky Li氏は、ThoughtWorks社のAgileChinaカンファレンス中にMartin Fowler氏と会談した。このインタビューは、Martin Fowler氏がスクラムの認定試験と、アジャイルの未来について語ってくれたものだ。

InfoQチャイナ (InfoQ): 数週間前に、中国においてスクラムはどのようにして採用されているのか(参考記事・英語)、という調査記事をInfoQで出しました。この記事の調査結果から言えるのは、自分の組織でスクラムを導入しようとしたことの大部分の人は、アジャイルの意味についてちゃんと考えたことがないということです。こういった人達はたんにトレーニングに飛びついてみて、認定スクラムマスターになることができたので、スクラムを導入し始めたというだけなのです。そんな有様ですから、スクラムの導入は失敗してしまいます。こういったことは何も中国だけで起きているわけではなく、他の多くの国でも全く同じような状況のようです。スクラムとXPに関係するYahooグループの数多くの議論を読んでもいても同じ結論に達しました。私が知りたいのは、このことをどう考えているのか、それから、我々がどう改善していくべきか、です。


Martin Fowler氏 (MF):  うーん。どのようなテクニックを用いようと、その問題を解決するのは容易ではないと思います。アジャイルで特に難しいところは、物事の考え方を大幅に変えていくことを要求されるというところだからです。もしここにいるのがRichard Durnall氏だったなら、彼はリーン生産方式でも同じような経験をしているということを話すと思います。つまり、多くの人達は、理念という垣根を越えてまで習慣を大切にしているということなのです。理念ではなく、習慣を身につけようとしている場合、必ずしもよい方向に進むとは限りません。

個人的にはアジャイルが影響力を持つまでにはまだ数十年の時間が必要なのではないかと考えています。オブジェクト指向と比較してみると、我々が使っているオブジェクト指向の技術は、60年代後半から70年代にかけて生まれたものです。それが、90年代になってようやくJavaやC++やC#のようなオブジェクト指向言語としてメインストリームになりましたが、そこまでなるには20年もの歳月を必要としています。それでも、クライアントのところに行って、彼らが書いたコードを見ると、オブジェクト指向になってないこともあります。Javaで書かれているのに!それでもオブジェクト指向じゃないんですよ!ですから、多くの人が本当のオブジェクト指向にそったコードを書いている、という時代になるまでにはまだまだ時間がかかるのではないでしょうか。

なんの話しでしたっけ?オブジェクト指向にかかった40年じゃないですよね...オブジェクト指向の領域というのは、アジャイルよりもはるかに限定的です。というのも、オブジェクト指向というのはプログラミングの技術であったりプログラム設計の話ですから。アジャイルの場合、ソフトウェアを開発するプロセス全体の話になります。ですから、アジャイルについてはオブジェクト指向よりももっと時間がかかると考えるべきでしょう。

スクラムの認定トレーニングコースは、基本的にたった2日間のトレーニングですから、スクラムについて学ぶことができるのはその2日間のコースの間だけなんです。しかし、私が気に入らないのはそれを「認定」と呼んでしまうことで、あやまった印象を与えてしまうことです。そうはいっても、一つの進歩ではあります。実際にスクラムを理解している人と2日間を過ごすことができるわけですから。どういうことが言いたいかというと、私が知る限り、実際に認定スクラムの講師をするのは、ちゃんとスクラムを理解している人がやっています。これは大きな利点です。なぜならば、教える立場の人達がちゃんと理解していない技術などいくらでもあるのです。むしろ一般的にはそういうものではないでしょうか。どういうことを言いたいかというと...そうですね...こういった問題は、ラショナル統一プロセスやCMMが抱える大きな問題の一つになっています。インストラクターが自分が教える内容をきちんと把握していないかもしれないという可能性があるのです。一方、最近の認定スクラムマスタのコースでは、私の知りうる限り、ちゃんとスクラムに精通している講師達ばかりです。むしろ問題は、2日間で全てを教え、説明することは不可能だということです。私は、どうアジャイルを実践していくかを学ぶには、数ヶ月はかかるものと考えています。ちゃんとチームを組むべきだし、そこでアジャイル手法を実践すべきだし、すべての事柄をどうやってうまく噛み合わせていくのかを理解するところから始めるべきなのです。そうなると幾月もかかるトレーニングになります。


InfoQ: アジャイルについてはまだまだ多く誤用が見られます、例えば「アジャイルはドキュメントをつくらない」、「アジャイルは急いでやるということだ」や「アジャイルでやるなら、すべてのプラクティスを実行しなければならない」といったものです。こういった誤用を防ぐために私たちができることはなんでしょうか?


MF: それは容易な道のりではありません。とても長い長い道のりですから、何度も例を示して、説明し続けていく必要があります。アジャイル界隈には、そこから外の世界に出て、アジャイルを語り、どうやったらうまくいくか伝えようと、とても活発に活動する人がたくさんいます。なかでもThoughtWork社は良い前例になろうとしています。私たちは実際にプロジェクトを動かしながら、それをアジャイルな手法で運営しているので、新しいメンバーが参加すれば、このやり方を見て、どう真似ようか想像する必要もなく、包括的に経験することができるようになっています。これはとても良い効果があります。

一方で、「あと数十年かかる」と言ったように、私は気長に構えています。まぁ、オブジェクト指向の時だってそうでしたから。いや、オブジェクト指向を正しく広める活動もまだ終わってないですね...これも長期的なの活動の1つです。


InfoQ: アジャイルの中に標準と呼べるものはあると思いますか?


MF:そういったものがあると思えません。そもそも私たちがやろうとしていた方法は、何が強みであり、何が弱いのか、そして何を伸ばしていくべきなのか、といったことを組織が理解するのを手助けする為に使うというものです。実際、CMMの本来の概念は、改善していく方法を学ぶ助けにするための評価活動でした。それは認定メカニズムのなかでねじれてしまったのです。

そして残念なことに、アジャイルでも同様のことが起きるリスクがあるのは明白です。ひょっとするとすでに多くの人達が、認定スクラムマスタについてもそう いったものに感づいているのではないでしょうか。私たちができることは、もがきながらも挑戦し、何が起きるのかを実証し続けていくことなのだと思います。

InfoQ: アジャイルマニフェストが宣言されてから7年が過ぎましたが、経験から習慣を導いているように、この期間に得た経験をパタンへと昇華させることができると思いますか?


MF: できますとも! そういったことを考えながら働いている人は確かにたくさんいます。しかし、それは私が語りたいと思っていたこととは違います。アジャイルが初期の頃はそういう立場にいましたが、かなり前にそうすることに決めたのです。アジャイルについて語り、アジャイルを広め、そしてアジャイルに多くを捧げる人はたくさんいます。私はそういったこととは距離を置くことにしています。それが重要ではないと考えているわけではないです。とても重要だとは思っていますが、それを続けている人はすでにたくさんいるのですから。私は競合の無い世界が好きです。私一人だけなら、それは簡単なことです。私がエンタープライズ・アーキテクチャのパターンとDSLに夢中になったのはそういった理由があったのです。


InfoQ: では、今後の行く末を見守っているだけということですか?


MF: うーん。そうですね。アジャイルな動きの中には、それはThoughtWorks社の中にも外にもですが、とても素晴らしい人達がたくさんいます。ですから、それほど私の助けは必要ないでしょうし、それは良いことだと思います。私にとっては、ですが。思うに、私が興味のある分野については、他の人達は興味がないと思います。


InfoQ:「プロジェクトがアジャイルであるかどうかは、どうやって判断したらよいの?」とよく聞かれます。ですが、その質問はあまり意味がないと考えています。私たちが知るべきなのはどうやって改善していくか、だけの筈です。


MF: その通り!


InfoQ: アジャイルかそうでないかをチェックするべきではありませんよね。


MF: 全くです。

 

原文はこちらです:http://www.infoq.com/news/2008/09/fowler-scrum-interview

特集コンテンツ一覧

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 のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。