Agile Japan 2009
2009年4月22日、東京千代田区にある放送会館で「アジャイルジャパン2009」が開催されました。本イベントは「ソフトウェア開発の次世代リーダーをつくる」ことを合い言葉に、200人以上の参加者を集めてスタートしました。
News
Brain Marick氏「アジャイルマニフェストに足りないもの」
作者 Chris Sims , 翻訳者 近藤 修平 - (株)永和システムマネジメント 投稿日 2008年12月11日 午前12時10分
Brain Marick氏(リンク)は、Agile Development Practices(リンク)カンファレンスの基調講演の中で、アジャイルマニフェスト(リンク)に足りていない価値について説明した。氏によれば、アジャイルマニフェストは本来マーケティング用の文章であって、アジャイルが日の目を見るように、ビジネスとして成立させるという目的があったと言う。この目的がおおよそ達成されている今、アジャイルマニフェストが約束するような成果をチームが達成する助けとして、指針となる一連の価値を拡張しておく必要があるとしている。
価値というのは、誘惑に直面する中で、至極まっとうな道を歩ませてくれるものです。アジャイルの価値を着実に自分のものにしてきたチームは、よいアジャイルプラクティスを拠り所にしています。この場合はよいアジャイルになりますが、指針となる価値を持たないチームは、ずるずると脱線していってしまいます。
Brian氏が基調講演で述べてる考えは、彼が2007年にトロントで行われたXP Dayで語り、後に文章にしたテーマを(リンク)進化させた最新のものである。当時、彼は必要と考えていた次の4つの新しい価値を紹介した。
スキル
スキルのある開発者とテスタは替えが効かない。スキルはソフトウェア開発の技術を学び、実践することでしか習得することはできない。
規律
アジャイルをやってみると、意外と多くの規律を必要としていることがわかる。すぐにコードをリファクタしなくなったり、テスト書くのをサボってしまっていないだろうか。一見、サボったほうが簡単だし、早くできるように思えるが、長い目で見れば生産性が落ちる結果にしかならない。常にこう心構えをもって行動するためには、規律が必要だ。
容易さ
頻繁に行うことは、たやすくできるようにしておくべきだ。Brian氏は、このことが居心地のよさという概念とどういう関係にあるかを説明している。住まいはその住人達によって、より便利に、より快適な生活が送れるように改造されていく。コードや作業環境も全く同様に、私たちが「暮らし」やすくなるように修正されるべきだ。
楽しさ
生き生きとした社員は生産性の高い社員だと断言できます。楽しさがないプロジェクトでは、炭坑でカナリアが卒倒してしまうのと同じようになるでしょう。そこには何か大きな問題の兆候があるのですから、そこに注意を払うべきです。おそらくこれは正しいと思います。当然私はそう信じてきました。ただ、私は基本的にはそれほど気にしているわけではありません。楽しさというのは、それ自身が理由になっていると思います。仕事を楽しむのは当然のことです。もっというと、私たちの周りにいる人達も言い訳なんてせずに純粋に仕事を楽しめばいいのです。
当時、Brian氏はこれらの4つの価値が欠落したらアジャイルがどうなってしまうのか危惧していた。
私が思うにアジャイルは今は苦悩しています。原因はここに挙げた根本的な価値がきちんとした形で書き留められていないこと、そしていとも簡単に忘れ去られてしまうところにあります。アジャイルが大きな企業で採用され、大胆さを失ってゆくに従って、文書化されていない価値は骨抜きにされてしまうでしょう。それが続けば、残念ながら、アジャイルは10年限定の流行として、結局何も変わらずに終わってしまうでしょう。そうだとしたらとても哀しい。
James Shore氏(リンク)は最近、アジャイルの動向について似たような懸念を表明した(参考記事)。チームが中途半端なアジャイルを実践することでアジャイルの衰退していく、というものだ。
つい最近、Brian氏はいくつかの新しい価値をリストに追加した。そこには、勇気、受動的になる、素早いフィードバック、可視化(目立つようにする)というものがある。
勇気
勇気とはチームやプロジェクト、そしてビジネスにとって一番ためになることをやろうとするときに、そうさせまいとする抵抗にに負けすにやり通すことだ。Brian氏は、Ken Schwaber氏から聞いた例として、パーティションを取り払ったスクラムマスタを例に挙げた。そうすることで必要とされていたチームのスペースを確保することができたのである。「設備監査員」と対決した際に、彼女は、パーティションを元に戻すなら退職するとまで言い切った。
受動的になる
Brian氏は「受動的」という言葉には悪い印象がつきまとうものだが、アジャイルチームにおいてそれは全く問題にならないし、むしろアジャイルチームのメンバーであれば、問題の無い範囲でそのようにすべきだと考えてる。コーディングをする時には、コードを少し書いてみて、そのコードが思った通りに動くかどうかを判断し受動的に対応した方がうまくいくことが時としてある。決断をする際にも、可能な限り決断を遅らせることで、受動的なやり方で行うことができる。
素早いフィードバック
インフラを最初に構築するようなやり方ではなくて、機能を積み重ねて作ってゆくようなやり方で開発することが、素早くフィードバックを得られる一つの方法である。ビジネスではインフラそのものにフィードバックを反映させられることは滅多にない（おや、すてきなデータベース設計ですね!）、だが、稼働している機能については、簡単に実用的なフィードバックを返すことができる。同じような素早いフィードバックの他の事例としては、テスト駆動設計というものがある。
可視化
できるだけ多くの情報を可視化することは、アジャイル実践者達のあいだで長くベストプラクティスだと考えられてきている。それは「可視化のための大きなチャート」とか「情報発信器」を使う動機になっている。誰もが情報発信しつづけるのに便利であるだけではなく、問題を素早く表面化させ、自然と対処できるようになる効果がある。
悪い習慣も十分に可視化してください。可視化することを常に働きかけることで、悪習をやめるように仕向けることができます。時が過ぎ、代わりに身につけたものはよい習慣となるでしょう。そしてさらに時が過ぎ、これらの変化は偉大なチームメンバーと偉大なチームを育むようになります。それこそ全く機能とよべないものから始めて、心から誇りを持てるようになるまでプロダクトを円滑に育てるのです。
Brian氏の基調講演の内容はこちらから参照できる(リンク)。
あなたのチームはこういった価値を採用するだろうか？それともしないだろうか？Brian氏のリストは完成されたものだろうか、それとも他にアジャイルチームが考慮しなければならない指針となる価値はあるだろうか？コメントを残してあなたの考えを聞かせて欲しい。
原文はこちらです：http://www.infoq.com/news/2008/11/Marick-on-Agile-Manifesto
No comments
スレッド表示 返信