エンジニアリング組織論への招待を読んでみて結構納得感のある内容だったので、忘れる前に自分的に響いたところなど書き留めておく。あくまで主観を書くので、本の内容など詳しく知りたい方は、実際の書籍を参照してください。

はじめに

問題解決のためには、コードだけでなく、人々の思考・組織・ビジネスの「構造」こそリファクタリングしなければいけないと考えるようになりました。それこそがエンジニアリングの本質なのだと気がついたのです。

いきなり本質をつく言葉。
最近、チームを俯瞰して見る機会があるせいか、この言葉がものすごく「真」だなと感じる今日このごろ。

Chapter 1. 思考のリファクタリング

人間にとって、本質的に「わからないこと」は２つしかありません。それは、「未来」と「他人」です。

これはよく聞く言葉だけど、改めて。レガシーシステムに向き合っていると、これに加えて、「過去」もわからないことが多く、これが結構厄介だなと感じる。「過去」は本質的には「わからないこと」ではないはずなので、「わからないこと」にならないように作っていくことが大事。

このような局所最適解（システム全体の一部分において最適な答え）が、全体にとって最適な答えかどうかの判断がつかないために、局所最適解同士が争うことになります。

これも、よく出くわすなーって感じ。みんな大きく見ると同じ方向に向かいたいんだけど、いろいろ大事にしている部分が違ったりして、それぞれの「正解」がぶつかって答えがでない感じ。あとは、何が「最適」かってのも判断が難しいところ。。ただ、自分が「正しい」と思っていることが実は局所最適解で、全体にとっては「正解」ではないのかもと心の片隅においておくのが大事なのかも。

同じ目的をもったチームメンバーが、局所最適な言い争いを発生させることなく全体最適に向かうことができるように、一次元上の観点から問題を捉えて、システムの全体像を把握していくことで、対立から発展的な議論へと視野が拡大することがシステム思考のメリット

確かに一歩引いた目線で見てみると、現場で実際の人たちから直接見えにくいところが見るようになったり、あるいは、複合的にいろいろ見なければいけないことに気づいたりすることがある。「視座」を変えるってのが大事なのかも。

自分にとっての正解が全体にとっての正解にならない

正論。その辺に貼っておきたい。自分も耳がいたい。

Chapter 3. アジャイルなチームの原理

複雑性の解消よりも、複雑性の管理に時間を使い、完了しないプロジェクトが増えていった

まさにSIerにいた頃のプロジェクト。プロジェクト自体が複雑だったり、システム自体が複雑であることは「しょうがない」とされ、その複雑性の解消ではなく、その複雑性と上手に付き合うことを選んでいる。絶対に間違いということではないと思うけど、「もっとシンプルに」という方向性ではなく、「上手にプロジェクトマネジメント」をという方向にどんどん流れて、「いいものを作ろう」という方向ではないような気がする。

(要約) ソフトウェア開発が「発注者」と「受注者」に分断
発注者は納期の絶対視や無自覚な追加要求
受注者は計画と契約で責任分界点を作る
→受注者はビジネスの成功率減少
→発注者は縛りの多いつまらない仕事に

あぁぁぁ、すごいうまく書かれている。。SIer時代はまさにこんな感じ。Web系企業でも、事業側と開発側が分断されていたりするとこんな感じだなと思うことも多々ある。だからプロダクトオーナーとして、みんな同じチームでやろうよってのは当然の流れなのかも。

必要なことは、外でうまくいっている何かを探し出すことではなく、しっかりと自分たちを取り巻く状況を観察すること。そして、何かの流行りのかっこよさを教条的に取り入れるのでなく、今何をすべきかをしっかりと周囲と対話していくことです。

かっこいいからやってみたいと思うのもエンジニアの性だとも思う。ただ、今何が必要かという視点が欠けると、ただの技術的な負債になる可能性も高い。あとはどう導入するかをチームで決めていくというのが大事。

Chapter 4. 学習するチームと不確実性マネジメント

「間に合うか、間に合わないか」ではなく、「スケジュール予測が収束していくかどうか」を管理するようにしなくてはならない

なるほどー。楽観的な見積もりと悲観的な見積もりを定期的にやる感じかな。

開発部門には納期絶対主義の管理者が重宝されるようになり、「何を作るべきか」という視点をどんどんと失っていく。本来、ソフトウェアプロダクトを提供する事業において「その日」にリリースされてないといけないという制約は、意図的に作らない限り生まれない

プロジェクトは大事。だけど、プロダクトはもっと大事。ということかな。

あるときはチームに入り込み、あるときはプロダクトオーナーを助け、あるときはチームの1人1人をメンタリングするというのが、スクラムマスターの役割だといえます。

昔、スクラムマスターを週ごとにまわしてやってて、基本デイリーハドルや振り返りのファシリテーターって感じでやってたけど、本当(?)のスクラムマスターの役割って実はもっと広いし、誰もができる役割ではそもそもないのか。

Chapter 5. 技術組織の力学とアーキテクチャ

ソフトウェア開発上の多くの問題は、技術的というより社会学的なものである

これも最近よく実感する。他のチームで困っていることの話を聞くと、技術的な課題の話と思いきや、実はチーム自体の問題が根本であったりすることがある。やはりチームで開発している以上、「人間関係」とシステム開発も切っても切り離せない。

開発者がその時点ですべきことは、「今必要な機能をシンプルに作る」ことです。将来的にシンプルであり続けると予測し、アーキテクチャを組むことは、それ自体が技術的負債の材料となる複雑性をシステムに組み込んでしまうことになります

実際現場でこれをよく見かける。そんな要求が今無いのに、いろんな場合に対応できるように、複雑な作りになってるやつ。今の要求を素で書いてみたときにイケテナイねってなって、リファクタリングとしてそういう仕組みになるならありだと思うんだけど、最初からやりすぎると、「The 技術的負債」になる。

まとめ

マネージャー向けのマネージメント論かと思いきや、実際の現場でよく起こる現象をうまく言語化してくれていたりして、いちエンジニアにとっても結構ためになる本だった。