「こういう機能を作りたいのですが、実現可否と概算をください」という相談は、EC開発ではよくある。だが仮フローだけを渡されて概算を出そうとすると、幅が大きくなりすぎて意味のある数字にならないことがある。この記事は、Shopifyアプリの追加開発を相談する側と、見積もりを求められる技術者に向けて、曖昧な要望をどう扱うかを整理したものだ。結論はシンプルで、見積もる前に「ここが分からないと概算すら出せない」というブロッカーを特定し、それを埋めることを最優先にする。むやみに広く質問するのではなく、金額を左右する少数の急所から潰す。
概算を左右するのは「実現可否のブロッカー」
たとえば「ECで在庫を見つけた顧客が、店舗での取り置きを予約する」という機能を考える。仮フローには「外部システム経由で店舗へ取り置き指示」「在庫ステータスを取り置き中に変更」と書かれている。だが、このフローの実現可否と工数を根本から左右するのは、書かれていない次の二点だ。
ひとつは、連携先の外部システムのAPIに何ができるのか。取り置きに使えるステータスがそもそも存在するのか。外部（Shopify側のアプリ）からステータス変更を叩けるAPIがあるのか、それとも外部システムから各チャネルへの一方向連携しかないのか。ここが不明なままでは、実現可否の判断自体ができない。
もうひとつは、複数チャネルにまたがる在庫の排他制御だ。中古品のように1点物を扱う場合、その商品はShopifyだけでなく他のモール（フリマ・オークション）にも同時出品されていることがある。取り置き中は他モールの出品を取り下げる必要があるか。取り下げるとして、それは自動でできるのか、各モール側の操作が別途要るのか。ここを詰めないと、取り置き指示が反映される前に他モールで売れる「二重販売」の事故につながる。
この二点が埋まらないうちは、どんな概算も幅が広すぎて判断材料にならない。だから当社では、まずこのブロッカーを特定し、そこを埋める質問から始める。
モデリングの選択が工数を大きく変える
ブロッカーと並んで工数を左右するのが、「その予約をどう表現するか」というモデリングの判断だ。取り置きをShopify上の「注文」として扱うのか、決済なしの「予約」として扱うのか。0円注文にするのか、下書き注文を使うのか、独自DBで予約を管理するのか。どれを選ぶかで工数はまるで変わる。
こうした判断は、要望の文面には現れない。だが概算段階でも「どの方式を前提に見積もっているか」を明示しておかないと、後で認識がズレる。当社では、見積もりに前提条件を添え、「この方式を想定して算出しています」と書くようにしている。
質問は優先度順に、最低限の急所から
確認したいことを全部並べると、相手も答えきれず、話が進まない。優先度順に整理し、概算に本当に必要な急所から尋ねる。先の例なら、最低限「外部APIのドキュメント開示」「取り置きは注文か予約か」「他モールの取り下げ要否」の三点が埋まれば、前提条件つきで幅のある見積もりは出せる。
逆に、外部APIが存在しない、あるいは開示できないと分かった場合は、Shopify側だけでは完結しない。そのときは無理に固定の概算を出すのではなく、「まず調査フェーズを別途見積もる」提案に切り替えるのが安全だ。分からないものを分かったふりで見積もると、後で必ず破綻する。
図で認識を合わせる ― 特に伝言ゲームになる案件で
要望が曖昧なときほど、文章の質問リストだけでなく、想定アーキテクチャ図をこちらから提示して認識を合わせるのが効く。「この構成を想定していて、赤い部分が実現可否のブロッカー、黄色が設計方針で工数が変わる箇所です」と図で示すと、質問の意図が一目で伝わる。
これは、間に別の担当者が入って伝言ゲームになる案件で特に効果が大きい。あわせて、相手からも現行システムの構成図・連携図をもらうべきだ。どのシステムがどう連携し（API連携かファイル連携か、リアルタイムか日次か）、どこが自社改修可能でどこがベンダー管轄か。これがないと、そもそも仮フローの実現可否を判断できない。当社では、想定図の提示と現行構成図の取得をセットにして、認識合わせと不明点の解消を同時に進めている。
まとめ
曖昧な機能要望を見積もるときは、いきなり数字を出そうとしない。まず「ここが分からないと概算すら出せない」というブロッカー――外部APIの能力と、マルチチャネル在庫の排他制御――を特定する。次に、注文か予約かといったモデリングの前提を明示する。質問は優先度順に急所から絞り、外部APIが確認できないなら調査フェーズの提案に切り替える。そして、想定アーキテクチャ図で認識を合わせる。当社ではこの手順で、幅が広すぎて意味をなさない概算を避け、前提条件つきでも判断できる見積もりを出すようにしている。