ソフトウェアエンジニアのチームがサイロ化する問題

ソフトウェア開発は当たり前のようにプログラミングだけでなりたっているわけではない。

そのため、エンジニアがプログラムを書くこと以外の仕事をすることも多分にあるのだが、そのときにちょくちょく「できる人がコードを書く時間をうまくとれない」ことが課題としてあがってくることがある。

自分が思うに、これはある程度人数が増えたチームになると発生する。人数が少ないと、どちらにしろ誰ががすぐにやらないといけないため「効率どうこうよりもガンガン行くんだよ」っていう思考だったり、あと、専門性が高い人よりもマルチに活躍できる人が揃ってることが多いために、そういう課題はあまり議題にならない。

一方で、ある程度人が増えてくと、一つ一つの業務や機能の解像度が上がり、マルチにこなす人よりも専門性が高い人の方が重宝されるようになる。

この活躍する人のイメージが変わるようなタイミングで「できる人がコードを書く時間をうまく取れない」ことを課題として認識するケースがでてくる。

このときに安易に「エンジニアからプログラムを書くことに集中しよう」という解決策をとると、後々まずいことになる。

徐々にエンジニアチームだけがプロダクト開発の本流から分断され、サイロ化してしまうからだ。

さらに、このときにエンジニアがコードを書くことを優先して、施策や仕様やデザインが決まる場所から姿を消すともう取り返しがつかない。

エンジニアチームはただ言われたものを作るだけの組織になってしまう。これではほぼほぼ外注するのと変わりがなく、内製で開発するメリットが霧散してしまうことさえある。

なので、こうなってはいけない。

そもそも「できる人がコードを書く時間をうまく取れない」ことは本当に課題なんだろうか。

ケースバイケースだけど、それは課題ではないことが多い。なぜなら、エンジニアはコードを書くことだけが仕事じゃないから。データを見るべきだし、仕様やデザインや施策にコミットしなければならない。
もし本当にコードを書くことしか期待されてないのであれば、その採用をしている時点でサイロ化済みの組織である可能性は高い。

また、本当にめっちゃくちゃコードを書く能力が高い場合はその対象者だけを別のロールとして考えるべきで、安易にすべてのエンジニアを対象者としてはいけない。