休暇は敵か、前提か ― グローバルプロジェクトにおける“時間設計”の思想
itpjstudy
グローバルプロジェクトでは、「休暇」は単なるスケジュール調整事項ではありません。
それはプロジェクトの成否を左右する構造的制約であり、同時にプロジェクトマネージャの考え方が最も表れるテーマでもあります。
日本では、休暇はカットオーバーや遅延リカバリに活用されることが少なくありません。一方で欧米では、休暇は“不可侵の前提条件”として扱われます。さらにオフショア開発が加わることで、祝祭日のズレが新たなリスクと機会を生み出します。 本記事では、実務ノウハウを押さえつつ、「時間をどう設計するか」というマネジメント思想まで踏み込みます。
なお、文化の違い、品質に対する考え方の違いなどの全体的な理解については、グローバルプロジェクトの全体像をご覧ください
日本型プロジェクトにおける休暇の使い方
日本では、休暇は「止まる期間」ではなく、「安全に動かす期間」として活用されることが多いです。
お盆・年末年始は「カットオーバー好機」
多くの基幹システム刷新や大規模リリースは、お盆や年末年始に設定されます。理由は明確です。
- 利用者が少ない
- 業務影響が限定的
- 万一障害が発生しても影響範囲が小さい
つまり、日本型の発想は次のように整理できます。
休暇＝業務影響を最小化できる“安全な切替期間”
これは極めて合理的で、実務的にも有効な戦略です。
遅延リカバリとしての連休活用
スケジュールが逼迫すると、連休が“挽回期間”として扱われることがあります。
- 休日出勤
- 特別体制
- 集中テスト
- 一斉リリース準備
「連休で取り戻す」という発想は、日本のプロジェクトでは珍しくありません。
グローバルでは休暇は「不可侵の前提条件」
日本では休暇は「業務影響を抑えて作業する期間」として活用されることがあります。
しかし、グローバルプロジェクトにおいては、休暇は調整対象ではなく、設計上の固定条件として扱われるケースが少なくありません。
ここでは、欧州・北米・アジアの拠点ごとの特徴を整理します。
欧州：長期連続休暇は組織前提
例えば ドイツ や フランス では、夏季に2〜4週間の連続休暇を取得することが一般的です。特徴は次の通りです。
- 休暇は数か月前に確定する
- 家族単位で固定される
- 休暇中は原則として業務対応しない
- 代理体制を前提に組織が設計されている
重要なのは、「休暇を削る」という発想がほぼ存在しないことです。
休暇は“努力で調整するもの”ではなく、“前提として織り込むもの”です。
そのため、夏季に重要承認や大規模カットオーバーを設定すると、意思決定が物理的に止まる可能性があります。
北米：ホリデーシーズンは実質スローダウン
アメリカ合衆国 では、感謝祭からクリスマス、新年にかけて業務が大きくスローダウンします。欧州ほどの長期連続休暇ではなくても、
- 有給取得が分散する
- 会議参加率が下がる
- 意思決定スピードが落ちる
といった現象が起こります。
この期間にカットオーバーを設定すると、
- 障害時のキーパーソン不在
- ベンダーのみが稼働する構図
- 本社承認が止まる
といったリスクが生じます。
アジア：中国・東南アジアの“集中型大型休暇”
アジア拠点は「休まない」という誤解を持たれがちですが、実際には非常に集中度の高い大型休暇があります。例えば、
- 中国：春節（旧正月）
- ベトナム：テト休暇
- タイ：ソンクラン（水かけ祭り）
- インド：ディワリ
これらの期間は、都市部から地方への大移動が発生し、実質的に業務が停止します。
特徴としては：
- 休暇が短期間に集中する
- 一斉離脱が起きやすい
- 休暇前後に生産性が大きく変動する
欧州のような長期分散型ではなく、短期集中型の停止が起きるのが特徴です。
| 地域 | 休暇の特徴 | リスクパターン |
| 欧州 | 長期連続型 | 承認停止・意思決定遅延 |
| 北米 | 分散取得型 | 会議成立率低下・判断遅延 |
| 中国・東南アジア | 短期集中型 | 一斉停止・復帰直後の混乱 |
どの地域も「休暇が重要である」という点は共通しています。違うのは、
- 取得の仕方
- 集中度
- 組織設計の前提
です。
つまり、休暇を理解するとは、祝日を覚えることではありません。その組織が「時間を誰が調整する前提で設計されているか」を理解することです。
グローバルプロジェクトマネージャは、「どの拠点がいつ止まるか」を把握するだけでは不十分です。“どの思想で時間が設計されているか”を理解することが重要です。
オフショア開発が生む“休暇のズレ”
グローバルプロジェクトでは、さらに複雑な現象が起きます。
旧正月・地域祝祭日という大きな山
例えば、
- 中国：春節
- ベトナム：テト
- インド：ディワリ
これらは、日本の年末年始以上に大規模な休暇になることがあります。
ズレは武器にもリスクにもなる
良い面
- 日本の年末年始中に開発を進められる
- リリース準備を前倒しできる
悪い面
- 旧正月直前の仕様変更
- テスト終盤で主力メンバー一斉離脱
- 障害時に対応不能
休暇のズレは、設計すれば武器になりますが、無視すれば構造的リスクになります。
スケジュール変更 × 休暇が引き起こす構造的遅延
休暇自体は予測可能です。問題は、スケジュール変更と重なったときです。
承認プロセスの停止
仕様変更が発生し、再承認が必要になったタイミングで欧州夏季休暇に入ると、決裁が数週間止まることがあります。その結果、
- 開発待機
- テスト開始遅延
- 外部リソース追加コスト
が発生します。
カットオーバー直前のブラックアウト
変更によって本番切替が休暇期間に食い込むと、
- 体制不十分で強行する
- 延期してコスト増を受け入れる
という厳しい選択を迫られます。本当の爆発要因は、「変更」と「休暇」の衝突 です。
実務ノウハウ ― 休暇を前提に設計する
ここからは具体策です。
年間カレンダーをWBS設計前に確定する
- 各拠点の祝日
- 長期休暇
- 学校休暇
- 固定休暇
これを最初に洗い出し、プロジェクト前提条件として固定します。
実効稼働月を算出する
年間12か月は幻想です。
| 拠点 | 名目 | 実効稼働月 |
| 日本 | 12 | 約11 |
| 欧州 | 12 | 約10 |
| オフショア | 12 | 約9〜10 |
全拠点同時フル稼働期間は想像以上に短いことがあります。
ブラックアウト期間の明文化
契約や合意文書に、
- 変更不可期間
- 承認不可期間
- サポート縮小期間
を明記します。 曖昧さは、後のトラブルの種になります。
休暇をどう扱うかは、マネジメント思想の問題
ここからが本質です。 少し噛み砕いて説明します。
「頑張れば何とかなる」と考えるかどうか
日本型プロジェクトでは、
- 遅れたら取り戻す
- 連休で挽回する
- 特別体制で乗り切る
という発想が比較的自然です。これは決して悪いことではありません。責任感が強く、組織としての一体感がある証拠でもあります。
しかし、グローバルでは通用しない場合があります。欧州では、
- 休暇は個人の権利
- 生活は仕事より上位概念
- 組織はそれを前提に設計するもの
という考え方が強いです。
ここで重要なのは、どちらが正しいかではありません。
「自分の常識が世界の常識ではない」と理解できるかどうか これがマネジメント思想の分岐点です。
プロジェクトとは「時間の使い方を決める行為」
プロジェクトマネージャの仕事は、タスク管理ではありません。本質は、
- 誰が
- いつ
- どれだけ
- どんな前提で
時間を使うかを決めることです。
休暇を「邪魔なもの」と見るか、「前提条件」と見るかで、設計の仕方は大きく変わります。
成熟したプロジェクトマネージャは、
- 休暇を責めません
- 文化を否定しません
- 前提として織り込みます
つまり、時間を制御しようとするのではなく、時間の制約を前提に設計する これがグローバルプロジェクトマネージャの思想です。
休暇を含めて設計せよ — 休暇は障害物ではありません。排除すべき問題でもありません。それは、
- 文化
- 前提条件
- 設計変数
です。グローバルプロジェクトで成熟したプロジェクトマネージャは、休暇を“調整”しようとはしません。休暇を含めて、時間を設計します。 そこに、本当のプロジェクトマネジメントがあります。
なお、文化の違い、品質に対する考え方の違いなどの全体的な理解については、グローバルプロジェクトの全体像で整理しています。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
