技術顧問との1on1で見積もりには3種類あることを教えてもらった

## はじめに

本記事は[モチベーションクラウドシリーズ Advent Calendar 2022](https://qiita.com/advent-calendar/2022/mcs)の17日目になります。

自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。
今回はその中で話したことを共有します。

※公開するにあたって分かりやすさを重視して脚色しています。

## 見積もりに対する課題感

ぼく「[約束は開発を遅らせる](https://bufferings.hatenablog.com/entry/2022/11/23/122815)という記事を最近読んだのですが、その通りだと思ったのですよね。」

> さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある

> 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発するのが一番早いんだなぁ。

ぼく「ビジネス的には計画が大事なのは分かるのですが、正確な見積もりって不可能だし、見積もりってない方が良かったりしませんかね？」

技術顧問「見積もりを3種類に分けて考えると論点を整理しやすいよ。[ソフトウェア見積り](https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K)という本を読んだことはある？」

ぼく「ないです！」

## 3種類の見積もり

技術顧問「その本の中では見積もり、コミットメント、ターゲットの3つに分けて考えが紹介されているよ。」

### 見積もり

見積もりというのは予測。
ある条件の場合、これくらいの時間がかかると思われますというもの。

### コミットメント

自分たちが、いつ、何を届けるのを約束すること。
ビジネスパーソンとして約束。

### ターゲット

ビジネス上の目標。
X月にはリリースしないとネガティブインパクトがあるとか。

ぼく「なるほど。」

## 見積もりという言葉のずれが問題を起こす

技術顧問「エンジニアが`見積もり`として出したものをビジネスサイドのメンバーに`コミットメント`として受け取られると後ほど問題になるよね。ビジネスサイドのメンバーからしたら約束は守ってよって思うけど、開発者からしたら勝手に納期決められて辛いっていう話になってしまう。」

ぼく「...(身に覚えがあるな)」

技術顧問「一方でビジネスサイドのメンバーもエンジニアに十分な`ターゲット`の情報を渡していなくて、エンジニアがビジネスを伸ばすためにA機能はX日までは無理ですが代わりになりそうなB機能はX日まで可能ですのような思考ができないケースもよく見る。」

ぼく「あ〜、いつの間にか年度の計画が作成されていたことがありました。」

技術顧問「あるあるだよね。でもエンジニアでもビジネスのこと考える必要があるよ。だって技術でビジネスしてるんだからさ。」

ぼく「確かに。。`ターゲット`を教えてくれというコミュニケーションをとったことなかったですね。」

## コミットメントは必要

技術顧問「君の会社はそうじゃないと思うけど、色々な会社の経営メンバーと話すとエンジニアはわがままだなんて言われちゃったりするよ。」

技術顧問「`見積もり`と称していつまでも`コミットメント`をしてくれない。`コミットメント`をしても守ってくれない。そういうエンジニアってどうだと思う？」

ぼく「かっこ悪いと思います。」

技術顧問「ソフトウェアの`見積もり`に幅があるからと言ってビジネス上のコミュニケーションが出来ないのは`見積もり`、`コミットメント`、`ターゲット`の3つを区別できていないだけだと思うよ。」

技術顧問「3つの区別をして適切なコミュニケーションができればエンジニアも無理なく`コミットメント`できるんじゃないかな？ビジネスで中長期の計画を立てるのは当たり前だし、必須だから一定の`コミットメント`は必要じゃない？」

技術顧問「まずは関係者の間で3つの概念を明確に揃えることからじゃないかな？」

ぼく「はい！」

## コミットメントラインはどのようの決めるか？

ぼく「3つの概念に分けることと`コミットメント`をすることが必要なのは分かりました。適切なコミットメントのラインはどうやって決めるのが良いでしょうか？エイやで決めるとデスマーチになってしまいますし、消極的な`コミットメント`は`ターゲット`を超えられない可能性を高めてしまうと思うのですがバランンスが難しくと思っています。」

技術顧問「最初から100%の`コミットメント`をしなければいいんじゃない？ソフトウェア開発の初期で不確実性が大きいのは事実なので、最初の方のスプリントは`コミットメント`を緩めてもらうのは全然ありだと思うよ。徐々に100%の`コミットメント`にしてく的な。そして、高い`コミットメント`の時はエンジニアもちゃんと達成するようにする。」

ぼく「不確実性のコーンに反比例して`コミットメント`の強度を上げていくのは良さそうです！」

技術顧問「アジャイル、スクラムは小さな`コミットメント`をし続けているとも言えるよね。だから`コミットメント`と実績がずれて当然みたいな顔をし始める開発チームは要注意だと思うよ。」

ぼく「あわわわ」

技術顧問「エンジニアが`ターゲット`を理解して、それを達成する`コミットメント`をしていくと、周りのビジネスメンバーから信頼が得られてどんどん仕事がやりやすくなるよ！」

技術顧問「一方で信頼を勝ち取れないと理不尽がくる。計画の実行の担い手である現場のエンジニアが出来る方法を考えていかないと偉い人の鶴の声を使わざるとえなくなって強制的なコミットメントラインを決められてしまう。例えばマイナンバーカードとか保険証とかそうだったんじゃないかな。」

ぼく「なるほど〜。`コミットメント`を重ねることがメテオフォール防止にも繋がるのですね。」


:::note info
1on1後にふと思いましたが、強い開発組織はエンジニアとビジネスサイドのメンバーの連携がしっかりとれている気がします。
無意識に3つの概念を理解していそう(?)
心理的安全とか良い文化が上記をワークさせている気がしました。
:::

## おわりに

自分は上記の1on1での学びが目から鱗でした。

ビジネスのことは何となくPdMに任せていましたが、`ターゲット`を理解して中長期の計画から出来るだけ参加して気持ちよく`コミットメント`をしていきたいと思います。

エンジニアはやることが多くて大変だと思いつつ、楽しく開発ができるようにこれからも精進していきます。

それでは皆様、Happy Coding！