余白

https://blog.lacolaco.net/ に移転しました

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

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日に発売された。

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さんもインタビューに答える社員たちも、編集も出版社も関係者みんなが飽きなければ、これからもシリーズとして続いてほしいと思う。

『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を読んだ

[asin:B08GSQ4BL3:detail]

シビレたフレーズ

放っておかない力

「技術的負債の返済に必要な腕力」について、すずけんさんとtwadaさんの一節。

す:腕力っていったい何でしょうね。

― 関係ないところに手を出す力、放っておかない力、というのがまずあると思います。 重要だけど緊急でないから誰も手をつけないところをゴリゴリ巻き取っていくためには、カッとなる力、放っておかない力が必要です。

フルサイクル開発者の仕事はビジネス

Zucksのフルサイクル開発思想について、河村さんとtwadaさんの一節。

― これだけ多様な技術が使われているシステムでフルサイクル開発者であることが求められるとしたら、場合によっては「言語を学ぶ」ところからスタートすることもありそうです。

河:ある言語が好きで、ほかの言語は絶対に使いたくないといった人には、耐えられないかもしれません。 フルサイクル開発者の仕事はコードを書くことだけでなく、ビジネスなんですよ。

業務として向かい合うシステムへの誇り

レガシーな大規模システムをゼロから作り直すことに決めるまでの過程について、ねこやさんとtwadaさんの一節。

ね:...これがもし自分たちで作ったシステムであれば、どんなに足をすくわれるような状態であったとしても、腹をくくって本気で対処できます。でも自分たちが作ったわけでもない、データベースの構造を含めて問題が多いシステムに立ち向かい続けることには、エンジニアとして辛いものがありました。

― 開発チーム本来の実力が発揮しにくい状態だったのですね

ね:その意味で、自分たちが業務として向かい合っているシステムに、開発者が誰も誇りを持てていなかったと思います。 この状態が長く続けば開発チームとして回していくのが難しくなるという危機感みたいなものがありました。

ギバーのジレンマ

他者に対して惜しみなく何かを与えるギバーがもてはやされる昨今、しかし与える者はそれを受け取る者がいてはじめて成り立つ。

自身がギバーでありたいと望むならば、他者がそれを受け取ってくれることを望まずにはいられない。 そのとき、利他的でありたいという欲望は、他者の利己的な姿勢を求めるという意味において利己的な欲望として現れる。

多くのビジネス書などでは、成功する確率が高いのはテイカーよりもギバーであると言われている。 そのような状況でみずからテイカーになろうという者のほうがむしろ自己犠牲的とも言えるのではないだろうか?

つまり、利他的であろうとすればするほど他者の自己犠牲を求める利己的な姿勢として現れてくるのではないだろうか?

ヒーローであるためには世界に悪がいなければならないヒーローのジレンマのように、ギバーでいるためにはテイカーにいてもらわなければならないギバーのジレンマがそこにあるのではないか。