読者です 読者をやめる 読者になる 読者になる

真面目に、強く、上品に

たのしくげんきに!

良い人生とは何か

はじめに

出来るだけポエムを書かないように、普段は不必要な情報を削ぎ落とした文章を書くことを心がけています。

しかし、たまにはポエムっぽいことが書きたくなるもので、今回はちょっとポエムっぽいことを書いてみます。

テーマは「良い人生とは何か」です。

良い人生とは何か

良い人生とは何か、と問うた場合、人によって定義が変わるとは思います。

僕の場合、よい人生とは一言で言うと、「満足な人生」です。

「満足な」という形容詞もいささか抽象的すぎるし、人によって捉え方も違う言葉ではありますが、 自分で自分を「十分頑張った」と評価できることと私は定義しています。

では、十分頑張ったという実感を得るためには何が必要でしょうか。

それは、その時々でベストを尽くす、これに尽きると思うのです。

ベストを尽くすためには、やりたくないことでもやらなければならない時もありますし、一筋縄ではいかないこともあるでしょう。

ベストを尽くさない行動はより楽な行動ではありますが、十分頑張ったという自己評価を得ることが出来ません。

ここで勘違いしてほしくないのは、例えばしんどいから体を休める、鬱になったので休職をするといったことがベストを尽くさないということではないということです。

ベストを尽くすとは言葉の通り、その時々で目標を設定し、目標達成のために最適な行動を取り続けるということです。

例えばこれ以上働くと自分が鬱になってしまう、という自体になった人間が取るべき「十分頑張った」行動は、まず休息を取ることです。

ベストを尽くす、といった場合に目先の目標にとらわれてしまい、大局的な目標の達成から離れてしまうということはよくあることだと思います。

自分のリソースを適切に配分し、目標達成のためにどうやって行動するか、それを考え続ける必要があります。

ただそれさえ出来れば本人が良くない人生を送ってしまったと思うところは無く、あるのは「結果はベストを尽くしたけど、ダメだった。ただ悔いはない」という満足感だけでしょう。

実は私は今まであまり「十分頑張った」という実感を得たことは多くないのですが、そもそもの話として「十分頑張った」という実感を得るのは相当なハードルなのかもしれません。

何かしら障害がある人間は特にハードルが高く、「周りが普通に飛び越えている障害をなぜ私は飛び越えることが出来ないのだろう」という自意識を持ちがちで、それこそがハードルを押し上げています。

ただ、そういうハードルがあっても、目標達成を目指し続ける、それこそが人生における本質的な価値なのではないか、最近私はそう思います。

ちなみにですが、本人がベストを尽くしたと実感しているけど全く成果が伴っていない、という人を私はあまり見たことがなく、 なんだかんだベストを尽くすということは成果に直結するし、基本的に例外はないのではないかと考えています。

今後も私の人生で色々な困難が待ち受けているとは思いますが、その時々で「十分頑張った」行動をし続けることを意識していこうと思います。

「プログラマのためのDocker教科書」を読んだ

概要

プログラマのためのDocker教科書」を読んだため、章毎の感想とまとめについて記述する。

対象読者

導入編でインフラ・ミドルウェアの基礎的な知識について解説があるため、非プラグラマでも最低限UNIXコマンドが使用できるならば読み進めていける。

導入編

インフラ・ミドルウエアの基礎知識、コンテナ仮想化技術とDokkerについての解説が主だった内容。

前半については既にソフトウェアエンジニア・インフラエンジニアであるならばこの辺りの内容は既に把握していることが多いため、場合によっては飛ばして良いと思う。

ちなみに私は確認のために一応読んだが、忘れているところもあったので、読んでよかったように思う。

後半はコンテナ仮想化技術とDockerについて。

Dockerの概要についてわかりやすくまとめられている。

とりあえず、VirtualBoxなどのホスト型仮想化、XenServerなどのハイパーバイザー型仮想化はOS以上のレイヤーについて仮想化を行うのに対して、Dockerの仮想化はKernel以上の仮想化を行う、ということさえ覚えておけば最低限問題がない。

基本編

Dockerのコマンドの解説が中心。

分かり易いがこの辺りはDockerのチュートリアルのほうが、陳腐化しないという点で良いかもしれない。

Dockerを使いこなす上で結構大変なのが、コマンドの階層が深い・コマンドが多いことにより、操作に慣れるまで時間がかかるということ。

コマンド操作はぱっと出来るようにしておくためにも、自分が参照し易いドキュメントを固定するのが重要であると感じた。

応用編

Docker Composeを使ったリソース管理や、マルチポスト環境でのDocker運用、クラウドでの適用方法などより実践的な内容が記述されている。

ただしDockerという進化の早いミドルウェアの性質上、ドキュメントも陳腐化しやすいことは留意しておく必要がある。

まとめ

進化の早いDockerではあるが、ここまで体系立ててDockerの解説をしている書籍は珍しいのではないかと思う。

この本でさっとDockerの内容を把握して、以降は公式ドキュメントを追っていくのがベターであると感じた。

「自衛隊メンタル教官が教える心の疲れを取る技術」を読んだ

概要

自衛隊メンタル教官が教える心の疲れを取る技術」を読んだため、章ごとの感想とまとめについて記述する。

ムリを無くす

ムリの段階には三段階あり、段階が進む毎に心身への負担は大きくなり回復しにくくなる。

そのため出来るだけ初期段階で休息を取ることが、ムリを無くすことに不可欠である。

以上の筆者の主張は当然ではあるが、非常に納得のいくものであった。

ムリをすると休息をしなければならないという当然のことさえ、意識を向けることが難しくなってくる。

常に自分が疲れているかどうか、疲れているならどの段階であるか、ということを常に意識することが重要である。

ムダを無くす

現代人は本質的な生命の危機に脅かされころが少なくなり、対人関係など生命の危機には直接関係ないところで感情疲労をする機会が多くなった。

またインターネットやそれに付随するSNSの発展で個人の受け取る情報が過多になり、必要以上に感情の無駄遣いをする機会が増えたというのが筆者の主張。

この主張に対しても大いに同調できる。

そもそも情報の取捨選択が難しい場合には、SNSを断つなども効果的であるように思う。

ムラを無くす

ムラが発生する主要因は以下の2つというのが筆者の主張。

  • 過去の失敗経験
  • エネルギー不足

この章で説明のあった、「満足7:不満3」での現状評価は是非試してみたい。

これはどういうものかというと、あるタームごとの自己評価を必ず「満足7:不満3」の割合にするというものだ。

もし失敗続きで不満の割合が大きいときは、本当に些細なことでも「満足」の項目に入れることで、「満足7:不満3」にする。

この割合にもちゃんとした理由があり、満足が大きすぎると改善するモチベーションが減退し、逆に満足が少なすぎると自信が喪失してしまう。

自分に自信をもちつつ改善活動も出来るちょうどよい比率が「満足7:不満3」というわけだ。

そしてこの評価を続けることで、過去の失敗経験も記憶から相対的に少なくなり、自信が定着し、ムラが減る。

このロジックは大変素晴らしいと感じたため、個人の習慣としていきたい。

まとめ

心の疲れを取る技術とはすなわち以下のことを習慣づけるということである。

  • ムリを無くす
  • ムダを無くす
  • ムラを無くす

精神論には頼らずにシステムでどのように心の疲れを取るかということが実践的な内容で記述されており、納得の出来る内容だった。

Vue.js雑感

概要

Vue.jsを使用した雑感について記述する

Vue.js雑感

日本語の公式ドキュメントがちゃんと整備されており、宣言的レンダリング機能により、APIを呼び出して取得した値を定義しデータにバインドするだけで、おおかたの機能が実現できる。

jQUeryベースだと、自分でレンダリングするタイミングを制御しなければならなかったため、これはものすごく書きやすい。

また周辺ライブラリが揃っており、コンパイラで強いlintをかけつつ開発出来たりといった、ツールによる制約を活用しながら実装を進めていきやすい。

現在はSPAでVue.jsを使っているが、SPAは仮にスマホなどでクライアントを作ることになったとしてもSPAのAPIがそのまま使えるので、そのSPAがVue.jsでは書きやすいので、今後はSPAでの開発が主流になっていくことは容易に想像できる。

気分の落ち込みに対する処方箋

概要

気分の落ち込みが発生したときの対処方法について記述する。

気分の落ち込みはこころの風邪

よく言われることであるが、「落ち込んでいる」という事象が永劫続くということは少ない。

誰しもがかかりいつかは治るという意味で言うと、風邪に近い。

体質によって風邪が引きやすい人、引きにくい人はいるが、生活習慣の改善で風邪をひきにくくすることはできる。

風邪を引いたからといって自分はだめな人間だと卑下するひとは少ないだろうが、こころの風邪についてはことさら自分を卑下してしまう傾向があるように思う。

そのため心の風邪を引いてしまった時は出来るだけ早めに「心の風邪をひいている」という自覚を持ち、早急に治すことだけを考えれば良い。

風邪の場合は自分をことさらにいじめることは少ないが、こころの風邪の場合は必要以上に自分をいじめてしまい、療養期間がいたずらに伸びてしまう例が多い。

そのため、単なる気のもちようではあるが、こころの風邪を意図的に風邪という事象におきかえることで、必要以上に自分をいじめる習慣を少なく出来ると考えている。

こころのもちようというのは難しいものであるが、気分が落ち込んでいるという自覚を持ったときに、この記事について思い出してくれれば幸いだ。

2017年度の目標設定

概要

難易度が高いかつ2017年度中に実現可能性がある目標を設定して記述する。

2017年度の目標

2017年度の目標は 「github.com/ymizushi でstar数100以上のプロダクトを作る」に設定した。

star数を100以上取るための戦略

広報

いくら良いプロダクトを作ったとしても、人に知られないことにはstar数を稼ぐのは難しい。

出来るだけそのプロダクトの存在を知って貰う必要がある。

プロダクトの存在を知ってもらうためには、以下の二通りの方法がある。

  • プロダクト自体の広報
  • プロダクト開発者の広報
  • 技術記事での広報

プロダクトを知ってもらうためには、開発者のフォロワーを増やし、共有する方が効率が良い。

技術記事のアウトプット先としては以下のものが考えられる。

技術記事は日本語とさらに英語でも行うことが出来ば、海外からの流入も望める。

需要のあるプロダクトを開発する

当然ながら需要の無いプロダクトにstarはつかない(例外的にネタ的なソフトウェアに対して大量のstarが付くこともあるが、ここでは含めない)ので、需要のあるプロダクトを作る必要がある

トレンドを抑える

前章の「需要のあるプロダクトを開発する」とも関連するが、トレンドの技術ではないプロダクトは既に需要が満たされているか、そもそも需要のなかったかのいずれかであることが多い

(このあたり、スタートアップが開発するサービスと似ているかもしれない)。

そのため、出来るだけトレンドに沿った技術のOSSプロダクトの方がstar数をより多くもらえる可能性が高い。

便利なものを作る

便利ではないものにstarは付かない。

需要のある言語で開発する

需要が全く無い言語で開発しても意味がない。

需要が無いという表現は、限定された市場に対して需要がない、という意味だ。

例えば、clojureはそれほどユーザ数が多いわけではないが、他の言語ではよくあるライブラリーだが、clojureでは今まで誰も実装していなかったプロダクトであればstarはつきやすい。

需要に対して供給が少ない、あるいは無い領域を見つけて開発するのが得策である。

短期間でリリースする

スタートアップと同じだが、自分が解決したい問題は、他の人も同じように解決したいと思っていることが多い。

ここで重要になるのは、リリースまでのスピードである。

リリースまでの期間を短くしつつ、コードのクオリティや使いやすさをどこまで追い求めるかが鍵だ。

まとめ

2017年度中にgithub上でstart100以上を稼ぐというのは、容易なことではない。

しかし、定量的に設定できる目標として1年で絶対実現不可能なことではないので、目標設定としては悪くないと考えている。

方針としては、業務を進める上で実装が必要になったツールなどをOSSとして切り出して公開することを考えている。

技術ドキュメントを読む際に意識していること

概要

技術ドキュメントを読む際に、如何に要点を素早く抑えてインプットをするかで仕事の効率は大きく変わる。

ドキュメントの読み方については、巷に読書術の書籍が多数溢れていることから分かる通り、絶対的な正解は無く、人によって最適な読み方は変わる。

ここでは現在の私にとって最適なドキュメントの読み方を整理して記述する。

いきなり全部読もうとしない

ドキュメントを読む上で最も意識していることは、いきなり全部を読もうとしないということだ。

全部読みきることができず、本質的な学習を出来ないまま終えることが多い。

数学など積み上げ型の学問の場合は、今学習している範囲をちゃんと理解していないと次に進めない、あるいは本質的な理解が得られないまま進んでしまうということもあるが、大抵の技術ドキュメントはそこまで積み上げ型の知識は要求されない。

目次と章毎の要点をつかむ

技術ドキュメントを読む過程においては、全体を把握してどこに必要な情報があるかという情報のマップをインプットすることが重要だ。

ここである程度全体を把握していれば、詳しく調べたくなった事柄が出てきたときでも、どこに必要な情報があるかの見当をつけることが出来る。

目次をざっと読んで、その章の最初とまとめを読むことで、章毎の概要と情報のマップを脳に入力する。

公式ドキュメント以外は基本的に読まない

非公式ドキュメントは一度書かれるとそのまま更新されないことが多いため、情報がすぐ陳腐化する。

またその質もまちまちであるため、何よりも情報のマップを構築するのが難しいため、情報を収集するコストが大きい。

公式の技術ドキュメントはチュートリアルやリファレンスが既に整備されていることが多く必要な情報も探しやすい。

多くは簡易な英語で記述されているため、英語に抵抗感さえ抱かなければ日本語と比べてそれほどコストが大きいものでも無い。

理解していないところだけを読む

技術ドキュメントにおいて殆どの情報は、必要なときに適宜参照すれば良い情報であり、読んだとしてもすぐ記憶から消えてしまう。

このような情報のために集中力と時間を使うのはあまり効率的ではない。

ここで意識することは、理解していない点を明確にして、理解していないと自覚したところのみ集中して時間を使うということだ。

自分が理解していない点を明確にする作業は意外と難しいが、自分の場合は、「単元ごとに1キーワードを設定して、そのキーワードをホワイトボードを使って説明できるか」ということを理解しているかどうかの基準にしている。

ホワイトボードでよどみなく説明できるなら理解しているということだし、説明できないなら理解していないということである。

理解していることと理解していないことについて明確に基準を設ける。

理解しにくい点があったらサンプルコードを打ち込む

これの適応範囲は限定的だが、サンプルコードを打ち込むことにより、インプットとそれに対応するアウトプットのパターンを圧倒的に増やすことが出来る。

インプットを自由に設定出来ることで、自分の理解していない点を対照実験から明確化出来るため、理解のスピードは劇的に早くなる。

まとめ

現状の私の技術ドキュメントを読む上で意識していることは以上の通りだ。

前述したとおり、人によって最適な読書法というのは、その人の性格や経験によって左右されるものであるのであるので、私自身にとって今後絶対的なものでないことを留意しておく必要がある。

「仕事のミスが絶対なくなる頭の使い方」を読んだ

概要

「仕事のミスが絶対なくなる頭の使い方」を読んだため、その要点について記述する

要点

仕事のミスには以下の4つがある

モリーミスの基本対策

「記憶はすぐ忘れる」ということを意識することが重要である。

いかに忘れることを前提に行動出来るか、ということがメモリーミスをなくすコツである。

覚えるべきこと・頭に留めておくべきことは全てメモしそれを見返すことを習慣化させる、などが具体例としてある。

大雑把にまとめる

例えば本を読んだ場合に、本に書かれた内容を全て記憶出来る人は一部の例外を除いていない。

重要なのは本毎に大雑把なまとめを覚えておくことである。

本毎に大雑把なまとめを覚えておくことで、まとめを思い出す過程で、詳細についても関連して思い出すことが出来る。

語呂合わせで覚える

数値や特徴があまり無い単語は暗記が難しいが、その場合は語呂合わせが有効。 直接語呂合わせがしにくい単語については、適当な数字から文字への変換ルールを決めておくことで、語呂合わせを適用することが出来る。

アテンションミス

ちゃんとみようとしない

ちゃんと見ようとすると、細かいところしか視野に入らないため、俯瞰して全体を見通すことが困難になる。 細部を注意してみる時間と全体を見渡す時間は全く別々にしたほうが良い。

フレームワークで対策

何か特定の作業を行おうと思った場合、ルーチンや定石といったお決まりのパターンがある。

ルーチンや定石を使用している間はワーキングメモリを専有せずに、妥当な行動をとれる。

妥当な行動をしつつワーキングメモリの領域を大きく取ることが出来るので、アテンションミスを減らすことが出来る。

集中できない時は書き出す

集中できない時はメモに現在思考していることを書き出すことで、悩んでいたことが整理され、ワーキングメモリを開放することが出来る。

見直す癖をつける

見直すことを習慣化させることで、作業中には気づかなかったミスに気づくことが出来る。 また、見直しのたびに別の確度から見ることを心がけると、今まで気づかなかったミスについても気づくことが出来る。

チェックリスト

チェックリストを用意することで必ず確認しておかなければならない箇所が視覚化され、作業者に対して以下を軽減する。

  • 作業内容を覚えないといけないというプレッシャーと忘れたらどうしようという不安
  • 作業内容を実行せずに忘れてしまうリスク
  • 作業が進んでいないのではないかという不安

TODOリスト

何をすべきかを思い出すことが出来る。 これにより、しなければならないのにするのを忘れていた、というミスを低減できる。

シングルタスクにしていく

人間は常にシングルタスクでしか作業が出来ないので、出来るだけシングルタスクに集中できるようにする。

同時並行で進めなければいけない状況や、突然のタスクが割り込まないように、タスクをキューにいれたり、といった工夫を行う。

ゾーンに入る

最も効率的にシングルタスクをこなすのが「ゾーンに入る」こと。

ゾーンに入ることで、無駄な雑念が取り払われ、真にシングルタスクの状態で、効率よく仕事を進めることが出来る

集中力を削ぐものを排除する

ブラウザやスマホのプッシュ通知など、雑念となるものを取り払う。

仕事に問いをもたせる

問いは人の注意を一点に集中させることが出来る。

ある事柄をより大きな事柄の一部として認識させることが出来る(このことをチャンクアップと呼ぶ)

やるべきことを明確化

抽象的な内容のタスクはモチベーションが湧きにくい。

タスクを分解することで自分がやるべきことが明確になってきて、ゾーンに入りやすくなる。

達成できるかギリギリのところで目標を設定する。

物事は簡単すぎたり、難しすぎたりするとモチベーションが低下する。

そのため、適切な目標設定を行い、常に達成できるかギリギリのところで目標を設定する。

コミュニケーションミス

自分の認識している前提と相手の認識している前提は違う

常に相手の記憶に意識の矢印を向ける。

無知の姿勢を心がけることで、自分の思い込みが排除される。

復唱によって自分の理解度を確認する。

ジャッジメントミス

利用可能性ヒューリスティック

都合の良いデータだけをとって全体がそうであるかのように錯覚する

今自分がしようとしていることとは真逆のことを考える

「起業と会社経営の実務がよくわかる本」を読んだ

概要

ダンゼン得する 知りたいことがパッとわかる 起業と会社経営の実務がよくわかる本」を読んだため、感想について記述する

感想

会社は当然ながら、事業活動により利益を出すことを目的に組織されている。

そのため、会社経営の実務はお金に関することが大半を占める。

起業・経営の実務としての代表例は以下の通りである。

  • 登記
  • 資金繰り
  • 経理
    • 税金
    • 保険
    • 給与
  • 人事

この全ての要素でお金が絡んでくるため、経営においては、常に取引はもちろんのこと、社内のお金の流れについても注意を払う必要がある。

この書籍では上記に挙げた起業・経営で絶対必要な最低限の知識について、網羅的に解説してくれている。

この本の知識だけで会社は作れるため、起業自体は物凄くハードルが低いことであるということが実感できる。

起業自体のコストは出来るだけ少なくし、事業に集中できることが望ましい。

信用について

概要

ある事象を信用するか信用しないかという選択を迫られた時の判断基準について考える。

判断基準

前提として、間違ったことを言ったことがない人間は一人としていないということ。

間違ったことを言うパターンとしては以下の2種類である。

  • 意図して間違ったことを言うパターン
  • 意図せず間違ったことを言うパターン

意図して間違ったことを言うパターンの代表例が詐欺であり、詐取目的で間違ったことを相手に伝える。

意図せず間違ったことを言うパターンの代表例は、ネズミ講の勧誘などだろう。 本人は間違ったことをしている認識は無いが、その仕組みで末端の販売員が儲かる、と吹聴するのは間違ったことである。 このようなパターンでは理解・情報不足により、合理的でない判断をしていることが多い。

以上のことから、今まで十分な情報が与えられており信頼性の高い言説を唱えていた人が、突然満足な情報が得られず間違った言説を唱えてしまう、ということは容易に発生する。

そのため、人"に対して信用するかしないかという判断をするのは危険であり、信用は人に対してではなく、個別の言説に対して設定しなければならない。

そして、個別の言説に対して常に正しい判断を下すためには、以下のことが重要である。

  • 状況を把握するのに必要十分な情報を揃える
  • 得られた情報の合理性や妥当性を検証する
  • 足りない情報を予想する
    • 情報は多すぎても少なすぎてもいけないが、情報は足りていないことが多い。その時には足りないピースを予想するしかない。今までの経験と論理から足りない情報を予測する。
  • 揃えた情報とリスクから合理的な選択をする
    • この場合、期待値が高いというわけではない。 目的のためには、あえてリスクが高い選択をしなければならないときがある。

まとめ

信用とは人に対してするものではなく、個別の事象について設定するもの。

思考放棄せず、その時々でしっかりと信用できるか検証しなければならない。

メンタルの強さはレイヤー毎に違う

概要

メンタルの強さとはどういうことかを考える過程において、

対象者が置かれている状況のレイヤーに応じてメンタルの強さが変わるのではないかという仮説が出てきたた。

ここではその仮説の整理と検証を行う。

メンタルの強さとは

一言にメンタルの強さと言っても判断する人によってメンタルの強さについての定義がばらつきそうであるため、一旦ここでメンタルの強さについて定義を行う。

メンタルの強さとは以下の要素で構成される。

  • 剛性
    • 自分や他人の思考・行動、物事に動揺しない
  • 弾性
    • 動揺しても元の状態にすぐ復帰できる

一番良いのは、剛性が高いかつ弾性が高いことだ。

剛性が低いが弾性は高い場合、一時的にメンタルは弱くなるがすぐ元の状態に戻ることが出来る。

この場合、大きなストレスを受けた場合でも復帰が早いというメリットがある。 ただし一時的にメンタルがとても弱ってしまうため、リアルタイムで重要な判断をしないといけない場合に判断ミスを犯しやすい。

剛性が高いが弾性は低い場合、ある閾値まではメンタルは強いがある閾値を超えると途端にメンタルが弱くなる。 リアルタイムでの判断は得意だが、耐えられないほど大きなストレスが来た場合に一気に潰れてしまうというリスクがある。

この2つは一長一短あるため、どちらが良いかは一概には言えない。

レイヤーとは

上記で定義したメンタルの強さはレイヤーごとに強さが違う。

そのレイヤーは主に、「社会的レイヤー」と「生存的レイヤー」の2つである。

「社会的レイヤー」でのメンタルの強さとは、社会生活を営む上でのメンタルの強さであり、 「生存的レイヤー」でのメンタルの強さとは、生命を維持する上でのメンタルの強さである。

例えば、生存が脅かされずに大企業で働く場合に必要なメンタルの強さは「社会的レイヤー」でのメンタルの強さに該当し、 戦争やゾンビの跋扈する世界で生き残るメンタルの強さは「生存的レイヤー」でのメンタルの強さに該当する。

メンタルの強さはレイヤー毎に違う

メンタルの強さ、レイヤーについて定義したが、本題はここからである。

一般にメンタルの強さと言った場合、レイヤーなど考えずに強いか弱いかでしか表現しないことが多いが、 実際は「社会的レイヤー」と「生存的レイヤー」でメンタルの強さは分けたほうが良いと考えている。

分けずにメンタルが強い・弱いと考えてしまうと、例えば「生存的レイヤー」では物凄くメンタルが強いのに、その強みを活かしきれずに自分はメンタルが弱いと思い込んで行動してしまう可能性がある。

パフォーマンスを出すためにはメンタルの強さというのは必要不可欠であり、「社会的レイヤー」でメンタルが強い人間は組織の中でその強みを活かしていくべきだし、「生存的レイヤー」が強い人間は傭兵や起業家など「生存的レイヤー」でのメンタルの強さが必要な領域でその強みを活かした方が良い。

「20代で身につけたい 営業の基本」を読んだ

概要

営業もやることになり、とりあえず基本となる営業テクニックを身に着けたいと思ったため、Aamzonで比較的評価が高めだった本書を読むことにした。

ここではその本の要点と感想をまとめる。

要点

  • 商品を売るのでなく、経験を売る
  • 営業のプロセスを「見える化」する
    • 日付、担当者名、課題、ネクストステップ、目標とする期日が記載されたTODOリストを書く
  • 大きい数字は小さい数字に分解する
    • 大きい数字も細かく分解することで現実的な目標に設定出来る
  • うまくいっているときほど新規開拓をする
    • ツイているときほど+αの目標に取り組む

感想

構成としては、営業マンが実践すべきことが箇条書きで並べており、項目毎になぜそれが必要なのかが述べられている。

項目によっては営業に限らず汎用的に使える習慣も記載されている(06 営業ノルマ以外に「自分自身の目標をつくる」など)。

営業を身につけるためには必ず実践が必要だが、どのようなことを意識して営業を経験していけば良いのかという指針になった。

ただ欠点もある。

箇条書きで読みやすい反面、体系的に営業とは本質的にどうであるべきか、といった体系的な理論としてまとめられていない。

体系的な知識を身につけるには、また別の営業の関する書籍を読む必要があると感じた。

「ゼロ秒思考」を読んだ

概要

友人から問題の整理のために実践することをオススメされたため読んだ。

ここではそこで得られた知識、感想、まとめについて記載する

ゼロ秒思考とは

ゼロ秒思考とはかいつまんで言うと、1分1ページで毎日10ページメモを書くことで得られる迅速でかつ深い洞察が出来る思考法だ。

メモのフォーマットは以下の通り。

  1. メモの上部にはタイトルと日付を記入する。
  2. タイトルについて考えた内容を4行ほど箇条書きで記入する。

行動としてはこれだけだが、続けることで問題を瞬時に整理する能力を獲得出来る、というのが著書の論旨だ。

メモを書くことで思考が整理される

ゼロ秒思考と大層なタイトルがついているが、本質は以下の通りだ

  • メモを書くことが思考が整理される
  • メモを書き続けることでちょっとしたことでも根底に流れる論理について深く考える癖がつく

これにより今ままで整理したことがない問題についても、過去の経験とその整理の仕方の対応関係から、 瞬時に問題を整理することが出来るようになる、と考えられる。

感想

「言葉を的確に使う」、「浅い思考・空回りの思考を避ける」の章が大変参考になった。 今まで上記のことが杜撰で、そのために齟齬や時間のムダが数多く生まれていた。

今までよりも徹底してメモ書きを行い、常に頭が整理されている状態にする必要性を強く感じた。

まとめ

  • メモを書くことで思考は整理される
  • 常に思考が整理されている状態を保つため、新しい問題に瞬時に対応出来るようにするためにメモを習慣化する
  • ちょっとでも行き詰まったり、考えが堂々巡りをしている、又は考えが浅いと感じたときはすぐさまメモで思考を整理する

Amazon CAPTCHA

「Yコンビネーター シリコンバレー最強のスタートアップ養成スクール 」を読んだ

概要

「Yコンビネータシリコンバレー最強のスタートアップ養成スクール 」において、スタートアップを運用していく上で重要と思った点、印象に残った点についてまとめる。

失敗する条件

  • サービス開発において必要でない、または重要度が低いことに時間をかけている
    • サービス開発に関係ないことはすべて捨てる覚悟が必要
  • 創業者が親友同士ではない
  • 創業者にハッカーがいない

スタートアップ創業者に必要な5つの資質

  • スタミナ
    • 寝る、食う以外をすべてプログララミングに捧げられるスタミナ
  • 貧乏
    • 貧乏というムチを当てられているのでなければスタートアップのストレスに耐える気にはなれない
  • 根無し草性
    • 移動を厭わないこと
  • 同僚
    • 親友、同級生、信頼できる同僚
  • 無知
    • スタートアップに纏わる苦難を深く認識していないこと

成功の確度が高いスタートアップの条件

金鉱を掘るよりもつるはしを売れ

一般人向けのサービスを認知・スケールさせるためには、莫大な資金が必要であり、最も難易度が高い。

「金鉱を掘るよりもつるはしを売る方が儲かる」という格言通り、直接一般人に使ってもらうサービスではなく、 一般人に使ってもらうサービスを開発している企業向けのサービスを開発する方が筋が良い。

人が欲しがるものを作る

顧客のいる市場で勝負する。

顧客第一で考える。

スタートアップにおいて重要なこと

周囲にスタートアップがたくさんあり、起業が日常化されていること。

周りが失敗を恐れないこと。

環境によってスタートアップの命運が左右される。

常に成長率に目を光らせ、設定した目標はなんとしてでも達成する。

契約はなんとしてでも成立させるl

打たれ強くなる。

ポール・グレアム曰く

  • 「急いでローンチしろ」
  • 「市場が君たちをクビにする」
  • 「セールスアニマルになれ」
  • 「常に成長率に目を光らせろ」
  • 「他の連中より真剣に考え抜いた点だけが優位性になる」

最も重要なこと

成功者は最初から成功者であったわけではなく、スタートアップを経る過程で成長して成功者になった。 現在の状態は関係なく、必要なのは強い意志とプログラミング能力だけ。

機械学習をツールとして使えるようになるまで

概要

機械学習をツールとして使えるようになるまでに学習すれば良いことをまとめる。

何を学習すればよいか

機械学習フレームワークPythonで書かれているものが多いので、Pythonをある程度読めると学習が早い。

機械学習フレームワークはWebフレームワークなど違って、ある程度裏側で動いている仕組みを理解しないとツールとして使うことも難しい。

機械学習を学習する上で前提となるのは、理系大学教養課程における初等解析学線形代数学の知識。

機械学習フレームワークを使う上で必要な数学的知識