AIは辞めない。でも、本当に残したいのはAIではない
人が辞めても、顧客に役立った経験は残せるか
ある担当者が現場を離れると決まったとき、引き継ぎ資料には何を書くべきでしょうか。
担当業務、利用しているシステム、作業の手順、関係者の連絡先。もちろん、どれも必要です。しかし、それだけを渡しても、新しい担当者が同じように仕事を進められるとは限りません。
たとえば、問い合わせが来たとき、すぐに回答してよいものと、先に利用部門へ確認すべきものがある。障害が起きたとき、手順どおりに切り分ける前に、過去に同じ事象が起きていないかを確認した方が早い場合がある。見積もりを出す際も、仕様書に書かれた作業だけを数えるのではなく、過去にどこで手戻りが出たか、誰との調整に時間がかかったかを見て、工数を置く必要がある。
こうしたことは、資料の末尾に「注意事項」として数行書けば済む話ではありません。
顧客が何を気にする会社なのか。どの部門との話が止まりやすいのか。過去にどんな説明が誤解を生んだのか。障害の影響を技術面だけでなく、業務の締め日や利用者の動きまで含めて考える必要があるのか。その人が数年かけて覚えたことは、作業そのものより、その周辺にあります。
人が辞めることを、会社だけで止めることはできません。
転職、異動、定年、家庭の事情、本人が次に挑戦したい仕事。理由はさまざまですし、本人が会社を離れることを失敗として扱うべきでもありません。問題になるのは、その人が抜けたあと、顧客に役立っていた経験まで一緒に失われることです。
ディーシステムが考えたいのは、退職をなくす方法ではありません。
一人の担当者が顧客の現場で得た経験を、次の担当者、別の顧客、別の提案へどう渡すか。そのために、何を残せるのか。逆に、何は残しきれないのか。そこに、ITサービス会社としての仕事があると考えています。
手順書に残るもの、残らないもの
手順書は、仕事を再現するために欠かせません。
誰が見ても同じ作業ができるようにする。必要な入力項目を漏らさない。承認の順番を間違えない。障害発生時の連絡先を確認できるようにする。日常の運用を安定させるうえで、文書化は土台になります。
ただ、手順書は基本的に、「決まっている仕事」を扱うものです。
現場で難しいのは、決まっていない仕事が出てきたときです。
利用部門から、前例のない依頼が来る。業務上は急ぎだが、システムを急いで変えると別の部門に影響が出る。障害の原因はまだ分からないが、翌朝の処理に間に合わなければ現場が止まる。担当者は、情報がそろわない状態で、誰に連絡し、どこまで説明し、何を先に確かめるかを決めなければなりません。
その判断には、技術知識だけでは足りません。
過去に似た事象があったか。顧客は過去にどの説明で不安を感じたか。その案件では、どの責任者に早めに知らせるべきか。調査を急ぐほど、確認を飛ばしてはいけない部分はどこか。手順書に書かれていないことを、本人が勝手に判断しているように見える場合もあります。
しかし実際には、その人が過去に失敗し、確認し、顧客から指摘され、少しずつ覚えてきた順番です。
経験者が抜けたときに困るのは、作業者が一人減るからだけではありません。新しい担当者が、毎回ゼロから「何を確認すべきか」を探すことになるからです。
回答に時間がかかる。確認する相手が増える。過去に避けていた失敗をまた踏む。顧客から見ると、担当者が変わるたびに説明の質が変わり、同じことを何度も話すことになる。
そこで失われるのは、単なる工数ではありません。顧客との関係の中で、少しずつ積み上がった信頼です。
現場だけの問題ではない
経験が一人の中に残ったまま離職や異動が起きると、困るのは現場だけではありません。
営業は、顧客に何を提案できるかを考えるとき、過去にどんな改善が受け入れられたか、どの領域で相談が増えているかを十分に把握できなくなります。現場の担当者が持っていた「この顧客なら、次はここに困るかもしれない」という見立てが、営業へ渡らないまま終わることもあります。
管理職は、誰に何を任せられるかを見極めにくくなります。ある人ができる仕事を、単にスキルシートの単語で判断すると、「SAP経験あり」「運用経験あり」といった情報しか残りません。しかし、実際に任せられる範囲はもっと細かいものです。
利用部門との調整までできるのか。障害時に優先順位をつけられるのか。後輩に説明しながら進められるのか。顧客の業務を理解したうえで、仕様の違和感に気づけるのか。
採用でも同じことが起きます。
経験者を採用したとしても、その人が以前の職場で得た経験を、すぐに自社や顧客の仕事へ移せるとは限りません。業務の前提、関係者、契約範囲、責任の持ち方が変われば、同じ技術でも求められる判断は変わります。
だから、経験者を採れば解決するという話でもありません。
その人が持つ経験を、今の顧客の課題とどう結びつけるか。本人だけに任せず、周囲がどこまで理解し、次の仕事に活かせる形にするか。そこまで考えなければ、経験は会社の中を通り過ぎるだけになります。
退職予定だったSAP有識者を、別の顧客の運用へつないだとき
ディーシステムでは、SAP／ERP領域で長く経験を積んできた方を受け入れ、別の顧客の運用体制へつないだことがあります。
その方は、定年後も専門性を活かして働き続けたいという意向を持っていました。一方で、これまでの環境では、処遇や働き方が変わることで、これまでどおり経験を使い続けることが難しくなる可能性がありました。
SAPの運用では、機能や設定を知っているだけでは足りない場面があります。
ある業務の変更を受けるとき、どの部門にどんな影響が出るか。障害が起きた際、どこまでを運用チームで切り分け、どの時点で開発や業務部門へ上げるべきか。以前の対応で何が問題になり、次はどこを先に確認すべきか。長く一つの現場にいた人ほど、こうした判断の背景を多く持っています。
その経験が、そのまま失われることを避けるために、ディーシステムは契約社員として受け入れ、社内のSAP有識者と組み合わせる形を取りました。
同じ時期、別の顧客ではSAP運用の体制を見直す動きがありました。既存の運用に課題があり、ただ要員を補うだけではなく、現場の状況を把握しながら立て直せる人材が求められていました。
そこで、長年の経験を持つその方の知見を、新しい運用の立ち上げへつなげました。
ここで必要だったのは、「経験者を紹介すること」だけではありません。
新しい顧客の業務や運用ルールを理解する時間が必要でした。前の現場で通用していたやり方を、そのまま持ち込めるとは限りません。既存メンバーとの役割分担も決めなければならない。顧客側が何に困っていて、どこまでを早く変えたいと考えているのかを確認しなければ、経験は単なる経歴の長さで終わります。
そのため、経験者本人の力だけに頼らず、ディーシステム側のSAP有識者と連携する体制をつくりました。
新しい顧客の運用で何が起きているかを見ながら、どこに過去の経験が使えるかを探す。逆に、前の現場の前提が通用しないところは、早めに修正する。本人の知識を借りながら、顧客ごとの運用に合わせた判断を積み上げる。
結果として、その方は専門性を活かし続ける場を得ました。顧客側も、運用を見直す局面で経験のある人材を迎えることができました。ディーシステムにとっても、採用と案件獲得を別々に考えるのではなく、一人の専門人材が持つ経験を、顧客の課題へつなぐ機会になりました。
ただし、この出来事を「経験があれば、どこでも活かせる」という成功談にはしたくありません。
経験は、持っているだけでは移りません。
本人がどんな判断をしてきたかを聞く。新しい顧客の前提を理解する。周囲がその判断を受け取り、別の人でも使える形にしていく。その時間を取らなければ、経験者が一人増えても、また新しい属人化をつくるだけです。
残せる経験と、残しきれない経験
会社は、人の経験をすべて残すことはできません。
顧客との長年の関係の中で生まれた信頼。会話の間合い。相手が言葉にしない懸念を察する感覚。判断の速さ。こうしたものは、録音や議事録、日報だけで移せるものではありません。
「この人なら安心して任せられる」と顧客が感じていた理由を、完全に引き継ぐことは難しいでしょう。
一方で、残せるものもあります。
どんな場面で判断に迷ったか。どの情報が不足すると作業が止まったか。誰に確認すると話が進んだか。過去に何を見落として手戻りが起きたか。顧客がどの説明を求めていたか。次の人が同じ場面で考え始めるための手がかりは、残せます。
ここで大切なのは、立派な報告書を作ることではありません。
毎回、長い振り返りを書かせれば、現場は続きません。忙しい時期ほど、記録は後回しになります。書いたとしても、誰にも読まれず、次の案件に使われなければ、作業を増やしただけになります。
残すべきなのは、誰かが将来使うかもしれない情報を無差別に集めることではありません。
次に同じ仕事をする人が、少し早く状況をつかめる情報。上司や営業が、顧客の変化に気づくための材料。本人が次の役割へ進むとき、自分が何を学んだかを振り返るための記録です。
経験は、保存物ではありません。
誰かが次の場面で使ったとき、初めて仕事に戻ります。
DSC（Dsystem Cycle）は、答えを蓄えるための仕組みではない
ディーシステムでは、日々の業務報告や振り返りを通じて、経験を個人の中だけで終わらせないための取り組みとして、DSC（Dsystem Cycle）を進めています。
DSCは、社員が日々の仕事を記録し、AIの支援も使いながら、何が起きたか、どこで迷ったか、次に何を試すかを振り返る仕組みです。
ただ、これを「経験をデータベース化すれば、誰でも同じように判断できる」という仕組みだとは考えていません。
業務報告に書かれた言葉だけでは、背景が足りないことがあります。本人が何を当然だと思って省略したのか、なぜその判断に至ったのかは、対話しなければ見えない場合もあります。AIが文章を整理しても、顧客との関係や現場の緊張感まで理解してくれるわけではありません。
DSCで残せるのは、完成した答えよりも、考え始めるための材料です。
「この人は、ここで確認を入れていた」
「この案件では、この順番が詰まりやすかった」
「この対応はうまくいかなかった」
「次に同じことが起きたら、まずこの人に相談した方がよいかもしれない」
そうした記録があることで、次の人が何もない状態から始めずに済む。上司や同僚が、本人のつまずきに早く気づける。顧客から受けた評価や指摘を、その担当者だけの記憶で終わらせずに済む。
DSCは、経験を完全に引き継ぐための装置ではありません。
経験が消えそうになる前に、会話や振り返りを始めるきっかけをつくるためのものです。
AIに任せられること、任せきれないこと
生成AIを使うと、会議の要約、問い合わせ履歴の整理、文書の下書き、過去記録の検索は以前より進めやすくなります。
特定のキーワードを含む障害対応を探す。似た問い合わせをまとめる。日報や週報から、繰り返し出ている課題を拾う。新人がつまずいた場面を整理する。こうした作業は、経験を再利用できる状態に近づけるうえで役に立ちます。
しかし、AIに記録を渡せば、それだけで経験が残るわけではありません。
そもそも何を記録するのか。誰が内容を確認するのか。誤った前提が混ざっていたとき、どこで修正するのか。顧客情報や機密情報をどう扱うのか。古い判断をいつ見直すのか。こうしたことを決めずに始めれば、検索できる情報だけが増え、現場はかえって迷うかもしれません。
AIは、過去の記録を探しやすくすることはできます。
ただ、今起きている問題に対して、その記録が本当に使えるかを決めるのは人です。
たとえば、以前の障害対応が成功したとしても、今回も同じ対応が正しいとは限りません。システムの条件、顧客の業務、影響を受ける部門、締め日の状況が違えば、優先順位も変わります。
AIを使うほど、現場の人には「答えを受け取る力」ではなく、「その答えを使ってよいかを確かめる力」が求められます。
だからディーシステムでは、AIそのものを残したいとは考えていません。
残したいのは、顧客の仕事を止めないために、誰が何を確認し、どんな理由で判断したのかという記録です。AIは、その記録を探し、整理し、次の人が使う入口をつくるために使います。
経験を事業につなぐとはどういうことか
一人の社員が顧客の現場で得た経験を、その人だけの成果で終わらせない。
これは、社員に「自分の知識を会社へ渡してほしい」と求める話ではありません。本人が積み上げた経験を尊重しながら、次の仕事で活かせる条件を会社側がつくる話です。
営業が、顧客から聞いた困りごとを現場へ渡す。現場が、そこで得た気づきを営業や管理職へ返す。管理職が、本人に次にどんな役割を任せるかを考える。採用した人の経験を、顧客の課題に合わせて活かす。育成の場で、過去の失敗や判断を教材にする。
その間にある情報が切れれば、経験は個人の中で終わります。
逆に、経験が次の人や次の顧客へ渡れば、過去の仕事が未来の仕事を少し進めます。
ディーシステムがSAP、ERP、IT運用、業務改善、生成AIの支援で扱っているのも、突き詰めれば同じことです。
システムを導入する。運用を引き受ける。人を配置する。AIを使う。それぞれは目的ではありません。顧客の現場で起きていることを理解し、その場で得た経験を、次の改善や次の人材育成へつなげるための仕事です。
人が辞めない会社をつくることは、現実的ではありません。
それでも、人が辞めるたびに顧客への理解や、過去の失敗、仕事を進める順番まで失う会社にはしたくない。
一人の担当者が残した記録を、別の人が読んで、次の判断の手がかりにする。経験者が持つ専門性を、新しい顧客の課題へつなぐ。顧客から受けた評価や指摘を、次の提案や育成へ戻す。
すべてを残すことはできません。
ただ、何も残さずに終わらせないことはできます。
人が入れ替わることを前提にしながら、顧客に役立った経験を事業として積み上げていく。そのために、ディーシステムは人の経験と、それを次の仕事へ渡す仕組みの両方を考え続けます。
ディーシステムでは、ERP、IT運用、業務システム開発、生成AI活用の支援を通じて、現場で得られた経験を次の業務改善や人材育成へつなげる取り組みを進めています。
ベテラン社員の退職を控え、引き継ぐべき範囲を整理したい。
担当者ごとの顧客対応の差を減らしたい。
過去の障害対応や問い合わせ履歴を、次の仕事に活かしたい。
AI活用を始める前に、どの情報を残すべきか考えたい。
そうした課題があれば、現場の状況を伺いながらご相談をお受けします。
