CS組織の体制・役割設計｜設計方針・実装・運用までの実践ガイド

カスタマーサクセス（CS：顧客が製品・サービスを使って成果を出せる状態へ導く活動）の担当者は置いたものの、営業やサポートとの線引きが曖昧で、更新対応が誰の仕事なのか決まっていない。そんな状態のまま人だけ増やすと、二重フォローや対応漏れが起きます。CS組織の体制設計とは、チームの箱を作ることではなく、成果に対する責務と権限を役割へ割り付けることです。この記事では、役割・責務の具体設計から、RACIによる権限整理、営業・サポートとの境界、実装ステップ、見直しのタイミングまでを実務手順で解説します。立ち上げの目的やKPI概観を含む体系的な全体像はCS組織の立ち上げ方を参照してください。

CS組織の体制設計とは｜「役割設計」が体制の土台になる理由

体制設計の出発点は、チーム構成やレポートラインという「箱」ではなく、「どの成果に対して誰が責任を持つか」という役割設計です。役割が曖昧なまま人を配置すると、営業の追客とCSのフォローが重なり、サポートの問い合わせ対応と定着支援の境界が消えて、結局「誰の仕事でもない領域」が生まれます。継続率・オンボーディング完了率・更新拡大といった成果を先に洗い出し、それぞれに説明責任者を1人ずつ割り付けてから、その責務を束ねる形でチームの箱を作ります。この順序を守るだけで、境界の曖昧さの多くは消えます。以下では、役割が先で箱が後になる理由と、最初に決めるべき「成果の帰属」を示します。

体制設計と役割設計の関係（役割が先、箱が後）

多くのCS立ち上げは「まず何人採るか」「どの部署に置くか」から始まりがちですが、これは順序が逆です。人数や配置は、役割と責務が決まって初めて必要量が計算できます。たとえばオンボーディングを専任で持つのか、CSMが兼務するのかで、必要な人数もスキル要件も変わります。役割（担う成果）を定義し、その責務を実行するのに必要な工数を見積もり、それを人と箱に割り当てる。この流れで設計すると、後から「この業務は誰の担当だったのか」という空白が生まれにくくなります。

役割設計で最初に決める「成果の帰属」

役割設計の核は、成果ごとに説明責任者を1人に定めることです。継続率、オンボーディング完了率、更新・拡大の金額といった成果に対し、「最終的にこの数字を説明するのは誰か」を一意に決めます。説明責任者が複数いる状態は、実務では誰も責任を持たない状態と同じになります。逆に、実行者（動く人）は複数いても構いません。まず成果を列挙し、それぞれに説明責任者を1人ずつ紐づけるところから設計を始めます。

よくある失敗｜人を採ってから役割を決める逆転

立ち上げ期に最も多い失敗が、先に人を採用し、その人のできることに合わせて役割を後付けする逆転です。この進め方だと、採用した人のスキルが役割定義を規定してしまい、本来必要な責務に空白が残ります。さらに、増員のたびに「この人には何をやってもらうか」を個別に決めるため、役割の重複や抜けが積み上がります。役割定義が採用要件を決めるのであって、その逆ではありません。採用・増員の設計を先に置きたくなったら、まず役割を確定させてから要件に落とす順序を守ります。

CS組織に置く役割と責務の定義

CS組織の役割は、CSM・オンボーディング担当・CSオペレーション（CSOps）といった系統に分けて考えることができます。ただしこれは十分な人数がいる場合の型で、1〜3名の少人数期は兼務が現実解です。役割を崩れにくく定義するコツは、「架電する」「メールを送る」といった動作ではなく、「オンボーディングを完了まで導く」「更新を取り切る」という担う成果で定義することです。動作で定義すると、業務が増えるたびに担当の押し付け合いが起きますが、成果で定義すれば境界が自然に決まります。以下、各役割の責務と切り分けを示します。

CSM（カスタマーサクセスマネージャー：顧客の成功を主担当する役割）の責務

CSMは、担当顧客が製品を使って成果を出し、契約を継続・拡大する状態を主担当する役割です。責務は次のとおりです。

• 担当顧客の活用状況の把握と、成果に向けた伴走・提案
• ヘルスチェック（利用状況や満足度から解約リスクを判定する点検）と解約リスクへの早期対応
• 更新に向けた関係構築と、更新可否の見通し管理
• 顧客の声を社内（プロダクト・営業）へ連携する接点

CSMは「顧客の成功と継続」に説明責任を持つ役割であり、活用促進から更新見通しまでを一貫して見ます。

オンボーディング担当の責務と、CSMとの切り分け

オンボーディング担当は、受注直後から顧客が製品を使い始め、初期の立ち上がりを完了させるまでを主担当します。責務は次のとおりです。

• 初期設定・データ移行・利用開始までの立ち上げ支援
• キックオフから初期活用定着までの進行管理
• オンボーディング完了の判定と、完了後のCSMへの引き継ぎ

CSMとの切り分けは、時間軸で区切るのが実務的です。「立ち上がりまで」がオンボーディング担当、「立ち上がった後の継続的な活用支援・更新」がCSM、という境界にします。両者が同じ顧客を並走する期間を作らず、引き継ぎ点を明示するのが崩れないコツです。

CSオペレーション（CSOps：仕組み・データ整備担当）の責務

CSOpsは、CSチームが回るための仕組み・データ・ツールを整備する役割です。責務は次のとおりです。

• ヘルススコアや活用データの定義・収集・可視化の整備
• プレイブック（対応手順の型）やテンプレートの整備・更新
• ツール設定・自動化・レポート整備による運用効率化
• 役割間の情報連携ルールの設計

CSOpsは個別顧客ではなく「仕組みと再現性」に責任を持つ役割です。少人数期は後述のとおり兼務になりますが、テックタッチ比率が高い組織ほど早期に比重が上がります。

マネージャー／チームリードの責務（意思決定と例外対応）

マネージャーは、役割間で判断が割れたときの意思決定と、標準プロセスに乗らない例外対応を担います。責務は次のとおりです。

• 役割配置・人員配分の決定と見直し
• 解約リスク案件など、CSM単独で判断できない事案のエスカレーション対応
• 役割ごとの責任指標の設定と進捗のレビュー
• 営業・サポートなど他部門との境界調整

マネージャーは「体制そのものが機能しているか」に説明責任を持ちます。個別業務のRACIでは相談先（C）や説明責任者（A）として登場することが多い役割です。

少人数期の兼務パターン（1〜3名時の現実的な割り付け）

CS立ち上げ初期は、3系統をそれぞれ専任で置く余裕はありません。1名のときは全役割を1人が兼務しますが、その場合でも「成果の帰属」だけは役割単位で分けて意識します。2〜3名になったら、オンボーディング担当を切り出すことが考えられます。立ち上げ支援は工数が読みやすく、専任化の効果が出やすいためです。CSOpsは、後述のとおり顧客数と自動化ニーズが増えてから専任化します。兼務期でも、責任指標だけは役割ごとに分けておくと、後の専任化がスムーズになります。

営業・サポートとの役割境界の引き方

CS組織のトラブルの多くは、CS内部ではなく営業・サポートとの境界の曖昧さから起きます。「更新対応が抜ける」「営業とCSが同じ顧客を二重にフォローする」といった問題は、引き継ぎラインが定義されていないことが原因です。実務解は、引き継ぎを「入口（いつ・何をもってCSへ渡すか）」と「出口（いつ営業へ戻すか）」の2点で定義することです。この2点を言葉で決め、後述のRACIで一覧化すると、境界が運用でも崩れにくくなります。

営業→CSの引き継ぎライン（受注後の入口をどう定義するか）

営業からCSへの入口は、「受注した瞬間」ではなく「引き継ぎに必要な情報がそろった状態」で定義します。契約内容、導入目的、キーマン、営業段階で握った成功の定義といった情報が、CS側に渡っていなければ引き継ぎは成立しません。入口の条件を「受注登録＋引き継ぎ情報の記入完了」のように具体化し、その条件を満たしたらCSの担当が着任する、というトリガーを決めます。入口が曖昧だと、営業は「渡したつもり」、CSは「まだ聞いていない」という空白が生まれます。

サポートとの境界（問い合わせ対応と定着支援の切り分け）

サポートとCSの境界は、「受動か能動か」で引くと整理しやすくなります。顧客からの問い合わせに答える受動的な対応がサポート、顧客の成果に向けて能動的に働きかける定着支援がCSです。ただし、問い合わせの中に解約リスクの兆候が見えたときは、サポートからCSへ連携するルートを決めておきます。境界を引いたうえで、境界をまたぐ情報の受け渡し先を明示するのがポイントです。切り分けだけして連携ルートを決めないと、リスクの兆候がサポート側で止まってしまいます。

更新・拡大提案は営業とCSどちらが持つか（条件で言い切る）

更新・拡大の帰属は、金額規模と提案の性質で分けます。既存契約の更新や、活用の延長線上にあるアップセルは、顧客の状態を最もよく知るCS（CSM）が持つほうが精度が上がります。一方、新規部門への横展開や大型のクロスセルなど、営業的な折衝が必要な拡大は営業が持つほうが向きます。判断軸は「顧客の成果に紐づく提案か、新たな商談を作る提案か」です。前者はCS、後者は営業に寄せ、境界の案件は入口・出口のトリガーで受け渡します。どちらも持たない、あるいは両方が持つ状態だけは避けます。

RACIで役割・権限を整理する

責務を言葉で書いただけでは、運用で必ず崩れます。「誰が最終責任者か」「誰に相談してから動くか」が曖昧なまま日々の判断が積み重なるためです。これを防ぐのがRACI（実行・説明責任・相談・共有の4区分で権限を割り付ける整理法）です。業務を行、役割を列にした表で、1つの業務ごとに誰がどの区分かを埋めます。最重要の原則は、1つの成果につきA（説明責任）は必ず1人に絞ることです。以下、RACIの定義と作成手順、ありがちな崩れを示します。

RACIとは何か（初出定義：Responsible／Accountable／Consulted／Informed）

RACIは、業務ごとに関係者の役割を次の4区分で示す整理法です。

• R（Responsible：実行責任者）：実際にその業務を実行する人。複数いてよい
• A（Accountable：説明責任者）：その業務の成果に最終責任を負う人。必ず1人だけ
• C（Consulted：相談先）：実行前に意見を聞く相手。双方向のやり取りがある
• I（Informed：共有先）：結果を知らせる相手。一方向の連絡

RとAは同一人物のこともありますが、Aは業務ごとに1人という制約だけは崩しません。

CS業務別のRACI例（オンボーディング／解約リスク対応／更新提案）

主要なCS業務でRACIを埋めると、境界が具体的になります。たとえばオンボーディング完了なら、R＝オンボーディング担当、A＝オンボーディング担当（または少人数期はCSM兼務）、C＝営業（引き継ぎ情報の確認）、I＝CSM（完了後の引き継ぎ先）となります。解約リスク対応なら、R＝CSM、A＝CSMだが金額上位はマネージャーがA、C＝サポート・CSOps（データ提供）、I＝営業。更新提案なら、前節の判断軸に沿ってR/AをCSと営業に振り分けます。このように業務単位で埋めると、営業・サポートとの境界も同じ表の上で見えるようになります。

RACI作成でありがちな崩れ（Aが複数・Rが空欄）

RACIは作ること自体より、崩れを検知することに価値があります。よくある崩れは2つです。1つは、1業務にAが複数ある状態。これは「みんなで責任を持つ」という聞こえのよい言葉で正当化されがちですが、実務では誰も最終責任を負わない状態を意味します。もう1つは、Rが空欄の業務。誰も実行者がいない業務は、実際には放置されます。表を作ったら、「A列に1つずつAが入っているか」「R列に空欄がないか」を機械的に点検します。この2点の点検だけで、設計の抜けの大半が見つかります。

対応方針（タッチモデル）が役割配置に与える影響

顧客セグメントごとの対応の濃さ、いわゆるタッチモデル（ハイタッチ／ロータッチ／テックタッチ）を決めると、必要な役割と人数配分の検討につながります。金額上位の顧客に人が手厚く伴走するハイタッチが多いなら、CSMの人数が必要になります。逆に、多数の顧客をコンテンツや自動化で支えるテックタッチの比率が高いなら、個別対応のCSMよりCSOps・コンテンツ整備の役割が主役になります。つまりタッチモデルの設計は、役割配置とレポートラインの前提条件です。タッチモデル自体の設計方針はハイタッチ・テックタッチの設計に詳しいので、ここでは役割への影響に絞ります。

タッチモデル別に変わる役割の比重

ハイタッチ中心の組織では、1人のCSMが少数の重要顧客を深く担当するため、CSMの採用要件が高くなり、担当社数は少なくなります。ロータッチでは、標準化されたプレイブックに沿ってCSMが多めの顧客を回すため、プレイブック整備を担うCSOpsの役割が効いてきます。テックタッチが増えると、個別のCSMより、コンテンツ・自動化・データを整備する役割が成果を左右するようになります。同じ「CS組織」でも、どのタッチモデルを主に置くかで、必要な役割の顔ぶれが変わります。

テックタッチを増やすとCSOps・コンテンツ整備が主役になる

テックタッチは「人が対応しない」のではなく「人の代わりに仕組みが対応する」モデルです。そのため、ヘルススコアの設計、活用を促すメールやガイドの整備、利用状況に応じた自動アクションの設計といったCSOps・コンテンツ整備の工数が前面に出ます。テックタッチ比率を上げる意思決定をしたら、CSMの増員より先にCSOpsの専任化を検討するのが順序として合っています。役割の比重を、対応方針とずらさないことが要点です。

役割ごとの責任指標（KPIの割り付け方）

役割設計は、各役割が「何の数字に責任を持つか」まで決めて初めて完成します。責務を言葉で定義しても、責任指標がなければ役割は評価も改善もできません。割り付けの原則は、その役割が自分の行動で動かせる指標を割ることです。CSMは活用度と更新、オンボーディング担当はオンボーディング完了率と立ち上がり期間、CSOpsは運用の整備率や自動化のカバー率、というように、実行できる指標を紐づけます。指標そのものの設計方法はCSのKPI・目標設定に委ね、ここでは役割への割り付け方に絞ります。

役割と責任指標の対応（実行できる指標を割る）

責任指標は、役割が直接コントロールできるものを選びます。オンボーディング担当に継続率の責任を負わせても、更新はオンボーディング後の活用支援に大きく左右されるため、担当は自分の努力と評価が結びつきません。オンボーディング担当には完了率や立ち上がり期間、CSMには活用度と更新率・更新見通し、CSOpsには整備率や自動化カバー率、という具合に、その役割の行動で動く指標を割ります。指標が行動と直結していれば、数字の悪化がそのまま改善の打ち手につながります。

結果指標（継続率・LTV）は役割単位で追わない理由

継続率やLTV（顧客生涯価値）は組織全体の結果指標であり、複数の役割・部門の行動が積み重なって決まります。これを特定の役割1人の責任指標に置くと、その役割は自分の力で動かせない数字を背負うことになり、責任が空洞化します。結果指標はマネージャーや組織全体で追い、各役割にはその手前にある実行可能な先行指標を割る。この二層構造にすると、役割ごとの評価が公平になり、改善の打ち手も具体化します。

役割設計を運用に落とす実装ステップ

設計を紙で終わらせないためには、決まった順序で運用へ落とします。レポートラインの確定、引き継ぎフローの合意、プレイブックへの責任割り付け、情報基盤の整備、定例での見直し、の順です。この順序が重要なのは、レポートラインが決まらないと引き継ぎの合意主体が定まらず、情報基盤が整わないと引き継ぎフローが機能しないためです。属人化を防ぐには、プロセスの型化と情報の一元管理という両輪がそろって初めて効きます。片方だけでは、型があっても情報が個人に散り、情報が集まっても回し方が人によって変わります。以下、各ステップを示します。

レポートライン（誰が誰に報告するか）の確定

まず、各役割が誰に報告し、誰が意思決定するかを確定します。CSM・オンボーディング担当・CSOpsがマネージャーに報告するのか、オンボーディング担当だけ別ラインなのか、といった報告関係を1本に決めます。レポートラインが二重（複数の上長に報告）になっていると、判断の依頼先が分からず、例外対応が滞ります。RACIのA・Cと矛盾しないレポートラインにするのが要点です。

引き継ぎフローの合意とドキュメント化

次に、営業→CS、オンボーディング→CSMの引き継ぎフローを、入口・出口のトリガー付きで文書化し、関係する役割全員で合意します。口頭合意だけだと、担当者が変わった瞬間に運用が崩れます。「入口条件」「渡す情報の一覧」「着任のタイミング」「出口条件」を1枚にまとめ、営業とCSの双方が同じ文書を参照する状態にします。文書化は、後述の情報基盤の項目と合わせて設計すると二度手間になりません。

役割ごとにプレイブックの責任を割る

プレイブック（オンボーディング手順、ヘルスチェックの進め方、解約リスク対応など、対応の型をまとめた手順書）は、作って終わりではなく、更新し続けて初めて価値が出ます。そこで、どのプレイブックを誰が保守するかを役割ごとに割ります。オンボーディング系はオンボーディング担当、リスク対応系はCSM、全体のテンプレートや構成はCSOps、という具合です。プレイブックの作り方そのものはCSプレイブックの作り方に委ねますが、責任者を割らないと更新が止まる点は役割設計の論点です。

情報の一元管理｜引き継ぎ・更新の抜けを防ぐ基盤

引き継ぎと更新の抜けを防ぐ最後の土台が、顧客情報・案件・活動履歴を一元管理する基盤です。営業段階でつかんだ導入目的やキーマン、活動履歴がCS側から見えなければ、入口条件をいくら定義しても引き継ぎで情報が失われます。よく使われるのは、営業とCSが同じ顧客・案件データを参照できる仕組みです。たとえばMazrica SalesのようなSFA（営業支援システム）/CRM（顧客関係管理）で、取引先・案件・活動履歴を管理すると、受注後の引き継ぎで情報が失われにくくなります。こうしたツールでは、蓄積した活動履歴をAIが要約し、次のアクションを提案する機能を持つものもあります（要約・提案はAIが生成するため、内容は担当者が確認します）。同種の情報共有・要約機能は他社のSFA/CRMにもあり得るため、自社の引き継ぎフローに合う基盤を選びます。

役割設計チェックリストと見直しのタイミング

役割設計が機能しているかは、感覚ではなく点検項目で確認します。「1成果につき説明責任者が1人か」「引き継ぎの入口・出口が定義済みか」「役割ごとに実行可能な責任指標があるか」の3点は、最低限の合格ラインです。そして設計は一度作って終わりではなく、顧客数や人員が一定を超えたら兼務を解いて専任化する見直しが必要になります。以下、点検チェックリストと見直しのサインを示します。

設計の点検チェックリスト（判断の閾値つき）

次の項目を1つずつ点検し、1つでも「いいえ」があれば設計を修正します。

• 成果（継続率／オンボーディング完了率／更新・拡大 など）ごとに、説明責任者が1人だけ定義されているか
• 営業→CS、オンボーディング→CSMの引き継ぎに、入口・出口のトリガーが文書化されているか
• 各役割に、その役割の行動で動かせる責任指標が割り付けられているか
• RACI表で、A列に複数のAがある業務、R列が空欄の業務がないか
• サポートとCSの境界をまたぐ情報（解約リスクの兆候など）の連携ルートが決まっているか
• 各プレイブックに保守責任者が割り当てられているか

このリストは、設計時だけでなく、四半期など定例のタイミングで再点検する運用にすると崩れを早く見つけられます。

役割を見直す（専任化・分割する）タイミング

役割の見直しは、顧客数の増加、契約更新の集中、人員の追加といった変化が起きたときに検討します。兼務でオンボーディングとCSMを1人が担っていると、新規オンボーディングが集中する時期に既存顧客のフォローが薄くなる、といった歪みが出ます。この歪みが常態化したら、オンボーディング担当の専任化を検討するサインです。CSOpsは、扱う顧客数が増えて手作業のレポート作成やデータ整備が回らなくなったタイミングで専任化します。専任化の判断は、後述の過負荷サインとあわせて見ます。

兼務を解くべきサイン（過負荷・成果の重複・引き継ぎ漏れ）

兼務を解く判断は、次の3つのサインで行います。1つ目は過負荷で、担当者の稼働が特定業務に偏り、他の責務が後回しになっている状態。2つ目は成果の重複で、複数の役割が同じ顧客・同じ成果に重なって動き、二重フォローが起きている状態。3つ目は引き継ぎ漏れで、入口・出口を定義しても情報の受け渡しが間に合わず、抜けが繰り返される状態。このいずれかが継続的に観測されたら、兼務のまま人を足すのではなく、役割を分けて責務を切り出します。人を足すだけでは、境界の曖昧さはむしろ増えます。

まとめ｜条件別のおすすめ設計

CS組織の体制・役割設計は、目的によって重心を変えるべきです。解約抑止が主目的なら、金額上位の顧客へのハイタッチCSMに更新責任を集約し、オンボーディング完了率をオンボーディング担当の責任指標に置く設計が向きます。立ち上がりの失敗が解約の主因になりやすいためです。アップセル拡大が主目的なら、更新・拡大提案の帰属を先に決め、営業とCSの引き継ぎラインをRACIで固める設計にします。境界の曖昧さが拡大機会の取りこぼしに直結するためです。少人数（1〜3名）なら、役割を無理に分けず兼務で始め、責任指標だけを役割単位で分けておくと、後の専任化がスムーズになります。

立ち上げ全体の流れや費用・KPIの概観はCS組織の立ち上げ方に委ねます。本記事の内容を運用に落とす最初の一歩は小さく始めます。まず既存の業務を「成果」単位で書き出し、各成果の説明責任者を1人に決める。ここから始めれば、体制の箱を作り直さなくても、境界の曖昧さの多くは解消に向かいます。

よくある質問

Q CSMは1人あたり何社くらい担当するのが適切ですか。

A

担当社数はタッチモデルによって大きく変わるため、一律の目安を当てはめるのは危険です。金額上位の顧客に深く伴走するハイタッチなら少数、標準化した対応で多数を回すロータッチやテックタッチなら多くなります。まずどのセグメントにどのタッチモデルを置くかを決め、そのうえで1顧客あたりに必要な工数から逆算して担当社数を設計します。他社の数値を借りるより、自社のタッチモデルと工数から導くほうが現実に合います。

Q カスタマーサクセスとカスタマーサポートは分けるべきですか、統合すべきですか。

A

判断軸は、対応の性質と規模です。問い合わせ対応（受動）と定着支援（能動）を1人が兼ねられる少人数期は統合でも回りますが、顧客数が増えると、受動対応に追われて能動的な働きかけが止まります。この兆候が出たら分離を検討します。分ける場合も、サポートで拾った解約リスクの兆候をCSへ連携するルートは必ず設計します。分離それ自体より、境界をまたぐ情報連携が続くかどうかが成否を分けます。

Q CSオペレーション（CSOps）は少人数でも置くべきですか。

A

立ち上げ初期は専任を置く必要はなく、CSMやマネージャーが兼務するのが現実的です。専任化のサインは、顧客数の増加で手作業のレポート作成やデータ整備が回らなくなったとき、あるいはテックタッチ比率を上げる意思決定をしたときです。テックタッチは仕組みで顧客を支えるモデルのため、CSOpsの整備が成果を左右します。この2つのタイミングでは、CSMの増員より先にCSOpsの専任化を検討します。

Q 更新・契約更改は営業とCSのどちらが担当すべきですか。

A

既存契約の更新や、活用の延長線上にあるアップセルは、顧客の状態を最もよく知るCS（CSM）が持つほうが精度が上がります。一方、新規部門への横展開や大型のクロスセルなど、新たな商談を作る折衝が必要な拡大は営業が向きます。判断軸は「顧客の成果に紐づく提案か、新たな商談を作る提案か」です。どちらも持たない、または両方が持つ状態だけは避け、境界の案件は引き継ぎのトリガーで受け渡します。

Q 役割定義書はどの粒度まで書けばよいですか。

A

責務の箇条書きに加えて、RACIと責任指標まで書けば実務では十分です。責務だけだと運用で権限が曖昧になり、RACIだけだと評価の基準が抜けます。「担う成果」「主な責務」「業務別のRACIでの立ち位置」「責任指標」の4点をそろえると、採用要件にもそのまま使える定義になります。過度に詳細な業務手順はプレイブック側に切り出し、定義書は役割の骨格に絞ります。

Q CSはどの部門にレポートさせるのが良いですか。

A

目的によって変えます。解約抑止と顧客の成果に軸足を置くなら、営業配下ではなく独立、またはCS本部として置くと、短期の売上圧力から距離を取れます。逆に、更新・拡大の売上責任を強く持たせるなら、営業と近い配置にして連携を密にする選択もあります。判断軸は「CSに短期売上の責任をどこまで負わせるか」です。売上から独立させて顧客成果に集中させたいなら独立配置、更新拡大の数字を主目的にするなら営業に近い配置を検討します。