経営判断ケース 2026-08-31

「お客様ごとの要望」にどこまで応えるべきか

favyの個社カスタム開発から考える、標準化と顧客適合の境界

今日は月曜日なので、商品・サービス設計と事業戦略をテーマにします。

商品やSaaSを伸ばしていくと、ある段階から「標準機能では足りない」「自社の業務に合わせてほしい」という要望が増えてきます。

ここで難しいのは、顧客の要望に応えれば受注しやすくなる一方、何でも個別対応すると開発・運用が複雑になり、利益が残らなくなることです。

つまり問題は、顧客の声を聞くか、標準化を守るかではありません。

どの顧客要望を個別対応し、どの要望を共通機能へ昇格させ、どこから先は断るのかを設計することです。

実際のケース

飲食店・商業施設向けにモバイルオーダーやサブスクリプションSaaSを提供するfavyは、2026年8月、既存SaaSをベースに企業ごとの機能を追加開発する「個社カスタム開発サービス」を開始しました。

favyによると、同社のモバイルオーダー・サブスクは全国3,500以上の拠点に導入されています。

導入先が増えるにつれ、顧客からは例えば次のような要求が増えていました。

自社会員基盤、POS、基幹システムと深く連携したい
自社ブランドに合わせて注文画面のUI/UXを作り込みたい
本部、エリアマネージャー、店長ごとに必要な専用ダッシュボードがほしい
商業施設全体で複数テナントの売上や稼働を統合管理したい

標準SaaSだけでは対応しづらい一方、フルスクラッチ開発では数千万円規模のコストや年単位のリードタイムになる場合があります。

そこでfavyは、エンジニアやプロジェクトマネージャーが店舗や本部に入り、実際の業務を確認しながら、既存SaaSをベースに個別機能を追加する方式を採用しました。

特徴的なのは、要件定義書だけを受け取るのではなく、現場で課題そのものを一緒に定義し、最短2週間のサイクルで開発・検証を進める点です。

料金も、通常のSaaS料金だけではなく、初期開発費＋月額運用費という形です。

さらに、個別開発した機能のうち他社にも有用なものは、今後SaaSの標準機能へ戻していく方針を示しています。

また同社は2026年8月26日、商業施設内の複数店舗の商品を一つのカートに入れ、一回で事前決済できる「横断型事前決済モデル」を発表しました。第1号はBLUE FRONT SHIBAURAのフードホールで、8月19日から運用されています。

これは今回の個社カスタム開発と同一案件だと公表されているわけではありませんが、商業施設では「1店舗単位の機能」だけでなく、施設全体の回遊や複数テナント横断の体験設計が求められることを示す例です。

ここで考えてみましょう

問1

顧客から「この機能を付けてくれれば契約する」と言われた場合、どのような条件なら個別開発を受けるべきでしょうか。

逆に、売上が見込めても断った方がよい要望はどのようなものでしょうか。

問2

個別対応を増やしながらも、会社が「受託開発会社」にならず、標準商品・SaaSとして成長し続けるには、商品・契約・開発の仕組みをどう設計すればよいでしょうか。

解説

問1の答え

判断軸は、**その顧客が大きいかどうかだけではなく、「その要望が将来の市場にもつながるか」と「採算が取れるか」**です。

例えば、次の条件がそろう要望は受ける価値があります。

同じ業界・顧客層で繰り返し発生しそうな課題である
既存商品の強みを壊さず、拡張として実装できる
開発費だけでなく、その後の運用・保守まで価格に反映できる
その顧客の導入によって、新しい市場や顧客層へ展開できる
将来的に標準機能として他社へ横展開できる可能性がある

逆に注意したいのは、その1社だけの特殊な業務を、その会社専用のロジックとして大量に抱えるケースです。

仮に1,000万円の売上が立っても、その後毎年エンジニアが張り付き、他の顧客へ転用できず、バージョンアップのたびに個別改修が必要なら、見た目の売上ほど事業価値は高くありません。

大口顧客だから受けるのではなく、

「顧客固有部分」と「市場共通部分」を分けられるか

を見ることが重要です。

問2の答え

個別対応を事業成長につなげるには、個別開発を本体の商品から切り離すのではなく、“商品を学習させる仕組み”として設計することです。

例えば、次のように3層に分けます。

① Standard Core

全顧客共通で使う機能。

認証、注文、決済、会員、基本レポートなど、商品として絶対に一本化する部分です。

② Extension

顧客ごとの業務に合わせて追加できる部分。

POS連携、基幹連携、専用ダッシュボード、権限、UIなどです。

ここはAPIや設定、拡張モジュールで差し替えられる構造にします。

③ Customer Specific

その会社だけに必要な特殊要件です。

ここは別料金とし、本体へ無条件に組み込まないようにします。

この境界を曖昧にすると、顧客が増えるほど製品が複雑になります。

売上だけで評価しない

個別開発を始めると、売上は増えやすくなります。

しかし見るべきなのは、契約金額だけではありません。

例えば、

初期開発売上：800万円
月額追加売上：30万円
初期開発工数：500万円相当
導入後の年間保守工数：250万円

だった場合、初年度は利益が出ても、毎年250万円の個別保守が続けば、月額360万円の追加売上の大半を消費します。

逆に、その開発を標準化して翌年5社へ展開できれば、最初の1社への個別開発が「製品投資」に変わります。

つまり、個別案件では、

案件粗利だけでなく、再利用率を見る必要があります。

例えば、

開発した機能の何％が共通化できたか
同じ機能を何社へ展開できたか
個別保守時間が増えていないか
標準機能との差分が増えすぎていないか

といった指標です。

では、どう設計するか

実務的には、次の順番が考えやすいです。

第1優先：受ける要望の基準を決める

「顧客が欲しいと言ったから」ではなく、市場性、再利用可能性、戦略性、採算性で判断します。

第2優先：初期開発費だけで終わらせない

個別機能には運用・保守が発生するため、月額料金や保守料金まで含めて収益設計します。

第3優先：個別機能を定期的に標準化判定する

3社以上から同様の要望が出た機能、利用率が高い機能などは標準プロダクトへ戻します。

第4優先：断る仕組みを持つ

売上が大きくても、製品構造を壊す、保守できない、将来性がない要望は断る判断も必要です。

今日のポイント

顧客の要望に応えることと、商品を標準化することは、本来は対立しません。

重要なのは、

個別案件 → 学習 → 共通化 → 標準商品強化

という循環をつくれるかです。

個別対応を「売上を取るための例外」と考えると、会社は受託開発化しやすくなります。

一方、個別案件を市場理解の入口として使い、再利用できる部分を標準商品へ戻せれば、顧客ごとの課題解決がそのまま製品競争力になります。

参考情報

favy「モバイルオーダー・サブスクSaaS導入企業向けにFDE型の個社カスタム開発サービスを提供開始」（2026年8月12日）
https://prtimes.jp/main/html/rd/p/000000357.000016506.html
favy「横断型事前決済のオーダーシステムを提供開始」（2026年8月26日）
https://prtimes.jp/main/html/rd/p/000000360.000016506.html