Clean Agileを読んだ

最近になってようやく・少しずつ「アジャイル」なるものに興味が出てきたな・・・というタイミングで、「新しくClaen Agileっていう本が出るよ」というのを、翻訳者の1人である角さんのツイートで知った。
こんな良いタイミングで、こんな良さそうな本!!と購入。最近、書籍購入の財布がガバガバなこともある。

読後の感想としては、「アジャイル(未)入門」な自分が触れても充分に楽しめた!
内容も然ることながら、文章が凄い読みやすかったし面白かったな・・全体を通じて、(しばしば技術書や翻訳書にあるような)専門的・歴史的・横暴で権威的な眉間にシワを寄せながら付き合っていかなきゃいけない箇所みたいなのがなかった。文量的な軽さも相まって、読みやすいな〜って感じ。

アジャイルやXPについての具体的なやり方・プラクティス・ノウハウについては踏み込みすぎず、あくまで「アジャイルって(本来は!)こういうものなんだぜ・・」という部分を語っている本だな、と思う。理念というか初期衝動というか。
アジャイルって聞いたことあるし何となく存在は知ってるんだけど、計画期間を短くして回すやつ?それ以上の違いってどこなんだろ?」みたいな雑な認識をしてる人が読んでみると、「なるほど、その辺りが本質なのか」という輪郭が掴める気がする。

まさに副題の「基本に立ち戻れ」という通り、これは「この先、具体的にアジャイルやXPについて学んだり実践したりして、少しずつ自分なりに理解を深めていく中で、何度も帰ってくるべき故郷みたいな本になるかもな」という予感。
もっというと、「2章: アジャイルにする理由」と「6章: アジャイルになる」の前半、「7章: クラフトマンシップ」かなぁ。本質さえ抑えておけば道を誤らない、”実装論”や”プラクティス”は些細なことになるのではないか?という感覚がある。その点、これらの章が本書の中でも「なぜ」「どうすれば」に簡潔に答えてくれているような気がして。


以下、読みながらとっていた読書メモを見返しながら、特に気に入った部分とか。

P43

アジャイルは速く進むことだと思っている人もいる。だが、そうではない。これまでそうだったこともない。アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることだ。できるだけ早く知りたいのは、そうすれば状況をマネジメントできるからだ。(中略)アジャイルはデータを生成する。アジャイルは大量のデータを生成する。マネージャーはそれらのデータを使用して、プロジェクトの成果を可能な限り最高にする。

"アジャイルは速く進むことだと思っている人もいる。だが、そうではない。これまでそうだったこともない。" は、読んでて1番「おぉっ!」と思った箇所かも。
「フィードバックサイクルを短くして、現状をしっかり見つめて機敏にやる」みたいな話だもんな、そうだよな・・「成功確度を上げる」というのと「速くする」ってぜんぜん違うよな。それに加えて、「要求とは常に変化し続けるもの」となれば、より「細かく方向修正していく余地を持つ」ことが大事になる。そのためにフィードバックを集めるのか。
”プロジェクトの成果を 可能な限り最高に する"、なるほど。

この「データ」というのは、例えばストーリーポイントの消化状況だったり、バーンダウンチャートに現れている状況だったり(この前節のタイトルが「アジャイルが生成するデータ」)。「能動的に(積極的に)フィードバックを集められるようにモニタリングして、”適応的”にやっていく」っていうことか。

P44

プロジェクトの鉄十字に戻ろう。「品質」「速度」「費用」「完成」だ。マネージャーは、プロジェクトから生成されたデータをもとに、どれだけの品質、速度、費用、完成度のプロジェクトにするかを決める。 そのためにマネージャーは「スケジュール」「スタッフ」「クオリティ」「スコープ」を調整する。

可変変数はどれか、という話。この後に「(クオリティは)速く進みたければ上げるしか無い」って書かれていて、なるほど「クオリティも非可変か」と思った。
ラクタを作っても遅くなるだけ!

P59

しかし、その新メンバーのトレーニングは誰が担当するのだろうか?これまでコードベースを雑然とさせてきた人たちだ。新メンバーはすでに確立されているチームでの振る舞いに従うことになる。 さらにまずいのが、既存コードが強力な手本になることだ。新メンバーは現状のコードを見て、チームの仕事を推測する。そして、雑然とさせることに加担し、それを続けていくことになる。

そう!!!!コレ!!!!!!!!!って感じ、思わず膝を叩きそうになった・・。 「プロダクトの成長性を規定するのは既存コード」みたいな感覚。この辺り、前にカンファレンスで話した時にも触れた部分に近い。
あと「腐敗は侵食する」という。ただ、よくも悪くも「コードを書いている内にプログラマの腕や見識は高まる」ものなので、つまり「既存資産が良いコード」である確率はゼロになるんだよな。 普段から「今あるコードよりちょっといいコードを書こう」くらいの気持ちを強く持つことは必要かもしれない、或いは「未来の誰かのお手本を作っている」という緊張感が欲しい。全力を出さないで良いと考える合理的な訳がなくなる。

P122

シンプルな設計とは、必要とされるコードだけを書いて、最もシンプルで、最も小さく、最も表現力のある構造を維持するプラクティスである。

  1. 全てのテストをパスさせる
  2. 意図を明らかにする
  3. 重複を排除する
  4. 要素を減らす

1はTDD当たり前として、2〜4は個人的に考える「良いコード = 筋肉質なコード」に近いなー!「最もシンプルで、最も小さく、最も表現力のある構造」って良すぎる。
プログラマーの意図を明らかにする」 = 「表現力を高める」で、「表現力を豊かにしたあとで、重複を排除する」なのか。 「すべての重複を排除したら、クラス、関数、変数などの構造的な要素の数を減らすべきであることを示している」。これも「ローカル変数をなくす・メンバを減らす・・を意識して徹底するとコードの読みやすさを上げやすい」っていう自分の体感に適う。


アジャイル〜〜なトピックだと、次は「みんなでアジャイル」→「アジャイルサムライ」→「エクストリームプログラミング」か「SCRUM BOOT CAMP THE BOOK」辺りを読もうかなぁ〜って予定