- +

書籍企画:関連議論ノート

書籍企画中:「徹底研究・IT技術者のための説明術」(仮題) の詳細セクションです。ご意見をくださった方との議論で気がついたことを残しておくために作りました。

論点1:どうしたらヌケモレに気がつく?

(O・Aさん)
わかりやすく書きたい、伝わるように書きたい、って言うあたりはとても大切なのですが、そもそもなのですが、漏れとか抜けが内容に書かれていないのが痛いです。

論理的に考えたら、抜けている、考慮が足りない、どの条件を言っているかわからない(主語が抜けているなどで、分かりにくいに入ると思うのですが)、なぜそう判断したかわからない、書いた文章からどうやって考えたらこの文章になったのか・・・・的な、わかりやすいともう一つ、大きなものが抜けていることに気がつかないってあたりがどうにかなるといいなぁぁと思ってます。
ヘタしたら目次しかないなんて現場もあったりします。
書いてあればなんとか読み砕くのですが、抜けているものを気がつくためにはドキュメントの粒度を揃えてみるとかやっていますが、ないものは気が付きもしないという。

なぜ、この説明には抜けているのかというのが書いた本人が気がつかかないことがすごく問題になっています。うちの現場ではそうですね~

(考察)いわゆるロジカルシンキングのトレーニングで、ある程度解決する部分はありそう。ただし、単に「ロジカルシンキング受講しました」というだけで実際はできていない例はよく見かける・・・

経験上、ヌケモレに気がつかない原因としては

1.抽象化できていない

2.対象業務、問題についての知識・理解が不十分

3.因果関係を整理することができていない

といった項目が挙げられます。このうち1.と2.に関係ありそうな話を以前ある本に書いたことがあります。

一部引用しますとこんな話↓ (技術評論社刊 「エンジニアのための 伝わる書き方講座」 2.7節より)

「2.対象業務、問題についての知識・理解が不十分」 だと、上図の「要素出し」がうまくできません。それでも、その後の「分類・ラベリング」をしっかりやっていればその段階で気づきやすいのですが、たいていこれをしっかりやらないので、気づかずそのまま行ってしまうわけです。

そして、「分類・ラベリング」というのは「1.抽象化」の作業です。したがって1と2が一緒になると問題が深刻化しやすいです。

ちなみに「ロジカルシンキング」でよくやるMECEやロジックツリーは、「1.抽象化」に熟練するための習慣です。これをやっておくと「2.理解不十分」の問題はある程度カバーできます。(とはいえ、人間、本当に知らないことは逆さに振っても出てこないので、限界はあります)

 

 

書籍企画:説明するために必要な技術とは?

書籍企画中:「徹底研究・IT技術者のための説明術」(仮題) の詳細セクションです。

説明するために必要な「技術」についての一般論的パートです。

ひとまず項目だけ挙げておきます。

  1. 「説明」「プレゼンテーション」「インストラクション」の違い

  2. 3種類のプレゼンテーションを知っておこう

   a. Persuasive Presentation

   b. Narative Presentation

   c. Informative Presentation

  3. 「説明」のプロセスを考える

   a. プランニング&ライティング

   b. デリバリー

  4. プランニング&ライティングの技術

   a. ゴールを明確にする

   b. シナリオを練る

   c. 必要なコンテンツを整理する

   d. わかりやすいドキュメントとして仕上げる

  5. デリバリーの技術

   a. ボイスコントロール

   b. ゼスチャー

   c. インタラクション

   d. プレゼンス

書籍企画中:「徹底研究・IT技術者のための説明術」(仮題)

ただいま、新しい本を出すべく企画を立てているところです。

仮タイトルが「徹底研究・IT技術者のための説明術」 (僕の出す本なので、「図解説明術」とかつけてもいいかもしれませんが)

表題の通り、IT技術者が遭遇する場面に焦点を当てた「説明術」の本です。

「わかりやすく説明する技術」についての一般論的なノウハウは存在しますが、それらはあくまでも一般論であって、具体的に実践しようとしたときに行き詰まるケースが多いんですよね。

行き詰まってしまう原因は、僕が思うに大まかに3つあります。

  • 第1に、「一般論」ではIT技術者の事情に合わないケースが多いこと。
  • 第2に、IT技術者にとってイメージしやすい「お手本」が存在しないこと。
  • 第3に、コンテンツを作るプロセスが明示されていないことです。

これらの問題を解決して、ITエンジニアがわかりやすく説明できるようになるための「お手本」と「プロセス」を示すことが、この本のテーマです。

この本はまだ企画を始めたばかりで、これから詰めなければいけない部分が山ほどあります。そして、どうやら自分1人では書けそうにない、ということも感じています。

たとえば僕はめんどくさい情報をわかりやすく構造化することは得意ですが、それが必要な具体的な場面の中には僕の知らないものもあるわけです。ですので、「こんな場面で困りました」という話は実際にそれを経験した人から聞かないとわかりません。

ですので、まだ出版企画も通っていない段階ではありますが、構想メモや関連情報をある程度公開していくことにしました。(もちろん、公開できるものだけです)。

ざっくばらんに言うと、僕が困っていることを書いていくので、役に立ちそうな話があったら教えてください、ということです。

たとえば、「IT技術者のための説明術」について書くために、こんな場面を想定しようかと考えています。

 1. 経営者向けにシステム提案をする場合
 2. ドメインエキスパート向けに仕様説明をする場合
 3. デベロッパーイベントで技術解説をする場合
 4. 社員を対象に新技術の教育をする場合
 5. オペレータ向けに操作教育をする場合
 6. 学生向けに会社紹介をする場合
 7. APIリファレンスを書く場合

この中でたとえば「3.デベロッパーイベントで技術解説をする場合」・・・はい、開米はやったことありません。やったことのないものについては、リアリティのある話って書けないんです。ですので、実際に経験のある方に話を聞いて、エッセンスをまとめて紹介したいと思います。

思えば今からおよそ2x年前、コミュニケーション下手なひきこもり人間だった僕は、人に説明をするということに大変苦労していました。そんな時にこういう本があったら、役に立っただろうな、という、そんな本を出したいと思います。

おっと、IT技術者が説明をする場面といったら、こういうものも避けて通れませんね。

 8. システム障害の報告をする場合

そんなわけで、想定したほうがいい場面は他にもありそうです。そういうものは自分一人ではどうしたってわからないので・・・・助けてください(^_^;)(^_^;)(^_^;)

逆に僕が得意なのは、人の話を聞いて、そこからエッセンスをつかんで要約し、構造化してわかりやすく図解し、目的に応じて書籍や記事の原稿として、あるいはセミナーテキストとして仕立てることです。

そうした「話のまとめ方」が苦手な方は、僕に話をしてくれれば、「えっ、あんなに適当にしゃべった俺の話がこんな風になるの?!」という新鮮な驚きを体験していただけるでしょう(笑)。

というわけで、ここに新しい本を出す企画の開始を宣言します!!

 

関連情報は以下にリンクを張っていきますので、興味のあるところをつまみ読みしてやってください。よろしくお願いします!

書籍企画:「徹底研究・IT技術者のための説明術」(仮題) 関連情報まとめ

どんな場面を想定するか?

IT技術者が「説明」をする場面として考えられるものをまとめます

説明するために必要な技術とは?

「説明」「プレゼンテーション」「インストラクション」の違い、プランニングとライティングの技術、デリバリーの技術について、等々

関連議論ノート

この本の企画について、意見をくださった方との議論の要点を紹介

 

書籍企画:どんな場面を想定するか?

書籍企画中:「徹底研究・IT技術者のための説明術」(仮題) の詳細セクションです。

想定する場面とその特徴をまとめてみました。加筆修正の提案をぜひお寄せください。

1. 経営者向けにシステム提案をする場合

  • IT専門用語は慎重に使う必要がある
  • 費用対効果に敏感
  • リスクに敏感
  • (はやり言葉に弱い例も?)

2. ドメインエキスパート向けに仕様説明をする場合

(ドメインエキスパートとは、システム化対象業務の専門家のこと。ユーザー部門の責任者を兼ねる場合もある)

  • 対経営者ほどではないがIT専門用語の使用は慎重に

3. デベロッパーイベントで技術解説をする場合

  • (・・・・)

4. 社員を対象に新技術の教育をする場合

  • 「説明のしすぎ」に注意

5. オペレータ向けに操作教育をする場合

  • 用語の統一に注意する
  • フロー&コメントのパターンが使えることが多い

6. 学生向けに会社紹介をする場合

  • どんな印象を持って欲しいか、ゴールを設定する
  • 業界的にどんなイメージがあるかを分析する
  • 学生に通じる言葉を整理する


7. APIリファレンスを書く場合

  • アーキテクチャ・モデルをわかりやすく示せるようにする


8. システム障害の報告をする場合

  • 障害報告の基本事項を押さえる

 

・・・・他、加筆修正の提案をいただけますと本当に助かります(^_^)/

業務報告書改善例(1)

「業務報告書の書き方」について、具体例をお見せしましょう。

たとえばある社員が四半期の業務報告の一部として次のような文章を書いてきたとします。

【2015年度第3四半期業務報告】(原文)
次期SASシステムで用いられる新プロトコルによる通信テストにつき、テスト仕様書に基づいてテストデータの入力・修正作業を行いました。当初はテストツールにバグが多く、かつ、仕様の記載があいまいなためにバグなのかどうかという判断もつかない中で本体プログラムの前にテストツールのデバッグを行っている状況でした。そんな作業の中で関係者の話をとりまとめて仕様を確定させることができました。また、そういった大量のテスト項目を効率的に処理するためにはテストツールが重要であることと、テスト項目を作る際の考え方のようなものを学びました。

これは架空の報告書ですが、実際に書かれたものをもとに固有名詞や記述の流れ、表現を変更して作ったものなので、現にこうした報告があったと思っていただいてかまいません。

これが四半期の業務報告の「一部」で実際にはもっと長く、それを数十人いる全社員が書いてくるのを社長は読んでなんらかのフィードバックを返さなければならないわけです。かなり大変な作業です。

「文章で書く」ことを当たり前と思ってしまうと上記例のような報告書を書いてしまいますが、もし、普段から「ラベルつき箇条書きで書く」習慣がついていたら、おそらくこんなふうに書いたことでしょう。

【2015年度第3四半期業務報告】(改善例)
 【対象業務】
 次期SASシステム向け新プロトコルの通信テスト用データの入力・修正作業

 【問題点】
 テストツール自体にバグが多かった。
 仕様の記載があいまいなため、バグかどうかの判断もつかない状況だった

 【対応】
 関係者の話をとりまとめて仕様を明確化させ、作業を推進

 【成果】
 顧客:テスト仕様を確定させることができた。
 自分:テストツールの重要性、およびテスト項目を作る際の考え方についての学び

 【考察】
 テストツールの品質が低い状態でテスト工程に入ってしまったわけで、工程管理の失敗と思われます。この問題は再発する可能性があります。

 

原文に比べるとはるかに分かりやすくなっていますね。
やったことといえば、下記2点です。

(1) 長い文章を分解して、【問題点】【対応】のようなラベルをつけた
(2) 【考察】を加えた

このうち、(1)は理屈として難しいことは何もありません。しかし実際にやり始めると、「ラベルをつける」のはなかなか難しいものがあります。普段からやっていないと、適切なラベルを思いつかないことが多いんですね。

そこで、「業務報告書の書き方講座」では、業務報告書でよく出てくるラベルについては例を挙げて解説してあります。

また、(2)は実は原文では書いていなかった部分です。内容を見ると、「工程管理の失敗と思われます」といった、書いちゃっていいのかなあ・・・と心配になるようなことが書いてあります。しかしこうした振り返りが、仕事を改善するためには大事です。ラベルつき箇条書きを習慣にしていると、この【考察】のように、意味あいを考えて自分の言葉で書かなければならない部分に気がつきやすくなります。

そういった効果が得られる「業務報告書の書き方講座」を開催しますので、報告書の書き方に悩んでいる方はどうぞご参加ください。

業務報告書の書き方講座(2/25)のお知らせ

サブカテゴリ

主な更新情報