会社紹介にも、設計サービスにも、運用サービスにも「豊富な経験で柔軟に対応」と書いてある。文章はそろっているのに、読む人には、どのサービスを選ぶと何を任せられるのかが分からない。複数の事業を持つ会社では、同じ強みの原稿を使い回すことで、このような状態が起こります。
会社全体の強みを消す必要はありません。共通する事実を一つの根拠として持ち、各サービスでは、その事実がどの仕事にどう関わるかを説明します。この記事では、原稿を確認する経営者・営業・現場責任者に向けて、共通の根拠、個別の提供価値、資料、掲載先を振り分ける方法を紹介します。
会社を信頼する理由と、そのサービスを選ぶ理由を分ける
会社の紹介を読む人は、どのような組織が仕事を受け、何を大切にしているかを確認します。一方、サービスの比較をしている人は、今回の依頼で何を受け取れるか、どこまで担当してもらえるかを知りたいはずです。同じ会社の情報でも、答える質問が異なります。
例えば、相談内容を社内で共有する体制が会社共通の事実だとします。それだけでは、設計サービスで図面の変更履歴を整理するのか、運用サービスで作業記録を引き継ぐのかは分かりません。サービスごとの説明では、実際に行う仕事まで進めます。体制があることから、未確認の作業を付け足してはいけません。
分ける単位は、良い言葉かどうかではなく、事実が当てはまる範囲です。全社で行うもの、特定サービスで行うもの、追加の契約があるときだけ行うものを確かめます。範囲が決まらない文は、どこへ載せるかを先に決めず、確認待ちとして残します。
全社共通にできる文章が少なくても、問題ありません。異なる仕事を扱う会社なら、共通するのは相談の受け方だけで、提供内容は別々という場合もあります。三つの強みに数をそろえるために、個別の対応を会社全体の約束へ広げないことが大切です。
公開ページでも、企業の説明とサービスの範囲は別に読む
公開例を見るときは、一つの企業の会社紹介とサービス紹介を組にすると、説明の違いを確認できます。IIJの企業紹介では、技術力、トータルソリューション、信頼性という観点で同社の強みを説明しています。ここでは、会社としてどのような基盤を持つかを知ることができます。IIJの企業としての強み
同社のマルチプロダクトコントローラサービスのページは、機器を遠隔で管理する仕組みと、そのサービスの対象を説明しています。また、利用者のネットワーク運用管理を請け負うものではないことや、一部機能にプラン差があることも示しています。IIJの個別サービスの説明
この二つから参考にするのは、表現そのものではなく、説明する範囲の分け方です。会社として幅広い支援を行えることと、一つのサービス契約にすべての作業が含まれることは同じではありません。自社でも、会社紹介の見出しをそのままサービスへ置いたときに、契約範囲が広く見えないかを確かめます。
他社のページ構成を使えば成果が出るという意味ではありません。提供内容や読者が違えば、必要な区分も変わります。自社の営業資料、現行の提供範囲、担当者の説明を照合し、実際に確かめられる内容で構成を作ります。
共通の事実と個別価値を、掲載先までつなぐ対応表
次は、設計サービスAと運用サービスBを持つ架空の会社Mの編集例です。実在企業の実績や標準サービスを示すものではありません。共通する事実を左側へ置き、サービスを選ぶ人に必要な説明、確認資料、掲載先へつなげています。実際の制作では、各欄を担当者と資料で確認してから原稿にします。
| 事実と適用範囲の例 | サービスで伝える内容 | 確認する根拠元 | 主な掲載先と扱い |
|---|---|---|---|
| A・Bとも相談内容を担当間で共有 | Aは設計条件、Bは作業依頼の履歴を引き継ぐ | 各担当の共有手順と記録様式 | 会社に共通体制、A・Bに対象の説明 |
| Aは提案段階で仕様の違いを整理 | 設計案を比べるための相違点を提示 | Aの成果物見本と提供範囲 | Aの提案内容に掲載。Bへ転用しない |
| Bは定期契約で作業報告を提出 | 実施内容と残る確認事項を報告 | Bの契約区分と報告様式 | Bの定期契約の説明に条件と併記 |
| Aの案件で個別の現地調査を実施 | その案件で何を確認したか | 案件記録と公開できる範囲 | 事例へ掲載。全案件の標準にしない |
| 全社実績の集計にA・Bが混在 | サービス別の件数は未確認 | 元の集計と案件区分 | 全社集計の定義を確認。個別件数は保留 |
一行目のように、共通の事実と個別の説明は両立します。会社のページで共有体制を説明し、Aでは設計条件の引継ぎ、Bでは作業依頼の履歴を説明します。文章を同じにすることではなく、同じ根拠から、それぞれの依頼に必要な情報を取り出す考え方です。
四行目の事例は、Aで対応した記録があっても、Aのすべての案件で行うとは限りません。会社全体かサービス単位かの二択にせず、一件の実施例として置く先も用意します。適用範囲を狭く正確に書くことで、その事例を標準の約束と混同しにくくなります。
五行目では、会社全体の合計をAとBのページへそれぞれ置かないようにします。同じ数字を各ページの「当サービスの実績」として見せると、元の集計と異なる意味になります。区分が取れなければ、全社合計であることを明示できる場所を検討し、サービス別の数字は確認が済むまで使いません。
一つの事実を両サービスに当てはめて、共通と呼べるか確認する
「担当者が引き継ぐ」という説明を共通にするなら、AとBの責任者へ同じ事実を確認します。Aでは日常的に行い、Bでは希望があったときだけ行うなら、そのまま全社の通常対応にはできません。Bの条件を個別ページへ残すか、会社側の表現を確認できる範囲へ絞ります。
原稿の確認では、文章に賛成できるかだけでなく、その文を読んだ人が何を依頼できると思うかを聞きます。「一貫して対応」を見て、受付窓口が一つだと思う人もいれば、全工程を自社の担当者が行うと思う人もいます。共通文には、窓口、作業、成果物のどの話なのかを補います。
AとBに共通の担当者がいることも、同じ支援を受けられる証拠とは限りません。担当者の配置と、サービスに含む作業を別々に確かめます。会社の組織図から直接サービスの約束を作るのではなく、各サービスの説明資料へ戻って確認します。
条件が違うと分かったら、共通部分を無理に長く残しません。「相談内容を確認し、担当サービスへつなぎます」と受付の事実までにとどめ、対応内容は各ページで説明する方法もあります。短くなっても、実態に合う共通文の方が、その後の個別説明とつながります。
ただし、部門ごとの言い方が違うだけで、必ず別の強みになるわけではありません。Aの「条件共有」とBの「依頼履歴の引継ぎ」が同じ共通手順に基づくなら、その関係を確認します。言葉の似ている部分だけで統合せず、実際の行動と適用条件を照合して決めます。
会社ページから来る人にも、サービスへ直接来る人にも伝える
会社ページでは、共通する事実を説明した後、各サービスで何を確認できるかを短く示します。M社の例なら、Aの入口は「設計案の比較と提案内容」、Bの入口は「定期運用の作業範囲と報告」と分けられます。同じ「詳しく見る」を並べるより、リンク先を選ぶ手掛かりになります。
サービスページでは、会社の強みの全文を再掲せず、そのサービスに関係する共通事実を短く示します。その上で、誰に向くか、何を行うか、何を渡すか、どの条件で利用できるかを説明します。会社の背景を詳しく知りたい人には、共通体制の説明へ進めるリンクを添えます。
検索や紹介からサービスページへ直接来る人もいます。全社の説明を一か所へ集めたからといって、そのページを読まなければ依頼条件が分からない構成にはしません。選ぶために必要な対象と条件はサービス側にも置き、背景の詳しい説明を共通ページへ渡します。
同じ事実を短く再掲することと、同じ段落をすべてのページへコピーすることは別です。例えば共通窓口の案内は各サービスにも必要ですが、全社の沿革まで毎回説明する必要はないでしょう。重複をゼロにすることより、その場で判断するために必要な情報がそろっているかを優先します。
入口のカードも原稿の一部です。Bの本文が定期契約だけの報告を説明しているなら、会社ページのカードを「すべての作業を報告」と短縮しないようにします。見出し、カード、画像内の文、検索向けの説明文まで、残すべき条件を共有します。
会社の歴史を使う場合も同様です。創業からの年数と、現在のサービスを提供してきた期間は分けて扱います。新しく始めたBのページに会社の年数だけを大きく置くと、Bにも同じ期間の経験があるように見える場合があります。創業の事実は会社紹介で説明し、Bでは開始時期や担当体制など、確認できる固有の情報を選びます。年数を外すだけで説明がなくなるなら、現在どのように仕事を受けるかを確かめ直します。
共通の原本と個別の原稿を結び付けて更新する
対応表は、最初の原稿作りだけで終わらせず、掲載後の確認にも使います。共通の事実には管理用の番号を付け、根拠資料、確認担当、確認日、その事実を使ったページを記録します。サービス固有の説明には、元となる共通事実と、追加した個別条件を残します。
例えば共有手順が変わった場合は、一行目を使う会社、A、Bの原稿を確認します。一方、Bの報告様式だけが変わったなら、Bの説明と会社ページのBへの入口が主な確認先になります。変更の種類と関係する掲載先を結び付けると、直す範囲を判断できます。
管理画面で共通文を一括表示する方法もありますが、すべてを共通部品にすれば解決するわけではありません。サービスごとに条件が違う文章を一括で変えると、一つの修正が別サービスの誤った約束になります。共通にする文と個別に持つ文の境目を、原稿で決めてから表示方法を選びます。
担当者が替わる場合も、完成した紹介文だけを渡さず、何を根拠にどの範囲へ適用したかを残します。新サービスを追加したときは、既存の共通文を自動でコピーせず、新しい提供範囲にも当てはまるか確認します。会社が同じでも、受け付ける条件まで同じとは限りません。
公開前は、二つの読み方で約束の範囲を照合する
最終確認では、会社ページからAへ進む経路と、Bへ直接入る経路を分けて読みます。前者は入口の短い説明と詳細が食い違わないか、後者は会社ページへ戻らなくてもBの対象・提供内容・条件が分かるかを確かめます。どちらも、読む人が頼めると思った仕事を書き出して比べます。
次に、共通の事実を取り除いても、AとBの違いが残るかを見ます。残るのがサービス名だけなら、個別の提供内容が不足しています。Aで渡す比較資料、Bで渡す作業報告など、確認済みの成果物や作業へ戻り、そのサービスを選ぶための説明を足します。
逆に、個別ページごとの言い方が違いすぎて、同じ共通体制が別物に見えることもあります。窓口の呼称や担当の役割は原本とそろえ、個別に説明する対象だけを変えます。文の統一と内容の使い回しを混同しないことが、複数サービスを整理するポイントです。
確認待ちの事実が残ったときは、確認者と質問を記録します。未確認の部分を「高品質」「柔軟」といった言葉で埋めず、確かめられた範囲で原稿を完成させます。会社として信頼を支える事実と、そのサービスで任せられる内容がつながっていれば、読み手は自分の依頼に合うページへ進めます。
参照資料：IIJ「IIJの強み」「IIJマルチプロダクトコントローラサービス」。2026年9月21日確認。公開ページの説明範囲を参照しました。実在企業への取材、サービスの機能検証、成果測定は行っていません。
