Larkや飛書の中でIT サービスデスクを運用する — 何が変わるのか

サービスデスクを従業員がすでに使っているチャットの中に置く——一見すると迷わず取るべき一手に見えます。しかし実際には、すべてのメッセージがカテゴリも担当者も計時もない生の依頼へと変わってしまいます。 Lark（飛書）の中で24時間365日対応のバイリンガル・サービスデスクを運用すること自体は可能ですが、それには届いたメッセージのすべてがその瞬間に、双方向で自動的にチケットへ変換される仕組みが前提になります。本稿では、チャットが受付チャネルになったときに何が変わるのか、そして「一次解決率」という数字がどんな条件のもとで初めて信頼できるのかを取り上げます。

会社全体がすでにLarkや飛書で動いているとき、何が起きるのか？

中国本土に本社を置く消費財ブランドを想像してください。香港オフィスは地域営業とコンプライアンスを担当し、より小規模なシンガポールオフィスは東南アジアの販売網を担当しています。どの部署もすでにLarkや飛書の中で動いています——経理には経理のグループチャット、物流には物流のグループチャットがあり、2年前に誰かが作った「IT相談」グループも、それ以来一度も整理されないまま存在しています。これは実在の顧客ではなく、説明のために組み合わせた複合シナリオです。

この会社にもチケットシステムはあります。しかし香港やシンガポールの社員は、ほとんど自分から開きません。Larkは一日中開きっぱなしなのに、ノートパソコンの不調を報告するためだけに別のシステムへログインし直すのは、パソコンが完全に動かなくなるまで誰もやらない一手間です。結果として、ITへの依頼はこの会社のあらゆる他の用件と同じ経路で届きます——チャットに投稿された一文と、前回返信してくれたエンジニア宛てのメンションです。

これは特定のベンダーが悪い、あるいは特定のIT担当者が怠けているという話ではありません。従業員が実際に使う受付チャネルと、IT側が実際に成果を測る仕組みが別物であるとき、既定でこうなるというだけのことです。その隙間にこそ、取りこぼされた依頼、見えなくなった作業量、そしてサービス品質をめぐる水掛け論が生まれます。

チャットが受付チャネルになると、実際に何が変わるのか？

受付をチャットアプリへ移すことは、「同じヘルプデスクの入口を変えただけ」では済みません。同時に3つのことが変わり、それぞれがサービスデスクの運営方法に波及します。

依頼件数が増えます。それまで依頼をふるいにかけていた摩擦が消えるからです。 チケットポータルにはログイン、フォーム入力、カテゴリ選択といったちょっとした摩擦があり、この摩擦のおかげで些細な困りごとの多くはそもそもチケットになりません。チャットのメッセージを送るコストはほぼゼロです。サービスデスクをチャットへ移すと問い合わせ件数は目に見えて増える傾向があり、ポータル時代の件数を前提に人員も運用も設計されたままだと、すぐに追いつかなくなります。

一次選別（トリアージ）のタイミングが前倒しになり、たまたまメッセージを最初に見た人の役目になります。 ポータルでは、誰かが対応する前にディスパッチャーが新規チケットをすべて確認します。グループチャットでは、最初にメッセージに気づいた人がそのまま返信することが多く、その人が本来の担当者かどうか、1時間前に別の誰かが同じスレッドですでに同じ問題を報告していないか、そもそも一次対応ではなくエスカレーションすべき案件ではないか、といったことは考慮されません。

依頼が届く時点で、フォームなら強制的に集めていたはずの背景情報が欠けています。 チケットフォームは提出前に、機種、場所、スクリーンショット、カテゴリを入力させます。チャットのメッセージは「またパソコンの調子がおかしいです」の一文だけで、しかもまったく別の話題の会話の中に4通目の返信として紛れ込んでいます。フォームなら最初に集まっていたはずの情報を、後から二度目のやり取りで聞き出す必要があり、それこそがチャット型サービスデスクが本来避けたかった行き来そのものです。

だからといって、受付をチャットに置くという発想自体が間違っているわけではありません。必要なのは、ポータルが自動的にやってくれていたことを、素のグループチャットでは自動的にやってくれない分だけ、チャット画面の下に補う仕組みです。

チャットの中でサービスデスクを運用するために、譲れない条件は何か？

チャットチャネルを実際に運用できるサービスデスクへと変えるには、4つのルールが必要です。どれか一つでも欠けると、サービスデスクはIT向けと名付けられただけの普通のグループチャットへ静かに退化します。

すべてのメッセージは、送信された瞬間に自動的に、必ず1件のチケットになる。 「価値があると思ったらエンジニアがチケットを作る」ではありません。質問、苦情、昨日と同じ問題の繰り返し——届いたすべての依頼は、人が読む前にチケット番号を割り当てられます。この一点こそが、依頼が会話の中に静かに吸収され、話題が移ったところで忘れ去られることを防ぎます。

実際のユーザーに使われても崩れないカテゴリ分類。社内の検討会では完璧に見えたものではなく。 ユーザーは自分の問題を正確に分類できませんし、そうする必要もありません。ハードウェア、アカウント権限、アプリケーション、ネットワーク、入退社対応、「その他」など、実際の依頼パターンから逆算した短いカテゴリ一覧を用意し、依頼者本人に理解できないメニューから選ばせるのではなく、最初の人によるトリアージか自動処理のどちらかに割り当てさせます。

SLAの計時は、メッセージが届いた瞬間から始まる。誰かに「引き受けられた」瞬間からではない。 これは多くのサービスデスクが気づかないうちに間違えるルールです。チケットが「受理」または「割り当て」された時点で初めて計時が始まるなら、忙しいグループチャットの中でメッセージが未読のまま過ぎていく時間はいっさい計測されません。つまり、SLAレポートは立派な数字を示しながら、Larkのチャネルには何時間も放置された未回答のメッセージが積み上がっているという事態が起こり得ます。計時はメッセージ受信の瞬間から、例外なく始める必要があります。

スレッドが流れ去った後にも残る、書面の記録がある。 チャットは本質的に一過性です。3週間前のプリンターについての会話は、今ごろ2000件のメッセージの下に埋もれています。すべてのチケットには、何を依頼されたか、何をしたか、誰が対応したか、いつ完了したかを記した、それ自体で独立した記録が必要です。その記録があるからこそ、半年後の月次レポートも、監査も、「これ前にも直したはずでは」という会話も成立します。

チャットネイティブ受付・チケットポータル優先・ハイブリッド：実際にどう比較するか

• チャットネイティブ受付（メッセージが自動でチケットになる）： 従業員がすでに慣れた働き方にそのまま合致するため、依頼はもれなく捕捉され、「ポータルにログインするのが面倒だった」という理由で消える依頼がありません。自動変換の仕組みがなければチャットは誰もレポートに使えない混沌へ崩れるというのがリスクであり、機能させているのはチャネルそのものではなく背後の仕組みです。
• チケットポータル優先（依頼のために別システムを開く必要がある）： カテゴリと優先度が最初から整理された、きれいな構造の対応キューをIT側に与えますが、実際の依頼のかなりの割合がそこまで届きません。「パソコンがまったく起動しない」レベルでない限り、別システムへのログインという摩擦を、多くの従業員は避けてしまうからです。
• ハイブリッド（報告はチャット、追跡はポータル、両者を自動同期）： Larkネイティブな組織に実際に合うのはこのモデルです。従業員はいつもどおりの方法で報告でき、ITは構造化されレポート可能なキューを保持でき、二重入力なしに両者が同期し続けます。正しく構築するコストは他の2つのモデルより高くつきますが、依頼件数が増えても持ちこたえられるのはこのモデルだけです。

3つの独立チームを持たずに、バイリンガルでどう振り分けるか？

シナリオの会社は、日々3つの書き言葉のレジスターで動いています。本社からは簡体字中国語、香港からは繁体字中国語と英語、シンガポールからは英語です。1つの言語でしか回答できないサービスデスクは、依頼者に自分の問題を自分で翻訳させるか、すべての依頼を単一のバイリンガル担当者へ集中させるかのどちらかを迫られ、後者はやがてサービスデスク全体のなかで最も遅いボトルネックへと静かに変わっていきます。

現実的な答えは、言語ごとに3つの独立したデスクを作ることではありません。それではこの会社がひとつのチャットプラットフォームへ統一することで避けようとしていた分断を、そのまま再現してしまいます。答えは、繁体字中国語・簡体字中国語・英語のいずれにもネイティブ水準で対応できる一次対応チームを、同じシフトの中に配置することです。そのうえで、返信は依頼が届いた言語で行うという固定ルールを設けます。その時間帯の当番エンジニアがたまたま得意な言語で返すのではありません。Brocentの24時間365日多言語ヘルプデスクは、まさにこの要件を軸に組み立てられており、広東語・標準中国語・英語の対応を1人のバイリンガルエンジニアが3つのタイムゾーンを一人で抱えるのではなく、同じシフト体制の中でカバーしています。

カテゴリ分類も言語に依存しない設計にする必要があります。「アカウント権限」という依頼は、本社から簡体字中国語で届いたものでも、シンガポールから英語で届いたものでも、同じように分類されるべきです。そうしてはじめて、月次のカテゴリ別件数を確認する管理者は、手作業で突き合わせる必要のある3つの断片ではなく、1つの実態を見ることができます。設計段階ではなく、実際にプロバイダーの多言語対応をどう検証するかという段階にいるなら、香港向け多言語ITヘルプデスクの検証チェックリストで契約前に確認すべき点を扱っていますので、本稿では繰り返しません。

現実的な一次解決率とは、実際にはどのようなものか？

90%以上の一次解決率は、実在のある問い合わせで挙げられた具体的な目標であり、真剣に検討する価値があります。ただしそれは、サービスデスクをその数字に合わせて設計するための目標であって、どんなチャットツールにも無条件でついてくる勲章ではありません。実現可能かどうか、あるいはスライドの上だけの数字に終わるかは、3つの問いで決まります。

「一次対応」とは何を指すのか、そしてそれはチケットが実際に完了した経緯と一致しているか。 エンジニアが調べ物をし、同じチャットスレッドの中でユーザーを操作案内し、他に転送せずにチケットを完了させたなら、それは正真正銘の一次解決です。チケットが2日間開いたまま、その裏では別の非公開チャットで3人が相談してからようやく返信が来た、というケースを一次解決として数えるのは、運用上の事実ではなく集計方法上の選択にすぎません。測定は、クローズ時のメモがどう書かれているかではなく、チケット記録に実際に起きたことを追う必要があります。

カテゴリ分類とナレッジベースは、実際に来る依頼の構成と本当に合っているか。 パスワードリセット、共有ドライブの権限、印刷キュー、既知のアプリケーションエラーは、繰り返し発生し文書化された問題なので、一次対応チームが素早く解決できます。まったく新しいハードウェア障害やベンダー側の障害は、決して一次解決にはなり得ません。そうした依頼の構成比を織り込まない目標は、正当な理由で未達になるか、あるいは難しい案件をこっそり別分類へ振り替えることで「達成」されるかのどちらかになります。

一次対応チームの人員配置は、実際の依頼構成に合わせたものか、それとも件数が増えるたびに他業務から借り出されているだけか。 90%以上という目標は、依頼が実際に届く時間帯に、必要な言語を話せる訓練済みの人員が一次対応シフトに十分いることを前提としています。同じ2人のバイリンガルエンジニアが二次対応のエスカレーションにも駆り出されているなら、この数字はその週たまたま誰が手すきだったかによって上下するだけで、計画の立てようがありません。

これは目標そのものが非現実的だという話ではありません。この数字はまずツール選定の問題である前に人員配置とカテゴリ設計の問題であり、真面目な計画であれば、前提条件を明示するはずで、単一の数字を初日から保証されたものとして提示することはない、ということです。

チャットが受付チャネルになったとき、「24時間365日」は実際に何を意味するのか？

「24時間365日」という言葉の裏には、まったく性質の異なる2つのものがあり、本社の一日の終わりに合わせて香港時間の深夜2時に依頼が届き得るようになると、その違いはより重要になります。

フォロー・ザ・サン方式は、地球の自転に合わせて有人の地域チームの間でサービスデスクを引き継いでいく仕組みで、常にどこかに実際に稼働しているフルスタッフのシフトがあります。オンコール方式は、時間外の小規模なチームが連絡可能な状態にはあるものの常時稼働ではなく、呼び出しを受けて対応する仕組みで、チャネルをリアルタイムで見張っているわけではありません。フォロー・ザ・サンは安定していながら予測しにくい依頼量にうまく対応できますが、オンコールは本物の緊急事態のために設計されたもので、日常的なチャットのやり取りのためのものではありません。夜間にオンコールしか用意されていないチャットチャネルは、翌朝には未回答のメッセージが静かに積み上がっており、それはまさにこの仕組み全体が解決しようとしていた問題そのものに見えてしまいます。フォロー・ザ・サンの引き継ぎとSLA階層について詳しくは、アジアの24時間365日多言語サービスデスクガイドで取り上げていますので、本稿では引き継ぎの場がポータルからチャットへ移ったことで何が変わるかだけを扱います。

どちらのモデルを選ぶかは、実質的には稼働時間帯の選択に見せかけた人員配置の判断です。フォロー・ザ・サンのシフトを組むには、各地域に訓練を受けたバイリンガル人材を十分な数配置し、「名目上は当番だが実際は別の仕事をしている」状態ではなく本当に稼働しているシフトを確保する必要があり、夜間の依頼量が安定している会社ほど、その投資が報われます。オンコール方式は配置コストが低い一方で、深夜の未読メッセージに最低限何を返すかを明確に決めておくべきです。最低限、チケットが生成された時点でチャットスレッド内に自動確認メッセージを返し、香港時間の深夜2時にメッセージを送った人が、自分の依頼がすでにチケットになったことを、実質的な回答が次の稼働シフトまで待つとしても、その場で知ることができるようにします。

本土に本社を置き、香港とシンガポールで事業を展開する組織にとって本当に問うべきなのは、抽象的に「24時間365日対応が必要か」ではありません。どのインシデントが24時間を通じて人が張り付くリアルタイム対応に本当に値し、どのインシデントなら明確な受領確認を返したうえで次の稼働シフトまで待てるのか、という点です。チャット型のサービスデスクは、メッセージを受領確認ゼロのまま放置してはなりません。ただし受領確認は、一次対応を実際に始めることと同じ約束ではなく、両者には異なる人員配置が必要です。

これは「そもそも24時間365日対応が必要か」という問いとは別の話で、それぞれに固有のトレードオフがあります。ここでは、シナリオの会社のチャットチャネルがそもそも実質的に閉じることがない以上、答えはイエスだと仮定しています。まだ決まっていないのは、その24時間のうちどの時間帯に人が実際に稼働してリアルタイムで返信する必要があり、どの時間帯なら確認だけで足りるか、という点です。

チャットのメッセージが返信ではなく現場派遣に変わるべきタイミングはいつか？

一部の依頼は、サービスデスクの運用がどれほど優れていても、チャットスレッドの中では解決できません。故障したスイッチ、断線した配線、物理的なハードウェアの交換などです。ここで譲れないのは、現場訪問へのエスカレーションが、同じチケット記録の中で明確に見える1つのステップとして行われるべきだということです。別の会話を、別の担当者と、最初からやり直すのではありません。カテゴリ、履歴、SLAの計時はチケットとともに現場派遣の工程へ引き継がれ、作業がチャット画面から技術者の車へ移ったからといってリセットされることはありません。Brocentが公開している現場派遣のSLA階層——通常営業時間、延長営業時間、24時間365日緊急対応それぞれでの応答時間と現場到着時間——は、まさにこの引き継ぎに双方合意の計時を紐づけるために存在しており、「そのうち誰かが伺います」という際限のない約束ではありません。

チャットスレッドの中で扱ってはいけないことは何か？

チャットの強みはスピードですが、だからこそ意図的にチャットの外に置くべき依頼のカテゴリがあります。権限承認——新しいシステム権限の付与、退職者アカウントの復旧、セキュリティポリシーの例外承認——には、名前の残る監査可能な承認経路が必要であり、流れて消えていくグループチャットの「いいね」スタンプでは足りません。誰かがすでに持っている権限の使い方を助けるのではなく、誰がどのシステムにアクセスできるかを変える依頼はすべて、チャット履歴よりも長く残る記録を持つワークフローに委ねるべきです。チャットネイティブなサービスデスクは、こうした依頼を認識した瞬間に正式な承認プロセスへ振り向けるべきであり、たまたまチャットから届いたからといって、そのスレッドの中で解決しようとするべきではありません。

これはより大きなマネージドITプランの中でどう位置づけられるのか？

チャット型サービスデスクは、単独の製品ではなく、より広い支援関係の一部です。それは監視、パッチ適用、チャットでのやり取りが現場対応へとエスカレーションしたときの派遣といったマネージドサービスの基盤の上に成り立っており、チャット型かどうかにかかわらず、信頼できるヘルプデスクであれば当然備えるべき同じレポートの規律——カテゴリ別の月次件数、応答時間と解決時間、そして何を測定しているのかが明確な一次解決率——にも従います。Brocentのユーザー単位マネージドITプランはユーザー数×月単位で課金され、香港の料金は1〜5名向けのスタータープランで月額HK$855.14から始まり、人数と対象範囲が増えるにつれてHK$1,247.40、HK$1,561.21へと段階的に上がっていきます。詳細は料金ページをご覧ください。Larkや飛書を業務基盤とし、香港とシンガポールにオフィスを持つ組織にとって、チャットネイティブなサービスデスクが本当に合うかどうかを検討されている場合は、担当チームまでお問い合わせください。御社の依頼量に合わせて、カテゴリ設計、人員配置、SLA設計を具体的にお話しします。

よくある質問

Larkや飛書は本当にチケットシステムの代わりになりますか？

それだけでは代わりになりません。Larkや飛書は、それらが本来目指す役割——迅速でネイティブなコミュニケーション——には非常に優れていますが、チャットアプリ自体にはチケット、SLAの計時、カテゴリ、あるいはクローズ後も残る記録という概念がありません。チケットシステムの代わりを果たすのは、受付チャネルとしてのチャットアプリと、届いたメッセージをその瞬間に構造化されたチケットへ変換する自動化の層、この2つの組み合わせです。この層がなければ、手元に残るのは非常に速いだけで構造を持たないグループチャットです。

忙しいグループチャットの中で依頼が取りこぼされないようにするにはどうすればよいですか？

「取りこぼす」という選択肢そのものをなくすことです。届いたすべてのメッセージは、誰かがトリアージする前に自動的にチケット番号を割り当てられ、流れていくスレッドの中で誰かが気づくかどうかに依存しません。これに加えて、明確な解決メモがない限りチケットをクローズできないというルールと、チケットを生成しなかったメッセージがないかを毎日確認する仕組みを組み合わせます。そうしたメッセージが見つかる場合、たいていは自動取り込みが特定のチャネルやメッセージ形式を見落としているということなので、毎日手作業で拾うのではなく、根本原因を修正すべきです。

このようなサービスデスクにとって、現実的な一次解決率はどれくらいですか？

依頼の構成と、「一次対応」がどう定義されているかによって完全に変わります。パスワードリセット、権限申請、既知のアプリケーションエラーなど、繰り返し発生し文書化された問題を中心に扱い、訓練を受けたバイリンガルの一次対応要員が十分に配置されているサービスデスクであれば、90%以上を含む高い目標を現実的に設定できます。同じ目標を、未知のハードウェア障害やベンダー依存の問題が多い依頼構成に当てはめたり、複数日・複数人が関わったチケットも「一次解決」として数えられる定義で測定したりすれば、それは目標ではなく、スライドの見栄えのために選ばれた数字にすぎません。

3つの独立チームを持たずに、3つの書き言葉にどう対応しますか？

御社が使う3つのレジスターすべてにネイティブ水準で対応できる一次対応シフトを1つ用意し、依頼が届いた言語で返信するという固定ルールを設けます。その下に言語に依存しないカテゴリ分類を敷けば、レポートも言語によって断片化しません。月次のチケット件数を確認する管理者が見るべきは、手作業で突き合わせる必要のある3つの断片ではなく、1つの分類済みの実態です。

チャット型サービスデスクは、24時間365日対応に実際に対応できますか？

はい、ただし自分たちがどちらのモデルを運用しているかを明確に意識している場合に限ります。フォロー・ザ・サン方式——常にどこかに稼働中のシフトがある状態——は、夜間の安定したチャット量に確実に対応できます。オンコール方式——小規模なチームがチャネルを見張るのではなく呼び出しを受けて対応する仕組み——は緊急事態のために設計されており、日常的なやり取りのためのものではないため、フォロー・ザ・サンの役割を求めると、夜間に未回答のチャットメッセージが静かに積み上がっていきます。

チャットよりメールを好む社員がいる場合はどうすればよいですか？

適切に設計された受付の層は、メールを別の受付チャネルとして同じチケットの流れに合流させるべきであり、全員をチャットに一本化する必要はありません。カテゴリ分類、SLAの計時、記録保存のルールはどちらのチャネルでも同じであるべきです。依頼がどのチャネルから届いたかによって、測定や報告のされ方が変わるべきではなく、変わるのは依頼者が依頼を送る際の体験だけです。

チャット型サービスデスクは実際にどのように監査されるのですか？

どのサービスデスクとも同じ方法です。チャットの履歴そのものではなく、各メッセージが生成する残存性のあるチケット記録によってです。作成時刻、カテゴリ、一次解決かエスカレーションかの別、クローズメモを含む月次エクスポートがあれば、管理者や外部のレビュアーは独立して件数と解決率を再計算できます。これは、SLAレポートを単に信用するのではなく検証可能にするのと同じ規律です。

会社がLarkや飛書ではなくMicrosoft TeamsやSlackを使っている場合はどうなりますか？

ここで説明している運用モデルは、会社がどのチャットプラットフォームに統一しているかに依存しません。メッセージの自動チケット化、実際のユーザーに使われても崩れないカテゴリ分類、メッセージ受信の瞬間から始まるSLAの計時、チャットスレッドの外に残る記録——これらの譲れない条件は、受付チャネルがLark、飛書、Teams、Slackのいずれであっても同じように当てはまります。プラットフォームによって変わるのは、メッセージを自動的に取り込むために必要な連携作業であり、サービスデスクそのものの設計ではありません。