移行プロジェクトの上流工程で学んだこと5選 ― 解像度が低い時こそ「ゴール」から逆算する ―

この記事はウィルゲート Advent Calendar 2025 24日目の記事です。

adventar.org

こんにちは!ウィルゲート開発室のりさりさ(@will_risarisa)です。

今回は、基幹システムの移行プロジェクトに品質担保の立場で参加した際に感じた「上流工程の難しさ」と、そこから得られた気づきについてまとめます。プロジェクトの初期段階から関わることで、日々の開発業務ではなかなか経験できない抽象度の高いタスクに触れ、多くの学びを得ました。同じような状況にある方の参考になれば幸いです!

移行プロジェクトの背景

長年使用してきた基幹システムの技術的負債を解消し、ライセンス費用も削減する目的で進めているプロジェクトです。

同じCRM移行プロジェクトに携わっているPMOの視点でまとめられたブログも公開されています! プロジェクト推進側の視点から、課題整理や進行管理について紹介されていますのでぜひこちらもチェックしてみてください |д゚) tech.willgate.co.jp

プロジェクトで担当した役割

移行プロジェクトでは、品質担保として以下の役割を担当しました。業務範囲は多岐にわたり、特に上流工程に深く関わる経験はこれまで少なかったため、新しい発見が多い期間でもありました。

  • 移行計画書の作成
  • テスト観点の整理
  • 結合テスト・シナリオテストの作成と実施
  • 仕様の抜け漏れ検知
  • ベンダーとのコミュニケーション

実装工程より前の“設計”や“計画”に踏み込むことが求められ、決めるべきこと・整理すべきことの多さに圧倒されつつも、非常に密度の濃い業務でした。

上流工程の難しさを実感した理由

今回のプロジェクトでは、これまで経験してきた領域とは異なる上流工程に多く触れる中で、その難易度を強く実感しました。

CRM領域の知識が追いつくまでに時間が掛かった

CRM は業務の幅が広く、画面・データ・運用が密接に絡み合っています。関連性が掴めない状態では仕様の判断が難しく、理解を深めるまで相当な時間を必要としました。

まずは理解するために、要件定義書を読み漁り分からないことをすべて書き出しました。 分からない点はすぐ、プロジェクト関係者に認識の相違がないかの確認をし自身の解像度を上げる作業をひたすら繰り返しました。

要件を大枠理解した後、機能としてどうなっているかを理解するのに『文字情報』だけで理解することは難しいものがありました。 すでにシステムの枠(デザインのみ)があれば照らし合わせる形で、画面からの操作はどう行い、内部でどう動いているのか答え合わせをすると良いと思います。

要件定義で詰め切れていない内容が後工程に影響した

改修依頼を進める中で、要件定義段階で詰め切れていない部分が原因の“考慮漏れ”が想像以上に多く発生しました。要件が曖昧なまま進むと、後になってから追加修正や説明が必要にな り、工程全体に影響が及ぶことを痛感しました。

細かい点でいうと、機能追加をした時下記ようなブレがあり差し戻しなども多く発生しました。

  • 日付形式の統一
    • YYYY年MM月DD日のところと、YYYY/MM/DD で異なる
  • ステータス
    • 「処理済み」「完了」などの表記揺れが発生

抽象度の高いタスクの進め方に苦戦

特に移行計画の策定では「何から決めるべきか」「どこまで具体化するべきか」といった判断が難しく、抽象的な状態のタスクを扱う難しさを体感しました。考え方の順序や押さえるべきポイントが分からないまま進めると混乱しやすく、頻繁に立ち止まって整理が必要でした。

プロジェクトを通して得られた気づき

ここからは、今回のプロジェクトで得られた学びをまとめます。項目ごとにどのような気づきがあったかを深掘りして記載しています。

1. まず“全体像”と“ゴール”から考える習慣

序盤は、細かい作業に意識がいきがちで、大項目がずれたまま作業に入ってしまうことがありました。特に移行計画は抽象度が高く、タスクを手順レベルに落とし込むタイミングを間違えると全体の構造が見えなくなります。

そこで意識したのは、最初に“あるべき姿”を想像し、全体像から先に描くこと。ゴールが明確になるだけで、判断の軸が整い、タスクの優先度も見えやすくなりました。迷ったら一旦全体に戻る──これが上流工程ではとても重要だと実感しました。

2. 逆算スケジュールで動くことの重要性

全体スケジュールとは別に、自分用のスケジュールを逆算で作ることの重要性を痛感しました。積み上げで進めると、気づいた時には期限が迫っている、という状況になりがちです。

特に外部との連携が週単位で動く場面では、1日の遅れがそのまま1週間の遅れに直結します。「この会議までに何が必要か」「次のレビューまでに何を決めるべきか」を明確にして逆算で動くことで、遅延や認識齟齬の発生を最小限に抑えられました。

3. 解像度が低いときほど焦らず全体を見直す

CRM領域は情報が多く、最初は理解できない部分が多くありました。焦って進めると判断ミスにつながることも。そんな時に有効だったのが、理解できている範囲の洗い出しや、関連性の整理です。

  • 分かる部分だけを一度まとめる
  • 点と点を線でつなげていく
  • 分かる部分から順に解像度を上げる

このプロセスを繰り返すことで、段々とシステム全体が見えてくるようになり、判断の精度が上がりました。

4. コミュニケーションの質を整える

今回特に実感したのは、上流工程ほどコミュニケーションの質が成果に直結するということです。

相手の認識から確認する

以前は、自分の認識を先に伝えてから合意を取ろうとしていました。しかし、この方法では相手の前提が見えづらく、後から認識齟齬が発生しがちです。

まずは「相手がどう理解しているか」を確認した上で話を進めると、双方の前提が合いやすく、調整もスムーズに進みました。結局のところ、認識合わせの鍵は“相手の視点”にあります。

伝え方に背景と重要度を添える

要望だけをそのまま伝えると、相手の負担が大きくなりがちです。そこで、「なぜ必要なのか」「どの程度重要なのか」といった背景を添えて伝えるようにしました。

ただ伝えるのではなく、相手に伝わるように工夫することで、協力的な関係を築きやすくなり、結果としてプロジェクト全体の進みも良くなりました。

5. 不安に負けず“仮のゴール”を置いて進める

上流工程では、正解がはっきりしないことが多く、最初の一歩を踏み出す際に不安を感じる場面がありました。そこで意識したのが、一旦“仮のゴール”を置くという考え方です。

仮の結論を置くことで、タスクの方向性が生まれ、次に考えるべきことが明確になります。途中で修正してもよいと割り切ることで、不安に飲み込まれず進めるようになりました。

伝えたいメッセージ

上流工程に取り組むことは難しく、不確実性も多いですが、その分得られる学びは非常に大きいです。抽象度の高いタスクに向き合った経験は、今後のプロジェクトでも確実に役立つと感じています。

もし機会があれば、ぜひ上流工程にチャレンジしてみてください。経験すればするほど、視野が広がり、プロジェクト全体を捉える力が鍛えられると思います。

ウィルゲート Advent Calendar 2025」、翌日はGM池添さんの「計画通り行かない不確実性の中で磨かれた開発組織 ― ウィルゲートVPoEが振り返る2025年 ―」です!