読者です 読者をやめる 読者になる 読者になる

亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

アジャイルサムライ読書会第二回:ウォーターフォール脳の恐怖

勉強会 Agile

アジャイルサムライ読書会第二回やってきましたよ。
11月18日 アジャイルサムライ読書会in京都 第二回

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

前回から +2、-2で適度に新規メンバーが入りつつも大体同じ規模で開催できました。まずは参加者の方々に感謝感謝。

さて、サブタイトルのウォーターフォール脳の恐怖ですが、まあ聞いてくだされ。
それは第6章「ユーザーストーリーを集める」を読んでいたときのことでした。。。

第6章の最初で、文書化して何もかも書き出すことの難しさと非効率が述べられています。即ち、

要求を文書として集めようとすることの問題点は、用意する文書量の多寡じゃない。これはコミュニケーションの問題なんだ。まず、文書とは会話できない。(中略)それから、他の誰かが書いた文書は誤解を招きやすい。
アジャイルサムライ pp.103)

ということ。


うんうん、そうだよね、と読み進めてユーザーストーリーの話に入ったのだけれども。
そのとき、なんとなく思ってしまったのです。
「あれ?これで何を解決するんだっけ??」


ユーザーストーリーは、

顧客がソフトウェアで実現したいと思っているフィーチャを簡潔に記述したもの

である。インデックスカードなんかに簡単なユーザー視点の書いておく。そりゃあもうざっくりしたものを。
ん?ざっくり??と、そこで思考がよくわかんなくなって、みんなに問いかけます。


「ユーザーストーリーって何するんですっけ?曖昧で分かりにくい文書、という問題を解決するのに、こんなざっくりした記述が効果的になるのってなんか繋がらなくなっちゃったんですが」

みんなもふと考え、何人かの人が同意し、ユーザーストーリってなんだっけ??と謎な思考の迷路に入っていきました。あれれれ。だってこれをベースにScrumじゃ見積もりするんでしょ?あれれ?

そんなとき、一人の人が呟きます。
「いや、つまりこれは、最初に詳細化することを戒めてるだけですよ。最初はざっくりしたリストを書きだすようにしなさいよ、と」
「あれ?じゃあ、どこで細かく見積もるの?」
「そんなんイテレーションの頭に決まってるじゃないですか(笑)」
「!!・・・そう・・・ですよね・・・」



・・・((( ;゜Д゜)))ガクガクブルブル



完全にその瞬間、どこかで仕様書を爆発的に書いてフィックスしてその通りに見積もって作るという、ウォーターフォール脳に陥っていました。しかも自分だけじゃなくて、そこそこ多くの人々が。ですよ。「アジャイルサムライ読書会」なんていうのに仕事がんばって早く終わらせて平日夜から集まって出席率100%でその後飲みに行くような人々が、ですよ。
マジその瞬間背筋が凍りました。そりゃあアジャイルできねーわ、根っこのところに染み付いてしまってるんだ、そういう「作るべきもの」がきっちりできていないと不安だ、という心が。


多分そこが、簡単にアジャイルできない要因。アジャイルにやるってのは変化を恐れないこと、常に改善すること、決まったプロセスなんてないということを受け入れる、そういう勇気を持つことなんですよねえ。
その場では大笑いしたもんですが、なかなかどうして、これってアジャイルする上での本質的な原因であり、刺身タンポポしてしまう最大の要因なんだろうなあ。

本気で、こいつを読まないといけない気がするな。とBlogの隅っこで勉強会をゆるぼしておこう。

Fearless Change: Patterns for Introducing New Ideas

Fearless Change: Patterns for Introducing New Ideas