普段、イテレーションの終わり(ちなみに1週間)にKPTをやって問題点をだして、それを解決すべくTryを実践してはいる。けれど、短期的な解決で落ち着いてしまってしばらくすると似たような問題が発生する。 結局のところ、問題が発生したらその場の解決だけではなく、問題の原因を検証して、自分達の開発プロセスに再発防止の仕組みを組込まなければならないなと思った次第。

そんなことをFaceBookやTwitterに書き込んでいたら、諸先輩方(@kdmsnrさん、@nawotoさんありがとうございます)から「それがアジャイル」みたいなことを言われてしまった。確かに言われてみればそうだ。一定のプロセスにこだわらないからこそ、柔軟に問題・変化に合わせてプロセスを変えていけるのがアジャイルなんだよね。うーむ、勉強不足。

今までやってきたことを繰り返したところで結果は同じなのは当然。今までのやり方で「何かうまくいっていない」と思ったら、やり方を変える必要がある。その辺りの検証が今のチームには不足してるなぁ。

あとは開発の遅れやバグの発生などが開発チームの問題として捉えられがちだけど、結構開発プロセスが上手くまわってなかったり、プロジェクト関係者のコミニュケーションロスが原因で発生してるものもある。そういう意味でちゃんと開発メンバー外のプロジェクトに関わる人を全員まきこんでやっていかないといけないわけだけど現状出来てないなぁ。そろそろアジャイルごっこから抜けだすべき時期なのかもしれない。(アジャイルな見積りと計画づくりの訳者あとがき)

その辺もなぜコミニュケーションが上手くいっていないのか、なぜデモ直前のテストで問題が多発するのかとか、ちゃんと原因を調べてプロセスに組み込んでいかないといけないなぁ。

ちなみに僕が再発防止の仕組みをプロセスに組込まないなといけないなと思ったのはリーン開発の本質 ソフトウエア開発に活かす7つの原則がきっかけ。リーンが何かと言うのはまだまだちゃんと理解しきれていないけれど、現状を色々考えさせてくれるいい本でした。

献本して頂いたにも関わらず、書評が大部遅くなってしまいました。角谷さん、ごめんなさい。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
	安井 力 角谷 信太郎 毎日コミュニケーションズ 2009-01-29 売り上げランキング : 8925 おすすめ平均 「正直になること」がアジャイル成功の秘訣 ソフトウェアの見積りは本来こうでないか？ 自信を持って見積もりを出すための手引き書 Amazonで詳しく見る by G-Tools

さすがに全てのアジャイル本に目を通しているわけではないけれど、最近までに出版されているアジャイル本の中でも断トツの重要度な本だと思う。これを読まずしてアジャイルとか言っちゃダメだ。

まず、出版から3年が経過した現在、本書の原著は北英圏のアジャイルソフトウェア開発コミュニティで「必読の一冊」という評価を確立していることです。

すでに北英圏から3年遅れっていうところも衝撃だけど、それよりも日本に持ってきてくれてありがとう!という感謝の念が強い。安井さん、角谷さん、本当にありがとうございます。

この本は23章のケーススタディがよくできている。個人的にこう言ったケーススタディが好きなので、まず最初にここから読んだ。それだけで十分にこの本が素晴しいことがわかったし、冒頭から読み始めた時もケーススタディが具体例としてイメージできたので理解しやすかった。

ケーススタディもそうだが、この本は非常に例え話が豊富だ。この本を初めて読んだときは、ストーリーポイントをはじめ見知らぬ概念が多かった。それらの理解を助けるのに、例え話は非常に効果的だった。

このボリュームの内容をここで全部書くことは厳しそうだが、1つ思ったのは「正直」の重要さだった。正確な見積もりができないことを認める。顧客やプロダクトオーナー(もちろん他のメンバーも)に細かく報告する。これらは全て「正直」にならないといけない。この「アジャイルな見積りと計画づくり」も非常に正直な本だった。

先日、うちの会社でストーリーボイントとベロシティの説明とプランニングポーカーを数人で実施してみた。好評で、「じゃあどう導入していこうか」という話にはなりつつある。問題なのはうちは少人数で小さい案件を回すことが多いので、例えば仮に僕がメンター的な役割をしようにも、僕がAという案件をやっていて、ほかの人がCだったりBだったりすると中々面倒を見れない。そのあたりを今どう解消しようか考えている。

個人的に、この本は手元に置いておきたいのがだ、会社のメンバー全員にも読んで欲しいと思っている。できれば全員に買って欲しいのだが(本の売上げ的にも)、なかなかそうはいかなそうなので、献本してもらった本を会社に置いて、もう1冊新しいものを自分で買おうかと思っている。

あと、この本はアジャイル入門本ではないので、この本と一緒に「Head Firstソフトウェア開発」と「アート・オブ・アジャイルデベロップメント」も読んでおけばいいんじゃなかろうか。まぁ僕はまだどっちも読み途中ですけどね・・・

最後にもう一度言います。この本を読まずしてアジャイルとか言っちゃダメ!絶対!

Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本
	木下 哲也 (監訳) 有限会社 福龍興業 オライリージャパン 2009-01-22 売り上げランキング : 165325 Amazonで詳しく見る by G-Tools

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
	木下 史彦(監訳) 平鍋 健児(監訳) 笹井 崇司 オライリージャパン 2009-02-18 売り上げランキング : 28100 おすすめ平均 現時点で最良のアジャイル解説本 アジャイルなやり方の具体的なガイド アジャイルのための練習曲集 Amazonで詳しく見る by G-Tools

木下さんと角谷さんが監訳したアジャイル本。なんとか年内に読み終わった。このエントリーを書くのは2008年になってしまったけど。

アジャイルな開発者もそうでない開発者も

今までアジャイルな開発とは無縁だった人達も、既にアジャイルな開発手法を採用している人達、どちらの人達にも得るものがある本だと思う。前者の人達にはこれからの道標として、後者の人達には振り返りとして。ちなみに私は前者。

そもそも本書での「アジャイル」の定義は以下のようになっている。

開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行ない続けることである

つまり、開発手法がXPとかScrumである必要はないし、極端な話、組織とかすら関係なく開発者が自分1人だけでもアジャイルな開発は行なえる。なぜなら、未来の自分に対してフィードバックをすればいい話だから。アジャイルプラクティスにも1人で実践できるプラクティスがいくつか載っている。

悪魔の囁き、天使の助言

各プラクティスの構成は、悪魔の囁きに打ち勝つべく天使の助言を授かるという形ですすめられている。まさに表紙の通り悪魔 VS 天使の構図なわけだ。悪魔の囁きはちょっと表現がオーバーな気もするけど、そこが悪魔っぽいと言えば確かに悪魔っぽい。仮に悪魔の囁きにピンとこなかったとしても、天使の助言は聞いとくべきだし、なんなら悪魔の囁きを自分なりに変えてみるのもいいと思う。

まずは1つのプラクティスから

いくら天使の助言を聞いたところで、それを習慣にしなければ意味がない。アジャイルプラクティスには全部で45のプラクティスが掲載されているが、流石に一度に全部実践しようと思ってもまず無理だ。とりあえず自分にとって重要なプラクティスを1つ選んで、それが習慣づいたところで次のプラクティスに進むのがいいと思う。(プラクティスによっては複数同時に実践できるかもしれない)

この辺に関しては「第9章 終章：アジャイルへ踏み出す」を読んでもらえればいいと思う。アジャイルへ踏み出すと言うタイトルからもわかるように、この本を読んで終わりじゃいけない。むしろ読み終わってからが本番なのだろう。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
	Venkat Subramaniam Andy Hunt 木下 史彦 オーム社 2007-12-22 売り上げランキング : 16000 おすすめ平均 迷える開発者への最初の一歩となる本 Amazonで詳しく見る by G-Tools