情報サービス産業協会（JISA）の2025年版 情報サービス産業 基本統計調査によれば、2024年度の売上高外注費率は33.54%でした。2023年度の30.50%、1991年度の20.99%と比べて上昇が続いています。同じ調査で、SIサービス売上高比率は46.32%、従業員一人あたりの売上高は3,815万円です。

この3つの数字は、情報通信業のCRM設計に対してそれぞれ別の要求を出しています。売上の3分の1が外注費ということは、案件を動かしている人員の相当数が自社の従業員ではなく、その稼働と進捗は自社のシステムの外側にあるということです。SIサービスが売上の半分を占めるということは、商談が単発の受注ではなく、要件定義・PoC・構築・保守という段階を踏む長期の連続体だということです。そして一人あたり3,815万円という生産性は、一件の取りこぼしが人員1人分の年間貢献に近い金額で効いてくることを意味します。

情報通信業は、自社でシステムを作れる産業です。だからこそ、顧客管理の仕組みを「作れるはずのもの」として扱ってしまい、結果として誰も全体を把握していないExcelとスプレッドシートの集合が残っている会社を、私たちは何度も見てきました。この記事では、SIer・ソフトウェアベンダー・SaaS事業者という3つの事業形態それぞれについて、HubSpotで何をどう持つべきかを、実際に支援した国内企業の構成例とあわせて整理します。

なぜ「システムを作れる会社」ほど、自社の顧客管理は整わないのか？

情報通信業のCRM導入支援でほぼ必ず出てくる言葉があります。「これくらいなら自分たちで作れる」です。実際、作れます。社内には要件定義ができる人も、データベースを設計できる人も、画面を作れる人もいます。問題は、作れることと、5年後も誰かが保守できることが別の話だという点にあります。

JISAの基本統計調査によれば、2024年度の中途退職者数は従業員100人あたり4.0人、従業員の平均年齢は41.2歳です。社内ツールを一人で作り切れる技術者ほど、社内の他の重要案件に引き抜かれるか、転職していきます。残るのは、仕様書のない管理画面と、誰も触りたがらないデータベースです。

内製した顧客管理が止まるのは、技術の問題ではなく誰の仕事かが決まっていないから

私たちがCRMの再設計を相談されるとき、既存の内製ツールが動かなくなっている理由は、技術的な破綻であることはほとんどありません。機能追加を誰に依頼すればいいのかが決まっていない、という組織の問題です。顧客向けプロダクトには当然プロダクトマネージャーと保守体制があるのに、社内の顧客管理ツールにはそれがない。結果として、営業は「言っても直らない」と判断し、手元のスプレッドシートに戻ります。

この構造は、自社でシステムを作らない業種では起きません。作れないから最初から外部のCRMを買い、設定の責任者を置くからです。作れる会社ほど、責任者を置かないまま走り出せてしまうところに落とし穴があります。

受託では必ずやる要件定義を、なぜ自社案件ではやらないのか？

顧客のプロジェクトでは、現状業務の棚卸し・あるべき業務フローの定義・データモデルの設計を順に踏むはずの会社が、自社のCRM導入では「とりあえずツールを入れて、使いながら考える」という進め方になることがあります。自社案件には発注者がいないため、要求をまとめる役割が宙に浮くことが原因です。

私たちがHubSpotの導入支援に入るとき、最初の2〜3週間はツールに一切触れず、商談の段階定義と、どの情報をどのオブジェクトに持つかの決定に充てています。この工程を飛ばした導入が後からどう崩れるかは、CRM全社導入で失敗する企業と成功する企業で整理しています。

ツールが足りないのではなく、どの粒度で持つかが決まっていない

「HubSpotでうちの業務が回るか」という質問をよくいただきます。回るかどうかを決めているのは機能の有無ではなく、案件を1件と数える単位が社内で揃っているかどうかです。同じ顧客の同じシステムについて、営業は「A社の基幹刷新案件」を1件と数え、PMOはフェーズごとに3件と数え、経理は契約書単位で5件と数えている。この状態でCRMを入れても、出てくる数字は誰の数字でもありません。

情報通信業の4つの収益モデルは、CRMに何を要求するのか？

情報通信業と一括りにされる企業の内側には、性質のまったく違う収益が同居しています。JISAの調査でSIサービスが売上の46.32%を占めるということは、裏を返せば残りの半分以上は別の形の売上だということです。受託開発、パッケージのライセンス販売、サブスクリプション、保守運用。この4つは、商談の長さも、成約後に発生する業務も、失注の意味も違います。

CRMの設計で最初に決めるべきは、この4つを1本の取引パイプラインに押し込まないことです。押し込むと、平均商談期間も受注率も、どの事業の数字なのか分からない平均値になります。経営会議で「受注率が下がった」という報告が出たときに、それが新規SI案件の話なのか既存顧客の保守更新の話なのかが判別できなければ、打ち手は決まりません。

この表の4行目に注目してください。保守・運用を取引として管理している会社は少なくありませんが、保守は商談ではなく継続する契約です。取引に入れると、毎年の更新のたびに受注率の分母が膨らみ、新規営業の成績が実態より良く見えます。HubSpotではチケットとカスタムオブジェクトに分けて持つのが素直な設計です。

パイプラインを分けると、かえって管理が煩雑にならないか？

分けた数だけ運用コストが増えるのは事実です。私たちが設計する際の基準は、「段階の名前が半分以上違うなら分ける、同じなら分けない」というものです。受託開発とパッケージ販売では、要件定義・基本設計といった段階の有無が根本的に違うため分けます。一方、同じパッケージの新規と増席は段階がほぼ共通なので、取引タイプのプロパティで区別すれば十分です。

HubSpotのパイプラインの設定では、パイプラインごとに段階と必須項目を変えられます。パイプラインルールを使えば、特定の段階に進める際に見積金額や契約開始日の入力を必須にできるため、営業の入力漏れを運用ルールではなく仕組みで防げます。

4つの収益を横断して見るレポートはどう作るか

パイプラインを分けると、全社の数字を見るときに合算が必要になります。カスタムレポートビルダーで取引オブジェクトを横断し、パイプライン別の内訳として並べるのが基本形です。ここで効いてくるのが、取引の金額欄に何を入れるかの統一です。受託は契約総額、サブスクリプションは年額換算、保守は年間契約額というように、期間の異なる金額を同じ欄に入れると合計が意味を持ちません。私たちは年額換算の金額プロパティを別に持たせ、全社の合算にはそちらを使う設計を標準にしています。

長期・多段階のSI商談は、どのパイプラインで持つべきか？

SI案件の商談は、顧客側の予算編成に従って進みます。情報システム部門との接触が先行し、稟議の段階で経営企画や経理が出てきて、最終的に調達部門が契約書を握る。6か月から18か月かけて関与者が入れ替わっていくため、商談の進捗を「誰と会ったか」で測ると実態を見誤ります。

私たちがSI向けのパイプラインを設計する際は、段階の定義を自社の作業ではなく顧客側の意思決定の到達点に置いています。「提案書提出」は自社の作業なので段階にしません。「提案内容について社内稟議を上げることに合意」が段階です。この定義にすると、営業が段階を動かすたびに顧客の状態が1つ確定するため、滞留しているのが自社の作業待ちなのか顧客の意思決定待ちなのかが区別できます。

PoC・技術検証は、取引の中の段階か、別の取引か？

有償のPoCを実施する場合は、別の取引として持つことを勧めています。PoCには請求が発生し、受注率の計算対象になるためです。無償の技術検証であれば本案件の段階に含めます。この判断を揃えておかないと、PoCで止まった案件が受注率の分母から静かに消えるという現象が起きます。

複数の取引が同じ案件に紐づく場合は、関連付けラベルで「本案件」「PoC」「追加開発」といった関係を明示しておきます。ラベルを付けておけば、後からレポートで「PoCを実施した案件の受注率」と「実施しなかった案件の受注率」を比較できます。PoCに投じた工数が受注率をどれだけ押し上げたかは、提案方針を決める材料になります。

長期案件の進捗は、何で測れば停滞に気づけるのか？

商談期間が長い事業では、受注予測より先に滞留の検知が必要です。HubSpotでは段階ごとの滞留日数を標準のレポートで追えるほか、パイプラインの自動化で「同じ段階に30日留まっている取引の担当者に通知する」といった動きを設定できます。長期案件は、失注するのではなく忘れられることで失われます。

予測ツールを使う場合、SI案件では段階ごとの確度を標準値のまま使わないでください。自社の過去2年分の実績から、どの段階まで進んだ案件が何%受注したかを集計し、その数字を確度として設定します。顧客の稟議を通過した案件の受注率が実績で80%なら、その段階の確度は80%です。

外注・パートナーが関わる案件は、どのオブジェクトで管理するのか？

売上高外注費率33.54%という数字が意味するのは、受注した案件の実作業の相当部分が、自社の従業員ではない人員によって行われているということです。元請けとして受注し、一次請け・二次請けに再委託する構造は情報サービス産業の標準的な姿であり、この構造をCRMに映さないまま取引レコードだけを管理すると、案件の粗利も要員の充足状況も見えません。

私たちがこの構造を設計する際は、パートナー企業を会社レコードとして持ち、案件との関係を関連付けで表現します。パートナーを取引のプロパティ（テキスト欄や選択肢）として持つと、同じパートナーの過去案件を一覧できず、評価も単価交渉の材料も蓄積されません。

協業パートナーと再委託先は、同じ扱いでよいのか？

分けてください。協業パートナーは案件を持ち込む側であり、再委託先は案件を受ける側です。商流が逆なので、管理すべき情報も違います。持ち込み元のパートナーには紹介件数と成約率を、再委託先には稼働可能な要員数と単価、過去の品質評価を持たせます。

HubSpotでは、会社オブジェクトに「取引先区分」のプロパティを持たせて顧客・協業パートナー・再委託先を区別し、レコードの関連付けで取引と結びます。関連付けラベルを「元請け」「協業」「再委託」と定義しておけば、1つの取引に複数社が絡む案件でも商流が読めます。再委託先ごとの発注実績は、関連付けの上限設定と組み合わせて、1案件あたりの再委託先数が増えすぎていないかの確認にも使えます。

パートナー経由の案件で、顧客の実体をどう持つか

再販パートナー経由で販売している場合、契約の相手はパートナーで、製品を使うのはエンドユーザーです。この2者を1つの会社レコードに押し込むと、エンドユーザーへの直接支援を始めたときに履歴が分離できません。会社レコードを2件持ち、親子関係で結ぶのが基本形です。

パートナーの担当者にHubSpotの画面を開放する場合は、チームとユーザー権限で、自社が担当する案件のみを閲覧できる状態にします。権限設計を省略して全件閲覧可能なまま運用を始めると、後から絞り込むときに「見えていたものが見えなくなる」という社内調整が必要になり、権限の設計よりも説得に時間がかかります。

複数プロダクトを持つ会社は、顧客データをどう設計するのか？

ソフトウェアベンダーの多くは、複数の製品を別々の事業部で販売しています。同じ顧客企業に対して、A事業部は基幹システムを、B事業部は品質管理パッケージを売っている。この状態で顧客データを事業部ごとに持つと、「この会社は当社から何をいくら買っているのか」という問いに全社として答えられません。

ここで安易にやってしまいがちなのが、会社レコードに「導入製品」というチェックボックスのプロパティを作ることです。導入の有無は記録できますが、いつ契約し、いつ更新で、何ライセンスなのかは入りません。製品と契約は、会社のプロパティではなく独立したレコードとして持つべき情報です。

カスタムオブジェクトで持つべきものと、持たなくてよいもの

私たちが基準にしているのは、「それ自体が更新され、履歴が必要で、複数件が同時に存在しうるか」です。契約は満たします。ライセンスも満たします。顧客の業種区分は満たしません（1件しかなく、更新履歴も不要）。カスタムオブジェクトの使い方に沿って、契約オブジェクトを定義し、会社と取引の両方に関連付けるのが標準的な構成です。

カスタムオブジェクトの設計をどこまで広げるかは、運用負荷との兼ね合いになります。設計の考え方はHubSpotカスタムオブジェクトの設計で詳しく扱っています。

製品ごとのサイトを分けたまま、リードを1つのCRMに集めるには

製品ブランドごとに独立したサイトを運営している会社では、問い合わせフォームが製品ごとに分かれているのが普通です。流入経路が分かれていること自体は問題ありませんが、コンタクトが重複して登録され、同じ担当者に3つのレコードが存在する状態になりがちです。HubSpotはメールアドレスでコンタクトを一意に扱うため、フォームの送信先を1つのポータルに集約すれば、同一人物は自動的に1レコードに集約されます。すでに重複が発生している場合は重複レコードの管理で統合します。

ＪＦＥシステムズの事例では、ERPを中核としたソリューションを提供する同社が、食品製造業向け品質情報管理システム「MerQurius」のブランドサイトをHubSpot CMSへ移行しました。移行前はCMSを使わない手作業での制作体制で、更新が特定の担当者に依存していた状態から、自然検索流入の増加とページ制作工数の3分の1への削減を実現しています（ＪＦＥシステムズの事例）。製品ブランドサイトを本体サイトと分けて運営しながら、リード情報は同じポータルに集まる構成です。

サブスクリプションの更新・解約は、標準機能でどこまで見えるのか？

SaaSを提供している事業では、新規受注よりも更新と解約のほうが経営に効きます。ところが多くのポータルで、更新は「契約満了日が来たら営業が思い出す」運用になっています。思い出す運用は、担当者が変わった瞬間に止まります。

HubSpotで更新を仕組みにする方法は単純です。契約オブジェクト（またはサブスクリプション情報を持つレコード）の満了日を基準に、ワークフローで「満了90日前に更新用の取引を自動生成する」という動きを作ります。更新案件が取引として存在すれば、パイプライン上に並び、滞留も検知でき、予測にも入ります。営業の記憶に依存していた業務が、CRMの標準機能の範囲で可視化されます。

解約の兆候は、どのデータから読めるのか

解約の予兆として最初に現れるのは、問い合わせの減少です。使われていない製品には質問が来ません。チケットの起票数が前四半期比で大きく減った契約を抽出すれば、それが最も安価な予兆の検知になります。HubSpotのチケットとカスタムレポートビルダーの組み合わせで実装できます。

より踏み込むなら、製品の利用状況をHubSpotに送ります。カスタム行動イベントを定義し、ログイン・主要機能の実行・管理者のユーザー追加といった挙動をイベントとして記録すれば、「過去30日間ログインのない管理者ユーザーがいる契約」をリスト化できます。この実装にはプログラムによる送信が必要で、開発リソースのある情報通信業であれば数日で組める規模の作業です。

更新の金額は、どこに持つのが正しいか

更新取引の金額欄には、更新後の年額を入れます。増席分だけを入れると全社の年額合計が過少になり、減席があった場合の影響も見えません。前年との差分は、別のプロパティとして「前年契約額」を持たせ、計算プロパティで増減を出すのが扱いやすい形です。製品と契約期間を明細で管理する仕組みを使えば、月額・年額の換算も明細側で持てます。

営業・カスタマーサクセス・開発の分断は、どのデータ設計で解けるのか？

情報通信業の社内では、営業はCRM、カスタマーサクセスは問い合わせ管理ツール、開発はIssueトラッカーを使っています。それぞれが自分の仕事に最適化された道具であり、統合すべきだと主張するつもりはありません。問題は、同じ顧客の情報が3つの場所にあり、どれが正なのかが決まっていないことです。

私たちがこの状態を整理するとき、最初に決めるのは「顧客に関する事実は何をもって確定とするか」という一点です。契約内容はCRM、障害の発生有無は問い合わせ管理、機能要望の採否は開発側、というように、項目ごとに正を1つに決めます。すべてを1つのツールに集めるのではなく、どの項目をどこが持つかを決めることが、サイロ解消の実体です。この考え方は組織のサイロ化を解消するデータ設計とSSOT（信頼できる唯一の情報源）で詳しく扱っています。

ライフサイクルステージを部門共通の言語にする

営業が「受注した」と言った瞬間と、カスタマーサクセスが「稼働した」と言う瞬間には、数か月の差があります。この差を埋めずに運用すると、CSは稼働前の顧客にオンボーディングのメールを送り、営業は稼働していない顧客に追加提案をします。

HubSpotのライフサイクルステージのカスタマイズでは、標準の段階に加えて自社固有の段階を追加できます。受注と稼働の間に「導入中」を挟むだけで、部門間の認識の差が1つの選択肢として明示されます。オブジェクト間のライフサイクルステージの同期を設定すれば、会社とコンタクトの段階がずれる問題も抑えられます。

脱炭素クラウドサービスを提供するe-dash株式会社の事例では、全社でHubSpotを使っていたものの運用ルールが定まらず、各部門が個別の使い方を続けた結果、経営が求めるデータを取り出せない状態に陥っていました。ライフサイクルステージの再設計とService Hubへの移行によって、意思決定に使えるCRM基盤へ作り直しています（e-dashの事例）。ツールを入れ替えたのではなく、同じHubSpotの中で定義を作り直した事例です。

問い合わせ対応の履歴を、営業が見られる状態にする

解約を防ぐうえで効果が大きいのは、営業が訪問前に直近の問い合わせ状況を確認できることです。HubSpotのチケットを使っていれば、会社レコードの画面に関連チケットが並びます。外部のツールを使い続ける場合も、アプリ連携や後述のUI拡張で、CRM画面に表示させることはできます。重要なのは、営業が別のツールにログインしなくても見える状態にすることです。見に行く必要がある情報は、見られません。

自社プロダクトとHubSpotは、どう接続するのか？

情報通信業がCRMを扱ううえで最大の資産は、開発ができることです。他業種であれば外部ベンダーへの発注が必要な連携を、自社の開発者が数日で組めます。HubSpotには4つの接続手段があり、どれを選ぶかで保守の重さが変わります。

選定の基準は、「データを持ってくるのか、画面を足すのか、業務を動かすのか」です。この3つを同じ手段で解こうとすると、無理のある実装になります。

この中で情報通信業が最も活用しやすいのは2行目です。自社プロダクトの契約情報・利用状況をCRMに流し込めば、営業とCSが同じ画面で顧客の実態を見られます。注意点は、同期の方向を最初に決めることです。契約情報の正をプロダクト側に置くなら、HubSpot側では読み取り専用にして手入力を禁止します。両側で編集可能にすると、どちらが新しいのか分からないレコードが積み上がります。

UI拡張を使うべきか、画面遷移で十分か

UI拡張は強力ですが、作れば保守対象が増えます。私たちが判断の目安にしているのは、その情報を見る頻度です。毎日見る情報、たとえばSaaSの利用状況や障害の発生状況はCRM画面に埋め込む価値があります。四半期に一度しか見ない情報は、リンクで別画面に飛ばせば十分です。

UI拡張を利用できるサブスクリプションの条件は、UI拡張の公式ドキュメントに記載されています。エディション要件は改定されることがあるため、実装に着手する前に自社の契約内容とあわせて確認してください。私たちが支援する際も、設計の前にこの確認を必ず挟んでいます。

情報通信業のHubSpot導入事例6選——何がどう変わったか

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、情報通信業の企業を継続的に支援してきました。以下はいずれも公開許諾をいただいている事例で、数値は各社へのインタビューで確認したものです。業態も規模も異なりますが、共通しているのは、ツールを入れたこと自体ではなく、何を1つのデータとして持つかを決め直した点にあります。

この6社のうち3社は、他社のCRMやMAからの移行、もしくはスプレッドシートからの移行です。情報通信業におけるCRM刷新は、何も無いところへの新規導入ではなく、すでにある何かを置き換える判断になることのほうが多いという実態がここに表れています。

オプロ：ライセンス更新期限が決めた移行スケジュール

オプロが直面していたのは、Salesforce Account Engagementを中核とした運用の硬直化でした。フォームやメール配信の設定に専門知識が必要で、特定の担当者に依存する状態が続き、企画から実行までに時間がかかっていました。移行の決断後、Salesforceライセンスの更新日まで残された期間は約1か月です。

短期移行では、すべてを持ち込まない判断が成否を分けます。過去のメール配信履歴をどこまで移すか、使われていないフォームを移行対象から外せるかを先に決めてしまえば、作業量は大きく減ります。結果として月間商談数は1.5倍に増加しました。移行コストの考え方はHubSpotのオンボーディングに必要な費用も参考になります。

デンタルシステムズ：年2,500万円のライセンス費に見合う活用ができていなかった

同社は歯科医院向けソフトウェアを開発・販売する企業であり、システムの内製能力を持っています。それでも数年にわたりSalesforceを導入し、年間2,500万円を超えるライセンス費用を支払いながら、営業現場での活用が十分に進まないという状態にありました（デンタルシステムズの事例）。HubSpotへの全面移行により、年間2,000万円以上のコスト削減を実現しています。

この事例が示しているのは、ツールの機能が足りなかったのではなく、現場が使う前提で設計されていなかったという点です。作れる会社であっても、使われない仕組みは使われません。

イー・エージェンシー：新規はCRM、既存はスプレッドシートという分断

9つのSaaS型プロダクトを持つ同社では、新規顧客の管理はHubSpotで行う一方、既存顧客の予実管理はスプレッドシートのまま残っていました。LTV算出や施策立案に欠かせないデータでありながら手入力に依存していたため、顧客数の増加とともに業務量とヒューマンエラーが増える構造になっていました。Data Hubによる自動化で、月30時間の入力・チェック業務を軽減しています。

複数プロダクトを持つ事業で起きやすいのは、プロダクトごとに管理方法が分かれ、全社の数字を出すために誰かが手で合算する作業が残ることです。合算作業が残っている限り、数字は月次でしか出ません。

内製・Salesforce・HubSpotは、どう選び分けるべきか？

情報通信業にとって、この3択は他業種と意味が違います。内製が現実的な選択肢として存在するからです。公正に書けば、内製が最適な場面はあります。自社プロダクトと極端に密結合した管理が必要で、その管理自体が競争優位の源泉になっている場合です。

一方で、営業・マーケティング・カスタマーサクセスの一般的な業務を内製で作るのは、ほとんどの場合で割に合いません。理由は開発工数ではなく、その後に続く機能追加・権限管理・監査対応・画面改善が永久に発生し続けることにあります。CRMは作って終わる製品ではなく、運用され続けるプラットフォームです。

この表で最も重要なのは2行目です。ツールの選定会議では初期の自由度が議論されがちですが、3年後に効いてくるのは運用の継続性のほうです。私たちが見てきた範囲では、CRMが使われなくなる原因の大半は機能不足ではなく、設定を変えられる人が社内にいなくなったことでした。

HubSpotとSalesforceを併用する構成はありうるか

あります。基幹に近い契約管理をSalesforceで続けながら、マーケティングと初期商談をHubSpotで動かす構成です。HubSpotにはSalesforce連携が標準で用意されており、カスタムオブジェクトの同期にも対応しています。併用を選ぶ場合は、どの項目をどちらが正とするかを先に表にしてください。この表を作らずに連携を設定すると、同期の衝突が運用開始の翌月から発生します。

最初の90日は、どこから着手すべきか？

全社展開を一度に進める計画は、情報通信業では特に破綻しやすくなります。事業部ごとに製品も商習慣も違うため、全事業部の合意を取ろうとすると設計が最大公約数になり、結果として誰にとっても使いにくいものができあがるからです。

私たちが推奨しているのは、1つの事業部、または1つの製品ラインで完結させることです。成果が出れば、他の事業部は自分から聞きに来ます。社内説得の材料は、資料ではなく動いている実例です。

最初の30日で決めること

最初の1か月は設定作業ではなく定義に使います。案件を1件と数える単位、取引の段階の定義、4つの収益モデルのうちどれを最初に載せるか、そして正のデータをどこに置くか。この4点が決まっていれば、設定作業自体は数日で終わります。逆に、この4点が曖昧なまま設定を始めた場合、3か月後に作り直すことになります。

既存データの移行は、この段階では着手しないでください。インポートファイルの準備は定義が固まってからの作業です。定義前に取り込むと、移行したデータが新しい定義に合わず、二重に手間がかかります。

31〜90日で動かすこと

2か月目は、決めた定義で実際に営業が1か月回します。この期間に必ず出てくるのが、定義の例外です。「このケースはどの段階になるのか」という質問が週に数件出るのは正常な状態で、それを都度決めて記録していくことが運用ルールの実体になります。3か月目には、滞留検知のワークフローと、経営向けのレポートを作ります。

レポートで最初に作るべきは、受注予測ではありません。段階別の滞留日数です。予測は過去データが溜まってからでないと精度が出ませんが、滞留は初月から見えます。目標機能と売上目標の設定は、データが揃ってから設定しても遅くありません。

よくある質問

Q1. 自社でCRMを内製済みですが、移行すべきか判断がつきません。何を基準にすればよいですか？

2つの質問に答えてみてください。1つ目は「その内製CRMに機能追加を依頼したとき、何週間で対応されるか」。2つ目は「作った本人が退職した場合、改修できる人が社内に何人いるか」。前者が1か月以上、後者が1人以下であれば、その仕組みはすでに事業のボトルネックになっています。機能の優劣ではなく、変更のリードタイムで判断するのが現実的です。

Q2. 受託開発が中心で、商談が年に数十件しかありません。CRMを入れる意味はありますか？

件数が少ない事業ほど、1件あたりの金額が大きいはずです。情報サービス産業の一人あたり売上高は3,815万円（JISA、2024年度）であり、案件単価はその数倍になることも珍しくありません。件数が少ないことは、CRMが不要な理由にはなりません。ただし、少数の大型案件を追う事業では、自動化よりも関与者の可視化（誰が意思決定に関わっているか）のほうが価値が出ます。設計の重心が変わります。

Q3. 開発部門がHubSpotのAPIを触ることになりますが、セキュリティ面で確認すべき点は何ですか？

プライベートアプリのアクセストークンは、付与するスコープを必要最小限にしてください。コンタクトの読み取りだけでよい連携に書き込み権限を付けると、不具合時の被害範囲が広がります。トークンはソースコードに直接書かず、環境変数またはシークレット管理の仕組みで扱います。HubSpot自体のセキュリティ体制は公式のセキュリティページで公開されており、社内のセキュリティ審査で求められる資料はここから確認できます。

Q4. 事業部ごとにHubSpotのポータルを分けるべきでしょうか？

原則として分けないことを勧めています。ポータルを分けると、同じ顧客企業が別々のポータルに存在し、全社でその顧客との取引総額を見ることができなくなります。事業部ごとの独立性は、ポータル分割ではなくチームと権限設定で確保できます。分割を検討すべきなのは、法人が別で会計も完全に分離している場合に限られます。

Q5. 契約情報は基幹システムにあります。HubSpotに二重で持つことになりませんか？

二重に持つこと自体は問題ではありません。問題になるのは、両方で編集できる状態にすることです。基幹システムを正とし、HubSpot側は参照用として読み取り専用にすれば、二重管理ではなく参照の複製になります。同期はプライベートアプリ経由のAPI連携で実装するのが一般的で、頻度は日次で足りることがほとんどです。

Q6. パートナー経由の販売が中心で、エンドユーザーの情報をほとんど持っていません。CRMに何を入れるのですか？

最初に入れるのはパートナーとの関係そのものです。どのパートナーから何件の引き合いが来て、何件が成約したか。これが見えるだけで、パートナー支援の配分が変わります。エンドユーザー情報の取得は、パートナーとの契約条件に関わるため、CRM設計の前に法務面の整理が必要です。順序を逆にすると、集めたデータを使えないという事態になります。

Q7. マーケティング担当が1名しかいません。HubSpotの機能を使いきれるか不安です。

使いきる必要はありません。初年度に使う機能を3つに絞ってください。多くの場合、フォームとワークフローとレポートの3つで、手作業の大半は置き換わります。ヤマハロボティクスの事例では、1名体制のウェブ運用で年間5〜10%のアクセス成長を継続しています（ヤマハロボティクスの事例）。人数ではなく、運用対象を絞れているかどうかが効きます。

Q8. 導入前の状態を測定していませんでした。効果をどう説明すればよいですか？

過去に遡って測れる指標を探してください。メールの送信通数、問い合わせ件数、受注件数は、既存のシステムやメールボックスから後からでも数えられます。測れないものについては、導入月を起点にして「ここから測る」と宣言したほうが、推計値を作るより社内の信頼を得られます。推計で作った導入前の数字は、必ず誰かに疑問を持たれます。

Q9. 情報サービス業向けの業種テンプレートはHubSpotに用意されていますか？

業種別のテンプレートとして提供されているものは確認できませんでした。HubSpotは標準オブジェクトとカスタムオブジェクトの組み合わせで業種要件に合わせる設計思想であり、テンプレートを探すよりも、自社の案件単位の定義を先に決めるほうが近道です。

情報通信業のCRMは、技術的な難易度が障害になることはほとんどありません。障害になるのは、作れてしまうがゆえに設計を省略できてしまうことと、事業部ごとに異なる商習慣を1つの定義に落とす社内調整です。売上の33.54%が外注費として社外に流れ、SIサービスが売上の半分を占める産業で、案件の実態が営業の記憶とスプレッドシートにしか存在しないのであれば、次に投資すべきは新しいツールではなく、何を1件と数えるかの合意です。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、情報通信業における商談設計・パートナー管理・自社プロダクト連携の設計を支援しています。自社のどの事業部から着手すべきかの整理を含めて、お問い合わせフォームからご相談ください。

最終更新日: 2026年10月23日（掲載している統計・製品仕様は同日時点のものです。HubSpotの機能およびエディション要件は変更される可能性があるため、導入前に最新の公式情報をご確認ください）