💡 この記事はcorp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2022の2日目の記事です。
ITサポートにおけるKPI設定には非常に難しい部分があります。そもそも数値化が難しく、また利益部門ではない事から、数値目標を設定するプレッシャーもかかりにくいからです。そのためITサポートを業務のメインにしている人にとっては、KPIを設定し、PDCAを回すという王道の取り組みが難しく感じられます。
今回は年3000件の問い合わせ対応を一人で担当している私が、機能するKPIを見つけるために回した4回分のPDCAと、それぞれのKPI設定時に起きた効果についてお話しします。
なお自分の環境は下記の通りです。境遇としては「チーム内に自分以外の専門家がいるITサポート」という感じでしょうか。スキルの高い上司や先輩がいて、その人がより専門性の高い業務へ専念できるようにする意図で配属されるITサポートです。
ではお話ししていきましょう。まずは「ITサポートのKPI設定はなぜ難しいのか？」という点です。
KPI設定が難しい事自体はどの部門でも変わりません。数値化を行い、正しく集計する事そのものが面倒ですし、誤ったKPI設定は業務全体に悪影響を及ぼすでしょう。
しかしその中でも、ITサポートには特にKPI設定が難しい理由があります。それはITサポートが「間接部門の間接部門」である事が理由です。
一般的に間接部門は利益部門よりKPI設定がしにくい事が多いです。売上に直結する数字を持っておらず、数値化への会社のモチベーションがそもそも低い事や、減点評価になりやすい事が理由です。
それでも間接部門であれば、多少無理にでもKPIは設定される事が多いでしょう。全社で統一した形で人事評価を行う必要があるからです。情報システム部門も同じ理屈で、何とかKPIを設定する事になるのではないかと思います。
しかしITサポートは、情報システム部門で設定されたKPIに対し、さらに間接的な役割を持つ事が多いです。ITサポートの基本的な役割は、情報システム部門の中にいるスペシャリストが、専門的な業務へ専念できるようにする事だからです。
ですから「システム稼働率」とか「削減した工数」と言った情報システム部門のKPIに対し、直接貢献する役割をITサポートは持たない事が多いです。数値化へのモチベーションの低さも測定の難しさも倍になり、評価基準もなあなあになってしまいやすい。これが「間接部門の間接部門」であるITサポートの難しさだと思います。
ではKPIが設定できないとどのようなデメリットがあるのでしょうか？ 最大のデメリットは、振り返りができない事です。
KPIがなくても、PlanとDoはできます。しかしCheckはできません。やった事を評価する基準がないからです。
もちろん感覚として個人が「これは良い」と評価する事はできます。しかしその基準には事前のコンセンサスが取れていませんし、人によって基準は異なり、同じ人でもタイミングによって良いと思うものは変わります。PDCAを回す度に進む方向性が変われば、サイクルは上向きのスパイラルではなく、ただの堂々巡りになるでしょう。
またKPIが設定できないと、会社へのアピールも難しくなります。「いつもより忙しかった」というアピールには「大変だったね」という答えしか返ってきません。数値で客観的に評価を行うというのは仕事において基本中の基本ですから、これができないというのは様々な場面で大きな悪影響を及ぼします。
ITサポートのKPI設定に対し、人事や上司の関心は薄いかもしれません。しかしそこに甘んじてしまえば、状況が良くなる事はありませんし、自らの頑張りや価値を正しく評価してもらう事もできなくなってしまいます。
KPIの設定が重要だという話をしてきました。そしてKPIを設定する時に欠かせないのが数値化です。数値化ができない要素は測定できませんから、KPIとして測定する事はできません。
すると真っ先に必要なのは、何が測定できるのか確認する事です。数値化できる事がKPIの候補になりますし、逆にKPIに設定したい指標が測定できない状態なら、測定できる環境を整える事がスタート地点になるからです。
自分の場合は全社にアンケートを実施し、満足度を測定する事ができました。またHalpのような問い合わせ管理ツールは導入できる状況にありませんでしたが、代わりにチャットツールはあったので、GASで簡易の問い合わせツールを自作しました。
結果として下記の4つを測定する事ができるようになりました。
満足度
問い合わせの対応件数
1件あたりの対応時間
1件あたりのやり取り数
そこでそれぞれについてKPIを設定し、どのような変化があるか実験しました。
結果として現在KPIに設定しているのは「1件あたりのやり取り数」です。問い合わせ1件に対し、チャットを何往復したら問題を解決できるかというポイントです。
ただしこれは私の環境で最適だったKPI設定です。正解ではないので、チームの人数や会社の環境が変わればフィットしない場合もあります。
そこでここからは各KPIを設定した時に起こった変化を解説していきます。それぞれの項目を読み比べて頂きながら、自ら設定する時の参考にしてもらえればと思います。
まず紹介していくのは「満足度」をKPIに設定した場合です。
皆さんもチャットサポートを受けた時に「今回の対応は☆いくつでしたか？」というアンケートへの回答を求められた事があるのではないでしょうか。満足度というのはあれです。サポートの満足度をユーザーに聞いて、☆が高ければ良いとする評価方法です。サポート業務の質を数値で評価するなら、まず思い浮かぶ指標ではないかと思います。
弊社でも数値目標が重視されるようになってから、上長の主導でこのKPIを設定しました。3ヶ月に1度満足度アンケートを取り、その結果を改善の基準にしようというものです。
今までひたすら来た問い合わせに対応するだけだったので、指標ができたという点で、この取り組みには大きな意味がありました。一方でチームでは初の試みだったため、課題もあったと思います。
普段のITサポートの対応では、その対応へのちょっとした不満や要望を伝えてもらう事は難しい事が多いです。改めてアンケートを配布する事で、目に見えない改善点を可視化できるというのは大きかったです。
例えば問い合わせがあり、やり取りをする中で、対応した人がグラボの知識が浅く、不信感を抱いてしまったデザイナーがいました。これは問い合わせの内容そのものではなかったため、アンケートがなければ把握できない不満でした。この結果を受けて部内でグラボに関する知見を深め、以後のPC選定の際にその知識を活かせました。これは満足度を調査したからこその結果だったと思います。
しかし満足度をKPIに設定する方針は、長くは続きませんでした。ITサポート・ユーザー双方に大きなコストがかかったためです。
ユーザー側について言えば、回答するために1人あたり10分程度はかかります。アンケートの回答は300人程度から得られたので、回答してもらうだけで、全社に50時間の工数を割いてもらっている事になります。
ITサポート側では、集計に相当な時間がかかりました。満足度の低い人に絞り込んで対策する形ならそこまで時間はかからないのですが、☆５の回答をしつつ、ちょっとした要望をコメント欄に書く人は少なくありません。わざわざアンケートに答えてもらったのに、そうした声を拾わないのはどうかという話にもなります。コメントを一つ一つ読みつつ、チーム内でどう対応するか方針を固めるのは骨の折れる作業でした。
手間がかかっても、効果が多ければ良いのではないかという考え方もできます。実際、今まででは気付けなかった改善点へ対応できれば、大きな効果を挙げる事もできたでしょう。しかしここに来てもう一つの問題が出てきてしまいました。
こちらの問題が致命的でした。寄せられる要望の中には、会社の方針として対応すべきではない問題も多くあるのです。
ITサポートの満足度を調査したいので、ITサポートで改善できる要望が来れば理想的です。しかし実際にはITサポートの範囲で改善できる要望は少なく、要望の多くは会社方針に関わる部分へ寄せられました。投資の必要なインフラ面での改善や、セキュリティや規定に関わる部分、またテレワークの頻度のような会社方針に関わる部分の要望です。
こうした部分はITサポートだけではなく、部門として、あるいは会社として調整が行われます。そして多くの要望に対し、対応しないという事が会社の方針になりました。これは経費削減という会社の状況もあったでしょうし、アンケートの趣旨がITサポートの満足度であり、そもそも経営層が何かしらの問題意識を持っていたわけではないという事もあるでしょう。
もちろんこうした要望を上手に上の人へ伝えるべきかもしれません。会社全体の課題がアンケートの中に眠っているかもしれません。しかしそれは会社として取り組むべき事で、ITサポートのKPIとして設定しても有効性は低くなってしまいます。
結局は改善の種が多く見つかりながらも、実際に改善を行う事はあまりできないままPDCAサイクルは止まってしまいました。
やってみて分かったのは、「満足度」をKPIに設定するのはハイコスト・ハイリターンだという事です。
自分の環境でこのKPIが機能しなかった理由は、十分なコストをかけられなかったという点につきるでしょう。
例えば問い合わせ管理用のツールを導入できれば、サポートの終了時にすぐ満足度のアンケートを配る事ができたかもしれません。数ヶ月に一度、大きな手間をかけてアンケートを集計する必要はありません。また出てきた改善点に対しても、十分な費用をかけられる状態であれば、解決のためのインフラ投資ができたかもしれません。満足度を向上させていく事もできたでしょう。
しかし自分の環境では費用をかけられませんでした。こうなると満足度の向上というのは現実的ではなくなってしまいます。
思えば自分がチャットサポートを受けた時、満足度のアンケートへの回答を求めてきたのはGoogleやAdobe、DellやSoftBankと言った大企業ばかりでした。自分の所属している企業とは規模感が合っていなかったのかもしれません。
逆に、会社としてITサポートや情報システム部門へしっかりと投資を行おうという意図がある時には、満足度はKPIとして有効に機能するでしょう。
満足度はKPIとして有効に機能せず、数値化の試みは自然消滅してしまいました。一方で、KPIを設定するのは大きな意味がありそうだという事も個人として体感できました。すると何とか他のKPIを設定できないかという事で、自分なりに考えてみたくなってきます。
そこで最初に設定したのが「問い合わせの対応件数」です。
複数人いるチームであれば、多くの問い合わせに対応すれば、評価を上げるという形になると思います。他のメンバーより頑張って対応したから、評価を上げようという形ですね。
しかし自分の場合はITサポートのメンバーが一人ですから、これでは評価が成り立ちません。メンバーが一人だと「問い合わせが発生した件数＝対応した件数」になりますが、問い合わせの発生件数が多いという事は、それだけ問題が多く発生しているというネガティブな意味を持つからです。
そこで「問い合わせの対応件数が少ない程良い」という形でKPIを設定してみました。問題をそもそも起こらないようにして、そもそも問い合わせが発生しないよう頑張ろうという意味です。
このKPIを設定してから大きく変わったのは、先回りしての対応が必要だという点です。
アンケートを取っていた時は、対応をした後で評価をもらい、改善策を打つ形でした。しかし問い合わせの件数を減らそうと思うと、問い合わせが発生する前に何かをする必要があります。
すると問い合わせが発生しそうな案件や運用があった時に、事前にマニュアルを充実させたり、そもそも問い合わせが発生しにくいような方法を考えたりする事ができます。先回りして対応していく事で、余裕を持って費用対効果の高い策を打つ事ができます。
こうして対応の質を上げられている感覚はありました。しかし対応件数をKPIにする事には大きなデメリットもありました。
このポイントが非常に厄介でした。問い合わせの総数は、コントロールする事が非常に困難だったのです。
問い合わせの総数は、問い合わせが発生するようなイベントの有無に大きく左右されます。例えば複合機の入れ替えを全社で行い、各ユーザーに設定を自分でしてもらう事になれば、複合機の設定周りの問い合わせは発生しやすくなります。
そしてこうしたイベントは不定期に発生します。すると本来であれば何件程度問い合わせが発生したのか測定する事が非常に難しくなります。
もちろん事前に対策を打つ事で、問い合わせの発生数を抑える事は可能ですが、対策を打った事で減った問い合わせの件数は測定できません。またイベントは不定期に発生しますので、前月と今月の問い合わせ件数を比較する事にもあまり意味がありません。
測定できなければ、頑張っても適当にやっても、見かけ上は何の変わりもありません。どうにか効果測定をする方法がないか検討しましたが、結局有効な方法は見つけられませんでした。
問い合わせの対応件数というのはシンプルな指標です。チームに複数のメンバーがいる時は、メンバー間での対応件数の比較を行う事で、有効な評価を行う事が可能でしょう。しかし自分の場合はITサポートが1人しかいなかったために、この指標は有効に機能しませんでした。
問い合わせの対応件数は、自分でコントロールできない部分が多く、KPIに設定しても効果測定ができませんでした。そこで次に選んだ指標が「1件あたりの対応時間」です。
これならITサポートのレベルアップが直接数値に反映されます。自らコントロールできる部分で効果を測定できれば、PDCAのサイクルも回していく事ができます。また問い合わせを短時間で解消できれば、ユーザーの満足度も結果的に上がると考えました。
このKPIはある程度機能しました。一方で、ITサポートとユーザー双方の満足度という点では下がってしまったかなと思います。
最も大きな効果があったのはここです。
満足度を測定していた時は、フィードバックが数ヶ月に一度でした。対応件数は日次でも取れていましたが、件数はコントロールできない数値でした。しかし対応時間は問い合わせ1件ごとに測れていて、今の自分の対応の評価がすぐに返ってきます。
しかも1件1件の対応の善し悪しを数値化できていますから、過去1年間の問い合わせをまとめて振り返る事も容易です。
細かい単位で素早く振り返りができますから、PDCAのサイクルも速く回す事ができます。すぐに評価を得られれば、モチベーションにも繋がっていきます。
KPIの設定が活きている事を強く実感できたのはここが初めてでした。
「対応時間」という一元的な数値で対応を評価する事で、KPIを悪化させている問い合わせを簡単に発見できます。シンプルに対応時間の長かった問い合わせを振り返る事で、簡単に対策を打つべき問い合わせが絞り込めるからです。
特に初見の問題や専門性の高い問題で対応時間は長引く傾向があります。こうした案件についてしっかりと調査・共有する事で、初見殺しのような問題への対策をしっかり打つ事ができます。
一方で副作用もありました。1件1件の対応がやや雑になってしまったのです。
対応時間をKPIに設定すると、未対応の案件がカウントアップタイマーに見えてきます。放っておけばどんどん対応時間が長引いてしまいますから、一刻も早く回答し、タイマーを止めなければなりません。
すると未対応案件が重なってきた時、問い合わせに対してしっかり調査して回答するよりも、とりあえずの一次回答をした方が良い状態になります。例えば「とりあえずwindow updateかけてOS再起動をお願い致します」 という感じですね。こう言っておけばとりあえずの時間は稼げますし、うまくいけば直ってしまうかもしれないからです。
これはある程度良い面を含んでいます。いつまで経っても回答が来ないより、とりあえずの回答をもらえる方が安心できるからです。また「困ったら再起動」のような対応を自力でやってもらえるようにもなるかもしれません。そして「とりあえず」の対応で解消しなかった時に、初めて本腰を入れて調査をする。たしかに効率の良いやり方かもしれません。
しかし裏を返せば、これは問い合わせに対し、最初は適当な対応をしている事を意味します。
ITサポートに限らず、仕事で忙しくないと感じるタイミングというのはほとんどありません。やる事はいくらでもあります。すると「とりあえず」で対応する機会は予想よりずっと多くなります。同じ人に二度、三度ととりあえずで対応してしまう事も出てきます。
するとユーザー側の感覚は「ITサポートに言ってもなかなかちゃんと調査してもらえない」というものになります。するとユーザー側がちゃんとITサポートに対応してもらうには「何度も言う・強く言う」必要が出てきます。
同じ事を「何度も・強く」言う必要があるというのは、言う側も言われる側も当然気分の良いものではありません。自然と雰囲気はギスギスしてきます。
副作用はもう一つあります。中長期的にやった方が良い事に取り組みにくくなるのです。
数ヶ月に一回程度来る問い合わせがあったとしましょう。少し内容がマニアックな感じで、問い合わせが来る度に「どこの設定が原因だったかな」なんてちょっと思い出しながら、10分程度で解消できるような内容です。
こうした問い合わせに対し、ドキュメントやマニュアルを残せれば、次回以降の対応が楽になります。30分かけて対応策を適切な場所に残せば、1年程度でこの30分はペイできます。あるいは本腰を入れて調べれば、グループポリシー等でそもそも問題が起こらないようにする事もできるかもしれません。
しかし対応時間が伸びてしまいますから、とりあえずは一次回答をして、タイマーを止めようという事になります。そして後でドキュメントを残そうと一旦は思いますが、次から次へと問い合わせを処理していくうちに、ドキュメントの作成は後回しになり続け、やがて忘れ去られてしまいます。
PDCAのサイクルをより速く、正確に回せる形は作れました。しかしサイクルを回す事自体の優先順位は下がってしまったように思います。
総合的に見て、やや短期的なスパンで結果を出すために非常に有効なKPIだったかと思います。問い合わせ1件単位での評価や簡単な振り返りが可能になるので、改善点が見つかりやすくなる上に、モチベーションにも繋がります。
一方で改善活動そのものには力を割きにくく、効果の小さな施策をたくさん打っていく形は作りにくかったです。問い合わせ1件1件に最速で対応しつつ、対応時間が大きく長引いた問い合わせに対応を打つ事になるでしょう。
短期的に見た時に、非常に効果を発揮するKPIだったと思います。
対応件数をKPIに設定する事で、パニック状態だったITサポートに一定の安定がもたらされました。一方で状況が安定してきた時に、もう一歩先のレベルへ進みたくなってきました。
そこでKPIに設定したのが「問い合わせ解消までのやり取り数」です。解消までにチャットが何往復したかを指標に設定しました。
対応時間をKPIにした時、最も悪化したのがこの指標でした。どうしても「とりあえずの一次回答」が増えてしまうので、一度で問い合わせが解消せず、やり取りの数が増えてしまったからです。
このKPIは現在に至るまで継続して利用しております。私としてもおすすめのKPIになるので、詳細を説明していこうと思います。
対応時間をKPIにした時点でも、指標の悪い問い合わせを簡単に見つけられました。しかしそこから一歩進み、このKPIでは指標の悪い問い合わせに対し、対策も打ちやすくなりました。
なぜならやり取りの数が増えやすい問い合わせは、性質として複雑さやややこしさを含んでいる事が多いからです。
解消のために高い専門性の必要な問い合わせも、対応時間は長くなりやすいです。しかし専門性が高い故に、ユーザーとITサポートの間でやり取りをしても分かる事が少ないので、やり取りの数自体は意外と膨らみません。
一方で運用のルールが複雑だったり、ややこしかったりする場合、チャットで説明してもすんなり理解してもらえない事が増えます。また最初の理解度が低ければ、最初の問い合わせに回答しても、芋づる式に他の疑問点が出てきてしまい、やり取りの数は膨らみます。
そしてこうした複雑さが生まれやすい問い合わせは、技術的に高度な問題と言うよりは、むしろ社内独自の複雑なルールが原因になる事が多いです。規定や監査への対応や、過去の出来事に対する再発防止策が時間の経過と共に積み重なり、初見の人には理解しにくい複雑な仕組みができた結果、やり取りの数が増えるのです。
そしてこうした部分はITサポートが最も得意とする分野になります。複雑な部分を何度も問い合わせられるので、理解度もどんどん上がっていくからです。
結果としてKPIの悪い問い合わせは、ITサポートの得意分野に関する問題だという形ができます。得意分野であれば、改善の施策もかなり打ちやすくなってくれます。
これは避けられない副作用です。
やり取りの数を減らすためには、1件1件を丁寧に対応する必要があります。一回でユーザーの疑問を解消できるようしっかり考える必要があるためです。その分1件あたりの対応時間は長引いてしまいます。
その分短期的には問い合わせ対応も苦しくなります。ある程度業務が安定していないと、やり取り数を減らそうというアプローチは苦しいかもしれません。
対応に時間がかかっても、満足度は上がった気がします。あくまで体感にはなってしまうのですが、ユーザーから好意的な反応をもらえる機会が目に見えて増えたのです。
理由を考えてみると、対応時間の長さというのは見た目程にユーザーのストレスになっていないのではないかという点に思い当たりました。
元々は対応時間が1時間かかれば、ユーザーの業務も1時間止まってしまうという考えがありました。
しかし問い合わせの中に、解消しないと業務が完全に止まってしまうようなものは1割もありませんでした。ネットワークが不調でもローカルで作業はできますし、PCが壊れても打ち合わせには参加できます。対応の時間が10分や20分伸びてしまっても、事前に分かっていれば、ただ作業の順番が変わるだけで済む場合も多いのです。
一方でやり取りの回数は満足度の低下に直結します。下記のようなやり取りを想像すれば、何度もやり取りをする事がいかにストレスを感じさせるか分かると思います。
「ご注文は何にしますか？」
（5分後）「コーヒーでお願いします」
（5分後）「かしこまりました。豆は深煎りで入れてもよろしいでしょうか？」
（10分後）「お願いします」
（5分後）「ありがとうございます。サイズはどちらにしますか？」
（5分後）「Mでお願いします」
（10分後）「コーヒーにガムシロップとミルクはお付けしますか？」
（10分後）「お願いします」
（10分後）「会計は現金のみとなっておりますがよろしいでしょうか」
（コーヒーを頼むのを諦める）
コーヒーを頼むまでに1時間かかるのは、最悪そういうものだと割り切れるかもしれません。しかし5分や10分の単位でやり取りが都度発生しては、他の事がろくにできません。これは非常にストレスを感じさせるでしょう。
間抜けに見えるかもしれませんが、チャット主体のやり取りだとこうした事態は容易に発生します。コーヒーを注文する時とは違い、お互いに他の事をやりながらやり取りをしているからです。
ですから多少不自然に思えたり冗長だったりしても、やり取りの数を減らそうと心がける事は大きな意味を持ちます。
「ご注文は何にしますか？」
（30分後）「コーヒーのMをお願いします。豆は深煎りで、ガムシロップとミルクも付けて下さい。会計は現金で行うつもりです」
（30分後）「承知致しました。お会計は500円になります」
同じ時間がかかっていても、ストレスの度合いはだいぶ減っていると感じられるでしょう。
満足度が上がれば、ユーザーは協力的になってくれます。積極的に情報を提供してくれますし、ちょっとした対応なら自分でやろうとしてくれます。仕事がやりやすくなる感覚を得る事ができました。
KPIをやり取り数に設定してから、良い循環ができています。対応時間をKPIにしていた時は、頑張ってKPIを改善していました。しかし今は無理をしなくても、徐々に状況が良くなってくれています。
ITサポートがキャパオーバーの状態では、このKPIの設定に現実味がないかもしれません。短期的には対応時間が増えるので、中長期的に効果があっても、現実的ではない目標に感じられてしまうかもしれません。
しかしどうにかITサポートが回っている状態まで来れていれば、このKPIは予想以上に機能してくれるでしょう。
ここまで自分がKPIに設定した4種類の指標と、その効果を説明してきました。
気を付けてほしいのは、自分が最終的にやり取り数をKPIにしたからと言って、全ての環境でそうすべきだというわけではない事です。特に自分は一人でITサポートをやっています。ITサポートが複数人いたり、逆にひとり情シスだったりすれば、また違った最適解が生まれてくるでしょう。
しかしKPIを設定した事による効果そのものは、他の環境でも大きく変わりがないのではないかと思います。満足度を指標にすれば集計や調査にコストがかかりますし、対応時間を指標にすれば、対応の質が課題になると思います。
大事なのはどんな指標であれ、KPIを設定し、指標を改善しようとする事そのものです。KPIをこれから設定しようという時に、どんな効果があるのか事前に予測するために、今回の解説は役立ててもらえるかもしれません。
それでもどんな変化が起こったのかあまりイメージが湧かないという方のために、現在のITサポートでどんな変化が起きたのか3つ程例を挙げて見ようと思います。
WIKIの作成を進めた結果、一年でWIKIのビュー数が1600件を超えました。弊社では多い時で年に3000件の問い合わせがありますので、問い合わせの50％以上をWIKIでカバーできている事になります。
WIKIの拡充には継続的なモチベーションが欠かせません。「ナレッジの共有」や「ユーザーの利便性の向上」と言ったお題目だけでは、一時的なモチベーションを得られても、どうしても他の重要な仕事と比べ後回しにされやすいものです。会社の評価サイクルと絡め、KPIを数値で設定できている事によって、定期的にWIKI拡充のモチベーションを高める事ができます。
何か施策を実施した時に、効果の測定は費用と効果の足し算で行われがちです。30分かけてWIKIを作り、月に2回×15分の問い合わせを解消できたら、1ヶ月で工数をペイできたという形です。
しかし改善を続けると、目に見える部分以外にも積み重なる効果があります。
一つは自らの改善スキルそのものの向上です。ドキュメントの作成やKPIの設定、調査等を行う過程で、改善そのものが上手になっていきます。すると改善を行った前の30分より、改善の経験を積んだ後の30分の方が大きなバリューを出せる自分になっています。
もう一つは改善の効果が積み重なっていく事です。多くの改善は「最初に大変な思いをして、今後楽をする」という形を取るでしょう。そのため改善を続けていけば、今現在は大変な思いをしますが、今後は継続的に楽になっていきます。
さらに足元の余裕を作る事で、費用も効果も大きな施策へ取り組めるようになります。絶対やった方が良いのに、余裕がなくてできない事というのは誰にでもあるでしょう。こうした課題に取り組むために何より重要なのは余裕です。改善を積み重ねる事で、この余裕を作る事ができます。
これらはスキルや工数と言ったキレイな世界はもちろん、印象や評価と言った人間関係の世界でも一定の効果を発揮します。短期的に大変な思いをしておけば、周りに「○○さんは今仕事が大変なんだ」という事を認識してもらいやすくなります。すると新たな雑務を安易には振られにくくなります。ITサポートは雑務が多く、立場も弱くなりやすいので、こうした形で細かな雑務を減らせるのは有利に働きます。
その上で改善の効果が出て、余裕ができても、しばらく評価は「○○さんは大変」のままです。結果としてさらなる余裕を生む事ができます。
多少無理してでも改善施策を打つ事で、目に見えない部分でもこれだけの効果を生む事ができます。しかもこれらの効果は長期的に積み重なっていきます。複利でメリットを得る事ができるというのは、やってみて初めて分かった部分でした。
当初はITサポートはルーチンワークの位置づけでした。問い合わせ対応は重要度が低く、チャレンジ目標として＋αで何か大きな事を設定しなければならない状況でした。
しかしITサポートは工数の多くを占める上、問い合わせは受動的なので、工数を予測する事も困難です。結果として余った時間に取り組むチャレンジ目標の進捗も安定せず、いくら頑張っても、評価として認識される成果を出す事が難しい状況でした。
ITサポートに関する指標をKPIとして設定する事で、自分が工数のほとんどを割いているITサポート業務に関する事にチャレンジができます。指標を改善する事が自分の業務全体の改善に直結し、自己効力感も高まりました。
こうして改善を続け、余裕を作っていくと、ITサポートの守備範囲は非常に広い事に気付かされます。極端に言えばITに関する事は全て守備範囲にできますし、ITに関わらない総務的な部分にも手を伸ばす事ができます。
この事はしばしばネガティブなニュアンスをもって語られます。守備範囲が広いと何でも屋さんになってしまい、過剰に忙しくなったり、専門性が伸びなかったりするからです。
しかし一度改善のサイクルが回り出すと、この事はポジティブな意味合いを持ってきます。今後のキャリアを考える時に、進める分野が非常に幅広くなってくるからです。
例えばネットワークやサーバーと言ったインフラ面での切り分けはITサポートなら不可欠です。権限設定を行う事から、監査やPマーク、ISMSと言った部分にも接点ができるでしょう。社内ツールがあれば開発とも距離が近くなりますし、開発ができるようになってくれば、他のバックオフィス部門からも依頼を受けやすくなります。
もちろん複数の分野がそこそこであるという事は、一つの分野が一番である事に敵わない部分も多いでしょう。しかし一番ではなくても、その「そこそこ」のレベルを高めていけば、通常よりはるかに多くの問題を解決できる状態を作れます。
こうした取り組みの中で、将来的に目指していきたい場所はどこになるでしょうか？ 自分の現状での理想は「リスキル」ができるプレイヤーになるというものです。
「リスキル」にはスキルを再習得するという意味のものもありますが、ここではゲーム用語の「リスキル」を使っています。
ではリスキルとはどういう意味でしょうか？
リスキルとは、リスポーンキルのことです。
FPSゲームやTPSゲームの中には、自分のキャラクターが倒されても、リスポーン地点から復活し、再び戦闘に向かうことの出来るゲームが存在しています。 そのようなゲームにおいて、行われる戦術のひとつに「リスキル」と言われるものがあります。 リスキルの方法は、相手チームのリスポーン地点の近くに陣取り、リスポーンしてすぐの油断している状況を狙って、相手プレイヤーをキルするというものです。つまり、リスポーン（してすぐ）キル（する）という戦法です。 リスキルという戦法を使う利点としては、相手チームのプレイヤーは、復活してもすぐキルされてしまうため、リスキルがうまくいっている間は、自チームが数的有利となる状況を継続することが可能であるということがあります。 一方で、リスキルをする際には、相手陣地の奥深くまで潜入しなければならないため、かなり難易度の高い戦法であると言えます。
サッカーで例えるなら前線でプレスをかけて延々とボールを奪い続ける感じで、バスケで例えるなら自分のコートへボールを運ばれる前にゾーンプレスでボールを奪っちゃう感じです。敵陣、最前線で暴れ続けて、ディフェンスの人が仕事をする前にピンチを潰してしまうのがリスキルです。
一歩間違えれば呆気なく突破され、ディフェンスの人に余計な負担を与えてしまいます。ピンチを大きくしてしまうかもしれません。
しかし実力さえあれば、一人で盤面を支配する事さえ可能になります。
最前線に立って、ディフェンスの人にピンチを守らせない。あるいは突破されても、ピンチに対応しやすい形を作る。こうして作った余裕で専門家の人により難しい課題へ対応してもらう余裕を作りつつ、経験を積み続ける。こうした事がITサポートには可能なのではないかと思います。