Labo288

プログラミングのこと、GISのこと、パソコンのこと、趣味のこと

職能別チームがなぜダメで、職能横断がなぜよいか

はじめに

  • 数年程度の経験則と一般論に基づくポエム
  • エンジニアなのでエンジニア組織の話

職能別チームと職能横断チームの違い

職能別チームは、web開発で言えば、フロントエンド班・バックエンド班、SRE…と別れている状態。 職能横断チームは、そのチーム内で、そのチームのミッションを達成するための全機能が網羅されている状態(フロント・バックエンド・インフラ等 )。

職能別チームの問題点

コンウェイの法則

コンウェイの法則では、システム設計は組織設計を反映したものになるとされる。フロント人材はフロントのこと、バックエンド人材はバックエンドのことだけを考えるので、それらをつなぐインターフェース、web開発で言えばWebAPIがシステムとして理想的な形になることはない、と思う(DBの鏡写しのようなCRUDのAPIが出来るだろう)。

分業とコミュニケーションコスト

過度に分業されているがために、少しでも自身の領域を超えるタスクは別チーム・別メンバーをアサインするようになる。フロント・バックエンド・インフラ、一気通貫でやれば1時間で終わるものを、わざわざタスクを切り・認識合わせて・一回じゃスムーズに出来なくて…。このようにスピードが低下していく。 これがコミュニケーションコスト、と言うと「そんなこと言わないでわかるようになるまで仲良くやろうぜ」みたいな雰囲気を出されることがあるが、そういうことを言いたいのではない。脳みそが2つでも中身を共有出来ないのだから数が増えたら破綻するだろ、なるべくひとりで多くの部分を出来るべきだと、そういうこと。

職能横断チーム

一定のミッションに対して、だれでも複数の工程を担当できる・流動的に担当工程を移れる。これはいわゆる多能工化であり、一般的によいとされている。私も理想形だと思っているが、そのうえで問題点をいくつか。

ひとつの領域を深めることは難しい

各メンバーが少なくとも「広く浅く」やっていないと、この体制では動けない(もちろん、広く深くやっていて良いし、たま~に実在する)。ただし、職能別チームだからと言って必ずしもその領域を深堀しているかというと、そうではないだろう(大概は職能別でドライブしているチームのほうが、各分野の能力も高いだろう)。

常に知らないことを学ぶ必要がある

対象とする領域が広いので、ネタ切れがない。ついていくのは大変。いわゆるラーニングアニマルみたいな人間が向いているだろう。

そんな人は都合よくいない

そういういわゆる「ソフトウェアエンジニア(≒フルスタックエンジニア)」はとてもレア

終わりに

とはいえ優秀な人材なら職能別でも十分機能するだろう。一方で、職能横断チームは理想形である一方、メンバーに最低限の能力がないと「狭く浅い」だけなので、チームにならない。結局は人材がだいじってこと。

エンジニアのキャリアと組織の技術力に関するメモ

日頃悩んでいることを言語化しておくメモ、まだ論理的にまとまっていない。

エンジニアのキャリア

(要出典)海外で働いたことはないので一般論だが、日本ではソフトウェアエンジニアとして有能だとマネージャーになることが多いらしい。Individual Contributorに相当するキャリアパスが整備されていないというわけ。全くICで居られないという意味ではなく、(語弊を恐れず言えば)出世を諦めれば、ICで居続けることは可能ではあるはず。つまりエンジニアの上位職としてマネージャーがいるのである(マネージャー>エンジニア)。つまり、エンジニアとして優秀だとコードに関わらなくなる職位になりがち、というわけ。

参考

satoshi.blogs.com

組織の機能の低下

現在の職位で成果を出したら別の職位に異動させる…、この状況下では組織内のそれぞれの「機能」が低下していく。コードが得意なエンジニアをコードを書かない状況に置けば、組織の「コードを書く能力」の平均値が下がることは自明である(これはコードに限らないが)。

こういった状況はピーターの法則で説明されている。

ja.wikipedia.org

終わり

  • ピーターの法則で説かれているように、ある職位で有能な人材が無能となってしまう職位に配置されてしまうと、果たしてどれだけモチベーションは維持出来るだろうか。
  • ピーターの法則はもちろん国外で提唱されたものだし、マネージャーになりたてのエンジニア向けの本である「エンジニアリングマネージャーのしごと」は海外で執筆されたものなので、日本に限った問題ではないかもしれない。なので逆に、日本は〜だから仕方ない、とも言えない。

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 | James Stanier, 吉羽 龍太郎, 永瀬 美穂, 原田 騎郎, 竹葉 美沙 |本 | 通販 | Amazon

それは本当に「心理的安全性」があるのだろうか?

はじめに

Googleが重要性を説いたことで広まった「心理的安全性」という言葉。

 心理的安全性とは、アイデア、質問、懸念、または間違いを率直に述べても、罰せられたり屈辱を与えられたりしないという信念です。チームでは、チームメンバーが他のチームメンバーに恥をかかずにリスクを冒すことができると信じていることを指します.心理的に安全なチームでは、チーム メンバーは受け入れられ、尊重されていると感じます。 - Wikipediaより引用

私見だが、心理的安全性は「パワハラをしない」だとか「ネガティブなことを言わない」だとか「空気を読む」ような意味合いで捉えられていることが多いように思う(パワハラ心理的安全性が低めるのはそうだが、そもそも存在自体が論外である)。ここでは頭の整理を兼ねて、自分が考える心理的安全性について述べる。

本文

心理的安全性」が説いている最も重要なことは「他人にとっては当たり前だったり、ネガティブと思われそうな指摘も遠慮なくできる」、つまり間違っていそうなことを間違っていると指摘できることだと思う。「The elephant in the room」という有名な言葉がある。会議室にゾウがいるのに誰もそれにツッコミを入れない(=見て見ぬふり)状況を示すイディオムである。これは心理的安全性が低い状況をわかりやすく表現している。明らかにおかしな、正しくない状況に対し、指摘を誰もしないわけである。

心理的安全性の文脈では、心理的安全性が低い状況では、以下の4つが発生するとされている(一般論ではあるが、参考サイト)。

  1. 無知と思われる不安
  2. 無能だと思われる不安
  3. 邪魔をしていると思われる不安
  4. ネガティブだと思われる不安

「会議室に巨大なゾウがいる」という明らかな問題を指摘出来ない状況を、この4点で説明してみる。

  1. 実は会議室にゾウがいるのは他の人にとっては当たり前のことかもしれない
  2. 会議室にゾウがいる理由は他の人にとっては考えたらすぐわかることかもしれない
  3. 誰も指摘しない=どうでも良い話だとしたら、会議の進行を妨げて鬱陶しがられるかもしれない
  4. 誰も指摘しない=自分だけがネガティブな発言をしていると、鬱陶しがられるかもしれない

単に「仲良しグループ」であれば「心理的安全性」が高まるわけではないことは明らかである。 (これまでの議論もそうだが)web上には心理的安全性に関するエントリは多数あるため、そのうえで私見として、心理的安全性を高めるために必要なことをいくつか挙げてみる。

  1. お互いが、役職・年齢・性別に関わらず対等であること
    1. これは心理的安全性を考える以前の問題であるが、相手が誰でもリスペクトが必要である
  2. 「正しいこと(正しくないこと)を正しい(正しくない)と言うこと」が常に善であることについて考えが一致していること
    1. そういう「雰囲気」をなんとなく作る…ではなく、明示的に意思を表明すべきである
    2. そこに人格は存在せず、「正しさ」「正しくなさ」だけが重要である
  3. 正しいことを指摘した人が損をしないこと
    1. 言い出しっぺの法則(=じゃあ君がやっといて)」は心理的安全性を低める最高の手法である(問題を指摘した人の仕事が増えるなら、誰が指摘し続けるだろうか?)
  4. 正しいことを指摘したら、正しい方向へ向かうこと
    1. 発言を許容するだけで何も変化しなければ、つまり無意味ならばリスクをとって指摘する人はいなくなる(=心理的安全性が低まる)

終わりに

心理的安全性」の議論は優秀な人材ばかりのGoogleだから通用する…と言われていることもあるし、私もそう考えたことがないわけではない。しかし上記の議論によれば、心理的安全性が高いことはメンバーが著しく優秀な場合だけ恩恵があるわけではないことは明らかである。間違っていることを気兼ねなく指摘出来ることは、どんな環境であっても望ましいからである。ただし何が正しいかを、正しく判別する能力・意欲は最低限必要である。「仲の良さ」だけが心理的安全性を高めるわけではなく、「正しいことを正しいということが善である」ことを組織で理解する必要がある。