「受託開発の経験があれば、自社サービスもできるはず」——私自身、以前はそう考えていました。しかし実際に自社サービスに挑戦してみて、同じ「システムを作る仕事」でありながら、求められる力も、考え方も、大きく違うことを痛感しました。

25年以上、企画・要件定義・設計・開発・運用までを一貫して担当してきた一方で、SNS投稿サポートツール「楽きじ」をリリースし、顧客がまったく付かないという経験もしています。大きな原因は、利用者のニーズに応えるサービスになっていなかったことでした。現在は、お問合せ対応用のAIチャットボットを1人で開発しています。この記事では、受託開発と自社サービスの両方に携わって見えてきた違いを、実感をもとにお伝えします。

違い1：「課題」を、誰が持ってくるか

受託開発

受託開発では、基本的に顧客が課題を持ってきます。「こういうことで困っている」「こんなサービスを作りたい」という起点が、最初から目の前にあります。もちろん、その要望をそのまま受け取るのではなく、背景や本当の課題を掘り下げる作業は必要ですが、「誰かが困っている」という前提は、すでに存在しています。

自社サービス

自社サービスでは、課題そのものを、自分で見つけなければなりません。「誰が、何に困っているのか」「その困りごとは、お金を払ってでも解決したいほど大きいのか」を、自分で調べ、確かめる必要があります。

「楽きじ」で顧客が付かなかった経験は、まさにここでの差でした。受託開発では当たり前に与えられていた「ニーズの存在」という前提を、自社サービスでは自分で確かめなければならない。この違いを、身をもって学びました。

違い2：「正解」の決まり方

受託開発

受託開発では、顧客の承認が一つの正解の基準になります。要件を合意し、仕様を確認し、検収を受ける。この一連の流れの中で、「顧客が求めているものを作れたか」が、比較的はっきりと判断できます。

自社サービス

自社サービスでは、正解を決めてくれる人がいません。利用者が使い続けてくれるか、お金を払ってくれるか、という市場の反応が、唯一の判断基準になります。そして、その反応が返ってくるのは、リリースした後です。つまり、「正しいものを作れたか」が分かるまでに、時間がかかります。

違い3：売上が立つタイミング

受託開発

受託開発では、契約を結ぶことで、一定の売上の見通しが立ちます。作業をした分、あるいは納品した分が収益になるため、「作ったのに、まったくお金にならない」という事態は、比較的起こりにくい構造です。

自社サービス

自社サービスでは、作った分がそのまま収益になるわけではありません。どれだけ時間をかけて作っても、利用者が付かなければ、収益はゼロのままです。開発にかけた時間やコストが、そのまま回収されない可能性を常に抱えることになります。

この違いは、意思決定の重みにも影響します。どこまで作り込むか、どこで見切りをつけるかという判断が、すべて自分の責任になるためです。

違い4：「作る」以外の仕事の比重

受託開発

受託開発では、案件の獲得（営業）や、顧客との関係づくりは必要ですが、サービスを使ってくれる人を集め続けるという仕事は、基本的には発生しません。納品したシステムの利用者を増やすのは、顧客側の仕事です。

自社サービス

自社サービスでは、開発と同じくらい、あるいはそれ以上に、「知ってもらう」「使い始めてもらう」「使い続けてもらう」ための仕事が重要になります。技術者として開発に集中していたい気持ちとは裏腹に、営業、集客、サポートといった仕事の比重が一気に増えます。

1人で企画・開発・運用・営業まで担当する場合、この比重の変化は特に大きく、技術力だけでは補えない領域であることを実感しました。

違い5：求められる「意思決定」の種類

受託開発

受託開発での意思決定は、主に「顧客の要望を、限られた予算と納期の中で、どう実現するか」という実現方法に関するものです。要件の優先順位づけや、技術選定、スケジュール調整といった判断が中心になります。

自社サービス

自社サービスでは、実現方法に加えて、「そもそも何を作るか」「誰に届けるか」「いくらで提供するか」「いつ方向転換するか」といった、事業そのものの判断が加わります。技術者であっても、事業全体の意思決定者として動く必要が出てきます。

受託開発の経験が、自社サービスで活きること

違いばかりを挙げてきましたが、受託開発の経験が自社サービスで活きる場面も、もちろんあります。

  • 曖昧な要望を、具体的な仕様に落とし込む力：自分の中にあるアイデアを、実現可能な形に整理する際に役立つ
  • 予算・納期・品質のバランスを取る感覚：限られたリソースの中で、何を優先するかを判断する際に活きる
  • 一貫して開発から運用までを見る視点：作って終わりではなく、運用まで見通した設計ができる

一方で、これらはあくまで「作る」側の強みです。「作るべきものを見つける」力は、受託開発の経験だけでは身につきにくく、自社サービスに取り組む中で、意識的に補う必要があると感じています。

自社サービスの経験が、受託開発でも活きること

逆に、自社サービスに挑戦したことで、受託開発の仕事にも良い影響がありました。

  • 顧客の「本当のニーズ」を、より意識して聞くようになる：「楽きじ」の経験から、要望の背景や、そのサービスが本当に利用者に求められているかを、以前より強く意識するようになった
  • 事業側の視点で、顧客の悩みを理解しやすくなる：事業の意思決定の難しさを実際に経験したことで、顧客の立場への理解が深まった

これから自社サービスを始める人へ

受託開発の経験が豊富な人ほど、自社サービスでも同じ進め方で成功できると考えがちです。しかし、受託開発では前提として与えられていた「ニーズの存在」を、自社サービスでは自分で確かめる必要があります。この点を意識せずに、「作る」ことから始めてしまうと、「楽きじ」と同じ状況に陥る可能性が高くなります。

自社サービスを始めるなら、まず「誰の、どんな困りごとを解決するのか」を、実際の利用者に確かめるところから始める。この順序を守ることが、受託開発の経験を、自社サービスで活かすための第一歩だと感じています。

まとめ

受託開発と自社サービスの主な違いは、次の通りです。

  • 課題を持ってくるのは、受託では顧客、自社サービスでは自分自身
  • 正解の基準は、受託では顧客の承認、自社サービスでは市場の反応
  • 売上が立つタイミングが、受託では契約時、自社サービスでは利用者が付いた後
  • 「作る」以外の仕事（営業・集客・サポート）の比重が、自社サービスでは大きく増える
  • 求められる意思決定が、実現方法から事業そのものへと広がる

どちらが優れているということではなく、求められる力と考え方が異なるということです。両方を経験したことで、それぞれの強みと難しさが、より立体的に見えるようになったと感じています。