#150 フルサイクルエンジニア④ ～成長に伴いチームに境界が生まれる理由～

こんにちは。ITベンチャーエンジニアのこへいです。

前回、フルサイクルエンジニアチームが高いパフォーマンスを発揮する条件として自立したメンバーが共通の責務・目標を共有することを挙げました。

今回はワークしていたチームが事業や組織規模の拡大に伴い境界が生まれ、パフォーマンスが落ちてしまうメカニズムについて考えます。

〇売上拡大のためのチームの分離

受託のシステム開発における売上増加の方法

弊社のような受託のシステム開発事業で売上を拡大するためのアプローチとしては、案件の数を増やす、案件の規模を大きくするなどが挙げられます。

いずれにしろ、より多くの開発を請け負うことで売上が向上します。弊社は完全な売り切りのシステム開発ではなく、資産となる技術があるため、すべての案件に対してゼロから開発するわけではありませんが、基本的には労働集約型のビジネスです。

そのため、売上の増加に伴い、開発量を増加させる必要があります。

フルサイクルチームにおける開発量増加の難しさ

売上増加のためには、開発量の増加が必要です。
開発量を増やすために人を増やすというアプローチもあります。

しかし、システム開発は知的労働であり、扱うシステムや組織によって求められる専門性や能力がことなります。
また、弊社の場合はフルサイクルで対応するため、個々人に求められる仕事の幅は多岐にわたります。高負荷のマルチタスクの中での働きが求めらるため、人を増やすことが難しいという側面があります。

採用後のオンボーディング期間を設ける必要があり、その期間はチームがフォローするため、短期的には生産性が下がります。
1人増員するのにも大変であり、一気に2,3人の増員をすると、受け入れる側のチームの負荷が一気に高まるという課題があります。

開発量を増やすための役割の特化

増員が難しいということで、手っ取り早く開発量を増やす方法として、開発案件を対応する役割に特化したチームに分離するというアプローチが取られます。

これまで一つのチームで開発・運用をフルサイクルに行っていたところ、チームが開発特化チームと運用チームに分離されます。
時には開発チームに増員されます。

開発特化チームは、開発プロジェクトを成功させるという目的を共有することができ、新規開発に集中し運用系のタスクを持たないため、見た目上の開発総量が増えます。

これで、開発量が増え、売上も増える！！めでたし、めでたし。とはなりません。

開発チームと運用チームの目線のずれが生まれる

チームを分離することで、開発速度は向上しますが、これまで一つのチームでフルサイクルに対応することで生まれていたコラボレーションが発揮されなくなります。

これまでは一つのチームのなかで開発・運用の双方にとって良い状態をバランス出来ていたのが、チームの分離に伴い大事にするポイントが変わってきてしまい、開発速度を優先することで運用負荷が増加するというトレードオフを抱えることになります。

また、『0→1』を担う開発チームと『1→10』を担う運用チームで、別々に評価を受けることにもなり、このトレードオフによるひずみがさらに大きくなっていきます。

〇プロジェクトの増加に伴う営業とエンジニアの分離

プロジェクトの増加に伴う役割の分離

売上を増やすためには案件の数も増やす必要があります。
フルサイクルなチームの場合は営業・エンジニアが揃って顧客とコミュニケーションを取ることで高いパフォーマンスを発揮します。しかし、案件の数を増やすために商談数を増やしていくと、すべての商談にエンジニアが同行することが難しくなります。

先ほども触れた通り、エンジニアの増員が難しい構造であるため、商談数の増加に伴いエンジニアを増やすことは容易ではありません。
そのため、この場合も役割を分離することになりがちです。

役割の分離に伴う弊害

エンジニアは営業を介して顧客の要望に触れることになります。また、役割を共有している時は営業・エンジニアが一緒に顧客に向き合っていたのが、営業は顧客とエンジニアの両方に向き合うことになります。

顧客に対して一緒に向き合うことで、実装コストを考慮して顧客の要望に応えられる最適な方法を検討し、顧客への伝え方も一緒に考え、一緒に顧客に伝えることができました。
しかし、営業が顧客とエンジニアの間に入る形になると、そうはいきません。伝言ゲームになって、情報の解像度が薄れてしまいます。また、営業からするとプロジェクトを円滑に進めるためには、顧客の要望とエンジニアの意見の折衷案を見つけて両者と合意することが必要になります。
これまでスムーズに進んでいたプロジェクトが、いちいち停滞することになります。

プロジェクトの数を追うために、営業・エンジニアの境界が生まれると、営業は「エンジニアが顧客に寄り添わなくなった」と思い、エンジニアは「営業が顧客の御用聞きになっている」と思い、互いにリスペクトして協力していくことが難しくなります。

営業・エンジニアに境界がない時は、営業・エンジニアが互いの持っている情報や互いの視点からの意見をすり合わせることで、最適な方法を一緒に見つけることが出来ます。しかし、境界が生まれることで、営業は技術観点の理解が浅い状態で顧客の要望を伺うことになってしまうために、御用聞きになってしまいやすくなります。

御用聞きになるかどうかが、営業の能力に依存してしまいます。凄腕の営業の方でもエンジニアと同等の深い技術的理解を持っている方は稀です。それを営業に求めるのは厳しいかと思います。

ということで、事業の拡大に伴い、より多くの売上を確保する必要が生じ、効率化のために開発チーム・運用チームの分離、営業・エンジニアの分離が進行する理由、そして、分離による弊害について紹介しました。

分離した状態で高いパフォーマンスを発揮するには、やはりチームごとに適切な責務を与えることが必要です。しかし、これまではチームとプロジェクトの規模や数がかみ合った中で現場が良い感じに最適化していたのであって、今の状況でチームごとの役割を明確にしていくことは非常に難しいです。

しかし、この難しさと向き合うことが、事業の拡大・組織の拡大を実現するためには必要です。
私の勤める会社での最適なチームの在り方はまだまだ模索中ですが、今後もチャレンジした内容について、noteで発信できればと思います。

最後までお読みいただきありがとうございました。