自社プロダクトを持つ開発会社を選ぶべき理由

ベンダーを比較するとき、あまり聞かれないものの、私たちがかなり判断材料になると考えている質問があります。その開発会社は自社プロダクトを持っているか？ 受託案件の実績ではなく、自分たちで作り、リリースし、販売し、自社名で保守しているプロダクトのことです。

私たちは2つのプロダクトを持つ開発会社としてこの記事を書いています。AIで動画のクリップを作るCuplikinと、下宿（インドネシアでは「コス」と呼ばれます）を管理するアプリKosProです。ですから当然、利害関係があります。それでも、どのベンダーを評価する際にも役立つ記事になるよう、デメリットも含めてバランスよく書くよう努めます。

受託案件だけを手がけるベンダーの課題

一般的な受託モデルでは、ベンダーの関わりはアプリの納品で終わります。ベンダーがコードを書き、クライアントが支払い、完了です。技術的な判断の結果、たとえば高額なデータベースの選定、変更しにくいアーキテクチャ、結局使われなかった機能などは、ベンダーではなくクライアントが背負います。

これは悪意の問題ではありません。良いベンダーは全力を尽くします。問題はフィードバックです。リリース後のプロダクトと共に過ごした経験がなければ、3か月目以降に初めて表面化することを学ぶのは困難です。

自社プロダクトを保守して初めて得られる教訓の例を挙げます。

• サーバーやAPIの費用は、ユーザー数ではなく利用量に応じて増える。
• ユーザーが最もよく求める機能は、最初の要件書にあるものとは異なる。
• アプリストアの星1つのレビューは、たいていログインできない、通知が遅い、文言がわかりにくいといった小さなことが原因。
• OSのアップデートやアプリストアのポリシー変更で、予定外の改修を迫られることがある。

CuplikinとKosProから学んだこと

私たちの2つのプロダクトはまったく性質が異なり、だからこそ得られる教訓が補い合っています。

詳しい経緯は、Cuplikinをアイデアからリリースまで作った話とKosProの開発記に書いています。

発注側にとってのメリット

ここが本当に重要な部分です。発注する側にとって、何が違うのでしょうか。

より根拠のある見積もり

自社プロダクトでスケジュールを守れなかった経験のあるベンダーは、見積もりに慎重になります。KosProの「請求リマインダー」機能は、日付のルールが複雑だったため、当初の見積もりよりはるかに時間がかかりました。私たちはそれを身をもって知っています。その経験が、クライアント向けに似た機能を見積もる際に活かされています。

運用コストへの意識

Cuplikinで毎月のAI分析費用を自分たちで負担してきた今、会話あたりのコストを説明せずに「AIチャットボット」を販売することは決してありません。これはベンダーの見積もりから抜け落ちがちな部分で、詳細はアプリ開発の費用で解説しています。

納品で終わらず、保守する習慣

自社プロダクトがあるからこそ、テストのパイプライン、エラー監視、再現性のあるリリース手順を整えざるを得ません。この習慣の基盤を、そのまま受託プロジェクトにも使っています。両方を同じチームが担当しているからです。

自分で確かめられる証拠

私たちのような若い会社にとって、プロダクトは最も正直な実績です。KosProをダウンロードし、Cuplikinを試し、レビューを読んで、品質をご自身で判断していただけます。検証できない導入事例を信じる必要はありません。

正直にお伝えすると： 自社プロダクトがあるということは、私たちの集中力が分散するということでもあります。Cuplikinの重大なバグに、クライアントのスプリントと同じ日に対応しなければならない週もあります。私たちの対処法は、クライアントとの週次デモのスケジュールを拘束力のあるものとし、プロダクトの作業はそれ以外の時間に組み込み、誰がプロジェクトを担当しているかをクライアントが常に把握できるようにすることです。プロダクトを持つベンダーを選ぶなら、同じことを質問してみてください。

具体例：自社プロダクトによって変わった判断

抽象的な話にならないよう、日々の仕事から一つ例を挙げます。

Cuplikin以前は、クライアントから「AIで文書を要約する」機能を求められると、私たちの見積もりは開発期間だけを計算していました。API連携、画面、テストです。Cuplikinの費用構造を設計し、AIの費用を自分たちで払うようになってから、同じ依頼への答え方がまったく変わりました。今、最初に聞くのは「作るのにどれくらいかかるか」ではなく、次の質問です。

• 1日に何件の文書を処理し、平均の長さはどれくらいか？
• 再処理しなくて済むよう、結果を保存する必要があるか？
• このタスクにはどのモデルで十分か？ 最も高価なモデルが社内文書の要約に優れているとは限らない。
• リリース後に月々の費用を誰が監視し、どの金額でアラートを出すか？

この4つの質問への答えによって、効果を損なうことなく、月々の費用が数倍変わることがあります。こうした知識はAPIのドキュメントには書かれていません。自分で請求書を払い、その金額に驚いて初めて身につくものです。

KosProからの2つ目の例です。以前はPlayストアへのリリース手続きを1日で終わる形式的な作業と考えていました。開発者アカウントの認証、クローズドテスト、データセーフティフォームを自分たちで経験してからは、すべての提案書のリリーススケジュールに専用の期間を設けています。プライバシーポリシーや、私たちではなくクライアント企業名義の開発者アカウントなど、クライアントに準備していただく書類のリストも添えています。

どちらも小さなことです。しかし、プロジェクトが失敗するのは、たいてい一つの大きなミスではなく、誰も予想しなかった小さなことの積み重ねが原因です。

反対の視点：自社プロダクトが警告サインになるとき

公平のために言えば、「プロダクトを持っている」ことが良いサインにならない状況もあります。

• 放置されたプロダクト。 最終更新が2年前で、レビューにも返信がないアプリは、ベンダーが見放したことを示しています。貴社のプロジェクトも同じ扱いを受けるかもしれません。
• チームの規模に対してプロダクトが多すぎる。 5人のチームが4つのプロダクトと受託案件を回しているなら、貴社に割ける時間がどれだけ残るか計算してみてください。
• カスタマイズを断る口実としてのプロダクト。 ニーズが異なるのに、自社プロダクトをクライアントに押し付けるベンダーもいます。自社プロダクトは経験を増やすためのものであり、解決策を制限するものであってはなりません。
• 利益相反。 ベンダーのプロダクトが貴社の事業と直接競合する場合は、共有するデータやアイデアについて慎重に考えましょう。

ベンダー選びにどう活かすか

開発会社選びのチェックリストに、次の質問を加えてください。

1. 自社プロダクトはありますか？ リンクを見せてもらえますか？
2. 最終更新はいつで、何が変わりましたか？
3. そのプロダクトから得た教訓のうち、受託プロジェクトの進め方を変えた最大のものは何ですか？
4. 自社プロダクトと私たちのプロジェクトの間で、時間をどう配分していますか？
5. 私たちのプロジェクトは誰が担当し、その人は自社プロダクトも担当していますか？

良い回答は具体的で、難しさも認めています。自社プロダクトを褒めるだけの回答なら、さらに掘り下げて質問するサインです。

それでも私たちがこの道を選ぶ理由

受託案件だけに集中することもできます。短期的には、そのほうがシンプルで利益も出ます。それでもプロダクトを作り続けているのは、クライアントの立場にいるとはどういうことかを知っている開発会社でありたいからです。サーバー代を払い、ユーザーレビューを読み、どの機能に自分たちのお金をかける価値があるかを決める。その立場です。

居心地の悪さも含めたその経験を、私たちは仕事の進め方のすべての段階と、提供するサービスに活かしています。

次のステップ

ご自身で判断したい方は、KosProやCuplikinを試したうえで、プロジェクトについてご相談ください。初回相談は無料で、上の5つの質問を私たちに直接ぶつけていただけます。最も早いのはWhatsAppです。メール（hello@rancanginaja.com）でもご連絡いただけます。