Masteries

技術的なことや仕事に関することを書いていきます.

最近読んだ本たち

転生したらスプレッドシートだった件

転生したらスプレッドシートだった件

転生したらスプレッドシートだった件

カクヨムから生まれた初の技術評論社の書籍, 「転生したらスプレッドシートだった件」を読みました. 著者は id:minemuracoffee 先生.

仕事でExcelやGoogle Spreadsheetをバリバリ使いこなしているぜ! という方には物足りない内容かもしれませんが, これから使い始める人, 或いは適当に(他の人が作ったシートを参考にしながら...)使っている人にとってはためになる知見が得られそうと思います. ラノベ形式なのでサクサク読める点もありがたいです. ラノベ形式なので(?), 登場人物たちが関数を技名のように呼ぶわけですが, カタカナで呼ぶのは最初「なんとなくダサい感じがあるな...」と思ったりしていました. しかし, よくよく考えると「この関数を口頭で説明するときにはこう呼べばいい」というのがわかって逆に便利(?)だ, という事に途中で気付きました.

...あと,お恥ずかしい話ですが, これまで例えば「A2以降全て」みたいな指定をするときに, A2:A1000 みたいなのをたくさん書いてましたが, これA2:Aとすると良い, というのはこの本で知りました...

個人的には, 索引というか, 「この機能はこの章で取り扱っています」という一覧があれば良かったかな, という気はしています. まあ, 自分の場合は電子書籍版(Kindle)で購入したので, それで検索したら良いのでは? という気はしますが...

外資系コンサルが教える 読書を仕事につなげる技術

同僚の, どなたかのブログで紹介されていて, 面白そう! と思ったところ, Kindle Unlimitedで読めたのでサクッと読んだ本.

著者は外資系コンサルの方なので, 書かれている内容が自分たちのようなエンジニアにそのまま流用出来るか... というとそうではないのですが, その元となる考え方とかは参考になりそう, と思いました.

例えば, ビジネス書において「ビジネス書は狭く深く読む」/「教養書は広く浅く読む」と良い, と紹介されていますが, これをエンジニアに例えるなら「ビジネス書」は言語やアーキテクチャの解説書籍(例えば, 「初めてのPerl」や「エリック・エヴァンスのドメイン駆動設計」など)は狭く深く, 「教養書」は例えば「WEB+DB PRESS」や「Software Design」などの雑誌, 或いは「リーダブルコード」など特定のテーマに沿った本として捉えて, こういったものは広く深く読むと良い... のかな? とか考えることができました.

後は, 割と本を読む時はなるべく全部読もうとするのですが, 「2割だけ読めばいい」と書かれていたのも印象深かったです. この辺りは, ビジネス書や教養書だけでなく, エンジニア向けの本でもそうだと思っていて, なんとなくわかっているつもりでも実践出来ていないのですよね...

ちなみに, 「うまく2割を読む方法」としては, 「目次を見る→総括, 結論といった章があれば読む→これを踏まえて面白そうな章の冒頭を読む」と進み, ピンと来なかったら手を出さない... という方法が紹介されています. 本, 買うと「もったいない」という気持ちで読み進めようとしてしまうので(いつも積んでるのに...), こういう考え方は試してみたいと思いました.

既に読書習慣が構築できていて, うまく本を通してインプットが出来ている人からすれば「そうっッスね」という内容かもしれませんが, そうでない人にとってはいろいろ気付きがある本なのかな, と思いました. そのまま真似をするのではなく, これを参考に仮説を立てて, いろいろ試してみる... という感じで今後の読書に取り組んでいけたらいいなー, と思いました.

他にも...

戦略思考コンプリートブック

戦略思考コンプリートブック

  • 作者:河瀬 誠
  • 発売日: 2003/07/10
  • メディア: 単行本(ソフトカバー)

人生は、運よりも実力よりも「勘違いさせる力」で決まっている

人生は、運よりも実力よりも「勘違いさせる力」で決まっている

  • 作者:ふろむだ
  • 発売日: 2018/08/09
  • メディア: 単行本(ソフトカバー)

去年から今年にかけて, 上記を含めていろいろ本を読んでいたのですが, 感想をまとめるのを忘れてしまっています. 読みながら/読んだ後すぐに感想とか書かないと, どんどん揮発してしまうので気をつけたいですね. せっかくなので折を見て読み返してみたいと思っています.