SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 Summer レポート(AD)

なぜあなたの説明は伝わらないのか? エンジニアにこそ必要な「伝える技術」【デブサミ2022夏】

【D-5】エンドユーザー500人にシステムを説明したらわかった「伝え方の技術」

  • このエントリーをはてなブックマークに追加

 エンジニアにとって「コミュニケーション力=伝える技術」が重要であることは言うまでもない。顧客との直接的なやり取りにフォーカスされがちだが、当然ながら開発チーム内や他部署との連携などにも活かされるスキルだ。そうした営業職・マネジメント職だけでないエンジニアにこそ必要な「伝える技術」についてのあり方、鍛え方などについて、エンドユーザー500人に向けて行った説明会の体験を踏まえながら、株式会社テンダ エンタープライズ開発統括部 世良 謙治氏が紹介した。

  • このエントリーをはてなブックマークに追加
株式会社テンダ エンタープライズ開発統括部 世良謙治氏
株式会社テンダ エンタープライズ開発統括部 世良謙治氏

説明上手なエンジニアは「ターゲット」と「メッセージ」を意識している

 現在、テンダでWeb系エンジニアとして活躍する世良氏は、テンダに入社して初の案件であるショッピングモールのWebサイト改修を手がけた際に、顧客向けに管理システム(CMS)の説明会を実施したエピソードを冒頭で紹介。対象は数名程度と思っていたところ、午前と午後で80人ずつ、結局500人を超える老若男女に対して使い方の説明を行なうことになったという。「いきなりのことで緊張し、戸惑いも大きかった。しかし、さまざま背景・経歴を持つユーザーに直接接し、『使い方を伝えること』に携わったおかげで、伝える・説明することの大切さ、難しさを実感した」と世良氏は語る。

 それでは、実際どのように感じ、どのように伝え方を変えるようになったのか。世良氏は、まず「基礎編」として「説明上手なエンジニアになろう」という目標のもと、「ターゲット」と「メッセージ」を意識することの重要性を語った。例えば、ショッピングモールのWebサイトをリニューアルすることを説明しようとした場合、「経営陣・マネージャー」と「システム担当者」、「ショップ店員」に同じように説明してもなかなか理解は難しいだろう。そこで、説明時には、それぞれの目的や解決策に応じたメッセージを考え、それをどう伝えるかを考えるというわけだ。そう考えると、例えば次のように想定できる。

図1:「ターゲット」と「メッセージ」の例
図1:「ターゲット」の例

①経営陣・マネージャー

  • 目的:収益をアップさせたい
  • 解決策:Webサイトをリニューアルすることで販売促進につなげる

 メッセージ:「Webサイトをリニューアルすることで、ショップの魅力を効果的に伝えることができ、販売促進効果が期待できます」

②システム担当者

  • 目的:販売促進させたい+運用コストも減らしたい
  • 解決策:Webサイトと同時にコンテンツ管理システムも改修する

 メッセージ:「Webサイトリニューアルに加え、コンテンツ管理システムを改修することで、ショップ店員の負担を減らしつつ、魅力的なコンテンツを発信することができます」

③ショップ店員(Webサイトのコンテンツ発信者)

  • 目的:もっと簡単にお店の魅力を発信したい
  • 解決策:Webサイトのコンテンツ管理システムを改修する

 メッセージ:「管理システムをリニューアルすることで、より簡単に、お店の魅力をお客様に発信しやすくなります」

図2:「メッセージ」の例
図2:「メッセージ」の例

 つまり、同じ内容であっても、伝えるターゲットに合わせて「伝えるべきメッセージ」を変える。そのためには、ターゲットが目指すゴールを意識し、ターゲットのゴールと自分が伝えたいメッセージがイコールになるよう意識する。そして、ターゲットに合わせて用語・内容を整理することが有効と思われる。例えば、IT用語などはそのまま使ったほうがいいか、それとも平易な日常語にした方がいいか、ターゲットによって変える必要があるだろう。

伝えるべき情報は「分類・構造化」して整理する

 次に世良氏が「重要」とするのが、伝えるべき情報を「分類・構造化」して整理し、伝え方を工夫することだ。例えば、セキュリティ対策委員に選出され、上長から「どんなセキュリティ脅威があるのかまとめてほしい」といわれたら、どうまとめたらよいのだろうか。

 世良氏は思いつくままセキュリティ脅威を羅列してみせ、わかりにくい部分として「①項目が多すぎる」「②項目のまとまりがない」「③全体的な危険性がつかみにくい」の3点をあげた。これを分類・構造化して整理することでわかりやすくなる。

図3:脅威の種類で分類する例
図3:脅威の種類で分類する例

 この例の場合、脅威の種類で分類し、さらに時系列による構造化を行なうことで、「見る側が頭の中で整理しやすくなる」、「項目ごとの関連性が分かりやすくなる」「全体像がつかみやすくなり、説得力が上がる」などが実現し、効果的に伝わりやすくなる。

図4:脅威の種類で分類したものを時系列による構造化した例
図4:脅威の種類で分類したものを時系列による構造化した例
 

 なお、長い文章はもちろん、箇条書きも3~4以上になると情報が整理しにくくなり、一般的に伝わりにくくなるといわれている。そんなときには、分類してタイトル付けを行なうだけでも把握しやすくなる。例えば、システムの改善点について話す時に、事象・問題点・対策と分類するだけでもいいだろう。

 世良氏は「エンジニアをしていると、調査結果を報告してほしいと依頼されることが多い。少しでもカテゴライズするなど整理して伝えるようにすると、受け取り側が理解しやすくなる」と語った。

整理した情報は順番を工夫して伝えよう

 さらに整理した情報を伝える際にも、工夫が必要だという。日々の業務の中で、世良氏が重要と感じたこととして次の3点をあげた。

① 情報量を増やしすぎない

 情報は多ければ多いほど理解にエネルギーが必要になる。簡潔であればあるほど説得力は増すので、情報は伝えられる必要最低限の量で示すことが重要。ただし、知識理解が目的のプレゼンテーションは例外。正しい情報が伝わることが最優先なので、情報量を減らすことよりも、分類して整理することが大事。

② 相手に通じる用語を使って伝える

 相手のITリテラシーに合わせて、意味が伝わる用語を使う。特にエンドユーザーに対しては、専門用語を無闇に使わないよう気を付ける。

例:

×:ステージング環境に修正内容をアップロードしました。 Basic認証ID/PWを入力してご確認ください。

○:テスト用ページの修正が完了しました。 IDとパスワードの入力画面が表示されましたら、 事前に共有させていただいたIDとパスワードを入力してご確認ください。

③ 結論⇒理由⇒詳細 の順番がわかりやすい 

 説明をする際、話し手側はどうしても理由や詳細から先に話してしまいがち。しかし、先に結論を述べることで、相手が理解しやすくなる。

例:

結論:システムの保守運用業務の月額費用の見直しを行いました。

理由:当初の想定よりも作業工数が抑えられているため、現状の実績ベースに費用を見直しました。

詳細:具体的には、AとBの作業工数が抑えられており、月合計で△△の工数が発生しているため○○円の減額となります。

さまざまな「伝え方の工夫」を覚えて実践してみよう

 続いて実践編として、世良氏が業務内で行っている「伝え方の工夫」について実例に基づいて紹介した。

 例えば、受託会社側から顧客へ「システムの一部の運用希望の費用を見直し、金額アップを図りたい」という要望を伝えたいことがあった。背景としては、当初予定していたよりも受託会社側で費用がかかっており、依頼を受けるたびに赤字が発生していた。顧客側としては「費用はできる限り抑えたい」という状況にあるものの、受託会社側としては赤字にならないように適正価格に設定したいという思いがある。

 この場合、「基本金額は上げさせていただきたいです。ですが、1か月あたりの依頼件数が多い場合は、今の運用費用より安くなります」という言い方をすれば、顧客側の「運用費用は抑えたい」という目的・ゴールを担保しながら、受託会社側では工数・費用に見合った金額に上げられる。これは「Yes if 話法」と言われ、いきなり相手の要望を否定せず、受け入れた上で、もし〜ならという仮定でこちらの要望を伝えるという手法だ。

図5:業務内での実例紹介①
図5:業務内での実例紹介①
 

 一方、顧客側から受託会社へ「月次保守運用にかかる費用の見直しを行いたい」というコスト抑制についてのリクエストもあった。保守運用スタート時の想定より、受託会社に依頼している保守運用作業が少ないため、金額も最適化したいという背景がある。

 このときには、「運用保守費用は下げられます。代わりに、不要な運用項目を減らし、一部項目を定常(無償)業務からオプション(有償)業務に変更させていただきたいです」という言い方をすれば、お客様側は「月次費用が下がる」という目的・ゴールを担保しながら、受託会社側では月次の売上は下がるものの項目の最適化によって無理のない範囲で運用を続けられる。これは「Yes but 話法」と言われ、相手を肯定して要望を受け入れつつ、こちら側の要望を伝えるという手法だ。

図6:業務内での実例紹介②
図6:業務内での実例紹介②
 

 いずれにしても、自分側のメリットと相手側のメリットを両立できるような提案をすることがポイントといえる。さらに世良氏は、話し方の工夫として、下記のような方法があることを紹介した。

肯定法(バックトラッキング)

 相手の意見、気持ちを先に肯定してから話を進めるという方法。

例:

「今は忙しくてその話を進める余裕があまりないんだよね」

×「えっ、それじゃ困るんです」

○「そうですよね、御社も忙しい時期にですよね。だからこそ、こちらで準備だけ先に進めておきたいです」

Yes but 話法/Yes if 話法/Yes and 話法

 Noで話を始めず、Yesの前提で、条件付きで話を進める方法。

Yes but 話法

 例:「費用は下げられます。代わりに、定常業務は減らしたいです」

Yes if 話法

 例:「今のままだと金額高いですよね。もし○○円安くなったらどうですか?」

Yes and 話法

 例:「確かに少し費用がかさんでいる状況です。であれば、この案はいかがでしょうか」

SPIN話法

 状況質問(Situation)、問題質問(Problem)、示唆質問(Implication)、解決質問(Need-Payoff)の4種類の質問を会話に取り入れることで、聞き手のニーズに対して適切な提案を行うための手法。

S(状況質問)

 例:「例えば、どの程度費用が抑えられれば御社の要望通りになりますか?」

P(問題質問)

 例:「マニュアル管理や共有が煩雑化していませんか? マニュアルの自動生成が出来る商品をご提案できます」

 世良氏は「さまざまな話し方の手法があり、それらを覚えておくだけでも役に立つ場面がある。ぜひ興味のある方は探してみてほしい」と語った。

「三方良し」の考え方を身に着けよう

 こうした話法は確かに役に立つが、本質的な部分をおざなりにしていると、上滑りする可能性がある。売り手の都合だけではない、買い手(お客様)のことを第一に考えた商売を行い貢献し、そこから得た信頼・利益によってさらに価値を提供し、しいては社会貢献に発展させていくという「売り手よし、買い手よし、社会よし」の考え方は、昔から近江商人の「三方良し」の思想として、多くの経営者の指針とされている。

 つまり、自社と顧客側の双方にメリットのある提案を考えること、そしてそれが社会貢献につながるということを認識し、前述のような「伝え方の工夫」を駆使して伝えること。それを意識することで、より建設的なコミュニケーションが叶う。

コミュニケーションにおける注意点や課題とは?

 どんなに自分側が三方良しで話し方を工夫したとしても、コミュニケーションは相手のあること。なかなか思うようにいかないこともままある。しかし、一定リスクを認識しておくことで回避できることもあるだろう。そこで、最後は陥りがちな注意点や課題について紹介した。

① お客様側の要望が掴めていない

 お客様自身が要望を整理できているとは限らず、言われたまま調整をするのが本当に正解かという視点を持つことが大事。また、特にシステムの仕様、運用状況を完全に把握しているのは自分たちであることから、提案によって要望を引き出すことを意識する。

②話の論点がぶれないようにする

 話の本筋が変わっていないか、都度整理することが必要。頭の中だけでなく、ドキュメントに細かく残し、今の進め方でいいのか、根本の問題が解決するのかどうか、都度確認しながら進めるようにする。特に前述したような「ターゲット」と「メッセージ」を意識するとよい。

③ルールを新たに定める時は、「反対」も意識する

 前述の運用保守の例でいうと、一定の閾値を設けて費用を下げる調整がしたいという要望があった場合、費用が上がる場合もあるが問題ないかという確認をとるようにする。

 世良氏は「説明すること、伝えることは、少し意識を変えるだけで、大きく効果が上がる。ぜひ、説明上手なエンジニアになろう」と語り、「お客様への提案は、どちらか一方だけが得する話ではなく、「三方良し」のビジネスを心がけよう」と改めて訴え、まとめの言葉とした。

関連情報

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16366 2022/09/22 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング