「入れない案」とも比べる——問い合わせ管理ツールの要件一覧

ツールの選定で、いちばん時間を溶かすのは「デモを見てから考える」ことだ。ベンダーごとに見せ方が違うので、比べようがなくなる。

前回、共有メールアドレスの未返信を GAS で検知した話を書いた。その会社（約70〜80名が1つの共有アドレスに関わる）で、続きとして問い合わせ管理ツールの選定を進めている。4製品と「ツールを入れずに今の環境で改善する案」を、2週間で順に商談した。比べられたのは、商談の前に要件一覧を作り、全製品を同じ物差しで見たからだ。この記事では、その要件一覧の作り方を書く。

▼要件には「優先度・根拠・確かめ方」をセットで書く

要件一覧は、1行ごとに4つの列を持たせた。

列	中身
要件	何ができてほしいか（機能名ではなく、困りごとの裏返しで書く）
優先度	必須（満たさなければ候補から外す）／推奨（加点）／任意（判断材料にしない）／要確認（現場に聞かないと決められない）
根拠	いつの会議で、誰の、どの困りごとから出た要件か
確かめ方	商談で何を聞くか、画面で何を見るか

「根拠」を書くのは、優先度の議論を早くするためだ。「なぜ必須なのか」と聞かれたときに、「この会議でこういう事故があったから」と答えられる。「確かめ方」を書くのは、商談で聞き漏らさないためだ。デモはベンダーが見せたいものから始まる。こちらが確かめたいことを先に持っていないと、見せられたものだけで判断してしまう。

もう1つ、こちらから提案した要件は「提案」と明記した。現場から出た要件と、外部の目で足した要件を混ぜると、優先度の合意が取りにくくなる。

▼共有アドレス運用の要件を7つに分けた

実際の一覧は30項目近くになった。分類と代表的な要件はこうだ。

分類	代表的な要件（優先度）
受信・振り分け	共有アドレスを窓口のまま使える（必須）／各自のアカウントで同じ受信箱を見られる（必須）／転送の上限に左右されない（必須）／振り分けに漏れたメールが誰かの目に入る（必須）
対応管理	担当の割り当て（必須）／対応状況と返信者が一覧で見える（必須）／二重対応の防止（推奨）／未返信を Slack に通知（必須）
計測	返信スピード・返信数・未返信数をチーム・担当ごとに出せる（必須）
業務データとの紐付け	メールごとに案件の URL を残せる（必須）／案件データベースとの自動連携（任意）
返信の効率化	テンプレートの共有と移行（推奨）／英語の画面（推奨）／AI の返信文生成（任意）
認証・セキュリティ	既存の IdP で SSO（必須）／IdP からアカウントの作成・停止（推奨・提案）／操作ログ（推奨・提案）／社内のセキュリティ審査を通る（必須）
運用・保守・移行	設定を管理画面で保守でき、特定の人に依存しない（必須）／試運転に間に合う（必須）／少人数から段階的に増やせる料金体系（必須）／やめるときに履歴を取り出せる（推奨・提案）

▼「ツールを入れない案」も、同じ物差しで比べる

比較表には、4製品に加えて「ツールを入れず、今の Google Workspace と GAS で改善する案」も入れた。

こうすると、ツールを入れて何が解決し、何が残るかがはっきりする。今の環境のままだと、転送の上限や同時ログインの制約、担当が見えない問題は残る。一方で、追加費用はかからず、運用も変わらない。「入れる理由」を、入れない案と比べて説明できることが、決裁を通すうえで大事だった。

▼商談で確かめること、鵜呑みにしないこと

確かめること

• ▶ SSO は標準か、有料オプションか。オプション扱いの製品が多く、費用に響く
• ▶ チームごとの閲覧制御のやり方。フォルダで分けられるのか、受信箱を分ける必要があるのか。受信箱の数が料金に響く製品がある
• ▶ 共有アドレスの取り込み方式。転送か、POP か、パスワードで同期するのか。方式によってはセキュリティ審査で引っかかる
• ▶ 送信の履歴がどこに残るか。製品の中で完結する方式だと、Gmail に送信履歴が残らなくなる。運用の変わり方が大きい
• ▶ 最低契約人数と、途中での人数の増やし方

鵜呑みにしないこと

商談では、ベンダーが他社製品の弱点を説明してくることがある。「あの製品には二重対応を防ぐ機能がない」といった話だ。それはその会社の主張であって、事実確認はこちらでする。比較表には「先方の説明・未検証」と書き分けた。

▼まとめ

• ▶ デモを見る前に、要件一覧を作る
• ▶ 要件ごとに優先度・根拠・確かめ方を書く。提案した要件は「提案」と明記する
• ▶ 「任意」を決めて、デモの華やかさに引っ張られない
• ▶ ツールを入れない案も、同じ物差しで比べる
• ▶ ベンダーの他社比較は主張。未検証と書き分ける