Link and Motivation Developers' Blog

リンクアンドモチベーションの開発者ブログです

見積もりという概念を「見積もり」「コミットメント」「ターゲット」に分ければもっと楽しく開発できる

(※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。

はじめに

リンクアンドモチベーションで、エンジニアをしています、宮田と申します。

自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。

今回はその中で話したことを共有します。

公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。

見積もりに対する課題感

ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」

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

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


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


技術顧問「見積もりを3種類に分けて考えると論点を整理しやすいよ。ソフトウェア見積りという本を読んだことはある?」


ぼく「ないです!」

3種類の見積もり

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

見積もり

見積もりというのは予測。 ある条件の場合、これくらいの時間がかかると思われますというもの。 約束ではなく予測であり、確率だということが重要。

コミットメント

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

ターゲット

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


ぼく「なるほど。」

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

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


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


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


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


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


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

コミットメントは必要

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


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


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


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


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


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


ぼく「はい!」

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

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


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


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


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


ぼく「あわわわ」


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


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


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

自分が思ったこと

自分は10くらいの開発組織を見てきましたが、強い開発組織(もしくは上手くいったプロジェクト)はエンジニアとビジネスサイドのメンバーの連携がしっかりとれていた気がします。

いずれもコミュニケーションがスムーズでストレスが少なかったので無意識に3つの概念が揃っていたのではないでしょうか?

心理的安全とか良い文化が上記をワークさせている気がしました。

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

後日談

元記事は色々な方に読んでいただけました。

感想がツイートされるのを見て嬉しく思いました。

こうなったらソフトウェア見積りも読まないとなるまいと勝手な責任感が生まれ、8000円で中古の物理本を買いました。(自分は電子書籍がどうしても読めないのです。)

ソフトウェア見積もり

確かに名著でした。何でもう絶版なんだろう。