記事：「このエンジニアはすごい！」顧客もうなる「質問力」とは
 URL<http://jibun.atmarkit.co.jp/lskill01/rensai/sales/06/01.html>
感想：
相手に質問を投げかける際に心掛ける点は以下の通り。
 1.相手の役に立つことを言う
 2.相手の知らなかったこと（気付かなかったこと）を言う
 3.相手の好奇心を満たすことを言う
今後、私も質問時にこの3点を意識してみようと思います。

記事：よみがえったアップルの顔
 URL<http://jibun.atmarkit.co.jp/ljibun01/rensai/adventurer/001/01.html>
感想：
アップル社の売れ始めた時の事を記載している記事ですね。
この記事を見ておどろいたのが、スティーブ・ジョブズ氏は一度アップル社から追放されていた事。
当たり前の事ですけど、どんな人でも苦労しているのですね

記事：「話し上手なエンジニア」といわれるための8つのコツ
 URL<http://jibun.atmarkit.co.jp/lskill01/rensai/sales/05/01.html>
感想：
この記事を読んで自分自身の話し方振り返ってみると、確かにたまに相手が聞きたいこととは、全く別の事を話している場合がある。
話しをする場合に以下の事を心掛ける事から始めてみようと思います。
「相手の聞きたいことだけを簡潔に話す」
「最初に、「相手の聞きたいことについて話す意思がある」ことを伝える」

記事：リーン・スタートアップが生む価値――「Just do it！」の無駄を省く
記事：リーン・スタートアップが示す「5つの原則」
 URL<http://jibun.atmarkit.co.jp/lskill01/rensai/leanstartup/01/01.html>
 URL<http://jibun.atmarkit.co.jp/lskill01/rensai/leanstartup/02/01.html>
感想：
リーン・スタートアップ(無駄なことをせず、成功の確率を高めるという考え方)について記載されている記事です。
　　　
「世の中無駄な事なんか一つもない」というセリフをよく聞きます。
まぁ「人生」という観点から考えると正しいと思えます。
ただ、「仕事」という観点から考えると正しくない。
　※　あくまで私個人の意見ですので・・・

じゃあ「仕事」をする上での正しい考え方とは？
私個人の意見としては、このリーン・スタートアップが一番適切な考え方なのでは・・・っと思います。
一度読んでみては如何でしょうか？

図書名：仕事は楽しいかね？　(デイル・ドーテン著　野津智子=訳)

タイトルに惹かれた。という理由のみで、本図書を購入、読むことにしました。

内容としては、日々の仕事にゆきづまりを 感じ、未来に期待感をもてない男に、老人が一晩の講義をする。といったストーリー仕立ての構成になっており、自分が想像していたものとはずいぶんと違ったものの、とても読みやすいという印象を持ちました。

多くの自己啓発本にあるような、”計画を立てること”や”未来の自分がどうなりたいかを想像すること”ということを良しとしない物言いが好印象でした。

気に入った言葉がいくつかありましたので、ご紹介します。

「成功するというのはね、右に倣えをしないことなんだ。」

「新しいアイデアというのは、新しい場所に置かれた古いアイデアなんだ」

そして、本図書は次のような言葉を締めに持ってきています。
「アイデアをいっぱい持つこと。ありとあらゆることをやってみる（試してみる）こと。明日は今日と違う自分になること。そして朝を待ち焦がれる、幸せなサムライの一人になってくれ」

自分も日々”変化”していく人間でありたいと感じました。
とても難しいことだとは思いますが、思わなければ進まないですからね。

今月は文具術でした。

文具をうまく整理し、使いこなせている人を見るとかっこいいと思います。

自分はガラケーなので、スマホやタブレットをもつことになったら、関連のかっこいい文具をかっこよく使いこなしたいと思います。

また、特集２は「武器としてのマナー」で、基本的なことですが非常にためになることが書かれていました。

日経SYSTEMSを読んだ中で、紹介したい記事を上げます。

=========
◎課題解決のための構造１「原因探索型」
　　『問題の原因を見つけて　抜本的に解決する』

【内容】
課題解決には「原因探索型」「目的展開型」「逐次解決型」がある。
原因探索では、問題の原因を分析し、その原因を解消する対策を提案する。
本編では、
「取引量が増加したため、また新システムでバッチが追加されたため、バッチの実行時間が長くなり、業務開始に影響する」
という問題例を通して、説明されている。

原因探索型の課題解決で大切な作業は、
①問題の明確化
②原因と対策の確認
③原因の緻密な構造化
である。

例でいうと、以下となる。
①問題の明確化
その問題はなぜまずいのか？を明確にする。この場合は、バッチ終了時刻が遅れると、業務が開始できないということを明確に示す。
②原因と対策の確認
「売上集計システムのデータ圧縮をやめる」という対策案は、原因（取引量増加、バッチの追加）を解消する対策ではない。
③原因の緻密な構造化
「取引量が増えた」という原因に対して打てる対策はないが、原因と対策を緻密に繋いでいけば、途中の原因に対する対策が考えられる。（※）
圧縮処理に多大な時間がかかっていることを説明すれば、対策は問題を解決する位置づけとなる。

これを考慮し、提案を以下のように説明する。
■問題
事実説明にとどまらず「So What?」を明確に示す。
→業務ができなくなることを説明する。
■原因
原因の構造を説明
■対策
考えられる対策をあげ、実施可／不可を明確に説明する。

ここまでくれば、以下の観点で、提案の妥当性を検討できる。
・問題は重要で、解決の必要があるか？
・問題を起こしている主要原因は網羅しているか？
・問題と原因の因果関係は確かか？
・主要原因に対策しているか？
・対策の実施で、原因が解消されているか？
=========

【所感】
私は以前から、なぜなぜ分析を書くのが苦手だ。それは私が、問題を掘り下げるのが苦手だということは事実だ。しかし「原因を5階層掘り下げる」「末端の原因に対策を打つ」というのはどうも合点がいかなかった。
そこでこの記事を読んで、そうれはそうだと確認した部分がある。上記（※）の部分であるが末端の原因にだけに対策を講じると、実際おかしなことになるのだ。ここで、原因を構造化して対策を検討するというのが、例として図解されているが、必ずしも末端の問題にだけ対策している訳ではない。
なので、なぜなぜ分析の様式、または書き方を考えないと、実務に即した対策にはならないように思った。

以上