『アジャイルプラクティス』を読んだ

ここ2年くらい事業会社の一人SEをやってたんですけど、そんな生活に嫌気が差して11月から某物流系スタートアップに転職し、エンジニアチームの一員となりました。 なにしろチーム開発の経験が全然無いもんで、色々勉強することが多いなーと思っていたら、上司から「これ読みなよ」と渡されたのがこちら。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

以下、簡単ですが所感をまとめておきます。

アジャイルとは「テクニック」ではなく「習慣」

アジャイル開発におけるテクニック、例えば「テスト駆動開発」なんかはそれ単体で議論できるほどのボリュームがあり、Web上の情報も含めて様々な所で触れることができる。 本書の中でもいくつか取り上げられているが、具体的な実践方法についてはほとんど書かれていない。

代わりに、開発の中で陥りやすいエクスキューズを「悪魔の言葉」として、 その習慣を取り入れるべき理由を「天使の言葉」として、 習慣を取り入れることで得られるものを「こんな気分」として紹介している。

「テクニック」はあくまで「テクニック」であり、実践するかどうかは各自の自由。 だけど、習慣として身につけ実践するとこんないい事がありますよ、ということを紹介するスタイルになっている。

オープンなコミュニケーションと共有

誤解を恐れずざっくり要約するならば、アジャイルな習慣とは * コミュニケーションを中心に置く * 課題とコードを共有する * 問題を先送りにしない ということだと理解した。

中でも、コミュニケーションは一番大切だ。 何しろ一番心に響いたのはエピローグ直前の最終第45節「みんなに知らせる」の、この一文だった。

悪いニュースを最後まで伝えないでいるということは、マネージャーや技術主任に「自分のことを事細かく管理してください」と頼んでいるようなものだ

エンジニアに限らず、大抵のチームで同じようなことは起きてるんじゃないだろうか？現に、自分も何度か「悪いニュースを伝えない」ことでやらかしたことがある。 だから、アジャイルでは毎朝スタンドアップミーティングを開き、日々各メンバーが一日やるべきことを手短に説明する場を設けたり、 Wikiやブログに自分の取り掛かっている作業やつまづいていることなどを「発信」する。

今のチームでもこの習慣は実践していて、毎朝カンバンの前に集まって朝会を開いて、自分が今日やるつもりのことを話したり、 Slackに”分報”チャンネルを各自作って、やっていること、やったこと、つまづいていることなどを都度発信している。

ちなみに、自分が大昔にいた（ITとは無縁の）職場では、朝会とは偉い人が話すのを部下が黙って聞く場だったり、失敗したことを報告して叱責を受ける「公開処刑」の場だったので、 「アジャイルを採用している職場では朝会をやっています」というようなことを耳にする度、「まじかよアジャイル最低だな」と思っていた。 （今は全然そんなことはない）

すべてを環境のせいにするつもりはないけれど、自分がよく「悪いことを抱え込んで後回しにしているうちに取り返しがつかなくなる」最悪の失敗をしてきたのは 上に書いたような良くない習慣がチームにはびこってたせいなのかもなと思った。

気に入った言葉

フィードバックをコーディングする

ユニットテストについての説明。文中では、従来的なprintデバッグとの対比で、

(デバッグのための)スタブコードを消さずに保存しておき、自動的に走らせ続けるんだ

との記載がある。 「これまでと何一つ変わったことはしていない、ただ洗練させただけ」ということだろう。

僕自身、人にTDDを説明するときは「チェックリスト2.0」なんて表現を使っていた。 プログラミングに限らず、仕事をする前にはチェックリストを作って、抜け・漏れがないか確認するものだ（トイレ掃除ですらそうだ）。 そのやり方をエンジニア目線でアップグレードしたのがTDDなのだ、と理解している。