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

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
安井力角谷信太郎

毎日コミュニケーションズ 2009-01-29
売り上げランキング : 4949
おすすめ平均

おそらくこの本は私が今年読んだIT関連の本のナンバー１になるでしょう。

私はかつて会社でソフトウェアを作っていました。
3年ほど地獄のようなプロジェクトを体験した後学んだ教訓は「はやくここから脱出しよう」でした。（笑）
なぜならソフトウェア開発というのは見積りが難しく、生活の大半の時間を仕事に取られてしまうという状況に簡単に陥るからです。
もちろん、自分の技術力がないとかコミュニケーション能力がないのもあったと思います。
しかし、経験豊かなはずの先輩SEでさえ徹夜続きになってしまうのは何かおかしいのではないかと思いました。

この本はアジャイルデベロップメントという手法を使って開発プロジェクトを見積って実行していく方法を解説しています。
内容をおおまかに言うと以下の通りです。

・開発システムをフィーチャー単位で考える
フィーチャーとはユーザーにとって役に立つ機能をいいます。
例えばある情報を検索できるとかデータをグラフ表示で見ることができるなどユーザーの視点での機能を開発の基本とします。
当たり前のことなのですが、ソフトウェアは使う人のために作るものです。
しかし、現実の開発現場ではDBは何にするとか効率のいいアルゴリズムはどれかといった作る人の立場でしか考えないことが多かったです。
フィーチャー単位で考えるのはソフトウェア開発であるべき姿だと思います。

・各フィーチャーにストーリーポイントをつける
フィーチャーごとに実現するのにどれくらいかかるかをポイントづけしていきます。
これをストーリーポイントと呼びます。
ストーリーポイントは相対的な量なので人月やコード量ではなく、あるフィーチャーに比べて何倍くらいの労力がかかるかを表しています。
しょせん、最初の段階で正確な見積りなんてできないのだから感覚的に決めていこうという開き直りの考え方ですね。

・開発スケジュールはイテレーション単位で考える
従来の開発方法では最初にスケジュールをしてそれにしたがってプロジェクトを進めていきます。
この方法のまずいところは後で状況が変わったときに柔軟に対応できないところです。
それに比べてアジャイル開発ではイテレーションという比較的短い期間単位でプロジェクトを区切っていろんな変化を吸収していこうとする試みです。
例えば新たな機能を追加しなければいけないときに次のイテレーションに入れられるかを検討したり、優先度の低い機能をはずしたりできないかなどを考えます。
イテレーションの期間は２週間から４週間くらいが多いそうですが、プロジェクトによって最適な日数は違ってきます。

・ベロシティを見積ってスケジュールを予測する
ベロシティとは速度という意味ですが、１イテレーションでどれだけのストーリーポイントをこなせるかの数値になります。
そして、ベロシティは個人の数値ではなく、チームでどれだけこなせるかの数値です。
ベロシティをチームの数値とするのはメンバー同士の協力体制を促すからなのでしょう。
例えば、あるシステムで１００ストーリーポイントの規模がある場合、1イテレーションで１０ポイントのベロシティの場合１０イテレーションで完了する見積りになります。
1イテレーションが４週間だとおよそ10ヶ月くらいかかるということになります。

実は私がソフトウェアを開発していたころ、これと似たようなことを考えていました。
体験的に、機能の数が増えるたびに工数が増えることが分かっていました。
なので機能をすべてリストアップしてそれにポイントをつけていきました。
私の場合は1人日を1ポイントとしてつけて、そして実際にかかった日数を記録して行きました。
その方法でもかなり正確に見積りができるようになったのですが、一人プロジェクトでやっていたのと似たようなシステムばかりやっていたので違うタイプのシステムでは利用できなかったかもしれません。
しかし、考え方は同じだと思います。

私は残業がきらいだったのでこういうことを一人でやっていたのですが、上司や同僚は全く興味をもっていませんでした。
その時、私は彼らがなぜ業務を改善していこうと思わないのか不思議で仕方ありませんでした。
今から考えるとシステム開発はそういうもので気合で乗りきるしかないものだという思考停止の状態だったのでしょう。
そして、火をふいたプロジェクトを気合でなんとか完了させて、自分たちは働いていると思っていたのかもしれません。
しかし、オーバーしたコストが発生していてそれが結果的に自分たちの待遇を悪くしているのがわからなかったんでしょうね。
私はそういう人たちとは付き合いきれないので早々にやめさせていただきました。（笑）

私はソフトウェア開発が好きだったので、本当は続けたかったのですがあまりにも長時間拘束されるのと精神的にモチベーションを維持できない状況が多すぎました。
もし、当時の会社がこの本に書いているようなことをやってくれていたら私の人生も変わっていたかもしれません。
ただ、自分の会社だけではなく顧客側の会社にも問題があります。
ソフトウェア開発はいつ完了するかが最初の段階ではわかりません。
しかし、営業するときにいつできるかわからないなんて言ったら受注できないでしょう。
ソフトウェアを作ったことがない人に見積りの難しさがわかるはずもありません。
そこは営業トークで期限をコミットせずにうまく契約できればいいのでしょうが、営業もわかってないから難しいでしょうね。

とにかくわからない人たちばかりでやっているから悲惨なプロジェクトが後をたたないのだと思います。
しかし、開発者がその犠牲になってしまう構造はやはりおかしいのではないかと思います。
人生には仕事以外にも重要なことがあります。
ソフトウェアを開発するエンジニアは自分の人生を生きるためにも会社のいいなりになるのではなく自分で考えてやっていかないといけないんだと思います。