この記事の手順どおりに設定すると、お名前.comで取得した自社ドメインのメールを、Google Workspace(Gmail)で送受信できるようになります。作業時間の目安は30〜60分で、これに加えてDNSの反映待ち(数分〜最大72時間)が発生します。MXレコードを切り替え、SPF・DKIMを先に設定してから、少なくとも48時間後にDMARCを追加します。最終的に3つの送信ドメイン認証を揃えることで、迷惑メール判定やなりすましのリスクを抑えます。

作業の全体像

設定は次の5つを順番に進めます。使う画面は、お名前.com Naviの「DNSレコード設定」と、Google Workspaceの管理コンソールの2つだけで、特別なソフトは必要ありません。

1. MXレコードの設定: 自社ドメイン宛てのメールをGoogleのサーバで受け取るための、いわば「郵便物の届け先変更」です。
2. SPFレコードの設定: 「このドメインのメールはGoogleのサーバから送る」と宣言し、送信元のなりすましを防ぎます。
3. DKIMの設定: 送信メールに電子署名を付け、途中で改ざんされていないことを受信側が検証できるようにします。
4. DMARCの設定: SPF・DKIMを設定して少なくとも48時間待ってから、認証失敗メールの扱いとレポート先を指定します。
5. 設定の検証: テストメールを送り、配送と認証がすべて通っていることを確認します。

2〜4番目のSPF・DKIM・DMARCは「送信ドメイン認証」と呼ばれる仕組みで、未設定のままだと、正当なメールでも受信側の迷惑メール判定で不利になることがあります。なりすまし対策としての詳しい仕組みや意義は「中小企業のメールセキュリティ対策」で解説しています。3つの認証は最終的にすべて揃えますが、DMARCだけはSPF・DKIMの設定後、少なくとも48時間空けてください。

事前準備

作業を始める前に、次の3点を確認してください。

• お名前.comのログイン情報: 対象ドメインのDNSレコードを編集できるアカウントで、お名前.com Naviにログインできることを確認します。IDやパスワードが分からない場合は、先に再発行手続きを済ませておきます。
• Google Workspaceの申込と管理コンソール: 管理者アカウントで管理コンソールにログインできる状態にしておきます。まだ申込前の場合は、導入判断からデータ移行までの導入5ステップをまとめた「Google Workspace導入ガイド」を先に確認し、申込(14日間の無料試用から開始できます)を済ませてください。
• 切替タイミングの計画(現在メールを使用中の場合): MXレコードを書き換えると、以降の新着メールはGoogle側に届き始めます。切替中は旧メールサーバを解約せずに残し、過去メールの移行が終わるまで併存させてください。作業自体も、メールの少ない時間帯(週末や終業後)に行うのが安全です。

手順1: MXレコードの設定

MXレコードは、自社ドメイン宛てのメールをどのサーバで受け取るかを決めるDNSレコードです。ここを書き換えた時点で、メールの配送先がGoogleに切り替わります。

1. お名前.com Naviにログインし、「ネームサーバーの設定」→「DNSレコード設定」を開いて、対象のドメインを選択します。
2. 次の内容でMXレコードを1件追加します。

3. 旧メールサーバのMXレコードが登録されている場合は、切替のタイミングで削除します。新旧のMXが混在すると配送が不安定になります。
4. 画面の案内に従って設定内容を確認し、確定します。

現在のGoogle Workspaceは、smtp.google.com(優先度1)を1件だけ登録する「単一レコード方式」が標準です。インターネット上の古い解説には、aspmx.l.google.comなど複数のMXレコードを登録する方式が載っていますが、これは以前の方式で、現行の案内とは異なります。正しい値は管理コンソールのセットアップ画面に表示されるものなので、本記事と表示が異なる場合は必ず管理コンソールの案内に従ってください。

手順2: SPFレコードの設定

SPFは、「このドメインのメールを送信してよいサーバ」をDNSで宣言する仕組みです。同じ「DNSレコード設定」画面で、次のTXTレコードを追加します。

ここでの最大の注意点は、SPFレコードは1つのドメインに1件だけというルールです。すでに「v=spf1」で始まるTXTレコードが登録されている場合は、新しいレコードを追加するのではなく、既存のレコードに統合してください。SPFレコードが2件あると受信側の認証はエラーになり、かえって迷惑メール判定されやすくなります。

たとえばお名前.comのメール転送サービスなどを併用していて、すでにSPFレコードがある場合は、その既存の記述にinclude:_spf.google.comを追記して1件にまとめる形になります。統合の書き方は併用しているサービス側の案内もあわせて確認し、判断に迷う場合は、転送の利用をやめてGoogle側に一本化することも含めて検討してください。

手順3: DKIMの設定

DKIMは、送信メールに電子署名を付けて改ざんを検知できるようにする仕組みです。ほかの手順と違い、先に管理コンソールで鍵を生成してから、お名前.com側にレコードを登録する2段階の作業になります。

1. 管理コンソールのGmail設定からメール認証(DKIM)の画面を開き、鍵の長さに2048ビットを選んで新しいレコードを生成します。画面の場所が分からない場合は、管理コンソール内の検索機能や案内に従ってください。
2. 生成すると、ホスト名(google._domainkey)と、TXTレコードに登録する値が表示されます。この画面は閉じずに残しておくと、後の作業が楽になります。
3. お名前.comの「DNSレコード設定」で、ホスト名にgoogle._domainkey、TYPEにTXTを指定し、表示された値をそのまま登録します。値が長いですが、途中に改行や空白を加えずに貼り付けてください。
4. DNSへの反映を待ってから、管理コンソールに戻って「認証を開始」します。

鍵の生成直後に認証を開始すると、レコードがまだDNSに反映されておらず失敗することがあります。失敗しても設定が壊れるわけではないので、数時間ほど置いてから再実行してください。

手順4: DMARCの設定

DMARCは、SPF・DKIMの認証に失敗したメールを受信側がどう扱うべきかを宣言し、認証結果のレポートを受け取るための仕組みです。「DNSレコード設定」で次のTXTレコードを追加します。

「rua=mailto:」の後ろは、レポート受信用の専用アドレス(例: dmarc-reports@自社ドメイン のグループアドレス)にするのがおすすめです。レポートは件数が多くなりがちで、個人の受信箱宛では埋もれて運用が続かなくなるためです。なお、自社ドメイン以外のアドレスで受け取る場合は、受け取り側での追加の承認設定が必要になります。

ポイントは、最初は必ずp=none(監視のみ)で始めることです。p=noneは「認証に失敗しても配送には手を付けず、結果をレポートで知らせてほしい」という設定で、届いたレポートを見ながら、複合機や業務システムなどGoogle以外から自社ドメイン名義で送っているメールが漏れていないかを確認します。正当なメールがすべて認証を通ることを確かめたうえで、隔離(quarantine)、拒否(reject)へと段階的に強化するのが安全な進め方です。いきなりp=rejectにすると、設定漏れのある正当なメールが相手に届かなくなるおそれがあります。

手順5: 設定の検証

DMARCまでの段階的な設定が終わったら、DNSの反映(数分〜最大72時間)を待って動作を確認します。確認は「レコードの反映」「メールの送受信」「認証結果」の3段階で行います。

1. MXレコードの反映確認: ターミナル(コマンドプロンプト)で次のコマンドを実行し、smtp.google.comが返ってくれば反映済みです。「自社ドメイン」は実際のドメイン名に置き換えてください。Windowsでdigが使えない場合は、nslookupコマンドでも同様の確認ができます。

dig MX 自社ドメイン +short

2. 送受信テスト: 外部のアドレス(個人のGmailなど)と自社ドメインのアドレスの間で双方向にテストメールを送り、どちらも届くことを確認します。
3. 認証結果の確認: 受信した側のGmailでテストメールを開き、メニューから「メッセージのソースを表示」を選びます。画面上部に表示される認証結果(Authentication-Results)で、SPF・DKIM・DMARCの3つがすべて「pass」になっていれば設定完了です。

いずれかがpassにならない場合は、まず該当レコードの値の写し間違いと、DNS反映待ちの不足を疑ってください。この2つで大半は解決します。

よくある失敗と回避策

• 旧MXと新MXが混在して配送が不安定になる: 旧サーバのMXを残したままsmtp.google.comを追加すると、メールが新旧どちらに届くか安定しません。MXレコードはsmtp.google.comの1件だけにし、旧サーバは「MXからは外すが、移行完了までは契約を残す」形にしてください。
• SPFレコードが2件あって認証に失敗する: 既存のレコードを確認せずに新規追加すると起きる典型例です。追加前に既存のTXTレコードを一覧で確認し、v=spf1で始まるレコードがすでにあれば1件に統合します。
• DKIMの登録直後に「認証を開始」して失敗する: DNSに反映される前に開始すると失敗します。登録から時間を置いて再実行すれば通るので、あわてて鍵を作り直す必要はありません。
• DMARCをいきなりp=rejectにして正当なメールが不達になる: 複合機の通知メールなど、認証設定が漏れている送信元が残っていると、そのメールが相手に届かなくなります。p=noneで始め、レポートで送信元の実態を把握してから段階的に強化してください。

よくある質問

設定はどれくらいで反映されますか?

TXTレコード(SPF・DKIM・DMARC)は数分〜48時間、MXレコードはGoogleの案内で最大72時間が目安です。反映までの時間は、各レコードに設定されたTTL(DNSキャッシュの有効期間)に左右されます。反映が完了するまでは新旧の設定が混在して見えることがあるため、切替はメールの少ない時間帯に行い、72時間は様子を見る前提で計画してください。

設定を間違えるとどうなりますか?

MXレコードの間違いは「メールが受け取れない」という直接の業務影響につながります。SPF・DKIM・DMARCの間違いは、送ったメールが迷惑メール判定される・不達になるという形で現れます。いずれも正しい値に修正すれば反映後に復旧するので、作業前に変更前のレコード内容を控えておき、問題が起きたらすぐ戻せるようにしておくと安心です。

お名前.com以外のDNSサービスでも手順は同じですか?

登録するレコードの中身(MX・SPF・DKIM・DMARCの各値)は、どのDNSサービスでも共通です。異なるのは管理画面の名称や入力形式だけなので、本記事の設定値を各サービスの画面に読み替えて登録してください。なお、ドメインのネームサーバーを外部のDNSサービスに向けている場合は、お名前.comではなくそのサービス側で設定する点にだけ注意が必要です。

まとめ

お名前.comでのGoogle Workspaceメール設定は、MXレコード(smtp.google.com・優先度1の1件)を切り替え、SPF・DKIMを設定して認証を確認し、少なくとも48時間後にDMARCをp=noneで追加します。最後にテストメールのAuthentication-ResultsでSPF・DKIM・DMARCのpassを確認して完了です。作業自体は30〜60分ですが、DNS反映(MXは最大72時間)を含めて3日以上の余裕を持って計画してください。設定後はDMARCレポートを確認し、段階的にポリシーを強化します。

本記事の検証ログ: 設定値・手順は2026年7月10日にGoogle公式ヘルプおよびお名前.comの設定画面仕様に基づき確認。監修: 髙田誠史(Google Professional Cloud Architect)。

この記事は、従業員5〜50人規模の中小企業でIT導入を任された方に向けた、Google Workspace導入の総合ガイドです。専任の情報システム担当者がいない会社でも進められるように、「そもそも導入すべきか」の判断材料から、料金プランの選び方、申込〜メール切替〜移行の具体的な手順、導入直後にやるべきセキュリティ設定までを順番に解説します。読み終える頃には、自社に必要な作業の全体像と、最初に決めるべきことが整理できているはずです。検討段階の方も、すでに申込を済ませた方も、必要な章から読み進めてください。

• 無料Gmailでの業務運用は「ドメイン・退職時データ・権限管理」の3リスクがある(→判断基準はこちら)
• 料金と契約条件は変更されるため、公式料金ページで確認する。選び方の軸はストレージと必要機能(→料金プランの選び方)
• 導入はドメイン準備→無料試用→MX切替→移行→展開の5ステップ(→導入5ステップ)

お急ぎの方へ: 料金だけ確認したい / 導入手順を見たい / 導入済みでセキュリティ設定をしたい / チェックリストが欲しい

導入作業の全体像は次の5ステップです(所要2〜4週間が目安)。

1. 独自ドメインを準備する
2. 14日間の無料試用に申し込む
3. DNS(MXレコード)を設定してメールを切り替える
4. 既存のメール・データを移行する
5. ユーザーに展開し、定着させる

Google Workspaceとは

Google Workspaceは、Googleが提供する法人向けのクラウド型グループウェアです。個人向けの無料サービスとの最大の違いは、自社の独自ドメイン(例: yourcompany.co.jp)でメールが使えることと、会社としてユーザーやデータを一元管理できることです。

中小企業の実務で中心になるのは、次の5つです。

• Gmail: 独自ドメインのメールアドレス(info@自社ドメイン)を、使い慣れたGmailの画面で送受信できます。
• Googleドライブ: ファイルの保管と共有。社内のファイルサーバの置き換え先としても使われます。パソコン版ドライブ(Drive for desktop)を入れると、エクスプローラーやFinderから内蔵ディスクのような感覚でファイルを開けます。実体はクラウド側にあり、開いたファイルだけがその場でダウンロードされるため、パソコンの容量を圧迫しません。共有も「誰に・どこまで(閲覧のみ/コメント可/編集可)」を相手ごとに指定でき、メール添付に頼らない安全なファイル共有ができます。
• Google Meet: ビデオ会議。URLを送るだけで社外の相手とも会議ができます。
• Googleカレンダー: 社員同士の予定共有と会議室予約。日程調整の手間が大きく減る部分です。
• 管理コンソール: 管理者がユーザーの追加・削除、セキュリティ設定、データの管理を行う画面。個人向けGmailにはない、法人版の核となる機能です。

このほかドキュメント・スプレッドシート・スライドといった文書作成ツールも含まれますが、まずは「メール・ファイル・会議・予定を会社として管理できる仕組み」と捉えておけば十分です。

導入すべきか判断する

無料Gmail運用の限界とリスク

創業期の会社では、社員それぞれが個人の無料Gmailアカウントで業務メールをやり取りしているケースが少なくありません。この運用には、規模が大きくなるほど無視できない3つの問題があります。

• 独自ドメインが使えない: 取引先から見ると「@gmail.com」からの請求書やあいさつは、会社の実在性を確認しにくく、なりすましとの区別もつきません。与信や新規取引の場面で不利に働くことがあります。
• 退職時にデータが会社に残らない: 個人アカウントのメールや連絡先、ドライブ上のファイルは、その個人のものです。退職者が去った後、取引の経緯やファイルにアクセスする手段が会社側にありません。
• 共有と権限を会社として管理できない: 誰がどのファイルにアクセスできるのか、社外に共有されていないかを、管理者が一覧で把握・制御できません。情報漏えいが起きても気づけない状態です。

導入が向く会社・急がなくてよい会社

次のいずれかに当てはまるなら、導入を検討する価値は高いといえます。

• 業務メールを個人の無料Gmailや、プロバイダ付属のメールで運用している
• 社員の入退社のたびに、メールやファイルの引き継ぎで困った経験がある
• ファイルのやり取りがメール添付やUSBメモリ中心で、最新版がどれか分からなくなる
• 社内のファイルサーバが老朽化しており、更改のタイミングが近い

一方で、すでに他社のグループウェア(Microsoft 365など)を契約して定着している会社や、業務上メール・ファイル共有をほとんど使わない会社では、乗り換えのコストが効果を上回らないこともあります。ファイルサーバを含めた社内システム全体をクラウドに移すべきかどうかの考え方は、別記事「サーバのクラウド化はすべきか——判断基準の整理」で詳しく解説しています。

料金プランの選び方

中小企業が対象になるのは主にBusiness系の3プランです。Business系プランは最大300ユーザーまで利用でき、それを超える規模ではEnterpriseプランが対象になります。主要な違いは次のとおりです。

選び方の軸は「ストレージ」と「使いたい機能」です。メール中心でファイル共有が少ないならStarterで始められますが、ファイルサーバの置き換えを視野に入れるなら、1ユーザーあたり30GBのStarterでは早い段階で不足しがちです。その場合は2TBのStandardが現実的な選択肢になります。メールやファイルの保持・監査(Vault)が求められる業種では、Plus以上が候補です。なお、共有ドライブなどプランごとの細かな機能差もあるため、契約前に公式ページの機能比較を確認してください。

契約形態は、1年間の利用を約束して単価を抑える「年間契約」と、月単位で増減できる「フレキシブル」の2種類です。人数の変動が読めない時期はフレキシブルで始めて、落ち着いてから年間契約に切り替えるという使い分けもできます。

モデルケース: 従業員10人の会社の場合

従業員10人全員にアカウントを配布し、Business Standardを契約する場合は、公式料金ページで表示された1ユーザーあたりの単価に、実際に発行する有料アカウント数を掛けて月額を見積もります。比較するときは利用料だけでなく、ファイルサーバの更改費、メールサーバの保守費、バックアップ、障害対応にかかる時間も含めてください。

なお、2025年に生成AI「Gemini」の統合に伴う料金改定が行われました。従来は追加料金のアドオンだったAI機能が全プランに標準搭載となり、その分プラン料金も見直されています。Starterでは利用範囲が限定され、Standard以上ではGmailやドキュメントなどアプリを横断してGeminiを利用できます。改定前の古い料金を記載したままの解説記事も多いため、比較検討の際は情報の日付に注意してください。

• 月額の基礎: 公式の1ユーザー単価 × 有料アカウント数
• 年間の基礎: 月額の基礎 × 12か月
• 比較に加える費用: 移行支援、教育、端末設定、既存サービスの解約費

導入5ステップ

ステップ1: 独自ドメインを準備する

Google Workspaceの利用には独自ドメインが必要です。すでに自社サイト用のドメインがあればそれを使えます(サイトはそのままで、メールだけGoogleに向けることができます)。まだなければ、お名前.comなどのドメイン登録事業者で取得します。この段階で、ドメイン管理画面のログイン情報を会社として管理できているかを必ず確認してください。「制作会社に任せたきりで誰もログインできない」というケースが、後のDNS設定でつまずく典型例です。

ステップ2: 14日間の無料試用に申し込む

Google Workspaceには14日間の無料試用があります。公式サイトから会社名・人数・ドメインを入力して申し込むと、管理者アカウントが作成され、管理コンソールにログインできるようになります。試用期間中に管理画面の操作感や既存業務との相性を確かめ、本契約に進むかを判断しましょう。申込の過程でドメインの所有確認(DNSに確認用レコードを追加する作業)を求められますが、画面の案内に沿って進められます。

ステップ3: DNS(MXレコード)を設定してメールを切り替える

メールをGoogle Workspaceで受信するには、ドメインのDNSにあるMXレコード(メールの配送先を指定する設定)をGoogleに向けます。お名前.comであれば「ネームサーバーの設定」→「DNSレコード設定」から、管理コンソールに表示される値を入力する流れです。現在のGoogleが案内する設定は、「smtp.google.com」を優先度1で登録する単一レコード方式です。古い解説記事では複数のMXレコードを登録する旧方式が紹介されていることがあるため、必ず管理コンソールに表示される現在の案内に従ってください。切り替えのタイミングや注意点は、後述の「よくある失敗と回避策」も参照してください。

MXとあわせて設定しておきたいのが、送信ドメイン認証(SPF・DKIM・DMARC)です。まずSPFのTXTレコードを追加し、管理コンソールで生成したDKIM鍵をDNSに登録して署名を有効にします。Googleは、SPFとDKIMを設定してから少なくとも48時間後にDMARCを追加するよう案内しています。DMARCはp=noneから始め、レポートを確認しながら段階的に強化してください。

ステップ4: 既存のメール・データを移行する

過去のメールを引き継ぐ場合は、管理コンソールから使える「データ移行サービス」で、旧環境(無料Gmailや他社メールサーバ)のメールを各ユーザーのGmailに取り込みます。ファイルは、共有すべきものを整理したうえでGoogleドライブへアップロードします。個人PCやファイルサーバに散在するファイルをどう棚卸しして移すかは、それ自体がひとつのプロジェクトです。Windowsのファイルサーバから移行する場合も、移行後はパソコン版ドライブを使えば、エクスプローラーからこれまでのフォルダ操作に近い感覚で作業を続けられます。アクセス権限はドライブ側の共有設定で一元管理でき、部署フォルダごとの権限運用も引き継げます。手順の詳細は別記事「ファイルサーバからGoogleドライブへの移行手順」にまとめています。

ステップ5: ユーザーに展開し、定着させる

全ユーザーのアカウントを作成し、初回ログインの手順書を配って展開します。ここで手を抜くと「結局、前のやり方に戻ってしまった」となりがちです。最初の1〜2週間は、質問を受け付ける窓口(チャットグループでも構いません)を決めておく、よく使う操作だけに絞った1枚もののマニュアルを作る、といった小さな仕掛けが定着率を左右します。全機能を一度に使わせようとせず、まずメールとカレンダーから始めるのが現実的です。

管理者が最初にやるべきセキュリティ設定

導入直後の初期設定のままでは、会社の情報を守る体制として不十分です。運用を始める前に、管理コンソールで最低限次の5つを設定してください。

1. 2段階認証を必須にする: パスワードが漏れても不正ログインを防ぐ、最も効果の大きい設定です。まず管理者自身が有効にし、周知期間を設けたうえで全ユーザーに強制します。
2. 管理者アカウントを日常業務と分ける: 特権管理者のアカウントで日々のメールを送受信するのは避け、業務用アカウントと管理専用アカウントを分けます。管理者権限を持つ人は複数名にしておくと、担当者不在時のロックアウトを防げます。
3. 回復情報を設定する: 管理者がパスワードを忘れたりアカウントにアクセスできなくなったときのため、再設定用の電話番号・予備メールアドレスを登録しておきます。
4. 共有ドライブと外部共有のポリシーを決める: 社外へのファイル共有を許可するか、許可する場合はどの範囲か(リンクを知っている全員への公開を認めるか等)を、運用開始前に決めて設定します。後から締め付けると現場が混乱するため、最初に方針を固めるのが肝心です。
5. 退職者アカウントの停止手順を文書化する: 退職日にアカウントを停止し、メールとファイルを後任者や管理者に移管してから削除する、という一連の流れをあらかじめ手順書にしておきます。退職後もアカウントが生きている状態は、情報漏えいの典型的な入り口です。

また、メールは依然として攻撃の主要な入り口です。なりすましメール対策を含むメール周りの設定は、別記事「中小企業のメールセキュリティ対策」で詳しく解説しています。

よくある失敗と回避策

失敗1: MX切替のタイミングでメールが消える

MXレコードの切り替え中は、DNSの反映タイミングによって旧サーバと新サーバのどちらにメールが届くか揺れる時間帯が生じます。ここで旧メールサーバをすぐに解約・停止してしまうと、旧側に届いたメールを取り出せなくなります。回避策は、切替後も一定期間は旧サーバを受信可能なまま残しておき、両方の受信箱を確認すること。切替直後には、外部のアドレスからテストメールを送って新環境に届くことを必ず確認してください。

失敗2: 無料Gmailからの移行漏れ

個人の無料Gmailで業務をしていた場合、メール本文だけでなく、連絡先・カレンダーの予定・ドライブ上のファイルも個人アカウント側に残っています。メールだけ移して安心してしまい、数か月後に「あのファイルは前の個人アカウントにしかない」と発覚するのが典型例です。移行対象を「メール・連絡先・予定・ファイル」の4点で棚卸しし、移行後に本人と管理者の双方で完了確認をしてください。

失敗3: Starterを選んでストレージが足りなくなる

単価の安さでBusiness Starter(1ユーザー30GB)を選んだものの、ファイルサーバ代わりに使い始めたら容量が不足した、というパターンです。図面・写真・動画を扱う業種では特に起こりがちです。既存ファイルサーバの使用量を事前に確認し、置き換えを想定するなら最初からStandard(2TB)以上を検討するか、ファイルはドライブに置かない運用と割り切るか、方針を先に決めておきましょう。

失敗4: 管理者パスワードの属人化

導入を主導した社員だけが管理者パスワードを知っている状態は、その人の退職・休職と同時に会社のIT基盤がブラックボックス化することを意味します。特権管理者を複数名にする、回復情報を設定する、管理情報の引き継ぎ手順を文書化しておく——地味ですが、数年後の自社を守る設定です。

導入チェックリスト

導入プロジェクトの進行管理に、そのままコピーして使えるチェックリストです。

まとめ

Google Workspaceの導入は、単なるメールの引っ越しではなく、「会社の情報を会社として管理できる状態」への切り替えです。判断の入り口は無料Gmail運用のリスクを直視すること、プラン選びの軸はストレージと必要機能、導入作業の山場はMX切替と既存データの移行、そして導入後の最初の仕事はセキュリティ設定——この記事で示した順番で進めれば、専任の情シスがいない会社でも大きく道を外すことはありません。まずは14日間の無料試用で管理コンソールに触れて、自社の運用イメージを具体化するところから始めてみてください。