サポートエンジニアが読む「医療とコミュニケーションについて」

「レジデント初期研修用資料 医療とコミュニケーションについて」を読みました。これは、内科医である筆者が視点を医療現場に置きつつ、普遍的なコミュニケーションの技術を紹介する一冊です。

レジデント初期研修用資料 医療とコミュニケーションについて

普段、ソフトウェアのプロダクトサポートを生業としている自分にとって、顧客とのコミュニケーションは避けて通れません。顧客が報告してくる問題をいち早く解決するのは当然の業務ですが、その過程におけるコミュニケーションのあり方についても常に向上させる必要があるのです。特に、サポート契約を継続してもらうことで大半の利益を得ているサブスクリプションビジネスにおいて、問題に遭遇した顧客に、満足したと思える体験を提供するのは至上命題ですが、難しいのも事実です。なぜなら、サポートエンジニアは問題を解決して当然、と思われるのが常からです。

本書で取り上げられる、内科医として患者とどうコミュニケーションすべきか、という技術は私たちのコミュニケーションのあり方に適用できる点が多々あると感じました。特に早急な復旧が望まれるケースでは、文面ではなくテレカンなどで直接会話しながらの問題解決を望まれるので、病状を訴えて来院する患者の対応と通づる点が多いのでしょう。

本書では、まずコミュニケーションの定義から始まります。それは端的に

「状況のコントロール」を達成するための技術

とされています。さらにそれは2つに分解され、

- 事実に対して自分の見解を持つこと
- 事実の改変を防ぐこと

となります。ソフトウェアサポートにおける事実とは、障害の内容、取得できているログやメトリクス、これまでに実施した作業、プロダクトのソースコード、などが考えられます。その中でもログは1秒あたり数十から百行以上の出力があるようなケースも珍しくないため、さらに掘り下げて事実として共有する必要があるでしょう。例えば、あるメッセージの出力傾向・頻度であったり、特定のスタックトレースだけ抽出して共有します。これらを基に、なぜそこに着目したのか（障害発生時刻と合致するから、など）説明した上で自身の見解を示します。

一般に、ソフトウェアのトラブルシューティングで共有される事実はテキスト情報として残りますので、事実の改変は起こりにくいでしょう（技術的に改変は容易ですが、お互いに同じデータを持っているので改変するモチベーションがない）。ただし、新しい事実が付け加えられるケースはままあります。その場合は、共有した新事実を基にした新たな見解の提示、というステップを繰り返す他にありません。

さて、コミュニケーションの定義を確認すると、本書は来院する患者と対面するところから始まります。

挨拶をする

挨拶というものは、「これから会話を始めます」という宣言であるのと同時に、拒否することが難しい、最も小さな「関係」でもある

特に海外の方が相手だと、名前の読み方がわからないケースは多々あります。これから障害の調査をするのにのんびりと挨拶して雑談する必要はないのですが、名前を聞くのは会話の始まりが一番ハードルが低く、聞き返すことも可能です。相手の名前を発音できるようにしておく、というのは意外と重要です。自分は自分で、相手が発音しやすい名前だと相手も覚えやすいので得かもしれません。意外とこういうことが貴重な経験だったりするのです。

また、私は相手の住む地域や現在時刻を聞くことにしています。地域や時刻がわかれば、相手が1日の生活のうちのどういうフェーズにいるのかがお互いにイメージしやすく、会話のネタになります。夕食前か、子供を寝かしつけた後なのか、はたまたメンテの担当者で夜通し作業しているのか、どの時間帯を過ごしているのかによって、会話内容も変わってきます。

待つことは難しい

外傷治療の急性期には、輸液を入れて、落ち着くまで「待つ」期間が発生することがある。（略）「待つ」ことにだって意味はあるのだけれど、外からだと、状況は止まっているように見えてしまう。（略）「今はこういう状況であると考えています。こうなっていく可能性があり、それに対してこれから対処を開始します」という見解は、状況が悪いときほど大切なものになる。

これはソフトウェアのトラブルシューティングでも大いに当てはまるでしょう。例えば、一見処理がスタックしているように見えても、内部的には進んでいるケースは往々にしてあるからです。つい先日も、あるプロセスの起動時の初期化処理がいつまでたっても終わらず、顧客のイライラが募るばかり、というケースがありました。しかし、プロセスのダンプとソースコードを確認すると、実際に処理は進んでいたのです。そんなとき我々にできるのは、その処理を高速化する手立てはないのか、ないのであれば、なぜそんなことが起きているのか、をできるだけ早く突き止めて説明すること、でした。

一貫性に注意する

ある成功したケースにおいて何らかの「一貫性」が見出されたからといって、「一貫した基準に基づいて何かを判断すべきではない」という話です。むしろ現場というのは

- 状況は見えないし、
- あらゆる判断は不十分な情報に基づいて、場当たり的に下されるし、
- むしろ系の中からは「絶対的な正しさ」なんか判断できない

ものだからです。だからこそ

- 自分の正しさを信じるべきではないし、
- 手元に集まる情報が不十分なときには、「どちらに転んでも大丈夫な」ように

一歩一歩探り続けて行くしかありません。ソフトウェアの世界でも、特に問題のあるシステムを直接見ながらトラブルシューティングするようなケースでは似たような状況となります。ただ、情報が不十分な状況で判断を下さなければならないケースがあれば、次回はより情報を取得できるよう、ソフトウェアそのものや調査のプロセスを改良することが可能です。そのためにはポストモーテムと、サポート&開発チームの密な連携は不可欠でしょう。第7章「ミスを素早く発見する」の一節でした。

謝罪は単なる道具

「謝罪というのは弱さの現れ」であるという文化はやめたほうがいい。「謝れる人は強い」という意見も同じぐらいに有害で、謝罪は手段であって、手段は中立でないといけない。（略）道具としての謝罪を使っていく上では、相手に怒られた状況というものを、「相手の勘違い」などではなく、常に「こちらからの配慮不足」であると考えないといけない。

これは第9章で出て来る話なのですが、ここまで読み進めて、あらためてこの本が「状況をコントロールする」ことに常に焦点をあわせているのだと再認識します。デバッグも謝罪も道具、すなわち「状況をコントロールする」ための技術であるということに尽きるのです。

このように、コミュニケーションの開始の合図である挨拶に始まり、本書は細かいコミュニケーションのテクニックをひとつずつ丁寧に紹介していきます。全ては「状況をコントロールする」ためです。診察に訪れる患者がそうであるように、障害に遭遇しているユーザーはセンシティブで疑心暗鬼なのです。

ここで紹介したのは本書の本当に一部に過ぎません。全部紹介したいところなのですが、読みながら付箋を貼っていたトピックを羅列するにとどめたいと思います。何らかの形で顧客対応をされている方であれば、本書に目を通してみたくなるのではないでしょうか。オーム社のサイトからであれば、PDFでも買えるみたいです。

https://www.ohmsha.co.jp/book/9784274068362/

p.13 面白い話はしなくていい
p.18 便利ともてなしとは違う
p.21 待つことは難しい
p.27 歩んで寄って見せること
p.48 ねじれの位置を保つ
p.51 判断の所在を明らかにする
p.52 時計の話をする
p.76 仮想のものさしは危険
p.79 目線の時代の会話作法
p.88 ミスを減らすためのチームと機械
p.107 予感で事故を回避する
p.109 一貫性というものに注意する
p.112 何もしないこと を決断するとき
p.117 ボスに従おう症候群
p.120 柔らかくもつことに意味がある
p.130 礼儀正しさには交差が必要
p.131 カードを切る前に考えること
p.134 接遇の本当の意味を理解する
p.137 謝罪は単なる道具
p.146 謝罪にうまさはいらない
p.153 常に見解を持つ
p.154 憶測は危険