--- title: ビジネスとエンジニアリングの3wayハンドシェイク slug: business-and-engineering-3-way-handshake created_time: 2022-11-01T00:00:00.000Z last_edited_time: 2025-11-06T01:41:00.000Z category: Idea tags: - 雑記 - 言語化 published: true locale: ja --- ビジネスとエンジニアリングが足並みをそろえて共に顧客に価値を届けるためには、欠かすことのできないステップがあることに気づいた。それは **「要求」「検査」「合意」** の3ステップで、あらためて考えると当たり前のことしか言ってないが、これを欠いたプロジェクトは簡単に炎上する。この3ステップの様子がTCPのコネクション確立時のプロトコルと似ていたので、**ビジネスとエンジニアリングの3wayハンドシェイク** と呼ぶことにした。 ## 1.「要求」: ビジネス要求をすべてテーブルに載せる 最初のステップは、ビジネスがプロダクトへの要求をすべてテーブルに載せる。 **「テーブルに載せる」** というのは、人々が囲む円卓の上に情報や考えを公開し、それぞれの人が吟味して議論できるようにするイメージだ。ここではプロダクトというテーブルをビジネスとエンジニアリングが囲んでいるということになる。 ![image](/images/business-and-engineering-3-way-handshake/Untitled.6b3134cfeee906f0.png) 「要求」に求められるのは、忖度も遠慮もなく、**100%の理想**をまずテーブルに載せること。2番目の「検査」では、最初にテーブルに載せられたものしか扱えない。ここで隠した目論見や期待が後出しされ、すでに動き出したプロジェクトが吸収できる衝撃の許容限界を超えてしまえば、プロジェクトは炎上する。 とはいえ最初からすべての要求を具体的にすることは難しい。それでもわかってないことはわかっていないということを全部載せる。何がわかってることで何がわかっていないことかという認識を、テーブルを囲む全員で共有する。わかってないからといって隠さずに「このへんは後から変わる可能性が高いから変わっても耐えられるようにしてくれ」という要求ができないと、「そんなことは聞いてない」という悲しい炎上が待っている。 ## 2. 「検査」: ビジネス要求の実現可能性を見積もる 次のステップは、テーブルに載せられたビジネスからプロダクトへの要求を、エンジニアリングの視点で開発要件に翻訳した上で**実現可能性を見積もる**。検査の最初の段階では、100%の理想を実現するために必要な仕事を見積もり、チームや組織にその仕事を実行できる力があるかどうかを吟味する。 力が足りないのなら、この要求すべてを満たすことは難しいということとその根拠をテーブルに上乗せする。もし余裕があるのなら、余力があること、もっと顧客に価値を届けるために厳しい要求に答えられることも上乗せする。ここで余力があることを隠すと、それに感づかれてしまった後には信頼を失い、「どうせ余力があるんだから後から追加の要求をしても大丈夫だろう」と「要求」の質が下がることになる。 ## 3.「合意」: 実現可能かつ価値ある明確なプロジェクトのゴールに合意する エンジニアリングサイドから最初の「検査」結果が出たら、あとはテーブルを囲む人々で協力してビジネス要求を調整する余地を探る。実現可能性があり、顧客にもっとも大きな価値を届けられる落とし所を探る。 全員が納得の行く「合意」に至るには、それぞれの判断基準がすべてテーブルに載っていて、テーブル上の材料から考えれば誰もが同じ結論に辿り着くだろうという信頼が必要である。 **実現可能性と顧客価値の両方が最大化される点**を見つけ、その実現に明確なコミットメントを置かなければ、プロジェクトは炎上する。厳しすぎるゴールはそもそも実現できないし、参加メンバーも消耗する。**甘すぎるゴール**もコミットメントがあいまいになり、計画性や生産性を高めるための創意工夫がおろそかになる。そしてプロジェクトの期間が長くなれば長くなるほど後からビジネス要求が追加される可能性も高まる。（**パーキンソンの法則**） ![image](/images/business-and-engineering-3-way-handshake/Untitled.dccf00c590758124.png) ビジネスにとっても顧客にとってもエンジニアリングにとっても、甘すぎるゴールは望ましくない。実現可能性と顧客価値の両方が最大化される絶妙なラインを見定めるのが、ビジネスとエンジニアリングでテーブルを囲んでやらなければならないことである。 ## 3way ハンドシェイク 3way ハンドシェイクとは一般的に、TCPにおいてクライアントとサーバーの間の通信を確立するための所定の手続きのことで、次の3ステップを最初に行う。 - クライアント -> サーバー: `SYN` を送信 - サーバー -> クライアント: `SYN-ACK` を送信 - クライアント -> サーバー: `ACK` を送信 [3ウェイ・ハンドシェイク \- Wikipedia](https://ja.wikipedia.org/wiki/3%E3%82%A6%E3%82%A7%E3%82%A4%E3%83%BB%E3%83%8F%E3%83%B3%E3%83%89%E3%82%B7%E3%82%A7%E3%82%A4%E3%82%AF) **「要求」「検査」「合意」** は同じ3ステップのプロトコルということだけでなく、クライアントとサーバーが接続して機能するためにかならず最初に行わなければならない手続きという点で似ている。ビジネスとエンジニアリングの協働をはじめるためのプロトコルとして、3wayハンドシェイクという比喩はそこそこ的を射ているのではないかと思う。 また、これはあくまでも**信頼できるコネクションを確立するまで**のプロトコルにすぎず、確立したコネクション上でどのようにコミュニケーションしてデリバリーにつなげるかはチームのプロトコル次第だというのも、TCPとHTTPの関係に似ているようにも思う。 ![image](/images/business-and-engineering-3-way-handshake/Untitled.c42be35154b2535d.png) ## 3way ハンドシェイクができないチーム そのチームが自分たちで3way ハンドシェイクができなければ、できる人に「要件定義」をしてもらわないといけない。つまり上流工程と下流工程の分離であり、バリューストリームの源泉をチームの外に依存した状態だということになる。 自分たちで一貫して顧客に価値を届けたければ、チームが自分たちで3wayハンドシェイクができるようにならないといけないし、それが自律したプロダクトチームが担うプロダクトマネジメントの最初の一歩ではないか。 --- 社内ブログに書いた内容から加筆修正して公開。