スクラムチームに個人パフォーマンスの高いメンバーを入れる際の注意点

ここ3ヶ月間、スクラムチームに個人パフォーマンスの高いメンバーに入ってもらうことをチャレンジしてきた。
結果的にはこのメンバーはこのスクラムチームから去ることになったが、この経験について、忘れないように記録しておきたい。
あくまで、スタートアップ企業で働く私（エンジニアリングマネージャ、アジャイル推進者）から見た主観であるという点だけご理解いただきたい。

個人パフォーマンスの高いメンバーをそれまでスクラムチームに入れられなかった要因

組織は昨年よりスクラムの導入を推進し、現在ではエンジニアチーム全体の７割程度のメンバーにスクラムを導入することが完了している。

スクラム導入以前の組織はマイクロマネジメントな状態で開発していた。一方で、マネジメントは個人の能力に頼る形で裁量を与えていたため、個人パフォーマンスが高いメンバーは自由度高く開発できていた。
このような個人依存、属人性の高い組織を脱却するためにスクラムを導入しているが、以下のような理由でなかなか個人のパフォーマンスの高い人をスクラムチームに入れることができなかった。

• 個人パフォーマンスが高いメンバーが入ると、チーム中で教育的な要素が大きくなり、当人の開発スピードが一時的に低下する。

• 自由度高く、仕事をさせてもらえるということを伝えて採用していたため、彼らが望まないジュニアメンバーの教育をしなければいけない。彼らに窮屈な思いをさせることになる

• チーム化が進んでいるものの、行き当たりばったりで開発を進めていて透明性が低い領域も多いため、自由に仕事してても仕事が割とある

上記の理由から個人パフォーマンスが高いメンバーをスクラムチームに入ってもらうことに躊躇いがあった。
弊社に限った話だが、さらに遡ること数年前にスクラムを導入したが、失敗していたという経験があり、この経験が更なる足枷を生み出していた。

なぜチームに個人パフォーマンスの高いメンバーを入れたのか

ここから、個人パフォーマンスの高い人＝個パさんとして記載する。

社内の諸々の事情は割愛するが、個パさんにチームに入ってもらうことになった。なぜ個パさんにチームに入ってもらうことになったかというと、主な理由は「新卒のメンバーが入ってきたが、彼のソフトウェアエンジニアリングのサポートが十分にできていない」という点だった。
また、個パさんスキルをチームに広げることができれば、組織全体の教育にも一役買ってもらえるのではないか、また、他のスキルフルなメンバーもスクラムに入れる可能性を示すことができる、そんな期待があった。

個人パフォーマンスの高いメンバーをスクラムチームに入れる上で最初に伝えたこと

スクラムチームに入ってもらう上で、伝えたことを箇条書きで記載する。

• スクラムチームに入る上で、一時的に個パさんの開発スピードは落ちる

• チームが成長してくれば、個パさんの負担は減ってきて、個パさんの開発スピードも戻るはず

• スクラムチームの教育を担ってほしい

• スクラムが合わなかった場合には、スクラムを抜けることも考えている

個人パフォーマンスの高いメンバーをスクラムチームに入ってもらう上で何を注意すべきだったか

私自身、何が問題だったのか、自分なりに分析してみた。最初に書いたがあくまで私の主観なので、そのつもりで読んでいただきたい。

嫌だったら抜けて良いというオプションを個パさんに与えるべきでない

まず、第一に私が一番問題だったと思っている点は、ここだ。スクラムチームに対して、彼がどれだけ思い入れを持って取り組めるのか。

「嫌だったら抜けられる」という前提は、彼にとって、「改善をしなくても、今は一旦飲み込めば良い」という選択肢を与えてしまう。結果的に不満を溜め込むことになり、目の前の個パさんの課題が不透明になる。あとで改善しようにも、課題が大きくなりすぎる。結果的にチーム内の衝突を招き、悪い雰囲気を継続してしまう。

組織としての方向性を明確にすべき

組織としてどんなことを実現したいのかを明確に示すべきだ。

私としてはスクラムを導入することで、いくつかある組織の課題を解決できると考えているものの、それを明確に示せていない。結果的にスクラムという手段だけが先行して開発メンバーに届き、スクラムを「やる」「やらない」の選択をメンバーに求めているだけになっている。

会社としての目標設定がきちんとしていれば、そこに個パさんの目標や想いをアラインメントしていくこともできたように反省している。
特に、ミドル、ジュニアが多い組織の中では教育の観点は必須だ。そこを目標として掲げることで、開発メンバー同士の教育を活性化していけると良かったと反省している。

スクラムマスターは経験のあるスクラムマスターが担うべき

これは私としてはあまり書きたくないことではあるのだが、私が機能していなかったという点がある。
私はEMとしてのロールもあり、また、このチームのマネージャでもあるためスクラムチームを支援する上では、あまり介入すると権限が先行してチームの自律性を損なうことを恐れていた。
そのため、スクラムマスターは「開発者兼任」で私ではない開発者に担ってもらっていた。（弊社はスクラムマスター専任というロールがまだ存在しない）
彼を頼って私があまり口を出さなかったせいで、開発者vs開発者の構図での議論なのか、開発者vsスクラムマスターの構図での議論なのか分からなくなり、結果的に個パさんが意見を言いにくい雰囲気を作ってしまっていた。
この構造を作らないための役割がまさにスクラムマスターの役割あり、この3ヶ月の体験を通じて、スクラムマスター専任の重要性を感じることができた。仮に専任ではないにしても、過去専任で担当したことがあるような人などが相応しいかもしれない。

ともかく、ここで言いたいのは、「難しいチームメンバーの関係性であればあるほど、経験値のあるスクラムマスターが必要」ということである。

まとめ

結果的に、スクラムチームに個人パフォーマンスが高い人に入ってもらうことには失敗したと思う。しかし、この経験が今後のチームづくりに大いに活きてくると考えているし、失敗しなければ次の成功はないと思う。今後の活動に下味をつけられた良い経験になった。

なんだか、正直まとまりのないことをとりとめもなく書いている意識はあるのですが、一旦自分の中で吐き出したかったので、書いた。

あまり得られるものが無かったかもしれませんが、自分自身のために書いているので、ご了承ください。ここまで読んでいただき、ありがとうございました。