webサービス開発において初期にやるのが見積りだと思います。この見積り、多くの現場で早く出したい経営者サイドととはいえ現実的なところに落としたい開発側で対立が起こりがちです。今回、なぜそれが起きるのかと対策の1例をまとめていきます。
私は今まで幾つかのwebサービスのPdMをやり、エンジニアでもあり、airteamというエンジニアさんに1時間から技術顧問についてもらえるプラットフォームも運営しています。開発面からも経営面からもみてきた知見をもとにまとめていきます。
対立とは？
そもそも対立ってなんやねんというのを定義するとここではいつまでに出したいという要望をする経営陣とそれを実際に開発する開発陣のスケジュールを決めるための対立を指します。
建設的な議論はもちろん問題にしていません。
ここで問題にしているのは経営陣と開発陣が見積への認識が違うが故に起こる対立を問題視しています。
見積りへの認識が違うため経営陣は
- ちゃんとコミットしたスケジュールにリリースできないのはなんで？
- 最初の頃にスケジュールを精緻にたてられないのはなんで？
という疑念を抱くことになります。ここを問題視しています。
そもそも見積もりを当てることはできるのか？
そもそも見積もりですが、見積もりは最初期に当てることはできないです。
一番最初に経営陣はまずスケジュール立てたいと思うでしょう。そのため開発にこのアプリを作りたいと思う、いつ頃リリースできそう？と聞きます。しかし、多くの開発陣の本音としてはいやわからんだと思います。
これには２段階あり、そもそも仕様が決まっていなければ何をするか決まっていないので見積もりは不可能です。対象がないので。
上記はまあ流石に決めて議論が開始されると思いますが、次が認識の齟齬が多いところでやることは決まっているけど調査が必要というものです。ここが経営陣側で納得いかない人が多いかもしれません。
開発というのはコードを書くよりも調査する方が実は長かったりします。エンジニアも全ての実装方法を覚えているわけではないですし、常に技術は変わっていくので調べながらどう実装していくのかを決めていきます。
また、実際に実装してみたら自分たちのサービスでは動かないということもあります。世界で自分たちのコードは一つしかないので試してみないとわからないのです。
そのため実装をし始めて調査しないとどう実装していくのか分からず、見積もりもできないのです。
対策
つまり経営陣と開発陣の見積りの対立は見積もりというものの認識が経営陣は作る機能さえ決まれば見積もれるものだと考えているが開発陣から見ると実装を初め、調査をある程度しなきゃ分からないというのがあるため起こります。
まずこの認識を擦り合わせることから対策は始めないといけません。その上で具体的には下記があるとより良いかなと思います。
見積りの更新
見積もりは実装しながらどんどん精度が上がっていくものなので常に更新していく必要があります。また、この期間までは見積りの精度がこれくらいという認識のすり合わせも重要です。
わかりやすく見積り期間とするのも良いかもしれません。例えば機能開発を始め、1週間を見積り期間とし、1週間後に最初に出した予想見積もりを更新し、精度を高めます。
更新自体は多くの開発組織がやっていると思いますが、経営陣に見積りの精度をここまでこれぐらい上げると認識合わせするところが重要です。
機能を削る
見積もりはある程度進めなきゃ精度は上がらない。というのはわかったが現実問題としては納期、リリース日が決まっていてそこに合わせないといけない！ということも多いでしょう。
その場合、各実装がどれくらいでどういう実装方法にしたら見積りが削れるかをコミュニケーションすべきです。多くの開発現場で最初に決めた機能を作らないといけないという前提で間に合わないからデスマーチしようというところが多かったです。
でも経営陣に話したら意外とそれは後回しでも良いということは多いです。もしくはこの仕様に変更したら工数減らせるんだけどというコミュニケーションをしたら通ることもあります。
実際出来上がってきた段階でわかることもあるので見積りの更新も必要ですが、仕様、機能の更新も必要になってきます。ここをざっくばらんに話せると根性論ではない開発現場になります。