「問い合わせはトラブルか？」という議論
問題。
あなたはとある開発部のプログラマーです。
とある顧客企業の総務部から、こんな問い合わせがあったとします。
「自分の個人情報が上手く表示されないと訴える社員Ａから、『設定ミスだと思うので修正してほしい』との問い合わせを受けています。ですが調べてもそんなミスは見当たりません」
登場人物は全部で３人。
あなた、総務部の人、社員Ａ。
調べたところ、社員Ａの画面に情報が上手く表示されなかったのは、一時的なネットワークトラブルだったことが分かりました。
さて、今回のトラブルで一番の問題点はなんでしょうか――？
いつもお読みいただきありがとうございます。
または初めての方も、この記事を見つけてくださって嬉しいです。
私は日本産まれの日本育ち、日本で日本国内向けのシステムの開発をしております、ブラジル人顔エンジニアの中島と申します。
この 絶対バグらないシステム作ろうぜの会 では、バグの出ないシステム・問題を起こさないチーム運営・ＡＩには作れない設計論などのコラムを、なるだけ面白く・分かりやすくお伝えする主旨で記事を配信しております。
1. トラブルの内容は立場によって変わる
冒頭のトラブルは、『営業系の人には当たり前のことなのに、エンジニアが意外と理解してくれなくて困惑する』という状況が生まれがちな例として出したものです。
時系列で整理するとこんな感じ。
1. 社員Ａのパソコンに、個人情報が上手く表示されなかった
2. 社員Ａは設定ミスだと考え、総務部へ修正を依頼した
3. 総務部の人が確認したところ、そのようなミスは見当たらなかった
4. 総務部の人は、あなたへ通報した
5. あなたが調べた結果、原因は一時的なネットワークトラブルだった
“トラブルシュートの専門家じゃないのに、トラブル対応させられがちな人” ほど、こういうのを「一時的なもので自然回復するので対応不要」としてしまいがちです。
と、このような書き方をすると、並行して営業系の業務もやっている人なんかは驚かれるのではないでしょうか。
今回のトラブルの最大の問題点は、実際にネットワークにトラブルがあったのにエンジニアが問題なしと判断していること
――ではありません。
ネットワークというシステムはときに不通になるものであって、それ自体は避けることができません。
不通の起こらないネットワークを作るとは、つまり「世界中の道路を壊れなくする」と言ってるのと同じで、そんなことは純粋に不可能です。
ですが、それ以外でもう１つ問題が有ります。
『トラブルとしては軽微なのに問い合わせが生まれていること』です。
お客さんとのコミュニケーションが第一の営業マンにとっては、問い合わせが発生すること自体がトラブルといえるからです。
ですが一部のエンジニアには、そういう感覚はありません。
とりわけ、製造担当者なのに、長年にわたってトラブル対応を意図せず押しつけられてきた人。
中でも、そのような状態が若いときから常態化していた人にとっては、
トラブルは急に降って湧いて当たり前
対応して当たり前
対応できるのも当たり前
それくらいが一般的な感覚だ、と感じる人も多いです。
このような系統の人は、若いときから問い合わせを防ぐために血のにじむような努力をしてきたが無駄だった、という経験を持っているため、もはや問い合わせを防ぐべきものとは考えていません。
そんな努力はやるだけ無駄だからです。
そういう系統の人は、「このインターフェースだと分かりづらくて問い合わせを生むから修正してほしい」という要望もピンときません。
問い合わせを防ぐべきものだと思っていないからです。
「どうやったって問い合わせはどうせ出るでしょ？ じゃあ分かりやすくする努力なんて無駄じゃん」と思ってしまうんです。
2. ルーチンに組み込めない仕事は“やって当たり前”ではない
では、そのような人が、問い合わせはトラブルの一種だと気づくためには、どのように考えればいいのでしょうか。
それは、業務が正常に回るかどうかで判断することです。
企業とは、全ての従業員がルーチン化された業務を日々こなすことにより、売り上げをあげるシステムのことをいいます。
ですが、長年同じ仕事をしているとどうしても突発的な業務というのは発生するもので、それはしょうがありません。
もちろん “しょうがないこと” ではあれど、だからって “やって当たり前” ってわけでもありません。
問い合わせ対応は、可能な範囲で防ぐべきトラブルの一種と捉えると、仕事がスムーズになります。
なぜなら、問い合わせ対応はいつ発生するか予測ができないゆえに、基本的に日々のルーチンに組み込むことができないからです。
エンジニアに限らず、“なぜかルーチン化できない突発的な業務ばかりやってる人” というのはどこにでもいますが、そのような仕事の仕方は絶対に健全ではありません。
世の中なんでも完璧は不可能ではあるものの、社会人にとって完璧な仕事とは、ルーチンワークのみで日々の業務が完結している状態のことです。
ですからルーチンに組み込めない業務は、全てトラブルの扱いにした方がいいし、問い合わせ対応はあらかじめ防ぐことができるなら防いだ方がいいのです。
最終的には、そうした方が絶対に楽です。
これは問い合わせ対応に限った話ではありません。
その仕事がルーチン化できないのであれば、それはやって当たり前ではないということです。
3. ルーチン化できる仕事とできない仕事を区別する
とりわけプログラマーは、自分の仕事の全体像をルーチン化するのが難しい仕事です。
なぜなら、職業プログラマーの作るプログラムは常に必ず “誰かのため” であって、従って全てのプログラマーの仕事には『その人の望みを理解する』という過程が含まれてくるからです。
とりわけＳＥＳ事業に属する人などは、顧客の業務内容をプロレベルで学習する必要だってあるかもしれません。
「そんなのどう考えても通常業務の範囲じゃない」と思いたいのが人情でしょう。
ですが残念ながら、プログラマーにとって『顧客を理解する』というプロセスはルーチンワークの範囲内です。
このことは、ゲームビジネスで考えると分かりやすくなります。
プレーヤーが望んでいるものを理解せずして、面白いゲームを作ることができるだろうか？ ってことです。
ゆえに、プログラマーの一般的なルーチンワークはこうなります。
1. 顧客のやりたいことを理解する
2. そのために顧客のことを理解する
3. そのために顧客がやろうとしていることを理解する
4. そのために必要なものを設計する
5. 設計したものを作る
6. 利用状況を調査して改善する
実に半分が『顧客を理解する』プロセスです。
理解の仕方や、理解するためにやるべきことは毎回違っても、『理解する』というプロセスは毎回同じ。
むしろ顧客を理解した段階で仕事の半分が終わる、くらいの勢いです。
対して、問い合わせ対応を「防ぐべきことだ」と理解できていない人のルーチンワークはこう。
1. 顧客が必要だと言ってることを理解する
2. そのために必要なものを設計する
3. 設計したものを作る
4. 作った製品の不満点を聞きだす、作り直す
あらかじめ顧客を理解する工程がばっさりとなく、不満点を聞き出して作り直す部分があらかじめルーチンワークに含まれています。
それゆえに、問い合わせ対応を防ぐべきトラブルだと、捉えることが難しくなってしまいます。
なぜなら顧客の不満点を調査する方法としては、『顧客が問い合わせてくるのを待つ』のが一番簡単だからです。
ただそのやり方だと、一時的に “評判が地に落ちる” ことを避けられません。
自分達のシステムの評判をいったん地に落とし、そこから五里霧中で再起していくのは青春ストーリーとしては美しいかもしれませんが、事業としてはどう考えても効率的ではありません。
ですので、防げるトラブルは予め防いだ方がいいのです。
そしてそのために問い合わせというルーチン化できない業務は、やって当然のことではなく《トラブルの一種》と捉えた方がいいんじゃないかなと、私なんかは思うわけです。
ではまた。
この記事が気に入ったらサポートをしてみませんか？