GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
News
ブックマークされました！
ブックマークがエラーになりました。もう一度お願いします。
主流としてのアジャイル
作者 Dan Mezick , 翻訳者 吉田 英人 投稿日 2010年4月6日
アジャイル開発が主流(メインストリーム)となる時代がいよいよやってきたようだ。大手コンサルティング会社が "アジリティ(Agility)" を喧伝し，IBM Global Business Services や Cap Gemini といった会社がアジャイル関連サービスの提供を始めた。Cognizant や ITC Infotech といったオフショア企業も，アジャイルのソフトウェアやサービスの分野で活発に行動している。
主流化の傾向
オンライン求人サイトをざっと見渡せば，業務説明の欄に 'アジャイル' ということばが増えているのに気付く。次の表は求人サイトの Dice.com と Monster.com を例に，およそ１年間の変化を示したものだ。
| 仕事リストに含まれる用語 | Dice, 2009年7月 | Dice, 2010年4月 | 増加率 |
| Agile | 2084 | 4088 | 96% |
| Scrum | 755 | 1222 | 61% |
| 仕事リストに含まれる用語 | Monster, 2009年7月 | Monster, 2010年4月 | 増加率 |
| Agile | 1756 | 3031 | 72% |
| Scrum | 379 | 755 | 99% |
このように突然注目を集め始めたことは，アジャイルにとってどのような意味を持つのだろうか？ "メインストリーム" なアジャイルとはどのようなもので，そこには何があるのだろう？ アジャイルで最も人気の高いフレームワークは Scrum であり，アジャイルの主流化について議論するには相応しいテーマだ。そこで，主流としての Scrum について考えてみよう。
ThoughtWorks の Martin Fowler 氏によると今，Flaccid Scrum (軟弱 Scrum) が大流行しているそうだ。次に示す３ステップがそのパターンだという。
- アジャイルの導入を希望して，Scrum を選択する。
- Scrum のプラクティスを採用する。さらには原則をも採用する。
- しばらく継続するものの，コードが混乱して思わしい成果が得られない。
Fowler 氏によれば，
... プロジェクトをトラブルに陥れるのは，いつでも内部的な品質の低さです。トラブル例が Scrum を掲げたプロジェクトに数多く見られるという事実も，Scrum 自体に何らかの要因があるというより，実は Scrum の普及に理由があるのかも知れません。
話が面白くなってくるのはここからだ。Fowler 氏は続ける。
いつも指摘していることですが，成功と失敗を分けるのは方法論ではありません。チームこそが成否を決めるのです。プロセスを導入することの効果はあるかも知れません。しかし最終的に重要なのは，そして結果に対して責任を負うのはチームなのです。数多くのだめな Scrum プロジェクトが Scrum の評価だけでなく，より広範なアジャイルの評価をも損ねているのは確実です。
主流化の意味
これがアジャイルの "主流化" にどのような意味を持つのだろう？ すなわち 'Scrum' の採用を自称する組織が行っている，実際には Scrum とは違うことを彼らが Scrum と呼んでいるように，Scrum という言葉が徐々に意味をなさなくなってきたのだ。Jeff Sutherland，ken Schwaber 両氏はそれを称して，Scrum-butt (クソScrum) と言っている。
ある面では適確とも思えるこの定義について，しかし Fowler 氏はもう少し "穏当な" 呼び名を与えている。Semantic Diffusion (意味的拡散) というものだ。
Semantic Diffusion とは，個人やグループによって優れた定義を与えられた造語が，広くコミュニティに伝わる中で，その意味が不明確になっていくような場合に発生するものです。この過程ですべての定義が失われてしまうと，もはや用語としての意味をなさなくなります。
このような動向に対して Scrum の創案者である Ken Schwaber，Jedd Sutherland の両氏は，Scrum の明確かつ正式な定義書である Scrum Guide を作成した。無償でダウンロード可能なこのリソースは Scrum の詳細資料であり，その定義の強化と維持を目的とするものだ。Ken Schwaber 氏の説明では，
Scrum は 1990 年代から複雑な製品開発に使用されてきました。この資料は Scrum を用いた製品開発手法について説明したものです。
Ken Schwaber 氏の "Confusion about Scrum (Scrum に関する混乱)" に対して書かれた Dominique Stender 氏のブログポスト には，Scrum の定義についての優れた考察が示されている。Stender 氏はここで Martin Fowler 氏の Semantic Diffusion の見解を支持して，次のように書いている。
Scrum に対する唯一(!)の公式定義が必要である，という Ken の意見に同意します。[Ken の] 指摘どおり，Scrum はその適用において，かんばんや XP など他のアジャイルアプローチと混同されています。ですから，何が Scrum であって何がそうでないか，という唯一(!)の "マスターコピー" の存在が重要になってきます。ベンチマークが必要なのです。
主流としてのアジャイル: プロダクトとプロダクトオーナの立場から
アジャイルが "メインストリーム" になるということは，Scrum がこれまでになく２極化する，ということを意味するのかも知れない。アジャイルが広範に普及していく一方で，Ken Schwaber と Jeff Sutherland の両氏は Scrum の定義を事実上固定化しようとしている。一体何が起きているのだろう？
次のような問題がある：現在の Scrum Guide では，プロダクトオーナは "常にひとりの人であって，委員会(複数人のグループ)である場合が考慮されていない"。Scrum の実行に関するこの問題については，ブログ上で強気の発言をする者もいる。例えば InformIT の Roman Puchler 氏は，プロダクトオーナの問題に関する記事 で次のように書いている。
プロダクトオーナ委員会とは，プロダクト全体に責任を持つ者のいないプロダクトオーナのグループです。グループをリードしたり，共通のゴールを設定したり，意思決定を促したりする者が誰もいないのです。プロダクトオーナ委員会は，利害と権力の衝突によって終わりのない会議に陥る危険性をはらんでいます - それは "コミッティ死" とでも呼べるものです。現実的な進展は何も得られず，全員が共同作業を止めて争い始めるのです。
プロダクトにはひとりの責任者が必要です。それは統括プロダクトオーナ，あるいはチーフプロダクトオーナとでも呼べる人物で，他のプロダクトオーナ達をリードし，意思決定を促進し，プロダクトバックログの優先度設定とリリース計画を行います。
"アジャイルの主流化" には，きわめて明確な用語定義が必要なようだ。'Scrum' という名称については，その創案者の著した Scrum Guide によって明確に定義されている。アジャイルの本格的な普及が始まり，その意味が拡散されていく (Semantic Diffusion) 中で，"アジャイル" ということば本来の意味がその重要度を増しつつある。
No comments
スレッド表示 返信