Forest Book
大型連携案件のスケジュールは依存関係で決まる ― 待つ工程・並行できる工程と、圧縮で削ってはいけないもの

大型連携案件のスケジュールは依存関係で決まる ― 待つ工程・並行できる工程と、圧縮で削ってはいけないもの

2026年8月3日

外部システムと連携するShopify案件のスケジュールを引くとき、「ストア構築が終わってから開発着手」と単純に直列で並べてしまうと、実態と合わない。この記事は、EC事業者と、大型連携案件のスケジュールを設計する技術者に向けて、依存関係の見極め方と、リリース日が固定されたときの圧縮の判断を整理したものだ。結論は二つ。ひとつ、ストア構築完了を待つ工程は実は多くなく、本当のボトルネックは別にある。ふたつ、リリース日を守るために工程を圧縮するときも、削ってよい工程と絶対に削ってはいけない工程がある。

「ストア構築完了待ち」の工程は思ったより少ない

連携案件では「ストア構築が終わらないと開発に入れない」と考えられがちだが、実際に完全な待ちになるのは限られている。テーマへの組み込みが必要な部分――ログイン導線の埋め込み、マイページ上の購入済みコンテンツ表示、テーマ拡張の埋め込み――と、注文発生から基幹・WMSまで通す結合テスト、受入テスト、本番切替リハーサル。ここは確かに構築完了を待つ。

一方で、外部連携やバックエンドの多くは並行して進められる。各外部システムのIF仕様確認と連携仕様書の作成、中間連携基盤の方式設計と環境構築、冪等性・リトライ・連携ログ・再送管理の設計と実装、視聴権限やデータモデルの設計。これらはストア構築を待たずに着手できる。

つまり、真のボトルネックは「ストア構築の完了」ではなく、開発ストアの早期払い出しと、商品・注文のデータモデルの確定だ。開発ストアさえ早めにもらえれば、外部連携側はほぼ並行で進められる。商品タイプやメタフィールド定義、バリアント構成、税率区分、会員ランクの持ち方といったデータモデルが固まらないと、マッピングの実装に入れない。だから当社では、スケジュールを引く際に「何を待つか」ではなく「何さえもらえれば並行で走れるか」を先に洗い出し、開発ストアの払い出しとデータモデル確定を最優先の依頼事項として前に出している。

クリティカルパスは認証連携に置く

大型のEC連携では、会員基盤との認証連携がクリティカルパスになりやすい。採用するShopifyプランによって実現方式が変わり、方式決定が遅れると全体が同じ幅で後ろ倒しになるからだ。だからスケジュール上は、この方式決定を要件定義フェーズの中で厚めに期間を取り、最優先で潰す前提にする。認証イベントを起点に権限を付けられない構成になる場合は、注文Webhookを起点にしつつ定期突合バッチで補う、といった設計前提もこの段階で固めておく。

リリース日が固定なら、削るのは前工程・守るのはテスト

リリース日が動かせない場合、標準所要期間では収まらないことがある。そのとき何を削り、何を守るか。当社の判断は一貫している。要件定義と基本設計は圧縮し、各フェーズをオーバーラップさせてIF単位で流す。逆に結合テストは削らない、むしろ厚くする。

理由は復旧余地にある。とりわけ年末年始や大型連休をまたぐ切替は、失敗したときにリカバリする時間がない。ここでテストを削ると、事故が起きたときに立て直せない。前工程の圧縮は要員の増強やオーバーラップである程度吸収できるが、テストの薄さは本番で顕在化する。だから「収めるために削るのは前工程、増やすのはテスト」という優先順位を崩さない。

データ移行のリハーサルも同様だ。移行対象の件数が未確定なら、1回目で所要時間を実測し、2回目で切替手順込みの本番相当リハとする、という二段構えにする。移行は一発勝負にしない。

圧縮には「成立条件」と「捨てる順番」を添える

スケジュールを圧縮するときは、それが成り立つ条件を明示する。たとえば要件定義を短縮する案なら、「外部システム各社の仕様回答が指定日までに揃うこと」「開発ピーク時に必要な要員を確保できること」が成立条件になる。条件を書かずに短い線表だけ出すと、守れなかったときに責任の所在が曖昧になる。

あわせて、遅延が見えたときに何を落とすかの優先順位も先に決めておく。一部の機能を後続フェーズに分離すれば、初期スコープが軽くなり、繁忙期のリスクも避けられる。当社では、圧縮した線表には必ず「成立条件」と「いざというとき落とす機能の順番」をセットで添え、着手前に合意しておくようにしている。線表は約束ではなく、前提つきの見通しであることを共有しておくことが、後のトラブルを防ぐ。

まとめ

大型連携案件のスケジュールは、工程を直列に並べるのではなく、依存関係で決まる。ストア構築完了を待つ工程は少なく、本当のボトルネックは開発ストアの早期払い出しとデータモデルの確定だ。認証連携はクリティカルパスに置いて最優先で潰す。リリース日が固定なら、要件定義や基本設計は圧縮しても、結合テストと移行リハーサルは削らない――年末年始の切替には復旧余地がないからだ。当社では、圧縮した線表に成立条件と機能を落とす順番を添え、着手前に合意することで、無理な直列スケジュールが招く手戻りと事故を避けている。