「アジャイルプラクティス」はスゴ本

　marsさんが、「システム開発に関わる人はみんな読めー」と強力にオススメするにつられて読む。これはスゴ本。marsさん、良い本を教えていただき、ありがとうございます。

■　どんな本?

　本書は、開発現場で培われた「成果を出す習慣」を、45のプラクティスとして紹介している。開発速度を大幅に上げたり、高速納期を目指すような、「アジャイル開発プロセス」という決まったやり方は、存在しない。アジャイルな開発とは、現場でのさまざまな活動をアジャイルにしていく――つまり、変化に適応することを継続させていく―― 「習慣」だということに気づく。協調性+フィードバックによるプラクティスは、あまりにもあたりまえすぎて見過ごされがちかと。その反面、意識して実践するならばこれほど心強い金棒はないだろう。

■　忘れがちな基本中の基本「成果をあげるのが仕事」

　面白いのは、「悪魔の囁き」と「天使の導き」との間で揺れ動く「感情」に焦点をあてているところ。例えば「プラクティス1:成果をあげるのが仕事」ではこうだ――

悪魔の囁き : 問題解決の第一歩は、犯人を突き止めることだ。大馬鹿野郎を探し出せ！過失を明確にすれば、問題の再発を確実に阻止できるってもんだ

　「おまえのバグだゴルア!」が厳禁句なのは、それを言っても何もならないどころか、人間関係に大ダメージを与えてしまうところ。ミーティングが非難と防御の戦場になってしまうから。暗黒面に陥ることはたやすいし、何よりもラクだ。しかし、それで気分よく仕事ができるだろうか? 苦々しい気分で愚痴やあてこすりを応酬して、安心して仕事ができるだろうか?

天使の導き : 誰かの後ろ指をさすのではなく、自分のできる解決策に注力しなさい。大事なことは、意味のある成果をあげることです

この悪魔→天使の間のギャップを埋めるため、具体的にどう考え・行動すればよいかが書いてある。誰だって気持ちよく仕事したい。だから、「アジャイルな習慣を身に付けると、こんな気分で仕事ができるよ」というアプローチは、とても魅力的。どれぐらい魅力的かは、「こんな気分」というチェックポイントで確認できる。

こんな気分 : 自分が答えを知らないということを安心して認められる。大きな失敗は学習の機会だ。魔女狩りの機会じゃない。チームは一致団結する場だ。互いを非難しあう場じゃない。

　さらに、「こんな気分」では、プラクティスが上手くいっているかどうかも確認できる。「こんな気分」にならないのであれば、何らかの修正が必要だということ。ただ、やり過ぎはよくないという戒めに、「バランスが肝心」という項も設けている。2500年前の賢者の教えは、システム開発にも生きている。

• 「自分のせいじゃない」というのが正しいことはまずない。また、「全部お前のせいだ」というのも同じくらい間違っている
• まったくミスをしていないのであれば、それはおそらく一生懸命やっていない証拠だ
• チームの多数派（特に影響力の強い開発者）の振る舞いがプロ意識に欠けていて、チーム運営に無関心な場合は、自分自身がチームを離れてよそで成功を目指すべきだ（デスマーチプロジェクトに引きずり込まれるのに比べたら、はるかにましだ）

　ひとりの開発者として、日々の現場で抱く感情、気持ち、態度、心構えに焦点をあて、ベストではなくベターなプラクティスを解説する（ちなみに、"ベストプラクティス"なんてものはウソっぱちで、どんなプラクティスも前提条件つきの"ベタープラクティス"でしかないという）。

■　「特に違いはありません」で痛い目にあう

　「プラクティス21:違いがあれば結果も変わる」がズブりと刺さったのは、先週の金曜。要するに、「特に違いはありませんよ」という罠の話。既に読んでいたにもかかわらず、実戦に適用できなかった失敗例として白状しよう。

　次のリリースで、他社のシステムとのSOAP接続インタフェースが増えるので、dtdやWSDLを準備すればオッケー…のはずが、「つながらない」。シミュレート環境だと上手くいくのだが、実際に他社システムと接続しようとするとrmiで例外になる。2日間あれこれ試したが、ダメ（←わたしはここでレスキューに入った）。

　最初にヒアリングした時点で気づくべきだった→「つながった場合と、失敗した場合の違い? 環境ぐらいで、他には特に違いはないです」…ここで、「違い=環境」にバインドしてしまったのが運の尽き、資材、設定情報を徹底的に洗い出し、間違い探しの旅を始めてしまった！

　結局、一昼夜かけてもつきとめられず、「ホントに環境だけ?」と血走った目でツッコんだところ、「実はテストデータが違うことに今気づいた」とのこと。な、なんだってーΩΩΩ と調べると、データ設定のトコで不具合があり、相手システムでぬるぽになってた… 「違い=環境=自システム」に閉じたのが敗因やね。そういえば、ヒアリングのとき、バグの言い訳のオールタイム・ベスト1「ぼくのマシンでは動くんだけど…」が出てたっけ… この「痛い目」は、本書ではこう紹介されている。

「特に違いはありませんよ」この不朽の名言をベンダや同僚が口にしたら、彼らが間違っているほうに賭けるんだ。何か違いがあれば、その結果は確実に違う。

この手の問題は、非常に高くつく

■　「あとどれだけ」で管理する

　TOC、すなわち制約条件理論（Theory Of Constraints）はオススメ。以前、[プロジェクトを成功させる魔法の言葉]でスゴ本を紹介しているが、本書ではTOCのエッセンスを紹介している。「プラクティス23:ありのままの進捗を計測する」だ。

「進捗率」をでっちあげるのはやめよう。作業がどれだけ残っているかを測定するんだ。最初に40時間かかると見積もった作業が、35時間経過した時点で、さらに30時間かかりそうだったら、その見通しのほうが重要だ（ここでは正直であることがとても重要だ）

　覚えがあるだろう、「進捗率80%」から変わらない報告会。「どれだけ進んだか」よりも、「あとどれだけ残っているか」が重要で、「残り」を正確に見積もるためにありのままの消化率を測るんだ。見当違いの測定基準（%が最たるもの）で、自分を欺くのはやめよう、という天使のアドバイスは激しくシンクロする。ゴールを念頭においた意識合わせにも通じるものがある。

ベストな解決策を探しはじめる前に、その状況は何をもって何をもってベストとするのか、メンバー全員の認識を合わせておく。開発者にとってベストなことが、ユーザーにとってはベストではないかもしれない。逆もまた然り

いわゆる「成功基準」やね。「何をもってうまくいっているのか」について認識を一致させておくと、「その成功基準に足りないのはどれぐらい?」という目で進捗を測ることができる。

■　「ソリューションログをつける」は、必読だけじゃなく実行すべし

　問題を解決した記録（ログ）やね。あたりまえなんだけれど、実はやってる人は少ない典型例がこれだろう。問題が起きたら、すばやく解決したい。以前、似たような問題があったのなら、そのときどうしたのかを思い出して、今度はもっと早く解決したい。ところが、どうやって直したのか思い出せないのが世の常だ。そこで、ソリューションログ。

　・問題が起きた日時
　・問題の簡単な説明
　・解決策の詳細な説明
　・詳細情報や関連記事のURL
　・解決の糸口や理解の助けとなりそうなコード片、設定、画面のキャプチャ

これをマメに記録しておけという。Wikiのようなカタチから入らなくてもいい、テキストエディタやExcelで充分。「あとで検索」できればいいのだから。

　実はこれ、数年前からやってた。昔はメールのログ、メモ、トラブルシートといったバラバラな形で残していたが、今では「自分ログ」として記録している。自分専用の問題解決パターンが蓄積され、文字通り「agile/素早く」対応できるようになった。「だまされたと思ってやってみな」と自信を持ってオススメできる。

■　現場で培われた45のプラクティス

　「あたりまえだけど、重要なこと」は、教えてもらえないもの。教わるというよりは、スゴい人から盗んだり、自分であがいてもがいて身に沁みさせたりするものなのかもしれない。ところが、嬉しいことに、本書にはそういった暗黙知（のような習慣）が並んでいる。「誰にでも役立つ弾丸」ではなく、「わたしに役立たせるために、身に付けるべき習慣」という目で、選びたい。

　じっさい、夢物語でしかない「プラクティス」もある。「10:顧客に決断してもらう」や「18:定額契約は守れない約束」なんて、「それができたら苦労はしねーよ！」と叫びながら読んだ（もちろん、あなたが読めば別の意見になる）。銀の弾丸は無いが、あなたが気分よく仕事をするための「習慣」は必ずある。選ぶだけでなく、「実行」が大事。

1. 成果をあげるのが仕事
2. 応急処置は泥沼を招く
3. 人ではなくアイデアを批判する
4. 機雷がなんだ！ 全速前進！
5. 変化に付いていく
6. チームに投資する
7. 時が来たら習慣を捨てる
8. わかるまで質問する
9. リズムに乗る
10. 顧客に決断してもらう
11. 設計は指針であって、指図ではない
12. 技術の採用根拠を明確にする
13. いつでもリリースできるようにしておく
14. はやめに統合、こまめに統合
15. 早いうちにデプロイを自動化する
16. 頻繁なデモでフィードバックを得る
17. 短いイテレーションでインクリメンタルにリリースする
18. 定額契約は守れない約束
19. 天使を味方につける
20. 作る前から使う
21. 違いがあれば結果も変わる
22. 受け入れテストを自動化する
23. ありのままの進捗を計測する
24. ユーザの声に耳を傾ける
25. 意図を明確に表現するコードを書く
26. コードで伝える
27. トレードオフを積極的に考慮する
28. インクリメンタルにコードを書く
29. シンプルにすること
30. 凝集度の高いコードを書く
31. "Tell, Don't Ask" ――― 求めるな、命じよ
32. 取り決めを守ってコードを置き換える
33. ソリューションログをつける
34. 警告をエラーとみなす
35. 問題を切り分けて攻める
36. あらゆる例外を報告する
37. 役に立つエラーメッセージを提供する
38. 定常的に顔をあわせる
39. アーキテクトもコードを書くべき
40. 共同所有を実践する
41. メンターになる
42. 答えを見つけられるように力を貸す
43. コードの共有には段取りがある
44. コードをレビューする
45. みんなに知らせる

　そういや訳について言うのを忘れてた。訳出が上手いというだけでなく、経験した者ならではの表現が巧い。「プラクティス12:技術の採用根拠を明確にする」には思わず笑った。要するに、「新しい技術はツールなのだから、その技術自体が仕事になってはいけない」例として、こうある。

ついカッとなって永続化レイヤを独自に開発したくなったら、テッド・ニューワードの言葉を思い出すんだ「O/Rマッピングは、コンピューターサイエンスのベトナムだ」

「ついカッとなって永続化レイヤを独自に開発したく」あるあるｗｗｗ「今は反省している」と付け加えたらサイコーなんだけれど、さすがに原文にないか。新人に限らず、オススメ。痛い目に遭っていればいるほど、身にしみるスゴ本。わたしも「システム開発に関わる人はみんな読めー」と声を大にしたいですな。