yigarashiのブログ

学んだことや考えていることを書きます

エンジニアの異動は推奨すべきなのか? - 組織の成長について考える

最近エンジニアの異動について軽く議論することがありました。自分はチームの安定性の側面からやや否定的な立場だったのですが、その議論で刺激を受けて周辺領域も含めて考え直したところ、組織の成長という軸で色々な知識がつながって面白かったのでまとめてみます。

議論の前提

異動も含めてエンジニア組織について考える時、まずは外せない前提がひとつあると思います。それは、安定したチームないしバリューストリームを維持することです。「チームトポロジー」の3章では以下の言葉を引用し、複雑なシステムの開発にはチームの効果的なパフォーマンスが欠かせないことを論じています。

ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ。

現代のソフトウェア開発の変化速度や複雑性に対処するには個人では限界があり、チームとしての活動が欠かせません。チームメンバー間で強い信頼関係が生まれることで、実験とイノベーションが起こり、パフォーマンスはさらに向上していきます。チームがそうした安定した状態に至るには一般に2週間から3ヶ月と長い時間がかかるので、仕事のたびに人をアサインするのではなく、安定したチームに仕事が流れ込むのが良いとされています。

エンジニアの異動に関する議論は、この前提をクリアした上で如何に新しい価値を生み出すのか、という視点で考えるのが良いだろうと思います。

エンジニアの異動に期待される価値

エンジニア組織において戦略的に異動を推奨する時、おおよそ次のようなことが期待されていると考えます。

  • チームの成長
    • 異なるやり方をする人がチームに入ることでUnlearnが起こる
    • チーム間で知識とプラクティスが交換され洗練される
  • 個人の成長
    • 異なる環境に身を置くことで手数が増えたり視野が広がったりする
    • 人脈が形成され帰属意識が高まったり、組織的な課題に挑戦しやすくなる

こうした価値が積み重なって組織全体が成長し続けることが最終的な目的になるでしょう。上で参照した「チームトポロジー」の3章でも、チームは安定している必要があるが、固定してもいけないと述べられています。安定したチームを破壊しない程度に人が流動することは前向きに捉えると良いようです。

高い効果を期待できる異動

安定したチームを維持しつつ、チームや個人の成長を期待する時、高い効果を期待できる異動のパターンがいくつか思い当たります。

ひとつはジュニアメンバーの異動です。ジュニアメンバーはチームのコミュニケーションやバリューストリームに与える影響が少ないので、チームの安定性についての心配は少ないでしょう。一方でジュニアメンバー本人の成長という観点では大きな価値を期待できます。さまざまなやり方を身につけ、一緒に仕事をしたことがある知り合いが社内に増えるのは良いことです。わたし自身、入社一年目に別のチームに半年だけ異動してそうした価値を享受した経験があり、納得感の強いところです。一方で、これが100%正しいとは限らないことには注意が必要だと思います。チームやその人の特性によっては、ひとつのことに早く習熟し、自己効力感を感じられることで良いフィードバックループが回り出す場合もあるでしょう。あくまで本人の希望やマネージャーの観察に基づいて慎重に采配すべき事柄だと思います。

次のパターンは特定領域の専門知識を持った人の異動です。これは、チームトポロジーにおけるイネイブリングチームが支援先を変えるのに近いものです。うまくいけば専門的な知識が複数のチームに伝播していきます。このパターンが機能する前提は、異動する専門家本人が、チームが専門的な能力を備え自律的に活動することに責任を持ち、実際にそれを成功させていることです。まさにこれはイネイブリングチームのミッションです。当然、本人しか変更できない要素がバリューストリーム上に残っているなら安易に異動するべきではないでしょう。チームの安定性を大きく損なう可能性があります。

最後はチームのリーダー的存在の異動です。リーダーが異動すると劇的なUnlearnが期待できます。他のメンバーにリーダーシップが芽生えることで個人の大きな成長も期待できます。もちろん短期的なチームの安定を度外視したやり方なので、そう乱発できるものではないですが、うまく戦略的に実行すれば組織の力を底上げできると思います。

いまのところ、上に述べた以外で突出したメリットのあるパターンには思い当たりませんでした。もちろん上記以外のパターンでも一定の効果は期待できると思われますが、組織として推奨するほどではないということです。ここの裾野を広げるためには、採用技術やアーキテクチャを揃えて認知負荷を下げたり、業務フローから属人性を排除したり、ピープルマネジメントの方向からメンバーを育てたりして、地道に人員の交換可能性を高める追加の戦略が必要になってくると思います。

そうした活動を突き詰めていくと、「異動という文化」が発展した、社員同士の信頼関係の強い組織ができるのかもしれません。「チームトポロジー」では、そうした高信頼な組織ではエンジニアが1年に1回チームを変えてもパフォーマンスが落ちないケースに言及されています。逆に、そうではない普通の環境では1年半から2年はひとつのチームに留まるべきで、さらにチームの一体感を高めるために支援も必要だとされています。

異動以外の手段

エンジニアの異動に期待される価値は、異動以外の手段でも得られるように思います。例えば以下のようなものです。

  • 優秀なスクラムマスターによる継続的なUnlearn
  • イネイブリングチームによる特定の領域に関する支援
  • ギルドのような特定の領域に関する知見交換のグループ

今回は「異動」というテーマから出発したので議論が偏りましたが、本来は「組織の成長」が一番上にきて、その実現方法として異動と上に並べたような内容が対等に並ぶのが健全なメンタルモデルだろうと思います。個人的には、これまで学んだスクラムマスターのテクニックや組織設計が異動という戦略を代替しうる点が非常に面白く、これまで学んだ知識が少し抽象度の高いところで繋がった気がします。

まとめ

この記事では「エンジニアの異動は推奨すべきなのか?」という問いに対する現時点のわたしの回答をまとめました。基本的には、チームの安定性の損失と組織が得る成長機会を比べて、得だと思う人には異動を推奨すれば良いし、損だと思うなら推奨しないという当たり前の結論に至りました。得になりやすいパターンはいくつかあり、得なケースが増えるように組織として工夫することもできそうです。

組織やプロセスがよくできていれば自ずと異動はしやすくなるので、ある種のヘルスチェッカーとしての側面が強いように思いました。間違っても異動の量をそのままKPIにしてはいけなくて、チームの安定性をいたずらに破壊してしまうので、異動を阻害する組織の課題にブレークダウンして取り組んでいくのが良いでしょう。一方で、組織の成長という観点では異動以外の手段によって似たような価値を享受することも可能で、広い視野で組織のあり方について考えることが重要だと思いました。