ML大学Python学部NumPy学科

主に学んだことのアウトプットの場として

【書評】技術者視点で読んでみた「大前研一と考える営業学」

 以前勤めていた会社で営業の先輩から借りパクしたまま未読だった下記の本を読んでみました。

正直、大前さんが学長をやっている学校の宣伝のための本なのかなという感じは否めません。

しかしながら、いわゆる「営業」という職種を仕事としていない僕が技術者の視点から読んでみることによって、それなりに学びはありました。

大前研一と考える 営業学

大前研一と考える 営業学

というのも、クライアントとの折衝は何も営業マンに限ったことではないからです。

例えばプログラマなどの技術者でも客先に常駐するような場合は、クライアントと一緒に過ごす時間はむしろ営業マンよりも長いはずです。

そのような際に、クライアントと良い関係を築くことは、自社にとっては勿論、技術者自身にもプラスの効果をもたらすと考えます。

働きやすくなったり、貴重な情報を入手できたり、今後につながる人間関係を構築できたり。何よりも、お客さんから信頼されたら嬉しいですよね。

メモ

そういうわけで、営業マンでなくとも頭に入れておくと良さそうなセンテンスを、メモとして残しておきます。

というか、別に営業マンとお客さんに限った話ではなくて、対人関係全般に大事なことだと思います。どれも当たり前のことですが。

売った買ったの短期的な付き合いではなく、顧客の庭で考え、信頼を勝ち得、長期的な関係を築くことが大切です。

営業には経営者が決して持ち得ない決定的なアドバンテージがあります。(中略)「顧客に最も近い存在」であることです。

何でもかんでも顧客の言いなりになってはいけません。その使命は、あくまで顧客のビジネスにしかるべき価値をもたらすことです。

確かに顧客の言うことを黙って聞いている方が楽ですし、いらぬ摩擦を起こす心配もありません。

顧客を満足させると同時に会社に利益をもたらすためには、交渉力が必要です。交渉は相手とのギブアンドテイクによって成り立つものです。

絶対に譲れない点、譲ってもいい点を明確にした上で、柔軟な姿勢で臨みます。

目次 

第1部 営業のプロフェッショナル化
第2章 問題解決型営業のすすめ
第3章 営業のマーケティング・マインド 
第4章 営業のセルフ・マネジメント力
第5章 営業チーム力の向上

最後に

なぜ人は借りパクしてしまうのだろうか。

 

大前研一と考える 営業学

大前研一と考える 営業学

【書評】インターネットを理解するための最初の一冊「インターネット技術の絵本」

ITやテクノロジーに関わる仕事を始めようと思ったり、プログラミングできるようになりたいと思った時、一番最初に理解しなければいけないものはインターネットそのものではないでしょうか。

誰しもが日頃からスマホやPCで触れてはいると思います。しかしながら、その仕組について一度しっかりと分かっておかなければ、その先にあるWebサービスやWebアプリを作るのは難しいと言えそうです。

前置きが長くなりましたが、本エントリーでは、インターネットを理解するための最初の一冊をご紹介します。有名な絵本シリーズの「インターネット技術の絵本」です。

インターネット技術の絵本

インターネット技術の絵本

  • 作者: (株)アンク
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/08/28
  • メディア: 大型本
  • 購入: 1人 クリック: 12回

こちらは、インターネットそのものを理解するために、周辺も含めて様々な知識を広く浅く紹介するといった内容です。

今後インターネットやコンピュータの理解を深めていくための初めの第一歩として、最適な書籍だと思います。

中学生でも理解できる程度の大変分かりやすい説明となっているため、プログラミング経験が無く、ブラウザとメール程度しか利用したことが無いという方でも問題無く読み進めることができるでしょう。

なお、本書ではブラウザとメールの仕組みについても説明があります。

こんな人にオススメ

・インターネットについて詳しくなりたいけれど、まずは簡単な本から始めたい

・プログラミングを始めてみたいと思っている

・簡単なhtmlやcss程度なら分かるけれど、その仕組はよく分かっていない

Webサービスを作ってみたが、インターネットそのものについて理解していない

プロトコルって何?IPアドレスって何?

・ メールが送受信されたりWebページを閲覧できたりする仕組みが知りたい

目次

第1章 インターネットの基礎
第2章 Webとメール
第3章 Webのしくみ
第4章 メールのしくみ
第5章 インターネットの技術
第6章 ネットワーク構成
第7章 サーバーサイド技術
第8章 セキュリティ
付録

最後に

インターネットに関わる仕事をするに際して初めの一冊としてはもってこいの本書ですが、この本が教えてくれることはほんの触りの部分だけです。

Webサービスを提供する側になったり、実践の場で使いこなせるようになるためには、各分野において、より詳しい知識が必要となるでしょう。

インターネット技術の絵本

インターネット技術の絵本

  • 作者: (株)アンク
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/08/28
  • メディア: 大型本
  • 購入: 1人 クリック: 12回

【書評】プログラマにとっての理想的な環境とは?「ピープルウエア」

 とても良い本に出会いました。ソフトウェア開発を行う企業において、経営層やマネージャーは、スタッフ(プログラマ)に対してどのようにあるべきか、どのような環境を提供すべきか、を記した本です。

新進のマネージャー、またはこれから技術者のマネジメントをやっていくことになるけども自信が無い、という人たちにとって、多くの学びがある本じゃないかなと思いました。

ピープルウエア 第3版

ピープルウエア 第3版

  • 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
  • 出版社/メーカー: 日経BP
  • 発売日: 2013/12/18
  • メディア: 単行本(ソフトカバー)

そういった役割の人は勿論、彼らから指示を受ける側のプログラマが読んでも大変有益だと感じました。

なぜなら、今自分の所属する組織よりももしかするともっと良い職場環境を提供してくれる組織が他にある、と本書が気付かせてくれる可能性があるためです。

というか、ここに書かれていることは、ソフトウェア開発企業に限定した話ではありません、多分。

以下、Wikipediaより引用。

ピープルウェアとは、ソフトウェア・ハードウェアシステムの開発、使用に際する人間の役割、関連したいかなるものも指す。たとえば、開発者の生産性、チームワーク、集団力学、プログラミングの心理学、プロジェクト管理、組織上の要素、ヒューマンインターフェイスの設計、人間と機械の相互作用、などである。

ピープルウエアとはつまり人に対して言及している概念なわけですから、どのような業界でも考慮しなければならないことだと思います。

特にこんな人が読んだら良いのでは

  • ソフトウェア開発会社の経営層
  • ソフトウェア開発会社のマネージャー
  • ソフトウェア開発会社の人事・総務
  • プログラマ
  • 優秀なプログラマと一緒に働いていきたい人
  • プログラマの生態に興味がある人

目次

第I部 人材を活用する

第1章 今日もどこかでトラブルが
第2章 チーズバーガーの生産販売マニュアル
第3章 ウィーンはきみを待っている
第4章 品質第一……時間さえ許せば
第5章 パーキンソンの法則の改訂
第6章 ガンによく効く?「ラエトライル」

第II部 オフィス環境と生産性

第7章 設備警察
第8章 プログラムは夜できる
第9章 オフィス投資を節約すると
ちょっと休憩 インテルメッツォ
第10章 頭脳労働時間 対 肉体労働時間
第11章 電話、電話、また電話
第12章 ドアの復権
第13章 オフィス環境進化論

第III部 人材を揃える

第14章 ホーンブロワー因子
第15章 リーダーシップについて話そう
第16章 ジャグラーを雇う
第17章 他者とうまくやっていく
第18章 幼年期の終わり
第19章 ここにいるのが楽しい
第20章 人的資産

第IV部 生産性の高いチームを育てる

第21章 全体は部分の和より大なり
第22章 ブラックチームの伝説
第23章 チーム殺し、7つの秘訣
第24章 続、チーム殺し
第25章 競争
第26章 スパゲティディナーの効果
第27章 裃を脱ぐ
第28章 チーム形成の不思議な化学反応

第V部 肥沃な土壌

第29章 自己修復システム
第30章 リスクとダンスを
第31章 会議、ひとりごと、対話
第32章 マネジメントの究極の罪
第33章 E(悪い)メール
第34章 変化を可能にする
第35章 組織の学習能力
第36章 コミュニティの形成

第VI部 きっとそこは楽しいところ

第37章 混乱と秩序
第38章 自由電子
第39章 眠れる巨人よ、目を覚ませ 

覚えておこうと思ったポイント

マネージャーの基本的姿勢。

マネージャーのほとんどは、技術面より、人に気を配っていると思い込んでいる。しかし、本当にそうしているマネージャーは滅多にいない。実際には、技術だけに関心があるというマネジメントをしている。

知的労働者が時々ミスを犯すのは極めて自然で、仕事を真面目にやっている証拠である。しかし、仕事の上の誤りを、聖書で言う「罪」と同じように考えている人がいる。この考えを正すのは非常に骨が折れる。

間違いを許さない雰囲気が社内にあると、担当者は守りに入り、失敗しそうなことには絶対に手を出さなくなる。(中略)間違いを犯さないよう手段を講じたプロジェクトでは、平均的な技術レベルは、それなりに上がるかもしれないが、チームの空気は重く沈む。これと正反対のアプローチは、間違いを恐れさせないことだ。

担当者を指示どおり働かせて、短期間の生産性が上がっても、長期的には大した効き目はない。担当者の自発的なヤル気が認められず、マネージャーがヤル気を補給するという考えほど、担当者の士気をくじくものはない。

担当者一人ひとりの個性は製造業でのマネジメント手法をそのまま採用しようとするマネージャーにとって頭痛の種である。一方本当に人を知るマネージャーはユニークな個性こそがプロジェクト内の不思議な作用を活発にし効果的にすることをよく認識している。これはもっと奨励されてしかるべきだ。

誰かに頼るしか問題の解決策がないという深刻な場合ですら、マネージャーがその誰かになってはならない。チームの中から助けの言葉をかけた方がはるかにうまくいく。

マネージャーの役割は人を働かせることにあるのではなくて、人を働く気にさせることである 。

マネージャーがいくらかでも意味のある方向に部下の人格を変えられることはまずない。部下が部下として留まる年月はあまり長くないし、またマネージャーも部下の本質的な人格を変化させるほどの影響力を持てないのが普通である。

したがって部下の本質は部下として過ごした期間に関係なく、その終わりの状態は初めと大して変わらない。(中略)

こうしたことは最初に人材を揃えることが何よりも重要だということを意味する。

力があるマネージャーは、チームのメンバーが頭を丸坊主にしようが、ネクタイを締めないでいようが、一向に気にしない。チームの誇りの対象は、チームメンバーが成し遂げた成果だけである。

最も大きな成功を収めるマネージャーは自部門のエントロピー=均質性を撹乱し、社内標準からかけ離れていても適切な人材を集め、彼らに本来の力を発揮させる人々だ。

リーダーシップは、私たちから何かを引き出すということではない。サービスである。(中略)明確に指示を出すこともないではないが、主要な役割は指揮官ではなく触媒である。

高品質の徹底。

早くやれとせかされれば、雑な仕事をするだけで質の高い仕事はしない。仕事を速くするためには製品の品質と仕事の満足感を犠牲にせざるを得ない。

大抵の人は自尊心を自分の作った製品の品質(製品の量ではなく質)と強く結びつける傾向がある。どんなことでも製品の品質を落としかねないことを指示すれば、それに反抗する部下たちの感情に火をつけることになる。

達成不可能な納期をマネージャーが設定すれば、製品の品質を危険にさらすことになる。マネージャーは自分のやっていることがそんな意味を持つとは思ってもいない。逆に面白くて挑戦するに足ることを部下に与え、人間的成長を助けているとさえ思っている。(中略)

古参で少し擦れた部下はそうは考えない。プレッシャーの下では作業には過度に制約がかかる。納期通りに完成するためにプロジェクト資源をやりくりする自由もなくなる。

例えばもっと人を投入するか実現する機能を削るかを選択できなくなる。犠牲にできる唯一のものは品質だ。そこで極端な時間のプレッシャーをかけ続けると部下は品質を犠牲にし始める。

問題が見つかってもカーペットの下へそっと隠し、後回しにしたり、エンドユーザーに捕まったりするのだ。不安定で本当は完成していない製品がこうして出荷される。好んで行っているのではないが、他に選択肢はないのだ。(中略)

会社自身の品質基準に満たない製品を早く出荷するようにとスタッフにプレッシャーをかけることは間違いである。(中略)

エンドユーザーの要求をはるかに超えた品質水準は生産性を上げる一つの手段である。

健全な作業環境のもとでスタッフが職務をきちんと遂行しない理由は、能力の不足か、自信のなさか、プロジェクトの目標や同僚に馴染めないことにある。納期によるプレッシャーは大した解決策にはならない。

短時間で出荷しようとして何かをすると、結局品質が下がってしまう。製品のエンドユーザーはこの取引(安くで早く納品する代わりに、品質が下がる)に進んで同意することが多い。

しかしそんな譲歩は開発者にとっては苦痛である。自分の能力以下の製品づくりを強制されることで、プログラマーの自尊心を傷つけられる。

品質削減が最初に破壊するのは、 長い間培ってきたチームの一体感だ。

プログラマが集中できる環境を作る。

オフィスに遅くまで残ったり朝早く出社したり果ては静かな自宅で仕事をしなければならないのは、オフィス環境の悪さに対する強烈な告発である。

貴重な時間を潰されるのと同じように深刻なのは、邪魔されてイライラすることだ。仕事に集中しようとしてその度に邪魔されては面白かろうはずがない。あと一歩で仕事に没頭できるというところで、結局自分の周りの現実に引き戻されてしまう。(中略)

これはまさしく近代的オフィスの弊害そのものである。

机の前に何時間座っていたかはどうでもいいことで、全神経を集中して仕事に取り組んで時間が重要なのだ。(中略)

1日のうち邪魔が入らない時間が少なくとも2、3時間あって当然だと考えるようになれば、邪魔の入らない時間をそれだけ確保しようと行動するようになるだろう。

絶えず中断を意識するようになれば、何の気なしに軽い気持ちで隣の人の仕事を邪魔することもなくなる。

オフィスの騒音や音楽が創造性やひらめきに与える悪影響は、表面には現れてこない。そもそもひらめきは時々しか起きないものなので、それが減ったとしても気づかないことが多い。創造的な思考に割り当て量があるわけでもない。創造性の低下による悪影響は、長い間に蓄積される。

かくして会社の能力は下がり、ひらめきのない仕事が垂れ流され、優秀な人は辞めていくのだ。

マネージャーができることは、せいぜい社員が自分に適したまともな作業空間を作れるように、十分なスペース、静かさ、および、プライバシーを確保することだ。

スペースについて、年月を超えで適用できるパターンがある。それはプライバシー深度というもので、建物の中に入るに従い徐々にプライベートになるというものである。

オフィスのいちばん外側は部外者が入ってくる場所である。一歩中は関係者のための空間であり、さらに奥は各個人用のプライベートのオフィスとなる。

グループがミーティングをする場所には、テーブル、全員分のイス、ホワイトボード、意見を全部書き留めておける掲示板が必要である。理想を言え、ば簡単な食事を作って食べられる設備と広さが欲しい。

会食なしにはいかなる人間集団も団結を保てない。すべての組織や生活集団に集まって食事のできる場所を用意すること。 会食を定例の行事にすること。特に仕事場では昼食会を始めること。

もちろん個人個人の貢献のすべてが積み上げられて統合されて全体になるのだから、最優秀チームでさえ協調は不可欠である。しかし、人材が揃ってさえいれば各人の努力を統合するのはどちらかというと機械的に事が運ぶ。大抵のプロジェクトの成否は、チームが構成され最初にある方向に歩みだす瞬間からおおよそわかる。

プログラマの採用、辞めないことの重要性。

新プロジェクトに入れる人を評価する場合、プログラマーの静的な能力を重視しすぎるきらいがある。

例えばコーディングがどのくらいできるか、ドキュメントがどのぐらいかけるか、などである。プロジェクトに加えたい人たちの一人一人がどれだけグループ全体にうまく馴染むかにはほとんど注意を払わない。

生産性は、利益をコストで割ったものと定義すべきである。利益は作業時に節約できた金額又は仕事からの収益と見ることができ、コストは全体のコストつまり退職者の補充に費やした余計な費用を含むべきである。

マネージャーは製品を作る人を採用しようとしている。その製品は応募者が以前作ったものと同じようなものだと思っている。それなら応募者がやっている仕事の質を評価するために、それらの製品のサンプルを検証する必要がある。

退職率が30%以上と病的に高い会社の場合、退職のほとんどは次の理由で説明がつく。

腰掛けメンタリー:この仕事を長く続けようという雰囲気を同僚が醸し出さない

使い捨てにされる予感:経営者が社員を交換できる部品としか考えない

会社への忠誠なんて馬鹿馬鹿しいという意識:人を部品と思っているような組織に誰が忠誠心を持つだろうか?

退職が次の退職を呼び、その影響は深く静かに潜行する。社員が長く居付かなければ研修に金を使うのは意味がない。(中略)

企業が社員への投資を全くやらないので、会社を変えることを何とも思わなくなる。(中略)

企業が社員の優秀さを認めないという印象は、個人として評価されていないという感じを社員に抱かせる。同僚が次から次へと辞めていくと、翌年までやめないでいたら何か自分に問題があるような感じになる。

すでに必要な技能を持っている人を雇った方が安上がりだ。ほとんどの組織はそうやっている。しかし、最良の組織はそうはしない。

再教育がずっとい続けるという気持ちを育て、 結果として低い退職率と強いコミュニティ感覚を生むことを認識している。そして、それがコストの問題よりもずっと大切であることをよく認識している。

チーム。

実際の仕事では本当にチームワークが必要になることは極めて少ない。しかしそれでもなおチームは重要だ。チームは、メンバーたちを同じ方向に引っ張るための道具として機能するからだ。チーム編成の目的は、目標を達成することではなく、目標を一致させることである。

結束したチームは生意気で自己満足的で他人を苛立たせ排他的かもしれないが、交換可能な部品の寄せ集めよりもマネージャーの本当の目標のためにはるかに役立つことは間違いない。

日頃密接に連絡を取るべき人々を物理的に引き離すことは、どの道全く意味がない。(中略)

チームのメンバーを一緒にしておけば、チーム形成にとって必要な日常の何気ない会話を交わす機会も生まれる。

マネージャーレベルでは結束したチームはありえない。マネージャーがチームに入るとすれば、二つの役割、つまりマネージャーとチームのメンバーを兼ねる時に限られる。部下の一時的な同僚として、チームに受け入れられるのだ。

組織での地位が上がるほど、結束したチームの概念は薄らぎ、遠く忘却の彼方へ去ってしまう。

最後に

以前いた会社で、開発者が一斉に辞めてしまうという悲劇があったのですが、そこの経営層は、この本に書かれている「ダメな経営層」に驚くほど類似した行動を取っていました。

しかし、この本で良しとされる振る舞いをしていたように思えるマネージャーもその企業にいましたが、その人は残念ながら結果を出せずにすぐ辞めてしまいました。何が悪かったのだろうか。まあ、業務時間中に寝てたからな(笑)

なお本書は、実際の事例を多く交えて、経営層・マネジメント層が犯す過ちを記していくスタイルなので、少々長ったらしく感じる方もいると思います。

しかしながら要点は非常に明快であり、決して読みにくいものではありません。Amazonの評価は芳しくないようですが、 当てになりませんね。

冒頭にも書きましたが、より良い職場環境を作りたい人、より良い職場環境で働きたい人、どちらにとっても読む価値ありの良書と思いました。

ピープルウエア 第3版

ピープルウエア 第3版

  • 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
  • 出版社/メーカー: 日経BP
  • 発売日: 2013/12/18
  • メディア: 単行本(ソフトカバー)

【書評】提案=思い通りに物事を動かすための行為「ロジカル・プレゼンテーション」

「ロジカル・プレゼンテーション――自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」」を読みました。

実現したい事象について的確に考え、的確に伝えるための方法論、と言ったところでしょうか。

「伝える」方は割りとテクニック的な要素が多かったので、今回は「考える」方にフォーカスして読んでみました。

コンサルタントの方によって14年も前に書かれた本ですが、非常に読み甲斐がありました。

ロジカル・プレゼンテーション――自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」

ロジカル・プレゼンテーション――自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」

  • 作者: 高田貴久
  • 出版社/メーカー: 英治出版
  • 発売日: 2004/02/01
  • メディア: 単行本
  • 購入: 35人 クリック: 293回
  •  

 目次

はじめに
序章
第1章 提案の技術とは
第2章 論理思考力
第3章 仮説検証力
第4章 会議設計力
第5章 資料作成力
第6章 最終章

メモ

何のために提案するのか。

ほぼすべての人間が、ビジネスや学校生活、家庭生活などのあらゆるシーンで「提案しなければならない」局面に毎日のように立たされている。提案力のある人は自分の思惑通りに事を進められる場合が多いが、提案力の無い人は他人に押し切られてしまい、自分の意見が通らず、結果として損をすることも少なくない。

提案の内容は論理的でなければならない。

「どんな相手をも」理解させ、説得するためである。(中略)

初対面の人や文化の異なる人、自分と反対の意見を持っている人などに話を伝えようとした場合、前提がちがいすぎるので話が通じないことが多い。

論理的とはどういうことか。

縦と横が全部「ちゃんと」つながっていること。(中略)

縦に論理がつながった状態とは、「誰から見ても因果関係が理解できる」状態である。(中略)

横に論理がつながった状態とは、「誰から見ても全体がカバーされていて、漏れもダブりもない」という状態である。

縦の論理がつながらない、すなわち「AならばB」が通じない原因は何か。

1. 前提条件の違い(暗黙の前提は存在しないか?)
2. 異質なものの同質化(もっと細かく分けられないか?)
3. 偶然の必然化(前提から結論に至るまでに偶然の要因はないか?)

横の論理がつながらない、すなわち「漏れやダブり」が生まれるのはなぜか。

そもそも言葉のレベル感が揃っていないから(まったく違う話をしているのでよく分からないという状態)。

言葉のレベル感はどのように揃えるのか。

1. 視点を揃える(誰の目から見た表現なのか?)

2. 切り口を揃える(どういう場面を想定した表現なのか?)

言葉のレベル感が揃って初めてMECE(漏れ無くダブり無く)に考えられる。漏れをなくすためには、状況にあったフレームワークを用いる。

既成のフレームワークに従うというアプローチだけではこころもとない。自分でまったく新しいフレームワークを編み出せる発想力を持つことが重要である。

どのように新しいフレームワークを編み出すのか。

「六次元で発想すること」(中略)。目に見える三次元の世界のほかに、(中略)時の流れで一次元、情報や電気や取引や、そのほか目に見えない物の流れで一次元、最後は人間の気持ちや習慣で一次元。

ダブリをチェックするためには、著者考案の下記「MECEマトリクス」を用いる。

ダブっているかどうかを判別するために、二つの命題をそれぞれ縦軸と横軸に展開する。そして、縦軸・横軸それぞれにイエス・ノーと書く(中略)。

それぞれにイエス・ノーがあるので、二×二の四つの箱ができるが、それぞれの箱について「その状態が存在するのか?」を考える。

縦横の論理が完成したら、主張したい内容をピラミッド型の図で表現することができる。

縦横の論理の原則をきっちりと理解したうえでピラミッド・ストラクチャーを描けば、非常に説得力のある論理が展開できる。

論理的であると誰が決めるのか。

「論理がきっちりつながっているか、つながっていないかを決めるのは、あくまで話をしている相手側である」(中略)

自分の論理を信奉しすぎると、反省がないため自己成長ができなくなる。(中略)

本当に論理的な人は、相手が誰であっても話を理解させることができる。

提案のためには論理的に正しいだけで良いのか。

「論理的に正しい」からといって、「相手が納得する」とは限らない。(中略)

大事なのは、相手を納得させること、腹の底から理解してもらうこと、そして何か結果につながる行動を起こしてもらうことだ。(中略)

相手の疑問に答えないかぎり、相手はとうてい納得しない。

相手の疑問はどうやって特定すればいいのだろうか。

「仮説検証」がきちんとできることが必要(中略)

仮説検証は以下の五つのステップで進める。

(1)目的の理解(どのような意思決定を求めるべきかを理解する)
(2)論点の把握(相手の意思判断に影響を及ぼす項目を把握する)
(3)仮説の構築(論点に対する答えとなり得る事柄を仮で定める)
(4)検証の実施(仮説の正しさを客観的事実や論理で検証する)
(5)示唆の抽出(論点を細かく分解して、方向性を提示する)

論点に対して、完璧な答えが出せればすべてはうまくいくのであるが、実際は「答え」を出すことは難しい。(中略)

直接答えることをひとまず保留にして、「示唆を出す」ことに集中してみよう。(中略)

示唆を出すとは、「論点を絞り込むために役立つ情報を提供する」ことだから、まずは論点をさらに細かく分解して考え、そのいくつかの部分に答えようと考える。(中略)

うまく「示唆」が書ければ、直接的に論点に答えたり、仮説を検証したりする必要はないのだ。(中略)

論点を絞り込み、方向性を提示する「示唆」が書ければ、それで事足りるのだ。

自責の精神が成長に繋がる。

提案が通らないことを前提に発想すれば、自分が何を努力すればよいかという視点で前向きに物事を発想するようになり、自己の能力に磨きをかける原動力となる。

最後に

考える力とは、習慣というかクセに依るところが大きいと思う。なので、本書に書かれていることを日頃から常に意識しながら過ごしていこう。

ロジカル・プレゼンテーション――自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」

ロジカル・プレゼンテーション――自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」

  • 作者: 高田貴久
  • 出版社/メーカー: 英治出版
  • 発売日: 2004/02/01
  • メディア: 単行本
  • 購入: 35人 クリック: 293回
  •  

【書評】データを扱う際に持つべき心意気「会社を変える分析の力」

下記の書籍を読みました。2013年に書かれたものなので少々古いですが、データ分析を行う全ての人が読むべき名著ではないかと思います。

会社を変える分析の力 (講談社現代新書)

会社を変える分析の力 (講談社現代新書)

  • 作者: 河本薫
  • 出版社/メーカー: 講談社
  • 発売日: 2013/07/18
  • メディア: 新書

ざっくり内容

著者は大阪ガスでデータ分析をされてらっしゃる方で、本書は主に、意思決定者に対してデータ解析者はどのようなスタンスであるべきか、が書かれています。

意思決定ありき

そこでは一貫して「データ分析=数値計算ではなく、そこには目的が無ければならない。意思決定(問題解決)に役立てなければノーバリューなのだ」と説かれています。

当たり前のことじゃないかと思ってしまいそうですが、データ解析が仕事の重要な部分を占める方の中には、ついそのことを忘れて手段のことにばかり目が行きがちな方も少なくないのではないでしょうか。

解析の精度が何%上がったか気にするのはもちろん大事だけれど、そもそもその解析は何のために(どのような問題を解くために)やってるんだっけということを常に意識しなさいということですね。

「分析の価値」=「意思決定への寄与度」x「意思決定の重要性」

とは言え、意思決定者が問題を正しく設定できていないことも多いので、データ解析者がその妥当性を積極的に修正しなければならない場面もあるとのことです。そうすれば、役に立たず終わりそうだった解析結果が活きるということもあり得るでしょう。

データ解析者の持つべき当事者意識

そして著者は、解析だけ行って「はい、おしまい」という当事者意識の無い人間になるなと警告しています。分析の結果得た示唆をもとに、実際のビジネスを変えていくことにも責任を持ちなさい、ということです。

知的欲求を満たすことと、ビジネスや研究に役立つことは違う

意思決定者とは

そもそも意思決定者はそのデータ分析がどのような手法で行われたかということには興味がなく、彼らが期待することは下記の3つだそうです。

  1. この予測手法を使うことでどれだけの効果を期待できるか
  2. この予測手法を導入するのにどれだけの手間と費用がかかるか
  3. この予測手法を使うことで問題は生じないのか

データ分析の結果を意思決定に使えるか見極めるプロセスとは、「どれぐらい外れそうか」を推し量るステップと、「意思決定は、その外れを許容できそうか」を判断するプロセスに分けられます

また、著者は意思決定を行う立場の人のスタンスにも言及しています。意思決定者が以下3つの特徴を持っている場合、分析者がどれほど価値のある分析を行っても徒労に終わると警告しています。

  1. 不確実性の軽視(データ分析は絶対正しい唯一の答えを見つけ出すことができる)
  2. 分析への過剰期待(データ分析は意思決定に必要なすべての材料を得られる)
  3. 結果への事前期待(期待に反した分析結果を得た場合それを軽視する)

目次

第1章 データ分析に関する勘違い
(データ分析の主役;分析の価値;モデルは所詮プラモデル;ビッグデータとは何か?)

第2章 データ分析でビジネスを変える力
(「分析力」だけではビジネスを変えられない;
見つける力(問題発見力)
解く力(いわゆる分析力)
使わせる力(実行力))

第3章 分析力を向上させるための流儀
(四つの問いを自問自答してみる;正しい心構えを持つ;役立つことに貪欲になる;良い習慣をつける―分析者九ヵ条)

第4章 分析プロフェッショナルへの道
(分析プロフェッショナルとは?;分析プロフェッショナルへの道;分析プロへっしょなるという職業の魅力)

最後に

 というわけで、データ分析が仕事と言えど、その目的を常に意識し、問題の解決に貢献すべく必死になれ、ということでした。

 データ分析をすれば、何でも問題を解決できると考えている人もいますが、それは間違っています。そもそも、データ分析に使えるデータは限られているのです。(中略)
使えるデータが限られているのですから、どれだけ分析手法を駆使しても、問題を解決できない場合があるのです。(中略)
大切なことは、データ分析で解決できないことを悟った後のアクションです。目的に立ち戻ることが重要です。(中略)
そして目的を達成する別の手段を考え、それを実現するために必要な分析課題と併せて、ビジネス担当者に逆提案すれば良いのです。

会社を変える分析の力 (講談社現代新書)

会社を変える分析の力 (講談社現代新書)

  • 作者: 河本薫
  • 出版社/メーカー: 講談社
  • 発売日: 2013/07/18
  • メディア: 新書

 

【書評】Linux学習の初めの1冊「入門者のLinux」

Linuxの基礎はこちらの書籍で学びました。

以前RailsでWebサイトを作ったことがあるのですが、その際サーバのOSはUbuntuを使いました。なにせ初めてかつ独学での開発だったので、当初はCUIの操作方法や御作法がよく分からず苦労した記憶があります。

本書はそういったプログラミング初学者向けのLinux入門書と言えます。

入門者のLinux 素朴な疑問を解消しながら学ぶ (ブルーバックス)

入門者のLinux 素朴な疑問を解消しながら学ぶ (ブルーバックス)

  • 作者: 奈佐原顕郎
  • 出版社/メーカー: 講談社
  • 発売日: 2016/10/19
  • メディア: 新書

本書の対象者

とても分かりやすく書かれており、初めてLinuxに触れる方でも問題無く読み進めることができると思います。

文中では、随所に架空の初心者による著者への質問が挟まれており、できるだけ読者が置いてきぼりにならないよう工夫されております。

内容は、Linuxで何ができるのかというざっくりとしたイメージを掴めるレベルです。各コマンドに関する詳細な解説等はありません。

本書で感じ取ったLinuxの雰囲気をもとに、各コマンドを自身で調べながら実際に使って覚えていく、ということになるでしょう。

目次

第1章 Linuxとは?
第2章 Linuxを使ってみよう! でもどこで……?
第3章 シェル初体験!
第4章 ディレクト
第5章 ファイル
第6章 標準入出力
第7章 ユーザーと管理者
第8章 ワンライナーでプログラミングしてみよう!
第9章 awkを使ってみよう!
第10章 定番のテキストエディターvi
第11章 シェルをもっと知ろう
第12章 プロセスの管理と操作
第13章 応用!
終章 「Linux力」をつけるには?

最後に

 プログラミングを全く知らなかった頃の僕は、ターミナルで何か作業することがとても苦痛でした。

何をしているのかよく分からなかったのです。というより、分かろうとしていませんでした。面倒臭いなあ、と。

それが今では、CUIを操作することが楽しくて仕方がありません。コンピュータを好きになったからだと思います。人は変わるものですね。 

入門者のLinux 素朴な疑問を解消しながら学ぶ (ブルーバックス)

入門者のLinux 素朴な疑問を解消しながら学ぶ (ブルーバックス)

  • 作者: 奈佐原顕郎
  • 出版社/メーカー: 講談社
  • 発売日: 2016/10/19
  • メディア: 新書
  •  

【書評】Python学習の初めの1冊「みんなのPython 第4版」

Pythonの基礎は下記の書籍で学びました。 半年程前に一度さらっと読み、先日から再度読み始め、昨日精読し終えたので、理解した内容を整理する意味も込めて記事を書いてみたいと思います。

みんなのPython 第4版

みんなのPython 第4版

本書の対象者

本書はプログラミング未経験の方にもお薦めできます。なぜなら、極めてとっつきやすい構成となっているからです。

普通、まだ実際にコードを書いたことが無い人がプログラミングに関する参考書を読んでいると、これは一体何のために書いてあるんだ?と疑問に思ってしまう部分が多いのではないでしょうか。

つまり、実際の利用方法のイメージが湧かない記述が、読み進めることの障害となることがあると思います。それは僕の経験上、学習のモチベーションを著しく下げます。

本書はそうならないよう、内容の掲載順序や説明の仕方が良く工夫されているように思います。でありながら、「はじめての◯◯」といったタイトルの書籍にありがちな、フワッフワッとしたなんとなくの理解で読者を騙すようななんちゃって参考書とは一線を画しています。

そういう意味で、本書はとてもバランスの良い参考書であると言えます。

僕は元々RubyC#など他の言語に関する知識があったのですが、そうではないプログラミング初学者の方でも問題無く読み進めることができ、かつ、それなりに読み応えのある書籍ではないかと思います。

機械学習関連の記述

本書の第12章には、機械学習を行う際のPythonの活用法も書かれてあります。

内容は極基本的なものですが、実際のコードが書かれてありますので、最初にイメージを掴むのにもよいのではないかと思います。

目次と一言メモ

Chapter01 プログラミング言語Python
Pythonを学ぶメリット、環境構築(AnacondaやJupyter Notebookなど)

Chapter02 Pythonでプログラミングをはじめよう
組み込み型、変数、for文やif文、関数、モジュールなど、基本的な内容

Chapter03 Pythonの基礎をマスターする
ディクショナリ、set(集合)、タプルなどの組み込み型や、if文、ループ

Chapter04 組み込み型を使いこなす
前2章で学んだ組み込み型の使いこなし方

Chapter05 Python関数型プログラミング
Python関数型プログラミングを行う方法

Chapter06 クラスとオブジェクト指向開発
Pythonでのクラスの作り方、使い方

Chapter07 クラスの継承と高度なオブジェクト指向機能
クラスの継承、特殊メソッド

Chapter08 モジュール
モジュールの概要、使い方

Chapter09 スコープとオブジェクト
名前空間とスコープの違い、オブジェクトとアトリビュート

Chapter10 例外処理
Pythonにおける例外処理

Chapter11 標準ライブラリを使う
Pythonが標準で用意する便利なライブラリ

Chapter12 Pythonとデータサイエンス
機械学習含め、データサイエンスにPythonを用いることのメリット、基本的な手法

Chapter13 Python2
Python2とPython3の差異

最後に

僕の今後の学習方針としては、本書で学んだ基本的なPythonの使い方を以て、実際のコードをたくさん書いていきたいと思います。

その中で、書き方に疑問を感じた際は本書を辞書的に使うこともできそうです。

みんなのPython 第4版

みんなのPython 第4版