アジャイル開発のスプリントサイクルやリリーススケジュールを踏まえた退職届提出の最適タイミングについて解説します。
法律上の退職タイミング
まず前提として、退職のタイミングに法律上の制約は少ないことを確認しましょう。
| 雇用形態 | 退職可能時期 | 根拠法 |
|---|---|---|
| 正社員（期間の定めなし） | 申し出から2週間後 | 民法第627条第1項 |
| 契約社員（期間の定めあり） | やむを得ない事由がある場合は即時 | 民法第628条 |
| 契約社員（1年超経過） | いつでも退職可能 | 労働基準法第137条 |
就業規則で「1ヶ月前」「3ヶ月前」と定められていても、民法の規定が優先されるとする裁判例が多数あります（東京地裁平成3年11月19日判決など）。
ただし、円満退職を目指すなら就業規則に従い、かつ開発サイクルを考慮するのが現実的です。
スプリント・開発サイクルを考慮した退職タイミング
スクラム開発の場合
スクラム開発ではスプリント（通常1〜4週間）単位で開発を進めます。退職のベストタイミングは以下の通りです。
最適: スプリントの最終日（スプリントレビュー後）
- 担当ストーリーが完了した状態で退職できる
- 次スプリントのプランニングで後任にタスクを引き継げる
- レトロスペクティブで引き継ぎ事項を共有できる
避けたいタイミング
- スプリント中盤（担当タスクが中途半端になる）
- スプリントプランニング直後（新しいタスクを引き受けた直後）
退職届提出のスケジュール例（2週間スプリント）
| 時期 | アクション |
|---|---|
| 退職の2ヶ月前 | 上長に退職の意思を口頭で伝える |
| 退職の1.5ヶ月前 | 退職届を正式に提出 |
| 退職の1ヶ月前 | チームに共有、引き継ぎ計画策定 |
| 最後から2番目のスプリント | 新規タスクを減らし、引き継ぎに注力 |
| 最後のスプリント | ドキュメント整備・引き継ぎ完了 |
| スプリント最終日 | 退職日 |
リリーススケジュールを考慮する
メジャーリリース前後の退職
メジャーリリースの直前に退職するのは、チームへの負担が大きくなります。
推奨タイミング
- メジャーリリース完了後の安定期間（リリース後1〜2週間）
- 次の開発フェーズ開始前
- 四半期の区切り
避けたいタイミング
- リリース1週間前（コードフリーズ期間中）
- リリース直後のバグ対応期間
- 年末年始・大型連休前（引き継ぎ期間が確保しにくい）
カンバン方式の場合
カンバンにはスプリントの区切りがないため、以下を目安にします。
- 担当中のチケットが全てDone列に移動したタイミング
- WIP（仕掛かり中）のタスクがゼロの状態
- 月初や月末などキリの良い日付
退職日までの引き継ぎ戦略
引き継ぎドキュメントに含めるべき内容
- 1 担当領域のアーキテクチャ概要図
- 2 開発環境のセットアップ手順
- 3 定常業務の手順書（デプロイ手順・障害対応フロー）
- 4 未完了タスクの一覧と優先度
- 5 技術的負債のリスト（把握している範囲で）
- 6 外部サービスとの連携情報（API仕様・認証情報の保管場所）
ペアプログラミングによる引き継ぎ
ドキュメントだけでは伝わらない暗黙知を共有するため、最後の1〜2週間は後任者とペアプログラミングを行うことを推奨します。
- 障害対応の模擬演習
- コードレビューを一緒に行う
- デプロイ手順を実際に一緒に実行
退職を伝えるタイミングで注意すべきこと
上長への報告
- 1on1ミーティングの場が最適
- 朝会やスタンドアップの場では伝えない
- メールやチャットだけで済ませない
チームへの報告
- 上長と相談の上、適切なタイミングで共有
- スプリントプランニングやレトロスペクティブの場で正式に共有するケースが多い
退職は法律で認められた権利です。プロジェクトの区切りを待つことは推奨しますが、義務ではありません。自分のキャリアと健康を最優先に判断しましょう。