アジャイルな見積りと計画づくり: つらつらぐさ

アジャイルな見積りと計画づくり

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
安井力角谷信太郎
毎日コミュニケーションズ 2009-01-29

by G-Tools

　正直なところソフトウェア開発の現場を知らないので、ここに書かれているアジャイルな方法というものとどう違うのかという実感はない。とはいえ、部分的にそういうことなら似たようなことは自分の仕事でもやっていたなあと思うところもあったりで、なかなか面白く読めた。

　もちろん、まったく内容が異なるので同列に扱うわけにはいかないものの、他の事柄においても似たような発想が有益なこともあるんじゃないかとは思う。

　順序立てて繰り返し繰り返し丁寧に解説されているので、開発現場にいる人々であれば理解することも実践することも非常に容易にできていると思う。障害があるとすればいつの世にも存在する「現状維持」しか認めたがらない人々をどう説得するかというあたりなのかもしれない。曰く「前例がないので却下」。

　全体の雰囲気ということでいうと、不思議なくらいに「プログラミングの心理学」との類似性が連想されたり。章立てて解説したあとで「まとめ」があり、「プラクティス（話し合ってみよう）」があるところとか。

　チーム全体で作業するのであらかじめ誰がどのタスクを担当すると決めず、その時々で流動的に全員が協力していくあたりとかは、「もしあるプログラマがかけがえのない人物だというなら、彼をできるだけ早く追い出せ」にも通じるような何かを感じたり。

　ま、とやかく言ってもわたしは門外漢であるのは事実で、とはいえそんなわたしが読んでも「ほー、いいねえ」とか思ってしまうのだから、ソフトウェア開発に携わる多くの人が読んで、よりよい作業に役立てて欲しいと思う。

　難を言えば、活字のポイント数がちょっと小さすぎること。紙質がよいので厚みをとってしまっているが、ページ数と厚みを調整することは十分にできたのでは。というか、そのほうが読みやすくまた手に取りやすかったのではないかなとは思う。

　以下は、気になったところ。

(P.98)見積りをするにあって、チームはストーリーポイントと理想日のどちらを採用してもよい。

「見積りをするにあ[た]って」？

(P.218)表18.1の最初のストーリー「SwimStatsとして、データベースベンダーが変更されても簡単を対応したい」

「変更されても簡単[に]対応したい」？

(P.229　Line 9)仕掛り作業が増えれば増えるほど、新しい要求を思い浮かんでから動作するソフトウェアのフィーチャとして開発するまでの時間は長くなっていく。

「新しい要求[が]思い浮かんでから」もしくは「新しい要求を思い浮か[べて]から」？

(P.232 2.1章 Line 2)リリースバーンダーンチャートは、プロジェクトの完了見込みがいつになるかをとてもわかりやすく教えてくれる。

「リリースバーンダ[ウ]ンチャート」

(P.275　Line 24)なので、それ以上の意味ありません

「それ以上の意味[は]ありません」？

(P.277　Line 26)アランが言った。「ファイルには複数の手を正解として保存しておけるようになってないと」

「保存しておけるようになって[い]ないと」？
（そのままでもよいのですが、小説とは違ってキャラクターの個性を目立たせるよりは文意がわかりやすいほうがよいのではないかと思うと、こちらのほうがよいのかもと）

(P.324　1.本書について　Line 13)「本書は名著と呼ばれることになるだろう」という予言は見事成就したといえます。

「予言は見事[的中]したといえます。」
（成就するのは願いや希望。予言・予想であれば的中したというべき。）

(P.326　3.信頼のおける見積りと計画づくりのために　Line 16)強みを活かし、弱みと補完するための仕組みによる支えによって、アジャイルな見積りと計画づくりは信頼のおけるプロセスになるのです。

「弱み[を]補完するための仕組みによる支えによって」？
（もしも「弱みと」が正しければ、「弱みと[それを]補完するための仕組みによる支えによって」というように、弱みもまた重要だという意味（表現）になるでしょうし、弱みはともかく弱みを補完するための仕組みが重要というのであれば「弱みを」という表現のほうが適切なのでは？）　＜　サポートページを見たらすでに訂正されていた。