ホーム » 2017 » 8月

月別アーカイブ: 8月 2017

自己紹介

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

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

図解パターン共有 ピクトレット・ライブラリ 開設

最近あったいくつかの出来事を通じていくつか感じたこと/考えたことがあり、ピクトレット・ライブラリを開設することにしました。

ピクトレットとは聞き慣れないな? と思われるのは当然で、具体的事例についての図解表現のサンプルとその考え方をセットで揃え、コピペ&改変利用が自由に出来るようにライセンスを整理したものです。

 

コンセプトおよび事例はこちらからどうぞ↓

知識伝達に効く! 図解パターン共有の勧め

Pictlet #2 音声認識ロボット

音声認識ロボットの仕様についての説明のピクトレットです。システムの図解でよく使われる、フロー&コメント型のサンプルです。

Slideshareで閲覧

 

PowerPointデータはこちらからどうぞ↓

Pictlet-2-Robotphone.pptx

Pictlet #1 IPv4/v6

IPv4 と v6 の接続性についての簡単な説明のピクトレットです。

Slideshareで閲覧

 

 

PowerPointデータはこちらからどうぞ↓

Pictlet-1-IPv4v6.pptx

問題解決提案で使う「必要・可能・概要」パターン

昨日は愛知県に日帰り出張で企業研修の打合せをしていました。
とある素材系メーカーさん向けの読解図解スキル研修です。

対象者は営業部門、仕事の大半は既存取引先と社内との調整で、新規開拓はほとんどないとのこと。

打合せの中で話題に出たのが、「筋道立てた文章の書き方を教えてもらった記憶は無い」という話。

まあ、実情はそうなんですよね。日本の学校ではそういう教育をしませんから、社会に出てから困ってしまう。業務で報告書や提案書を書くときに「もっと筋道がわかる説明をしろよ」とダメ出しをされて、何度も書き直しをせざるを得ないのが普通です。

それにしても、「筋道」って何でしょう?
「筋道立つ」とはどういうことでしょう?

1つ具体例を挙げると、たとえばこういうことなんです↓↓↓

これは、「問題があるので解決しましょう」と、問題解決提案をするときによく使われるパターンの1つです。中間の3項目の並びを取って「必要・可能・概要パターン」と私は呼んでいます。

具体的な内容は違っても、抽象化するとこのような「必要・可能・概要」パターンで整理できる問題というのがよくあるので、こういうパターンを知っていると説明するときに楽になります。

開米:いかがでしょう、聞いたことはありますか?
担当者:いや全然ないですね。言われてみればこういうことを考えますね・・・・

今まで聞いたことがなくても、一度知ってしまえば当たり前の考え方なので、それを知って何度か試してみると、「筋道立った説明」をするのが少し楽になります。

このパターンがいつも使えるわけではないので「楽になるときもある」というだけですが、そうした「少し」を積み重ねていくことが大事だし、それを世の中に伝え広めていくのが私のミッションだと考えてます。

RDB技術の連載記事を書く仕事

先月、18ヶ月の連載を無事終了したRDB性能トラブルバスターズ奮闘記(Software Design誌)は、著者:生島勘富、構成・文:開米瑞浩というクレジットで名前を入れてもらってます。

この「構成・文」というのは、原作みたいなものです。といっても「原作」という言葉自体が分野によって違う意味に使われているので、これだけじゃわかりませんね。

流れとしては、

原案(生島さん)

構成(開米・商業誌の記事として成り立つ形にストーリーを組む)

文(開米・文章と図案を書く)

編集(Software Design編集部)

という感じです。話の大元のネタエピソードや技術解説のエッセンスは生島さん(私自身はRDBには詳しくありません)、それをもとに読者に伝わるようなストーリーを作るところから先は開米がやっていたわけです。

原作者つきのマンガだと「構成」の部分を「原作」と呼び、「文」を「作画」と呼んでます。

一方、アニメや映画の場合は、上の「原案→構成」がおそらく「原作→脚本」と呼ばれることが多いので、「原作」といっても分野が違えば違う種類の仕事を表してしまうわけです。言葉の意味を統一するのは難しいですね(^_^;)

 

過去最高に図が多い本になりそう?

技術評論社 Software Design 誌で連載していたRDB性能トラブルバスターズ奮闘記(私が文を書いていました)の書籍化打合せのため市ヶ谷に行ったところ、担当編集者氏に「過去最高に図が多い本になりそう。しかも大半が画面キャプチャでもない書き起こしの図で」と言われました(笑)

まあ、僕の書くものはそうなるんですよね。

プログラムはそれがJavaでもPHPでもSQLでも基本的にテキストで書きますけど、それが表現している構造というのはたとえばUMLだったりER図だったりと、図で表した方が理解しやすいケースが多々あります。これはプログラムに限らず至るところで言えます。だから、文章よりも図で表すことを習慣化しよう! と私は常日頃アピールしているわけです。

自分で書いている余裕がない場合はご相談を。代わりに書いてしまう仕事もしております→伝わらない文書レスキュー室

論理文章能力検定?

論理文章能力検定、というものを発見したんですが・・・・論理文章能力?

過去問題が掲載されていたのでざっと見てみましたけど、最高のレベル10の問題を見ても、今までのよくある現代文の問題と大して変わらないような気がします。

まあ、必要ないと言う気はないんですが、これができたからといって「論理力がある」とは思って欲しくないような……何かズレているような気がしてならないですね。

この件はいずれまた。

 

ちょとだけ追記しておくなら、「論理力」を問うのにベン図もロジックツリーもフローチャートも使わない試験問題というものに意味があるのかな? と思うわけです。

ラベリングの基本 #6 違う部分を明示する

手順/仕様説明などをする際に 「Aの場合は・・・Bの場合は・・・」 のように基本は同じでも場合によって少し違う説明が必要なときがあります。

このような場合、 「コピペして違う部分だけ直す」  という方法をとりがちですが、それだけだと読者に大きな負担を与える、分かりにくい説明になりやすいので注意してください。

 

先日20数人の図解宿題の添削をしていたところ、1/4の6人の解答でこのパターンを発見したぐらい、よくあるものなんです。これも自然な発想でしてしまうことなので、「やっちゃいけない」と教えられていないとなかなか気がつきません。

このやり方、書く方はコピペ+修正で済むので楽です。コピペした本人だからこそ、「修正した部分以外は同じ」と知っているので同じ部分をわざわざ読み比べたりはしません。ですが、それを知らない読者は「だいたい同じに見えるけれど、もしかしたら微妙に違うかもしれない」と不安になり、似た部分をいちいち全部見比べなければならないので、とても疲れてしまうわけです。書いた本人はこれに気がつきません。

↓↓↓

 

↓そんなわけですので、違う部分を目立たせるようにしましょう。

 

↓「同じ情報を二度書かない」ようにするのも良い方法です。

 

↓「標準的にはAだが、例外的にBとする場合がある」といった業務フローがある場合、標準側を真っ直ぐ、例外系を脇道として書くのが基本です。

 

↓例外処理とバグはハッキリ区別しておくべきです。

 

↓バグを注釈として書く方法。

 

↓バグ発生後のフローを完全に切り離す方法。

「3G1Sフィードバック」を使う理由とは?

プレゼンテーション練習会マニュアルへの感想】

「あー、なるほど、こういう風に考えるのか!」と思った部分は・・・ 「3G1Sフィードバック」 の部分ですね。普段、なんとなく練習してなんとなくフィードバックしていたので・・・
3G1Sだったのは意外と言えば意外で、3Gと3Sなのかと一瞬思いました。

 

ご感想ありがとうございます。

良いこと(Good)を3つ褒めてから改善提案(Suggestion)を1つ言う「3G1S」というフィードバック法を使う理由は主に2つあります。

1つは、特に初心者のうちは恐る恐るやってみたのにたくさんダメ出しされると凹みやすいので、まずはやってみたこと自体を称賛する、ぐらいの意識で「3つ褒める」を先にしようということです。それで、不安な気持ちをほぐしてもらったところで、「これができればもっと良くなる」と希望を持ってもらうために「1S」、提案を1つ出すわけです。

2つめは、3Sではなく1S、つまり提案を1つだけにするという理由で、これは「1人で全部言ってしまわないように、他の人が違う提案を出す機会を残しておく」ということです。

「提案」型のフィードバックというのはちょっと難易度が高いです。その分、フィードバックを出す側にとって勉強になるので、その機会が参加者全員にバランス良く回るようにしなければいけません。

積極性の高い人だけがしゃべるような勉強会は続きません。それで、1Sなんですね。

 

参加者全員にバランス良く機会が回るようにするためにもうひとつ大事なのは、人数を増やしすぎないこと。増やすとその分薄くなるので、5人ぐらいまでが手頃だと思います。

知っていればできるのに‥‥‥

「日本人はプレゼンテーションが下手」とよく言われますけど、学校でも会社でも(一部を除いて)ほとんど教えてくれないし練習したことがないんだから無理もないです。

コツを知って練習しさえすれば、ちょっとの時間で誰でも見違えるように上手くなります。

(さらに…)