ビジネスとエンジニアリングの3wayハンドシェイク

ビジネスとエンジニアリングが足並みをそろえて共に顧客に価値を届けるためには、欠かすことのできないステップがあることに気づいた。それは 「要求」「検査」「合意」 の3ステップで、あらためて考えると当たり前のことしか言ってないが、これを欠いたプロジェクトは簡単に炎上する。この3ステップの様子がTCPのコネクション確立時のプロトコルと似ていたので、ビジネスとエンジニアリングの3wayハンドシェイク と呼ぶことにした。

1.「要求」: ビジネス要求をすべてテーブルに載せる

最初のステップは、ビジネスがプロダクトへの要求をすべてテーブルに載せる。 「テーブルに載せる」 というのは、人々が囲む円卓の上に情報や考えを公開し、それぞれの人が吟味して議論できるようにするイメージだ。ここではプロダクトというテーブルをビジネスとエンジニアリングが囲んでいるということになる。

「要求」に求められるのは、忖度も遠慮もなく、100%の理想をまずテーブルに載せること。2番目の「検査」では、最初にテーブルに載せられたものしか扱えない。ここで隠した目論見や期待が後出しされ、すでに動き出したプロジェクトが吸収できる衝撃の許容限界を超えてしまえば、プロジェクトは炎上する。

とはいえ最初からすべての要求を具体的にすることは難しい。それでもわかってないことはわかっていないということを全部載せる。何がわかってることで何がわかっていないことかという認識を、テーブルを囲む全員で共有する。わかってないからといって隠さずに「このへんは後から変わる可能性が高いから変わっても耐えられるようにしてくれ」という要求ができないと、「そんなことは聞いてない」という悲しい炎上が待っている。

2. 「検査」: ビジネス要求の実現可能性を見積もる

次のステップは、テーブルに載せられたビジネスからプロダクトへの要求を、エンジニアリングの視点で開発要件に翻訳した上で実現可能性を見積もる。検査の最初の段階では、100%の理想を実現するために必要な仕事を見積もり、チームや組織にその仕事を実行できる力があるかどうかを吟味する。

力が足りないのなら、この要求すべてを満たすことは難しいということとその根拠をテーブルに上乗せする。もし余裕があるのなら、余力があること、もっと顧客に価値を届けるために厳しい要求に答えられることも上乗せする。ここで余力があることを隠すと、それに感づかれてしまった後には信頼を失い、「どうせ余力があるんだから後から追加の要求をしても大丈夫だろう」と「要求」の質が下がることになる。

3.「合意」: 実現可能かつ価値ある明確なプロジェクトのゴールに合意する

エンジニアリングサイドから最初の「検査」結果が出たら、あとはテーブルを囲む人々で協力してビジネス要求を調整する余地を探る。実現可能性があり、顧客にもっとも大きな価値を届けられる落とし所を探る。

全員が納得の行く「合意」に至るには、それぞれの判断基準がすべてテーブルに載っていて、テーブル上の材料から考えれば誰もが同じ結論に辿り着くだろうという信頼が必要である。

実現可能性と顧客価値の両方が最大化される点を見つけ、その実現に明確なコミットメントを置かなければ、プロジェクトは炎上する。厳しすぎるゴールはそもそも実現できないし、参加メンバーも消耗する。甘すぎるゴールもコミットメントがあいまいになり、計画性や生産性を高めるための創意工夫がおろそかになる。そしてプロジェクトの期間が長くなれば長くなるほど後からビジネス要求が追加される可能性も高まる。（パーキンソンの法則）

ビジネスにとっても顧客にとってもエンジニアリングにとっても、甘すぎるゴールは望ましくない。実現可能性と顧客価値の両方が最大化される絶妙なラインを見定めるのが、ビジネスとエンジニアリングでテーブルを囲んでやらなければならないことである。

3way ハンドシェイク

3way ハンドシェイクとは一般的に、TCPにおいてクライアントとサーバーの間の通信を確立するための所定の手続きのことで、次の3ステップを最初に行う。

• クライアント -> サーバー: SYN を送信
• サーバー -> クライアント: SYN-ACK を送信
• クライアント -> サーバー: ACK を送信

3ウェイ・ハンドシェイク - Wikipedia

「要求」「検査」「合意」 は同じ3ステップのプロトコルということだけでなく、クライアントとサーバーが接続して機能するためにかならず最初に行わなければならない手続きという点で似ている。ビジネスとエンジニアリングの協働をはじめるためのプロトコルとして、3wayハンドシェイクという比喩はそこそこ的を射ているのではないかと思う。

また、これはあくまでも信頼できるコネクションを確立するまでのプロトコルにすぎず、確立したコネクション上でどのようにコミュニケーションしてデリバリーにつなげるかはチームのプロトコル次第だというのも、TCPとHTTPの関係に似ているようにも思う。

3way ハンドシェイクができないチーム

そのチームが自分たちで3way ハンドシェイクができなければ、できる人に「要件定義」をしてもらわないといけない。つまり上流工程と下流工程の分離であり、バリューストリームの源泉をチームの外に依存した状態だということになる。

自分たちで一貫して顧客に価値を届けたければ、チームが自分たちで3wayハンドシェイクができるようにならないといけないし、それが自律したプロダクトチームが担うプロダクトマネジメントの最初の一歩ではないか。

---

社内ブログに書いた内容から加筆修正して公開。

独検2022冬の4級に出願した

www.dokken.or.jp

ゆる言語学ラジオのサポーターコミュニティDiscordがきっかけで始めたDuolingoでのドイツ語学習が180日くらい続いており、せっかくなので何かしら試験を受けてみようと思って独検ことドイツ語技能検定試験に出願してみた。

試験日は12/4。 Duolingo基準だとこれまでに1500単語くらいに触れているらしいが、ReadingはともかくWritingはぜんぜんやってないので、あまり冒険せず1000語相当らしい4級からはじめてみることにした。

文法規則はけっこうわかってきているのであとは語彙と場数という感じな気がしている。というわけで試験までの戦略は

1. 過去問を解く
2. 単語学習用のアプリで毎日語彙を増やす

単語学習用のアプリはなんとなくよさそうな ReWordというのを使ってみる。Duolingoと同じく英語話者向けの教材だが多分これで困らない。

reword.app

というわけでしばらく合格に向けて勉強していきます。

読後メモ『エンジニアリングマネージャーのしごと』

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

O'Reilly Japan - エンジニアリングマネージャーのしごと

今年オライリーから発売された『エンジニアリングマネージャーのしごと』を読み終わったので、あとでまた思い出したいエッセンスをいくつか書き残しておく。

3章 人間と関わる

3.3 上司との連携

毎週時間を取って状況をまとめるというシンプルな活動は、強力な治療効果があります。 取り組んでいる問題からちょっと離れて、紙の上で扱えるようになります。そうすると、問題もそれほど 重大でないとか、難しくないことがわかります。 自分の生活を記録することは、気分や健康の改善に良い影響があるという研究もあります。 仕事を毎週記録することで、 仕事でも同じような効果があるのです。

うまく書けないなら、4つのPというアプローチを試しましょう。

• 進捗 (Progress): 前回の記録から何が起こったか?
• 問題 Problems) どんな問題が起こったか、対処が必要なものは何か?
• 計画 (Plans):問題に対してどのように取り組む予定か?
• 人 (People) : チームの人はどうか。 全員良い状態か? 辛い状態の人はいないか? 何を改善できるか? (p56)

自分のマネージャーとしてのパフォーマンスや健康状態について上司と話をするために、ふりかえりと計画を端的に、定期的に記録する。

サマリーの書き方としておすすめされている「4つのP」も、この文脈に限らず汎用性のありそうなので覚えておきたい。

4章 1on1

4.3 コントラクティング：最初の1on1

コントラクティングとは最初の1on1で扱う単純な質問一式で、あなたと部下が期待することについての会話を誘発するものです。 両者から期待することを出します。 このエクササイズにより、 お互いのニーズを構造化された安全な方法で話せるようになり、率直で透明性の高い会話ができるようになります。(p65)

部下との最初の1on1で、コントラクティング（contracting, 契約）というエクササイズを行うことで、その後両者が互いに何を期待し、どのように関わるかについて合意をつくることができる。

似たようなことは今までにメンターとして1on1をするときにやっていたが、この節のガイドのおかげで今後はもっといいコントラクティングができそうだと思った。

10章 人間って難しい

10.3 ムチとニンジン

処理能力を向上させる本当のリーダーシップは、チームのなかで目的と情熱を育むことで生まれ ます。 エンジニアが組織内での自分の目的と会社のために形勢を変える方法がわかれば、本来のパ フォーマンスを発揮できるようになります。 仕事に情熱が持てれば、もっと良い仕事ができるようになります。 本質的に楽しめる人たちだからです。

（中略）パフォーマンスの問題ではないと仮定してですが、もしチームの仕事に対するモチベーションが低いとか、あなたの思うような動きをしてくれないといった場合は、チームがよく機能する一団となっていける状況を作り出す必要があります。

これに役立つモデルがあります。 自律性、熟達、目的です。 (p186)

チームにとってニンジン（それによってやる気が湧いて一生懸命働くようになるもの）となるのは、それが自律性・熟達・目的の3つの条件を満たすようなものであるという考え方のモデル。

チームの成果に課題を感じるとき、まずこのモデルで考えてみようと思う。そのチームの前にニンジンはぶら下がっているか？ムチで叩いてしまっていないか？

12章 情報の証券取引所

12.3 社内政治

あなたが情報をうまく扱っているとしても、仕事はそこで終わりではありません。 マネージャーとして、人に情報を把握しておいてもらう義務があります。誰も置いていかないようにしましょう。

共有する情報の一貫性を継続的に示すべきです。（中略）プライベートなインタラクションと全体への周知の両方を使って、誰も置いていかないようにしましょう。 (p223)

チームやメンバーが情報の流れから置いていかれないように、必要な情報を確実に把握しておいてもらうことはマネージャーとしての義務である。

「チームを適切な情報のループに入れておく」という考え方はなるほどと思った。点での情報共有ではなく、確実なループを作ることを意識してみようと思う。

14章 良いハウスキーピング

14.4 問題を学習の機会に変える

先ほどは、ソフトウェアに問題があったときに何をするかを見てきました。 では、プロ セスに問題がある場合はどうすべきなのでしょうか？チームが、ブラットフォームのアーキテクチャーに関するドキュメントや新しいサービスを作るときのベストプラクティスを記したガイダンスを見つけるのが難しいような場合です。 これは単にチームにとどまらない問題であり、答えを見つけるのは難しいかもしれません。 また、このような問題は、士気の低下にもつながります。手に負えない状況の場合、 人はどうやって変化をもたらせるのでしょうか?

このようなときに、マネジメントバグに取り組んではどうでしょうか? eBay が急成長していたときリーダーシップチームは現場からどんどん離れていってしまいました。 小さくて機敏な文化は、急激に大企業的になりました。 CEOはこの問題を正したいと考えて、オフィスの人通りの多い場所に意見箱を置きました。 誰でもメモを箱に入れることができ、全社ミーティングのときに箱を空にしました。すべての意見や提案が、従業員全員の前で読み上げられ、 回答されたのです。 (p266)

マネジメントバグという方法ははじめて知ったが、つまりプロセスやマネジメントの課題についての目安箱だということだろう。特徴的なのは、それがすべて全員の前で読み上げられ、マネージャーがすべてに回答するという徹底的な透明性へのコミットメントだと思う。投げ込んだチケットが無視されず回答されると信頼できるからこそ、真剣に意見を上げてくれるのだろう。会社全体の課題じゃなくとも、小さい規模でやってみたいと思った。

16章 現代の職場環境

16.2 リモートワークへの移行

非公式なやりとりが減ってくると、スタッフのために価値と目標をきちんと設定することはより重要になります。

• 価値はチームの働き方を定義するため、メンバーは統一された方法で非同期に進捗を出せます。（中略）
• 目標はチームの狙いを定義するため、みんなの足並みがそろいます。 分散チームではスタッ フが自律的に働けるため、目標の重要性が増します。

チームの価値と目標についてそれぞれ別の効果のために設定する。価値は何を大事にするかという、チームの働き方を規定するための土台になるもので、具体的な行動指針として記述されればそれがワーキングアグリーメントということになるだろう。 一方で、目標はチームがなんのために働くのか、何がそのチームの勝利・成功なのかということの基準になるものであって、イテレーションの中で追跡していくものになる。この2つを混同せず、どちらも欠けていないようにチームを保たなければならないだろう。

---

感想

エンジニアからマネージャーになったことで、個人としての自分のアウトプット、パフォーマンスの見えにくさによって自己効力感や自己肯定感を失い始めている人に、本書をおすすめしたいと思う。繰り返し出てくるフレーズがあるのだが、これがこの本で一番伝えたいこと、覚えて帰ってもらいたいことなのだろうと思う。

マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット

とはいえ、このことを頭で理解していても、実際に心で納得できるほどになるには精神的な成熟が必要だと思うし、このことに悩んでいる人は実際に周りでもたくさん見ている。

僕個人はこのことには悩んでいないが、それはそもそもマネージャーじゃなかったとしても、そんじょそこらのエンジニアでは個人で生み出せる価値なんて大したものじゃないと思っているし、結局チームとして価値を出せるかどうかだけが拠り所だと割り切っているからかもしれない。なので、マネージャーをやり始めて日は浅いがこの方程式はしっくり来ている。それがうまく言語化されていて腑に落ちた本だった。

コンウェイの法則の反転現象

発見したつもりだが、すでに周知のことかもしれない。が、少なくとも私には知られていなかった。全文はScrapboxに。

scrapbox.io

TL;DR

システムの構造を変更するほうが組織の構造を変更するよりも困難である場合、組織の構造はむしろシステムの構造から優越的に影響を受ける

• 「コンウェイの法則の反転現象」と呼ぶものについて
• システムの構造と組織の構造がミスマッチしたとき、システムの構造を変化することが容易でなければ、組織の構造のほうが適応してしまう
• システム開発能力の養成が不十分なまま内製化を進める組織においては、この反転現象が起こりやすい
• また、ソフトウェア開発現場のアジャイル化はこの現象をさらに促進するだろう
  • アジャイルな組織とは変更容易性の高い組織であるため、相対的に必然的に組織の構造のほうが適応しやすい
• この現象によって、逆コンウェイ戦略を狙ってシステム構造の改善をめがけた組織構造の再編も、結局現状のシステムに引っ張られて元に戻ろうとする

改訂版『事業をエンジニアリングする技術者たち』を読んだ

先日読んだ『Engineers in VOYAGE - 事業をエンジニアリングする技術者たち』の改訂改題版である 『事業をエンジニアリングする技術者たち』 が8月8日に発売された。

事業をエンジニアリングする技術者たち ― フルサイクル開発者がつくるCARTAの現場

lacolaco.hatenablog.com

初版から2年が経ち、各章の後日譚が加筆され、さらに新たに2つの章も増えた贅沢な増補版となっている。

初版は興味があって自分で買って読んだのだけど、本書にも登場するZucks CTOの@r_kawaiimuraさんとの縁で改訂版の献本を頂いた。そのお礼を兼ねて、改訂版の見どころを少し紹介できたらと思う。

端的に言えば、初版を読んでない人には変わらずおすすめしたいし、初版を読んだ人にも重ねておすすめできる改訂版だった。

初版インタビューの「それから」

コロナ禍も続くこの2年間は、ほとんどの現場でさまざまな状況の変化に対応せざるを得なかった2年間であり、その適応力を試される2年間だったように思う。『Engineers in VOYAGE』に登場した各現場もそれは同じだったはずだが、改訂版を読んだ率直な印象は「思ったよりあっさりしてるな」というものだった。

これは語られている2年間の変化が薄いというわけではない。改訂版にあたっての加筆なのでそれほどボリュームがあるわけではないのだが、当時の主力メンバーが退職していたり、業界の状況が変わっていたり、リモートワークへの移行による困難など、十分に苦労しそうな変化が語られている。

だが、その語り口がどこか「あっさり」して見えたのは、おそらく彼らの「事業をエンジニアリングする」という基本姿勢からすれば、変化を起こすことも変化が起きることも当たり前だということだろうと思う。だから、この2年の社会情勢の変化も数ある変化のうちのひとつに過ぎないし、これまでどおり試行錯誤しながら適応していけることを疑っていないんだろう。そんな力強さを感じる、風格ある「あっさり」感だった。

追加された新章

この改訂版では新たに2つのインタビューが追加されている。

• テレビCMのDX事業「テレシー」の立ち上げ
• CARTA HOLDINGSへの統合にあたって2社の「基盤システム統合プロジェクト」

ところで、改訂版のまえがきでインタビュアーのtwadaさんはこの本の価値を次のようにまとめている。

...これをさらに短く、「生々しく、これまでの問題解決と、これからの技術者像を一冊で見せてくれる本」とリフレーズしています。これらの価値は、初版である 「Engineers in VOYAGE』 から読者の皆様が読み取っていただいた、本書『事業をエンジニアリングする技術者たち」のエッセンスにほかならないといえるでしょう。

改訂版で新たに追加された2つの章も、まさに 「生々しく、これまでの問題解決と、これからの技術者像を一冊で見せてくれる本」 そのもの、むしろ生々しさをより強めているように感じた。特に「基盤システム統合プロジェクト」は、失敗できないし締切も動かせない重要なプロジェクトを遂行するエピソードだが、読んでるだけで胃が痛くなりそうなくらい生々しかった。

文化もキャラクターも大きく違う2つの会社で、共通のゴールを目指す協力体制をどれだけのスピードで設計・構築できるかということが試されたのだろうと思うし、その点での判断の速さ、的確さ、失敗からのリカバリーの速さが伝わってきた。プロダクト開発の現場だけでなく、バックオフィスやコーポレート部門などを巻き込むエンジニアリングに必要な「腕力」のひとつの形がここに示されているように思う。

2021年から始まった新規事業「テレシー」の立ち上げにまつわるエピソードの章も面白かった。Zucks出身のメンバーから育っていったチームが、Zucksの文化や強みを引き継ぎつつ新たなチームのあり方を作っていく適応の姿を感じられる。

また次の改訂版が楽しみになる本

初版の記憶が新しいうちに改訂版を読んだので、今回は差分だけに注目して読んだが、また数年後に次の改訂版を読みたいと思った。数年後のCARTA HOLDINGS（また会社が変わっているかもしれないが）が事業をエンジニアリングしつづけながらどのように変化していくのかを見届けていきたいファンとしての気持ちもあるし、彼らの変化を刺激として自分ももっと事業をエンジニアリングしなければと気合を入れたい気持ちもある。インタビューするtwadaさんもインタビューに答える社員たちも、編集も出版社も関係者みんなが飽きなければ、これからもシリーズとして続いてほしいと思う。