どんなチームにも「すごくデキる人」はいると思います。その人は、技術的な知見が深く、タスクをこなすスピードが速いため、チームの代表的な戦力として活躍します。素晴らしいですね。
残念ながら、私はそういった「すごくデキる人」ではないため、時にその人に頼ってしまうことが多々あります。「この人に任せておけば安心だ。でも、自分がやるのは不安だ」と思ってしまうのですね。これはよくない傾向ですが、誰しもそう思ったことは一度でもあるのではないでしょうか？
今回は、こういった「ハイパフォーマー」のメンバーがチーム内にいたときに、発生しうる問題について考えていきたいと思います。ただ、当然ですが、このハイパフォーマーのメンバーが悪いのではなく、「誰も悪い人はいないが、どうしても発生してしまう問題」というくくりで、考えていきたいと思います。
チーム構成の例
※ 以下は架空のチーム例です
Aさん
誰もが認める実力者。テックリードを担っている。チームの中で、会社の在籍年数が最も長い。技術的な造詣が深く、タスクをこなすスピードも非常に速い。
Bさん
チームの2番手。Aさんの次に在籍年数が長い。中堅的な存在。
Cさん
最近会社に入ったばかりのエンジニア。技術者としての年数も短めのため、タスクをこなすスピードは他二人に比べて遅い。
例1) 小規模なプロジェクトに取り組むとき
小規模なプロジェクトの場合、タスクをこなす量としては上記であるとします。ハイパフォーマーであるAさんがダントツで消化量が多く、チームの半分を占めます。残りの5割をほか二人が消化します。Cさんが最も消化量としては少ない状況です。
このプロジェクトを終えたとき、Aさんはそのプロジェクトで作った機能の半分ほどを実装したとします。もちろん、タスクの消化数がそのままコード量に反映されるとは限らないので、今回はあくまで考えるのを簡易にするための一例として考えてください。
例2) 中・大規模なプロジェクトに取り組むとき
さて、今回もっとも注目したいのは、上記のチームが大きめのプロジェクトに取り組むときです。仕様はより複雑になり、実装する機能は増え、開発期間も数ヶ月に及ぶようになります。
例1で見たように、プロジェクトが終了するころには、タスクの消化量は 5:3:2 になるのでしょうか？
私は違うと思います。プロジェクトの期間が数ヶ月に及ぶので、その間に、タスクの消化量にさらに差ができる可能性があります。
どういうことかと言うと、タスクをこなしていくと、当然ですがプロジェクトに関する知識が深まっていきます。コードを書けば書くほど、仕様や既存コードの理解がどんどん進んでいきます。これらの理解は、タスクの着手前にチームがペアプロ的に取り組むこともあるとは思いますが、なんだかんだ1人でコードを実際に書いているときが、最も理解が捗りますよね。よくあることだと思います。
最初の数週間（スクラムを採用していれば数スプリント）は、確かに例1のように、5:3:2の消化量でタスクが進むかもしれません。しかし次の数週間では、前回5割のタスクを消化したAさんが、チーム内で最もプロジェクトに対する理解が深まっている状況になります。プロジェクト開始時点では、ある程度3人が同じスタートラインに立っていたはずなのに、タスクをこなすスピードが異なると、結果的に理解の差がチーム内で生まれてしまいます。
そうすると、当然プロジェクトへの理解が深いメンバーが、タスクを進めやすくなるので、Aさんの消化量が増えていきます。一方で、他二人は、コードの記述量がAさんに比べて少ないので、プロジェクトへの理解もやや浅く、タスクにこなすときに色々と調べる時間が発生してしまいます。仕様書を読み返したり、コードを眺めて既存実装を理解し直したりします。そうしている間に、Aさんがどんどん実装を進めていってしまい、差がどんどん開くのです。
そのため、プロジェクトが終わるころには、結果的に以下の消化量になるのではないでしょうか。
これは極端な例ですが、プロジェクトの期間が長くなると、結果的に実装量の差がさらに開いてしまうというのは、なんとなくイメージできるかなと思います。
どんな問題が生まれるか？
一つは、Aさんに知見の偏りが生まれてしまうことです。プロジェクトが終わるころには、Aさんがもっともそのプロジェクトの仕様や技術的な部分に詳しい状況になっており、ひょっとしたらAさんしか知らない何かしらの情報があるかもしれません。そのため、Aさんが退職してしまうと、彼が持っていた大切な情報が喪失してしまうかもしれません。あるいは、Aさんが休暇か何かで不在のとき、不具合が生じてすぐに直す必要になったときも、ほかメンバーは知識が浅いため、解決までに時間がかかる可能性があります。
また、Aさんがプロジェクトの途中でやむを得ず離脱してしまった場合、プロジェクトの進行に大きな影響を与える可能性があります。体調不良や、プライベートな事情、あるいはもっと重要なプロジェクトへ引き抜かれてしまうなど、やむを得ない事情でAさんが不在になってしまうかもしれません。そうなると、BさんとCさんは二人だけで実装を進めねばなりません。さらに、この状況が後半で発生してしまうと、計画に大きな変更を余儀なくされたり、開発そのものが停止してしまうリスクがあります。
チームメンバーの成長という観点でも問題があります。結局のところ、技術者が成長するには、たくさんの経験を積むのが手っ取り早いですが、1人のハイパフォーマーが独占的にタスクを消化してしまうと、ほかメンバーの成長を遅れさせてしまう可能性があります。
どう対処するか
これらの問題を回避する方法を考えてみます。
一つは、タスクを消化する際、ペアプロで同期的に進める方法があります。これをすることによって、メンバー全員で実装を行うことになるので、知見の偏りが少なくなります。
また、タスクに取り掛かる前に、各タスクの実装方針や設計を、チームメンバー全員で取り決める、という方法もあります。「このタスクでは、何を実装して、どのファイルをどこに作成して、どんなテストを書くのか」といったことを細かく決めます。これをすることによって、「考える作業」を前倒しにし、コードを書く作業をできるだけ簡素にすることができます。コードを書いているときに一番理解が進むのであれば、その理解する（=考える）という作業をチームメンバー全員で最初にやってしまおう、という考えです。これは前述のペアプロに近い発想です。
ハイパフォーマーのメンバーに、タスクの消化量を調整してもらう、という発想もあります。仕事の進み具合が速いのは素晴らしいことですが、それによってほかメンバーの成長が阻害されてしまったり、プロジェクト進行におけるリスクを発生させてしまうのであれば、涙をのんでタスクを明け渡すのも必要だと思います。これは当人とって歯がゆい思いになるかもしれないので、事前にしっかりと会話をしておかなくてはなりません。せっかくのハイパフォーマーの仕事を奪うような事態にはなりますが、プラスに考えると、空いた時間を別の重要な作業（リファクタリングなど）に充ててもらうこともできるようになります。あるいは、ほかメンバーがタスクを進めるうえで困っているようであれば、ペアプロを申し出てヘルプに回ることも可能です（相手からしたら、ハイパフォーマーと一緒にコードをかけるのでいろいろなメリットがあります）。ハイパフォーマーはテックリードの役職を担っていることが多いと思いますが、メンバーの成長に貢献することもテックリードの仕事であるとも捉えられるので、この点をじっくり本人と話し合うのが良さそうです。
持続可能なチームであるために
最近、私はチームの「持続可能性」について考えています。長く、力強く成果を発揮し続けるチームになるためにも、こういった「実力の偏り」みたいなものをできる限りなくしていく必要があります。プロジェクトを進めている間は、どうしても終わらせることに集中してしまい、チームの成長といった観点を忘れがちですが、逆に言うとチームが最も成長するのは、困難なプロジェクトに取り組んでいるときであるとも思いますので、このチャンスを十分に活かせたら良いですね。