「技術的負債をなんとか減らさなきゃ！」とがんばっているのに、なんかうまくいかないってケースをちょくちょく見る。忙しくて時間が取れないとか、少し改善を進めている間に別の機能追加によってまた負債を抱えてしまうとか。
僕はこの10年ぐらい、どうやったらもっとうまく開発できるかなぁって考えながら過ごしている。よりうまく開発をするためには、開発チームの内側を良くするのはもちろんだけど、それ以上に、開発チーム自体を組織の中でどのように設計するかがとても重要だよなと思っている。
8月25日に発売です！
最近もそんなことを考えながら過ごしていたところ @mtx2s さんから「チームの力で組織を動かす」をいただいた。明日（8/25）発売です！めちゃ面白かった。結構ボリュームがあるので、最初ザーッと読んで、次に、気になったところを中心に読み込んでいった。図がたくさんあって分かりやすいのも良かった！
組織やチームについて考えているエンジニアリングマネージャやテックリードにはぜひ読んでほしい。目の前の問題をなんとかするための対応が別の問題を引き起こしてしまうようなアンチパターンや、じゃあどうすればいいのかという組織設計の原則がまとめられていて、とても参考になる。
技術的負債に日々向き合っているエンジニアのみんなも「あぁ、このアンチパターン分かる！ここから問題が発生しているのかーたしかになー」といろいろ考えさせられて面白いのでぜひどうぞ。
最近は開発が遅い？
「以前はもっと少人数で勢いよく開発が進んでいたのに、今はこれだけの人数がいるのにどうして進みが遅いの？」みたいな声を聞いたりして「以前に少人数で勢いよく開発を進めていたから、今大変なんですよね」という気持ちになったりする。
それは、少人数で勢いよく開発を進めていたことを否定する気持ちではない。その時代があったから今があると思っている。ただ、そこで意識的に・無意識的に蓄積された技術的負債と、プロダクトや組織の拡大が絡まって、どんどん開発の難易度は上がっていく。
だから、その難しさに対応するための組織設計がとても重要になってくる。
「組織設計のひずみによって生じた問題は現場だけでは解決できない」
最初の方に出てくる言葉。これ好き。
組織設計のひずみによって生じた問題は現場だけでは解決できない。
そうそうそれだよなーという気持ち。エンジニアが対応しないといけなくなる場所って、いろいろなことの結果が表にでてくる場所だよなと思っている。その原因はコードよりももっと前にあったりする。
目の前に現れた問題には対処するんだけど、それと同時に、その発生源をなんとかしたい。じゃないと、改善してもまた発生してしまうから。その発生源はチームの外側の組織設計のひずみからきていることが多い。
でも、どうしてそんなひずみができてしまうんだろう？
本書の前半ではアンチパターンが紹介されている。組織設計のひずみだ。
開発をするときって、やりたいことに対して人は全然足りていない。人が足りていて余裕を持って開発できるんだったらひずみも生まれにくいだろう。でも、現実を見てみてると全然足りていない。そんな中で、なんとか前に進まないといけない。じゃないと会社は競争に負けてつぶれてしまう。
じゃあどうやって開発を進めようか、というところにひずみが生じる。
足りていない状況でなんとかしようとするので、どこかにひずみが生じるのは避けられない。兼務1によって時間が細切れになってしまう関わり方だったり、特定の人を頼るしかなくて知識がその人に偏ってしまう関わり方だったり。
アンチパターンの出口を見据える
僕は、アンチパターンは踏んでも構わないと思っている。いま目の前で何か困っていることがあって、その問題をなんとかするために例えば「4-5 ねじれコンウェイ2」をやるしかないならやるしかないのだ（それはそう）。
問題は「それが最終的な状態だ」と思ってしまうこと。アンチパターンは何かの問題を解決はするものの、チームに別の難しい問題を持ち込んでしまう。だから「アンチパターンは通過点であるべき」で、踏み込むときには同時にその先に出口を見ておく必要がある。
今はアンチパターンを踏んで前に進むしかないからそうするんだけど、ずっとこのままではなく、少し先で「ねじれ」がなくなっていくように組織を設計していくぞー！ということが大切。
本書を読むことでまず「アンチパターンによって引き起こされる問題」が分かる。それが分かっていれば、前もってその問題をやわらげるための手が打てる。そして本書にはアンチパターンによる問題をやわらげるためのヒントも書かれている。とてもいい。
「組織の力でチームを動かす」ではないのがいい
さて、出口を見据えるとは言っても、どこを目指したらいいんだろう？と思うかもしれない。そんな疑問にも本書は答えてくれる。本書の後半では組織設計の原則とガイドラインが紹介されている。
組織設計について書かれた本なので「組織をうまく設計したらチームが動き出すよ！」という流れも考えられるんだけど、本書はそうなっていない。あくまでも「チーム」が中心にあって、チームを中心とした組織設計になっている。それがいい。
チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計
誰か偉い人がトップダウンで「うまくいくように組織を設計しておいたからあとはみんな頑張って！」みたいなものではなく、現場を見ているエンジニアリングマネージャを中心とした開発チームを主役にして、そこがうまくいくことで組織全体が開発をうまくまわせるようになる、という視点なのがいい。
「5-2. アトミック」
これとても好き。本書に書かれていることの中で一番好きなのを選んで、って言われたらこれだな。
組織内でのチームをそれ以上分解が不可能な「個」として扱うことで、自己管理型チームを育て、それを単位とするチーム指向の組織を実現します
開発がうまくいかないって相談があってサポートに入ると、だいたい人にタスクをアサインしてその進捗をこまかく追いかけている場合が多い。そして問題を聞くと「属人化している」とか「レビューに時間がかかる」とかがあがってくる。「それはそうなりますよね」って気持ちになる。そういうときは、人じゃなくてチームにタスクをアサインするようにサポートする。
チームがアトミックな単位ってのはいいなぁと思った。次に同じような状況のチームをサポートするときがあったら、ここを読み直そうと思う。
考え続ける・変化に適応し続ける
アトミック以外にも、いろいろとなるほどなー面白いなーと思うことが紹介されている。どれも、著者のさまざまな経験や深い知識を元に書かれていてとても参考になる。また、その経験が海外の全然違う文化圏の話ではなく日本の開発チームの話だというのもいい。
アンチパターンだからやってはいけないというわけではないし、本書に書かれているからそれに従わないといけないということもない。これをやれば成功する！みたいな正解はなくて、すべてはトレードオフで、状況に応じてやり方は変わってくるし、その状況も刻々と変化する。
だから、本書で得た知識を参考にして、自分のいる状況をもとに考え続けて、変化に適応し続けていかなきゃなと思った。
面白かった
目の前の技術的負債や開発の問題の根本原因を理解し、それに対してどのような手を打てばいいのか、どういう指針でチーム開発を進めていけばいいのかについて、多くのヒントを得ることができる一冊でした。
組織やチームの問題で悩んでいるエンジニアリングマネージャやテックリード、技術的負債と日々格闘しているエンジニアの方々にぜひ読んでいただきたいです。
@mtx2s さん、素晴らしい本をありがとうございました！
8月25日発売予定の「チームの力で組織を動かす」 @mtx2s さん著
— mitz (@bufferings) 2025年8月8日
をいただきましたー！読むの楽しみー！わーわー！ pic.twitter.com/H2iEZWJRmm
