mofmof社では定期的に「モジャイル開発を語る会」なる社内勉強会を開催してます。複数のチームがそれぞれのプロジェクトで開発をやっているので、自分以外のチームがどういう風にやっているのか知識共有するために始まった。今回のテーマはシステム開発における「見積もり」について。

ところでモジャイル開発とは一体何か。

それは「もふもふ」と「アジャイル開発」をかけ合わせた造語である。ふざけた名称だけど、案外社内では定着しているし、モジャ公を彷彿させるその名称は密かに気に入ったりしてる。

開発前の見積もりと開発中の見積もり

まず、一口に見積もりと言っても、開発前か開発中かの2つに分けられると思う。問題になりやすいのは開発前(受注前)の見積もりですね。

大体の場合、開発前(受注前)の時点ではシステムの概要の情報しかないので、ほとんど推測で見積もるしかないわけですが、推測で立てたざっくり見積もりがいつの間にかコミットメントになってしまう、みたいな話は良く聞きます。

mofmof inc.では月額制の開発サービスをやっていますが、やはり発注者にとっては、いくらくらい払ったらどのくらい出来る見込みなのかは事前に知りたいわけなので、当然いつまでにどれくらい出来ますか？という質問がある。

以前は過去の実績から「1ヶ月で30ポイントくらい出来ます」って回答していたりしましたが、本来ストーリーポイント見積もりは相対見積もりなので、人やチームに寄って尺度が変わります。30ポイントという具体的数字が出されてしまうと、実際との乖離が生じてしまう可能性があるという懸念がありました。

参考: プランニングポーカーを使ったストーリーポイント見積もり

リリース日だけ決めて、小さいスコープで見積もる

ストーリーポイントの正しい考え方に則って見積もりをするのであれば、実際にプロジェクトを走らせて計測した上で、どれくらいのポイントが出せるのかを見出さなければなりません。

ともすると、見積もりがなければ開発スタート出来ないけど、見積もりするためには開発をスタートしなければならないというニワトリ卵問題にぶち当たるわけです。

そうなるといつまでたっても見通しが立たないので、我々は、リリース日タイミングを先に決めてしまって、それまでにどの程度やりたいことが実現出来そうかという見積もりの出し方をします。作りたいシステムの概要を聞いて、どの部分が出来なくて、どの部分まで出来そうかをざっくり決めます。

実際の回答の仕方は「ここら辺の機能は難易度が高いので最初のリリースからは外しましょう。その上で、今描いている構想全体の60%くらいが実現出来ると思います。それでもMVPとしての機能としては足りるはずです。」みたいな言い方することが多い。

ちなみに、どんなに大きい構想のプロジェクトでもリリースタイミングは開発着手から3ヶ月間で設定しています。それ以上先の計画を立てようとすると、見積もりとのズレ幅が大きくなりすぎるためです。この現象は不確実性コーンと呼ばれています。

参考: プロジェクトの本質とはなにか

結論

一般的には機能リストに対して全て実装したら、いつまでにいくらで実現出来るか？という流れで見積もりを出すことが多いですが、上で述べたようにそれだと見積もりのズレ幅を大きくなりすぎるので、それはやめて、スコープを最小限まで絞って見積もりするのが良い。

機能を全て実現することではなく、最初のリリースで検証したいユーザー体験の実現にフォーカスして見積もるのがベストだと思います。機能=価値ではないはずなので。

あと、見積もりの回答には可能な限り担当予定エンジニアの意見を反映させるの大事。