職能別チームがなぜダメで、職能横断がなぜよいか
はじめに
- 数年程度の経験則と一般論に基づくポエム
- エンジニアなのでエンジニア組織の話
職能別チームと職能横断チームの違い
職能別チームは、web開発で言えば、フロントエンド班・バックエンド班、SRE…と別れている状態。 職能横断チームは、そのチーム内で、そのチームのミッションを達成するための全機能が網羅されている状態（フロント・バックエンド・インフラ等 ）。
職能別チームの問題点
コンウェイの法則
コンウェイの法則では、システム設計は組織設計を反映したものになるとされる。フロント人材はフロントのこと、バックエンド人材はバックエンドのことだけを考えるので、それらをつなぐインターフェース、web開発で言えばWebAPIがシステムとして理想的な形になることはない、と思う（DBの鏡写しのようなCRUDのAPIが出来るだろう）。
分業とコミュニケーションコスト
過度に分業されているがために、少しでも自身の領域を超えるタスクは別チーム・別メンバーをアサインするようになる。フロント・バックエンド・インフラ、一気通貫でやれば1時間で終わるものを、わざわざタスクを切り・認識合わせて・一回じゃスムーズに出来なくて…。このようにスピードが低下していく。 これがコミュニケーションコスト、と言うと「そんなこと言わないでわかるようになるまで仲良くやろうぜ」みたいな雰囲気を出されることがあるが、そういうことを言いたいのではない。脳みそが2つでも中身を共有出来ないのだから数が増えたら破綻するだろ、なるべくひとりで多くの部分を出来るべきだと、そういうこと。
職能横断チーム
一定のミッションに対して、だれでも複数の工程を担当できる・流動的に担当工程を移れる。これはいわゆる多能工化であり、一般的によいとされている。私も理想形だと思っているが、そのうえで問題点をいくつか。
ひとつの領域を深めることは難しい
各メンバーが少なくとも「広く浅く」やっていないと、この体制では動けない（もちろん、広く深くやっていて良いし、たま～に実在する）。ただし、職能別チームだからと言って必ずしもその領域を深堀しているかというと、そうではないだろう（大概は職能別でドライブしているチームのほうが、各分野の能力も高いだろう）。
常に知らないことを学ぶ必要がある
対象とする領域が広いので、ネタ切れがない。ついていくのは大変。いわゆるラーニングアニマルみたいな人間が向いているだろう。
そんな人は都合よくいない
そういういわゆる「ソフトウェアエンジニア（≒フルスタックエンジニア）」はとてもレア
終わりに
とはいえ優秀な人材なら職能別でも十分機能するだろう。一方で、職能横断チームは理想形である一方、メンバーに最低限の能力がないと「狭く浅い」だけなので、チームにならない。結局は人材がだいじってこと。
