唐澤智哉 
唐澤経営コンサルティング事務所の唐澤です。中小企業診断士・ITストラテジストの資格を持ち、20年以上にわたり経営戦略立案や業務改革、IT化構想策定などのコンサルティングに従事してきました。現在は中堅・中小企業に特化したコンサルティングをしています。
このコラムでは、私のこれまでのコンサルティング経験をもとに、中堅・中小企業の経営に役立つ情報を発信しています。
「IT導入やシステム開発を進めるにあたって、どのように要件をまとめればいいのか分からない」「IT部門や外部ベンダーと話がかみ合わず、プロジェクトが途中で頓挫してしまった」というお悩みやご相談を聞くことがあります。そこで１つポイントとなるのが、「業務要件」と「システム要件」をしっかり区別して理解し、それぞれを整理しながら明確化することです。
実は多くの企業で、業務要件とシステム要件を混同したままプロジェクトを進めてしまい、「気づけば現場が望んだシステムとは異なるものができてしまった」「システムは完成したが、使いづらくて結局現場で浸透しなかった」という事態に陥りがちです。
そこで本コラムでは、業務要件とシステム要件の基本的な違いを分かりやすく解説しながら、どのように整理し、プロジェクトを成功に導くためには何が必要なのかという点について、私のコンサルタント経験を踏まえてお伝えします。
その前に。要件を分ける前に、順序があります
業務要件とシステム要件の違いに入る前に、1つだけ先にお伝えします。
検討の順序は、経営課題 → 業務課題 → ITツールです。
この記事でお伝えする「業務要件」は、真ん中の業務課題にあたります。そして、その手前に経営課題があります。「この会社はこれから何で稼ぐのか」「何を守るのか」。ここが決まっていないまま業務要件を書き始めると、書けたように見えて、実は何も決まっていません。
ベンダーとの話が噛み合わないとき、原因はたいていここより手前にあります。技術の話が通じないのではなく、そもそも何のために作るのかが、社内で決まっていないのです。
先に、いちばん大事なことを1つだけ
要件定義は、発注者の責任です。
IT導入を検討されているお客様に、私が必ず最初に申し上げることです。そして、ここが最も伝わりにくいところでもあります。
業務要件を決められるのは、ITベンダーでも、情報システム部門でもありません。決められるのは、その業務を実際にやっている部門です。営業部、購買部、生産部、経理部——毎日その仕事をしている人たちです。ベンダーと情報システム部門は、それを手伝う側にいます。
ここが逆転した瞬間に、プロジェクトは崩れ始めます。「業務のことは分からないので、御社で決めてください」とベンダーに言った時点で、そのシステムは、誰の業務にも合わないものになります。
業務要件とは？
業務要件の定義
業務要件という言葉を平易に表現するならば、「自社が目指すビジネス上の活動・サービスを実現するための要望・ニーズ」と言えます。具体的には、経営者や管理職、さらには現場部門が抱く「業務プロセスをこのように改善したい」「生産性をこれだけ向上させたい」「従来手作業でやっていたこの業務を自動化したい」といった要望になります。
例えば受発注業務であれば、「注文を受けたら当日に出荷指示を出し、翌日には商品をお客様に届けたい。これを実現することで顧客満足度を高め、リピート率向上を図りたい」といった具合です。このような「現場の本音」や「経営上の狙い」を反映させた業務上の具体的な条件が業務要件です。
業務要件の重要性
業務要件をきちんと整理せずにシステム開発やIT導入に着手してしまうと、後々「求めていた機能はこれではない」「この工程で自動化が止まってしまい、かえって作業が増えた」など、現場の混乱や追加費用が発生しがちです。特に中堅・中小企業では、限られた資金・人材でプロジェクトを進めるケースが大半であるため、プロジェクトの途中で要件漏れが判明して大きな修正が必要になると、そのまま計画そのものが破綻してしまう可能性もあります。独立行政法人情報処理推進機構（IPA）が発行した『要件定義を成功に導く128の勘どころ』では、要件定義の不備がシステム開発プロジェクトの失敗要因として挙げられています。この資料では、要件定義の重要性が強調されており、特にユーザー企業側の活動の遅れや要件の不明確さが問題視されています。
また中堅・中小企業においては、人的リソースやITに関する知見が限られていることが多く、要件定義の段階で十分な検討が行われないケースが見受けられます。このため、業務要件を確実にまとめることがプロジェクト成功のカギとなります。IPAの資料『失敗しない要件定義とリスク対策』では、要件定義の段階でのリスク対策や、経営者の視点での問題認識と対策の重要性が述べられています。
IT導入における要件定義が適切に行われない場合、導入後の運用で失敗するリスクが高まります。要件定義は、企業の業務や目的を明確にし、それに基づいたシステムを構築するための重要なステップです。そのため、経営層や現場の担当者が積極的に関与し、外部の専門家の支援を受けながら、具体的な要件を明確にすることが求められます。要件定義の段階で十分な検討と合意形成を行うことで、プロジェクトの成功率を高め、IT投資の効果を最大化することが可能となります。
システム要件とは？
システム要件の定義
一方でシステム要件とは、先ほどの「業務要件を、どのようなITの仕組みで実現するのかをより技術的に落とし込んだもの」です。ITベンダーやシステム開発会社が中心となり、「必要な機能」「動作環境」「処理速度」「セキュリティ対策」など具体的な仕様を決めていきます。例えば、先ほどの受発注業務の例で言えば、以下のような具体的な技術仕様や機能要望がシステム要件となります。
- インターネットを介したクラウド型の受発注システムを利用し、注文内容がリアルタイムで倉庫と共有される仕組みを構築する
- 受注データは同時に在庫システムとも連携し、在庫状況が随時更新されるようにする
- 納品書や送り状を自動で発行する機能を搭載し、二重入力・二重発行のミスを防止する
システム要件の重要性
システム要件を適切に設定するためには、専門知識が必要になります。ITベンダーやSE（システムエンジニア）と連携して、企業としてのセキュリティポリシーや外部環境との連携要件、また予算や導入スケジュールなどを総合的に勘案しながら検討する作業が求められます。 特に中堅・中小企業の場合、大企業ほどの予算やIT専門人材が確保できないケースが多いので、「導入後の運用担当が誰になるのか？」「カスタマイズをどこまで許容できるか？」「将来の拡張性はどこまで見込むのか？」といった観点で、地に足の着いた判断が不可欠です。システム要件の決定を「丸投げ」にすると、想定外のコスト増や運用の難航に直面しかねません。
業務要件とシステム要件の具体的な違い
業務要件とシステム要件の主な違いは、次の3点となります。
違い①：フォーカスする視点の違い
- 業務要件：経営・現場の視点から、組織や顧客に対して「何をどう実現したいのか？」
- システム要件：ITの視点から、「どんな機能や技術要素を使って要望を実現するのか？」
違い②：決定プロセスの違い
- 業務要件：経営側・現場側が主体となり、問題点と課題を洗い出し、「目標達成に必要な要素」を抽出する
- システム要件：システム担当者やITベンダーが主体となり、業務要件を実現するための「最適なソリューション」を検討する
違い③：必要とされる知識の違い
- 業務要件：自社のビジネスモデルや業務フローの理解、また現場スタッフの作業工程・困りごとの把握
- システム要件：IT技術やプログラミング言語、サーバー・ネットワーク・セキュリティなどの技術的知見
なぜ中堅・中小企業は業務要件とシステム要件を混同しがちなのか？
中堅・中小企業では、IT部門そのものが存在しなかったり、仮にそんざいしていたとしても人材が少ないケースが大半です。そのため、経営者や現場管理職の「使えるITシステムが欲しい」という思いだけでプロジェクトに着手してしまうことがよくあります。すると、業務要件が十分に言語化されないままITベンダーに依頼することになるため、ITベンダー側も「導入したい機能はこんな感じですね」と大雑把に受け取って開発を進めてしまう――このような流れの中で、気づいたら「業務要件とシステム要件の区別が曖昧」になりがちとなるのです。
もう1つ、私が現場でよく見る失敗があります。最初からフルスペックを求めてしまうことです。
「せっかく入れるのだから、全部できるようにしたい」。この一言で、要件は際限なく膨らみます。そして予算と期間を超え、途中で止まります。止まったプロジェクトは、次の投資判断を何年も止めます。
決めるべきは「何ができるか」ではなく、「何をやらないか」です。ここを先に決めておかないと、要件定義は必ず膨張します。
実際、中小企業庁が公表している「中小企業白書2023』によれば、多くの中小企業がデジタル化やIT導入を進める際に、社内のIT人材の不足を主要な課題として挙げています。具体的には、「IT、デジタル人材は採用していない」という企業が7割に達し、「IT、デジタル人材が不足している」と訴える企業まで含めると9割を超える状況です。
また、要件定義の不備がプロジェクトの失敗につながることも指摘されています。一般社団法人日本情報システム・ユーザー協会（JUAS）の「JUASソフトウェアメトリックス調査2016」によれば、DXプロジェクトの失敗原因として、要件定義フェーズでの問題が30～44%を占めており、計画段階での検討不足が主な要因とされています。
業務要件を整理するためのステップ
業務要件とシステム要件をスムーズに切り分けるためには、まず「業務要件を徹底的に整理する」ことが重要です。ここでは代表的な考え方に基づくシンプルな４つのステップをご紹介します。
社員50名の建設会社で、実際に起きたこと
もう1つ、規模の近い例をお話しします。
社員50名ほどの建設会社を支援したときのことです。工事の受注量が急に増え、現場も事務も追いつかなくなっていました。
ご相談は「システムを入れたい」というものでした。しかし現状の業務を洗い出していくと、本当の問題はシステムではありませんでした。
工事番号が、業務の軸になっていなかったのです。見積・発注・原価・請求が、それぞれ別の管理表で動いていました。だから同じ数字を何度も入力し、月末に突き合わせるだけで数日かかっていた。
やったことは、まず「工事番号を軸に管理する」と決めることでした。システムの話は、その後です。二重入力と集計作業をなくす形で、工事管理の仕組みを設計し直しました。
結果として、全社で30%以上の業務効率化が見込める状態になり、運用開始から1年未満で、管理部門の残業時間が20%以上減りました。月次決算も回るようになり、経営判断のスピードが変わりました。
順序を入れ替えただけです。先にシステムを入れていたら、いまの混乱がそのままデジタル化されていました。
ステップ1：現状の業務フローを可視化する
- 現行の業務を整理し、どのような手順で、どの部署が、どんな作業を行っているかを業務フロー図として可視化し、把握します。
- この際、実際に手を動かしている現場担当者から直接ヒアリングし、日常業務で起こっている「非効率のポイント」「トラブルの原因」を明確にします。
以下が業務フロー図の作成例です。
業務フローの書き方については以下の記事で解説しています。
ステップ2：経営上のゴール・KPIを設定する
- 「なぜシステム導入（または刷新）が必要なのか？」「システム導入（または刷新）によって、どんな経営上の価値を高めたいのか？」を明らかにします。例えば、「作業時間の短縮」「売上アップ」「人件費の削減」「顧客満足度の向上」など、できるだけ定量化できるゴールを設定します。
- KGI（最終的な目標）とKPI（中間目標）という言葉がありますが、これらを無理に使う必要はありません。要は「どうなったら成功と言えるのか？」を社内で共通認識にすることが大切です。
ステップ3：具体的な課題の優先順位を決める
- ゴールを達成するために必要な要素は何か、「必須」「推奨」「あれば望ましい」といった優先度に分けて整理します。
- 中堅・中小企業の現場では、多くの課題が同時多発的に発生しているケースが珍しくありません。すべてを一度に解決しようとすると混乱しやすいため、優先順位を明確にしましょう。
ステップ4：現場の声を吸い上げ、要望を言語化する
- 現場レベルの「こういう機能が欲しい」という意見や不満・要望をできるだけ吸い上げ、分かりやすい言葉にまとめます。
- この段階では、ITの技術的制約は一切気にせず、とにかく「業務として何を実現したいか」に焦点を当てて自由に意見を出してもらいます。
この4ステップを経て、ようやく「何を実現したいのか」という業務要件の全体像が見えてきます。こうした整理こそが、次に挙げる「システム要件」を正確に導く土台となるわけです。
決めた業務要件を、どうやってベンダーに渡すか
ステップ4まで進むと、「何を実現したいか」が社内に揃います。多くの会社がつまずくのは、その次です。
揃えた要件を、口頭の説明と既存帳票のコピーだけでベンダーに渡してしまう。すると何が起きるか。ベンダーは、自社の標準機能で説明できる範囲に、御社の業務を寄せて理解します。悪意があるわけではありません。それ以外に理解のしようがないからです。
渡し方には型があります。提案依頼書（RFP）です。
RFPに書くべきなのは、「ほしい機能」ではありません
私はこれまで複数の会社で、新しい基幹システムを入れるための提案依頼書を作ってきました。そこで一貫して書かないようにしているのが、「ほしい機能の一覧」です。
機能を書くと、提案は「その機能があるかないか」の答え合わせになります。書くのは、解決したい業務の状態です。
| 機能で書く（避けたい書き方） | 業務の状態で書く（推奨） |
|---|---|
| 在庫照会画面がほしい | 営業が客先で、その場で引当可能な在庫を答えられるようにしたい |
| 原価計算機能がほしい | 月次の原価が翌月5営業日以内に確定するようにしたい |
| 承認ワークフローがほしい | 出張中の役員がいても、承認で3日以上止まらないようにしたい |
左は「機能があるか」しか判定できません。右は、提案が本当に効くかどうかを判定できます。そして右の書き方をすると、ベンダーごとに違う解き方の提案が返ってきます。比較できるようになるのは、このときです。
「今と同じにしてください」は、要件ではありません
提案依頼書を作っていて、いちばん多く出てくる要望がこれです。しかし「今と同じ」は要件になりません。
「今」を再現するには、今の業務のすべてを、誰かが書き出さなければなりません。それを書き出せる人が社内にいないから、システムを入れようとしているはずです。「今と同じ」と言った瞬間に、その定義作業はベンダーに丸投げされ、ベンダーは自分に都合よく解釈します。そして稼働後に「前のほうが良かった」となります。
決めるべきなのは、「何をやらないか」です
中堅・中小企業のシステム導入がふくらむ原因は、ほとんどがこれです。あれもこれもと積み上げ、最初からフルスペックを求めて、予算も期間も膨張する。
優先順位をつける作業は、実は「何をやるか」を選ぶ作業ではありません。「何を今回やらないか」を、経営として決める作業です。やらないと決めたものは、提案依頼書にはっきりそう書きます。書いておくと、ベンダーからの提案も、社内からの後出しの要望も、そこで止まります。
なお、追加開発（アドオン）を大量に前提とした提案依頼書には、そもそも提案を出さないベンダーが増えています。パッケージの標準に業務を合わせるのが前提になってきているためです。「何をやらないか」を決められない会社は、提案すら集まらなくなってきている、ということです。
システム要件を正しく導くためのポイント
ポイント①：ITベンダーとの綿密な連携
システム要件を策定する際には、ITベンダーやシステム担当者と以下のようなポイントを詰めていきます。
- 機能要件：必要な機能リスト、その優先度
- 非機能要件：システムの性能やセキュリティ、操作性、メンテナンス性など
- 導入・運用体制：サーバー環境、ネットワーク回線、クラウド利用の有無など
- 予算・スケジュール：初期導入費用、保守費用、納期、運用開始時期
ITベンダーから技術的な提案を受けるだけでなく、経営者側からも「このような未来像を描いている」「今後2年で売上がこれくらい伸びる予定なので、サーバー負荷やトラフィックの想定を考慮したい」といった情報を積極的に提供しましょう。ここで双方向の対話が不足してしまうと、後から「想定外のコスト増」や「機能の過不足」が起こる可能性が高まります。
ポイント②：試作・デモ段階での確認をこまめに行う
システム開発のプロジェクトでは、要件定義の段階で作成した資料が途中で一人歩きしてしまうことがあります。要件定義書はプロジェクトの初期段階で作られますが、実際に開発してみると「思っていた仕様とちょっと違う」「操作画面が複雑すぎる」といった問題が見つかるのはよくあることです。したがって、プロトタイプ（試作品）やデモ版を早めに提示してもらい、現場の管理職や実際にシステムを使うスタッフに動作イメージを確認してもらうことが大切です。これにより、システムの完成が近づいてから大掛かりな修正を求めるリスクを低減できます。
ポイント③：長期運用を見据えた要件策定
システムは作って終わりではなく、運用開始後もメンテナンスやバージョンアップが必要です。中堅・中小企業にありがちなのが、「導入時だけ外部ベンダー任せにし、社内にノウハウが蓄積されない」というケースです。今後も社内運用が続く以上、将来的には機能追加や他システムとの連携を検討する可能性もあります。
- 運用担当は誰がどのように行うか
- どの程度の期間でシステムアップデートが必要になるか
- サポート費用やクラウド利用料はどれだけ継続的に必要か
こうした点を考慮に入れながら、過度に最新技術に飛びついたり、逆に古い技術に固執しすぎたりしないよう気をつけましょう。
すでにプロジェクトが動いている場合は、どうすればいいか
ここまでは、これから始める会社に向けて書いてきました。しかし相談として多いのは、「もう動いているが、これでいいのか分からない」というものです。
途中からでも、確認できます。次の3つのうち2つが当てはまるなら、一度立ち止まって見直したほうがいい状態です。
① 要件定義書に、自社の業務用語が1つも出てこない
御社が毎日使っている呼び方が1つも出てこず、一般的なIT用語だけで書かれているなら、それはベンダーの標準機能の説明書であって、御社の要件定義書ではありません。
② 「現行踏襲」「今と同じ」と書かれた項目がある
前の章で書いたとおりです。この項目は、稼働後にほぼ確実に問題になります。
③ 追加開発（アドオン）の件数が、当初の見積から増え続けている
増えること自体が問題なのではありません。増えた理由が「業務要件が後から出てきたから」なら、要件定義が終わっていないまま先へ進んでいます。
誰に見てもらうか
見直すときに、そのシステムを売っている会社に「これでいいですか」と聞いても、答えは出ません。利害が一致していないからです。
判断できるのは、そのシステムを売っていない人です。「入れないほうがいい」「今回はやめて現行を使い続けたほうがいい」という結論を出せる立場にいるかどうか。そこだけ確認してから相談してください。
当事務所では、顧問型 業務・ITコンサルティングとして、発注者側に立った要件の点検や、ベンダーとのやり取りへの同席を行っています。特定の製品を売っていないため、「今回は見送るべき」という結論も出せます。
業務・ITコンサルティングのご案内はこちら
Q&A
Q1. 業務要件とシステム要件のまとめ方に“正解”はありますか？
A: 企業の業種や規模、組織文化によって最適解は変わります。ただし、共通するポイントは「まずは業務要件ありきで考え、システム要件はその後に決める」という検討順序です。業務要件が曖昧なままシステム要件を先に固めてしまうと、後になって手戻りが多発するリスクが高まります。
Q2. システム開発会社を選ぶ際に気をつけるべき点は何ですか？
A: 「自社の業務やビジネスモデルを理解しようとする姿勢があるか」「コミュニケーションが取りやすいか」「サポート体制が整っているか」などを重視してください。IT技術力の高さはもちろん重要ですが、業務要件を深く理解してくれるかどうかが成功のカギになります。
Q3. 社内にIT知識がほとんどない場合、どうすればいいですか？
A: 経営コンサルタントやITコーディネータなど、外部の専門家にサポートを依頼するのも一つの方法です。特に、中小企業庁や自治体でもIT導入支援策や補助金が出ている場合がありますので、活用できる公的サポートがないか調べると良いでしょう。
Q4. 要件定義の段階で、どうしても社内で意見がまとまらない場合はどうすればいいですか？
A: まずは意見が対立する理由を洗い出し、「本当にその機能が必要なのか」「何のために導入するのか」という目的に立ち返りましょう。また、対立している当事者同士だけでなく、第三者（コンサルタント等）や社内の別部署も交えて幅広く意見を聞くと、新たな打開策が見えることもあります。
Q5. IT導入が成功しても、その後の業務改革が進まないことはあります？
A: あります。システムを導入したことで満足してしまい、現場での業務改善が中途半端に終わるケースです。システム導入はあくまで「手段」であり、目的はあくまで「業務プロセスや経営の改善」です。導入後に、業務フローがどう変化したか、成果が上がっているかを定期的に点検し、必要に応じて運用ルールの改善や社員教育を継続しましょう。
生産管理システムの選び方については以下の記事でも解説していますので、もしよろしければお読みください。
Q. 機能要件・非機能要件とは、どう違うのですか？
A. 3つは並列ではなく、階段になっています。
| 段 | 何を決めるか | 決める人 |
|---|---|---|
| 業務要件 | 業務としてどうなっていたいか | 発注者（業務部門・経営） |
| 機能要件 | そのために、システムが何をするか | 発注者とベンダーで詰める |
| 非機能要件 | 速さ・止まらなさ・守り（性能／可用性／セキュリティ／保守） | ベンダー主導。ただし判断は発注者 |
機能要件と非機能要件を合わせたものが、おおむね「システム要件」です。混乱の原因は、いちばん上の業務要件を飛ばして、機能要件から始めてしまうことにあります。
Q. 「ビジネス要件」という言葉も聞きます。業務要件と同じですか？
A. 現場ではほぼ同じ意味で使われますが、分けて使うなら、ビジネス要件は「経営としてこうなりたい」、業務要件は「そのために現場の仕事がこう変わる」です。「粗利率を2ポイント上げたい」がビジネス要件、「見積時に原価が見えるようにする」が業務要件、という関係になります。どちらの語を使うかで揉める必要はありません。大事なのは、その2つを飛ばしてシステムの話を始めないことです。
Q. 業務要件は、具体的にどう書けばいいですか？
A. 1行の型があります。「【いつ】【誰が】【何をできる／どうなっている】状態にしたい。いまは【どうなっている】から」です。
例：「月次の締めのとき、経理担当が、部門別の粗利を翌月5営業日以内に確定できる状態にしたい。いまは手作業の突合に10日かかっているから」
「いまはどうなっているか」を必ず書いてください。これが無いと、ベンダーは「それは今のシステムでもできますよね」と返してきます。
まとめ
ここまで、業務要件とシステム要件の違い、そしてその要点や注意すべきポイントを整理してきました。中堅・中小企業がITプロジェクトを成功させるうえで、最も大切なのは以下の点です。
- 業務要件を明確にする
- 「何を実現したいのか」「どんな課題を解決したいのか」を現場レベルから経営レベルまでしっかり言語化する。
- システム要件はその延長線上で考える
- 技術的なトレンドやコスト、運用体制などを踏まえつつ、業務要件を実現するための最適解を検討する。
- 社内外の連携を密にとる
- 経営者、現場担当者、ITベンダー、コンサルタントなど、関係者が同じゴールを共有しながら進める。
- 導入後の運用定着を重視する
- システム導入はスタートラインに過ぎず、その後の社内浸透や運用改善の継続が不可欠。
多くの企業がIT導入に失敗する原因の一つが「業務要件とシステム要件の区別があいまいなままプロジェクトを進めてしまうこと」です。逆に言えば、この2つをしっかり区別し、かつ両者をうまく結びつけることができれば、システム導入による生産性向上や売上拡大を十分に狙うことができるでしょう。
経営コンサルタントとして、私は様々なITプロジェクトに関わってきましたが、「業務要件ありき」で進める姿勢が最終的な成功を左右するケースを何度も目の当たりにしてきました。社内にITの専門家が少なくとも、最初に「本当に必要なもの」を徹底的に洗い出すことができれば、その後のITベンダー選定やシステム要件策定もスムーズに運びます。
あなたの会社が、より生産性が高く、かつ競争力のある企業へ成長するための一助となれば幸いです。ぜひこのコラムを参考に、現場の声と経営の視点を取り込みながら、業務要件とシステム要件を整理し、プロジェクト成功への道を切り開いていただければと思います。 今後も経営課題の解決やIT活用に向けたヒントを随時発信していきますので、引き続きご愛読いただければ幸いです。最後までお読みいただき、ありがとうございました。
業務要件を把握するための第一歩は「業務の見える化」です。当事務所のオリジナル資料「DXで失敗しないための「業務の見える化」と「課題整理」実践マニュアル」を無料で公開しています。以下よりダウンロードの上、ご活用ください。
デジタル化やDXの具体的な進め方やツール選定、社内体制づくりなど、お悩みやご不明点がありましたらお気軽にご相談ください。唐澤経営コンサルティング事務所では、中小企業診断士・ITストラテジストとして、中小企業の規模や業種に合わせた最適なアドバイスとサポートを行っています。
お問い合わせや無料相談は、以下のフォームからお願いいたします。
経営者が抱える経営課題に関する
分からないこと、困っていること、まずはお気軽にご相談ください。
ご相談・ご質問・ご意見・事業提携・取材なども承ります。
初回のご相談は1時間無料です。
LINE・メールフォームはお好みの方でどうぞ（24時間受付中）