発見したつもりだが、すでに周知のことかもしれない。が、少なくとも私には知られていなかった。全文はScrapboxに。
TL;DR
システムの構造を変更するほうが組織の構造を変更するよりも困難である場合、組織の構造はむしろシステムの構造から優越的に影響を受ける
発見したつもりだが、すでに周知のことかもしれない。が、少なくとも私には知られていなかった。全文はScrapboxに。
システムの構造を変更するほうが組織の構造を変更するよりも困難である場合、組織の構造はむしろシステムの構造から優越的に影響を受ける
先日読んだ『Engineers in VOYAGE - 事業をエンジニアリングする技術者たち』の改訂改題版である 『事業をエンジニアリングする技術者たち』 が8月8日に発売された。
初版から2年が経ち、各章の後日譚が加筆され、さらに新たに2つの章も増えた贅沢な増補版となっている。
初版は興味があって自分で買って読んだのだけど、本書にも登場するZucks CTOの@r_kawaiimuraさんとの縁で改訂版の献本を頂いた。そのお礼を兼ねて、改訂版の見どころを少し紹介できたらと思う。
端的に言えば、初版を読んでない人には変わらずおすすめしたいし、初版を読んだ人にも重ねておすすめできる改訂版だった。
コロナ禍も続くこの2年間は、ほとんどの現場でさまざまな状況の変化に対応せざるを得なかった2年間であり、その適応力を試される2年間だったように思う。『Engineers in VOYAGE』に登場した各現場もそれは同じだったはずだが、改訂版を読んだ率直な印象は「思ったよりあっさりしてるな」というものだった。
これは語られている2年間の変化が薄いというわけではない。改訂版にあたっての加筆なのでそれほどボリュームがあるわけではないのだが、当時の主力メンバーが退職していたり、業界の状況が変わっていたり、リモートワークへの移行による困難など、十分に苦労しそうな変化が語られている。
だが、その語り口がどこか「あっさり」して見えたのは、おそらく彼らの「事業をエンジニアリングする」という基本姿勢からすれば、変化を起こすことも変化が起きることも当たり前だということだろうと思う。だから、この2年の社会情勢の変化も数ある変化のうちのひとつに過ぎないし、これまでどおり試行錯誤しながら適応していけることを疑っていないんだろう。そんな力強さを感じる、風格ある「あっさり」感だった。
この改訂版では新たに2つのインタビューが追加されている。
ところで、改訂版のまえがきでインタビュアーのtwadaさんはこの本の価値を次のようにまとめている。
...これをさらに短く、「生々しく、これまでの問題解決と、これからの技術者像を一冊で見せてくれる本」とリフレーズしています。これらの価値は、初版である 「Engineers in VOYAGE』 から読者の皆様が読み取っていただいた、本書『事業をエンジニアリングする技術者たち」のエッセンスにほかならないといえるでしょう。
改訂版で新たに追加された2つの章も、まさに 「生々しく、これまでの問題解決と、これからの技術者像を一冊で見せてくれる本」 そのもの、むしろ生々しさをより強めているように感じた。特に「基盤システム統合プロジェクト」は、失敗できないし締切も動かせない重要なプロジェクトを遂行するエピソードだが、読んでるだけで胃が痛くなりそうなくらい生々しかった。
文化もキャラクターも大きく違う2つの会社で、共通のゴールを目指す協力体制をどれだけのスピードで設計・構築できるかということが試されたのだろうと思うし、その点での判断の速さ、的確さ、失敗からのリカバリーの速さが伝わってきた。プロダクト開発の現場だけでなく、バックオフィスやコーポレート部門などを巻き込むエンジニアリングに必要な「腕力」のひとつの形がここに示されているように思う。
2021年から始まった新規事業「テレシー」の立ち上げにまつわるエピソードの章も面白かった。Zucks出身のメンバーから育っていったチームが、Zucksの文化や強みを引き継ぎつつ新たなチームのあり方を作っていく適応の姿を感じられる。
初版の記憶が新しいうちに改訂版を読んだので、今回は差分だけに注目して読んだが、また数年後に次の改訂版を読みたいと思った。数年後のCARTA HOLDINGS(また会社が変わっているかもしれないが)が事業をエンジニアリングしつづけながらどのように変化していくのかを見届けていきたいファンとしての気持ちもあるし、彼らの変化を刺激として自分ももっと事業をエンジニアリングしなければと気合を入れたい気持ちもある。インタビューするtwadaさんもインタビューに答える社員たちも、編集も出版社も関係者みんなが飽きなければ、これからもシリーズとして続いてほしいと思う。
「技術的負債の返済に必要な腕力」について、すずけんさんとtwadaさんの一節。
す:腕力っていったい何でしょうね。
― 関係ないところに手を出す力、放っておかない力、というのがまずあると思います。 重要だけど緊急でないから誰も手をつけないところをゴリゴリ巻き取っていくためには、カッとなる力、放っておかない力が必要です。
Zucksのフルサイクル開発思想について、河村さんとtwadaさんの一節。
― これだけ多様な技術が使われているシステムでフルサイクル開発者であることが求められるとしたら、場合によっては「言語を学ぶ」ところからスタートすることもありそうです。
河:ある言語が好きで、ほかの言語は絶対に使いたくないといった人には、耐えられないかもしれません。 フルサイクル開発者の仕事はコードを書くことだけでなく、ビジネスなんですよ。
レガシーな大規模システムをゼロから作り直すことに決めるまでの過程について、ねこやさんとtwadaさんの一節。
ね:...これがもし自分たちで作ったシステムであれば、どんなに足をすくわれるような状態であったとしても、腹をくくって本気で対処できます。でも自分たちが作ったわけでもない、データベースの構造を含めて問題が多いシステムに立ち向かい続けることには、エンジニアとして辛いものがありました。
― 開発チーム本来の実力が発揮しにくい状態だったのですね
ね:その意味で、自分たちが業務として向かい合っているシステムに、開発者が誰も誇りを持てていなかったと思います。 この状態が長く続けば開発チームとして回していくのが難しくなるという危機感みたいなものがありました。
他者に対して惜しみなく何かを与えるギバーがもてはやされる昨今、しかし与える者はそれを受け取る者がいてはじめて成り立つ。
自身がギバーでありたいと望むならば、他者がそれを受け取ってくれることを望まずにはいられない。 そのとき、利他的でありたいという欲望は、他者の利己的な姿勢を求めるという意味において利己的な欲望として現れる。
多くのビジネス書などでは、成功する確率が高いのはテイカーよりもギバーであると言われている。 そのような状況でみずからテイカーになろうという者のほうがむしろ自己犠牲的とも言えるのではないだろうか?
つまり、利他的であろうとすればするほど他者の自己犠牲を求める利己的な姿勢として現れてくるのではないだろうか?
ヒーローであるためには世界に悪がいなければならないヒーローのジレンマのように、ギバーでいるためにはテイカーにいてもらわなければならないギバーのジレンマがそこにあるのではないか。
2022 4月〜6月に読んだ本・読み始めた本
NOISEは積み続けている。『省察』を読み終わるとようやく17世紀哲学に区切りをつけて18世紀へ迎えるので楽しみ。