はじめに
本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。
自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。
今回はその中で話したことを共有します。
※公開するにあたって分かりやすさを重視して脚色しています。
見積もりに対する課題感
ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」
さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある
約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発するのが一番早いんだなぁ。
ぼく「ビジネス的には計画が大事なのは分かるのですが、正確な見積もりって不可能だし、見積もりってない方が良かったりしませんかね？」
技術顧問「見積もりを3種類に分けて考えると論点を整理しやすいよ。ソフトウェア見積りという本を読んだことはある？」
ぼく「ないです！」
3種類の見積もり
技術顧問「その本の中では見積もり、コミットメント、ターゲットの3つに分けて考えが紹介されているよ。」
見積もり
見積もりというのは予測。
ある条件の場合、これくらいの時間がかかると思われますというもの。
コミットメント
自分たちが、いつ、何を届けるのを約束すること。
ビジネスパーソンとして約束。
ターゲット
ビジネス上の目標。
X月にはリリースしないとネガティブインパクトがあるとか。
ぼく「なるほど。」
見積もりという言葉のずれが問題を起こす
技術顧問「エンジニアが見積もりとして出したものをビジネスサイドのメンバーにコミットメントとして受け取られると後ほど問題になるよね。ビジネスサイドのメンバーからしたら約束は守ってよって思うけど、開発者からしたら勝手に納期決められて辛いっていう話になってしまう。」
ぼく「...(身に覚えがあるな)」
技術顧問「一方でビジネスサイドのメンバーもエンジニアに十分なターゲットの情報を渡していなくて、エンジニアがビジネスを伸ばすためにA機能はX日までは無理ですが代わりになりそうなB機能はX日まで可能ですのような思考ができないケースもよく見る。」
ぼく「あ〜、いつの間にか年度の計画が作成されていたことがありました。」
技術顧問「あるあるだよね。でもエンジニアでもビジネスのこと考える必要があるよ。だって技術でビジネスしてるんだからさ。」
ぼく「確かに。。ターゲットを教えてくれというコミュニケーションをとったことなかったですね。」
コミットメントは必要
技術顧問「君の会社はそうじゃないと思うけど、色々な会社の経営メンバーと話すとエンジニアはわがままだなんて言われちゃったりするよ。」
技術顧問「見積もりと称していつまでもコミットメントをしてくれない。コミットメントをしても守ってくれない。そういうエンジニアってどうだと思う？」
ぼく「かっこ悪いと思います。」
技術顧問「ソフトウェアの見積もりに幅があるからと言ってビジネス上のコミュニケーションが出来ないのは見積もり、コミットメント、ターゲットの3つを区別できていないだけだと思うよ。」
技術顧問「3つの区別をして適切なコミュニケーションができればエンジニアも無理なくコミットメントできるんじゃないかな？ビジネスで中長期の計画を立てるのは当たり前だし、必須だから一定のコミットメントは必要じゃない？」
技術顧問「まずは関係者の間で3つの概念を明確に揃えることからじゃないかな？」
ぼく「はい！」
コミットメントラインはどのようの決めるか？
ぼく「3つの概念に分けることとコミットメントをすることが必要なのは分かりました。適切なコミットメントのラインはどうやって決めるのが良いでしょうか？エイやで決めるとデスマーチになってしまいますし、消極的なコミットメントはターゲットを超えられない可能性を高めてしまうと思うのですがバランンスが難しくと思っています。」
技術顧問「最初から100%のコミットメントをしなければいいんじゃない？ソフトウェア開発の初期で不確実性が大きいのは事実なので、最初の方のスプリントはコミットメントを緩めてもらうのは全然ありだと思うよ。徐々に100%のコミットメントにしてく的な。そして、高いコミットメントの時はエンジニアもちゃんと達成するようにする。」
ぼく「不確実性のコーンに反比例してコミットメントの強度を上げていくのは良さそうです！」
技術顧問「アジャイル、スクラムは小さなコミットメントをし続けているとも言えるよね。だからコミットメントと実績がずれて当然みたいな顔をし始める開発チームは要注意だと思うよ。」
ぼく「あわわわ」
技術顧問「エンジニアがターゲットを理解して、それを達成するコミットメントをしていくと、周りのビジネスメンバーから信頼が得られてどんどん仕事がやりやすくなるよ！」
技術顧問「一方で信頼を勝ち取れないと理不尽がくる。計画の実行の担い手である現場のエンジニアが出来る方法を考えていかないと偉い人の鶴の声を使わざるとえなくなって強制的なコミットメントラインを決められてしまう。例えばマイナンバーカードとか保険証とかそうだったんじゃないかな。」
ぼく「なるほど〜。コミットメントを重ねることがメテオフォール防止にも繋がるのですね。」
1on1後にふと思いましたが、強い開発組織はエンジニアとビジネスサイドのメンバーの連携がしっかりとれている気がします。
無意識に3つの概念を理解していそう(?)
心理的安全とか良い文化が上記をワークさせている気がしました。
おわりに
自分は上記の1on1での学びが目から鱗でした。
ビジネスのことは何となくPdMに任せていましたが、ターゲットを理解して中長期の計画から出来るだけ参加して気持ちよくコミットメントをしていきたいと思います。
エンジニアはやることが多くて大変だと思いつつ、楽しく開発ができるようにこれからも精進していきます。
それでは皆様、Happy Coding！