ある事象を通じて、エンジニアのどのようなプレゼンテーションが「伝わらないのか」を体感する機会がありました。
そのとき、澤が「聴く側」として感じたことをご紹介します。
超高速光ファイバーサービスに変えようと決心
お久しぶりです、澤です。
今回は、澤の経験談を皆さんと共有したいと思います。
私の家の光インターネットは最高速度100Mbpsという契約なのですが、夜間だと下手すると350Kbpsとかまで速度が低下していました。
ISDNかよっ!とか思いながらのろーいネットに接続していました。これがどれだけストレスを感じるかは、リクナビNEXTジャーナルの読者の方なら心の底からご理解いただけるのではないかと思います。
どうにかならんかなぁ。……ずっと思っていたのですが、と知人のSNSの投稿に「最大2Gbpsの超高速光ファイバーサービスに変えたらすごく快適になった」というコメントを発見し、「これだっ!」と思いました。手続きも簡単そうだし、すぐに連絡してみることに。
Webから手続きしようとすると、「接続可能かどうか」の確認をするための機能があります。そこで自分の住所を入力すると、マンション名まで含めて「設置可能」との表示が。これはうれしい!明るい未来が待っている!と興奮しまくりました。
ざっくりした番地とかではなく、マンション名まで表示されてOKといわれると、これは実に嬉しいですね。
人を介さずとも、個別に情報を表示すると、人はそれを「自分事」と受け取ることができ、信頼を高めることができます。UIデザインの参考にはなります。
Webでの申し込みののち、いくつか確認事項があったので、オペレーターと電話でお話をしました。
工事は宅内だけで済むこと、こちらは特に準備しなくてはならないものはない旨、説明を受けました。とんとん拍子で手続きを進めていって工事日も決定し、わくわくしながらその日を待ちました。
この家に機器の設置はできません
いよいよ工事当日。いかにも実直そうな工事担当者の方が来訪され、早速宅内の配線を見ます。そのあとで、「これは管理人室の配線板を見なくちゃいけませんね」と言うのです。
時間は、土曜昼の11時45分。我が家のマンションの管理人さんは12時までの勤務。もしこれが12時を過ぎていたら…日曜だったら…と少々焦ったものの、まぁ管理人さんはまだいるし、よいことにしよう、と気を取り直して管理人室へ。
管理人さんは親しいので、「配線板見せてくださーい」と言ったら「どうぞどうぞ」と気楽に受け入れてくれます。
そして、工事担当者が配線板を開いてしばらく眺めた後、ひと言。
「あ、これは機器の設置はできません」
──ん?なんですと?
「いや、この配線板の中には機器を入れるスペースがないので、導入できません」
──えーっと、そもそもそういう確認事項はなかったし、家の中の配線だけで済むという説明を受けたんだけど。
「ともかく、無理です。できません」
──このマンションは導入OK、工事は自宅内だけで済む、そのような説明をうけて今回申し込んだんだけど。
このあたりで、工事担当者はヤバイことになっていることに気づき、汗をだらだらと流してめちゃめちゃどもりながら必死の説明を始めます。
専門用語と技術の説明を延々と続ける担当者
「この配電盤はxxxxという作りになっていて、xxxxという回線の形式がxxxxにつながっていてxxxxをxxxxすればxxxxになるのですが、このマンションの形式がxxxxなので、こ接続できるようにするためには道路を掘り返して」
と、専門用語を豊富に交えながら、できない理由をかたっぱしから挙げていきます。
その話を聞いていると、その人がかなり回線については詳しいことはわかりました。(工事のプロなんだから当たり前なんですが)
ただ、私がほしい情報は、かけらも含まれていません。配電盤の形にも、配線の方法にも興味はありません。
私がほしい情報は、
「この接続ができるのかできないのか」
「できないのであれば、代替案はあるのかどうか」
この二つに集約されます。
でも、そんな話は1ミリも出てくることはなく、できない理由を技術的観点から必死に話をする姿を見続けることになりました。
これ、もしかしたらあらゆるエンジニアに起こりうる状況だよな~と思って観察していました。
営業現場でどのような会話がなされたのか、エンジニアはすべて把握しているわけではなく、顧客の期待値を知らない状態で現場に投入されたりします。
仕様通りに動いてくれればそれほど大きな問題にはならないのですが、パフォーマンスが出ないとか、デザインがイメージと違うとか、コストが妙に高すぎるとか、そんなトラブルが発生するのは日常茶飯事でしょう。
その時、現場のエンジニアは何を語るのか。
依頼主に対して、技術的に「できない理由」を説明しても、あまり意味はないことが多いのではないでしょうか。
本来、彼らが知りたいのは「なぜ動かないのか」「なぜできないのか」ではなく、「どうすれば改善されるのか」「どうやれば仕様通りに動くのか」なのです。
(トラブルに直面すると、相手は「なんでできないんだ!」ってよく言いますけど、それって感情的な発言でしかなくて、本質的な質問ではないんですよね)
そんなことを思いながら、ひとつ疑問がわいてきました。
「もしかして、この人は注文を受け付けるコールセンターでの説明を知らないのではないか?」と。
ということで、私はコールセンターに電話して、スピーカーホンで音を出して工事担当者に聞かせながら会話をしました。
──私がWebで調べて、自分のマンションが設置可能ってなっていたので申し込んだのですが?
「そちらは外部から確認される情報だけで判断されるものであって、建物内で接続できるかどうかまでの確認はしていません」
──宅内での工事のみでできるという話だったのですが?
「それは実際に見てみないとわからないことなので」
──マンション名まで含めて「設置可能」とまで表示しておいて、接続ができないリスクがあるのであれば、最初の電話の時に説明してもよかったのでは?
「…おっしゃる通りです」
かくして、現場に出ている人は営業フェーズで「考えられるリスク」が顧客に説明されていなかったことを知ることとなったのでした。
エンジニアは「備える」必要がある
結局、どうやっても設置不可ということになったので、しょんぼりしてTwitterでつぶやいたところ、知り合いの中の人から連絡があり、代替案を示してもらうことができました。それは、プロバイダを変える必要もなく、自宅のルーターを変えるだけで実現できるものでした。
最初からそうしておけばよかったのですが、「そうすればスピードが上がる」という情報は、残念ながら簡単にリーチできるところにはありませんでした。(少なくとも、私から見るとかなりの想像力を要するものでした)
つまり、答えはプロバイダの中にあったはずなんですね。にもかかわらず、それが提示されたのは外から。
これは会社にありがちな話ですね。いわゆる縦割りというやつです。
犠牲者になるのは、いつも顧客です。ま、顧客は自由なのでほかのプロバイダに移ればいいだけの話ですから、最終的にはそのツケはサービス提供者側に跳ね返ってくることになります。
そして、一番最前線に出ているエンジニアは現場で顧客から怒られ、結果的に契約破棄になったりすると上司や経営層から怒られたりします。
そんなの嫌ですよね。少なくとも私は嫌だ。
ではどうすればいいか。エンジニアは「備える」必要があるのです。
何を備えるのか。「相手の期待に応えられなかった場合、相談相手になれるような準備をしておく」のです。
- 納品したシステムが動かなかった場合の代替案
- 会社の中にあるサポート体制の確認
- 同様の機能を提供できるサービスの有無
- ここぞという時に頼りになるスーパーエンジニア
あらかじめ調べれば分かることはいくらでもあるはずなのです。
もし、うちに来た工事担当者が、「このサービスではできないけど、弊社の別のサービスで速度が上がる可能性ありますよ」という情報を提供していたら、まったく違う印象を持つことになったでしょうし、問い合わせもはるかに効率的にすることができたと思います。
エンジニアは、何かを生み出すことが一番の仕事ではありますが、ビジネスの世界においては「顧客にとってのパートナーになる」ことも併せて目指すことが求められる時代になりました。
単純なコーディングはどんどん自動化が進むでしょうし、結果的にエンジニアの単価も抑えられていくことになります。
エンジニアとして生き残るためには、他者に対して貢献できることが必要です。そのためには、「相手に役に立つ情報が提供できるかどうか」がポイントになります。
すべての会話はプレゼンテーション。常にプレゼンができる状態を作っておくことをお勧めします。難しいことはありません。
自分が今いるチームや組織、会社のことをもっと知りましょう。自分の担当している技術領域の他社事例やライバル企業の動向を知りましょう。
そして、知ったことは、あらゆる手段でアウトプットしていきましょう。結果的に、皆さんはエンジニアとしてより一層大きな成功ができることになると思います。
著者プロフィール
澤 円(さわ まどか)氏
大手外資系IT企業 テクノロジーセンター センター長。立教大学経済学部卒。生命保険のIT子会社勤務を経て、1997年より、現職。情報共有系コンサルタントを経てプリセールスSEへ。競合対策専門営業チームマネージャ、ポータル&コラボレーショングループマネージャ、クラウドプラットフォーム営業本部本部長などを歴任。著書に「外資系エリートのシンプルな伝え方」「マイクロソフト伝説マネジャーの世界No.1プレゼン術」
Twitter:@madoka510
※本記事は「CodeIQ MAGAZINE」掲載の記事を転載しております。