はじめに
私は昔、DevOps Grp. に所属していました。
開発をしつつ、必要であれば保守対応、つまり問い合わせの対応も行っていました。
取り扱っていた製品の性質上、その日のうちに解決する必要があり、さらに解決まで一分一秒を争う問い合わせが多く、その上で繁忙期は全社一の問い合わせ数が殺到していました。
過去最高、1日で20件の問い合わせ対応を開始、完了したこともあります。
平均して、1件の問い合わせに30分もかけられない状況下で、非同期的にメールのような応対方法で、普通に対応していては時間が足りません。
その最中、編み出した方法論の話です。
問い合わせのタイプ
問い合わせには、大きく3つの種類があると考えています。
- 質問
→仕様の確認や操作方法についてなど。知識やナレッジの引用で完了する作業 - 情報調査
→環境やユーザー固有である情報、データ、ログを取得して、内容を確認する - バグ調査
→ソフトウェアのコードを追ったり、検証環境でバグの再現確認を行う
これらは1つの問い合わせ内であっても、タイプが変動します。
仕様について質問されたが実はバグでした、など経験あるかと思います。
掲題の「問い合わせを爆速で捌く-ジャグリング方法論」は質問と情報調査の種類に適用できます。
ジャグリング
ところで、みなさんは「ジャグリング」をご存じでしょうか？
いわゆる大道芸です、いろいろあります。
その中でも今回思い出してもらいたいものは、
出典：https://www.irasutoya.com/2015/02/blog-post_37.html
こちら「ボールジャグリング」です。
さて、ここで問題です。
この「ボールジャグリング」、
A,ボールを投げる方
B,ボールを取る方
大事なのはどちらでしょうか。
正解は「A,ボールを投げる方」です。
ボールを取る方で頑張ったとしても、あらぬ方向にボールが飛んでいったらどうしようもないですよね。
だから「投げるとき、どこに戻ってくるのかコントロールすること」に集中するわけです。
もう一つ問題です。
A,ボールを手に持っている時間
B,ボールが宙に浮いている時間
どちらが長いでしょうか。
正解は「B,ボールが宙に浮いている時間」です。
ボールを持っている時間は一瞬です。
対して、ボールが宙に浮いている時間は長く、ボールの数が増えれば増えるほど長く（＝高く投げ上げることに）なります。
ボールを手に持つ技もありますが、それは一旦スルーします。
さらに、最後の問題です。
基本的に1つの手に何個ボールを持ってるでしょうか。
正解は「1個」です。
どんなにボールが増えても、1つの手には1個しかボールを持ちません。
手からしてみれば完全なシングルタスクです。
もちろんこちらも、ボールを複数個手に持つ技もありますが、それは一旦スルーします。
ジャグリング方法論
つまり、多くの問い合わせ（ボール）を持つには、
自分が問い合わせを持っている時間を最大限短くして、実質的なシングルタスクを維持し続ける
ということが重要になります。
そして、そうなるようにコントロールするということです。
問い合わせをジャグリングする方法
要素は大きく4つあります。
- 質問を投げるとき、返答をコントロールする
- 返答されてから調査するのではなく、待つ間に予想される返答の答えを用意しておく
- 予想外の返答をされた場合に備えておく
- 問い合わせ（ボール）が増えたら、1回あたりの情報量を上げる（高く投げ上げる）
返答のコントロール
質問はすべてクローズドクエスチョンに限定します。
「YES/NO」だけでなく「ここの表示はXですか？ Yですか？」
のような選択肢でも構いません。
また、調査に必要なログを求めることも該当します。
しかし、明示的にしなければなりません。
「Aのログをください。hogehogeから取得できます」
「15日～20日の間に出力されたBのログをすべてください」
といった感じです。
答えを準備する
クローズドクエスチョンで質問することによって、
その後にこちら側で取るべき行動が予測できます。
「表示がXなら問題なし。Yならログが必要」
と考えることができます。
そして「返答次第ではログ取得の再依頼が必要だ」となるのであれば
返答のコントロールの準備までしておきます。
「ログの正確なファイル名は何か」
「どこで取得できるか」
「対象の日付や時刻は何か」
といった準備をしておきます。
ログの取得を求めたのであれば、
「ログから何を探せばよいか」
「確認した結果、次に発生する行動は何か」
「それぞれの行動についての準備」
……と、準備を先にしておくわけです。
極論、
- 答えがXだった時の返信文
- 答えがYだった時の返信文
を全部作っておき、答えを見た瞬間投げ返せるレベルに準備できればよいのです。
そうすることで、スイッチングコストは低減されます。
想定外に備える
クローズドクエスチョンを投げ、その通りに返信されることは、9割程度だと考えてください。
今までの2つは、その9割の速度を上げる準備です。
「違うログを送ってきた」
「見ているところが違った」
などは往々にしてあります。
こういったパターンは、クローズドクエスチョンでの指定の仕方が悪かったり、改良点があることを表します。
ジャグリング的に言えば「投げ方が悪かった」パターンです。
説明の精度を上げていきましょう。
何度も準備をしていれば、過去の指定の使いまわしをすることで、
精度の向上と準備時間の短縮にもつながります。
問題は、
「取得を依頼したがログが無い」
「表示がXかYか聞いたらZだった」
といったパターンです。
ジャグリング的に言えば「風が吹いた」「太陽が眩しい」「足攣った」です。
この1割は、即時返せるように準備する必要はそこまでありませんが、身構えておきます。
「表示がXの時とYの時の準備はした。稀にZの時もあるんだ、へぇ～」
「ログ取得依頼したらなかった時あったんだ、へぇ～」
と、クローズドクエスチョン外のパターンの存在を知っておくだけでよいのです。
知っているだけでも、初動の速度は違いますし、知らないことによるパニックもありません。
他の問い合わせをコントロールするのは、こういったボールをリカバリーするためでもあります。
情報量を上げる
問い合わせ（ボール）が増えたら、返答の準備をしているうちに、他の問い合わせ（ボール）が返ってきます。
1つくらいなら大丈夫ですが、追い付かなくなってきた場合は、時間がかかるように（高く投げ上げられるように）します。
つまり、1手先、2手先を見据えた質問をして、1往復の情報量を増やします。
先ほどの例で行くと、
「ここの表示はXですか？ Yですか？」
「表示がXなら問題なし。Yならログが必要」
「必要なログはAのログで、hogehogeにある」
あたりの手順を一度にまとめてしまい、
「ここの表示はXですか？ Yですか？ また、Aのログをください。hogehogeにあります」
としてしまいます。
すると、返答までの時間が「表示の確認+ログの取得」となり、少し伸びます。
しかし、これはあまり多様してはいけません。
忙しい時の奥の手です。
なぜならば、
・情報量を増やすと受け取る側も負担になる
・やることが増えると、受け取る側の取りこぼしが増える
・不要になってしまう操作が発生する可能性がある
・たくさん処理を投げたが初めの一歩目から想定外のパターンがある
つまり高く投げ上げすぎると、想定外の可能性が高まります。
だから多様しない、最終手段に近いです。
さいごに
問い合わせは、どうしても後回しにしてしまいがちですが、
前のめりにしていくことで、その姿勢も矯正していけます。
経験豊富なメンバーだけが使える手ではなく、
経験の浅いメンバーでも、先行して動くことで、
全体のタイムを短縮することができます。
圧倒的な速度で問い合わせを解決していけば、
それだけでも周りから一目置かれるでしょう。