アジャイル・プラクティス

驚くべき事に，監訳者がボクのブログにスターをつけてくれてビックリ．

この本を読んで感じた事は３点

１．翻訳が秀逸．
２．アジャイルに開発が出来れば効率があがりそう．
３．ボクの会社では使えない．

だと思う．

１．翻訳が秀逸
翻訳がうまい．とにかくサクサク読める．
エンジニアが訳してるって感じがした．

ただ，「こんな気分」っていう訳が少し気にかかった．
原著でなんて書いてたのかは知らないからあまりなんとも言えないけどね．
P8の説明にもある通り，「プラクティスを実践するとこんな風に思える様になるよ」っていう意味だと思う．
でも，そう書いちゃうと長いしなぁ〜．．．プラクティス毎に登場するだけに気になった．

２．アジャイルに開発が出来れば効率があがりそう．

ボクが特に心がけようと思ったのは，

3.人ではなくアイデアを批判する．
8.わかるまで質問する．
26.コードで伝える．

の３つ．

特に26はコーディングをする上で一番重要なポイントだよね．
不思議とすらすら読めるコードって時々あるけど，そういうコードって案外印象に残らない．
印象に残るコードは，奇天烈な手法を使っているコードか，あり得ないコードが多い．

印象に残らないコードこそ良く読もうと思うし，自分もそういうコードをかける様になろうと思う．

３．だけど，ボクの会社では使えない．

これが一番大きい．
アジャイルの醍醐味は，どんどん開発して，ユーザに見てもらって，それを受けてまた改善して，っていうのを繰り返すイメージ．
なによりも，スピードが速い感じがする．

でも，メーカの情報システム部門のスピードは，ハワイや北欧の様な感じ（もちろん常時火を噴いてるんだけどね．）

「５行だけ修正して，修正盤をデプロイします．」なんて言おうモノなら，
５時間はドキュメント作り・レビューに費やさなくてはならない．

まずは，システム改善仕様書を書く．
次に，みんなでレビューして，グループリーダー（電気系出身）に説明・検認．
その後課長（機械系出身）に説明・検認をもらって．
やっとデプロイできる．

デプロイする際にも，サーバに変更をかける場合は最低でも２人以上で作業すること．（キーボードは１つしかないんだよ．）
なんていう社則があるから，簡単には出来ない．

と言った様に，メーカの情報システム部門ってアジャイルには向いてない．
どちらかというと，工程管理・プロジェクト管理・ウォーターフローモデル．．とかっていう単語の方がしっくりくる．

システムを作るっても，皆使いたがらない．
課長が求めているシステムは管理を目的としたシステムだが，他のエンジニアが求めているシステムは業務改善を目的にしたシステムだからだ．

技術系の課長クラスが集まって要求を聞き．
それを僕らが作る．
そして他のエンジニアに展開すると，「なにこれ？また，俺らの仕事増やすわけ？」って言われる．
ある意味，彼らも被害者だと思うんだけどね．

さらにたちが悪いのが，
リリース直前になって，事務系の50代の管理職クラスから改善要求が入ってくる．
それも小出しにしてね．（内容は，ボタンの配置が今迄と違う．操作が直感的じゃないなど．．．）

そして先輩達は，それに対して愚痴や文句をボクに言ったり．たまに八つ当たりされたりする．
P13にある

「陰湿な責任のなすりつけ合いから，もっと当たり障りのないスポーツや天気の話題に向ける様にしよう」だよね．

あー月曜からもがんばろう☆
でも，こういう現場で働けたら楽しいだろうなぁ〜って思う一冊だった．

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