つくる前の判断が、
開発の成否を決めます。

Shopifyはできることの多い仕組みですが、どんな事業にも万能ではありません。
実際に、開発のご相談をいただいたあとで「Shopifyではない方がよい」とお伝えし、前提から考え直していただいたこともあります。
方法を探せば、形にはできたかもしれません。ですが、合わない道具に運用を合わせ、そのずれを何年も抱える方が高くつきます。

つくれるかだけでなく、使い続ける時間まで含めて、道具との相性を見ています。

実装方法を考える前に、受け取る人と運用する人に「何が起きればよいか」まで戻ります。
ある案件では、決まった形式の書類を発行して送る仕組みが必要だと伺いました。ところが目的を確かめると、必要だったのは書類そのものではなく、決まった情報が確実に届くことでした。

そこで、すでに使われている通知に必要な情報を組み込み、受け取る側には同じ内容が届き、運用側には新しい作業が増えない形で解決しました。

目的まで戻ると、つくる量を減らしながら、より自然な答えが見つかることがあります。

独自開発の前に、すでに使える手段で解けないかを順番に確かめます。
理由は開発費だけではありません。公開したあとに誰が保守し、Shopifyの変化に誰が追いつくのかまで考えるからです。
公開アプリなら、その保守やアップデートを多くの利用者で分担できます。同じ機能を独自につくれば、その責任はこの先、お客様と私たちで背負うことになります。

実際に、購入時の動きを細かく制御したいというご相談でも、独自開発ではなく、テーマと運用の組み合わせで目的を満たしたことがあります。費用を抑えながら、あとから自分たちで調整できる余地も残りました。

同じ「アプリの利用料が高い」というご相談でも、事業の規模やフェーズによって答えは変わります。
事業に対する負担が大きく、独自開発による効果が十分なら、保守の責任を引き受けてでもつくる意味があります。まだ負担が小さいなら、公開アプリを使い続ける方が身軽です。

見るのは金額そのものではなく、事業に占める負担と、独自開発で得られる効果です。

さらに、独自につくれば、その瞬間から保守も自分たちの責任になります。変更するたびに開発会社への依頼が必要な構成は、お客様自身で動かせる範囲を狭めます。
いま払う費用と、あとに残る依存。その両方を見て決めます。

Shopify Plusでなければ実現できない要件が出てきたときに、初めて検討します。
選べる機能が増えることと、いまの事業に必要な機能が増えることは同じではありません。
「将来使うかもしれない」という理由だけで上位プランにすれば、まだ使わない機能のために固定費だけが先に増えていきます。

必要になったときに、その時点の要件と事業の状態で選ぶことができる。そういった点もShopifyを選ぶ理由の一つです。

外部システムとの連携で見るのは、つなぎやすさより、つないだあとも自分たちで運用を決められるかどうかです。
特定の連携サービスに依存すると、そのサービスの制限が、できることの上限になります。仕様に合わせ続けるうちに、本来の運用よりも連携側の都合が優先されてしまうこともあります。
渡すデータも、つなげられるからといって全部渡しません。目的に必要なものだけを境界の外へ出します。

依存する範囲を小さくしておけば、相手の仕様が変わっても、影響する範囲を小さくできます。

お見積りは、ページ数ではなく、新しく設計・実装する範囲をもとに組み立てます。
同じページ数でも、すべてを新しくつくる場合と、すでにある仕組みを組み合わせる場合では、必要な仕事量はまったく違います。

既存のセクションを再利用できる。標準機能で済む。設定だけで対応できる。
そうした部分まで、新規開発と同じ金額で計算することはしません。
何に、どれだけ費用がかかるのか。理由がわかる見積もりをつくります。

ご予算に届かないからといって、同じ仕事を安く引き受けることはしません。
無理に金額だけを下げれば、設計や検証、データの持ち方など、あとから効いてくる部分にしわ寄せが出るからです。

その代わり、目的と優先順位を整理して、
今やること。
余裕があればやること。
次の段階へ回すこと。
に分けます。

必要なところから小さく始め、見送ったものも次に進むための選択肢として残す。
予算を削るのではなく、予算の中でいちばん価値が残る範囲を決めます。

確認という工程そのものが、お客様の時間を使います。
画面を開く。内容を確認する。社内で意見を集める。返答をまとめる。
確認という工程そのものにも、お客様の時間がかかります。

関わる範囲が大きい案件は、早い段階から細かく区切って方向を合わせる。範囲が限られている案件は、まとめて確認する。戻るリスクと確認の負担を見ながら、進め方を調整します。

ただし、確認を減らすこと自体が目的ではありません。
公開前の最終確認と、双方でのテストは必ず行います。

つくったものは、お客様自身が持ち、動かせる状態でお渡しします。
コードも、運用に必要なアカウントも、お客様の資産です。データも特定のアプリや私たちだけが扱える状態に閉じ込めず、将来ほかの方法へ移る可能性まで考えて設計します。
変更するたびに私たちへの依頼が必要な状態は、できるだけ残しません。

運用が整ったあと、私たちがいなくても動き続ける。
それが、納品後の理想です。

できないことやリスクを後から出さないために、着手前に前提を揃えます。
条件に難しさがある場合は、どこに問題があるのかを先にお伝えし、前提を変えれば進められるのかも一緒に考えます。
ご予算が限られているだけで、お断りすることはありません。今回やることと将来へ回すことを分けられるなら、小さく始める方法も考えます。

一方で、次のような条件ではお引き受けできないことがあります。