アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

きっかけ

この本最初に知った時、マネージャーの人が読むものだと思っていた。
アジャイルに興味を持った当初は、具体的にどういったことをやるのかという全体像が知りたくて、この本は後回しにしていた気がする。
けど、どこかで

「アジャイルな見積もりと計画づくり」ってみんな読んでるもんだと思っていたけど・・・

みたいな書き込みをみて、やべー俺読んでないわって思ったのが、手に取ることになったきっかけ。
あと、いい加減「で、いつ出来る?」という上司やクライアントの質問に対するストレスに嫌気がさしてきていて、何とかならないかなと思っていたところでもあった。

もう、見積もりなんて毎回毎回自信ゼロなんで。
アジャイルサムライとかで、みんなで見積もるみたいなものの存在は知っていたので、具体的にはどんな感じなのかなーってのも気になっていたのもある。

決して「見積もり」と「計画づくり」”だけ”ではない

タイトルでは「見積もり」と「計画づくり」って単語が入っているので、アジャイルの一部が紹介されているだけのような印象を受けるかもしれない。
しかし、読み終わってみるとアジャイルという開発手法の全体の理解が進んだ気がする。
というか、アジャイル開発の本質は「見積もり」と「計画づくり」なんじゃないかとさえ思えてくるので、結果的には全体の理解に繋がっているんだと思う。

アジャイルは開発者の逃げ道じゃない

この本ではエンジニアにとって聞き入れやすい甘い言葉がたくさん載っている。

  • 見積もりに幅を持たせよう(厳密な見積もりは難しい)
  • 1日5~6時間が作業時間の目安(他にやることたくさんある、メールのチェックとか)
  • 見積もりが間違っていたら、納期を伸ばすか機能を削るかリソースを増やす

当たり前のように思えるかもしれないが、現実とは乖離していることが多い気がする。
エンジニアにとっては、ありがたい言葉の様に僕は感じた。
けど、実は耳の痛い言葉も沢山あるんだよね、そこに目を背けてはダメなんだよな。
その中で特に大事だなと思ったのが

  • 仕様変更ありき(無い方がおかしい)
  • 職務を横断してチームにコミットする

仕様変更ってエンジニアはあまり好きな言葉じゃないと思うんだけど、そもそもアジャイルは変化に対応する為のものであったりするので、仕様変更自体をポジティブに受け入れなくちゃいけないんだよね。
そのマインドの切り替えってなかなか難しいなって思う。
こういうのって価値観のフラット化みたいなものなんだろうか?
意識改革?うわーめちゃくちゃ難しいなあ。

職務を横断してってのも、現実ではなかなか難しいよね。
みんな自分の作業をとっとと終わらせて、早く帰りたかったりするわけだし。
僕もデザインのことはようわからんって言って思考停止してしまっているところもあると思う。
なんか素人が口出すとギクシャクしそうだなって自重しちゃうところもあるし、そういった部分の意識の変化が求められる訳だ。
これらの問題の本質は雇用形態とか評価方法といった、プロジェクトの外側にあったりもするので、これまたなかなか難しいところ。

日本人の空気を読む特性

日本人の「空気を読む」という特性、これがチームにコミットする妨げになることもある気がする。
っつうか、昔の日本は結構「和」をかなり重視していて、それが上手くチームとして機能していた部分もあったと思うんだけど、年々「和」というものが重視されてこなくなっている気がする(表面上だけは取り繕うことはあるけども)。
だからといって完全な個人主義というか「他人との差異の尊重」とかも育ってきてないので、非常に中途半端な印象。
そんな日本で職務を横断して、上下関係もあまり気にせず自由活発な議論を行い、チームにコミットする体制が簡単に出来るかというと疑問だなー。
もちろんそういったことが出来ている会社もあるだろうけど、慣れきってしまった自分の仕事に取り組む姿勢から改めないとだから、意外と日本人には取り入れにくい仕組みなのかもしれない。
だからといって諦めたくはないけども。

まとめ

最初、結構読むのに時間がかかるかな?と思っていたけども、1週間で読み終えることができた。
そしてめちゃくちゃ面白かった。
それは感想の文章量からもわかると思う。
こんなに面白いならもっと早く読めば良かったなーって思う。

アジャイルの話が出てくるところに必ずといってもいい程にこの本が紹介されているけど、その理由が良くわかった。
良い本って読み終わった後に、ワクワク感が残るんだよね、明日への活力が貰えるというか。
この本もそういう意味で良い本だと思う。

アジャイルな開発手法を実際に取り入れようとした時に、「じゃあ、こんな感じに進めていこうか」って流れをメンバーに説明しなくちゃいけない。
んで、計画を立てて実際に作業をこなしていかなくちゃいけないわけで、まあ、一番最初に「見積もり」とか「計画づくり」とかの壁にぶち当たるので、この本はその一番最初にやらなくちゃいけない大枠を説明してくれている。

そして最後のケーススタディーの小説がむちゃくちゃ面白かった。
あー、アジャイルな開発を実現できているところは楽しそうだなーって前向きになれた。

角谷さんの翻訳が好きなのかもしれないけども、「アジャイルサムライ」と良い名著が多い気がするので、読んでない人は合わせて読むとぐぐぐっと理解が深まると思う。
今度は毎日のタスクを如何に進めていくかという技術的なプラクティスの勉強をしていきたいな。
XPとかテストの自動化とか。
あと、スクラムにも興味があるので、勉強を進めたいと思う。

頑張ろう。