「便利なのは分かる。でも、うちの社員に使えるかな」。システムを導入するとき、こんな不安を感じる経営者の方もいると思います。社員の年齢が高い。パソコンに慣れていない。新しい操作を覚える時間がない。今のやり方を変えることに、不安がある。
機能がそろっていても、使う人が困ってしまったら、仕事は楽になりません。結局、詳しい人に操作を頼んだり、紙に書いてから誰かが入力し直したりする。それでは、せっかく作ったシステムの良さを十分に生かせない。
僕は、この問題に対して、システムの作り方そのものを変えられると思っています。いつもの操作画面に加えて、話しかけて仕事を頼める入口を作る。普段、同僚にお願いするような言葉で伝えると、必要な情報を探して、処理を進めてくれる。
01予約を一つ変えるために、いくつ操作していますか
例えば、電話で予約の変更を受けたとします。お客様の名前を検索する。予約一覧を開く。該当する予約を見つける。編集画面へ進む。空いている日時を確認する。日付を変えて保存する。
慣れている人なら難しくないかもしれません。でも、たまにしか操作しない人にとっては、「最初にどこを押すんだっけ」から始まります。画面を開けても、「これを押したら予約が消えないかな」と迷うこともある。
本人がやりたいことは、予約を一つ変更するだけです。そのために、システム側で決められた手順を覚えなければならない。ここを、会話で進められるようにします。例えば、次のような利用場面です。
画面には、変更前と変更後の予約が並んで表示される。社員が覚えるのは、編集画面を開く手順ではなく、「予約を変えたいと伝えればいい」ということです。
同じ名字のお客様が複数いたら、システムから聞き返す。指定された時間が埋まっていたら、空いている候補を出す。足りない情報だけを、その場で確認する。人に頼むときと同じように、会話しながら必要なことが決まっていく。こういう体験を、業務に合わせて設計できます。
02「使い方を教える」負担まで減らしたい
システムを導入すると、操作説明の時間が必要になります。マニュアルを作り、研修を行い、分からないことが出たら質問してもらう。担当者が変われば、また最初から教えることになります。
もちろん、仕事のルールを知ることは必要です。予約を変更してよい条件や、誰の確認が必要かまで、知らなくてよくなるわけではありません。ただ、「このメニューを開いて、次にこのボタンを押す」という操作の説明は減らせるはずです。
「今週の予約を見たい」と伝えたら一覧が出る。「まだ返事をしていない問い合わせは？」と聞いたら対象が表示される。「このお客様との前回のやり取りを教えて」と頼んだら、記録を探してくれる。
年齢だけで得意不得意が決まるわけではありません。若くてもパソコンが苦手な人はいるし、年齢が高くても使いこなす人はいます。年齢で使い方を決めつけず、その人が無理なく使える入口を選べることが大切だと思っています。
03文字を打つのが大変なら、話せばいい
会話で使えるといっても、長い文章をキーボードで入力しなければならないなら、それが負担になる人もいます。そこで、音声で頼めるようにする。大きな「話して頼む」ボタンを押して、「明日の予約を見せて」と話す。すると、明日の予定が表示される。
文字入力に慣れている人は、チャットで頼めばいい。人前で話しづらい場所なら、よく使う仕事のボタンを押して始めてもいい。
空っぽのチャット画面に「何でも聞いてください」と書くだけでは、人によっては困ってしまう。「何ができるの？」「どんな言い方をすればいいの？」という疑問が残るからです。会話で使えるシステムを作るなら、会話を始めるところまで分かりやすくしたい。
聞き取りが違っていたときも、簡単に直せるようにする。説明が長すぎないようにする。文字の大きさやボタンの押しやすさも、その現場に合わせる。AIを付ければ、それだけで使いやすくなるわけではありません。使う人の立場で、一つずつ設計する必要があります。
04会話の先で、実際の仕事が進む
「予約変更の方法を教えて」と聞いたら、操作手順を説明してくれる。それも便利ですが、説明を読んだあとに自分で操作する作業は残ります。僕たちが目指しているのは、依頼を受けて、実際の処理まで進められることです。
予約を変更する。顧客の記録を探す。報告内容を保存する。見積書の下書きを作る。対応が止まっている案件をまとめる。そのために、AIとシステムの機能をつなぎます。MCPという共通規格やAPIは、こうした連携を作るための手段です。
MCPは、AIから外部の機能やデータを呼び出すための共通の接続方法です。音声を聞き取ったり依頼を理解したりする仕組みと組み合わせて使います。接続すれば何でもできるわけではなく、予約変更なら予約を変更する機能と、それを使う権限が必要になります。
使う人が技術の名前を覚える必要はありません。大事なのは、「頼んだことが進んだか」「結果が合っているか」「間違っていたら直せるか」です。
例えば見積書なら、できあがった内容を画面で確認できる。金額を変えたければ、「この項目を二つにして」と伝えられる。送付まで対応する設計なら、宛先と内容を確認してから送れるようにする。
見る・探す・集計するたびに細かい確認を求められたら、かえって面倒です。一方、予約を変えただけなのに、お客様への連絡まで勝手に送られたら困る。どこまで自動で進め、どこで確認するかも、業務ごとに決めておきます。
05いつもの画面も、使えるままでいい
すべての操作を会話にする必要はありません。一日の予定をまとめて確認したいときは、カレンダーを見たほうが早い。複数の見積もりを比べるなら、表に並んでいたほうが分かりやすい。慣れた担当者なら、いつもの画面でまとめて入力したいこともあるでしょう。
だから、通常の操作画面と、会話で頼める入口の両方を用意する。同じ予約を、ある人はカレンダーから変更する。別の人は、話しかけて変更する。どちらから操作しても、同じ情報が更新される。
途中で切り替えてもいいんです。「来週の空きを見せて」と話して、出てきたカレンダーから希望の時間を押す。「今月の売上をまとめて」と頼み、表示された表を見ながら詳しいところを確認する。
頼むところは会話で、見るところは見やすい画面で。使う人や作業の内容に合わせて選べるほうが、無理がありません。
06作る前に聞きたいのは、普段どう頼んでいるか
このようなシステムを作るには、機能の一覧を聞くだけでは足りません。普段、社員同士でどう仕事を頼んでいるのか。何を聞き返しているのか。どんなときに判断に迷うのか。そこを知る必要があります。
「いつもの内容でお願い」と言われたとき、何を見て「いつもの」を判断するのか。「田中さん」と言われたとき、同じ名字のお客様をどう見分けるのか。「急ぎで対応して」と言われたとき、何を優先し、誰に知らせるのか。
人同士では自然に補っていることでも、システムを作ろうとすると、決めておくべきことが見えてきます。ここで必要なのが、業務を構造化する力です。誰が、どの情報を使い、何を判断して、次に何をするのか。それを整理して、処理できる形にする。
画面と会話で別々のルールが動くと、使うたびに結果が違ってしまいます。どちらの入口からでも、同じ業務処理と権限の確認が働くように作る。使う側には見えないところですが、安心して使い続けてもらうために必要な設計です。
07まずは、よく頼まれる仕事から変えていく
最初から、会社のすべての業務を会話で完結させようとする必要はありません。例えば、毎日何度も行う予約の確認と変更。社員から頻繁に聞かれる情報の検索。日々の作業報告の登録。使う機会が多く、困っていることがはっきりしている仕事から始める。
実際に使ってもらうと、開発する側が想定していなかった言い方が出てきます。説明が伝わらない場面や、聞き返しが多すぎる場面も見つかるでしょう。そこを直して、「これなら使える」と思ってもらえる範囲を広げていく。
導入したかどうかだけでなく、誰かに操作を頼む回数が減ったか。仕事が終わるまでの時間が短くなったか。間違いがあっても自分で直せるか。そこまで見たいと思っています。
08「うちの社員には難しいかも」に、作り方で応えたい
これからの受託開発では、依頼された機能を作ることに加えて、その機能を現場の人がどう使うかまで、もっと踏み込めるはずです。パソコンが苦手なら話して頼めるようにする。何を頼めばいいか迷うなら、よく使う仕事を選べるようにする。結果が分かりにくければ、表やカードで見せる。
イケメンでは、通常の操作画面に加え、会話で依頼し、必要な確認をしながら、実際の業務処理まで進められるシステムを、業務に合わせて開発できます。必要な機能や判断の条件を整理して、任せられる範囲をきちんと作っていきます。
「社員の年齢が高いから」「新しい操作を覚えるのが苦手だから」「教える人の負担が増えそうだから」。そうした理由で、便利にできる仕事まで諦めなくていい。
「使いこなせる人がいるか」を心配する前に、その人たちが使える形を一緒に考える。それが、僕たちの目指す、次世代の受託開発です。
