業種別

システム開発会社のBtoBマーケティング検討のきっかけと、よくある課題の解決方法

業務システムやアプリを事業会社から受託して開発する会社（SIer・受託開発会社。ITコンサルティングと開発を一体で受ける会社を含む）では、発注の前に完成品を見せられないため、買い手は過去の案件と進め方から任せられるかを判断します。このページでは、買い手が検討を始めるきっかけと、システム開発会社のマーケティングでよくある課題の解決方法を紹介します。

システム開発会社のマーケティングの今

受託開発の仕事は、長く付き合ってきた取引先からの継続案件、元請けからの二次請けの案件、知り合いからの紹介に支えられてきた会社が多いはずです。Webサイトは会社案内と採用の役割が中心で、技術ブログもエンジニアに向けて書かれていることがあります。

一方で、発注する側の探し方は変わっています。発注の窓口は、情報システム部門、DX推進の担当、業務を抱える事業部門と、会社によって違います。担当者は自社の業界や業務の言葉で開発会社を探し、近い案件を手がけたことがあるかで数社に絞ってから、相見積もりを取ります。作る前に試せないため、判断の材料は過去の案件と進め方です。ところが受託の案件には守秘義務があり、実績を十分に見せられない会社が少なくありません。

そのためシステム開発会社のマーケティングでは、「何でも作れます」と対応範囲の広さを見せることより、どんな業界の、どんな業務の課題を、どの段階から引き受けてきたかを、発注側が自社の案件に重ねられる言葉で先に示しておくことが出発点になります。

アイコネクトの見解

どの業種でも、BtoBマーケティングでいちばん大切なのは、顧客の課題に寄り添うことだと考えています。 寄り添うとは、顧客の痛みが最大になる瞬間を知ることです。課題はいつもそこにありますが、何かが起きて期限が決まり、放っておけない影響が見えたとき、初めて後回しにできなくなります。その瞬間に、判断に必要な情報がすでに手元にある会社が選ばれます。

システム開発会社の買い手にとって、その瞬間は「よい開発会社を探そう」と考えたときではありません。今のシステムを頼んできた開発会社から保守の終了を伝えられたとき、パッケージを試して自社の業務に合わないと分かったとき、経営から新規事業の方針が出て発注先を決める担当になったときです。そのとき担当者は、自社と同じ業界・規模の案件を手がけた会社を探し、要件が固まっていなくても相談できるかを確かめます。相見積もりの違いを決裁者に説明する材料も要ります。システム開発会社のマーケティングは、その瞬間に「この会社なら、うちに近い案件をこう進めてくれる」と分かる情報を、先にWebサイトと資料に置いておくことから始まると考えています。

note：BtoBのモーメントは、顧客のペインが最大化する瞬間にある。

システム開発会社の顧客が、検討を始めるきっかけ

事業会社の情報システム部門や事業部門の担当者が、開発会社を探し始めるきっかけは、次のような出来事です。そのとき探す情報を、Webサイトと資料に先に置いておきます。

今のシステムの保守を頼んできた開発会社から、対応の終了や担当者の退職を伝えられた
いつまでに
保守の契約が切れるまで
放っておくと
不具合が出ても直せる人がいなくなり、業務が止まる
このとき探す情報
他社が作ったシステムを引き継げるか。調べてから引き継ぐまでの進め方と期間
システムが動いている基盤（OSやミドルウェア、パッケージ）のサポート終了が決まった
いつまでに
サポートの終了日まで
放っておくと
セキュリティの更新が止まったまま使い続けることになる
このとき探す情報
同じような移行を手がけた事例。作り直すか移すかを決める材料と、費用の目安
法改正や取引先の要請で、業務システムの改修が必要になった
いつまでに
施行日や、取引先が決めた切り替えの日まで
放っておくと
手作業での対応が増え、間に合わなければ取引に響く
このとき探す情報
自社の業務とシステムを理解したうえで、期日までに改修できるか
パッケージやSaaSを試したが、自社の業務の流れに合わなかった
いつまでに
次の予算の締めまで
放っておくと
表計算と手作業の運用が残り、業務の見直しが1年先に延びる
このとき探す情報
業務の整理から相談できるか。近い業界・規模で作った例と、費用の目安
経営から新規事業やDXの方針が出て、発注先を決める担当になった
いつまでに
経営会議で計画を報告するまで
放っておくと
何を作るかが決まらないまま、期の予算を使えずに終わる
このとき探す情報
構想の段階から一緒に決めてくれるか。進め方と体制、決裁者に説明できる資料

システム開発会社のマーケティングのよくある課題と解決方法

ターゲット・差別化の課題誰に何を売るかが定まらない

主要な元請けや取引先から、発注を減らすと告げられたとき、直請けの案件や新しい業界を開拓しなければならなくなります。次の期の営業計画を立てるまでに、どの業界のどんな業務に強いかを言葉にできていなければ、狙う先が決まりません。

「何でも作れます」としか言えない
業務システム・Webアプリ・スマホアプリ・保守と対応範囲を並べるほど、何が得意な会社かが見えなくなっている
解決策
直近1〜2年の受注と失注を、発注元の業界・規模・発注のきっかけ・その後の取引で並べ、差が出る項目を探す。そこから「◯◯業で、△△をきっかけに相談してくる会社」の形で狙う条件を書き、合わない依頼の条件も添える。顧客層が分かれるなら、追う層を1〜2つに絞る
詳細を見る
他の開発会社との違いを説明できない
「高い技術力」「柔軟な対応」「一気通貫」が、比べられる開発会社のサイトにも同じように並んでいる
解決策
受注と失注の両方で、最後まで比べた相手と決め手を聞く。比べる相手には、ほかの開発会社に加えて社内での開発やパッケージの導入も入れる。決め手になった項目（業務の理解・上流の提案・体制・保守）ごとに発注側がどうなるかまで書き、選ばれた場面を強みの前に置く
詳細を見る

認知・集客の課題知られていない・見つけてもらえない

紹介をくれていた取引先の担当者が異動したり、元請けが開発を内製に切り替えたりすると、案件の入口は急に細くなります。稼働が空く時期が見えてから入口を作り始めると、検索で見つけてもらえるようになるまでの間、エンジニアの手が空いたままになります。

紹介以外から案件が来ない
既存の取引先や元請けからの紹介で稼働が埋まっており、Webサイトから来る相談はほとんど無い
解決策
紹介で来た案件の発注担当に、紹介が無ければどんな言葉で探したかを聞き、業界と業務の言葉ごとに入口のページを作る。本数は半年続けられる数で決め、公開したら実績や関連するページからリンクをつなぐ。急ぐときは、同じ言葉で広告を出して反応を確かめる
詳細を見る
手がけたシステムが会社名の認知につながらない
二次請けや守秘のある案件では、作ったシステムに元請けや発注元の名前しか出ず、社名で探されない
解決策
実績を業界と解決した課題で並べ直し、いちばん厚く語れる領域を1つ選んで、サイトの肩書きと事例の並び順をそろえる。社名を出せる取引先には掲載の了承を取り、出せない案件は業界・規模・課題で書く。発注元の担当者が社内で回せる1枚の会社紹介も渡す
詳細を見る

サイト・資料の課題サイトや資料で価値が伝わらない

直請けの案件を増やすと決めると、営業が会う前にサイトと資料だけで比べられる相手が増えます。次の提案の機会までに、営業が打ち合わせで口頭で補ってきた「何から頼めるか」「頼むと何が変わるか」の説明を、サイトと資料に移せるかが分かれ目です。

コンサルと開発のどちらを前に出すか決まらない
業務の整理から開発まで受けているのに、サイトは開発言語と技術の紹介が中心で、構想の段階の相談先に見えない
解決策
直近の受注で、発注側が最初に頼んできたのが「何を作るか」の整理か「どう作るか」の開発かを営業の記録で確かめ、多いほうを入口に出す。「業務の整理から始め、必要に応じて開発と保守まで引き受けます」のように頼む順番で書き、トップには誰の何をどう変える会社かを一文で置く
詳細を見る
実績の説明が技術の話で終わっている
事例には使った言語や構成が詳しく書かれているが、発注側の業務の何が変わったかが書かれていない
解決策
案件ごとに、発注前に何に困っていたか、なぜそれが問題だったか、作って何が変わったかを発注側の担当者に聞いて書き足す。使った技術や構成は取り組みの部分に残し、課題・取り組み・成果の順に並べ直す。数字が出せない案件は、誰のどの作業や判断が変わったかを書く
詳細を見る

リード獲得の課題問い合わせ・リードが増えない

紹介の案件が一段落し、次の四半期にエンジニアの稼働が空くと分かったとき、Webサイトからの相談で埋めようとします。サイトにアクセスはあっても、相談の入口が「お問い合わせ」一つでは、発注担当は送る手前で止まります。

技術ブログは読まれているのに問い合わせにならない
開発言語やフレームワークの解説で流入はあるが、読んでいるのはエンジニアで、発注を決める担当者ではない
解決策
受注した顧客が最初に調べた言葉を集め、発注側の業務の困りごとから入る記事を足す。今の技術記事は消さずに残す。記事ごとにどのサービスのどの課題の話かを1行で書き、つながる記事の先には近い事例や相談の入口を置く
詳細を見る
サイトを見た発注担当が、問い合わせずに帰っていく
サービス紹介と会社概要はそろっているが、自社に合う会社かを判断する材料が無く、比較の候補から外れている
解決策
受注した顧客に、相談の前に何を確かめたかったかを聞く。多いのは、費用の目安、自社に近い案件の事例、進め方と体制、会社としての信頼の4つ。それらがサービスページから迷わずたどれるかを確かめ、商談でいちばん多い質問の答えから足す
詳細を見る
要件が固まってからでないと相談できないと思われている
何を作るか決まっていない段階で相談してよいか迷い、社内で要件をまとめるまで問い合わせを先送りされている
解決策
要件が固まる前に来た相談を書き出し、「業務の整理から」「作るか買うかの判断から」のように受けている段階をサイトに載せる。相談の時点で決まっていなくてよいこと（予算・時期・機能）と、あると話が早いものを分け、問い合わせから提案・見積もりまでの流れと日数も書く
詳細を見る

比較検討の課題比較の段階で選ばれない・検討が止まる

相見積もりで、技術の評価は高かったのに別の会社に決まったと聞いたとき、比較の材料が足りなかったことに気づきます。次の提案の締め切りまでに、発注担当が決裁者に回せる材料を用意できなければ、同じ負け方を繰り返します。

実績一覧はあるのに「うちに近い事例は？」と聞かれる
実績が年度順や技術ごとに並んでいて、発注側が自社と同じ業界・規模・課題の案件を探せない
解決策
受けてきた案件の規模の幅（期間・体制の人数など）を数字で書く。業界ごとに発注側がよく確かめること（業界の決まりごと、切り替えに使える時期など）と、どう合わせて進めるかを組にして書き、発注側の社内で要る準備も示す。実績はその裏付けとして添える
詳細を見る
守秘義務で、社名も画面も出せない
顧客名もシステムの画面も出せず、実績ページが「製造業A社様業務システム開発」の一行で終わっている
解決策
出せない理由を、契約上の守秘・相手の社内の事情・まだ頼んでいないだけ、に分ける。頼めていない相手には目的と載せる範囲を先に伝えて取材を依頼し、承諾は書面で取る。社名を出せない案件は、業界・規模・発注前の課題・選ばれた理由・導入後の変化を、相手と確かめた範囲で書く
詳細を見る
見積もりが高いと言われて失注する
要件定義や業務の整理に工数を載せた見積もりが、開発費だけの見積もりと同じ土俵で比べられている
解決策
見積もりを工程ごとに分け、何をどこまで行うか、含まれない作業、前提（画面の数・修正の回数・保守の範囲）を書く。他社の見積もりと並べるときの確認点を1枚添え、要件定義を省くと後で何が起きるかを1文で示す。比べる作業は発注側に任せる
詳細を見る

商談率・受注率の課題商談にならない・受注まで進まない

期の後半になっても受注が計画に届かないと、手元の相談を一つずつ見直すことになります。打ち合わせは重ねているのに提案に進まない相談が並んでいるなら、エンジニアの稼働が空く前に、どこで止まっているかを確かめなければなりません。

打ち合わせを重ねても提案に進まない
「こういうものは作れますか」という相談から何度か打ち合わせても、予算と時期が決まらず、提案書を出す段階に進まない
解決策
直近半年の相談を、提案に進んだものと止まったものに分け、進んだ相談に共通する条件を書き出す。資料が欲しい人・相談したい人・見積もりが欲しい人で受け皿を分け、営業が提案の準備に入る条件も、料金や事例のページを見比べたといった行動を含めて営業と決める
詳細を見る
「来期に予算化します」の後、連絡が途切れる
具体的な相談まで進んだ相手が、予算がつくのを待つ間に接点を失い、翌期には別の会社に発注している
解決策
商談で聞いた「来期の予算で」「今のシステムの保守が切れる頃に」といった時期を記録し、そこから逆算して、短い事例や関係する制度の変更のお知らせを届ける。メールに加えてサイト内の案内や広告でも接点を持ち、料金や事例のページへの再訪があれば営業に知らせる
詳細を見る
失注の理由が次に活かされない
提案まで進んで失注した案件の理由が、「価格」「タイミング」の一言で片付けられている
解決策
失注にするときは理由を選択肢から選ぶ決まりにし、「価格」は「効果が伝わらなかった」「予算がつかなかった」「他社が安かった」まで分ける。止まった段階も残して月に1回、営業とマーケティングで集計を見る。理由ごとに直す場所（事例・見積もりの説明・決裁者向けの資料）を決める
詳細を見る

効果測定・KPIの課題成果が測れない・社内に説明できない

期末が近づき、来期にWebや展示会へいくら使うかを決める段になると、紹介とWebのどちらが利益の出る案件を生んでいるかを聞かれます。受注した案件の経路が営業の記憶にしか残っていなければ、答えられません。

Webからの問い合わせが受注にどれだけ効いているか分からない
問い合わせの件数は数えているが、受注した案件がどの経路から来たかは営業の記憶にしか残っていない
解決策
相談がCRMに入った時点で、流入元（Web・紹介・元請け・展示会など）を選択肢で残し、商談と受注をひも付ける。経路ごとに相談・商談・受注の件数と受注額を並べ、受注までが長い案件は途中の段階の進み具合で見る。報告は、どの入口に力を入れるかを問いにして組む
詳細を見る

既存顧客・LTVの課題既存顧客から広がらない

大きな開発案件の納品が近づくと、その後の稼働をどう埋めるかを考えることになります。保守で毎月やり取りしている顧客でも、次の構想の予算が組まれる前に話ができていなければ、別の開発会社に相談されていることがあります。

納品後は保守だけで、次の開発につながらない
保守契約で毎月やり取りしているのに、顧客の次の構想は別の開発会社に相談されている
解決策
顧客の一覧に、保守契約の更新日、基盤のサポートの期限、顧客が話していた次の計画の時期を足し、そこから逆算して連絡する日を担当者のタスクにする。連絡は提案から入らず、運用の状況と次の計画を聞く場にする。既存顧客から生まれた案件は新規と分けて記録する
詳細を見る
取引先の他部署やグループ会社に広がらない
一つの部署で評価されているシステムが、同じ会社の他部署やグループ会社には知られていない
解決策
開発前の作業時間や手作業の量を発注部署と記録しておき、成果が見え始めたら、課題・選んだ理由・変わったことを1〜2枚にまとめ、担当者の名前で社内に回せる形で渡す。取引先ごとに部署とグループ会社を書き出し、同じ業務がありそうな先と予算の時期を書き込む
詳細を見る