アジャイルサムライを読んだ感想
書籍 アジャイルサムライ を読みました。
とても有名な本なので評価は検索すればたくさん出てきますが、例によって自分の感想を。
一言：「実践は大変」
とても平易なというか、砕けた口調で書かれた本です。中高生でも難なく読めるでしょう。 ただその中身を真面目に考えると、とてもとても「大変」なことを書いています。
今、意図的に「難しい」ではなく「大変」という言葉を使いました。「辛い」と書いてもいいかもしれません。
恐らく、著者が想定していない「難しい」ポイントは「各国の法律の違い」くらいでしょう。そういう意味で、日本のIT業界でこの本のようなことがどのくらいの企業で可能なのかは、ちょっと自分にはわかりません。 ただ、その壁を除いたとしても大変です。
顧客の参加
この本は自分なりに整理すると次の3つの部分に別れます。
- チームの在り方
- 計画と実績評価の方法
- 導入すべき開発技術
このうち開発技術については、ユニットテストを書くとか、CIの仕組みを導入しておくとか、開発者サイドでの効率化の話です。
一方それ以外の部分では、 顧客の関わり方 がキーポイントになります。
アジャイルが その時本当に必要なもの を見つめて 機敏(Agile)に動く ということでしょうから当然といえば当然なわけですが、本当に何度も顧客という言葉が出てきます。
日本語だと「お客様」という丁寧な言い方をしますが、今ここで必要なのは、もっとクールで対等な表現なのでしょう。顧客でもまだ違う気がします。 少なくともお客様は神様ではなく チームのメンバーとして積極的に関わってもらわないと失敗します。崇めてお気持ちを察するだけでは機敏には動けません。
開発チームがそういう状況を作るという意味では開発方法論なのでしょうが、 顧客に当たる人こそ読むべき本 という印象でした。
そして、日本社会で今の所あまり一般的ではない状況を強いるという点で、本人たちの意識次第ではあるけど大変だと思います。
現実の直視
「進捗どうですか？」と聞かれたときには基本的には、「進んでたらいいな」という期待があるわけです。すると現実がどうであれ良い返事を返したくなってしまいます。 「元気？」と聞かれたらとりあえず元気だと答えるように。
一方筆者は、たとえ進捗が0でデモするべきものがなくても、顧客とのデモの日程は延期しないほうが良いと述べています。何も進んでいないことを顧客に説明するだけでなく、そういう場を設けることでチームの意識ができると。 難しくはないけど大変なことです。。
評価は実績で
現実をより正しく捉えるために、「80%完了」といった途中での実績評価は許していません。たしかに、残り20%と思っていたら大きな問題を抱えるかもしれません。 そして、 完了基準はテストまで完了していること というのも繰り返しでています。 厳格にやり通すのはなかなか辛いかもしれないなと。
責任
- 顧客は 何を優先し何を諦めるか を自ら決めなくてはならない
- 開発者は 顧客の要求変化 に応えなければならない
これらは一定の権限さえあれば経験も技術も不要でしょうが、決断力や覚悟が必要です。
積極的な顧客なら今もやっているのでしょうが、平凡なサラリーマン同士が集まったら惰性で動くのが見えます。
誰に読んでほしいか
途中に書きましたが、 顧客に読んでほしい と思いました。
最近でもアジャイル開発要員を○○人増員しますといったニュースが出ていました。でもこの本を読んだら、開発会社だけが頑張る問題ではないと強く感じました。
それから、 経営者 にも読んで欲しいです。
アジャイルを採用したら開発コストが下がるみたいな発想は、そもそも見る視点が違うのだと理解できるかと。
日本語版のいいところ
日本語版には訳注として 訳者の経験則 がチラホラ入っています。
例えばユーザーストーリーの見積もりについて、筆者は「1, 3, 5 で十分」と書いていますが、訳者は「1, 2, 3, 5, 8」を使っているそうです。筆者の経験だけでなく訳者の経験も入っているのは、翻訳本の良いところですね。
ここまで書きましたが..
書籍には、 アジャイルに決まったルールがあるわけではない とも書かれています。
著者のアジャイル観がこの本には詰まっているわけですが、他の人のアジャイル観も知りたいところです。
導入した大企業とかの社員の声も聞いてみたいところですが、そういう知り合いがいないのが残念。
