人間からシステムに業務を移譲する3つのステップ
どうも、エンジニアのgamiです。
先日主催した勉強会で、某社のエンジニアさんからカスタマーサポートツールの内製開発についてお話を聞く機会がありました。曰く、toCサービスの大量の問い合わせに対して数十人規模のCSメンバーが効率的に対処するためには、自社サービスの仕様に最適化された専用システムが必要とのことでした。
今夜の #Customer系エンジニア座談会 は、メルカリ/ソウゾウさんとミクシィさんのCSやCREのお話を聞きました！
— gami@noteマガジン連載中 (@jumpei_ikegami) March 9, 2022
最初は
「CSツール内製とか必要なの？」
と懐疑的だったけど、話を聞けば聞くほど
「こりゃあ内製しないと無理だわ。すごい」
という感想しかなかった。すごい。
聞いていて面白かったのは、開発が間に合わない機能があるときはとりあえず「SQL実行機能でこのSQL実行して」と伝えることで対処している、という話でした。業務フローの変化をシステムに予め持たせておいた柔軟性によって吸収する。サービスの仕様変更や業務フローの最終理想形を正確に予見することが困難で開発リソースも有限である以上は、システム側に一定の柔軟性を持たせておくような戦略が価値を持ちます。
考えてみれば、ある業務を支える業務システムを1から構築する状況においても、システムの柔軟性にはグラデーションがあるべきです。最初からガチガチに用途や挙動が1つに決まったシステムを作るのではなく、徐々に柔軟性を落としていくようなアプローチの方が実態に即しています。
わかりやすい問題に落とせば、「最初から高いお金をかけて目の前の業務を楽にするオーダーメイドのシステムを作ったのに全然使い物にならない」という事態をどう避けるかという話でもあります。開発側の文脈で言えば、「なぜアジャイル開発が必要か」という話にも直結します。今回はこの問題を業務の側から考えてみたいと思います。
業務を遂行する方法はたくさんある
Customer Engineerとしていわゆる開発側とビジネス側の間で働いていると、「この業務の一部を自動化したいんだけど」みたいな相談をもらうことがあります。たとえば「ある条件に合致するユーザーだけに案内を出したい」みたいな話が来ます。そんなとき、僕の頭の中にはいくつかの選択肢が常にあります。
最もガチガチの選択肢は、「プロダクトの機能として組み込む」というものです。僕はSaaSプロダクトの開発や提供に関わっています。プロダクト自体の仕様を変えて「特定のユーザーにアラートを表示する」という機能を足すことは、開発チームを巻き込んでやればできます。要は専用の機能を独自に開発するというアプローチです。
逆に最も柔軟性の高い選択肢は、「全くシステム化せず人間がやる」というものです。コードを書いたりシステムを組んだりすれば、それだけで構築やメンテナンスにコストがかかります。どうやるのが最適かがわからない、そもそも本当に必要かわからない業務のためにいきなりシステムを作るよりは、「必要かわかんないのでまずは人力でメール通知送りましょう」みたいに判断することもあります。
これら両極端の道の間にも、選択肢はいくつかあります。大雑把に言えばそれは「既存のSaaSとか使って雑にシステム化する」というものです。僕は立場上この選択肢を取ることが最も多く、「専用の機能をプロダクトに組み込む前にとりあえずKARTEとかZapierとか使って自動通知の仕組みを作りましょう」みたいなことをよく言っています。
「この業務をなんとかしたい」という状況において取りうる手段はいくつかあります。もちろん、雑にSaaSと人力を組み合わせて一定期間業務フローを回した結果として、「これは専用の機能を開発した方がいい」という判断に至ることもあります。しかし、「雑に作ってみたけど実際そんなに使われなかった」という結果になることも多いという実感があります。
業務は徐々に型化され、システムの柔軟性は徐々に下がる
見てきたように、「ある業務が属人的に担われている状態」と「専用のシステムや機能を開発・利用する状態」との間には、業務フローとITシステムのそれぞれについて漸進的な変化があるはずです。
それぞれの変化をフェーズで整理した図がこちらです。
ここではカスタマーサポートの業務を例に、業務とシステムの両方の変化を見てみましょう。
まずは業務が各々のメンバーによって属人的に担われている状態があります。たとえば新規事業でカスタマーサポートを提供し始めるとき、その事業のカスタマーサポートをやったことがある人は世界で誰一人いません。初期のメンバーは日々のサポート業務を回す中で、より良いヒアリングや調査や回答の方法を模索していきます。当初はメンバーの頭の中だけに知見が貯まり、また複数いるメンバーそれぞれが独自のやり方で業務を遂行しています。
事業が拡大してその業務を担う新しいメンバーが入ってきたり、業務の負荷が大きくなってきたりしたタイミングで、「業務をもっと型化しよう」という流れがやってきます。カスタマーサポート業務でいえば、優れたサポート担当メンバーのやり方を誰でもわかるように明示的に言語化します。サポート問い合わせの発生から回答完了に至るまでのフローをフローチャートで整理し、チャート内の要素毎に定型文や対処方法をドキュメントにまとめていきます。
ドキュメントを見ながらヒトが定形業務を回していくうちに、「ここは自動化できる」とか「ここはチーム外のメンバーを巻き込む必要があり効率が悪い」といったことが見えてきます。サポート対応で毎回実施するヒアリング項目があれば、フォーム自体を開発して問い合わせ前にまとめて聞いてしまった方がいいかもしれません。毎回エンジニアに依頼していたユーザーのデータ抽出は、専用のクエリや機能を作ってサポート担当だけで完結できた方が効率が上がります。ここにきて初めて、「ITシステムで解決する」という選択肢の合理性が高まってきます。
ITシステム側の変化にもグラデーションがあります。カスタマーサポート業務を実現する最低限のシステムは、電話やメール問い合わせフォームを用意することです。しかし、ユーザー数やオペレーター数が増えていきサービスの機能が複雑化する中でサポート品質を担保し続けるには、電話やメールだけではすぐに足りなくなります。たとえば次のようなシステムや機能が欲しくなります。
・電話やメールの代替としてのサポート用チャットツール
・ユーザーの状況ややりとりの内容を記録するためのCRMツール
・ユーザー向けサポートドキュメントの管理
・ユーザーが自己解決できる割合を上げるためのFAQのレコメンド
・典型的な対応を自動化するチャットBot
・サービスの利用ログを検索するログビューワー
・サポートの品質を定量的にチェックするためのダッシュボード
・…
これらのシステムや機能は、最初から全て必要になるということはなく、徐々に追加され業務フローに組み込まれていくべきものです。また、各機能もいきなり内製やオーダーメイドでガチガチに開発するのではなく、「作ったら便利に使われるか？」を検証するためにSaaSを導入したり簡易なプロトタイプを作ってみたりします。まずは金銭的にも仕様的にも柔軟なシステムで業務を回してみてから、必要性に応じて徐々に柔軟性を落としたソリッドなシステムに作り変えていきます。
ちなみに「システムの柔軟性を落とす」と聞くと、「柔軟性は高い方がいいのではないか？」と違和感を覚える人もいるかもしれません。たとえばシステムに関して柔軟性が最も高い状態とは「システムが無い状態」です。業務システムを導入するということは、業務をそのシステムの仕様によって縛るということです。個々人のメンバーがその業務を実施するときの自由度はその分下がりますが、それだけ人間が考えることが減ったり、誰がやっても一定の品質が担保されたりするようになります。そして究極的には、人間が一切関与しなくても自動で一部の業務が回るようになります。
もちろん、システムの柔軟性が全く無い状態が常に理想形だというわけではありません。ある業務に対してシステムがどの程度の柔軟性を残しておくべきかについては、その業務の特性に依ります。たとえばチャットサポートツールが決まった定型文しか送信できないとすれば、それは楽ですがとてもチャットサポートの業務が遂行できるとは思えません。また、システムの価値を担保したまま柔軟性を下げるためには業務の型化が不可欠です。逆に言えば、高度な対人コミュニケーションや不確実な状況における意思決定など、型化することが本質的に難しいような業務をシステムに丸投げすることはできません。それこそが、まさに人間がやるべき業務と言えます。
システムに業務を徐々に移譲する
ITシステムの柔軟性を下げ特定業務に特化させていくこうした活動は、言い換えれば人間がITシステムに業務を徐々に移譲していくための活動です。
人間が人間に対して権限移譲をするとき、「この業務は渡すけどこっちはまだ渡せない」とか「意見は出してもらうけど最終決定はこっちでやる」みたいなグラデーションがあります。たとえば権限移譲をフレームワーク化したデリゲーションポーカーでは、権限移譲の段階を次の7つに整理しています。
1. 指示する ：管理者として意思決定を行う
2. 売り込む ：意思決定についての人々を納得させる
3. 相談する ：決定する前に、チームからの意見を得る
4. 同意する ：チームと一緒に決定を下す
5. アドバイスする ：チームによる意思決定に影響を及ぼす
6. 問い合わせる ：チームの決定後のフィードバックを求める
7. 移譲する ：特に影響を及ぼさずチームに任せる
システムに対して業務を任せていくときも同様に、「どの業務をどこまで任せるか」というグラデーションがあります。また、移譲すべき業務の範囲も日々変化していきます。
IT投資に関する世の中の言説を見ると、「ITシステムを導入する」というイベントが「不可逆で重要な大いなる断絶」であるような印象を受けることがあります。しかし実際には、業務フローを固める活動も、システムによる最適な支援を用意する活動も、ゆっくり漸進的に進むべきです。なぜなら、システムを使う側の人間が経験から学習を得るプロセスはゆっくり進むし、不確実な状況においては「やってみないとわからん」ということが多すぎるからです。にもかかわらず巨大システムをビッグバンリリースしてしまっては、無駄なコストが発生し社内は混乱するばかりです。
今回学んだことを、改めて3つのポイントにまとめました。
・システムを導入する前に、業務を型化して人間中心に回してみる
・いきなり独自開発するのではなく、既存SaaS導入から始める
・今の業務の不確実さや多様さに合わせて一定の柔軟性をシステムに残しておく
多くの業務は、人間が100%やるのもシステムが100%やるのも理想状態ではありません。実際には人間とシステムの最適な権限移譲配分がどこかにあり、人間100%の状態から徐々に業務をシステムに移譲していって、どこかでそれを止める必要があります。そのプロセスの中では、業務の進め方やシステムの構成を現場感をもって適切に変化させていくことになります。こうした活動は、コンサルやSIerに要件定義やシステム開発を丸投げしていてはとてもできない性質のものであるはずです。
というわけでみなさんも、目の前の業務が本来はどこまでシステムに移譲されるべきか、人間が介在する範囲はどこまでであるべきか、どんなステップで移譲を進めていけばいいのか、ぜひ具体的に考えてみてください！
ここから先は
仕事を楽しくするデジタルリテラシー読本
【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…
サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！