正しさではなく「許容範囲」で決める｜情シス取材でわかったSaaS移行の進め方

目次
• 導入判断は「正しいか」ではなく「止める理由があるか」
• 目的ありきで始まり、課題は後から見えてくる
• 「何を確認すればいいか分からない」状態で検証が始まる
• トライアルは「評価」ではなく「確認項目を増やす作業」
• 現場の協力は“自走する状態”まで設計する
• 最終的に判断を支えるのは現場の検証結果
• まとめ：判断の土台は、現場との検証でつくられる

導入判断は「正しいか」ではなく「止める理由があるか」

SaaSツールを移行する際に、「どのツールが最適か」を判断しようとしても、非実務部門が業務を完全に再現することは難しく、確信を持った評価はできません。実際の移行プロジェクトでも、「100%問題ない」と言い切れる状態で意思決定できるケースは限られます。

そのため移行判断は、「より優れているか」ではなく、「致命的な問題がないか」「業務として成立するか」といった観点に置かれます。つまり、「正しい選択かどうか」ではなく、“止める理由があるかどうか”で判断する形です。

では、なぜこのような判断基準になるのか。情報システム部門が主導したCTIシステム移行について、担当者への取材をもとに、その実態を見ていきます。

目的ありきで始まり、課題は後から見えてくる

非実務担当者がSaaSツール移行を主導する場合、最初から現場の課題が整理されているとは限りません。現場からの相談や上位レイヤーからの指示をきっかけに、課題や優先度が曖昧なまま動き出すケースもあります。

今回取材した企業でも、既存システムへの強い不満があったわけではなく、会議用ツールの文字起こし機能をきっかけに、「電話業務でも、文字起こし機能を活用できないか」という発想から検討が始まったといいます。実際にCTIシステムの切り替えを推進した情報システム担当者からは、次のような声が挙がりました。

「元のツールに課題があったから入れ替える、というよりは、すでに別の用途で使っていたツールがあって。これ現場でも使えないの、という形で上から降りてきた感じでした」

このように、明確な課題ではなく、既存のツール起点で検討が始まる場合、進める中で課題や必要な要件が具体化していきます。一方で、現場では既存ツールで業務が回っているため、「なぜ変えるのか」が見えにくい状態になりがちです。

「よほどのことがなければ、課題があるから別のツールに変えようとはならない。新しく変えると別のトラブルが出るかもしれないので」

この状態で進めるには、「なぜ変えるのか」「何が良くなるのか」を、自分の言葉で説明できる状態を作る必要があります。ツールの機能だけでなく、業務にどのような変化が生まれるのかという観点で整理することが重要です。

そのため、トライアル開始にあたり、目的・対象業務・役割分担を整理し、各部署にNotionで共有しました。あわせて、検証の中で何を確認するのかという観点もすり合わせています。

具体的には、現行の業務フローをもとに、トライアルで再現する業務範囲を定め、各担当の役割を切り分けました。また、「問題なく運用できる状態」の判断目安も共有しています。検証のポイントは、以下2点です。

検証では、業務での再現性や文字起こしの精度に加え、運用上のメリット・デメリット、外部連携の可能性なども確認し、関係部署ごとに役割を分担して、並行して検証を進めました。

「何を確認すればいいか分からない」状態で検証が始まる

非実務部門がツール移行を主導する場合、最初に詰まるのは機能ではなく、何を確認すれば判断できるかという観点そのものです。実務を担当していない立場では、重要な機能や判断基準を持てないため、どこまで確認すれば十分か分からないまま検証が始まります。今回も同様の状態からスタートしました。

「何を検証すればいいんですかって聞かれても分からない。そこが一番きつかったですね。例えば、モニタリングってどうやるんですか？と聞かれても、自分も使ったことないから分からない」

実際には、トライアルを依頼したカスタマーサクセスの現場から「何を見ればいいのか」「どこまで確認すればいいのか」といった質問が上がります。しかし、判断基準を示せないため、検証が止まりかける場面もありました。

この状況に対しては、要件を最初から固めるのではなく、検証を進めながら確認項目を整理していく進め方を取りました。

「まずはトライアルの担当者を複数人決めて、実際に触ってもらいながら出てきた疑問点を拾っていきました」

具体的には、現場の担当者複数人に、実際にツールを使ってもらい、出てきた疑問や違和感を都度拾い上げ、確認項目として整理しました。

例えば、「通話履歴はどこに残るのか」「CRMとの連携はどう動くのか」「転送は問題なくできるのか」など、トライアルに出てきたタイミングで一つずつ確認し、検証項目として追加していきました。

非実務部門が主導する場合は、 最初に要件を固めるのではなく、現場の操作や質問を起点にして確認観点を後から作っていく必要があります。そうしなければ、「何を検証すればいいか分からない」状態のまま、トライアルが形骸化してしまいます。

トライアルは「評価」ではなく「確認項目を増やす作業」

トライアルは一般的に「ツールを評価するフェーズ」と捉えられますが、非実務部門が主導する場合、そもそも評価基準がありません。どの機能が重要か分からないため、良し悪しを判断する前提が欠けています。

今回も、評価に進むための前提が整わないまま、検証の方向性が定まりにくい状態からスタートしたといいます。

「ベンダー（ツール提供会社）の担当者に都度確認して、実際に自分でもできるだけ試してみて、分かったらマニュアルに記載していくといった手探りでした。分からないことが発生したら都度、全部リストに入れて一つずつ確認していくしかない」

現場からは操作方法や再現可否に関する質問が次々に上がりますが、事前に整理された回答はなく、その場で確認しながら地道に潰していくしかありません。

その結果、トライアルは「評価」ではなく、疑問を蓄積し、ベンダーに確認し、内容をマニュアル化する作業の繰り返しになります。この過程を通じて、初めて問題点や許容範囲が可視化されます。

一方で、非実務部門では確認しきれない領域もあります。

「実際の電話業務で試してみないと分からない部分は、実際に使ってもらうしかない」

顧客対応時の使い勝手や通話中の細かなストレスなどは再現できないため、最終的な判断の一部は現場に委ねる必要があります。

つまり、トライアルは「評価」ではなく、不明点を解消し、判断に必要な情報を整備するプロセスとして設計する必要があります。評価軸が存在しない状態では、検証自体が成立しません。

現場の協力は“自走する状態”まで設計する

非実務部門が主導する場合、トライアルや検証の実行は現場に依存します。ただし、現場にとってツール検証は本来業務ではないため、依頼しただけではスムーズに進むとは限りません。

「忙しいからできない、といった気持ちはあったかもしれませんね」

このままでは検証が偏り、十分な情報が集まらないまま判断できなくなります。そのため、現場の協力を前提にするのではなく、検証が自走する状態を作る必要があります。

今回のケースでは、作業を分解し、実行しやすい形に落とし込みました。

「スプレッドシートを作って、疑問が発生したら都度入れてもらうようにしていました。リマインドして…それの繰り返しです」

誰が・何を・どこに入力するかを明確にし、リマインドで進捗を維持しています。また、疑問や不明点はその都度回収し、検証が止まらない状態を保つようにしました。

また、トライアル中は必ず疑問や不明点が発生します。ここで対応が止まると、現場はツールを触らなくなり、検証も進まなくなります。

「質問が来たら全部拾って、確認して、質問に対する回答を作っていく。ずっとサポート係みたいな感じで、聞かれたら答えるのを繰り返してました」

この対応は単なるサポートではなく、検証を止めないための仕組みの一部です。現場は本来の業務と並行して対応しているため、負担をかけている感覚も常に伴います。

「ここが一番大変でしたね。ずっと“すみません”って思いながらやってました」

非実務部門が主導する場合、現場は自然には動きません。そのため、依頼・実行・フィードバックの流れを設計し、人に依存せず進む状態を作ることが前提になります。

最終的に判断を支えるのは現場の検証結果

非実務部門が主導していても、最終的な判断の根拠になるのは現場の検証結果です。これは単に「現場の意見を尊重する」という話ではなく、それ以外に判断できる材料がないためです。

使い勝手や業務への影響を自分で再現できない以上、「問題なく回るかどうか」は現場の結果に依存します。今回も、確信を持って判断できる状態ではありませんでした。

「本当に大丈夫かと言われても、100%ですとは言えない」

それでも導入が進んだのは、「致命的な問題が出ていない」ことが、現場の検証で確認できていたためです。

「検証してもらってるから大丈夫だよね、という感じでした」

重要なのは、「良いから進めた」のではなく、“問題がない範囲で進めている”という点です。

非実務部門が主導する場合、意思決定には常に不確実性が伴います。そのため、完全な確信ではなく、現場の検証結果をもとに「許容できる状態かどうか」で判断することになります。

役割は結論を出すことではなく、現場の検証を通じて情報を集め、判断できる状態を作ることです。この状態が整わなければ判断は止まりますが、現場の検証結果が揃っていれば、100%の確信がなくても意思決定は進められます。

まとめ：判断の土台は、現場との検証でつくられる

非実務部門が主導するツール導入・移行は、一定の目的意識はあるものの「何をどこまで実現するのか」「何を確認すべきか」が整理されていない状態から始まるケースも多く、進めながら論点を整理していくプロセスになります。

求められるのは正しい答えを出すことではなく、現場に触ってもらい、疑問を潰しながら判断材料を揃えることです。また、検証が止まらないよう仕組みとして設計する必要があります。

最終的な判断も、「最適かどうか」ではなく、「致命的な問題がないか」「許容できるか」で行われ、その根拠は現場の検証結果にあります。

「どれだけ実際に使う人に本気で協力してもらえるか、それだけだと思います」

非実務部門が担う役割は、ツールを評価することではありません。現場の検証を通じて情報を集め、確信が持てなくても判断できる状態を作ることにあります。