BtoBサイトを制作・リニューアルするとき、「きれいなデザイン」や「ページ数」だけを決めて発注すると、公開後に問い合わせが増えない、営業が使えない、更新できないといった問題が起こります。発注前に必要なのは、誰のどんな判断を支えるサイトか、どの行動を成果とするか、公開後に誰が改善するかを合意することです。BtoBサイトの要件定義は、ページの仕様書を作る作業ではなく、顧客の検討から商談までを支える仕組みを社内と制作会社で共有する作業です。
本記事では、事業目標、顧客像、情報設計、機能、非機能要件、計測、運用体制まで、発注前に確認する項目を具体的にまとめます。制作会社から見積もりを取る前に、社内の営業、マーケティング、経営、情報システムの意見をどう揃えるかも説明します。これからサイトを作る企業だけでなく、既存サイトの成果が出ず、リニューアルを検討している担当者にも役立つ内容です。
BtoBサイトの要件定義とは？制作前に決める範囲
要件定義とは、サイトに期待する成果、必要な情報・機能、守るべき制約、判断の担当者、完成の条件を文書化し、関係者で合意する工程です。デザイン案を選ぶ前に、サイトの役割を明確にします。BtoBでは、閲覧者がすぐに問い合わせるとは限りません。担当者が情報を集め、上司や利用部門が比較し、予算やセキュリティの確認を経て商談に進むため、複数の人が異なる情報を必要とします。
要求と要件を分ける
「問い合わせを増やしたい」は事業上の要求です。「導入事例の詳細ページを作る」「サービスページから相談フォームへ進める」「フォーム完了を計測する」は、それを実現するための要件候補です。単なる希望をすべて実装すると費用と期限が膨らむため、どの要求に結び付くかを確認します。IPAのユーザのための要件定義ガイドも、要求には異なるレベルがあり、意味や粒度の認識を揃える重要性を説明しています。サイト制作でも同じ考え方が役立ちます。
まず決めるべき成果の単位
問い合わせ総数だけでは、営業が求める成果を表せない場合があります。相談、見積もり依頼、資料請求、ウェビナー申込などの行動を分け、それぞれ商談へのつながりを確認します。資料請求を増やしたいのか、具体的な相談を増やしたいのかでページ構成とフォームが変わります。成果の目標は現状値と期間を基に現実的に設定し、根拠のない「公開後3倍」を要件にしないでください。案件単価、対象業種、地域など、営業上の条件も明示します。
社内の関係者を早めに特定する
営業は顧客の質問を知り、マーケティングは流入を把握し、情報システムは連携やセキュリティを担い、経営は投資判断を行います。制作の終盤に初めて承認者へ見せると、根本的な方向転換が起こりがちです。最初に企画責任者、情報提供者、レビュー担当者、最終承認者を決めます。承認の順番と回答期限も設定し、曖昧な「社内確認中」で進行を止めないようにします。
要件定義書は何を含むか
少なくとも事業目標、対象顧客、主な利用場面、現状課題、対象ページ・機能、コンテンツの責任者、技術・運用上の制約、予算と期限、検収条件を含めます。細部まで固定しすぎる必要はありません。未決事項を明記し、いつ誰が決めるかを残すことが大切です。制作会社と議論しながら改善する余地を持ちつつ、成果や承認基準のような重要条件は曖昧にしないでください。
「何を作るか」の前に「誰の判断を助け、どんな成果を測るか」を社内で揃えます。
顧客と商談プロセスからサイトの役割を決める
BtoBサイトの訪問者を「企業担当者」と一括りにすると、内容が薄くなります。実務担当者、部門長、決裁者、情報システム担当、購買担当では知りたいことが違います。さらに、課題を調べ始めた人と、複数社の見積もりを比較している人でも必要な情報が違います。自社の商談記録や営業へのヒアリングを使い、顧客がどの段階で何に迷うかを具体化します。
役職より検討時の問いを把握する
「どんな課題を解決できるか」「自社の業種に合うか」「導入にどれくらい時間がかかるか」「社内説明に使える根拠はあるか」など、検討時の問いを書き出します。肩書きだけのペルソナより、この問いがページ構成を決めます。実務担当者には使い方と導入後の業務、決裁者には投資効果やリスク、情報システムには運用・連携・セキュリティの情報が必要な場合があります。ただし実際の販売方法と違う想像上の顧客像を作らないよう、失注理由や問い合わせ内容で確認してください。
検討段階別の情報を用意する
課題認識の段階には、問題の背景と選択肢を説明する記事が役立ちます。比較段階には、サービス範囲、料金の考え方、導入事例、他の手段との違いが必要です。決定段階では、導入までの手順、担当体制、契約条件、相談方法が重要になります。サイトのすべてのページに強い問い合わせボタンを置くだけでは、まだ比較している訪問者の不安は解消しません。次に読みたい情報へ進める内部リンクとCTAを設計します。
営業とサイトの責任をつなぐ
問い合わせ後の初回返信、担当部署への割り当て、営業資料との整合も要件です。フォームを送っても誰も気づかない、資料請求の情報がCRMへ渡らないといった問題は、デザインでは解決しません。フォームの通知先、対応期限、問い合わせの分類、重複への対応を明文化します。Webサイトが獲得した見込み客を、営業がどのように評価し、次の接点を作るかを決めてください。インサイドセールス代行の費用記事も、営業体制を考える際の参考になります。
顧客理解を一度で完成させようとしない
最初の要件定義では仮説が残ります。過去の商談、問い合わせ、サイト内検索、営業担当の質問から情報を集め、公開後のデータで修正します。重要なのは、誰を優先し、何を確かめるかを明記することです。たとえば中堅製造業の技術部門を主な対象にするなら、導入事例と仕様資料の閲覧から相談までを測ります。対象を広げる場合は、別の導線が必要かを検討します。
BtoBサイトでは「訪問者を増やす」だけでなく、検討段階ごとの疑問を解消し、営業へ正しく引き継ぐことを要件にします。
サイト構成とページごとの役割を設計する
サイトマップは単なるページ一覧ではありません。どの入り口から来た人を、どの情報へ案内し、どの段階で相談してもらうかを表す設計図です。検索から記事へ入る人、広告からサービスページへ入る人、社名を知ってトップページへ来る人では経路が違います。トップページだけを磨いても、実際の主要な入り口が弱ければ成果につながりません。
サービスページに必要な情報
対象顧客、解決する課題、提供範囲、進め方、料金の考え方、成果物、よくある質問、相談方法を整理します。すべてを長文で書く必要はありませんが、営業に毎回聞かなければ分からない基本事項はサイトで説明します。強みは「丁寧」「高品質」のような抽象語だけでなく、具体的な体制や実績、他社と異なる条件で示します。価格を公開できない場合も、何で見積もりが変わるか、相談時に何を準備すればよいかを伝えられます。
事例は選定の不安に答える
導入事例は、社名と成果数値だけでは十分でないことがあります。導入前の課題、選んだ理由、実施範囲、社内の関係者、運用上の制約、成果までの期間を可能な範囲で記載します。数値を掲載できない場合も、プロセスや条件の具体性が信頼につながります。顧客の承諾を得て公開範囲を決め、機密情報や誇大表現を避けてください。業種、規模、課題で事例を探せる構成にすると、比較段階で役立ちます。
記事とサービスページの関係を定義する
集客記事を大量に作っても、サービスの対象外の検索語句ばかりなら商談に結び付きません。記事テーマは顧客の課題、比較・費用・手順、実装上の疑問から選び、サービスページへつながる文脈を設計します。GoogleのSEOスターターガイドは、ユーザーが情報を見つけやすく、検索エンジンが理解しやすい構造を基本としています。構造だけで順位は保証されませんが、重要情報が孤立しないようにする価値があります。BtoBサイトの制作費用記事も、ページ数と制作範囲を考える際に参照してください。
ナビゲーションを意思決定の順にする
社内の部署名に合わせたメニューは、訪問者には分かりにくい場合があります。「何を解決するか」「どんなサービスか」「実績はあるか」「どう相談するか」が追える名称にします。スマートフォン表示でも主要なページへたどり着けるか確認してください。製品数が多い場合は、業種別、課題別、機能別のどれを優先するかを顧客の探し方に合わせます。URLや階層を頻繁に変えると既存の評価やリンクに影響するため、リニューアル時は移行計画も必要です。
ページ一覧ではなく、顧客の入口から判断材料、問い合わせまでの経路をサイトマップに描きます。
問い合わせを増やすCTAとフォームの要件
「目立つボタンを置く」だけでは問い合わせは増えません。訪問者が相談する理由、相談後に何が起きるか、どれだけ手間がかかるかが分からなければ押しにくいからです。BtoBでは、すぐに発注したい人だけでなく、情報収集段階の人もいます。目的別のCTAを用意し、問い合わせを営業が受け止められる設計にします。
CTAはページの意図に合わせる
費用記事なら見積もり条件の整理、導入事例なら似た事例の相談、サービスページなら課題のヒアリングなど、直前に読んだ内容とつながる行動を提示します。すべてを「今すぐお問い合わせ」にすると、情報収集段階の人には負担が大きい場合があります。資料請求、相談予約、概算の問い合わせを分けるなら、それぞれに必要な情報と営業対応を決めます。資料請求だけが増えて商談が増えない場合は、CTAの数ではなく対象読者や案内内容を見直します。
フォームは必要項目を定義する
営業が初回連絡に必要な項目と、後から聞ける項目を分けます。項目を減らしすぎると対応先が分からず、増やしすぎると離脱が増える可能性があります。企業名、氏名、連絡先、相談内容などの必要性を業務に合わせて決めます。必須・任意の表示、エラー箇所の説明、送信完了後の案内も要件です。W3Cのフォームアクセシビリティの解説は、ラベル、入力説明、フィードバックを明確にする実装の参考になります。
送信後の体験まで設計する
完了画面で受付を伝え、返信の目安や次の連絡方法を示します。自動返信メールを使う場合は内容と送信失敗時の扱いを確認してください。社内通知には必要な情報だけを含め、担当者が不在のときの代替も決めます。問い合わせデータをCRMやメール配信ツールへ連携するなら、同意の範囲、保管方法、誤送信防止を含めて仕様化します。セキュリティとプライバシーは制作後に追加する装飾ではありません。
相談の質を測る
問い合わせ件数だけでなく、対象企業からの割合、商談化、失注理由を記録します。問い合わせが増えたのに営業が対応できない、対象外の相談が多いなら、フォームの文言やサービスページの対象条件を調整します。施策の評価には、流入元、閲覧ページ、CTA、フォーム完了、商談結果を可能な範囲でつなぎます。ただし個人情報の扱いと同意を優先し、計測のために過剰な情報を取らないでください。
CTAはボタンの色ではなく、相談する理由・入力負担・送信後の対応まで含めて設計します。
機能要件と非機能要件を抜けなく整理する
制作の見積もりが大きく変わるのは、見た目だけではありません。CMS、検索、外部システム連携などの機能と、速度、可用性、セキュリティ、運用のしやすさなどの非機能要件で工数が変わります。IPAの非機能要求グレードの説明は、利用者と開発者の認識違いを防ぐため、非機能項目と要求レベルを整理する考え方を示しています。一般的なBtoBサイトで全項目を同じ水準にする必要はありませんが、重要なものは契約前に合意します。
CMSと更新権限
社内で誰が記事、事例、サービス情報を更新するかを決めます。デザインを壊さずに編集できるテンプレートが必要なのか、自由なレイアウトが必要なのかでCMS設計が変わります。公開前の承認フロー、履歴、差し戻し、権限分離も検討します。CMSの名前だけを先に選ぶと運用に合わない可能性があります。まず更新する情報と頻度、担当者のスキルを定義してください。
外部ツール連携
CRM、MA、フォーム、予約、チャット、アクセス解析、広告タグなどの接続を一覧にします。どのデータをどちらへ渡すか、重複をどう扱うか、障害時に何が起こるかを確認します。ツールの利用料、API制限、設定権限は制作費と別になることがあります。契約後に連携要件が増えると見積もり変更の原因になるため、既存ツールと管理者を早めに共有します。不要なタグを増やすと性能や保守に影響するため、目的のない連携は避けます。
セキュリティと個人情報
通信の暗号化、管理画面の多要素認証、バックアップ、更新、脆弱性対応、ログの保管、フォームのスパム対策を要件にします。問い合わせには個人情報が含まれるため、通知メールや外部連携での扱いも確認します。サーバー管理者、CMS更新担当、事故時の連絡先を決めてください。プライバシーポリシーとフォーム上の案内は、実際のデータ利用と一致させます。法的評価が必要な場合は専門家に確認し、制作会社の雛形を無検討で流用しないでください。
速度・アクセシビリティ・対応端末
スマートフォンでの操作、画像の読み込み、フォームの利用しやすさ、キーボード操作、文字と背景のコントラストを確認します。W3CのWCAG概要はWebコンテンツのアクセシビリティに関する共通の基準を示しています。対象の適合水準を決める場合は、テスト方法と対象ページも合わせて合意します。速度指標はGoogleのCore Web Vitalsを参考にできますが、数値だけを追い、情報の分かりやすさを犠牲にしないようにします。
保守と障害時の責任分界
公開後に誰がサーバー、ドメイン、CMS、プラグイン、フォーム、計測タグを管理するかを整理します。バックアップの頻度だけでなく、復旧の目安とテスト方法も必要です。制作会社が保守を担う契約なら、対応時間、対象範囲、追加費用を確認します。管理画面やドメインを制作会社の個人名義にせず、会社として所有・引き継ぎできる状態にします。ホームページ保守の記事も運用条件の検討に役立ちます。
見た目に現れない更新・連携・安全性・保守を先に決めることが、公開後の手戻りを減らします。
コンテンツ制作と社内の承認体制を決める
サイト制作が遅れる大きな理由の一つは、文章、事例、写真、価格情報の準備が後回しになることです。デザインができてから素材を集めると、仮の文章に合わせたレイアウトを作り直すことになります。要件定義の段階で、どの情報を誰が作り、誰が確認し、どこまで公開できるかを決めます。
コンテンツの責任者をページごとに置く
サービス説明は事業責任者、技術情報は開発部門、事例は営業と顧客担当、採用情報は人事など、事実を確認できる人を割り当てます。制作会社へ文章作成を依頼する場合も、一次情報を社内から提供しないと一般的な説明にとどまります。価格や導入条件は変更されやすいため、公開時の確認日と更新責任者も決めます。承認が必要な箇所と、編集者の裁量で直せる箇所を分けると進行が速くなります。
写真・図・事例の権利を確認する
社員写真、顧客ロゴ、導入事例、製品画面、図表には利用条件があります。既存の営業資料で使っているからといって、Web公開が許可されているとは限りません。撮影やイラスト制作を依頼する場合は、必要なカット、二次利用、改変、納品形式を決めます。フリー素材を大量に使うとサイトが自社固有の情報を伝えにくくなります。重要なページには実際の担当者、サービス画面、業務工程などを優先してください。
検索意図に合う情報の深さを決める
トップページを短くする一方で、サービスページには比較検討に必要な詳細を載せるなど、ページの役割で情報量を変えます。検索流入を狙う記事も、読者の問いに直接答えることが前提です。見出しに語句を詰め込んでも内容が薄ければ判断材料になりません。AIで下書きを作る場合も、事実確認、独自の経験、顧客への適合、最新情報を人が点検します。画像に重要情報を閉じ込めず、本文にも説明してください。
変更依頼の運用を決める
制作中に新しい要望が出るのは自然です。ただし、変更のたびに費用と納期が変わる可能性があります。要望を「成果に必須」「公開後でもよい」「対象外」に分類し、追加見積もりの承認者を決めます。変更履歴には理由と影響を残します。細部をすべて固定するのではなく、事業目標と重要な導線は守りながら、実装方法は制作会社と調整する進め方が現実的です。
コンテンツの一次情報と承認者を先に揃えると、デザインの手戻りと公開後の誤情報を防げます。
計測設計と公開後の改善計画を要件に入れる
公開を最終目標にすると、その後の改善に必要なデータが残らないことがあります。サイトの成果を判断するには、公開前の現状値、追う指標、計測方法、担当者が必要です。成果指標は事業目標から逆算します。検索流入は重要ですが、アクセス数が増えても対象外の人ばかりなら商談は増えません。
KPIは段階を分けて設定する
第一段階は検索表示や訪問などの発見、第二段階はサービスページ・事例の閲覧、第三段階は資料請求・相談、第四段階は有効商談・受注です。すべてをサイトの直接成果にせず、営業活動や季節変動の影響を考慮します。たとえば問い合わせ数が同じでも、対象企業の商談割合が上がれば改善の可能性があります。測るものが多すぎると担当者が継続できないため、主要指標と補助指標を分けます。
イベント計測を公開前に検証する
フォーム完了、資料ダウンロード、電話タップ、相談予約などをどの条件でカウントするか定義します。同じ人が送信を繰り返した場合やテスト送信、社内アクセスをどう扱うかも決めます。計測タグは実装しただけで安心せず、テスト環境と公開環境で実際に動作を確認します。フォームの完了画面が表示されても営業通知が届かない場合は、成果を生まないため、計測と業務の両方をテストしてください。
SEOとAI検索への対応を過大に約束しない
Googleの開発者向け検索ガイドは、安全で高速、アクセシブルで端末に対応したサイトを勧めています。クロール可能な本文、適切なタイトルと内部リンク、構造化データの内容一致を要件として検討します。ただしSEOの順位やAI検索での引用は保証できません。重要なのは顧客の質問へ明確に答え、情報源と更新責任を持ち、実際のサービス内容と一致させることです。検索エンジン向けの表現が顧客に分かりにくいなら見直します。
公開後の改善サイクルを予算化する
公開から一か月は計測不備と表示問題を修正し、二〜三か月で閲覧経路やCTAを見直すなど、最初の改善会議を予定に入れます。サイトの評価には検索需要や商談期間の影響があるため、短期間の数値だけで成功・失敗を断定しないでください。改善用の予算と社内工数を確保し、制作会社へ保守と改善提案のどこまでを頼むか決めます。運用体制がないなら、公開時のページ数を絞り、更新できる構成を優先するほうがよい場合があります。
計測と改善の担当・予算は、公開後に考える追加作業ではなく制作要件の一部です。
発注前チェックリストと制作会社への伝え方
見積もり依頼は、詳しいデザインを指定することより、目的、対象、制約、成果物を揃えることが大切です。同じ条件を複数の制作会社に渡せば、提案の考え方と費用の差を比較できます。条件が曖昧だと、ある会社は文章制作込み、別の会社は素材支給を前提として回答し、価格の比較ができません。以下のチェックリストを、発注前の社内会議で使ってください。
| 領域 | 発注前に決めること | 制作会社へ伝える資料 |
|---|---|---|
| 事業 | 対象顧客、主力サービス、商談目標 | 事業概要、営業資料、失注理由 |
| 現状 | 既存サイトの流入、問い合わせ、課題 | 解析データ、サイトマップ、変更履歴 |
| 顧客 | 検討段階ごとの質問、決裁に必要な情報 | よくある質問、商談記録、事例候補 |
| 構成 | 主要ページ、必要な導線、残すURL | ページ一覧、優先順位、参考サイト |
| コンテンツ | 文章・写真・事例の作成者と承認者 | 素材一覧、権利確認、公開可能範囲 |
| 機能 | CMS、フォーム、検索、CRM連携 | 利用中のツールと権限・管理者 |
| 非機能 | 対応端末、速度、セキュリティ、保守 | 社内規定、アクセシビリティ要件 |
| 進行 | 予算、公開期限、社内レビュー体制 | 役割表、承認フロー、検収条件 |
RFPには目的と判断基準を書く
提案依頼書には「なぜ制作するか」「何を改善したいか」「何はまだ決まっていないか」を明確に書きます。見た目の好みだけでは、制作会社は成果に関する提案をしにくくなります。評価項目も事前に決め、事業理解、情報設計、実装体制、運用支援、費用を分けて見ます。提案書が華やかでも、公開後に更新できない構成では困ります。提案内容のうち契約に含まれるものと参考案にとどまるものを確認してください。
見積もりの内訳をそろえる
戦略・要件定義、情報設計、デザイン、コーディング、CMS、原稿、撮影、フォーム、連携、テスト、公開、保守を項目ごとに確認します。ページ単価だけでは難易度が異なるページを比べられません。修正回数、管理画面の使い方説明、旧URLからのリダイレクトも含むかを聞いてください。追加費用が発生する条件を具体例で確認し、安い見積もりに必要な作業が抜けていないか確かめます。制作費の考え方はホームページ制作費用の記事も参考になります。
検収を主観的な感想にしない
「イメージと違う」だけでは合意しづらいため、要件定義で受け入れ条件を決めます。主要ページが承認済み原稿と一致する、フォームが指定先へ通知される、スマートフォンで操作できる、計測イベントが動く、旧URLが適切に転送されるなど、確認できる条件を書きます。デザイン面も、参考サイトの見た目を丸写しするのではなく、ブランドの色・書体・写真の方針を共有します。公開前テストの担当と期限を決めてください。
制作会社との相性を確かめる質問
「顧客の検討行動をどう調べますか」「原稿は誰が書きますか」「CMS更新は社内でどこまでできますか」「公開後の改善提案はどのデータを見ますか」「担当者が交代したらどう引き継ぎますか」と質問します。業界経験があっても、こちらの事業条件を確かめずに成功パターンを当てはめる会社なら慎重に判断します。期待値と作業範囲を文書にして合意できる相手が望ましいです。
同じ条件書を渡し、制作範囲・素材の責任・公開後の運用まで含めた総費用で比較します。
よくある質問
Q. 要件定義は制作会社に全部任せられますか？
ヒアリング、資料整理、仕様化は制作会社が支援できます。しかし事業上の優先順位、対象顧客、価格や提供範囲の事実、最終承認は発注側が担う必要があります。社内の情報提供者と承認者を決め、制作会社と一緒に要件を明確にする進め方が現実的です。
Q. サイトのページ数は先に決めるべきですか？
概算見積もりにはページ規模の目安が必要ですが、数だけを先に固定しないほうがよいです。顧客の問いと導線を整理すると、統合できるページや必要な新設ページが見えます。ページ種別と優先度を決め、数は情報設計の結果として調整してください。
Q. デザインの参考サイトはどのように伝えればよいですか？
URLだけを渡さず、好きな点と避けたい点を言語化してください。たとえば「業種別事例を探しやすい」「専門性が伝わる写真」「サービス比較が分かりやすい」など、機能や印象の理由を添えます。他社の表現やデザインをそのまま模倣する指示は避け、自社のブランドと顧客に合う設計を検討します。
Q. リニューアルで既存のURLは変えてもよいですか？
必要なら変更できますが、旧URLから新URLへの対応表とリダイレクト計画を作ってください。流入の多いページを安易に削除すると、既存の訪問者が情報を見つけられなくなる可能性があります。ページ統合・廃止の理由を記録し、公開後に検索結果とアクセスを確認します。
Q. 問い合わせフォームは短いほどよいですか？
短さだけで決めません。顧客の負担と営業に必要な情報を両立させます。後で聞ける項目を減らし、必須項目の理由を明確にし、エラーが分かりやすいフォームにします。送信後の返信体制も合わせて設計してください。
Q. 要件定義にどれくらい時間をかけるべきですか？
関係者の数、既存データの有無、機能連携の複雑さで変わるため、一律の期間は示せません。短い期間でも目的、対象顧客、主要導線、作業範囲、承認者、検収条件は合意します。未決事項は決定期限と担当者を付け、制作に影響するものから解消してください。
まとめ
BtoBサイトの要件定義では、顧客の検討行動を起点に、事業目標、ページの役割、問い合わせ導線、機能、非機能要件、コンテンツ、計測、運用を一つの計画にまとめます。社内で営業・マーケティング・情報システム・経営の認識を揃え、制作会社に同じ条件を渡して比較しましょう。すべてを初日に決める必要はありませんが、重要な未決事項には担当と期限を置きます。成果につながるサイトは、公開時の完成度だけでなく、顧客の疑問に答え続け、データで改善できる体制から生まれます。
HPの達人に相談する
HPの達人では、サイトの見た目だけでなく、顧客の検討経路、必要なコンテンツ、問い合わせ後の営業対応まで含めて制作方針を整理します。現状のサイト、主力サービス、相談が増えない箇所を伺い、発注前に決めるべき項目を一緒に確認します。費用や成果は条件で変わるため、まずはお問い合わせから現状をお聞かせください。
参考・出典
- IPA「ユーザのための要件定義ガイド」
- IPA「非機能要求グレード」
- W3C WAI「Forms Tutorial」
- W3C WAI「WCAG 2 Overview」
- Google Search Central「SEOスターターガイド」
- Google Search Central「開発者向け検索ガイド」
- Google Search Central「Core Web Vitals」
情報確認日：2026年9月22日。サイトの要件は業種、顧客、システム構成によって異なります。法務・セキュリティ上の判断が必要な項目は、担当部門や専門家と確認してください。
