チームの問題の原因は外側にあることが多いよなぁ。「チームの力で組織を動かす」を読んだ。 - Mitsuyuki.Shiiba

「技術的負債をなんとか減らさなきゃ！」とがんばっているのに、なんかうまくいかないってケースをちょくちょく見る。忙しくて時間が取れないとか、少し改善を進めている間に別の機能追加によってまた負債を抱えてしまうとか。 僕はこの10年ぐらい、どうやったらもっとうまく開発できるかなぁって考えながら過ごしている。よりうまく開発をするためには、開発チームの内側を良くするのはもちろんだけど、それ以上に、開発チーム自体を組織の中でどのように設計するかがとても重要だよなと思っている。 8月25日に発売です！ 最近もそんなことを考えながら過ごしていたところ @mtx2s さんから「チームの力で組織を動かす」をいただいた。明日（8/25）発売です！めちゃ面白かった。結構ボリュームがあるので、最初ザーッと読んで、次に、気になったところを中心に読み込んでいった。図がたくさんあって分かりやすいのも良かった！ 組織やチー

[bufferings]

おもしろかったー！

[zentarou]

"開発がうまくいかないって相談があってサポートに入ると、だいたい人にタスクをアサインしてその進捗をこまかく追いかけている場合が多い。"

[diveintounlimit]

マイクロマネジメントで良いことは起こらんよなぁ。

[soxandcity]

技術的負債という言葉はよく使われるが、ピュアに「技術的」であるケースはあんまりなさそう。組織全体でプロダクトに負債を積み上げているケースがほとんど。

[tk_musik]

個人として兼務うまくいってたなってときは、割り当てに応じて曜日完全に決めたとき。違う曜日は反対側のSlackもなんもみない。反応しちゃうといるんだってなるし。1.0に入らないタスク「責任感」は薄れるがなら1.0アサ

[morimarii]

結局自己管理できずに誰かがマイクロマネジメントしなきゃいけないような奴はチームから外せっていう結論になる気がする

[bouzuya]

アトミック（チームをそれ以上分解不可能な単位にする）という考え方は、弊社の「ペアを既定」にする（個人には割らない）と似たところがあるかも。 https://zenn.dev/doctormate/articles/a907703cdc03f2

[mkusaka]

8月25日発売の『チームの力で組織を動かす』を読後、技術負債削減より組織設計の重要性と“twisted Conway”等のアンチパターンを解説。

[kuwayoshi]

だいたい人にタスクをアサインしてその進捗をこまかく追いかけている場合が多い。そして問題を聞くと「属人化している」とか「レビューに時間がかかる」とかがあがってくる。「それはそうなりますよね」って気持ちに

[uniR]

面白そう

[ultrabox]

せやね