とあるPJの立て直し: 見積もりについて

Reading time: 約4分
Publish date: 2020-01-07
Tags: agile, development, turnaround, project management, developers, team, estimation

 とあるプロジェクトの立て直しの記録に基づいて、プロジェクトマネジメントをテーマにシリーズで書き残したいと思います。今回は見積もりについて触れていきたいと思います。

要旨


見積もりの状況

 本プロジェクトにおける見積もりの状況は以下のようなものでした。

 引き継いだ時点では、「3ヶ月後までに三大機能を三人で作ってください。」と言うに等しい状況でした。(参考までに、一機能当たりは最低でも60人月程度は必要でした。180人月かかるものを9人月で進めていたのです。)

 このときの開発メンバーには申し訳なかったのですが、試しに一人一機能ずつ担当いただき、無理をして2週間取り組んでいただきました。そうして2週間でできあがったものを顧客に提示し、「このままでは絶対に達成できません」という話をし、体制の増強の必要性を目の当たりにしてもらいました(余談ですが、後に20人規模に増強しました)。

 このような見積もりとなった問題の本質は、見積もりが開発メンバーのあずかり知らぬところで行われていたことです。誰かがどこかで立てた計画はチーム・開発メンバーとは関係がありません。そのスケジュールで進められるのか、期日までに何ができるのか、開発メンバーは関与していないわけですから、できるかどうかは未知数です。「こうなるとよい」あるいは「こうなってほしい」というPMあるいは顧客の想像の産物でしかありません。

 ウォーターフォール型の開発であれば、専門技能のある数人がファンクションポイントやCOCOMO IIのような指標を用いて大規模な見積もりを行うこともあるでしょう。しかし、アジャイルでは目の前に開発メンバーがおり、インクリメントを積み上げてプロダクトを完成させていきます。目の前に実績があるのです。

 そうでなくとも、開発メンバーに一言「これでできますか?」と聞くだけでも不可能であることは早期に認識できたはずでした。


見積もりは遂行するメンバーが行う

 見積もりは見積もりたい対象があってはじめて行われるものです。見積もりの改善だけを行うことはできません。何を提供するために何を作りたいのか、きちんとメンバー全員で認識する必要がありますので、顧客を巻き込んだ要求分析を繰り返しながら見積もりを行っていきました。これは双方にとって負荷の高いものでしたが、この過程はとても重要な活動です。

 そして、見積もりは遂行するメンバー自身が見積もる必要があります。メンバーにとって遂行する過程を正確に想像し、組み立てることで抜け漏れを防ぐこともできます。また、見積もる対象は仕事量であり、時間ではありません。時間はメンバーの能力や経験に依存するところが大きく個人個人で異なりますが、仕事量は全員で共通の見積もりを行うことができます。


見積もりは実績に基づいて行う

 チームのパフォーマンス・実績をチーム全員が認識していれば、自分たちがどのくらいのペースでどの程度のものが作れるのか感覚が身についてきます。これらを定量的に行うための方法として、ストーリーポイントやベロシティがあげられますが、これらの使い方については別の記事をご参照ください。

 アジャイルにおいては、計画を立てられないという誤解が時折見受けられますが、「実績に基づいてより正確に見積もること」ができます。そのためには安定したチームの形成が先です。チームのパフォーマンスの振れ幅が大きい場合にはいくら正確に見積もっても、実態と乖離しやすくなります。チームの安定性の観点からチームを維持することの重要性が垣間見えます。

 パフォーマンスを向上させるためにはチームを継続的に成長させる重要性はいうまでもありません。また、透明性はいつだって重要です。同じ情報を持つと共通認識を形成しやすく、見積もりの精度も高まります。


スコープを調整する

 見積もりがどこまで精緻になってもできること、できないことは変わりません。「作りたいもの」に対して体制が十分であることはほとんどありません。常にスコープの調整が求められます。特にビジネス上、マイルストーンを置くことは必須です。マイルストーンに対して、今の体制だと何が実現できるのか、何はできないのかを把握することが見積もりの一つの目的です。実績に基づいて積み上げた見積もりを眺めることで、正確に把握することができます。「いつ頃に何を提供できるのか」をステークホルダーやユーザーに正しく伝えることが重要です。