◎雑感
自分は開発経験約２年半の、若手ー中堅プログラマーだが、働きながら常に不満に思っていたことがある。まとめてみると、以下の３点だ。
１：自分の書いたコードは適当なのか（コードレビューはしなくて良いか）
２：テストの質と量
３：残すべきドキュメントの質と量とその管理
今まで研修も入れて３カ所の職場を経験しているが、いずれの所でもこれらの管理体制が十分では無いと感じていた。くだらないバグが頻発するし、大事な仕様がドキュメントになっておらず、担当者に聞くしか無いなど、どう考えても非効率な状況が多々遭遇した。
単に自分のスキルや気配りが不足しているといえばそれまでだが、同時に上記の３点の事柄は多くの場合個人頼みの体制には疑問を感じていた。
世の中には大体２：６：２位で「できる人」：「普通の人」：「できない人」がいるとすれば、どんな状況でも「できる人」はできるし、「できない人」はボトルネックになるので置いといて、「普通の人」をどうモチベーションを上げてマネジメントするかが鍵だということは明らかだ。そのためにはこの本で書いてあるようなプラクティスを参考にして取り入れるのが重要なのではないかと思う。
◎短評
アジャイルという開発手法には一長一短で批判もあるだろうけど、この本の中に書かれていることは、どのような開発手法を採用するにしても通用することが満載だ。それは単に技術的なことのみならず、人間関係や心構えなども含む。
例えば第１章のイントロダクションを終えて本編の第２章 アジャイルの初心 で一番始めに出てくるのが「成果をあげるのが仕事」という項目だ。
これはチームで行うあらゆる仕事に共通する大切な心構え、態度だろう。非難してもバグは直らない
サーカスで象の糞の始末する仕事のほうがまだましだと思えるほど最悪の仕事は、極端に後ろ向きな集団で働かねばならないことだ。彼らは問題の解決には興味がない。互いに後ろ指をさしあうのに夢中だ。陰口を叩いたり、非難する相手を探すのに必死になっている。・・・
アジャイルチームではこんなことは起きない。アジャイルチームでメンバーに不平をこぼしたら、こんな返事が返ってくるはずだ。「オーケー。で、私が力になれることはある？」 そう、彼らはくよくよ考える代わりに、努力をその問題の解決に向ける。なぜそうするのかは明らかだ。成果をあげることこそが重要だからだ。誰の手柄だとか、誰の責任だとか、誰が一番頭がいいとか、そんなことはどうでもいい。
技術的には
・Wiki
・ユニットテスト
・バージョン管理
・ビルドの自動化
などが軽く触れられていたが、具体的な使い方までは触れられていない。
全体的にはアジャイルの心構えとその方法について包括的にそのエッセンスを紹介している感じだと思ったし、書かれてあることはどれも的確だと感じた。
各項目の構成は
・主題
例：成果を上げるのが仕事
・悪魔のささやき
開発者を惑わす甘い誘い。 例：「問題に対処するうえで最も重要な第一歩は、犯人を突き止めることだ。・・・」
・本文
・天使の助言
進むべき道。 例：非難してもバグは直りません
・こんな気分
プラクティスの実践が引き起こすはずの感情 例：大きな失敗は学習の機会だ。・・・
・バランスが肝心
プラクティスのバランスをとるためのヒント 例：「自分のせいじゃない」というのが正しいことはまずない。また、「全部お前のせいだ」というのも同じくらい間違っている。
というようになっているが、 "悪魔のささやき"では何度も「あるあるw」と思ったし、"こんな気分"では何度も「成る程なあ」と思った。ユーモアあふれる楽しい構成だ。このような構成は応用すれば実用書などに援用できるのでは？
◎内容
今回は久しぶりにマインドマップにまとめました。
◎今回の一曲
植松伸夫／「片翼の天使」(ファイナルファンタジー７より）
なんか悪魔と天使が出てきたので、天使でitunesに検索かけたら出てきたこの曲で。
「塩酸 姫路 比目魚 出目金 田代ス！♪」
「大きなリス 元気なリス♪」
・オケストラ
・初音ミク
・片翼の天使は東京さ行ぐだ 【FF7×吉幾三】
