見積せえへんねやったらどうやって予算取りするねんという話
私は世界規模のクラウドプラットフォームの開発者で、現在はシアトル付近に住んでいる。
先日書いた自分のポストに対する反応で面白い意見があってそれを読んでそらそう思うやろなぁと思った。ただ、私も別に嘘を言っているわけではないですし、これでビジネスも回っている。面白そうなので、その辺も調べてシェアすることにしてみました。
ウォーターフォールからアジャイルって開発側の話はいいのだが、それだと管理とか経営とか非エンジニアの理解を得られないので、納得できるところをちゃんと言語化してほしいんだよな。アジャイルの人の「見積もりがない」って言葉を使われるのが一番苦手、ストーリーポイントの設計は「計画と見積もり…
— えふしん (@fshin2000) August 1, 2024
自分のチームの開発プロセス的なもの
こちらの方に自分のチームが現在やっている開発プロセスは書いてある。アジャイルとか、DevOps 以降の手法であるが、厳密にアジャイルというわけでもないし、企業秘密というほど特殊なことをしているわけでもありません。他の北米の企業のエンジニアの方に話を聞く限り、多分現在の北米では普通のスタイルではいでしょうか。また常に変わっていきます。
最初の質問に戻ると、少なくともエンジニアとかチームのレベルでは
ストーリポイントを含む、タスクに対する工数見積もりはしない
スコープに関しては相当に柔軟で In/Out 優先順位も頻繁に変わる
納期に関しては日本人的には無い感じで、どうしても必要なケース（Build のキーノートで発表される予定の機能の担当）とかでもない限り納期的なものは無い。
そのように納期を絶対に守りたい場合はそれまでにどう考えても絶対できるぐらいにスコープを小さくする。無理はしない。
という感じだ。そんなので経営層納得するんかい！どうやっとんねや？というのはごもっともなご意見だろう。直接経営層とやってるレベルの友人のクリスにそこら辺のこと、そして、昔からそうだったのかあたりを聞いてみた。
アメリカでも昔はやっていた
クリスの話によると、昔は見積をしていたようだ。ただ、１１年ぐらい前までにはやらなくなったらしい。アジャイルでも下記のような本が出ていたので、みんなやっていたのだろう。この本が出たのは 2005 年だからもう20年近く前の出版になる。
なぜやらなくなったか？と聞くとクリスは次のように答えてくれた
このような積み上げスタイルの見積もりは、細かくなればなるほどブレが酷くなるから役に立たなくなるんだよ。それに納期は無理に合わせると、品質も下がるし、エンジニアがバーンアウトしたり、辞めたりするのでろくなことがないよ。
うん。とてもわかる。だからそのあと No Estimate みたいな動きが出てきて、一般に取り入れられたのが１１年前ぐらいなのだろうか。やっぱりソフトウェアの場合は、見積というのは星占いレベルのものでしかないのだろう。だから、この事実をまず受け入れて「どうするか？」を考える必要がある。
どうやって予算をとるのか？
しかし、株主もいるし、当然予算は計画するので何らかの手法で、予算取りをする必要はあるのだ。そのあたりをクリスに聞いてみるとこんなことを言っていた。
予算は人の人数とそのほかの必要経費から計算できる。ただ、人を増やしたいケースの場合は、どれだけ追加の必要がある論拠を説明できないといけないので、経営層が納得いくエビデンスを出すんだよ。
なるほど。とてもシンプルな意見だ。どこにもスコープの話が出ていない。私たちは脳死で「工数積み上げ」でないと論拠にならないと思っているかもしれないが、よく考えると経営層からするとそんなものはどうでもよくて、お金を投資するに値するかジャッジするものがもらえればよい。だから私たちも「過去にこの方法で予算が通った」という事に固執することなく、新しい方法を考えてくと良いのだろう。クリスが例えばといった方法はこんな感じ。
自分は「デモ駆動開発」って言ってるけど、何か新しいことをやる場合は、タイムボックスでやってみる。期限を切って、それまで人数を増やさず、やってみる。その期限までになにか良い成果が出たら継続するし、だめならやめるという事をするよ。
確かに、経営層も細かいものを見たいわけではないので、例えばこの戦略であれば、失敗しても、特に予算を増やす必要はなく、現在のリソースで、何かいい成果が出たら、経営層にデモをして投資する価値があるか判断してもらえるだろう。
結局のところ、経営層は、「投資するに値するかをジャッジ出来る何か」が欲しいのであって、工数積み上げの細かい見積と、細かい機能に対するコミットが欲しいわけではない。それが、「不確実」なものであればなおさらだろう。経営層からすると細かい機能の出し入れなどはどうでも良いはずだ。
ただ、どれぐらいお金が必要なのか、会社の株価に影響するような、大きなリリースは達成される見込みなのか？というレベルを知りたいだろう。（例えば、うちでいうと、大きな Feature が Public Preview になるとか、GAするとかそういうレベル)
これは想像でしかないが、北米のITをやっている企業では、経営者でもこの辺りのソフトウェアの見積もりの不正確さとか、理解しているか、もしくはもともとそういう細かいことはどうでも良かったのかもしれない。いづれにしても、最初からそうだったわけではなく、いろいろな経験を経て今のようなスタイルにしているのだろう。
日本ではどうやってやったのか？
じゃあ、例えば、日本でSIer で請負開発だったら、アジャイル以降の方法だったらどうするの？できるん？どうやったらええん？という話になると思う。ちなみに、私は 2002 年に、皆が知っているめっちゃ大手の SIer でアジャイルをお客様に対してやって、当時日経コンピュータに事例として掲載された。古い話なので、きっと今ならもっと良い方法があるだろう。
当時の私たちのやった方法は単純で、人件費などからめっちゃざっくり見積を作る。ちなみに当時は見積があまり正確ではないと知らなかったのもあり、その時点で分かっている機能かつ、お客様が絶対欲しい機能（３０％ぐらい）のみを普通の方法で見積ってコミットしたが、その機能ですら同等の機能とは入れ替え可能というわけにしている。そうすると、「変化を抱擁」しながら、予算をコミットして、お客様は絶対欲しい機能に関しては手にはいると最初にコミットしている。エンジニア側としては、その期間があれば余裕ありまくって絶対出来るレベルしかコミットしていないので、当時は、もちろんその３０％だけではなく、変化を抱擁しまくって、いろんな機能をお客様と会話しながら作ってリリースしました。
ただ、これは2002年にやった方法なので、2024年にはもっと良い方法があるでしょう。もしなくても、これも先ほどの 2024年の話から振り返ってみると、経営層にとっては、細かい事が欲しいのではなく、「予算」そして「投資に見合うかジャッジ」できる何かが必要ということなのだと思います。そこから自分で考えてみるのが良いでしょう。
まとめ
これが唯一の方法とは思いませんが、疑問に思う人も多いのかなと思って、私の周りで2024年現在そして、2002年で起こった一次情報に基づいて一つの一例として書いてみました。なんらか皆さんの参考になれば幸いです。
最後に私の本ですが、おかげさまで、９万部突破して、あと 7000部で１０万部みたいです。Amazon の評価も 1500を超えてとてもありがたいことです。ちなみに、Kindle は、2024/8/8 まで 50% 還元セールっぽいですね。よかったらこの機会によろしければどうぞ！