やっと、読み終えたので。

平日に本を読む時間をとるのは、通勤の帰りか、寝る前かになる。
朝の通勤は、新聞を読んでいるから。
休日は、時間が取れるけれど、ベッタリ読むわけにはいかないけれど、それでも、平日よりはソファに寝っ転がって読むことが多い。
読む本は、amazonで買うか、紀伊国屋で買うのだけれど、最近は、どうしてか紀伊国屋で買うことが多い。多分に、この半年の週末の行動が変わったからだろう。

本を買うときは、何冊か買うことが多く、テーブルに積み本にして、それを読もうと思ったときに、食い散らかすように読むことが多い。

アジャイルプラクティスは、4月くらいに買ったようで、約3ヶ月掛けて読み終えたことになる。この本は、読みはじめると、テーマテーマが面白く、読み応えがあるなぁと感じる。なぜ時間を掛けたのだろうかと後付けの理由を見繕ってみたのだが、つまり、一つのテーマの面白さと奥の深さがあって、それを自分の腹に落とすまでの時間を自然と取っていたのかもしれない。まぁ、時間を掛けて読んだ必要の無い言い訳だが。

アジャイルプラクティスには、アジャイルより以前から言われていたことも、たくさん取り上げられており、アジャイルと聞いて、web系アプリ開発のプラクティスなんだろう、なら関係ないや、と思わない方が良い。ITのプロジェクトに関わるエンジニアで、開発経験者なら同意できることが数多く出てくるに違いない。
特に、赤字プロジェクトなどのトラブルプロジェクトに携わった、いや、巻き込まれたシステムエンジニアやプロジェクトマネージャなら、読む時間を割くべきだ。その見返りは十分ある。

何年か前にトラブルプロジェクトに入ったときに、はじめに取り掛かったのは、朝のミーティングだ。第8章　アジャイルなコラボレーションの38　定常的に顔を合わせる　に書いてあるように、　　

昨日なにやったことは？
今日やることは？
進捗を妨げている問題点は何？

まさに、これをやっていた。トラブルプロジェクトは、誰が何をしているかが見えておらず、結果的にだれも全体を俯瞰できていない状態に陥っている。もちろん、何が課題で、ユーザと何をいつまでにするとコミットしているとか、一度、全体を見渡せるように棚卸しさせることも必要だ。ただ、アジャイルプラクティスにも書いてあるように、多くのことを一度にはできないので、一つひとつ習慣として組み入れて、プラクティスが本当に彼らの役に立っていることを実感させることも必要だ。

あと、同じく第8章アジャイルなコラボレーションの39から42まではとても良いことが書いてある。
周りの経験を積んだエンジニアには、後進育成のために後進育成を課しており、メンタリングも活動させている。
39アーキテクトもコードを書くべき　は、正にそのとおりで、若手の立場なら、アーキテクトの書くコードは、とても良い生きたコードになるだろう。同じプロジェクトで何をどう作るかはドキュメントを読むことで理解できて、その実装がコードで手に取るようにわかるのだから。