ローテーションガイドライン
🛡️

ローテーションガイドライン

背景

  • アンラーニングにおいては適切なローテーションが必要となる
  • 個人に依存しないようにするには、定期的なローテーションが必要
  • 同じプロジェクトに長くいる場合、成長の余地が少なくなる

内容

  • 同じプロジェクトに1年半、継続して業務を行う場合ローテーションの判断を行う

ローテーションを行うべき判断基準

  • その後の成長の余地が無い、少ない場合
  • 他のプロジェクトにローテーションして参加した場合の方が、成長の余地が大きい場合
  • 業務知識、仕様理解などが個人に依存するネガティブリスクが高い場合

ローテーションを行う必要が必ずしも無い場合の想定

  • 1年半同じプロジェクトに所属するが、同じプロジェクトの中で役割を変える場合
    • サーバーサイド(半年)→フロントエンド(半年)→スクラム マスター(半年)→エピックプロダクトオーナー(半年)

ローテーションをより行うための方法

ローテーションDBによる可視化

ジョブローテーション判断情報 (α版)

を活用して、ローテーション希望を可視化する

人材開発会議

  • レップ会議で、人材開発会議(今後開催予定)を定期的に開催してローテーションを促す

重要)半年毎の兼務メンバー増員

  • 既存のプロジェクトにおいて半年毎に兼務メンバーの増員を行った上で、これまでの既存メンバーの稼働を少なくして、新規増員メンバーの稼働を増やす
    • 既存メンバーAの稼働1人月→0.75人月
    • 新規増員メンバーBの稼働0人月→0.25人月
  • 重要なのは、1年半後のローテーションを見越して、増員メンバーBの稼働を増やしながら、既存メンバーAの稼働を少しずつスライドさせながら減らしていくことである
  • それには、長期に続くと予想されるプロジェクトにおける早期(半年以内)増員が必要となる

保守のみとなっているプロジェクト

  • DevOps、自動化を進める中で、結果としてほぼ保守のみの作業となったプロジェクトについては、外部パートナーに委託をする
  • その上でプロパーは新規プロジェクトにおける参加機会を増やすこと