読了 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
- 1161 words
- 6 min
エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリングを読了しました。 2020年読了本2冊目。
- 組織の乱れはコードの乱れ
- 乱れた組織をメンタリングとチームビルディングで改善していく
- 改善の技術的なアプローチまでまとまっている
読み始めの動機
組織改善のために、この本を改めて読み直した。
概要
システムに関することはエンジニアだけが理解して、エンジニアだけで改善できるというのは勘違いである。
組織に属し、組織が生み出したビジネスで稼いだ金をもとに生活する以上、組織の力学にしたがって、エンジニアのコードも変わってしまう。そこに気づかないでいると、組織は乱れてコードもそれに従い乱れてしまい、バグが頻発したりデリバリーの速度が下がってしまうという事象にまで至ってしまう。
ITが必須の現代において、これは致命的である。
感想
2回目を読んだところ、注目する点がかなり変わっていることがわかった。
特にChapter 5 の技術組織の力学とアーキテクチャは以前読んだときはなるほどわからんという感想だったが、今回はかなり身にしみて近い問題を抱えていることがわかった。
取引コストという考え方がおもしろかったので、取り上げておく。
システム発注者と社外の受注者という関係性で、発注者は安く働いてほしいというモチベーションを持ち、対して受注者は高く金を払ってほしいというモチベーションをもつ。 発注者と受注者でモチベーションは相反するが、社内エンジニアを使えば、その相反した事象から逃れられる。ただ、社内エンジニアの仕事は平準化されないため、他事業部からは変動費のように捉えられ、金額的な売上が算出しづらいエンジニア組織も売上に責任を取るように流れが発生する。そうなると、先の発注者と社外の受注者のような関係性に変化し、取引コストが発生してしまうというのは往々にして起こり得る。今いる組織では、まさにこれが発生している。
また、部署を分割することで横のつながりがなくなり、部署間でも取引コストが発生してしまい、同じ組織内にもかかわらず、利害関係が発生するというつらみのある現状に至ってしまっている。
経営者の判断ミスやエンジニア側のビジネス視点がない点、双方に問題があるため、誰が悪いとかではないが、ここを改善していくメリットを打ち出していく必要がある。固定化されたチームだからこそ出せる、長期的に良好なパフォーマンスが見込める点をうまく経営者にプレゼンしていき、見直しを図っていきたい。
技術は古くなっていくし、未来は見通せないため、古いアーキテクチャが問題になることは多い。現実はすぐにスクラップ・アンド・ビルドという判断はできない。そこを防ぐために腐敗防止層という過激な言葉が定義していたのはおもしろい。これはデザパタのファサードの一種だが、腐敗防止層はキャッチーな単語のため、積極的に使っていきたいｗ
2回読んだところ、1回目と2回目で注目した点がまったく異なる点は興味深い。この本は自分自身、メンターとメンティー（1対1）、チームビルディング（1対多）、組織（多対多）と取り扱う領域がだんだん規模が大きくなっていくが、今回は組織に関しての章が特に参考になった。
逆コンウェイを用いて、組織を改善してアーキテクチャも改善していくという手法を会社で取っていくらしいので、タイミングよく再読して学び直せてよかった。