チームトポロジー

目的

担当業界を増やした。人も足りているはずだ。それなのに、どの業界も浅い理解のままになっている。

人数の問題ではなく、一人が抱えられる範囲を超えている。本書を読む目的は、その上限を前提に組織を設計することにある。

論点1 人数ではなく、抱えられる範囲で決める

本書が設計の軸に置くのは、チームが頭に入れておける範囲だ。超えるとどれも中途半端にしか見られない。

営業でも同じことが起きる。担当業界を増やし続けると、どの業界の事情にも詳しくない状態になる。

いちこ

人を増やせば解決しませんか。

シュン

人数を増やしても、一人が持つ範囲が広いままだと変わらないんだ。範囲のほうを狭めないとね。

論点2 「連携する」では曖昧

• 一緒にやる … 期間を区切って並走する。立ち上げ期
• 任せて受け取る … 仕様だけ決めて渡す。安定期
• 支援する … 相手が自立できるまで助ける。移行期

常にこの形、ではなく期によって切り替える。営業と開発の関係も、案件の段階で型が変わる。

論点3 組織の形が、そのまま成果物の形になる

3チームに分かれていれば、できあがるものも3つに分かれた作りになる。

顧客体験が分断されているなら、組織が分断されている可能性がある。営業・CS・サポートの分け方も、顧客からはそのまま見えている。

いちこ

社内の分け方は、お客様には関係ないと思っていました。

シュン

関係ないはずなんだけどね。たらい回しになる瞬間に、分け方がそのまま見えるんだ。

この本の限界と、次に読む本

開発組織が前提で、用語も開発寄り。営業組織に当てはめるには読み替えが要る。開発組織の論理なら エンジニアリング組織論への招待、管理職の実務なら エンジニアリングマネージャーのしごと が隣に並ぶ。