目的
エンジニアとして働く際に効率的（＝少ない時間で最大限インプットしたものをアウトプットできる）に学ぶための手法や考え方をインプットするため。
一言でいうと、どんな本？
主にエンジニアが実践している勉強法ー効率的に学び、内容を整理してアウトプットし、自分の”モノ”にしていく技術について、紹介された本。
印象的だった箇所（ベタ張り）と所感
情報収集について
大雑把に情報収集できないなら、片っ端からやるしかありません。大雑把な全体像の把握ができない状態は、理解を組み立てるための材料が足りていません。大まかな説明を読んでも頭の中でイメージが湧かないなら、イメージするための知識がそもそも欠けているのです。【・・・】しかし、最初は「何から学べば効率が良いか」を判断する材料すら持っていません。そこで足踏みをしないで、まずは材料を手に入れることが必要です。
▶️判断材料がなくて、「何から手をつけていいかわからない！」時だからこそ「手当たり次第探りまくれ！！」という考え方が大事と思われた。そこに躊躇してはいけないのだなと。
情報収集の3つの方法
遅延評価的学習法
YAGNI原則
Matzのソースコードの読み方
遅延評価的勉強法とは？
本を1ページ目から読んでいくのではなく、目的を分割して、目的に必要なところから飛び飛びに読んでいきます。そうやって断片的に集めた情報が、ジグソーパズルを組み上げるようにあとからつながっていく、という考え方
▶️普通なら上から順番に取り組んでいくが、目的から逆算して必要なところだけを抑えて学習を進めるのが大切。しかし、それができるのも、次に示す前提条件を満たしてこそ。
知りたいところから学ぶための前提条件
1.目標が明確化されている
2.目標が達成可能である
3.大まかに全体像を把握している
ソースコードを段階的に読むには
- 内部構造解説したドキュメントがあればそれを読む
- ディレクトリ構造を読む
- ファイル構成を読む
- 略語を調査する
- データ構造を知る
- 関数どうしの呼び出し関係を把握する
- 関数を読む
※『Rubyソースコード完全解説』注20序章の「ソースコードを読む技術」より引用の引用
▶️最初に関数の意味は何か、考えようとしていたけど、その前に、今のディレクトリ構造や関数同士の呼び出し関係をちゃんと理解しているか確認してから実装進めたいと思った。エラー▶️関数の確認、よりも、エラー▶️そもそもAからBに何をしようとしたんだっけ？と確かめてから実装入る、などかな。
抽象化のコツー「比較」について
新しいパターンを発見するには、「同じ」でも「違う」でもない、一部同じで一部違う「似ている」ものどうしを比較する必要があります。
共通部分を見つけるのはとっつきやすいのですが、「あれも似ている、これも似ている」と単に情報を集めただけにもなりやすいです。ある程度慣れてきたら、違いに注目したり、一見矛盾しているように見えるものについて考えると、考えが進みやすいです。
この「違っているぞ」「なぜ違っているのだろう？」「よく考えたら違っていなかった！」のサイクルを回すことで、一歩一歩階段を上がるように考えを進めていくことができます。
「作る前はどうだったのか、今とどう違うのか」を考えることで、「なぜそれを作ったのか」が見えてきます。
▶️1つの言語の概念（配列・ハッシュ・インスタンス変数・オブジェクト思考・・・etc）を理解する際に、様々な観点で比較してみると、理解度がさらに固まると感じた。
パターンから学ぶこと＆理解を検証すること
パターン本は、具体的な経験からあなた自身がパターンを見いだすことを手助けすることはできますが、あなたが具体的な経験を持たないままパターンだけ習得することはできないのです。
箱が床に置かれたのか、ちゃんと積み上げられたのかを知るために、次の3点に注意してみましょう。
・自分の言葉で説明できるか？
・自分の経験に基づいた具体例を挙げることができるか？
・自分の目的を達成するためにその知識を使えるか？
やる気を出すには？
やる気が出ない人の６５%はタスクを1つに絞れていないとのこと。ポイントは3点。
❶GettingThingsDone：まずすべて集める
❷全部集めて、そのあとで処理をする
❸優先順位は、緊急度✖️重要度で
※２分以内に片付くものならすぐやる方が良い
参考になった文章を引用。
GTDでは、まずは「気になること」を全部1ヵ所に集めます。人間はあまりたくさんのことを一度に覚えておくことができません。覚えていられる以上のことを覚えていようとするとその負担からストレスが生まれ、認知能力が低下します。そこで、まずは「やるべきことはすべてここに集まっている」という状況を作り、それによって「やるべきことを覚えておかないといけない」というストレスから自分を解放するわけです。
物が多すぎて部屋が散らかっている状態と、気になることが多すぎて頭が混乱している状態は似ています。そして部屋が散らかっている人向けのよくあるアドバイスの一つが、「とにかく片っ端から捨てろ」です。
もう一つのアドバイスは、「まず基地を作れ」です。私はこれを高く評価しています。「部屋全体」を片付けることには時間がかかるので、まず領域を区切って、その場所だけは「片付いている状態」にしようという方法です。こちらは「基地＝片付いている領域」が手に入ったことが達成感を生みます。また、基地が手に入ると日々の作業が効率的になり、余剰の時間が生まれ、それを基地の維持・改善に使うことができます。そうやって基地が片付いている状態を維持しつつ、徐々に基地の使い勝手を向上していくわけです。
U理論ーいわゆる「変化」は、どのようなフローで発生していくのか？をモデル化
❶Downloading：思い込みにとらわれて外界を観察していない状態
❷Seeing：外界を観察しているが、自分の既存の枠にしがみついて、他者の視点から情報を感じ取れていない状態
❸Sensing：他者の視点から情報を感じ取り、自分の既存の枠が壊れたが、「自分」を手放していない状態
❹Presensing：「自分」を手放し、未来の変化の可能性を見ている状態注12
❺Crystallizing：アイデアが結晶化された状態
❻Prototyping：試作品（プロトタイプ）が作られた状態
❼Performing：アイデアが既存のシステムに組み込まれ、機能している状態
アイデアを引き出す問い
彼らは、相手の中にあるメタファをなるべく歪めずに引き出すために、「前提を含まない質問」（クリーンな質問）を整備しようと考えました。彼らの定式化した基本5質問が以下です。
❶そのXはどんな種類のXですか？
❷そのXについて、ほかに何かありますか？
❸そのXはどこにありますか？
❹そのXはどのあたりにありますか？
❺そのXは何のようですか？・それから何が起こりますか？
・次に何が起こりますか？
・そのすぐ前には何が起きますか？
・それはどこから来るのですか？
シンボルについて（SymbolicModelling）
明確化されたメタファー（隠喩：〜のようだと使わない意味での例え・・・「雪」のことを「白い肌」と使ったりすることね）のことをシンボルと呼ぶと、その関係性を明らかにする質問は下記の通り。
シンボルの関係を明らかにしていく質問は以下のとおりです。
・XとYはどういう関係ですか？
・XとYは同じですか？違いますか？
・XとYの間には何がありますか？
・（Xが出来事のとき）Xが起きたとき、Yには何が起こりますか？
悩み
悩んでいるということは、現時点のあなたの知識では、どれも同程度の評価であるということです。ならば、どれを選ぶことも現時点では同等に正しいです。判断の締め切りまでに時間があるなら「判断を先延ばしにして情報収集をする」という意思決定も一つの手でしょう。しかし、多くの場合、いくら情報収集をしてもどの選択肢が正しいかは確定しません。どこかのタイミングで、正解がわからないままエイヤと選択肢を選ぶことになります。そして時間が経ってから選んだ結果を振り返ってみて、その選択が有用であったなら、その選択は正しかった、と事後的にわかるのです。
▶️意思決定において、選ぶ時点では何が正しいかなんて分からない。やった後に結果を振り返って正しかったか、そうでなかったかが分かるもの。だから同程度に悩んでいる時間が続いてしまうのであれば、どっちでもいいからとりあえず”選ぶ”ことが大事。
本の学び＆実践することを箇条書きで
✅学びの基本：具体▶️抽象化・モデル化▶️実践・検証▶️応用（これってメモ魔と同じような発想だよね）に沿ってアウトプット重視の学習を継続すること。
✅やる気がどうしても出なければ、既存タスクを段取りごとに分解して、ちょっとでもできそうな所からやってみる。
✅新しいことXを理解するために、要素を分解して、コードを書いたり比較しながらイメージを固めていく学び方を実践。