はじめに

アジャイルをやったことがない場合にアジャイルPJをどう見積もれば良いか
PBI/SBIとかの見積もりとか、アジャイルな見積もりとか、そういうのじゃなくて、契約時に求められる「見積もり」を指す。

先人の回答

前提知識

まとめより

見積りという言葉にはコンテキスト依存性がある

「何を」見積もるのか正しく依頼する必要がある

見積りが「どう使われるか？」も最初から知っておくべきである

予め数字を指定したりといった先入観を与えない

規模が大きくなればなるほど、いかなるものの見積りも難しい

「事前に分からないもの」が多ければ多いほどどちらにしても見積りは不正確

アジャイルなやり方であれば、期日と予算を固定(スコープは可変)するのが定番

見積りの作業をするのは、実際に作業をするチームが行うべきである

個人的に特に重要だと感じるポイントは以下4つだと思っています。

規模が大きくなればなるほど、いかなるものの見積りも難しい
「事前に分からないもの」が多ければ多いほどどちらにしても見積りは不正確
アジャイルなやり方であれば、期日と予算を固定(スコープは可変)するのが定番
見積りの作業をするのは、実際に作業をするチームが行うべきである

予算の決め方

２つの道。

投資可能額を元にする。ソフトウェアを作るというのは投資してリターンを期待してのものです。なので投資可能額というのはある程度決まることもあります。それを聞いて、そのまま予算にするというのがオプション1。

従来のやり方に近い形で積算して、それを予算にする。ただしあくまでも規模感や予算の算出のためだけに使うのであって、スコープを保証するわけではない。

1つ目の時は、顧客内部で完結すると思うので、この記事では２つ目のケースの話をします。

その他

以下あたりの情報を見ると参考になるかと思います。

書籍としては以下あたりが参考になりました。

実体験ベースでの整理

なぜ見積もるのかを理解する

予算をとってもらうための承認プロセスは、ウォーターフォール案件ベースで整備されていることが多く、事前に見積もらていなければ俎上にすら上がりません。
（そこをお客さん内部でなんとかしてほしいという気持ちはあれど、すぐに変わるものでもないので、難しいところ。）
なので、現行制度という制約を前提にすると、見積もりが求められるケースはあり得ます。

重要なのはどんな情報がどんな精度で必要なのかをちゃんと顧客とすり合わせることです。
アジャイルという話が伝わっており、今までと少し温度感が変わるのであれば、それらは把握しておくほうがスムーズに事が進むでしょう。

見積もりの立て付けが変わることをすり合わせる

見積もりは約束じゃなくて「外れるもの」という前提に立てるか

アジャイル界隈では「不確実性コーン」とかがよく話題になります。
要は「見積もり時点では不確実性が高く、外れる確率が高いよ」という話です。
その前提にお客様と同じように立てるかどうかがポイントになります。

よくあるすり合わせ方

「トレードオフスライダー」を使って話をするのが、とっかかりを掴みやすいです。
「アジャイルではこうやって認識合わせするんですよ〜」みたいな感じで言い訳に使える。
（本来論的な話をするなら、アジャイルじゃなくてもやるべきだと思ってるので「言い訳」って表現を用いています。）

（トレードオフスライダーとは、）プロジェクト上の判断基準として、「品質」「コスト」「デリバリー」「スコープ」をどのように優先するべきなのか、関係者ですりあわせるための道具です。

個人的な感触として、初めての受託アジャイルで品質の優先順位を変えられるほど覚悟のあるお客さんも開発ベンダーもいない気がするので「品質」は含めないことが多い。コスト・デリバリー・スコープの優先順位を聞いています。
「コストを優先するということは、コスト超過が見えた場合はスコープを削減する方針で良いですか？」というような感じで言葉にして確認します。

揉めないわけじゃない

揉めるか揉めないかで言えば揉める。場合によってはめちゃくちゃ揉める。
トレードオフスライダーは、揉めないようにするための道具ではなく、アジャイルPJで揉めるポイントを可視化する道具。

PJ開始前に揉めるところを揉めておかないと本当にまずい。
PJ始まってからのっぴきならない状況で揉めるのは本当にしんどい。

契約前ならいろんな落とし所なども見つけられるし、ステークホルダーとの合意もまだしやすい。
（契約後だと「契約時にそんなこと言ってなかったじゃん！」みたいな揉め方する。）

揉めにもめて収集つかなくなるのであれば、それはアジャイル始められないってことなので、始まらなくてよかったね、って受け止めるのが良いと思う。

程度問題は残る

トレードオフスライダーが全てではない。どうしても程度問題は残る。
例えば、デリバリー（工期）の優先順位が低いとしても、「半年なら許容できるけど、10年とかは流石に許容できない」とかはあり得る。
なので、単純な優先順位では語りきれない部分は残る。

トレードオフスライダーを盾に取って、「こういう優先順位って合意したじゃないですか！」と迫るのはおかしい。
「そうは言っても！」ってのはどうしても残る。
大事なのは「現時点の見積もりは、約束ではなくブレうるもの」という認識を合意すること。

何を見積もるのか

開発規模
そもそも何を作るのか曖昧だからアジャイルにしようという話題になるはずで、何をするかわからないものは見積もれない。
なので、仮でもいいからどれくらいのものを作るのかの開発規模を見積もることになります。

ただ、開発規模は参考でしかなく、その通りになるかは不明です。
あくまでこんなものを作るならこれくらいの規模になるんちゃいますかね？みたいな温度感でしか提示できません。

あくまで参考でしかないことをわかりやすくするために、類似のシステムの工数をそのまま持ってくるでもいいかもしれない。

体制
請負と異なり、実際に開発ベンダーとしてお客さんに提供するのは開発体制になります。
なので、開発規模から直接見積もるのはやや理屈が通らないと思っています。

具体的には、何人×何ヶ月みたいな感じ。
開発規模から算出して工期がどれくらいで、何人チームくらいだと仮置きして、こんなもんですかね？
みたいな出し方になるかと思います。

どうやって見積もるか

開発規模

ウォーターフォールと同じで良いか
見積もりが外れるという前提に立てるのであれば、別にウォーターフォールと同じ見積もりでも良いと思ってます。
ただ、スクラム系はイベントは重厚になるので、ウォーターフォールよりは開発に掛けていられる時間は少なくなります。
そういう意味では生産性は少し下げる方が良いような気がしています。
どの程度下がるのかと言われると難しいですが、どの程度イベントがあるかは整理すれば出てくるはずです。

FPもしくはslocもしくは積み上げ
どれもよく聞く見積もり方法だと思いますし、どれでも良いと思います。
よくある話ですが、複数の見積もり方法で見積もって、ちょっとでも精度をあげる工夫などはあります。
が、不確実性コーンの概念からすると、その精度向上は誤差な気もしてます。

生産性の考え方
実際の現場で使っているわけではないですが、どうにもこうにもアイデアがない場合はこんな回答するかもです。

ウォーターフォールで開発に従事できている時間を出す
- 1日の労働時間を7.5時間と仮定。（1週間で37.5時間）
- 進捗会議が毎週1時間。それにまつわる準備を含めて3時間程度だと仮定。
- 年休が月1.5回程度と仮定すると1週間あたりは0.375回。1日が7.5時間なので、0.375回を当て込むと約3時間と仮定。
- それ以外は開発業務に従事できているとすると、「31.5時間/週」。
  - 1週間37.5時間のうち、進捗関係で3時間、お休みを考慮して3時間をそれぞれ引いて、31.5時間。
アジャイルで開発に従事できている時間を出す
- 1日の労働時間を7.5時間と仮定。（1週間で37.5時間）
- スプリント期間は2週間と仮定。
- プランニング・レビュー・レトロスペクティブで、スプリントあたり2日潰れると仮定。
- デイリーやスクラムオブスクラムなどのイベントがあることを考えると、スプリントあたり更に1日潰れると仮定。
- 年休が月1.5回程度と仮定すると1週間あたりは0.375回。1日が7.5時間なので、0.375回を当て込むと約3時間と仮定。
- それ以外は開発業務に従事できているとすると、「23.25時間/週」。
  - 2週間のうち3日はイベントに費やされる＝残り7日＝1週間あたり3.5日＝1週間あたり26.25時間
  - 26.25時間のうち、お休みの3時間を引いて、23.25時間。

単位時間あたりの生産性が変わらないのであれば、23.25/31.5（約73%）くらいの生産量になると算出はできます。
なお、実感としてはもうちょっと生産量は落ちているように感じます。（60〜70%くらい）
（イベントが細々挟まると、さっきまで何に集中してたのか思い出す作業が生まれたりする感覚がある）

生産量が重要なのではない
ゴミを生産しても意味はない。
アジャイルでは、価値があるものを見極める作業などが多く挟まるので、その分高価値なものを生み出す形になります。
不透明なものを作ろうとする場合、ゴミを作ってしまう可能性が格段に上がります。
そのゴミを不必要に作らないように、本当に価値あるものは何かをみんなで会話しながら進めていくスタイルがアジャイルだと思っています。

体制

どんな体制を組むのか？
これがクッソむずい。

1チームをどのように構成するのか
- 1チーム何名にするのか（実感としては5〜6名。これより少ないとチームというより個人の集合っぽくなる、これより多いとコミュニケーションコストが高すぎてしんどい。）
- スクラムマスターは各チームに1名なのか、複数チームを見るのか？
- POは誰がやるのか？
- 偽装請負リスクを下げるために、各チームにプロパーを配置できるか？そのプロパーのスキルは妥当か？
- パートナーをどのように組み込むのか？
- チームとして成り立つのか？
チーム同士の関係性をどのように構成するのか
- 統括チームは置くのか？（大規模アジャイルフレームワークNEXUSの考え方）
- チームごとに役割を少し強調するのか？（大規模アジャイルフレームワークSAFeの考え方）
チームのスケール
- どのタイミングでチームをスケールするのか？
- どのようにチームをスケールさせるのか？（既存チームを分割していくのか、新規メンバーだけで新チームを立ち上げるのか）
メンバーの成長
- アジャイルコーチは用意するのか？
- 特殊な技術が必要で、要員調達が難しい場合、どのように成長を見込むのか？
- スクラムの理解度は十分か？不十分な場合どのようにサポートを考えるのか？
総じて
- これでPJを遂行できる体制と言えるのか？

これ、お作法無いと思う。
特にスケールのタイミング含め、大規模体制をコーディネートできるかどうかはマネジメントスキルとかメンバーとかに依存する気がする。。。

実際の例

どの事例にも適合するものじゃないし、このやり方をしたらまずい案件もあるとは思うけど、あくまで一例として。

タイミング
- 1チームで3ヶ月
- 2チームで3ヶ月
- ４チームで3ヶ月
- 6チームで3ヶ月
- 6チーム化するまでに12ヶ月かけてる感じ。(ギリギリなんとかできた、って感覚。これ以上早くできるイメージはあんまり湧かない。)
スケールの方針
- 既存チームを分割する形で新チームを立ち上げる。
- 新規メンバーとの相性もあって、チームとして成立していないと感じる場合はチーム間の移動も行なっている。

メンバーは固定化すべきとは思ってますが、明らかに雰囲気悪いチームに対して自浄作用だけでの改善を期待するのはちょっと変だと思ってます。
当然、自浄作用で改善していくのがベストだとは思うけど、チーム内部で解決できない問題だってある認識。

どう見積もるか

だいたいの単価を決めて、人数と期間で算出するだけです。
最終的な見積もり根拠はこれだけ。（開発規模はあくまで参考でしかない）

契約を取った後も見積もる

スプリントを数回回して、見積もりが妥当だったか評価するプロセスを組むと良いです。
見積もりがあってた/あってないで揉めるためではなく、見積もりが妥当じゃなかった場合は、計画を見直す必要があるからです。

あと、見積もりと実態が合ってるなんて、おかしいと思った方が良いと思ってます。
何か変な圧力を現場にかけてないか？などを確認した方が良いと思います。

毎スプリントやるのは大変なので、3ヶ月ごとなど、タイミング決めてやるのが良いと思っています。

注意事項

本情報をもとに見積もって外れたとしても保証はできません。（念のための免責）
というか何を持ってしても保証なんてできないよね、という話を書いたつもりです。

まとめ

案件のための見積もり提示は、体制見積もりしかできない。（開発規模は参考値でしかない）
実態に合わせて、見積もりを見直し、計画を精緻にしていくスタンスを顧客と共有する。

次回予告

スケジュールをどう組み立てるかという話。
ウォーターフォールだと工程を順番に並べていきますが、アジャイルは考え方が違うので。