＃6 ドキュメントを用意しない
整理されており、明解でわかりやすい指示をユーザーに提供できないと、コミュニケーションをうまく図れない一因となる。われわれの仕事では、新しい手順書、会社のコンピュータ利用ポリシーの説明書、新入社員向けのマニュアルなど、さまざまな局面でユーザーが読みやすいドキュメントを用意する必要がある。新しいドキュメントを作成したら、実際に配布する前に、数人のユーザーに査読してもらうとよい。よく書けたドキュメントは、よく整理され最新の情報が反映されているので、結局はこちらの時間節約にもなる。良いドキュメントは、ユーザーにとって、問題が起こったときに自分で解決するための拠り所になるからだ。
＃7 嘘をつく
骨の折れる、または退屈な仕事の依頼を受けたとき、どのように対応すべきだろうか。質問を受けたが答えがわからないときはどうだろう。また、質問の答えが、ユーザーにとって不愉快なもの、耳の痛いものになる場合はどうすればよいだろう。このような場合は、思わず事実を曲げて、うそをつきたくなる。うそをついても、何も害がなく、相手にわかる可能性も低い場合はなおさらだ。ユーザーにうそをつくことが許されるケースはあるのだろうか。
ユーザーが理解できるように事実を単純化して伝えなければならない場合はあるが、それは、面倒を避けたり面目を保ったりするために故意につくうそとは違う。昔、こんなことがあった。当時わたしは、先輩のサポート技術者に付いて仕事をしていたが、その先輩には、不具合があると何かにつけてマイクロソフトのせいにしてしまう悪い癖があった。ユーザーが質問してきたとき即座に答えられないと、彼は決まって、それはマイクロソフト側の問題だからどうしようもないと答えていた。しばらくすると、ユーザーは彼に聞きに来なくなってしまうのだが、彼は勘違いして、自分の仕事が素晴らしいからユーザーには何の問題も起こらないと自慢するようになった。この状況はIT部門の次の組織替えまで続いた。その組織替えで、彼は、コンピュータに精通しており、一目置かれることに慣れているユーザーを担当することになった。数週間後、彼は、解雇されてしまった。ユーザーから高度な内容の苦情が寄せられたこと、そして彼自身のスキルが低下していたことが原因だった。
要するに、ユーザーからの質問に答えられなかったら、理由はどうあれ、そのことを率直に認め、ユーザーといっしょになって他の解決方法を探すように努力することだ。自分が無知なだけ、あるいは解決する気力がないだけなのに、技術的に解決不能な問題として片付けてしまうようなことだけは絶対にしてはならない。
＃8 余計なことを言い過ぎる
正直は最善の策であることは確かだが、これは何も必要のないことまで説明してユーザーを混乱させてしまってよいという意味ではない。5人の男の子を育てた母親が自分の体験からこんなことを言っていた。「平均的な10代の若者は、どんな説教をしても最初に言われた3つの文しか覚えていない。だから、最初に言う3つの文は慎重に言葉を選んだほうがよい」と。ユーザーを10代の若者と比較するのは適切ではないかもしれないが、サポートがユーザーに対するときの方針も基本的にはこれと同じである。つまり、必要最小限のことだけを話し、一度に多くのことを伝えようとしないことだ。
コミュニケーションにおいても、まさに過ぎたるは及ばざるがごとしである。報告の頻度が多すぎても、内容が詳し過ぎてもいけない。ユーザーの環境にわずかでも変更があるたびにその旨を全社員にメールで通知していたら、ほとんどの社員はメールを無視するようになってしまう。ほどなく、IT部門からのメッセージを削除する受信ルールを設定してほしいという依頼がヘルプデスクに殺到するようになる。
アップグレード、ダウンタイム、その他の変更によって、最も大きな影響を受けるのはユーザーだ。だから、ユーザーに送るメールの数は普段から抑えるようにしなくてはならない。ユーザーが影響を被る時間が限られている場合（例えば、昼休みにメールサーバをリブートする場合など）には、メッセージに有効期限を設定しておくとよい。ユーザーが知る必要もない詳細な事項や説明で、ユーザーに余計な情報を与えて混乱させてはならない。例えば、業務時間帯にメールサーバを突然リブートする必要が生じた場合は、リブートする時刻、メールが使えなくなる時間、リブートが必要な理由、ユーザー側で行う必要がある作業を通知する。ユーザーはリブートが必要になる詳細な理由など知る必要はないが、発生した問題を一文にまとめて伝えておけば、緊急事態であることを理解してもらえるし、協力も要請しやすくなる。
＃9 トレーニングを行わない
トレーニングといっても、3日間教室の席に座って、PowerPointプレゼンテーションの作成方法を学習するといったものだけに限らない。サポート技術者によるトレーニングは、アドレス帳に連絡先を追加する方法を1人のユーザーに教えるほんの30秒ほどの簡単なデモで終わることもあれば、Crystal Reportsを使った数日間のレポート作成のための上級者向けハンズオンセミナーのように複雑なものもある。トレーニングを行うのは正式にはサポート技術者の仕事ではないが、ユーザーをトレーニングせずにサポートの仕事を効果的に遂行するのはほぼ不可能に近い。サポート技術者によってはユーザー教育を故意に避けている者もいる。ユーザーが知識をつけると、ネットワークの整合性が脅かされるし、サポートの仕事も面倒になると思っているからだ。こうした心配を単なる被害妄想として片づけるべきではないけれど、少なくとも、ユーザーのコンピュ―タ操作能力を向上させない正当な理由にはならない。
＃10 話を聞かない
コミュニケーションは双方向プロセスである。われわれは、サポート技術者として、ユーザーの話をきちんと聞く必要がある。名前のとおり、われわれの役目はユーザーをサポートすることとユーザーが自分の仕事をできるようにすることだが、それを行うには、ユーザーのニーズを十分に理解する必要がある。時間の許すかぎりユーザーの話を聞くことが結局は次善の策となる。サポート技術者がユーザーとともに時間を過ごすことでその日常業務を把握し、どこにテクノロジを適用すれば生産性または安全性を向上させることができるのかを検討するのである。
ユーザーからのフィードバックは、感想記入用紙、満足度調査、追跡電話調査などで得られる。昼食時に、気軽にユーザーの声を聞くこともできるだろう。ビジネスの観点から見ると、すべてのユーザーのリクエストを、IT業務と会社の一般業務を密に連携させる社全体の協力なしに実現するのは、おそらく不可能だろうし、望ましいことでもない。しかし、実際には、IT部門が自分の部署の事情を最優先し、肝心のユーザーをほとんど邪魔者扱いするといったことが行われがちである。
