Shopifyストアへの追加機能開発では、レビュー、検索、レコメンドといった領域に必ず既存アプリの選択肢があります。要件定義書に「レビューアプリを使用予定」と書かれていると、それだけで工数が読めた気になりますが、これは危険です。既存アプリで要件を満たせるかどうかの見極めこそが、見積もり金額を数倍動かす最大の変数だからです。本記事は、Shopifyの追加開発を発注する事業者と、見積もりを作る技術者に向けた内容です。
「アプリを使う」には三つの段階がある
レビュー機能を例に考えます。「レビューアプリを使う」と一言で言っても、実際には次の三段階があります。
ひとつ目は、アプリの標準UIをそのまま埋め込む方式。工数は最小ですが、実現できるのはアプリが提供する機能の範囲だけです。ふたつ目は、アプリをデータストアとして使い、APIで取得した内容に独自のUIを被せる方式。表示の自由度は上がりますが、投稿フローや権限まわりをアプリの仕様に合わせ込む必要があり、工数は跳ね上がります。三つ目は、アプリを使わず完全に独自実装する方式です。
問題は、要件のごく一部がアプリの標準機能を超えるだけで、一気に二段目・三段目へ落ちてしまう点です。たとえばレビューであれば、投稿ごとの実名とペンネームの切り替え、投稿者属性の自動表示、下書き保存、表示名を変更したときの過去投稿への遡及反映。こうした要件は、レビューアプリの標準機能の範囲を超えている可能性が高い。ワイヤーフレームに一行書かれているだけの要件が、実装方式を丸ごと変えてしまうわけです。
当社では、この種の要件を見つけたら見積もり作業に入る前に、まず「標準UIで妥協するか、独自UIを被せるか、完全独自にするか」の方針決定を事業者に求めます。ここを決めずに積んだ金額には、意味がありません。
検索は「標準でできない」ことを前提に置く
同様に見落とされやすいのが検索です。Shopifyの標準検索は商品名や説明文に対する素直な検索であり、本文の全文検索、ヒットした箇所の表示、件数付きファセット、評価順のソートといった要件は、標準の範囲では実現困難です。
外部の検索サービスを導入するのか独自実装にするのかで、初期費用も月額のランニングコストも変わります。さらに、検索対象となるデータを外部から取り込むパイプラインが必要になるケースも多く、これは検索機能そのものとは別の工数です。「検索機能」という一行の裏に、データ取り込み基盤が隠れていないかを必ず確認します。
複数機能にまたがる基盤は、独立項目として切り出す
追加開発の見積もりでもうひとつ重要なのが、機能横断で使われる基盤の扱いです。たとえば「お気に入り」や「いいね」の仕組みは、商品詳細ページ、キャンペーンページ、マイページなど複数の機能から参照されます。これを特定の機能の内訳として埋め込んでしまうと、その機能が予算調整で削られたときに、他の機能まで巻き添えで壊れます。
当社では、複数機能にまたがる基盤は共通項目として見積書上で独立させます。こうしておくと、事業者が予算を絞りたいときに「どの機能を削るとどこまで安くなるか」を正しく提示でき、削れないものが明確になります。見積書の構造そのものが、意思決定を支援する道具になります。
減額オプションを、見積書にあらかじめ書いておく
見積もりを提出した後、ほぼ必ず「もう少し安くならないか」という話になります。ここで場当たり的に値引きすると、根拠のない金額になり、スコープも曖昧になります。
当社では、見積書の中に減額オプションを最初から併記します。たとえば「レビューをアプリの標準機能で妥協した場合はいくら減額」「外部検索サービスを利用する構成にした場合は初期費用がいくら減額、ただし月額が発生」「購入者判定との連動を次フェーズに切り出した場合はいくら減額」といった形です。
これには二つの効果があります。ひとつは、金額の交渉が「値引き交渉」ではなく「スコープの選択」になること。もうひとつは、なぜその金額なのかという説明が、機能の中身に紐づいて成立することです。特に、見積書に工数を載せず金額のみを提示する場合、単価で金額差を説明できなくなるため、機能の複雑さで説明できる構造をあらかじめ作っておく必要があります。
「なぜ標準機能では実現できないか」を見積書に書く
減額オプションと表裏一体なのが、前提条件の明文化です。独自実装で金額を積んだ項目については、なぜ既存アプリの標準機能やShopifyの標準機能では実現できないのかを、見積書の前提条件として書いておきます。
これを書いていないと、事業者からは「アプリがあるのになぜ作るのか」という当然の疑問が出ます。そして口頭で説明した内容は残らないため、担当者が代わったタイミングで同じ議論が再燃します。見積書に書いてある前提は、後から議論を蒸し返されたときの共通の土台になります。
まとめ
追加開発の見積もりで最初にやるべきは、工数を積むことではなく、既存アプリが要件をどこまで満たすかを一つずつ検証することです。当社では、アプリ依存度が高い機能については実装方式の方針決定を先に求め、機能横断の基盤は独立項目として切り出し、減額オプションと前提条件を見積書に併記します。そうすることで、見積書が「金額を伝える紙」から「事業者が意思決定するための道具」に変わります。