洋書売り場で、ちらっと”The Agile Samurai”を見かけて、気にはしていた。左図で判るように、特に表紙の奇抜さ。
いつだったか翻訳版が出そうなつぶやきを読んで、待ち望んでいた。発売日に大きな本屋さんに行くチャンスが無くて、近所の本屋さんで探したけど（さすがに近所では）見当たらず。とある2日間の会合初日の帰りに大きな本屋さんに寄ろうと思ってたら、初日に懇親会というか飲み会に誘われてそちらへ。2日目の懇親会には翻訳者の一人を見かけて、買ってなかったことを猛反省。そしてつい数日前に、想定してなかったが、隣駅の本屋さんで購入できた。
”アジャイル”と”サムライ”。前者は英語で、後者は日本語という2言語による造語がタイトルなので、人によってはどんな本かピンと来ないかもしれない。本の中ではさほど強調してないが、アジャイルでの一手法の”スクラム”を中心としたソフトウェア開発方法の本と考えればいいのかもしれない。つまり、”スクラム”の元ネタが、野中郁次郎氏らによる日本の製造業における開発プロセス紹介であることから、”サムライ”との単語と結びつけられても違和感が少ないと言える。（なお本の監訳者あとがきで触れているが、原著者自身元々は別タイトルにしたかったようだ。） 蛇足だが、本の説明図で、相撲のポーズらしきものも書かれている。
”スクラム”をはじめとして、アジャイル手法を導入してすると課題が発生するが、それらに踏み込んだ記載が多い。また想定課題を「センセイ」と弟子が問答するシナリオとしていくつも掲載されているため、具体的に感じるだろうし読みやすい。その意味でも、多少スクラムなどのアジャイル開発を実践していると、参考になることが多い。もちろん、これから実践する人が読んでも役立つ。ちなみに、「センセイ」は原書でも”Sensei”（Master Sensei）。
例えば、各イテレーションで正式受け入れテストを含めるべきか。P197。実は、既述の2日間会合で、関連することが話題となった。(リリース前）イテレーションの「テスト」には、一般的には受け入れテストは含めなくても良いだろうというのを自分の意見として述べた。アジャイルサムライを読んでなかったことがバレバレ^.^;。 ただし振り返ると、実際の自分のプロジェクトでは、正式リリース前に顧客との/顧客によるテストは何度も実施することが多かった。一般的にも、イテレーションでの「テスト」に、受け入れテストを含めるべきと考えるようになった。（組込みソフトの場合、どんな体制にするかは組織体で要検討だろうが。）
またP217では、スタンドアップミーティング無しにする場合のことが述べられている。価値を生むならやるべき、そうでなければ無くしても良いケースもあるだろうとの記載。個人的には、若いメンバーなら^.^;立ったままで実施すべきと考える。（ただし駄目チームは、単に朝寝坊したくてスタンドアップミーティングはおろか朝のデイリースクラムすら否定したがるので、要注意かな。）
センセイと弟子との問答では、このように組織体によって柔軟に運用することが述べられている。Aでも良いしBでも良いと書かれているように受け取り、悩みが出てくるかもしれない。ただ、各自やプロジェクトチームで考えたり、場合によってはアジャイルのコミュニティなどでやりとりして自分なりに解決していくしかないんだろうと考える。
3章では”インセプションデッキ”という用語が出てきて、プロジェクトの方向性を明確にするための設問(例)が記載されている。ここが、なかなか良い。表面的にはさらっと読める部分だが、実践の際には何度も読み返したり、実際のプロジェクト運営で細部を考えてみると良い。”インセプションデッキ”は、アジャイル系のコミュニティでも、最近話題になることが少なくないと感じる。
冒頭での”読者の声”というのも少し面白い。初版でありながら日本の読者の声もある。ちなみに原書での何人かの”声”と、10数人の日本読者の声という構成になっている。原書も訳本も、レビュアーの存在が大きいとの印象。またそこでのメンバーはアジャイル系のコミュに登場する人が少なくないので、”読者の声”は読んで損はない(/読んでおくべき)と考える。
ちなみに、原書も購入した。当初P6の”期待をマネジメントする”のコラムで日本語監訳者によると書かれており、コラム全てがそうなのかなと、ふと思ったためだ。”期待をマネジメントする”のコラムのみと判明したが、それ以外でも原語が何だろうと気になる部分が少なくなかったのが理由。前に述べた”センセイ”/”Master Sensei”は端的な例。円高ということもあり、興味あれば原書も揃えてはどうだろう。
