○月に読んだ本というエントリを何回か書いていたけどあれがうまく機能したのはBOOKSCANへの電子書籍化の依頼があったからだと思う。依頼のおかげ読んだ本を毎月整理するタイミングがあった。しかしその後、電子書籍化してから読むというシフトチェンジをしたのでその月に何を読んだかというのをあまり振り返るタイミングが無くなった。毎月書くのは面倒なので年単位で書くのはどうだろうかと思い立った。何冊かは紹介済みだけど気にしない。
「メモ書き」について書かれた本。この本読んでからノートを大胆に使うようになった。実際、どこから手をつけていいかわからないときとかとりあえず気にせず書いていくと進められることが多い。頭が良くなるかどうかは知らないけど仕事はできるようにはなる。
多くの場合、なんの遠慮もなく書き出していくと、最後の頃には少しだけ気分が晴れる。
いろいろ回り道したが、結局、頭の整理には「A4用紙へのメモ書き」が一番効果的であることがわかった。
お金を使って失敗しないと成長しないよという本。この本読んでからまた物欲に目覚めた。でも、２つとも欲しいという状況には全然遭遇しなかった。投資という意味でお金を使うことは惜しまないもののPS4のように本当に要るのかというのをじっくり考えることも怠っておらずそのバランス感覚はどこから来ているのかは自分でもよくわかっていない。
一方でiMacと二つの机と椅子を並べるということをしてみたがここ最近の自宅での開発集中っぷりを考えると思い切ってお金を使って正解だったと思っている。失敗してもそれも勉強と思えばと何にでも価値相当のものを得られていると実感できる。
節約は好奇心を失わせる、節約に美学があったのは国内全般にお金がたりない時代
好きなもの、ほしいものを買うというのが働くモチベーションになる
ほしいものを値段を見て止めてはいけない、美しいものは買うべきなのだ。買っても使わないかもしれないがそのリスクを背負うべきだ。
ゲームというより作者のマルクスについて書かれた本。この本を読んでいたので買収時にマルクスが会社やMinecraftから離れることになったのは理解できた。エンジニアであってもビジネスも理解しないといけないと言われる一方で、ビジネスを無視して自分の作りたいものを作るということに徹する熱意も持っておきたいと思う。
今日のマインクラフトがあるのは、自由な実験ができたおかげだ。そこにはゲーム開発者は芸術家であるという哲学が存在する。つまり、この会社を成功に導いた原動力は頑固さと自由であって、事業計画やPR戦略ではないのだ。
モニターに目をくぎ付けにして、暗い部屋で一晩中座りつづけることができないプログラマーは、真に優秀なプログラマーになれない。トレーニングに打ち込めないサッカー選手がズラタン・イブラヒモヴィッチになれないのと同じ理屈だ。
タイトルで誤解を受けそうだけど他者から嫌われなさいという直接なことは書いていない。言わんとする所は他人の評価を気にしすぎないで自分の価値観や判断基準をしっかり持ちなさいということだと思う。印象的だったのは他人を意識して自分の行動を決める人のほうが自分勝手だという意見。同じことでも他の人が良いと思えば肯定し、悪いと思えば否定する行動にでるので自分の意思がなくそれは自分勝手だという主張。
今年からSNSから距離を置いてブログでも人に読まれる記事よりも自分が書きたいことを優先していたのでその方向に進むのが正しいと思わせてくれた面がある。
問題は世界がどうであるかではなく、あなたがどうであるか、なのです。
もしも比べるべき他者が存在しなければ、わたしは自分の身長が低いなどと思いもしなかったはずです。
もし、「わたしは学歴が低いから、成功できない」と考えているとすれば、それは「成功できない」のではなく「成功したくない」のだと考えなければなりません。
もし、本当に貢献感が持てているなら、他者からの承認はいらなくなります。わざわざ他者から認めてもらうまでもなく、「わたしは誰かの役になっている」と実感できているのですから。つまり、承認欲求にとらわれている人は、いまだ共同体感覚を持てておらず、自己受容や他者信頼、他者貢献ができていないのです。
嫌われる勇気と若干似ている。F1ドライバーであるキミ・ライコネンの「Leave me alone, I know what I’m doing」や孔子の「君子は和して同ぜず小人は同じて和せず」といった言葉好きなんだけど、内容はそれに近い感じ。
孤高であっても孤立だけは避けるべき、自分勝手でもよいから人々（社会）の中に入ること
好奇心をもつ、素直になる、肯定的に考える、この３つがあれば1人でもやっていける
自主ルールを達成できなかったときに言い訳（理由付け）をしないでケロッとしていればよい、言い訳を始めると人は怠け者になる
あまりエンジニア向けの本を紹介していないのでとりあえず印象に残ったものを1冊選択。しかし、どちらかというとエンジニアよりかはマネジメント層が読むべき内容だと思われる。本にも書いているがわかっていても実践するのは簡単なことではない。
大切なのは優秀な人が「何を知っているか」ではなく、「これから何を学ぶか」だ。
なぜなら組織を事業部、あるいはプロダクトライン別にすると、それぞれの事業部が自分のことだけを考えるようになり、情報や人の自由な流れが阻害されるからだ。
誤解のないように言っておくと、「世に出してから手直しする」アプローチはあとで改善することを前提に、質の低いプロダクトを送り出してもいいという考え方ではない。