iPhoneやAndroidoといったスマートデバイス向けアプリの受託開発をやっています。
簡単に言うとオーダーメイドのスマフォアプリ開発です。
こういった案件の見積をいくつかやっていて気付いた点は、ストーリーポイント法を使って見積もると効果があるということです。
前提としてスマフォ開発は小規模だということ
まずスマートデバイス向けアプリ開発は、
企業情報システム開発やECサイトなどの企業Webサイトに比べて開発規模が小さいことが多いです。
ふつうは数十万円程度、大きな案件でも200〜300万円を超えるような案件は希です。
（それに対して、企業情報システムなどは軽く数千万から数億円に達します。）
小規模の案件ですので、プロジェクトの全工程の見通しが効きます。そのため見積精度を上げやすいという特徴があります。
しかしながら、金額が小さいので細かい見積ミスの影響でも、開発会社にとっては赤字プロジェクトになる可能性があります。
開発期間も当然短いので、見積の精度がプロジェクトの成否に大きな影響を与えます。
これはマネージメントをする者にとっては怖い話ですね。
機能・画面で見積もるリスク
スマフォアプリは、発注側/受注側の双方にとって身近なモノとなりました。
そのため、機能や画面を発注側が具体的にイメージして発注することが多いですし、受注側も詳しく画面・機能レベルに落としやすいです。
概算見積もりの時点で見積単位がいきなり画面や機能といった粒度に落ちることが多いようです。
（この傾向は小規模なECサイトやBtoCのWebサイトに近いですね。）
ところが、機能や画面で見積もることはリスクを含んでいます。
なぜならアプリ全体の実現コストから、画面や機能一つ一つの実現コストは切り離せないからです。
金額が合わないときに、見積単位毎に要件を落としていくことが世の常です。
しかし画面や機能を落としても、実装量自体は大きくは変わらないことはよくあります。
「結局、裏側の仕組み（ロジック）は実現しなくてはならない」ケースや
「要件自体は変わらないので他のやり方で実現しなくてはならない」ケースなどです。
機能や画面で見積って失敗する例
たとえば、「スマフォアプリを使って、発注業務を楽にしたい！」というテーマがあるとします。
発注業務の中の「商品選択」と「発注明細のメール送信」機能を見積もってくださいと言われたとします。
見積として以下のように出したとしましょう。
- 商品選択画面 いくら
- 商品検索機能 いくら
- 選択商品確認画面 いくら
- 発注明細メール送信機能 いくら
金額を抑えるために削られるとしたら、「選択商品確認画面」でしょうね。
実装経験のあるエンジニアの方ならわかると思うのですが、確認画面を減らしてもまったく工数削減効果はありませんよね。
なぜなら、
「選んだ商品データをオブジェクトなどでまとめてメモリ上に持つ仕組み」は、
確認画面があろうがなかろうが実現しなくてはならず、
選択した商品の確認はどういった形にせよ実現しないと不便なので、
いずれ何らかで実現することになるからです。
（最悪、ユーザ試験で仕様バグになったり）
ですが画面あたりいくらで見積しているので、
画面を減らすなら、多少とはいえ値引きすることになります。
これは現実的とはいえない値引きであり、小規模案件だと結構ひびいてきます。
ストーリーポイントとは
前述のような機能・画面で見積って失敗するような経験は、企業システム開発でもよくありました。
企業システム開発の見積もりでは、これに対応するために「ユースケース分析」と「ストーリーポイント法」という見積もり方式が生み出されました。
ストーリーポイント法は、ユーザストーリーを洗い出してストーリーの実現に重みづけのポイントを付与して見積る方法です。
ユーザーストーリとは、
どういう利用者がいて、
どういう利用シーンで、
どういうメリットを享受するか？
を中心に分析したもので、ユースケースシナリオと呼ぶ場合もあります。
画面や機能といった具体的なイメージは、ユーザストーリーの実現の重みづけに利用できます。
ストーリーへの重み付けそのもののやり方などは、話がずれるのでここでは控えます。
ストーリーポイント法で何が解決できるか？
ストーリーポイントで見積ると安易で非現実的な値引き検討ではなく、
本質的な機能の優先順位づけの話ができるようになります。
ストーリーポイントで見積るようにすると、アプリの実用価値を見積上で表現し、それを単位とすることができるからです。
画面や機能といった具体的なイメージも、もちろん見積もりの根拠にしてよいのです。
ただし、その画面や機能はどういうストーリーを実現するために必要なものなのかを示します。
こうすることで画面削減・機能削減ではなく
「実現するべきストーリーに優先順位をつけて対応する」ことや
「実現するべきストーリーを軽微な内容に切り替える」といった調整を進めることができるのです。
ストーリーが減れば必然的に機能が減りますし、ストーリーの実現方式を運営やユーザアクションにゆだねることもできるかもしれません。
ストーリーの分析・優先度を発注側・開発側双方が意識することは開発をスムーズに進める秘訣だったりします。
