システム開発会社の集客方法｜いま使える手段と、優先順位の決め方

なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。

現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。

今月の無料診断は残り4社です

無料マーケ診断を申し込む

広告からLPまで、まとめて見ます。オンラインで30分から対応しています。

システム開発会社の集客で、まず直すべきはどこか

受託開発の会社から相談を受けると、最初に出てくるのは問い合わせが少ないという話です。
ところが中身を聞くと、問い合わせはそれなりに来ていることが多いです。
来ているのに売上にならない。
理由は、見積もれない相談だからです。

業務を効率化したいアプリを作りたいだけの相談は、要件定義の前段階です。
ここから提案書を作ると、数日から数週間の工数が飛びます。
そして半分以上は失注します。
受注できても、聞いていた話と違う要件が出てきて赤字になります。

明示すべき四つのこと

サイトに書くべきことは、実績の羅列ではありません。
次の四つです。

サイトで先に示しておくこと

これを書くと問い合わせは減ります。
減ってよいです。
減るのは、もともと受注できなかった相談です。

減らしてはいけない問い合わせ

発注側はどんな言葉で検索して、開発会社にたどり着くのか

開発会社のサイトでよく見るのは、対応言語とフレームワークの一覧です。
発注側は、その言葉で検索しません。
情報システム部門の担当者ですら、まず業務の言葉で調べます。

実際に検索される言葉の形

検索される言葉は、だいたい三つの型に分かれます。

一つめは、業務名と開発を組み合わせた形です。
勤怠管理 システム 開発生産管理システム 構築。
二つめは、費用を知りたい形です。
業務システム 開発 費用 相場スマホアプリ 開発 いくら。
三つめは、比較検討の形です。
パッケージ 自社開発 どちらシステム開発 会社 選び方。

この三つに対して、それぞれ答えるページがあるかどうかが入口の数を決めます。

技術で選ばれる場面もある

ただし例外があります。
発注側に技術が分かる人がいる場合、技術スタックで絞り込まれます。
既存システムの言語に合わせたい、特定のクラウドで組みたい、といった条件です。
この場合は技術名での検索が発生します。
技術名のページを作るなら、その技術で何を作ってきたかまで書いてください。
対応可能と書いてあるだけでは、判断材料になりません。

地域名は効くのか

費用を書けない業種で、費用のページをどう作るか

要件によるので書けないという理由で、費用のページを作らない会社が多いです。
発注側から見ると、これは調べる手がかりがないのと同じです。
そして手がかりを求めて、費用を書いている他社のページを読みます。

幅で書く

一つの金額に決められないなら、幅で書きます。

費用の書き方の例

ここに出した数字は、説明のための仮の値です。
自社の過去案件から、実際の幅に置き換えてください。

金額が動く要因を書くことに意味がある

幅を書くだけでは、発注側は自分がどこに入るか分かりません。
金額が動く要因を書くと、発注側が自分で位置を測れます。
測れた発注側からの問い合わせは、いきなり具体的です。
画面数はだいたい二十くらいで、既存の販売管理と連携したいという書き出しで来ます。
この一行があるだけで、初回の打ち合わせの内容が変わります。

人月単価をそのまま出すかどうか

実績が守秘義務で出せないとき、何を見せればいいのか

受託開発は、実績の公開に制限がかかることが多いです。
社名を出せない、画面を出せない、場合によっては業種すら出せない。
この制約を理由に、実績ページが大手企業様 多数で終わっている会社があります。
これでは判断材料になりません。

社名なしで書ける情報

社名を伏せても、書ける情報は多くあります。

実績ページに書ける要素

社名が出せる案件が一件でもあるなら、それは最優先で許諾を取ってください。
一件あるだけで、伏せた案件の信頼度も変わります。

許諾を取るタイミング

オフショアや低単価の会社と比較されたとき、どう戦うか

人月単価だけを並べられると、国内の受託開発会社は不利です。
この土俵で戦い続けると、単価を下げるしかなくなります。

総費用で比べてもらう

発注側が本当に払う費用は、開発費だけではありません。
要件を伝えるための社内の時間、仕様の食い違いによる手戻り、稼働後の不具合対応、数年後の改修。
これらを含めた総額で比べると、順位が変わることがあります。

これを言葉で主張しても響きません。
過去の案件で、要件定義に時間をかけたことで手戻りがどれだけ減ったか、という形で示すほうが伝わります。

保守が差になる

作って終わりの会社と、五年運用している会社では、発注側のリスクが違います。
保守の体制、対応時間、担当者の引き継ぎ方法。
このあたりを具体的に書いている会社は多くありません。
書くだけで差がつく領域です。

単価で選ぶ発注側は追わない

自社サービスを持つことは、集客の助けになるのか

人月の上限から抜けるために自社サービスを作る、という流れはよくあります。
方向としては妥当です。
ただし集客の面では、いくつか誤解があります。

自社サービスの集客は受託より難しい

受託開発は、困っている企業が探しに来る構造です。
自社サービスは、こちらから知ってもらいに行く構造です。
必要な費用も、必要な期間も、まったく違います。
受託の集客が回っていない会社が自社サービスを始めると、両方が中途半端になります。

相乗効果が出る部分

それでも、重なる部分はあります。
自社サービスを運営していること自体が、受託の提案での説得力になります。
自分たちも同じ課題を持っていて、こう解決したという話ができるためです。

また、自社サービスの開発で得た技術の記事は、受託の入口にもなります。
技術記事を読んだ発注側の技術担当者が、社内で名前を挙げるという経路です。
細い経路ですが、単価の高い案件につながることがあります。

受託と自社サービスの集客の違い

順番

問い合わせから受注までの間に、何が起きているのか

システム開発の発注は、担当者一人では決まりません。
情報システム部門、利用部門、経理、そして決裁者。
複数の人が関わります。

担当者が社内で説明する内容

担当者は、次のことを社内で聞かれます。
なぜこの会社なのか、他社と比べたか、費用は妥当か、失敗したらどうするか。
このすべてに、担当者が自分の言葉で答えられる状態を作る必要があります。

そのために渡すものは、提案書だけでは足りません。
比較しやすい形の見積もり、進め方の説明資料、過去の類似案件の概要。
社内でそのまま回せる形にしておくと、決裁までの期間が短くなります。

失敗の不安への答え

システム開発の発注で、担当者が最も恐れているのは、失敗して自分の責任になることです。
この不安に答えているサイトは、ほとんどありません。

答え方は二つあります。
一つは、開発が途中で止まったときの扱いを契約の形で示すこと。
もう一つは、途中で仕様が変わったときの進め方を先に決めておくことです。
どちらも、書いてあるだけで安心材料になります。

期間の長さを前提に設計する

限られた予算で、何から着手すればいいのか

着手の順番

順番をつけると、次のようになります。

着手の優先順位を、項目ごとに見ていきます。
1については、やることは対応範囲と進め方の明示、狙いは見積もれない相談を減らす。
2については、やることは費用の幅と変動要因のページ、狙いは問い合わせの具体性を上げる。
3については、やることは社名を伏せた実績の整理、狙いは比較検討で残る。
4については、やることは業務名での検索に応えるページ、狙いは入口を増やす。
5については、やることは既存顧客からの紹介の依頼、狙いは最も安い経路。
6については、やることは技術記事の発信、狙いは技術担当者への接触。
7については、やることは広告、狙いは受け皿が揃ってから。

紹介を軽く見ない

受託開発の受注経路として、既存顧客と取引先からの紹介は今も大きな割合を占めます。
ここを増やす動きは、Webの施策より費用がかかりません。
納品後も定期的に連絡を取る、運用の相談に応じる、といった地味な積み重ねが効きます。

一度に全部やらない

よくある質問

まとめ