オルタナティブ・ブログ > An Agile Way >

アジャイルに行こう!

End of Methodology (日本語訳)

»

アリスターコーバーンの新着記事『方法論の終焉』(End of methodology)の翻訳です。この翻訳は、twitterを使って数名で短時間で人力翻訳する、という実験プロジェクトでやってみました(末尾にその話)。

元記事は、こちら。http://alistair.cockburn.us/The+end+of+methodology

アジャイル開発が「方法論」といった体裁からどんどんはなれ、「自分たちで自分たちやリ方を(Reflective=ふりかえり)どんどんよくしていく(Improvement=改善)そんな枠組み(Framework)」になっていったことに、一つの名前を与えようとしている。そんな話です。この名前自体(当然その日本語も)まだ良いものではなく、新しい名前がこれにつくことの前兆となる記事だと思っています。


方法論の終焉(End of Methodology)  by Alistair Cockburn

別名 ふりかえり改善フレームワーク(Reflective Improvement Framework)
別名 ふりかえり改善フレームワークの勃興。(The Rise of Reflective Improvement Framework)

われわれは、ようやく成熟した。現在われわれが作っているのは、ふりかえり改善フレームワーク(Reflective Improvement Framework)とも呼ぶべきものであり、方法論(methodology - 今も習慣上こう呼ぶことが多い)ではない。Crystal, Scrum, 大文字KのKanbanがその例で、これらは少数のルールからなる。少数とは、プロジェクトを運営するのには不十分なくらい、でも、単なる観察と調整(inspect&adapt)を繰り返すよりも、現場の人々が状況を改善するには十分なものだ。旧式の「方法論」、つまり ”Big-M のMethodology” は現在ではもう過ぎ去り日のものになった。それはよいことだといえるだろう。


この記事は、平鍋健児がリード&オーケストレイトする、Astah マインドマップツールを使った興味深いクラウド翻訳(crowd-sourced)によって日本語に訳された。私は日本語が読めないが、面白いマインドマップの使い方が気に入った。ありがとう、ケンジ。


「Agile Roots 2010」カンファレンスにおいて、私は 「新しい方法論は方法論ではない」と題した発表を行った(この発表のビデオも見てほしい:「Agile Roots 2010」Alistairによる基調講演のビデオへのリンク)。

わたしの講演の趣旨は、われわれは、単に習慣として、1980~1990年代前半にかけて作ってきたものを「方法論」と呼んでいるということである。われわれは業界として若干成熟し、1995あたりに作られたものは、古い世界観と現実の世界観を埋めることができなくなってしまった。

Scrumや私のCrystalシリーズ、あるいは最近 David Anderson の提唱している大文字Kの「Kanban」(トヨタのかんばんと混同しないでほしい。確かに一緒にしたくなるし、まぎらわしいけれど)は、方法論というにはあまりに構造に欠けている。そもそもプロセスではなく、「ふりかえり改善フレームワーク」(Reflective Improvement Framework)というか、あるいは似たような、まだ名前のないものである。とにかく、「方法論」という言葉の定義にはどう考えてもあてはまらないのだ。

以下は2つのステップで説明する。

  • これらはプロセスでも方法論でもない。
  • それでもわれわれには方法論やプロセスが必要である。

*1* これらはプロセスでも方法論でもない

プロセスとか方法論は、役割、手順、繋がりについて記述したものである。CSM後のScrumはほぼこれである。プロダクトオーナー、スクラムマスター、スプリント、スプリントミーティングなど。しかし、それでもこれでは本当に (a) ゆるすぎるし、(b) 本当のScrumにちょっと味付けしただけのものだ。本当のScrum(ここにTMマークを想像して欲しい) は以下のようにシンプルだ:

  • スキルが十分ある人たちで多能工の集団をつくる。
  • その人たちにデモをしてもらったり、頻繁にリリースしてもらったりする。ただし、こまかく管理するのはやめる。
  • チームには日ごと月ごとに「観察と調整」(inspect&adapt)させる。
  • 誰か一人に自由な時間を与え、 阻害要因を取り除いたり、チームの質を観察したりしてもらう。
  • ビジネス側には代表者1人を通じて話すようにしてもらう。

これはプロセスではない。これは【ナントカ】だ。チームが仕事をこな し、上手になっていくことができるような、ひとまとまりの説明である。

CrystalはScrumより簡素だが、Scrum以上でもある。 Crystalでは:

  • すべてのプロジェクトには固有の、自家のプロセスないし方法論が必要だ。
  • 人々がうまく協調して仕事するためのルール、理論、法則をわれわれは学んできたのだから、活かさなくてはならない。
  • 成功するチームには7つの特徴があり、活かすべきだ。頻繁にリリースする、頻繁にふりかえる、コミュニティとコミュニケーションの品質を重視する、すべて のレベルですべての方向性についてフィードバックを得る。

これがScrumより簡素だというのは、Scrumにあるプロセスに関する要素を必要としないからだ。スクラム以上だというのは、チーム設計に必要な性質か「法則」、あるいは理論と呼ぶべきものを実際に7つ挙げているからだ。

大文字KのKanbanは、ScrumとCrystalの中間あたりに位置する。これは何らプロセス的な要素を定めていない。しかし、組織横断的なキューの共有という考え方や、仕掛中(WIP)という状態への厳しい制限を課すという考え方を導入し、その制限を破ったり頓挫した場合に何が起こるかを俎上に載せている。つまり、時間経過によるものではなく、状態に基づくふりかえりの契機が設けられているのだと言える。

これら3者は実に素晴らしい…そして、それらは方法論でも無ければプロセスでもない。私たちはそれらの適切な呼び名を持っていないのだ。そこで、私は、これらを、当面ここではこう呼ぶことを提案したい。

ふりかえり改善フレームワーク
(Reflective Improvement Frameworks)

*2* それでもわれわらにはプロセスや方法論が必要だ。

ふりかえり改善フレームワークは素晴らしい。ただ、フレームワークはチームに仕事のやり方を教えてくれない。チームは仕事やり方を必要としている。

以前の「プロセスは何に役に立つ」(What is a process good for ?)というブログの記事で、プロセスは以下の役に立つことを発見した。

  • コミュニケーションを減らしても働ける方法
  • 忘れていることがないかを確かめるチェックリスト

どちらも重要だ。

方法論(プロセスの部分を含むが、プロセス部分だけではない)は、「役割」(roles)と「割り当て」(assignments)、そして割り振りや部門をまたいだ人々の「相互作用の接点」(points of interactions)を定義するのに役立つ。

おわかりのように、自分たちのためのプロセスや方法論は必要だし、これからも必要とされ続けるだろう。(それらを効率よくつかむ方法を、「よりシンプルに方法論を記述する」に書いた)

この短いブログエントリで私が提示したかったのは、次のようなことだ。これまでに、列挙された役割や仕事の割り当て、用いるテクニック、そして相互作用の接点などが、分厚い教則として書かれてきた。それは多くの組織やプロジェクト、国、文化をまたいで、一様に使われることを想定していた。我々が「プロセス」あるいは「方法論」という言葉でこの30年以上考えてきたのはこうしたことだったが、それは今や終焉を迎えたのである。

依然として、それを期待する人達もいるだろうし、それ/それらを求める人達がいるだろうことも想像に難くない。しかし、我々はそれらの人達を満足させることはできない。 なぜなら、我々ソフトウェア産業界に身をおくものの多くが、プロセスや方法論といったものが、ひどく部分最適なものであるということを悟り、 それらを生み出すことをどんどん拒否し始めているからだ。そんなものを生み出す者たちに災いあれ。そんなものにお金を払ってうまく行くと期待する者たちに災いあれ。

(で、面白半分だが、私は大規模な顧客のために、守レベルのドキュメントを準備する契約にサイン*しかけている*。そのドキュメントは、 ンケ国にわたる、ン百の会社の、ン千人の開発者を、よーいドンでアジャイルへ移行させるためのものだ。これは大変なことではなかろうか?私は本気でこれをやり遂げたいと思っている。なぜなら、これが私の能力を限界まで伸ばしてくれるだろうから。契約があれば十分だとは決して思わないし、私の思い通りにさせてくれるとも、皆が私の書いたとおりにするなんて思ってはいない :)けれども、 これは最高の思考実験だ。)

(※5/31修正、「よりシンプルに方法論を記述する」に関する記述を追加。日本語訳への言及を追加)


ここで、プロセスや方法論がいまでも必要といっている意味は、「自分たちのためのプロセスや方法論は必要」ということ。経典のようなすべて開発をカバーする厚いプロセスや方法論は、葬られた、というのが論旨になっています。

この記事は、twtter で5/28(火) 7:03 に、ぼくからの呼びかけで #EoM_ja ハッシュタグでカジュアルに始まったリレー翻訳をブログにまとめたものです。みなさんのツイートを、平鍋のほうで若干、全体統一の面から修正、補足、削除をいれて、上記に仕上げました。

参加してくれたみなさん、ありがとうございました。

@hiranabe Kenji Hiranabe
twitterを使った実験:アリスターコーバーンの新着記事『方法論の終焉』をリレー翻訳しようと思います。twitter+togetter で速攻やってみよう。#EoM_ja で参加表明ください。そのタグのTLをトークンとして、 取った時刻順に、はじめちゃってください。
(5月26日 Twitter for iPhoneから)
@digitalsoul0124 Yukei Wachi
#EoM_ja 和智やります。
(5月26日 Twitter for Macから)
@yattom YASUI Tsutomu
#EoM_ja やっとむやります
(5月26日 Tweenから)
@nen_jp GOTO, Shoichi
#EoM_ja 何それ面白そう。…なので、ちょっと参加させてください(1)。
(5月27日 webから)

@haradakiro HARADA Kiro
#EoM_ja ちょとやってみる(1)
(5月27日 YoruFukurouから)
@yolpika YOLPIKA
次のパラグラフやってみます。 #EoM_ja (6)
(5月28日 Keitai Webから)

そして、活動を応援してくれた、アリスター、ありがとう。

@TotherAlistair Alistair Cockburn
@hiranabe thanks for the lead(5月27日 webから)
@hiranabe that is fascinating and an interesting use of mind maps! I like it. thanks. http://bit.ly/kyXx3U (5月28日 webから)

このブログをまとめる前に、みなさんのツイートをMindClipでキュレーションしてた結果を、Dropastaで公開します。

みなさん、ありがとうございました。楽しかったですね。またやりましょう。

(上記、ブラウザによって、見えなければ、ここに、リンクをはっておきます。
http://p.astah.net/a/naxah4ck

Comment(0)