分業した方が絶対に早いでしょ！

スクラムでは、ウォーターフォールと違って分業をしていないことが多いと気づいている人はいるのではないでしょうか？それどころか、積極的にお互いのスキルの交換や実践を行っているようにすら思えます。
ただ、そんなことをするよりもメンバーが自分の得意なことを活かして専業や分業をした方が作業の効率は良いのではないでしょうか。例えば、フロントが得意な人はフロントだけに専念してもらう、バックエンドの経験が豊富な人はそこに集中する、インフラに興味がある人はしばらく勉強をする、などです。分業による属人化してしまうことが問題かもしれませんが、それを補ってあまりあるだけのメリットがたくさんある！そう思っている人はいませんか？

分業に変えたせいで失敗した事例

私の経験では、分業をしたことで失敗した事例がいくつかありますので、紹介します。

私はあまりプロセスも管理されていないようなウォーターフォールもどきでエンジニアとして開発していたことがあります。そのときは、分業化しフロントエンドとバックエンドの担当に分かれて実装していました。そのため、エンジニアという立場で分業するメリットについても、理解しています。分業することで、エンジニアは覚えることが圧倒的に少なくなりますよね。そして、自分が好きな技術を集中して使えるので、スキルを磨くことも容易です。

しかし、デメリットも多かったです。担当の作業が遅れることで、チームの関係性が悪化することもありました。具体的には、自分が足を引っ張っているという罪悪感があったり、早くリリースしたいと考えている仲間から責められることになったり、遅れている担当はもちろんですが残業をすることはあっても体調が悪くても休むことができなくなってしまっていました。

そして最終的にはもっと悲惨な結末も待ち構えていました。1つの案件では、サービスを小さく試すことができないビックバンリリース（大きなリリース）をすることになり、ほとんどユーザに使ってもらえないサービスを生産することになってしまいました。また別の案件では、関係が悪くなり締切にも間に合わなくなってプロジェクトを頓挫することになってしまいました。

かろうじて、リリースできたケースもありますが、それは分業しながらもスクラムをつかって開発していたため、リリース予定が大幅に遅れたもののリリースしてサービスを利用してもらうことになりました。

結論としては、分業してウォーターフォールもどきで開発していた案件については、お金を生み出さなかったわけですから、かけたリソース（人、もの、かね、情報、時間）が全て無駄になりました。スクラムの分業に関しては、大幅に遅れてリリースすることができました。

能力格差がある場合、分業や専業によるメリットは消える

分業化に対する単純労働と知的労働の特徴は以下のようになります。

• 単純労働

  • 車の組み立てなど知的難易度の低い作業に向いている

  • 高度なスキルや研修がほぼ不要なので、スイッチコストが低くく、替えが効く

  • 個人の能力格差による全体の生産性への影響は小さいので、ボトルネックがあったとしても簡単に解消できる

• 知的労働

  • ソフトウェア開発などの知的労働には向いていない

  • 専門的なスキルや経験が必要なので、スイッチコストは高く、替えが効かない

  • 個人の能力格差による全体の生産性への影響は大きいので、ある個人の限界=そのチームの限界となりやすくボトルネックの解消が難しい

エンジニアやPMからの反論

それでも、エンジニアの方やPMの方からの反論があるとも考えています。エンジニアとして分業することのメリットは以下のようなものが想定されます。

• エンジニアの分業のメリット

  • 専門に専念できるので余計なことを考えずに済む

  • 組織のことを考えずに、自分のペースでできるから気が楽

  • より専門分野の経験と知識を増やせる

  • 市場価値を高めやすい

しかし、このような反論にはかなり危うい点があります。まずは、最初の2つ。「専門に専念できるので余計なことを考えずに済む」「組織のことを考えずに、自分のペースでできるから気が楽」に関してはエンジニアとしての仕事としては楽になるが組織から求められている成果に貢献できないという大きなデメリットがあります。もちろん、このような状況であれば、昇給もしづらくなり、賞与も少なくなってしまうことでしょう。

後半については「より専門分野の経験と知識を増やせる」「市場価値を高めやすい」に関しては、転職をベースに年収を上げようとされているのでしょう。しかし、実は逆効果になります。なぜなら、市場価値を高めるなら1つのスキルの専門性よりも、フルスタック経験がある方が高い年収を得られるからです。さらに、1つのスキルの専門性を評価してくれる会社はスキルのマッチングの問題で対象の会社が少なくなることも考えられます。さらに、エンジニア経験として「経験年数○年」といった募集をしているところもありますが、複数のスキルを同時に経験していれば、同時にReactもGolangも経験年数を増加させることができるわけです。こちらに関しては、Indeedで調べた結果を用いているので、気になる方は検索してみてください。

PMの方の反論として、最も考えられるのが「最も生産効率が高いのは分業」だというもの。もちろん、分業することで生産効率が高いことには同意します。しかし、ビジネスとして開発をしている限り、生産効率よりも、ビジネス価値を生む方法の方を重視するほうがいいと思います。多くの方は、生産効率が高いことがビジネス価値を生むこととイコールで考えられているかもしれません。しかし、実は生産効率とビジネス価値は全然違ってきます。

なぜなら、先にバックエンドを先行して作っていても、あとからフロントエンドを作れば利用できるわけではないからです。もちろん、1つ2つなら、そんなに大きな変更もせずに進められるかもしれません。しかし、バックエンドの機能だけが溜まっていった場合、その後開発する機能に影響を受けて手直しをする必要が出てくるのはもちろんのこと、手直しされ続けたにもかかわらずリリースされることがない場合や、そのままずっと使われずにお蔵入りなんてこともあり得るわけです。体感では、その後手直しの必要がなくリリースできる場合は、2割あったらいい方ではないでしょうか。

そうなってくると、リリースしていないからビジネス価値を生んでいない部分に関してもメンテのコストが取られてしまったり、最悪作ったものが使われないで終わってしまうことを考えると、生産効率を最大化するメリットよりも遥かにデメリットのほうが大きくなってしまうのです。

分業により、離職率や有害社員の誕生など問題が頻発した

また、それに加えてかなりチームの関係性が良いチームでないと、分業によって有害社員が生まれてしまう可能性もあります。有害社員は、ハラスメントをしたり虚偽の時間報告をするなど、組織にとって悪い影響をもたらします。この有害社員のマイナスの影響は、優秀な社員のプラスの影響の2人分よりも大きいと研究で明らかになっています。また、チームで開発するときに心理的安全性が重要であることはよく言及されていますが、有害社員は心理的安全性に関してもマイナスの要因として働き、チームのパフォーマンスを悪化させます。

得意分野の偏りは、どうやって解決したらいいの？

分業しないほうがいいと紹介しましたが、どうやってチームで経験の浅い分野を克服していったらいいのでしょうか？ ここでは、ペア・モブプログラミング、簡単なタスクから任せる、順番に一番上のタスクから取っていく、の3つの方法を紹介します。

ペア・モブプログラミング

この方法は、好き嫌いが分かれるやり方なのですが、最もオススメな方法です。これは、1つのタスクを複数人で同時に取り組むやり方です。ペアプログラミングは、1つのタスクに対して2人で、モブプログラミングは、1つのタスクに対して3人以上で取り組みます。1つの大きなディスプレイを複数人で見るような形式でもいいですし、複数のディスプレイに同時に同じものを移しても良いです。有名なIDEであるIntelliJ IDEAには、リモートでペアプログラミングする機能も提供されています。

チームにある領域が得意な人が1人しか居ないなら、他のメンバー全員がその1人からスキルを習得しないといけないので、モブプログラミングをするのが適切でしょう。そうではなく、ある領域が得意な人が複数人ずついるような場合であれば、ペアプログラミングを選んでも、モブプログラミングを選んでもどちらでも大丈夫です。

この方法は、他の方法と違って、優秀な人の仕事のテクニックを学ぶことができるため、特に優秀な方法です。ペアで作業をすると、時間効率が半分になってしまうという心配をする方もいると思いますが大丈夫です。知見の共有や、複数人で設計を考えるフェーズなどを踏むこと、複数人で開発しているのでコードレビューが不要になることなど他のメリットもあるので、生産性にマイナスの影響は殆どありません。

簡単なタスクから任せる

この方法は、ペアプログラミングと違って、簡単なタスクから任せるので好き嫌いなくやれる方法でオススメです。方法は簡単で、比較的優しいタスクに印を付けておき、経験の浅い人に印のついたタスクを任せるだけです。優しいタスクが枯渇していると、なかなか進まなくなってしまうデメリットもあります。

順番に一番上のタスクから取っていく

この方法は、ちょっと難しいやり方ではありますが、新しいやり方を導入したりせずに、得意分野を担当することをやめるだけの方法でプロセスを考える労力が最も少ないです。ちょっと厳しい方法のため、一時的に生産性は大きく下がるでしょうが、長期的に見るとチームがビジネス価値を生み出しやすくなることを考えて取り組むのが良いでしょう。一時的にベロシティ（生産能力）が落ちると思いますが、しばらくすると伸びを感じられるので良いと思います。

成果を可視化する

チームによっては1人しかできないタスク、2人しかできないタスクなど、できる人が少ないタスクにマークを付けたり、付箋の色を変えるなど、管理しているところもあります。また、それを集計することで、チームで経験が浅い人が多いタスクの数を可視化することができます。こういった可視化を通してチームの改善を見えるようにしてチームのモチベーションアップにつなげているチームもあります。
また、スキルマップを作ってスキルを可視化しておくのも成果の可視化として優秀な方法です。

まとめ

分業したほうが早くなるのは生産速度であり、ビジネス価値を生むことが早くなるわけではない。それどころか、ビジネス価値を生むことにはマイナス要因（価値を産まないものに手直しを続ける、作ったものがリリースされない、有害社員を生む、など）の方が多く、生産速度を上げるための分業は望ましくない。

そして、エンジニアの市場価値を考えて、分業によってスキルを絞って専門家になることを目指すことは必ずしも良い戦略と言えない。逆にフルスタックエンジニアとして、スキルを幅広く積み上げるほうが高い単価の仕事の選択肢が大幅に広がる。

得意領域の偏りに対する効果的な対策は、ペア・モブプログラミングや、簡単なタスクから任せる、などの方法がオススメです。不得意分野を1人でタスクをこなすことができない分野と定義し、それを可視化することでチームで取り組んだ成果を見ることもできるので、推奨しています。