こんにちは！データウェアハウス開発部の大出です。
今年、JMDCではアドベントカレンダーに参加しています。 qiita.com 本記事は、JMDC Advent Calendar 2025 22日目の記事です。
21日目は秦さんによる「Amazon Bedrock✖️GenkitをGoで構築してみる」でした。
はじめに
私がプロジェクトマネージャー（以下、PM）を担当した基幹システムのクラウド移行プロジェクトが、約 1 年半の期間を経て 2025 年 11 月に完了しました。あらためて感じたのは、「計画と実態のギャップをどう可視化し、どう共通認識をつくるか」が移行プロジェクトの成否を大きく左右するということです。本記事では、その過程で実際に行った工夫を PM 視点で紹介します。
プロジェクトの前提
プロジェクト期間は 24 年 7 月〜25 年 11 月。私は 24 年 7 月に JMDC に入社し、その後 PM として参画しました。開発チームは 6 名で、対象は基幹系システム。停止できるのは最大 1 週間、切り戻しは実質不可能という制約があるため、準備と事前合意の精度が特に求められるプロジェクトでした。
遭遇した課題
1. 進捗の見える化
2 週間単位のイテレーティブな開発と、2 か月周期の機能開発・品質確認を繰り返すアプローチでしたが、プロジェクト開始時は「このペースで本当に間に合うのか」を定量で語る手段がありませんでした。シンプルなウォーターフォール開発であれば工程表で進捗を見える化できますが、今回はそれとは異なる方法が必要でした。
2. 進捗遅れへの対処
プロジェクト序盤ならではの課題ではありますが、開発チームには入社から日が浅いメンバーが多く、初期は現行システム理解が並行していました。若手メンバーへの負荷も高まり、進捗を計測すると計画からの遅れが明らかになりました。
3. 困難なデータ移行
移行データ量が多く、要件の制約上、事前移行が難しい状況でした。周辺システムへの影響範囲も広く、利用部署や周辺システムへ「いつ・どんな影響が出るか」を把握し、関係者と調整する必要がありました。
対処
1. 進捗の見える化
Before：
イテレーション単位の進捗は見えるものの、全体計画とのギャップを定量的に説明することが難しい状態でした。
Action： EVM（Earned Value Management）を導入し、毎月の定点観測を開始しました。 去年のブログでも触れましたが、 EVM は計画値（PV）、出来高（EV）、実績工数（AC）を比較して遅れや効率を把握する手法です。
また、EVM の全体指標だけではメンバーの行動に結びつきにくいため、「今月どれだけの出来高（EV）が必要か」「投入工数がどれだけ出来高に変換されているか」といった補助指標も活用し、イテレーション計画や日々のセルフマネジメントに反映しやすくしました。
After：
「なぜ遅れているのか」「今後この遅れはどうなるのか」を数値とストーリーの両面で説明できるようになり、ステークホルダーとの認識合わせが格段に容易になりました。結果として、計画見直しやリソース追加といった意思決定もスムーズに行えました。メンバーから「単に●% の遅れを取り戻せばいいだけ」という前向きな発言があったことも印象的でした。 遅れを定量化したことで、一つひとつの作業完了により集中しやすくなりました。
2. 進捗遅れへの対処
Before：
若手メンバーを中心に負荷が集中し、計画からの遅れにつながっていました。
Action： 私は過去に「人を増やしてもリカバリーできないプロジェクト」を経験していたため、メンバーの対応力の底上げが重要だと考えていました。
- 若手メンバーとの定期的な 1on1 とメンタリング
- PM・プロジェクトリーダー（以下、PL）・エンジニアリングマネージャーによる月次の振り返り
これらに取り組みつつ、中間地点で計画の見直しと 1 名の追加アサインを行いました。「EVM で把握したギャップ」と「現場の状況」を踏まえた判断でした。
After：
開発チームの尽力により、様々な課題に遭遇しながらも進捗は驚くほど計画通りに進みました。 後半フェーズでは、若手メンバーが中心となりデータ移行や試験まわりを推進してくれ、PLを中心にチーム全体がよりよい形にまとまっていきました。
3. 困難なデータ移行
Before：
移行期間中のデータの状態が複雑で、調整負荷が高い状態でした。
Action：
システム構成が利用部署ごとに明確に分かれていたため、分割リリース方針を採用しました。また、移行の半年前には社内ステークホルダー向け説明会を開催し、影響の早期共有と懸念点抽出を行いました。
その後、ユーザー部門・下流システム・ビジネス主幹への影響ポイントを一覧化。公開後も随時アップデートし、関係者が一元的に確認できるようにしました。
After：
リリース影響の見える化により、リリース詳細計画から直前に発生した課題への対応まで、関係者との調整が格段にスムーズになりました。ビジネス主幹をはじめ、社内ステークホルダーの理解と協力のおかげで、システム移行は大きな問題なく完了しました。
振り返り
今回のプロジェクトは、リリース影響が広く運用要件も複雑、かつ在籍期間が浅いメンバーによる対応（技術的不確実性が相対的に高め）という背景のもと、イテレーティブな開発アプローチで進めました。
全体を通して基盤となったのは次の 2 点です。
① 数字による現状把握（プロジェクト内部）
- EVM を中心に、計画と実態を数値で語れるようにしたことで、状況把握と意思決定の安定化につながりました。
② 業務影響・スケジュールの共有（プロジェクト外部）
- リリース影響を見える化し、ユーザー部門・関連システム・ビジネス主幹と前提を共有したことで、移行に向けた調整がスムーズに進みました。
最後に
今回紹介した内容はプロジェクト管理の基本ではありますが、実践を通して効果を強く実感しました。 「計画と実態のギャップを的確に掴む。関係者と共通認識をつくる」という指針について、皆さんの取り組みのヒントになれば幸いです。
最後までご覧いただきありがとうございました。
明日21日目は、山本さんによる「GitHub Copilot向けMCP RegistryをGitHub Pagesで構築する」です。お楽しみに！
JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！ フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。 hrmos.co
まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co
★最新記事のお知らせはぜひ X（Twitter）、またはBlueskyをご覧ください！
