Deep Agile People で考えていたこと

一週間ちょい経過したので、Agile Japan 2012 で参加させていただいた Deep Agile People について、何を考えて話していたかを、ちょっとメモを残しておこうと思います。

細谷さん、森崎さんに、企画からコメントからいろいろと助けて頂きました。あれがなかったら、単なる酔っ払いトークだった気がするので、大変ありがたかったです。DevLove HangerFlight のときのビデオを提供頂いた富田さん、あのオープニングを編集頂いた(あ)さん、ありがとうございました。

あの場に参加頂いた皆さんに感謝します。ぜひ今度は本当にビール入りでやりましょう。

• 方法論者ではなく実践者でありたい

Scrum や XP などの方法を、枠組みとして定義する人々はものすごい苦労をしてまとめています。いろいろな状況に対応できるように、改善や推敲を重ね、ようやくできるようなひとかたまりのやり方のかたまりになります。すばらしいと思います。

ただ、その方法論を実際に使おうとする場合は、方法論者のまねをしてもうまくいきません。

自身で気をつけているのは、自分でその方法論の弱点を説明できない、もっと単刀直入に言ってしまえば、自分でその方法論を dis れないうちは、その方法論は使わない、ということです。もちろん、その弱点は方法論を適用する状況、現場によりますから、その弱点を現場と切り離して議論することはやりません。簡単に空中戦になっちゃいますからね。

方法論やプロセスをあらたに導入しようとする場合は、もしそれがなかったら何が起こるか？どうやったらこの方法論の利益を破壊できるか？を考えるとよいと思っています。もちろん個々のプラクティスでも。

• 書いていないことには意味がある

Scrum や XP みたいな方法やフレームワークもそうですし、DDD の方法自体や、それで書かれたドメインモデルにもいえることなのですが、そこに書いていないことは、重要な意味があります。

Scrum には技術プラクティスは書いてありませんが、技術を軽視しているわけではありません。Scrum の場合は、元々 SmallTalk の技術方法論が含まれていたのですが、あるとき技術プラクティスは除去するという判断がなされて、今の形になっています。XP にも、もっとマネジメントのプラクティスが含まれていたはずです。ドメインモデルには、ドメインモデルをつかってなにかをよりよくしたいと考えているモデラーの視点は含まれることはありません。

そこに書いていないことは、作成者が利用者を信頼して、自分で考えて欲しいということを願った場所です。その成果をよりよく使ってもらうために。批判があっても、あえて除いたところ。そこで自分で考えることを外してしまったら、どんな方法論もモデルもうまく使えないでしょう。

 利用者を信頼せず、考えてもらいもしなかった方法論がどうなったか、ここで批判するのはやめておきます。

どうもありがとうございました。何かの役立てていただけたら良いのですが。コメント、ご意見、ご批判はいつでもどうぞ。お待ちしております。

さて、続きはいつやろう？＞川端さん、牛尾さん