見出し画像

自動テストの社内ヘルプデスクを16ヶ月間やって思ったこと

「ビジュアルリグレッションテストに最適なツールを教えてください」
「大変です!IEが動かないです」
「SeleniumとCypress どっちが良いですか?」

どうもこんにちは、自動化アーキテクトの森川です。

冒頭は自動テストの社内ヘルプデスクにやってくる問合せの一部です。フランクな書き方をしていますが、実際にはもっと丁寧な文面でいただいています。

E2Eテストツールの開発から教育とヘルプデスクを兼任している私のところには、自動テストのエンジニアからの問合せがたくさん来ます。

ヘルプデスク担当として1年と数か月が経ち、QAログもかなりたまってきたので、振り返ってみたいと思いました。


自動化ヘルプデスクって?

ざっとこんな感じです。

・自動化教育を受けた社内エンジニアの現場からの問合せに対応
・常時100人近くの自動化エンジニアが稼働
 ※ 全員がE2Eテストを担当しているわけではありません
・問合せ、ナレッジベースには社内標準ツール(MS Teams)を運用

社内ヘルプデスクは自動テストの教育を受けて現場にアサインされたエンジニアの皆さんを後方支援します。

弊社の自動テスト教育は比較的充実していますし、E2E自動テストツールのRacineは言語経験のあるエンジニアならば誰でも自動テストが書ける仕組みになっています。

SHIFTのGUIテストツールRacineとその開発プロセス

とはいえ、教育で得た知識だけでは実務はまわせないというのも然り。現場ならではの問題が毎日もりもり発生するものです。

そんなときに社内ヘルプデスクの出番となります。

サマリ

問合せログの集計値を見てみましょう。

画像8

期間は直近の16ヶ月間、問合せ件数は244件

工数にして110H、総勢66人から問合せ

月当たりに換算すると15件/6.9H、日当たりでは0.8件/20.6分。

1日に約20分の問合せというのがどれだけなのか、ちょっと感覚ではわからないですね。

どんな問合せが多いか

問合せの中身を見てみましょう。

カテゴリでは65%がE2Eテスト、ツールでいうと弊社のE2EテストツールRacineに関する問合せが70%ほどです。

これは私の担当領域を反映しています。他の自動テストに関する問合せは別のシニアアーキテクトのところに来ていると思います。

画像7
画像7

問合せにはツール固有のエラー解決法や技術選定に関するもの、抽象的な技術QAなどがあります。解決できるエラーは即答できるものから時間を要するものまでさまざま。最終的にGitHub IssueでOSS貢献につながるケースもありました。

やはり難しいのは技術選定に関する質問です。ツールの優位づけは前提条件や目的によりますので一概に断言できないことが多いからです。

問合せの頻度

画像4

1日1件が基本、2件の日もまぁまぁあります。1日に4、5件はつらいですね。聖徳太子なスキルが必須になりそうです。

1日の最大問合せ工数は3.7Hでした。その日は絶対に自分の仕事できてないですね、大丈夫か私。

問合せがある日だけで見た平均対応工数は40分/日でした。40分間の突発的な割り込みは結構辛いです。このおかげで自分タスクはできるときにさっさとやっつける習慣が身についた気がしています。

プライベートチャット強し

問合せの方法では面白い数字が見られました。

パブリックなQAチャンネルでの問合わせを推奨していますが、実情はプライベートチャットが50%と大人気なのです。

画像5

パブリックな場所のほうが有識者がレスポンスしやすいから良いはずなのですが皆さんの感覚はちょっと違うようです。

実は私もチャット経由の問合せが多いことに当初は戸惑いましたが、今ではそれよりも質問を躊躇されることをリスクと考えるようになりました。わからないことはすぐに尋ねるというのはエンジニアにとって大切なスキルの1つですし、そのための手段は別になんだって良いと思います。

余談ですが、パブリックなチャンネルの利用を促進するには、単に質問しやすい空気を作るのではなく「どんな事でも尋ねて良い空気」が必要だと思っています。

『え!そんなことも知らないの?』
みたいな一言がパブリックチャンネルに1つ投げ込まれるだけで雰囲気がぶち壊しになってしまうのは余りにもったいない。自戒をこめて心に刻んでおきたいですね。

気をつけていること

後出しで良いから必ずパブリックナレッジ化

解決したネタをプライベートのまま放置すると知見の共有になりません。
後日パブリックなチャンネルに転記してもらうようにお願いしています。

面倒なので嫌がられると思っていましたが、殆どの方が非常に協力的なのは嬉しい誤算でした。

スピードが命

問合せは反応速度が肝心です。特にお客様発信の質問の解決スピードはビジネス価値そのものにつながると思っています。

なるべく数分以内に第一報するように心がけていますが、できない場合は他の方が代りに回答してくださることも多く「スピードが大事」という文化が皆さんの間に根づいている、と勝手に思っています。

これも可視化したいので問い合わせから第一報までの時間をロギングできるチケット管理ツールが欲しくなりますね。

あらわれてきた変化

ヘルプデスクを続けることで、エンジニアの皆さんの認識に変化が見られるようになりました。あくまで肌感ではありますが。

回答スピードの向上は述べましたが、質問者の訊き方も要領が良くスムーズになっていると感じます。過去のQAスレッドを見て「訊き方のコツ」を真似ることができるのかもしれません。

また、定期的に起こる似た問合せは過去スレッドやナレッジを案内することでスピーディに解決するようになりました。問合せしなくてもナレッジベースを検索して見つけて解決した、という嬉しい声を聞くことも。

ナレッジのスレ主を辿ることで有力な識者をキャッチできるので、スレ主と質問者で直接会話して解決されるパターンもあります。

これらは総じて過去スレッドやナレッジを活かせているということだと思っています。

知の共有ですね。

余談ですが、ヘルプデスクとナレッジ検索を高効率化することで弊社の自動化エンジニアが一つの有機的な知の集合体のようなものにならないかな、と夢想することがあります。エンジニアチームとしてのナレッジバリューが爆発しそうですよね。

更に余談ですが、知の集合体といえばスタートレックシリーズに出てくる「ボーグ」を思い出します。

ボーグ - Wikipedia

ボーグは全メンバーが意識を常時共有しており、自分のことを「我々」と名乗るなんともけったいな機械生命体。ボーグの一個体が新しい知識を得た瞬間にすべての個体が同じ知識を得る、という仕組みです。

ボーグだとヘルプデスクが楽そうですね。(私の仕事は無くなりますが)

でもボーグはだいたい悪役で、主人公はいつも手を焼きます。

ちなみにスタートレックシリーズのマイベストはジェネレーションズ(新スタートレック)です。データ少佐最高。

ライフサイクル

ナレッジの蓄積からその先の流れも見えてきました。

画像6

1. ヘルプデスクの活動からパブリックなナレッジがスタックされます
2. 特定カテゴリのナレッジをまとめたポータル情報ページを作ります
 ※ 必要に応じて追加の技術調査を行います
3. ポータルページを元にノウハウを学ぶ教育カリキュラムを整備します
4. 教育を受けたエンジニアがサービスをデリバリします

この図の実現にはまだ時間がかかりそうですが、問合せから生まれたナレッジの一つ一つから最終的にサービスを創出するというヘルプデスク・ドリブンなPDCAにちょっとワクワクしてしまいます。

課題

いくつか課題が見えてきました。

問合せプラットフォーム

現状、問合せとナレッジベースにMS-Teamsを、情報ポータルとしてShare Pointを運用しています。Teamsはナレッジベースとしては検索機能が微妙ですし、スレッドにタグやカテゴリなどの構造は持たせられません。(何よりもWikiは検索対象外なのは辛みが深い。改善切望です)Share Pointは慣れれば意のままに作り込めますが学習コストが気になります。

また質問頻度や回答速度やリアクションを定量化できると生産性が可視化されて捗りそうです。このあたりは専用のカスタマーチャットツールを導入できたら面白そうです。

スケール

今回は私の手元で握っている数値を対象にしましたが、社内のヘルプデスク的なコミュニケーションすべてのログを採れるようにスケールしていきたいです。

特にお客様からいただいた質問から回答~解決までの経緯を定量的に観測できたら、ビジネス的な価値の可視化に繋がりそうですし、日頃の技術研鑽を頑張っている皆さんにとってはポジティブなメトリクスが増えるので良い話だと思います。

一方で、ヘルプデスク業務はマンパワーに頼るところが大きいためビジネスとしてスケールしない、という側面も感じました。

「三人寄ればなんとやら」と1人で考えるよりも短い時間で解決できることは多々ありますが、そもそも識者があと3人必要っていう時点でスケールしにくいです。

ナレッジ検索効率の向上やAIによる支援という発想が浮かびますが根本的にはマンパワーがある程度のボリューム必要なことには変わりないと思います。

このあたり、面白いアイディアがあれば是非ともお聞きしたいです。

まとめ

本エントリーでは手元のログをもとにヘルプデスク業務を振り返ってみました。

エンジニアが困っている事を解決するという単純でミクロな業務ですが、ログ収集とナレッジ化から始まるPDCAを回すことで、ミクロで終わらない活動につながることがわかりました。

また、質問している皆さんは1人ではなく、いつかまた回答者側にまわることもあることを実感してもらうことでエンジニアの意識向上にもつながっているのでは、と思いました。

とかなんとか書いていますが、今回は数値と私の所感のみで書いています。

実際のところ、質問者の皆さんの思っていることはどうなのでしょうか。
もしかすると私の思いとはかけ離れているかもしれません。

そこで質問者向けのアンケートを計画しています。
次回はヘルプデスク利用者のアンケート結果から見る実態をレポートできればより深い考察が見えてきそうです。

ご期待ください。

最後までお読みいただきありがとうございました。

それでは皆さん 長寿と繁栄を

__________________________________

執筆者プロフィール:森川 知雄
中堅SIerでテスト管理と業務ツール、テスト自動化ツール開発を12年経験。
SHIFTでは、GUIテストの自動化ツールRacine(ラシーヌ)の開発を担当。
GUIテストに限らず、なんでも自動化することを好むが、ルンバが掃除しているところを眺めるのは好まないタイプ。
さまざま案件で自動化、効率化によるお客様への価値創出を日々模索している。

このSHIFT公式ライターの他の記事を見る

画像7

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/

SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/


みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!