導入事例や口コミを見ても、うちに当てはまるのか分からない

何かを導入しようと調べ始めると、まず出てくるのが「導入事例」と「口コミ」だ。読めば読むほど、うまくいった話が並んでいる。それでも「で、うちの場合はどうなのか」という肝心のところだけが、いつまでも埋まらない——この辞典が扱うのは、その場面である。

• 導入事例のページを開くと、成功した話ばかりが載っている。うまくいかなかった例は、どこにも見当たらない。
• 事例に出てくる会社は、自社より規模が大きかったり、業種が違ったりする。「うちと同じだ」と思える例が、なかなか見つからない。
• 口コミは星の数こそ多いが、書いた人がどんな会社で、どんな使い方をしているのかまでは書かれていない。
• 「同業の◯◯さんも入れたらしい」と聞いて安心しかけたが、よく考えると、その会社の中の事情までは知らない。
• 良いレビューと悪いレビューが両方あって、結局どちらを信じればいいのか分からない。
• 営業から「御社と同じ業種でも導入実績があります」と言われ、それが決め手になりそうになる。

「導入事例や口コミを見ても、うちに当てはまるのか分からない」という言葉が出るとき、たいていその裏には、成功例をいくつ読んでも自社の判断が進まないまま過ぎた時間がある。

ここで、たいていの会社が取る手は決まっている。

「当てはまるか分からないのは、自社に近い事例をまだ見つけられていないからだ。もっと同業・同規模の事例を探せば、あるいはもっとリアルな口コミを見つければ、うちに当てはまるかどうかが見えてくるはずだ」

だから、事例を探し回る。メーカーのサイトだけでなく、レビューサイト、SNS、知り合いの伝手。少しでも自社に近い成功例はないかと、時間をかけて集める。

他社の経験に学ぶ、という向きである。

だが、事例をどれだけ集めても、たいてい「当てはまるか」ははっきりしない。なぜか。

導入事例というものは、そもそも売り手が「これを買えばうまくいく」と思ってもらうために、選んで載せた成功例である。失敗した話は、まず載らない。丁寧な会社ほど事例を数多く並べるが、並んでいるのはすべて「うまくいった側」だ。うまくいかなかった会社が同じ数だけいたとしても、そちらは表に出てこない。

だから、事例をいくら読み込んでも、出てくるのは「その会社では成功した」という事実だけで、「自社でも成功するか」という答えではない。しかも、規模も、業種も、客層も、社内の体制も違えば、同じ道具を入れても結果は変わる。同業と聞いて安心しても、その会社が何人でどう使い、どこで苦労したのかまでは、事例には書かれていない。

つまり、他社の事例は「あの会社もやっているなら、大丈夫そうだ」という安心材料にはなる。だが、「うちがこれで困りごとを解決できるか」という判断材料にはならない。この二つを混同したまま近い事例を探し続けても、探しているもの——自社で解決するかの判断材料——は、構造として事例の側からは出てこない。ここが本当の原因である。

そうなると、やるべきは「もっと近い事例を探すこと」ではなくなる。

判断の起点を、他社の事例から自社の業務条件へ移す。事例が答えているのは「相手の条件で成功したか」だ。自社が本当に知りたいのは「自社の条件で成功するか」である。問いが違うのだから、いくら他社を見ても答えは出ない。見るべきは、他社ではなく自社の側にある。

自社の困りごとと、いまの業務の条件——誰がその作業をしていて、月に何件あり、どんな流れで、今どこで詰まっているのか——を書き出す。そのうえで、「うちの条件だと、これは効くのか」という目で道具や事例を見る。すると事例は、"当てはまるかを判断する対象"ではなく、"参考の一つ"という本来の位置に下がる。

自社の条件を先に持つ。事例を読むのは、そのあとだ。順番を入れ替えるだけで、事例に振り回される時間はぐっと減る。

自社の条件を先に立てる、といっても、その立て方は一つではない。現実に取れる道を、三つ並べる。手が届く道は、会社ごとに違う。

A案：AIを"要件整理の相手"にして、うちの条件リストを作る

事例や口コミの見え方に頼るのをやめ、自社の困りごとと業務の条件をAIに書き出させて整理させ、「うちが満たすべき条件」のリストを、自分の言葉で先に作ってしまう、という道がある。

これは「AIに"どの製品がいい？"と聞いて、おすすめを答えてもらう」という使い方とは違う。製品名を聞けば、返ってくるのは結局また"他社評価の寄せ集め"で、振り出しに戻る。そうではなく、AIを壁打ちの相手にする。自社の状況を話すと、AIが問いを返してくる。そのやり取りの中で、頭の中でぼんやりしていた困りごとを、箇条書きの「条件」に起こしていく。

手順にすると、こうなる。

• 「うちは◯人で、月に◯件の△△という作業をやっていて、今ここで手間取っている」とAIに話す。
• するとAIが「その作業は誰がやっていますか」「今のやり方で一番時間がかかるのはどこですか」「間違いが起きるのはどの場面ですか」と問い返してくる。
• そのやり取りを重ねるうちに、曖昧だった困りごとが「◯◯を半分の時間で」「誰が担当しても同じ結果に」といった、満たすべき条件の箇条書きになる。
• その条件リストを持って、初めて事例や製品を「うちの条件に効くか」という目で見る。

つまり、他人の成功例をなぞるのではなく、自社の中を言葉にする作業を、AIが相手になって進める。判断の軸を、他社の事例ではなく、自社の条件の側に作る、という考え方だ。

• 向く場面：事例を読んでも当てはまるか分からず、そもそも自社が何を満たしたいのかを、まだ言葉にできていない会社。
• 割に合わないこと：これで全部が片づくわけではない。AIは自社の業務の中身を知らないので、渡す情報が薄ければ条件リストも浅くなる。返ってくる問いも、こちらが渡した範囲の外までは出ない。出てきたリストが本当に的を射ているかの最終判断は、人がする。
• 始める前に要ること：今の業務で「どこで・誰が・どれだけ困っているか」を、断片でいいので話せる状態にしておくこと。整った資料は要らない。

※AIにはいろいろな種類・サービスがある。ここでは「特定の製品を入れる」話ではなく、「要件整理の相手をAIに任せる」という考え方を指している。どれが合うかは、会社の状況によって変わる。

B案：自社の業務条件を、紙に書き出してから事例を読む

AIを使わず、いまの業務の流れと困りごとを自分で紙に書き出し、その条件を手元に置いてから事例を読む。

• 向く場面：業務の流れが頭に入っていて、困りごとをある程度は自分の言葉にできる会社。
• 割に合わないこと：書き出す時間がかかるうえ、抜け漏れを自分で埋める必要がある。一人で書くと、視野が自分の思い込みの範囲に狭まりやすい。
• 始める前に要ること：現場の人に「実際に何に・どれだけ困っているか」を聞き取ること。経営者の頭の中だけで書かない。

C案：事例を"会社"ではなく"条件"で読み替える

事例をそのまま真似るのではなく、その会社が「どんな条件（規模・体制・使い方）でうまくいったのか」を読み取り、自社と重なる条件の部分だけを参考にする。

• 向く場面：手元にどうしても気になる事例があり、それを参考にしたい会社。
• 割に合わないこと：事例には前提条件まで書かれていないことが多く、読み取れる情報に限りがある。書かれていない失敗の要因までは分からない。
• 始める前に要ること：「この事例のどの条件が自社と同じで、どこが違うか」を並べて見る視点。同業というだけで同じ条件とみなさない。

続けられそうなところが、始めどきになる。事例を"卒業"して自社の条件を軸にする、という向きだけは、どの道も同じである。

まだ何も買わない段階でも、できることがある。

次に事例や口コミを見るとき、読みながら頭の中で一言当てる——「これは"うちで解決するか"の話か、"あの会社で成功した"話か」。成功した話だと分かったら、それは安心材料であって判断材料ではない、と仕分ける。それだけで、成功例に引っ張られる度合いが変わる。

あわせて、自社の困りごとを一行だけ書いてみる。「今、◯◯の作業で、△△に困っている」。たった一行でいい。これがあると、事例を"自社の条件"に照らして読む下地ができる。

ここでできるのは「事例に振り回されなくなる」ところまでだ。

「自社の条件を書き出そうにも、そもそも何を条件に挙げればいいのか分からない」「事例の会社と自社の違いが、どこまで結果に響くのか見当がつかない」「同じ業種でも導入実績がある、と営業に言われたとき、それをどこまで重く見ればいいのか決めきれない」——ここは、たいてい最後まで残る。ふだん動かしている業務ほど当たり前になりすぎて、いざ言葉にしようとすると手が止まる。

そういうときは、OSAKA AI-Center の窓口に相談するという選択肢がある。何かを買う必要はなく、こちらから売り込むこともない。「うちの場合、どこを条件にすればいいのか」——その整理を一緒に考えるところまでが、この辞典の役割である。

ITは、本来は専門家の領分でもある。弁護士や税理士のように、ITと経営の両方を知る第三者を"ブレイン"として側に置く——という考え方もある。何もかも自社だけで抱え込まなくていい。この辞典も、そうした相手と一緒に読めば、自社に合った次の一手につながりやすい。