背景

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

内容

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

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

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

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

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

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

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

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

人材開発会議

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

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

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

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

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