アイデアクラフト

開米の著書で一番人気といえばこの本！
一番人気なのは、安いから？　いえいえとんでもございません。

文字通り　「口ベタなままでもなぜか説明がうまくなってしまう」　ヒミツを地道に地道に根気よく丁寧に語り尽くしているからです。

読者の声１：本書は各プロセスで具体例を挙げて説明しており、分かりやすさの点では他に類を見ません。

読者の声２：苦手な、人への説明を何とか克服したくて購入しました。
結果から言うと、買ってよかったです。この本の通りに準備した上で上席に説明したところ、スムーズにできました。

読者の声３：タイトルからはイメージしずらいですが、初心者レベルの非常にわかりやすい本です。 このジャンルではお勧めです。

読者の声４：プレゼンを行うことが多い方および説明しなければならない立場の方にお薦めします。 非常に読み易く、2 ～ 3 時間で読破できました。

読者の声５：いつも開米さんの本は買って読んでますが、一番まとまっていて、 すっごく参考になります。

こんなレビューを書いていただけるなんて著者冥利に尽きるというものです。

皆様、いつも応援ありがとうございます！

人に説明するためではなく、自分が考えるために図解してみませんか？

ITエンジニアが扱う問題は何かと複雑で、自分が理解するだけでも一苦労なものが多いですよね。だからこそ、「まずは自分自身が関連情報を整理し、考え、問題を理解する」ために、適切な図解をする必要があります。 

本書は、読解力・図解力の研修講師として豊富な経験を持つ著者が、エンジニアの情報理解・伝達のスキルを飛躍的に向上させる「図解思考」のノウハウを手ほどきする指南書です。複雑なドキュメントや会話、思考などさまざまな情報を図解することで、情報の「関係」「プロセス」「パターン」や、間違っている部分、足りない部分、情報からだけでは見えない部分などを見つけることができます。豊富な事例と練習問題を通して、エンジニアが押さえておくべき、情報図解の手法・ノウハウを習得することができる1冊です。

 「晴耕雨読＠エンジニアライフ」様から書評いただきました！　ありがとうございます！

書評：「格好良い仕様書」には良い図解があるものだ

＜冒頭部引用＞

　仕様書などのドキュメントを書いていると、「ここは図示したい」「図を描いてみたけどどうもいまいち」ということ、営業が作る提案書がやたら格好良くて「自分もあんな風につくれたら」と思うことがあるはず。少なくもぼくはある。

　そんな気持ちで手に取ったのが、本書『エンジニアのための図解思考　再入門講座』。説明に「本書は、エンジニアの情報理解・伝達のスキルを飛躍的に向上する『図解思考』のノウハウを手ほどきする指南書です」とある。後述するが、即効性を期待してはならない。本書はじっくり、腹を据えて読む本だ。

（続きはリンク先にて）

「教える技術」の基本中の基本をおさらいしてみませんか？
「プレゼンテーション」と「ティーチング」はまったく違う仕事だということをご存じでしょうか。

どちらも人前に出て話をするという点では同じですが、「私には仕事が出来ます」という、自分のアピールがうまく行けばそれでいいプレゼンテーションと、「仕事をするのは君だ。基本的なポイントは教えるからあとは自分でコツをつかんで、できるようになってくれ」と、他人の成長をうながさなければならない「ティーチング」では、１８０度違う面があります。

新入社員に仕事をさせるためには、教えなければなりません。

でも「教える」技術、「ティーチング」の技術を学ぶ機会はほとんどないのが現実です。

「素人同然の後輩に仕事を教えるにはどうしたらいいんだろう・・・」と悩んだことのある方に、この本をお勧めします。

読者の声１：この本を読めば、プレゼンやコーチングとの違いや、部下や後輩達に今までどうして仕事をうまく理解してもらえなかったのかが大変よくわかります。さらにコーチングよりもティーチングの方が重要であることも理解できます。

読者の声２：知っていることから引き出すコーチングと異なり、知識を与えるのがティーチングです。本書はティーチングの考え方から方法論までを包括的に記載した実用的書籍だと思います。 　最近「コーチング」が流行していますが、それは「ティーチングからコーチングへのシフトが始まった」のではなく、その逆だと著者は述べています。本当のティーチングが必要とされる時代の前触れとして、先にコーチングが流行し始めているのが真相だと述べており、なるほどと思わせる説得力があります。

新米ＳＥに技術を教えるための準備は十分ですか？
後輩メンバー、ユーザー、プロマネ、etc.専門知識を相手が理解できないのは、あなたの教え方が悪いからです!

システム開発の現場では、ITエンジニアがITの専門知識を素人同然のプロジェクト関係者に教えなければならない場面がたくさんあります。後輩のITエンジニア、システムの利用者であるユーザー、システム開発の発注者である顧客、そして技術に詳しくないプロジェクトマネジャーなどなど、ITに明るくない彼らに対して、専門知識や概念を教えるのは非常に難しいものです。ITの専門家であっても、「教えるノウハウ」がなければ、正しく伝えることができないのです。
本書は、そんな「教え方の悩み」を抱えているITエンジニアを対象とし、体系立てた教え方の理論(ノウハウ)を説明します。そのうえで、ケーススタディとして練習問題に挑戦してもらいます。それにより、現場で役立つ実践的な「教える力」を養うことができます。

読者の声１：一番役立ったのは、タイトルが「ITの専門知識を素人に教える技」であっても、第3章までは、ITに限らず、「専門知識を誰にでもわかりやすく教える技」について、書いてあったことだ。

読者の声２：『第４章ＩＴ専門家の「教える技術」実践習得編』のスラッシング、仮想記憶～デマンドページングの辺りがとてもわかりやすく、単に知っているというレベルではなく腑に落ちるという感覚を味わえた。ＩＴの専門知識をこれと同じ調子でひととおり説明してもらえれば、それなりのＳＥになれそうな気がした。是非そんな本も書いて欲しい。『第３章教材制作とプラクティスのための１７原則』は、テーマは必ずしもＩＴに限らず研修を行う場合に注意すべき点が記述されており、そうした担当の人には役に立つだろう。教える側は教えることを知っているだけでなく、本当によく知ったうえで、いかに伝えればわかりやすいかということを十分に考えないとならないというのは、当たり前といえば当たり前だが、中々に大変なことだということもよくわかった。

ビジネス現場でよく使われる図解のパターンと練習問題を集めました

読者の声１：本書はタイトルにありますように、文章を図解する問題がたくさんあり、それらの問題を 自ら考え解いていくことで図解力を身につけることが可能な構成になっています。

読者の声２：ワークを取り入れ、楽しみながら学習できる本です。時に、特におかしなところはないように見えて、実は矛盾している書き方等、「なるほど」って感じです。
早速仕事にも取り入れ、活用しています。技術系にとっては、長い文章よりも短い図解のほうが要点を押さえられ、わかりやすく、誤解がないので助かります。

読者の声３：年末の忙しい時期にいい本が出たものである。 昔、ピラミッドなんちゃらの思考法かよくわからないが、 読むのに時間がかかりそうな本があったが、本書ではその理解が 数分で終わる。

読者の声４：仕事にかかわらず日常において、何となくわかっているつもりであっても
人にうまく説明できないことって、結構ありますよね。 それは口下手が原因ではなくて、説明しようとしている「もの」の本質 が理解できていないからではないでしょうか？ 本書では、その「もの」（または仕組み）の本質を理解するための手法を、 わかりやすい例題（個人的には「防犯パトロール」が好きでした。）とともに みっちりと教えてくれます。

情報をきちんと整理して図を書けば、コミュニケーションが１０倍速くなる
いい仕事をする「情報の仕事人」は、情報を選び、それを切り刻み、1つの狙いに沿って組み上げて、仕事を仕上げます。そのために使うのが図解という道具です。だから、この本では、そんな「情報の仕事人」が使いこなすべき必須のツールである「図解」の事例と技術を徹底して紹介してあります。ぜひこの一冊をとことん活かして、そして「仕事ができる男(女)」への道を切り開いてください。めざせ、情報の仕事人。

関数名、変数名、機能名、等々、名前の付け方に気を使ってますか？

システム開発では膨大な「名前」を扱います。

ところが、「まぎらわしい名前」「意味の覚えにくい名前」をつけてしまうと関係者の間で余計な誤解が増え、多大な開発工数増大を招くにもかかわらず、機能名や変数名のつけかたにあまり気を使っていない例が多いんですね。

それにしても、システム開発における、規約ではなく「意味」志向のネーミングのポイントについて書いた本なんて聞いたことがありません。

だったら私が書いてやろうじゃないか！！　という発想でこの世に出た前代未聞の一冊がこの本です。システム開発の実務において、「名前」に困ったことのある方にお勧めします。広告やプロモーションにおけるネーミングではなく、テクニカル・コミュニケーションのためのネーミングについてまるごと一冊書いた、おそらく空前絶後の（笑）本なのです。

読者の声１：ソフトウェア開発で使う機能名や変数名などの名前の付け方を論じた一冊。名前の付け方だけで一冊の本になってしまうのがまず驚き。それだけ深い世界なのでしょう。アジャイル界隈の人たちが「名前重要」と言っていますが、「ではどうやって適切な名前を付けたらよいの？」という問いに対する答えが本書にあります。 

読者の声２： 似たような情報を集め、それらに何とネーミングするかで、その人の発想の質が決まってしまいます。それ程、ネーミング（標題付け・タイトル付けとも言う）は、重要なのですが、今まで、このネーミングについて、正面きって書かれた本はなかったように思います。
この本では、「ネーミングに成功する７つのワーク」として、手順やチェック方法を教えてくれています。特に、５つのチェック方法は具体的で、ネーミングだけでなく、発想力に自信の持てなかった人にも、悩みを解消してくれる実にありがたい本です。

図解には体系的な方法があります
「文章の書き方」は学校でやりますが、「図の書き方」をあらためて勉強する 機会はほとんどありません。
本書は、筆者が高校時代から２０年かけて積み上げてきた「考えるための図解の 技術」の集大成です。図解の技術は「ロジカル・シンキング」には欠かせないものです。
また、ＳＥの図解の技術は「設計図」の技術でもあります。
通常の図解の技術は「企画書」や「プレゼンテーション」に使うことを想定している ので、アバウトで単純なもので済みます。
しかし、問題解決の現場で分析のために使う図解、運用のために使う図解は、「設計図」 の正確さと豊富な情報量が必要になるものです。
本書ではそういった「設計図」としての図解の方法を詳細に記述しました。
この点は、他に類を見ない一冊です。ぜひ本書でＳＥの使う図解技術を学んでください。

「とことん、考え抜く」体験、してみよう！
SEがシステム解説の上流工程に関わるとき、「本当の課題は何なのか」という問題に直面します。若手SEが思考力の壁にぶつかるのはこのあたりからなのです。思考法の訓練を受けていない人は、「情報は必ずゆがんで伝わる」という現実にも慣れていません。本書は「言われたことしかできないSE」を脱却して「考え抜くことができるSE」になるための技術・道具・習慣をわかりやすく解説します。