BtoBマーケティングの役割と全体像｜リード創出から商談化まで担う機能と責任範囲
公開日 ・ 更新日 ・ 読了 21分
「マーケティング部門として何をすべきか、社内で定義されていない」「リードを渡したのに商談が増えない」「営業にはリードの質が低いと言われるが、改善の手がかりがつかめない」。こうした詰まりを抱えるマーケ担当者やマネージャーは少なくありません。多くの場合、問題の根本は施策の良し悪しではなく、役割そのものが定義されていないことにあります。
この記事では、BtoBマーケティング部門が担う役割と責任範囲を、フェーズ別・KPI別・組織連携の観点から具体的に整理します。BtoBマーケティングの定義・プロセス・主要施策の全体像については、BtoBマーケティングとはを参照してください。本記事は「役割・責任範囲・KPI・組織連携」の深掘りに徹します。
BtoBマーケティングにおける「役割」とは何か
マーケ部門の役割が曖昧なまま施策を積み重ねると、何をやっても「成果が出ているかわからない」状態が続きます。役割とは「誰が・何に責任を持ち・何を次のフェーズに引き渡すか」を定義することであり、施策の選定より先に決めるべき設計事項です。BtoBマーケティング部門の役割は「商談数の最大化に責任を持つ機能」として定義するのが最も実務と合致します。この節では役割の概念と、よくある誤解から整理します。
「施策担当」と「成果担当」の違い
「コンテンツを作る」「セミナーを運営する」「広告を回す」は施策の実行であり、役割の定義ではありません。役割とは成果に対する責任の範囲、すなわち「何が達成されればマーケが機能したと言えるか」を定義することです。
マーケ部門の役割を「リード数を増やすこと」だけに設定したとき何が起きるかを考えると、問題が明確になります。リード数が増えれば増えるほど施策は「成功」に見えますが、商談化率が落ちれば営業の対応工数だけが増えます。やがて「マーケのリードは使えない」という評価が固まり、営業との摩擦が深まります。リード数という単一の指標をKPIに置くこと自体が、この摩擦を生む設計上の欠陥です。
BtoCとの違いが役割設計に与える影響
BtoBの購買プロセスがBtoCと根本的に異なる点は、意思決定者が複数いること・購買期間が数ヶ月から年単位になること・購買目的が個人の欲求ではなく業務課題の解決であること、の3点です。この構造の違いが、マーケの役割設計に直接影響します。
BtoCでは一人の意思決定者が購買直前まで情報を収集し、比較検討を経て購入します。マーケの役割は「認知を取り・購買意欲を高め・購買行動につなげる」流れで完結する場合が多いです。しかしBtoBでは、複数のステークホルダーが異なるタイミングで情報を収集し、社内で合意形成を経てはじめて発注に至ります。
この構造のもとでは、マーケが「認知を取る」だけでは役割が完結しません。購買意欲が低い段階から継続的に接点を持ち続けるナーチャリングと、商談化に値するかを見極めるクオリフィケーション（選別）が、独立した機能として必要になります。「BtoCで効果があった施策をBtoBに転用しても成果が出ない」という失敗の根本原因の多くは、この構造の違いへの認識不足にあります。
リードの種類と考え方の詳細については、別途関連記事も参考にしてください。
フェーズ別に見るマーケ部門の担当機能と責任範囲
マーケ部門の責任範囲は、自社のファネル設計によって異なります。「リード獲得まで」「MQL定義まで」「商談フォロー資料の提供まで」と範囲は組織によって変わりますが、フェーズと機能を対応させて整理しなければ、何も担当しているようで何にも責任を持っていない状態になります。以下では5つのフェーズに沿って、マーケが担う機能と次フェーズへの引き渡し条件を整理します。
リードジェネレーション（創出）
役割は、見込み顧客との最初の接点を作ることです。コンテンツマーケティング・SEO・Web広告・セミナー・展示会・ホワイトペーパーといった手段を通じて、連絡先情報が取得できた状態のリード（RAWリード）を次フェーズに引き渡します。
注意すべきは、量を追いすぎると質が下がることです。「リード数」だけをKPIにすると、ダウンロードされるだけで商談につながらないホワイトペーパーを量産する、購買意欲の低いリードを大量獲得するといった方向に施策が歪みます。創出フェーズのKPIには、リード数と同時にその後の商談化率も視野に入れておく必要があります。
リードナーチャリング（育成）
役割は、購買意欲が低い・検討初期のリードを温め、検討フェーズを引き上げることです。メール配信・コンテンツ提供・ウェビナー・スコアリングといった手段を通じて、一定のスコアに達したリード（MQL：マーケティング認定リード）をインサイドセールスに引き渡します。
ナーチャリングをしないまま営業に渡すと、まだ検討初期の相手に営業が連絡を取ることになり、「時期が早すぎる」という摩擦が生まれます。ナーチャリングは施策の一種ではなく、引き渡しの質を担保するための機能として位置づけることが重要です。
マーケティングファネルとカスタマージャーニーの設計については、別途関連記事も参考にしてください。
リードクオリフィケーション（選別）
役割は、商談化に進む価値があるリードを選別し、インサイドセールスや営業に引き渡すことです。スコアリング設計・MQL/SQL基準の定義・インサイドセールスへの連携を担い、インサイドセールスがアプローチすべきSQL（営業認定リード）を成果物として出します。
MQLとSQLの定義が組織内で合意されていない場合、「渡したのに動いてもらえない」が頻発します。これはインサイドセールス側の問題ではなく、引き渡し条件が未定義のまま運用している設計側の問題です。クオリフィケーションの機能を担うためには、まずMQL/SQL基準の文書化と三者合意が前提になります。
商談フォロー支援（商談化への貢献）
役割は、商談中のフィールドセールスをコンテンツと情報で支援することです。提案資料・事例コンテンツ・比較資料・デジタルセールスルームへの情報集約といった機能を担い、商談を前進させるコンテンツアセットと、顧客の検討状況データを成果物として出します。
「コンテンツを作ったら渡して終わり」という運用では、商談フォロー支援の役割を担っているとは言えません。顧客がどのコンテンツを閲覧したか、どの情報に関心を示したかのデータを営業にフィードバックすることが、このフェーズにおけるマーケの役割の一部です。コンテンツの提供だけでなく、データの還流まで設計する必要があります。
受注後フォロー・フィードバックループ
役割は、受注・失注理由をマーケ施策に還元し、改善サイクルを回すことです。受注・失注分析・コンテンツの改善・カスタマーサクセスと連携したアップセル向けコンテンツ提供を担い、施策改善のインプットと既存顧客向けコンテンツを成果物として出します。
このフェーズを担わないと、「リードを増やしているが受注率は改善されない」という状態が続きます。マーケは「案件創出まで」で役割が終わるという設計では、失注の原因がコンテンツの質にあっても・提案タイミングにあっても・ナーチャリングの不足にあっても、改善されません。受注後フォロー・フィードバックループまでをマーケの責任範囲に含めることで、はじめて施策改善サイクルが機能します。
KPIで役割を定義する
役割を文章で定義しても、KPIが設定されていなければ「誰が何に責任を持っているか」は実際には曖昧なままになります。マーケ部門の役割をKPIで定義することで、営業との責任境界線が明確になり、摩擦の原因も特定しやすくなります。この節ではマーケが持つべきKPIと、営業が持つKPIの境界線を整理します。
マーケが持つべきKPIの4層
マーケ部門が責任を持つべきKPIは、以下の4層で整理できます。
- MQL数（マーケティング認定リード数） ナーチャリングを経て一定基準を満たしたリードの数。「量」の指標ですが、MQL定義の質が担保されていることが前提です。
- SQL数（営業認定リード数） インサイドセールスや営業が「アプローチする価値あり」と判断したリードの数。MQLのうちどれだけが営業に受け取られたかを示します。
- 商談化率 SQLが実際に商談に転化した割合。マーケとインサイドセールスの連携の質を反映する指標です。
- パイプライン貢献額 マーケ起点の案件がパイプラインに占める金額・件数。マーケが受注にどれだけ貢献しているかを把握できる最終的な指標です。
営業生産性の観点で整理すると、「商談数×受注率×単価÷工数」のうち、マーケは「商談数」（分子の最初の項）に最も直接的な責任を持ちます。受注率・単価には、提案資料の質・コンテンツ品質・顧客理解の精度を通じて間接的に貢献します。
「リード数」だけをKPIにする危険性
リード数が増えても商談化率が下がれば、営業の工数だけが増えます。「量のマーケ」から「質のマーケ」への転換は、KPI設計を変えることから始まります。
具体的には、MQL数を追うだけでなく、MQLのうち何割がSQLになったか・SQLのうち何割が商談化したかを追跡することが必要です。この数値を継続的に把握することで、「リードの数は足りているがナーチャリングが弱い」「MQL基準が甘すぎて営業に受け取られていない」といった詰まりの場所が特定できます。
「渡したリードの質が低い」という営業側の不満の根本原因の多くは、MQL定義の曖昧さにあります。定義が合意されていなければ、マーケと営業で「質の高いリード」の基準がそもそも異なります。
営業側のKPIとの境界線をどう引くか
営業が持つべきKPIは、受注率・受注件数・案件単価です。これらはフィールドセールスの商談力・提案力・クロージング力によって主に決まる指標であり、マーケが直接コントロールできる範囲ではありません。
「商談化率」をマーケとインサイドセールスのどちらが持つかは、組織設計によって異なります。インサイドセールスが独立した機能として存在する組織では、商談化率はインサイドセールスが持つことが多いです。インサイドセールスがいない組織では、マーケがSQLを作り・フィールドセールスが商談を担う二分割になるため、商談化率はマーケとフィールドセールスの連携指標として扱われます。いずれにせよ、KPI設計は施策より先に営業・マネジメントと合意することが前提です。
マーケと営業の摩擦が生まれる原因と解消策
「マーケがリードを渡しても営業が動かない」「営業はリードの質が低いと言う」。この摩擦は多くのBtoB組織で繰り返されますが、原因の多くは施策の質ではなく役割定義の曖昧さにあります。摩擦のパターンを類型化し、根本原因と解消手順を整理します。
よくある摩擦パターン
摩擦には、繰り返し観察される3つのパターンがあります。
パターン1：MQL定義が合意されていない。 マーケは「渡した」と認識しているが、営業は「まだ検討初期で連絡する段階でない」と感じています。原因はMQL/SQL基準が文書化されておらず、双方の基準がずれていることです。
パターン2：フィードバックが戻ってこない。 渡したリードが商談になったか・失注したかがマーケに返ってきません。結果として、どのリードが商談化しやすいか・どのコンテンツが受注に貢献しているかの分析ができず、施策改善サイクルが止まります。
パターン3：KPIが断絶している。 マーケはリード数を追い、営業は受注数を追います。中間にある商談化率を誰も持っておらず、「マーケと営業で見ている世界が違う」状態になります。この断絶が、責任の押し付け合いの構造的な原因です。
解消手順：役割の合意から始める
摩擦の解消は、施策の見直しより先に役割の合意から始めます。
- MQL/SQLの定義をマーケ・インサイドセールス・フィールドセールスの三者で合意する 「どのような状態のリードを次フェーズに渡すか」を文書化し、三者で合意を取ります。
- SLA（サービスレベルアグリーメント）を設定する 「SQLを渡したら2営業日以内にコンタクトを試みる」「初回コンタクト結果を3営業日以内にSFA/CRMに記録する」といった運用上の取り決めを明文化します。
- フィードバックループを設計する 受注・失注理由をマーケに返す仕組みをSFA/CRMで設計します。失注理由の分類（価格・競合・タイミング・ニーズ不合致 など）をSFA/CRM上に定義し、フィールドセールスが商談クローズ時に必ず入力する運用にします。
マーケティング組織の役割分担の全体像については、別途関連記事も参考にしてください。
The Model型の分業と役割の実態
BtoBマーケティングの組織設計で多く採用されているThe Modelは、マーケ・インサイドセールス（SDR/BDR）・フィールドセールス・カスタマーサクセスを分業する考え方です。この分業が機能するための前提条件として「各ロールの引き渡し条件の合意」と「情報連携の設計」が必要であり、分業するだけでは成果につながらない点を整理します。
The ModelにおけるマーケとSDR/BDRの役割の違い
The Modelにおける各ロールの役割は次のように分かれます。
- マーケ（インバウンド起点） コンテンツ・広告・SEOでリードを創出し、ナーチャリングを経てMQLをSDRに引き渡します。パイプライン貢献額とMQL数・商談化率が主なKPIです。
- SDR（Sales Development Representative） インバウンドリードを精査・アプローチし、SQLに転換してフィールドセールスに引き渡します。マーケからの引き渡し先であり、SQL数と商談化率が主なKPIです。
- BDR（Business Development Representative） アウトバウンド（ABM・DM・テレマーケティング等）でターゲット企業に能動的にアプローチします。マーケのインバウンド施策ではリーチできないターゲット層への接点を作る役割です。
マーケが担うナーチャリングはSDRの手前で機能します。ナーチャリングが不十分だと、SDRが接触する相手はまだ検討初期のリードが多くなり、SDRの活動効率が下がります。
The Modelが機能しないときの典型パターン
The Modelを導入しても機能しない場合、原因の多くは次の2つに集約されます。
引き渡し条件を決めていない。 MQL基準が曖昧なままSDRへの引き渡しを始めると、SDRの接触タイミングが安定しません。「渡したばかりのリードに連絡してしまった」「まだ資料を読んでいる段階の相手に電話した」といった事態が頻発し、リードの信頼を損ないます。
情報が各ロールで分断されている。 マーケが取得した接触履歴・コンテンツ閲覧データ・スコアリングの経緯が、フィールドセールスに届いていない状態です。フィールドセールスが顧客の検討状況を把握しないまま商談に臨むことになり、的外れな提案につながります。この問題を解消するには、SFA/CRMでの情報統合が前提として必要です。
マーケの役割をThe Modelの中で再定義する
The Model全体の文脈で言えば、マーケは「商談数を最大化する責任」を持つ機能です。インサイドセールスの「受注率・活動効率を高める責任」とは性質が異なります。
カスタマーサクセスとの連携においては、既存顧客向けのコンテンツやウェビナー提供でアップセルに貢献する場合、マーケの役割がThe Modelの後半まで拡張されます。この場合、マーケが担う指標にアップセル率や既存顧客のエンゲージメントスコアが加わります。
役割を遂行するためのツールカテゴリと選定基準
ツールは役割と担当フェーズが決まってから選ぶものです。「MAを導入すれば解決する」という発想でツールを選ぶと、機能と課題が合わず定着しません。この節では、マーケ部門の役割フェーズとツールカテゴリの対応関係を整理し、選定の判断軸を示します。
MA（マーケティングオートメーション）の役割
MAが主に補うフェーズはナーチャリングとクオリフィケーションです。メール配信・スコアリング・シナリオ設定・フォーム管理・アクセス解析といった機能を持ちます。
選定の判断軸として重要なのは、「リードが一定数あるか」と「ナーチャリングに割ける人員があるか」の2点です。リードが少ない段階でMAを導入しても、ナーチャリングするリードが足りず機能しません。また、MAはシナリオ設計・コンテンツ制作・スコアリング設計に一定の工数がかかるため、担当できる人員の確保も選定前提になります。
例えばMazrica Marketingのような案件創出型MAは、Mazrica Sales利用が前提です。MAとSFA/CRMのデータを統合することで、マーケ施策が商談・受注にどう貢献しているかを把握できます。
SFA/CRM（営業支援システム・顧客管理システム）の役割
SFA（営業支援システム）・CRM（顧客管理システム）が主に補うフェーズはクオリフィケーション・商談支援・フィードバックループです。案件管理・活動記録・受注/失注分析・マーケへのフィードバックデータの蓄積といった機能を持ちます。
マーケにとってのSFA/CRMの価値は、「営業が何をしているかを把握する」ことだけではありません。「マーケ施策が商談・受注にどう貢献しているかを把握する」ための基盤として活用することが本来の目的です。失注理由・商談化した案件の特徴・受注までのリードタイムといったデータをSFA/CRMから取得し、マーケ施策の改善に還元することがフィードバックループの実体です。
デジタルセールスルーム（DSR）の役割
DSRが主に補うフェーズは商談支援です。提案資料・事例・比較資料を1つのURLに集約し、顧客の閲覧状況をデータとして取得する機能を持ちます。
マーケにとっての価値は、商談中に顧客がどのコンテンツを見たか・何に関心があるかのデータが返ってくることです。「比較資料を詳しく見ている」「事例ページは閲覧していない」といったデータは、コンテンツ改善の具体的なインプットになります。例えばMazrica DSRのようなツールは、他社SFA/CRMや単独でも利用できます（Mazrica Sales専用ではありません）。
エンゲージメントツール（Webチャット・AI接客）の役割
エンゲージメントツールが主に補うフェーズはリード創出と初期育成です。WebサイトへのAI接客でリードの取りこぼしを防ぎ、商談につながる問い合わせを増やす機能を持ちます。
選定の判断軸は、サイトへの流入数があり・問い合わせ転換率を上げたい段階にあるかどうかです。流入数が少ない段階でエンゲージメントツールを入れても、接客する母数が不足します。例えばMazrica Engageのような製品は、WebサイトやコンテンツにAI営業アシスタントを常駐させてリードや商談のデータ取りこぼしを防ぐ機能を持ち、他社SFA/CRMや単独でも利用できます。
BtoBマーケティングの役割設計でよくある失敗
役割設計の失敗は「施策が機能しない」という形で表れます。問題が起きてから気づくのではなく、典型パターンを事前に把握することで設計の精度が上がります。
「リード数を最大化する」を役割にしてしまうパターン
リード数が増えるにつれて商談化率が下がり、営業の対応工数が増えていきます。やがて「マーケのリードは使えない」という評価が定着し、マーケへの不満が蓄積します。
解決策は、MQLの質の基準を設定し、商談化率もマーケのKPIに含めることです。「リード数を増やす」ことと「商談化率を維持する・改善する」ことを同時にKPIとして追うことで、量だけを追う施策の暴走を防げます。
施策を増やすほど成果が出ると考えるパターン
コンテンツ・広告・セミナーを並行して走らせると、どれが商談につながっているか不明なまま活動が続きます。リソースが分散し、すべてが中途半端になります。
解決策は、ファネルの「最も詰まっているフェーズ」を一つ特定し、そのフェーズに集中することです。「リードは来ているが商談化しない」なら選別フェーズを先に整備します。「商談化はするが受注につながらない」なら商談支援コンテンツを先に整備します。詰まりを特定する前に施策を増やすのは、診断前に薬を増やすようなものです。
営業連携をKPIではなく「報告会」で済ませるパターン
月次の定例でリード数を共有するだけで、受注・失注理由がマーケに戻ってきません。報告会は情報共有ですが、フィードバックループとは「マーケが受け取ったデータで施策を変え、次の月の結果が変わる」サイクルです。報告会だけで施策改善サイクルは回りません。
解決策は、SLAとフィードバックループの設計を先行させることです。「SQLを渡してから2営業日以内に初回コンタクトの結果をSFA/CRMに記録する」「失注時は理由を分類して入力する」といった運用上の取り決めを、報告会の設定より先に合意します。
役割設計の最初の一歩
役割設計のために最初にやることは、「自社のファネルのどのフェーズが最も詰まっているか」を一つ特定することです。これだけで、どのKPIを先に整備するか・どの施策から着手するかが絞られます。以下は着手可能な最初のステップです。
ファネルの詰まりを特定する3つの問い
まず、次の3つの問いに答えることから始めます。
- 問い1：商談数が足りないか？ 「そもそも商談の絶対数が少ない」という状態なら、リード創出・ナーチャリングが詰まっています。施策より先に、リード獲得の母数とナーチャリングの仕組みを見直します。
- 問い2：商談はあるが受注につながらないか？ 商談数は確保できているが受注率が低い場合、商談支援コンテンツ・提案資料の質・クオリフィケーション基準のいずれかが詰まっています。
- 問い3：営業のリソースが逼迫しているか？ 「リードは来ているが営業が捌ける量を超えている」なら、リードの質・MQL基準の厳格化・SDRとの連携設計が詰まっています。受け皿の整備なしに創出施策を強化することは、逼迫をさらに悪化させます。
「役割の合意」に必要な3つの文書
詰まりのフェーズが特定できたら、次の3つの文書を整備します。
- MQL/SQL定義書 どのような状態のリードを次フェーズに渡すかの基準。業種・規模・役職・行動スコアなど、合意できる具体的な条件を記載します。
- SLA（サービスレベルアグリーメント） SQLを渡してからどう動くかの合意。「○営業日以内に初回コンタクトを試みる」「コンタクト結果をSFA/CRMに記録する」といった運用上の取り決めです。
- KPI設計書 誰が何の指標に責任を持つかの対応表。マーケ・インサイドセールス・フィールドセールスの各ロールがどのKPIを持つかを明記します。
BtoBマーケティングの基礎知識全体の戦略立案・施策・ツール選定の総論については、BtoBマーケティングとはを参照してください。
まとめ：役割を定義してから施策を選ぶ
BtoBマーケティング部門の役割は「商談数の最大化に責任を持つ機能」です。しかし「商談数を増やす」という目標だけでは、どのフェーズで・どのKPIを持ち・何を次のロールに引き渡すかが定義されません。役割の定義とは、この3点をフェーズごとに合意することです。
組織の状況に応じた最初の打ち手は、次のように分かれます。
商談数が足りない組織は、MQL/SQL定義の文書化とナーチャリングの仕組み整備を先行します。施策の追加より前に「引き渡し条件の合意」を取ることで、創出した施策の成果を正しく評価できます。
受注率に課題がある組織は、フィードバックループの設計を優先します。失注理由がマーケに返っていない状態では、施策改善の根拠が生まれません。SFA/CRMへの失注分類の入力と、マーケへの定期的な共有の仕組みを先に作ります。
営業工数が逼迫している組織は、MQL基準の厳格化とSDRとの連携設計を優先します。創出施策を強化する前に受け皿を整えないと、逼迫がさらに深刻になります。まずインサイドセールスとの三者合意でMQL基準を引き上げ、渡すリードの質を上げます。
次のアクションとして取り組みやすいのは、MQL定義書の作成・SFA/CRMのデータで商談化率を確認する・マーケ・インサイドセールス・営業の三者でKPI合意の会議を設定する、の3つです。施策の見直しはその後です。
よくある質問
Q BtoBマーケティング部門はどこまでを担当範囲とすべきですか？
自社のファネル設計と組織体制によって異なりますが、最低限「リード創出・ナーチャリング・クオリフィケーション」の3フェーズを担い、MQL/SQL基準をインサイドセールス・営業と合意することが出発点です。リソースや組織成熟度に応じて、商談フォロー支援・受注後フィードバックまで拡張します。
Q MQLとSQLはどう定義すればよいですか？
MQLは「ナーチャリングを経て一定基準を満たしたリード」、SQLは「インサイドセールスや営業がアプローチする価値ありと判断したリード」です。定義は業種・企業規模・役職・行動スコア（ページ閲覧数・資料ダウンロード・メール開封 など）の組み合わせで設定します。重要なのは、マーケ・インサイドセールス・フィールドセールスの三者で文書として合意することです。一方的に設定した定義は機能しません。
Q マーケと営業のKPIはどのように分けるべきですか？
マーケはMQL数・SQL数・商談化率・パイプライン貢献額を持ち、営業は受注率・受注件数・案件単価を持つのが基本的な境界線です。商談化率はインサイドセールスがいる組織ではインサイドセールスが持つ場合もあります。いずれにせよ、境界線は施策より先に三者で合意することが前提です。
Q The Modelを導入したが機能しません。原因はどこにありますか？
最も多い原因は「引き渡し条件の未合意」と「情報の分断」です。MQL/SQL基準が文書化されておらず、各ロールの引き渡しタイミングが不安定になっている場合と、マーケが取得した接触履歴・コンテンツ閲覧データがフィールドセールスに届いていない場合が典型です。分業の設計より先に、引き渡し条件とSLA・SFA/CRMでの情報統合を整備することが解消の出発点です。
Q リード数は増えているのに商談化率が上がらない場合、何を見直すべきですか？
MQL基準の甘さ・ナーチャリングの不足・フィードバックループの欠如の3点が主な原因です。まずMQL定義をインサイドセールス・営業と照合し、双方の基準がずれていないかを確認します。次に、商談化したリードと商談化しなかったリードの属性・行動履歴を比較し、MQL基準に追加できる条件がないかを検討します。
Q マーケ部門が商談化率に責任を持つのは正しいですか？
組織設計によって異なります。インサイドセールスが独立している組織では商談化率はインサイドセールスが持つことが多く、マーケはMQL数とパイプライン貢献額を主なKPIとします。インサイドセールスがいない組織では、マーケが商談化率を追うことが理にかなっています。「正しい設計」を探すことより、現在の組織体制でどのロールが商談化率を追えるかを実態に即して判断し、全員が合意することが先決です。