エンジニアの知的生産術について
詳細については以下のサイトを参照してください。
Scrapboxで著者ページを公開しているの、珍しいですよね!
目次のダイジェストや「はじめに」が公開されています。
購入するか悩んでいる方は一度みてみると良いかと。
感想
いわゆる「勉強の仕方」というものを期待して読みましたが、
それ以上に得るものがありました。
読んでみて自分がこれはいいな!と思ったことをあげていきます。
やる気について
勉強するにあたってそもそもやる気が出ないという問題があります。
勉強する気、出ないですよね?
この本の中でも第2章を割いてやる気について書かれています。
特に良いと思ったのは以下の内容。
- やる気は貴重なリソース
- ゴールは明確に
やる気をリソースとして捉えるのがなるほど!と思いました。
優先順位大事!
またITエンジニア的にはよくある、PHPを勉強するぞ!みたいなゴールはマズイ例です。
どうなったらPHPが勉強できたのか?が不明確だからです。
なにか入門書を読んでみるとか、アプリを1個作るとか明確なゴールにしたほうが良いです。
なお本書には必ずやる気が出る方法は書いていませんが(そんなものは無いと思う)、
やる気が出ない原因がいくつか書かれています。
その原因について、本書ではやる気を出す対象であるタスクに着目しています。
(後述するTODOリストの作り方もその原因の一環です)
もし「やる気が出ないんだよねー」と思っているがその原因を説明できない方は、
一度本書を読んでみる事をオススメします。
それでも説明できなければ別の原因があるのかもしれません。
本の読み方について
私は本を読むのが好きなので基本的に全ページを読みます。
他に読み方があるなんて思っても見ませんでしたが、
本書には他の読み方も紹介されていました。
その中で取り入れようと思ったのは、
「大まかに読んで気になるとこはだけ詳細に」です。
まずは目次だけすべて読んで気になる所だけ中身を読むとか、
全ての章見出しだけ読んでみて気になる所はさらに中身を読むといった方法です。
無限に近いほど本がある世の中で読める量を増やすには、
自分に必要な部分のみ読むという考え方です。
私は目次を読む、ということはまったくしていませんでした。
購入前に何が書かれているか?という観点では見ますが、
いざ本を読むとなったらどうせ全て読むので目次は飛ばしていました。
ブログなどもなるべく必要な部分だけ読むようにして、
インプットする量を増やしていこうと思います。
TODOリストについて
TODOリストについて、本書だとやる気の出し方に関連して説明されていました。
ですが、本項目ではTODOリストについてだけ思ったことを書きます。
TODOリストを作る際、やろうと思った事を集めると思います。
このとき「判断」と「集める」を両方すると効率が悪くなります。
やること候補を書き出す→やる/やらないを判断する→やること候補を書き出す…
ではなくて、
やること候補を書き出す→書き出す→...→書き出し終わったら判断する
とすることで効率的に「集める」事ができて「判断」することが出来ます。
「集める」と「判断」を交互にするとコンテキストスイッチによって効率が悪くなり、
やること候補が埋もれたり、判断を誤ったりする可能性があります。
自分もやる事をリスト化するとき頭の中で考えながらやると「判断」もしてしまうので、
紙でも電子でもまずは書き出してその後「判断」するようにしたいと思います。
この考えをもっと詳細に説明したものとしてGTDが紹介されていました。
Getting Things Done
集める 考える やる。
他にも様々な考え方が掲載されていたので、
TODOリストを作るのが苦手な人は読んでみると良いと思います。
効率の良い学習方法(記憶術)
これは一番自分が学びたいと思った点です!
本の中で取り入れたいと思ったのは以下の内容です。
- 間違えたらすぐ復習、覚えられていたら時間を開けて復習
- 問題が優しかったらさらに時間を開けて復習、 難しかったらすぐ復習する
- 間違い続けるものはレベルが合っていない可能性があるので一度外す
本書の中で紹介されている方法としてライトナーシステムがあります。
例えば単語カードで英単語を覚える場合、
1日、3日、7日、1ヶ月と期間を分けます。
覚えられた単語は期間が長くなるように、
間違えたものは短くなるように分類します。
これにより覚えられた物は期間が長くなり、
間違えたもののみ集中的に学習できようになります。
英単語を覚えるときに簡単な単語ばかりだとやる気が無くなります。
can, why, have, drive, eat...など中学で学ぶような単語は多くの方が覚えているでしょう。
復習する期間を調整することで効率的に学習できるようになります。
また、上記のように簡単な単語はさらに長い時間にする(外しても良いかも)ことで、
難しい単語を集中的に学習できるようになります。
繰り返し間違えてしまうものに多くの時間が取られてしまうのであれば、
効率化のために一度あとまわしにしてしまうのも手です。
どうしても今覚える必要があれば他に何か問題がないか考えてみると良いかも。
何かと勘違いしているとか、間違った別の情報と紐付いてしまっているとか…。
切り取ってきた桜の枝のような根のない知識
靴底は地面との摩擦によってすり減る。
摩擦とはどのようなものですか?
この質問に答えられるかどうかによって、
「摩擦」という言葉をなんとなく使っているか、
理解して使っているかが分かります。
「靴底が地面の小さいデコボコと擦れることですり減る、これが摩擦だ。」
と答えられれば摩擦という言葉の具体的なイメージがあなたの中にある、ということです。
「摩擦は摩擦だ。」
もしこんな解答であれば、
それはあなたにとって、切り取ってきた桜の枝のような根のない知識ということになります。
これは理解度を試すにはアウトプットしたほうが良い、ということの典型的な例だと思います。
学習していることが「切り取ってきた桜の枝のような根のない知識」にならないように、
積極的にアウトプットして根のある知識にしていきたいと思います。
顧客からタイムマシンを作れと言われた
これは他人と意見が食い違った時は情報獲得のチャンスである、という文脈で出てきていました。
この話を読んで情報獲得が上手くできなかった別の「タイムマシン」話を思い出しました。
それはTwitterで見たのですが、
ある忙しいデザイン系の会社でWindows PCがフリーズして作業が吹っ飛んだそうです。
作業が飛んだデザイナーは「タイムマシンがあればなぁ、なんでタイムマシンが無いんですかね?」と愚痴を言いました。
忙しいのにふざけていると感じた上司は「何がタイムマシンだ!」と感情的になり、
そのデザイナーは辞めてしまったそうです
私もWindowsしか使っていなかったので知らなかったのですが、
MacにはTime Machine(タイムマシン)というバックアップ機能があるそうです。
上記のデザイナーはずっとMacで作業してきたのでタイムマシンが当たり前でしたが、
上司はずっとWindowsだったので知りませんでした。
本書の中でも顧客が欲しい「タイムマシン」は、
上書きしてしまったファイルの上書き前のファイルが欲しい、ということでした。
上記のTwitterの話も「タイムマシン」ではなく「バックアップが欲しい」ということだったのですが、
デザイナーも上司もお互いに情報獲得ができずに不幸な結果になってしまいました。
自分も視野が狭まるというか物事を1方向から見て判断してしまう事があります。
「意見が食い違った時は情報獲得のチャンス」を意識して行きたいです。
自分が知らないということを知らないのは盲点
この言葉は「学びたい対象を探す探索戦略の項目」で出てきました。
これは自分の経験談に通じるものがあり、
事あるごとに発信している「知ることは大事」ということに繋がると思います。
そしてこの概念自体を知らない人は盲点になっているわけですね…。
知らなければ目指さない、知らなければ対策しない、知らなければ楽しめない。
すべてはまず知ることから。
理想を知れば目指す、問題を知れば対策できる、知ったら楽しめる。
当たり前のように毎日仕事したりネットしたりしていますが、
「知ること」を意識すると意外と新しい発見があると思います。
いままではそのまま流していた事に興味を持ったり、
深掘りして調べるようになったり…。
「知ること」が「楽しいこと」になると毎日がちょっと楽しくなると思います。
ちなみに自分が知ることは大事だと思った話については以下のLTで話しました。
資料を貼っておきますので、興味がある方はどうぞー。
docs.google.com
(だいたいP11あたりからその話が出てきます)
おわりに
エンジニアの知的生産術を読んだ感想でした。
本の感想って難しい…。
単に思ったことを書いていくのが自分にとっても参考にする人にとっても一番良さそうだけど、
どうなんだろうか…。
エモい話にしたほうがより刺さりそうではありますね。
(本を読んでこういうエモい効果があった!みたいな)
まだまだ"積読"の本がたくさんあるので、
継続して読んで感想をアウトプットしていきたいと思います。
