ホーム » 開米 瑞浩 の投稿

作者アーカイブ: 開米 瑞浩

自己紹介

複雑な情報をわかりやすく説明するための「書く・話す」技術のプロフェッショナル。ライティングやプレゼンテーションの研修を行っています。
代表者プロフィール画像

趣味:将棋(81道場四段)、野鳥撮影

ヒアリングとレポーティング

先日書いた「「指示命令」はティーチングじゃありませんよ?」に関して、

「ヒアリングとレポーティングはどちらも状況把握をするもののようですが、違いは何ですか?」

という質問いただきました。

 

これは現場を体験したAさんと、状況把握をしたいBさんがいるとして、どちら側が主体で動くかの違いです。

(さらに…)

【T3L】事例27:報告書の書き方の注意-3 (全体構図を描く)

事例25から続いている「報告書の書き方の注意」も最終回です。今回は、「ストーリーを明確に」 以後の部分を考えましょう。

 

 

これだけだとよくわからなかったので、「ストーリーって何ですか?」 と聞いてみたら、こういうことでした。

 

 

なるほど、トラブルが起きたときにはたいてい必要な情報ですね。
それはそれとして、「ストーリー」 というのは一般化して言うと、何と何にどのような関係があるのかを明確にすることです。で、ラベルをうまく使うとその関係の明示に効果的です。

 

 

そうですね、関係と言ってもいろいろありますね。

ええ、ですが、原因・結果ぐらいの単純なものならラベルだけでいいんですけど、複雑な関係になるとラベルだけでは不十分なんです。今回の話題もラベルだけでは足りないですね。

 

 

それは要素の数が多いからですか? ざっと考えただけで、何かトラブル/事故が起きたときって、トラブル事象そのものとその影響に加えて、原因究明を「真の原因」まで遡ってやれ、と言われることが多いので、4つぐらい要素が出てきますよね。

 

 

そうです。要素の数が多くなるのと、それと、単線じゃ間に合わないんですよ。事象そのものには拡大防止や復旧の手を打つ必要があり、原因に対しては応急処置を、真の原因に対しては是正処置を・・・・と考えるとこんな構図になるじゃないですか。要素が7~8個に増えて、しかも二系統に分かれた複線構造になりますよね。

 

 

ああ、そうですね、こうなりますね。

ん? これって・・・・左側は事故発生の時点で過去の、既に起きたこと、調べて把握すべきことで、右側は事故の後で行うべきこと・・・ですよね?

そうですね。それと、左側は上から下に時間軸が流れますけど、右側のほうは下から上へ対応していくのが普通のはずです。

あ、対応か。じゃあ、左側に解析対象、右側に対応事項、と、こんなラベルをつけてもいいですか?

 

 

おお、いいですね! その通りだと思います!

確かにこれだと単線じゃないし・・・図にしないとわかりにくいですね。

ストーリーがわかる、というのはこういうつながりが見える、ということなんですよ。だから理想的にはこの図のハコの中にそれぞれのサマリーを書いたものを一枚用意して、詳細は別に書く形にすればいいと思います。それで第三者にもストーリーがわかる報告になります。

なるほど!

じゃ、あとは 「トラブルの本質を明確にして欲しい」、「余計なことに触れず簡潔に書いて欲しい」 という部分ですが・・・

 

 

これは、詳細をずらずら並べるんじゃなくて、要点をまとめろっていうことですかね

 

 

そうですね、そういう理解でいいと思います。

 

 

じゃあ、最後にこの箇条書き全体を一枚にまとめてみましょう。 全体と言っても、最後の「図や表を使え」というのは省略して・・・・こんな感じでどうですか。

 

 

ああ、なるほど・・・これが一枚あれば、新入社員にでもイメージが湧くように説明しやすいと思います。

「上司」のレベルと「担当者」のレベルを上下に離した理由はわかりますか?

それはつまり・・・担当者は詳細を把握しているがそれをそのまま上司に言っても通じないよと、要点をまとめてから上司に伝えろ、という話をするなら、この構成のほうが話しやすいから、じゃないですか?

その通りです!

それにしても、今回やったことって、大元の箇条書きを細かく分解して、1文か2文単位で図解して、それを組み合わせてますよね。 一気に全部やろうとしないほうがいいんですかね?

 

 

そうですね。長い文とか、何箇条もあるものをいきなり全部まとめて図解しようとすると、何を表せばいいのか焦点を絞れないのでなかなか大変です。一文単位ぐらいに分解してやったほうがやりやすいことが多いですよ。

わかりました! 今度からそういうふうに考えてみます!

 


 

このように、「適当な文章を分解・ラベリング・図解する」ワークをすることで、複雑な情報を整理し分かりやすく説明する力が上がっていきます。といっても1人ではなかなか「考え方のポイント」が見つかりません。1人で考えることに限界を感じたら、一緒にやってみませんか?

 

【T3L】事例26:報告書の書き方の注意-2 (全体構図を描く)

事例25で書いた「報告書の書き方の注意」の続きです。今回は、「第三者にもわかるように書いて欲しい」 という部分をどう表すか、ですね。

 

 

第三者ってどんな人か、というと・・・現場の状況を知らない人ってことになりますかね

そうですね、逆に、現場を知っている人というのはどの範囲ですか?

上司だと知らないことがあるので、知っているのは担当者レベルということで・・・・こういう感じかな

 

 

お、いいですね~、じゃ、その範囲を明示するためにワクで囲って、それから言い回しも少し変えて・・・こうしましょう

 

 

「現場を知っている」ではダメですか?

おそらく、「現場を知っている」 は、単にその場にいました、という意味じゃないですよね? その場にいても、知識のない者にとっては何が起きてるのかさっぱりわからないときってあるじゃないですか? たとえば料理をしたことのない人間が一流レストランの厨房を見学してもぜんぜん勉強になりませんけど、シェフ経験のある人が見ればいろんなことがわかるわけです。なので、予備知識の有無が大事なんだよということは表現したいです。
それから、「現場を知っている」 だと、「昔は俺も現場で働いてたんだぜ」 という上司も 「知っている」 に入るような錯覚をしやすいので、その表現は避けたほうがよかろう、ということです。

なるほど、わかりました!

じゃ、残りの部分行きましょうか! ということで続きます!

 

(以下、続編に続きます)

 


 

このように、「適当な文章を分解・ラベリング・図解する」ワークをすることで、複雑な情報を整理し分かりやすく説明する力が上がっていきます。といっても1人ではなかなか「考え方のポイント」が見つかりません。1人で考えることに限界を感じたら、一緒にやってみませんか?

 

勉強会サポートへの問合せ

自主勉強会サポートプログラムへのお問合せとして、こんなメールをいただきました。

【困っていること】

  • メーカ等業者へ要件や問い合わせをする際に、なかなかこちらの意図することを正しく伝えることができない
  • そのため、求める回答を得ることができない
  • 上司への状況報告や、他部署ユーザへのわかりやすい案内もなかなかできない
  • これらを改善する必要があるとは感じているけれど、日々の業務に追われて何もできていない

そうなんですよ、こういうこと、よくありますよね。問題があるとは感じていても、実際に何かアクションを起こすためには、そもそも「何をやったらいいか」を考える必要があります。その「考える時間」がなかなか取れないことが多いんです。

書く技術・話す技術を上げていくためには「手頃な題材で、やってみて、フィードバックを得る」必要がありますが、「手頃な題材を探す」のがまず難しいし、「フィードバックをもらえる相手を探す」のも職場によっては難しいです。

そこで、そんな悩みをお持ちのエンジニア諸氏のために「自主勉強会サポートプログラム」を作った次第です。

「指示命令」はティーチングじゃありませんよ?

「コーチング」がビジネス教育界で一種のブームになったのはもう10年ぐらい前の2007~8年ぐらいのことだったと思います。

そのときも気になったのですが、コーチングを推進している人々は「ティーチング」という用語を誤用していることが多いようです。それは、

ティーチングとは、指示命令やアドバイスによって相手に答えを教えてその通りに動かす方法である

というもの。何が誤用かというと、申し訳ないですが

  • ティーチングは、指示命令をすることである → 間違い
  • ティーチングは、相手を指示通りに動かすことである → 間違い

なんですよね。この両者はどちらもティーチングというより「インストラクション」と呼ぶべきなんです。

これらの意味あいを解説するために、最近あるチャートを書いたのでご紹介しましょう。

(さらに…)

写真はロジックを伝えるのには向いていない

プレゼンテーションで写真を使うケースが増えていますが、写真では論理的に複雑な構造を持つ情報は表現しづらいので、本当におおまかなアバウトなイメージを伝える場合にしか使えません。

写真を使うとわかりやすそうに見えるかもしれませんが、実際にわかりやすいとは限りませんので、写真を使うべき情報なのかそうでないのかはきちんと見極めて使いたいところです。

「写真に向いていない情報」の一例がこちら→【T3L】事例25:報告書の書き方の注意-1 (全体構図を描く)

【T3L】事例25:報告書の書き方の注意-1 (全体構図を描く)

Together! 3行ラベリング、25本目のお題は、これはどんなお話しでしょうか?

■原文

トラブル報告書を書くにあたって、トラブルの内容~原因~対策にいたるまで一貫したストーリーを踏まえた報告書を書ける社員が少ないので、こんなことに気をつけて書けるようになって欲しい

【報告書を書くにあたっての注意事項】

  1. 誰向けに書いているのかが明確な報告書にして欲しい
  2. 第三者にもわかるように書いて欲しい
  3. ストーリーを明確にして欲しい
  4. トラブルの本質を明確にして欲しい
  5. 余計なことに触れず簡潔に書いて欲しい
  6. 文章だけに頼らず、必要に応じて図や表を使って欲しい

出典:一般的によく言われる事項を当事例向けに開米が整理したもの

(さらに…)

「エンジニア向けの情報整理術」のご相談

先日ある会社から「文書作成のための情報整理術」というエンジニア向けの研修のご相談をいただきました。

文書作成というのはたとえば報告書、提案書、手順書など。

特に気にされていたのが「トラブル報告書」で、「トラブル報告の内容、原因、対策を含めて一貫したストーリーを踏まえた報告書がなかなか書けない社員が多い」というお話し。

まあ、この種の悩みはどの会社でも共通して抱えていると言っていいですね。

トラブル報告というのは会社ごとにある程度は一定の書式が決まっていることが多いですが、じゃあその書式に沿って書けば十分か、というとたいていうまく行ってません。

具体的にゴールイメージとして出てきたのはこんな願いです。

【ゴールイメージ】

  • 誰向けに書いているのかが明確な報告書にして欲しい
  • 第三者にもわかるように書いて欲しい
  • ストーリーを明確にして欲しい
  • トラブルの本質を明確にして欲しい
  • 余計なことに触れず簡潔に書いて欲しい
  • 文章だけに頼らず、必要に応じて図や表を使って欲しい

社員にはこういった書き方ができるようになって欲しいけれど現状ではなかなか出来ていない、ということでした。

ああ、そうそうわかるわかる、と思い当たる方も多いのではないでしょうか。

そんなご相談をいただいた御縁で「文書作成のための情報整理術」研修をソフトウェア系エンジニア対象に企画し、実施させていただいた次第です。

講座概要 → エンジニアの文章図解・情報整理術 講座概要

 

実はその講座の中でも使ったのですが、上記の「ゴールイメージ」の箇条書き自体も、単なる箇条書きよりも図解してあげるともっとわかりやすく通じるようになります。具体的にはどう書けば良いのか? それはまた別途投稿することにします。

(追記: → 【T3L】事例25:報告書の書き方の注意-1 (全体構図を描く)として投稿しました。)

 

【T3L】事例24:バーナム効果(原文の構成に引きずられるケースに注意)

Together! 3行ラベリング、それでは24本目のお題に行ってみましょう! 今回は、心理学というか心理操作テクニック系のお話しですね。

■原文

【バーナム効果】 実際には誰にでも当てはまるようなどうとでも取れる事を自分だけに適用される極めて正確な内容だと思い込んでしまう心理学的な現象のこと。占い師や詐欺師たちに騙しのテクニックとして利用される。

例:A型だから綺麗好き(A型以外にも綺麗好きなO型もいる)、 何か最近悩み事があるでしょう?(誰にでも何かしらの悩みはある)

■出典:ネット上に流布している文章につき、明確な出典不明

(さらに…)

【T3L】事例23:数字で考える(名詞と動詞を分けて「変化」を表す)

Together! 3行ラベリング、23本目のお題は・・・はい、
「仕事を進める上で、数字で考えることの重要さ」 ですか!

■原文

どんなに優れたアイデアを出しても、そのアイデアを裏づけるための情報がなければ、それは「ただの思いつき」とされてしまいます。また、アイデアを裏づける情報があっても、それをきちんと分析し、そのアイデアを具現化する方法を考えなければ、仕事になりません。さらに、ビジネスとして実現させるためには、会社の決裁も必要でしょうし、周りに協力してもらう環境をつくらなければなりません。これら一連の仕事の流れで、最も必要なのが「数字」で考える能力です。
数字で情報収集し、数字で分析し、数字で問題解決方法を考え、数字で伝える。このコツさえつかめば、大きな説得力で周囲を巻き込み、効率的に仕事ができるようになります。

■出典:『「数字」で考えるコツをつかめば、仕事の9割はうまくいく』 久保憂希也著、中経出版

(さらに…)