SEのための、お客さんから素早くメールを返していただく方法
»
弊社の場合、システムエンジニア（ＳＥ）が営業を兼ねているのですが、これはいいところもあり、悪いところもあります。
もっと大きな会社でＳＥと営業が分離している場合、ＳＥはどんなぶっきらぼうで堅物であっても、営業の人がうまくフォローしてくれるかも知れません。
「もっ、、うしわけございません！」
「うちの技術者みんなこんな言い方しかできないんでー」
「あとできっちりシメときますわ。一応彼、私の上司なんですけどねｗｗｗ」
みたいに。
しかし、技術者たるＳＥが営業を兼ねていると、一人の人間でデジタル思考をしながら柔らかくお客さんと接しなくてはならず、これはなかなか難しいものです。
特に大手のSIerから弊社に転職してきたＳＥの場合、まず最初にぶつかる壁がここです。
「お客さんにただ聞きたいことを聞いただけなのに、何日経っても返事が来ない」
こんなことがよく起きます。
今回は、システムエンジニアがお客さんにメールで書いた質問になるべく素早く返事をいただく方法をまとめてみます。
■タイトルで脅迫しない
システムの要件や仕様の確認メールとなると、内容はただでさえ面白いものではありません。
それが
【要返信】システム要件の確認(状態遷移について)
こんなタイトルがついていると、まるで脅迫されているようです。
【要返信】などはつけようがつけまいが、たいていの人は返信の必要性を感じれば返事をします。むしろ取ってしまったほうが開封確率が上がります。
「要件」という言葉も一般的ではないです。「状態遷移」については意味はなんとなくわかっても、どんな話なのかさっぱりわかりません。
「おい、大事だから早く読めよ！ただお前にはこれから言うことは意味がわからないと思うがな」
タイトル部分でこんな気の滅入るメッセージを送ってしまっているのです。これだと、まず未読状態のまま3日は放置されるでしょう。
■長文を避ける
長文メールは厳禁です。どんなにすべてのセンテンスに意味があっても、たとえば3000文字以上になるようだと、もはやメールでやり取りするレベルの内容ではないでしょう。
それであれば、つなぎの言葉は一切排除して、箇条書きかエクセルにまとめて、時間を決めて電話をかけ、１つずつ口頭で確認していくべきです。
長文メールは見た瞬間に読む気をなくします。
同様に、「メールを読む端末環境は人それぞれ」ということで、改行を入れなかったり、空白行を入れない人もいますが、これも読み手にとってはかなりのストレスです。
本当の正解がどこにあるかはわかりませんが、それよりも、多くの人がやっている方法に習った方がよいです。
■多重分岐を避ける
これは意外と多くの人がやってしまうことですが、これが長文メールを作る原因にもなっています。
たとえばこんなメールです。
○○は△△がご希望ということでよろしいでしょうか？
△△の場合、コストが10％ほどアップします。
もしご予算に余裕があるようでしたら、こちらをお勧めします。
ご予算を絞りたい場合は××という案もございます。
ただし××の場合は、□□というデメリットがあります。
□□でも構わないという場合は、、
このように、下手な手続き型プログラムのような多重分岐は、読み手にとって相当の苦痛です。
なぜなら、自分にあてはまらない条件部分はすべて無駄な情報だからです。
電話か対面の打ち合わせの場を持ちましょう。
■中途半端な主張を書かない
ある小さな機能について、お客さん側は「当初から言ってあったのでやってほしい」と言っている。
こちらはそんな話は聞いてないと思う。
（まあ、でもたいした作業でもないしやっておくか...）
こういうシチュエーションは1プロジェクトで10回から100回くらいあるものです。
こういうときに「こちらはお聞きしていなかったと思うのですが、、、（やっておきます。）」などという主張は書くべきではありません。
もし、このような「聞いてない要望」が際限なく繰り返されるようなことがあれば、一度はっきりと伝える機会を持つべきかも知れませんが、細かいやりとりの中で言ったところでほとんどメリットがないです。
「こちらは聞いてない」と書いてあればお客さんの方もそれを見過ごすことができず、どうしても反論せざるを得なくなります。
「ちっ、言っただろ。えーと、あれいつだっけなー...。」
とか
「言ってないのはわかってて言ってるんだよ。CCに上司も入ってるし、めんどくさいな...。」
などとなって返信が遅れます。
■用件毎にメールを分ける
前述の「長文を避ける」の対策的なことですが、メールの用件ごとにメールを分けるというのは１つの方法です。
「新システムのご確認(ログインできるユーザー権限について)」
「新システムのご確認(ユーザー登録機能について)」
「新システムのご確認(ユーザーの削除について)」
こんな感じで一問一答できる分け方でメールを書くと、簡単なものから素早いレスが期待できます。
ただし、まあすぐに30通、100通になってしまうことは容易に想像できますし、お客さんの方は、1つのメールの返信でたくさんの内容を突っ込んでくることがあるので、なかなかうまくいきませんね。
もしリテラシーがある程度高いお客さんであれば、BackLogなどの無料のバグトラックツールを使うのは、かなりの正解です。
■フッターに連絡先を書く
これはメールマナーに近い話なのですが、メールのフッターに会社の電話番号を書いていない人がたまにいます。
お客さんがこちらからのメールを読んで、「あー、これ文章では説明しにくいな。電話で説明するか。」と思ったときに、電話番号が書いてない。
「なんだよー、、名刺、名刺と、、、おっと電話だ」
これでほぼ永遠に放置されます。
メールフッターが長すぎたりするのも嫌われますが、とりあえず連絡が取れる最低限の情報は載せましょう。それっぽっちのことで貴重なお電話をいただけるチャンスを逸してしまうのはもったいないことです。
■毎回確認用URLを張る
たとえば、デモサイトで進捗を報告し、それをもとに確認をしていただこうという際に
「先ほど、今日までの改修部分をいつものデモサイトにリリースしました。以下、疑問点を書きましたのでご確認ください。」
となっている惜しい感じのメールがよくあります。
「リリースしました」のその後に、
「デモサイト：http://demo.example.com/ (基本認証：test/test)」
くらいの内容はぺたっと貼っておきましょう。
開発側がリンクを張るのは10秒ですが、お客さんが「はてさて、いつものデモサイトってどこだっけな？ユーザー名パスワードってなんだっけ？」となると数日放置というのはよくあることです。
■基本認証は覚えられるくらい簡単なものにする
確認用の基本認証については、通常の場合は誰かに偶然見られたり検索ロボットに収集されることが無いように、という意味ですから、簡単なものにすべきです。簡単とは、頭で覚えられるレベルというものです。
もちろん、その基本認証を第三者に破られると、個人情報がずらりと並ぶような社内利用を想定したシステムは、この限りではないです。まあ、そういうのは複雑なパスワードにしたところで、暗号化されてない時点でアウトなんですが。
要はセキュリティとお客さんにいち早く確認していただけるぎりぎりを考えるのがＳＥの腕の見せ所です。
いろいろ挙げてきましたが、実際にはきっともっとあるでしょう。つまるところ、お客さんが日々の本業の忙しさの中で
- メールを開封して
- 内容を読んで
- 理解して
- 確認して
- 回答を返す
という一連の作業で、何か障害になりそうなところをすべて取り去っていくことが、お客さんから素早くメールを返していただくためのコツなのです。
株式会社plumsa(プラムザ)では、AWSの監視サービスも提供しています↓