付箋用ダイジェスト

エンジニアの知的生産術 反響まとめ

エンジニアでなくとも読むべき良書

エンジニア以外にクリエイターやライターにもおすすめ

焼き直しでもなく、寄せ集めでもなく

目的のためにうまく組み合わせて実践されていて再現性があります。

中心的なテーマは「学び」

いかに読み、いかに記憶し、いかに考えるのか

「やる気を出すには」のような裏方的な話もきちんと押さえられている

実践的な内容

学びというものの捉え方

学びのサイクルモデル＋知識ブロックの積み上げのモデル

第5章および第6章は、いわゆる「知的生産の技術」の話。

情報や発想に興味を持つ人でも楽しめるだろう。

タイトルには「エンジニアの」と銘打たれているが、もう少し広い読者を受け入れられそうな本である。

本書が面白いのは、本の中で書かれていることを実践しながら著者が書き進めているという点

曖昧な記述を極力減らし、具体的な定義と事例、参考文献に基づいた論を進めようという節が読み取れる

本書で紹介されるメソッドには見知ったものも多く、読み飛ばしそうになった

しかし、他の本の記述とまったく同じわけではない。

ならば、「共通点は何か、違いは何か」ということから、学べることはあるはずだ。

「知的生産術大全」とでも呼ぶべき書籍

豊富なリファレンスをベースに知的生産に関する事項を網羅的に扱う

個人的なお勧めの読み方は「自分の興味のある所から読む」

7章「何を学ぶかを決めるには」は、かなり重要なテーマ

ここに踏み込んだ書籍はあまり多くない

エンジニアリング要素は排除してもよいのでは？

ソフトウェアエンジニアの感覚を出発点にしている

共感しにくい（わかりにくいというのともまた違う・・）

知的生産をする人間として必要なエッセンスが凝縮された一冊

毎日アウトプットしていくために必要なことはなんだろうか？

運によってもできることは変わる

できないことを後悔してもしょうがない

新しいことを学ぶには

Doneを具体的に定義する

タスクを適度に細かく区切って、達成感をこまめに味わう

知りたいことから学ぶ(遅延評価的勉強法)

効率的に読むには

本を読む前に自分への質問を作り、一読したのちに回答する(読む目的を明確化)

読みたいときに読みたいところから読む

現状あまり知識や経験がなく手っ取り早く楽をしたいだけの人にはオススメできない

今まで言語化できていなかった事象や経験が｢そうそれ!そういうこと!｣ってなるのは個人的に心地よい

もっと時間を掛けて本書を理解したい

第1章。設計技法の説明がわかりやすい。

抽象⇒具体的な対象から注目すべき点を抜き出す

モデル(模型)⇒対象の複雑さを説明するための簡素化

モジュール⇒コードを扱いやすく分割

型(クラス)⇒データ構造(の隠ぺい)と有効な操作(の公開)

エンジニアの知的生産術読んで、やっぱり知的生産術は自分で作り上げていかないといけないと再確認できた

タイトルにエンジニアとあったが、エンジニアはあまり関係ない内容が多かった

新しいことを学ぶときは写経するのがいいという点はエンジニアにあてはまる。

読んで満足することも多いけど、自分も写経するようにして勉強していこうと思う

全体的にどうにも頭にうまく入ってこない箇所が多かった。

哲学的な話っぽくてわざと難しく書いているような感じ。

比喩とか例えとかもよく書いてあったのだけど、それもよく分からなかった。

必要になったところを学習する

すごくエンジニアらしいし、効率的だと感じた

後半で、今やっている仕事の効率化から始めるのが良いという知識の拡大再生産戦略が提案されている。

エンジニアに限らず、学びたいけどやる気が出ない、学び方に詰まっている人にオススメできる。

特にどうやって情報を集めるか、インプットの部分で参考になる箇所が多かった(人によって変わると思う)

今まで何かを勉強するぞ、となるとつい体系的に学ぼうとしてスピードを意識していなかった

どうやって取り組むことを発見するのか、というのがまだはっきりしていない。

学ぶことの技術と実践が詰まっている！

問題を設定し、パターンとモデルを作り、検証する、サイクルを回していこう

エンジニアの知的生産術めっちゃ脚注多いから組版が大変そう

エンジニアが普段心がけていることが体系的にまとめられ、論理的に理由付けされている

書籍そのものから得られる新しい学びも勿論価値があるけど、既に持っている思想を言語化して理由付けしてくれる書籍も凄く貴重だ。

思考の言語化

理由づけ

0から書いたり理解するための材料が自分の中に乏しいのでもちろん開発スピードも遅く、一人で勝手に落ち込んでいるのですが、これはあれだな、先日読んだ「エンジニアの知的生産術」でいうところの、モデル化ができていない状態で情報収集・検証を行なって、当然上手くいかずに失敗している状態

15年くらいの知見を圧縮した若者向け高速道路本。だけどお年寄りにも向いている。「GTD」と「アジャイル・サムライ」と「7つの習慣」になんとなく共通点あるよなって感じが、具体的な言語化されていて学びがある

あんまり腹落ちした感覚がなく

わたしにはまだ早かったのかな

数年寝かせて、思い出したときにまた通読しようかな。

KJ法の「語彙のネットワークを構築し直す」「フレームワークを更新して展望を切り替える」みたいな発見の面白さに焦点が当たっている部分がよかった。

一旦忘れる、気になったら勉強再開する。

「5章考えをまとめるには」、思考整理のノウハウが書かれてるけど、やり方がまさにボトムアップでモデリングする、ソフトエンジニアリングそのものだと感じた。

トップダウンで先に分類作るのは後になって分類困難なものが登場して良くない、というのも納得。

まだぱらぱらっとしか読んでないけど、凄い本だ。 学ぶということを究極に体系立てている。

学びがうまくいかない、あるいはもっと効率よく確かな方法で学びたい全ての人に有益な本。

「エンジニアの知的生産術」もそうだけれど、試行錯誤した経験がある人のほうが腑に落ちる内容が多いと思う。

逆引きシリーズみたいなものかな？

今まで自分が試行錯誤でやっていた学び方が間違ってなかったことの裏付けがもらえた感じ

プラスアルファの改善の方向性をもらえた感じ。

また適宜参照しようと思う。

第6章の「アイデアを思いつくには」は他の章に比べると腹落ち感が少なかった。

これまで、どちらかというと自分のアイデアを発想するよりは、人のアイデアや既存のアイデアを具現に落とし込む仕事が多かったからかもしれない。

知的生産技術カタログとしては、類書も多いけど、本書はそれぞれが具体的

著者に一貫した思想があるのが伝わってよい

ポモドーロテクニック

KJ法

シングルタスク

目標の細分化

検索学習（テスト効果）

メタ認知的読書法

もはや一般常識だと思ってしまうときもあるのだけど、けっこうみんな知らないし実践してないんだよなあ

関連

先週の土日に読み終えた

今日改めてページをめくりつつ気になったところを思い出しながらScrapboxに書いている

時間がかかる

4章まできたが理解が噛み砕けていないところがちらほらあった

納得した形で出し切れるようにしたい

8章まで読み返してscrapboxにメモ取ってみたけど、量が不足しているな。

発想法とまとめ(KJ)に関して個別に試してみる必要がある。

学びたいものが多すぎるので取捨選択する方法を考えてみた話

…に対するReplyに対して「詳細を公開したら？」というReply

どうなんでしょー？ 結局人やライフスタイルによってやり方を変えていく(銀の弾丸はない)しかない気もするので、公開して効果あるかどうか…

エンジニアの知的生産術を読んだら自分でやってることが良い感じに言語化されていたので これを渡せば良い

公開して効果があるのって結局公開の過程で言語化した本人だったりするかもですね。

内容としては、全然エンジニアの人以外でも読める

記憶するには、思い出しながら内容を試すのが一番定着するとのこと

自分で例題を出して、どういうことか説明できると理解が早まる

実際にするのは難しい

『独学の技法』と『エンジニアの知的生産術』を読みました。大きく共通する部分はアインシュタインの思考プロセスをかなり参考にしている点。

エンジニアの知的生産術、読了。今まで自分が試行錯誤でやっていた学び方が間違ってなかったことの裏付けがもらえた感じだし、それにさらにプラスアルファの改善の方向性をもらえた感じ。また適宜参照しようと思う。

一方で 第6章の「アイデアを思いつくには」は他の章に比べると腹落ち感が少なかった。これまで、どちらかというと自分のアイデアを発想するよりは、人のアイデアや既存のアイデアを具現に落とし込む仕事が多かったからかもしれない。

「エンジニアの」というタイトル、印象は「エンジニア"のための"本」

しかし実際は一般的な内容「自分はエンジニアではないから対象読者ではないんだ」と考える人がいるならもったいない

本当のところは筆者に効いてみないとわかりませんが、「エンジニア"による"知的生産術」のほうがしっくりきました。

大きすぎて分割出来ないなら時間で区切る。

どうも大きなプロジェクトに取り組めないと思ってたが・・・それか。

Javaではコンストラクタは継承されないんね。Rubyのinitializeみたいにはいかんのか

西尾さんの「エンジニアの知的生産術」にもあったけど、どこが違ってどこが同じかを意識して勉強するのが良いなぁ。

うちが上手くいったなぁ、って思う奴は自然とそういうパターンで勉強できていた気がする。

"写経が必要ないと感じるのは新しい分野に挑戦していないから。"

これほんとそうだなぁと思ってて、今機械学習勉強してるけど、未知の領域過ぎて、写経しないとほんまにわからへん・・だんだんわかってきたけど。

読書をしている間頭の中は他人の思想を駆け巡ってるだけで自分自身は考えていない。読書ばかりしていると考える力が衰えて愚かになる

先週の面接で自分の書いたコードを隅から隅までちゃんと説明しきる事が出来なかった反省…。まだまだ、目標とするところとの溝があるなぁ。

1.自分の言葉で説明できるか？

2.経験に基づいた具体例をあげられるか？

3.目的を達成するためにその知識を使えるか？

プログラムは大抵、期待と違う動きをする。なぜ違う働きをするのか？疑問を解明して、何度も修正して、プログラムは正しい動きをする。人はこの試行錯誤の過程をあまり他人に見せない。

彼は天才だなと思うことがあるのだとしたら、表面的な部分しか見ていないから。

プログラミング能力は、情報収集→比較してパターン発見→実践して検証（期待とギャップを発見）を繰り返すことで得られる。

これは他の勉強においても同じだな、と思う。最初の情報収集で満足してわかったつもりになってしまうから、学びが活用されない。

当たり前だろみたいなことがちゃんとまとまっててなんかやりたいのになにをやればいいかわからん人には勧められる

他の人が言ってるとおりエンジニアは全然関係なかった。

学びのサイクルの情報収集->公理化->論理化->検証のループで公理化にかなりのセンスがいるんじゃなかろうか

プログラミングの勉強は短いサイクルで公理化、検証出来るけど、設計業務は規模の大きなものは中々携わる事が出来ないから設計の勘所、自分の中での公理をどうやって構築すればいいんかな

公理と検証をパッと結び付ける事が出来ると良いんだけどね

「エンジニアの知的生産術」の中に、読書の目的に 1.娯楽 2.情報を見つける 3.理解を組み立てる の3種類があるという記述。今読んでいる本をその基準に当てはめて考えるとどのタイミングで読むか？とかまとまってくるのでおすすめ。

例えば「エンジニアの知的生産術」は2と3の傾向が強めなので、一日に一定の時間を確保しながら読む、必要になりそうな順にトピックをつまみぐいしていく。メモを取る。

娯楽目的で買った本を肩の力を入れて読みすぎるとつまらなくなるし、必要な知識を手に入れるために買った書籍をダラダラ読んで積んでももったいない。「知的生産術」のおかげとのこの辺りのグラデーションを意識できるようになった。

エンジニアの知的生産術読んで、やっぱり知的生産術は自分で作り上げていかないといけないと再確認できた

「エンジニアの知的生産術」読んでてなるほどと思うところはあるのだけど「で、俺はこれをやるのか?」と考えると…… orz

ちょうど、本の読み方に迷っていたので、この迷いに近い論点が提示されててよかった。

ぼくみたいなCS専攻してない、大学行ってない学歴コンプレックスある人には良さそう。

デザインパターンとしての、ドアパターンってなんかわかるんだけど笑う

今まで自分が試行錯誤でやっていた学び方が間違ってなかったことの裏付けがもらえた感じ

それにさらにプラスアルファの改善の方向性をもらえた感じ。

また適宜参照しようと思う。

エンジニアの知的生産術の第1章。設計技法の説明がわかりやすい。

抽象⇒具体的な対象から注目すべき点を抜き出す

モデル(模型)⇒対象の複雑さを説明するための簡素化

モジュール⇒コードを扱いやすく分割

型(クラス)⇒データ構造(の隠ぺい)と有効な操作(の公開)

プログラム言語の話は具体例としてスルーすれば、知的生産に関わる人はだいたい「あー、あるある」って感じ。

根性論や過度に合理的な人間の前提に立ってなくて、普通のやる気からいかに仕組みで生産性を向上させるか考えられてるのが良い

「エンジニアの」って表現やめた方が良いと思う。完全に万人向けだし読書で苦労した身なら痛いほどわかる話が載ってる。学生時代にあったらどんだけ救われたか分からないくらいに素晴らしい。

知的「生産」術だと、アウトプットの方を想定してしまいますが、これはむしろインプットを効率的に行う方法の章が充実してますね。下手な読書術とか突飛な学習法とかそういうものはなく、ちゃんと経験に基づいて書かれた素晴らしい本だと思います。

買って目次見てつまみ食いした限りだが、既存知識の補強と再確認になる感がある

全ページめくる

読書法ピラミッドの一番最初が「読まない」なの笑えるし「読んでない本について堂々と語る方法」って表現がそれだけで最高感ある

「優先順位って大事だけどそもそも難しいんだよ」→「1次元じゃないとソートできないし」→「確率的不確定要素あるとさらに無理があるし」→「そういう際には楽観的にやれよ」の流れ大好き

有効読者はタイトルから受ける印象より広そうです

エンジニアの知的生産術読んでからインプット・アウトプットの方法を変えてみた。しっかりアウトプットが出来るよう試行錯誤して自分に１番合う方法を模索しよう

エンジニアの知的生産術という本を読んでるんだけどこれ別にエンジニアに限らないな……

試行錯誤とか学びのサイクルの3フェーズって、守破離って概念と似てるなと思った。

エンジニアの知的生産術を読んでるけど、文章中のフォントが変に見えて気になって頭に入ってこない

この本から「トリンプという会社では12:30-14:30を「がんばるタイム」として一切の私語、連絡、通話の禁止し、集中する」という新たな知見を得た

やらず嫌いだったポモドーロタイマー使ったらめっちゃ捗った!

良いものどんどん取り入れていかなきゃだし試さなきゃだな！

エンジニアの知的生産術、数ページ単位で「そんなものがあったとは…！」と気付かされる

「10年後も役立つ考え方を身に付ける」という表紙のコピーも決して大袈裟ではないと思った。

わりとマジで全人類読んだ方が良いのでは？？(大袈裟)

人に物を教えるときも、答えや解決方法は教えやすいけど、それを見つけるまでの試行錯誤は伝えるのが難しい

答えだけ言うより何倍も長くなる

慣れてると自分はいろいろ省略できてしまいますけど教える対象の人にとってはそうでない

試行錯誤した結果とか経緯とかを、例えばcommitメッセージなどに残していかないといけないな

これがあるので、OSS上で（最終的にコミットを目指して）試行錯誤するときは、一人でやるのではなく、先にMLなりissueなりで問題を提起して、見えるところで試行錯誤するといいんだよね。

あと、試行錯誤だけじゃなく、品質向上も同じように目に見えない。やはりオープンな場所でやるのが吉。

git logでは見えない部分ですね

自分に裁量があるプロジェクトで特に新しいフレームワーク・ミドルウェア・パッケージソフトを使う場合は最初の方に「試行錯誤フェーズ」を作るようにしてる

その期間に試しに作ったものは原則捨てる。

お作法覚えるまでは写経や試行錯誤が必要

実際には自分に裁量が無いプロジェクトも少なくないので常にはやれてないけど、明な試行錯誤なしに新しいことをやると最初に何かを勘違いして作った設計なり実装なりが後々にすごく大きな負債になる

第7章。読了。

本書を通した思考実験が知的創造のためのそれという壮大なメタ構造に。

結びには自己の生存戦略や他者を巻き込んでの相乗効果を得ながら自他と共に成長していき、社会をより良いものにしていく意志を感じた。

知識は閉じてはいけない、開き交わり膨らむイメージ。

第6章。耕す・芽生える・育てるフェーズ、そのイテレーション。

PDCAも引用されるが、えてして新しい情報の取り込みがなく、幅の狭い仮説検証となりうるなと思った。

また感覚として捉えている事象の言語化もしかり。

湧いたアイディアこそ、愛で、晒し、豊かなものに育てる

やる気を出すためのヒントがたくさん書いてあって今のわたしにかなり役立つ一冊

後半の章ではメンタルモデルの共有を思い出した。

学習法って道具面での発展はあるだろうけど、方法論としてはそんなに変化しないと思うから、この本一冊ちゃんと読んで自分なりにカスタマイズすればいい気がする。

目次を読んで面白そうなところを読むタイプの僕だけど、全部面白そうだから、前から読むしかない

大学に入りなおすべき？って節がある。

ある分野を勉強したいとき、その分野の大学に入った方がいいのかな？って思ったことあった。

大学に入った方がいいかな？って思う理由は、『何かを誰かと一緒に学びたい』

自分と同じテーマについて、興味がある人の集まるところに行くと、議論もできるし、気になる事を話し合える。

そういう場所が欲しいよなー、って。

KJ法、中公新書で増刷が重ねられるくらいには評価されているが、その知が行き渡ってないことが不思議

見知った方法論をどう使うのか、なぜそれを使うべきなのかというのが具体化されている

最もよかったのは「差異に着目する」という点

相対化して抽象化

他の書籍も引用しながら多数の方法を平易に解説している

第4章は読書量に囚われて読み方を軽んじていたと気付かされた。

名前が付くのは大切だと実感‬

目次を読んで半分ほど既知だったのであまり読んでいない。

アウトプットに当たる内容が章立てられていない…

エンジニアの知的生産術、第三章。記憶の定着。オンメモリではなく長期記憶のためのメソッド。定着にはテストがかかせない。間隔を置いた反復のテストが定着を強固にする。ベストは前章と同じく取捨選択せよ、だ。これ年齢に応じても方策変えなきゃだし見直すタイミングは死ぬまで続くんだろうなぁ

エンジニアの知的生産術、第四章。読むこと、見つけ組み立てること。難易度によってアプローチも変わる。英語記事や新しいプログラミング言語は特に時間がかかる。通読する前の効率化に少しテコ入れもあり。選り分けるという意味で見出しをなめてから、あえて読まないという選択肢もありえそう

エンジニアの知的生産術、第五章。脳内にインプットした情報を引き出し、整理し、脳内に戻してやるイメージ。普段は高速でI/Oを繰り返し精度を上げてる気もする。今期は取り込んだものを人にくべることを意識的しており、『果たして伝わるのか、これは』という自問もまたより良い反芻なのかもしれない

第二章。やる気のための外的要因、というよりメソッドの紹介に徹していたように感じる。それもまたパターン化のひとつにも思えるメタ構造。見積り精度のために時間計測はやってたなぁ。

探索と利用のトレードオフ、そのバランス。なるほど。

2章「やる気を出すには」

理論、その経緯、例がバランスよく配分されててわかりやすい。

やる気を出すには、タスクを1つに絞ること、タスクに明確な達成目標を振ること、絞ったら内容か時間かで区切ること、区切ったら計測すること。

計測大事

3章「記憶を鍛えるには」

復習よりテストせよ。テストによって主観的には自信がなくなるが、客観的な成果は上がる

第4章「効率的に読むには」

読むとは情報のインプットだけではなく、読むことで新規にインプットされた情報を持っている知識・経験と組み合わせること。

ここで言われている「組み合わせる」は他の言い方だと「化学反応を起こす」くらいになるのかな。

Whole Mind Systemって方法論は本は初めから終わりまで舐め尽くすように読まねばならんという強迫観念の持ち主には有効そう。

章の後半に載ってる数学科出身者と物理学者出身者の「わかるの定義」の違いの話面白い^^

第5章「考えをまとめるには」

KJ法

付箋を使って多すぎるアイデアをまとめていく方法

第6章「アイデアを思いつくには」

言語化がまだできないイメージをどうやって言語化するかについて。

「違和感」の話が面白かった

知識は外部から獲得するだけでなく、自ら産み出していくものでもある。

新しい知識を産み出すことが価値につながる。

読書、知識の整理方法

アウトプットも付箋を使った具体的な整理方法が書いてあって、本を執筆するにあたって是非取り入れたい

KJ法良さそうだなと思ったので、小さめのポストイット買って試しているけどなかなか良い感触。

考え事をしたいときに上手く考える手法

経験則を言語化してくれてて面白い

人に教える時も役に立ちそう

こういう体系化はありそうでなかった

10年かけて学んできたソフトウェアエンジニアとしての学び方、戦い方が全部解説されてる

10年前の自分が読んで理解できるのかわからない

繰り返し、試しながら読むといい本かも

普段何気なくやっていることの言語化

パターンから違いを見出だすところまでいつも至ってないかも

パターンが出来ると安堵して深堀りしなくなる傾向ある

「知ってたり聞いたりした事」も多いけどわかりやすくまとめられててモチベ再燃に良さそう

内容はわりと抽象的

目的を持って学ぶ

具体的なゴールを設定して、やる気を引き出す

抽象化する事で、色々な局面で応用できる汎用的なスキルを身につける

「学び方」に関する色々な話題が書いてある、ふわっとした本。テーマが広すぎる

ソフトウェアのたとえ話が多いけど、エンジニア向けの特別なノウハウがあるってわけではない。

プログラミングは試行錯誤しやすくて学ぶのにいいよ！は何回か出てくる

こういう本は学部1年の時とかに読んでおきたかった

表紙のデザインが10年くらい前にでたような本とほぼ変わらない

タイトルも広辞苑に載ってるであろう言葉のみで構成されてる

ワクワク感がない

プログラミングの学び方

『情報収集（具体）・モデル化（抽象）・検証（応用）』これら3つの要素の繰り返し。

個人的には「モデル化 → 検証」の壁が大きいと思っていて、ここのクオリティの違いが、プログラミング力の差に直結している気がする。

抽象とは解釈が広く応用が効くものである。具体は逆にこの応用力がない。抽象化する能力があるから人間は数と言葉を生み出してきた。また、現実世界で起きている事象を精神世界に応用したり、その逆を行えるのも抽象概念を用いているから

読書スピードのMAXとMINなんて考えたことなかった

知識の獲得において、概念を獲得すると応用が広がる。概念を学習しやすくしたのが原理、原則、公理、法則で、これは高速道路。概念の獲得には事例の収集が必要で、この部分に高速道路はない。手を動かして収集するしかない。

教育で根気が要るのはこの辺。概念を理解している教え手からは、概念を説明しても伝わらないのがもどかしい。自分は分かっているので、何で伝わらないのかわからない。聞いている側は、事例が足りないのでわからない。が、自覚はないので、何がわからないのかわからない。

教える側は、応用が効く概念を教えたい。そしたら、二回教えなくて済む（と考えている。実際は事例を飛ばして、概念だけを教えることはできない。原理を言葉として教えることはできても、複数の事例との結びつきを獲得しないと、新しい事例に適用できるか判断できない）

エンジニアじゃなくても作る仕事してる人は読むと良いよ。あー、私こうやって仕事してたのかーって再認識する。

直近では技術書典用に原稿を書く必要があったのだが、少しKJ法の真似事をしてみたりタスクを細分化したりしてみた。

原稿（長文）を書くのは初めてだったので、最初はたじろいでいたが、文書全体の筋道を作って個々のタスクに細分化することで（ハマりなどはあったが）だいぶ迷わずに原稿を書くことができた。

また、少しずつ書くことができたので、「すこし時間があるからこの部分だけざっと文章書いてみよう」とやる気を継続することも出来た。

悲観的な勘違いは気づくチャンスがないけど、楽観的な勘違いはあとで気づいて修正できるというもの。

これを読んでふりかえりを強く連想した。

楽観的にチャレンジするよりも、悲観的な不安・リスクを優先して失った機会はどれだけあるのだろう。

うまく言語化できてなかった暗黙知を形式知にしてて良い．

結局は目的なき勉強や漠然とした目標設定は大半の人がもたないんだよね．小目標の連続が重要．わかってるんだけど設定するのが難しい

言葉ってとても重要なものなんだなあと

言葉が存在しなかったら事象を認知できない

学んでいることと自分の考えのズレに意識しながら勉強するの凄くよさそう

やる気とタスク分割のつながりを考えたことはなかったので新鮮だった

学ぶことに前向きになれる

定期的に読み返す本

最近インプットとアウトプットが歪だったので、この本にすがったらとても役に立ちました。

題名ほど難解ではなく図を交えた平易な表現で読みやすく、自分に足りないものがよく分かった。

エンジニアの知的生産術の感想をアップしました!

やる気とか記憶の話はみんな興味があると思うから、エンジニアに関係なく読んで欲しい一冊。

飛ばし読みでいいから、読んでみるのは価値があると思う(すでに勉強の仕方とかを自分の中で体系立て出来ている人は不要かも)

息子は今家で本を読む時間がないので、学校の朝の読書タイムに読みたい本を読んでいる。ちょっと前まで、「エンジニアの知的生産術」を読んでいて、なにかにつけてこういう時はね…と引用して教えてくれた。今は「プログラマの数学」読んでるけど、またいろいろ教えてくれるかな。

知的生産に関する様々な先行研究(KJ法とか)を著者自身が色々試して現代風にアレンジしたやり方を紹介。

「記憶を鍛える」「効率的に読む」「考えをまとめる」この辺は普通なんやが、学ぶために「やる気を出す」を一つのテーマにしてるのが面白い。

ただ、いい本なんやけど、読むのに認知負荷がかかる。こう、文字の多さでたたみかけてくる的な。章/節で話が結構飛んだりして、流れが掴みにくいからかも。

あるいは、最近ヌルい本しか読んでなくて、鈍ってんのかも。難しい本を読むときは、脳内の情報の組み立てがボトルネックって書いてあるし。

気になったところをメモっとくと、

「過去の経験に基づいて一番期待値が高い選択肢を選ぶ」というアルゴリズムは、一度悲観的な勘違いをすると、二度とその選択肢が試されない。だから、不確かなときは楽観的に行動するのが吉。

知識を使って立場を得て、その立場を使って、知識を獲得する。

特定の領域で卓越できないなら、知識領域をずらして差別化する。(自分が一番詳しい領域を作る)

複数領域をかけあわせた領域で卓越する。

ふたこぶの知識で専門領域をつなぐ。

「読んだ」だけで身になる本ではないので、紹介されている手法から自分に合いそうなものを選んで取り込んでいかなくては。

なにごとも遅延評価的勉強法で取り組んだほうが効率よさそうという再認識を得た。

勉強の方法や、そもそも何を学ぶかの戦略、やる気を出す、アイデアを出すなどの知的スキルについて、こんな方法があるよ！と包括的に紹介する本

「知識の貿易商になる」は自分も副業した時や、他チームにカンバンをプレゼンした時にすごく感じた。他社や他チームのノウハウってかなり貴重だったりする

あと「組み合わせでナンバーワンになれ」はよく言われるけど、具体的なイメージが湧かなかったのですが、「この知識や経験については、この部署でナンバーワン」と言われると非常にイメージしやすい

チームでナンバーワンでない分野については、どうしても二番手、三番手の仕事が回ってくるので、結果的に評価されるべきアウトプットの質や量も二番手、三番手になるというお話しは、厳しいけど確かにそうよねと思った

みんなの課題「やる気を出す」は、タスクが絞りきれていないか、タスクがでかすぎるのが問題。1個数分で片付くマイクロタスクにして、ポモドーロとかで時間を区切ってやれという、まぁそうだよねという内容でした

自分の場合は、やることを5分以内で終わる作業に区切って5分タイマーをつけてやる。やる気がなくても、最初の5分やればまぁ始まる。本当にやる気がないときにはタスクの分解もしないで、最初に思いついた5分のタスクをやる。ということをやってなんとかかんとかやる気をブーストしています

記憶を定着させる方法。本を読んだあとでどれだけその本の内容を覚えているか、書き出すと内容の把握が捗る。あとはよくある時間が空いてから復習する手法が紹介されていた

記憶を定着させる方法はわかるのだけど、「この状況はあの本で紹介されていたあれだ！」みたいに、「今の状況に対して、過去の経験や知識から最適解を手繰り出す能力」ってどうやって鍛えれば良いのだろう？

自分の勉強方法がアップデートされてく感覚ある。

どうやって勉強したらいいかの本として最適

エンジニアの」という枕詞は必要ないくらいに、幅広い分野において求められている「知的生産術」について綴られていました。

と書いてから、本書における「エンジニア」の指し示す定義が広義なものであるという想像が頭を過ぎりました。例えば、料理人や画家なども食材やモデルの構造を理解し扱うエンジニアと見ることもできますね。

新しいアイディアを求めている人は特に、本書で述べられているフレームワークは参考になると思いました。自分できちんと検証していないので手放しで推奨はできませんが、うまくいきそうな説得力のある文章で綴られています。

今日考えていることが、明日の自分に伝わらないということが最近結構ある🤔

多分走り書き(メモ)だと、その時点で整理ついてないからだと思う。

できるだけ言葉にすることをサボらないように気をつけよう💡

残していればOKかもしれません。

「エンジニアの知的生産術」にアイデアに関して、上手く言語化できないものや違和感も重要。関連付けて整理する際に、磨き上げればすればよい。書き出す際には同じことを書いても構わない。特に似てるけど少し違うのが重要。言語化できるのは氷山の一角とありました。

言語能力の域を超えたアイデアみたいな部分ってことですか。そこまでは考えてませんでした！！整理するときに削ぎ落としてしまいそうなところですね🤔元々結構メモは取る方なので、今後気をつけてみます！

アイデアを思い付いた際に、それが明確かつ現実的であることは稀で、世に送り出されて知ることができるのは、現実的な形に磨き上げられたもの…みたいな記述もありました。すごく納得しました。補足ですが、NM法といってアイデアをメタファに関連付けて発展させる思考法もあるみたいです。面白いです。

『エンジニアの知的生産術――効率的に学び，整理し，アウトプットする』（⁠西尾泰和, 2018, 技術評論社）で書かれている話とかもそうなんですけど，1つ上のメタの知識を持っていれば，個別の案件も一緒のことが見えてくるんです。1つの案件だけを見てしまうと，そのメタな知識は得られないですが，2つ3つといろいろな業界を見ていくと，共通するところだねっていうのが見えてきます。それをベースに考えていくと，新しい業界で話すときも理解が得やすいことがありますね。

普段あまり意識せず自然にしていることが、言語化されていて「確かに」という感覚があった。

1~4章は割とすんなり内容が入ってきた、5~6章はあまりピンとこなかった。

普段考えを整理しアウトプットする量が少ないからかも。（課題）

いつも本を読む時1ページ目から丁寧に読むことが多く、分厚い本など先が見えず辛くなっていたので、まずは見出しのみ掻い摘んで全体を見通すことで分厚い本への抵抗が軽減された気がした。

自分が若い時は新しい知識を得ようとはしてても、新しい考えを取り入れようとはあまりしてこなかった。四十路を超えた今になってその価値に気づいている

真新しいものは特にないけど、確かにエンジニア寄りに1冊にまとまってるのは良い

『エンジニアの知的生産術』で紹介されていた、付箋&KJ法メソッドがめっちゃワークしてて楽しい。付箋もすでに100枚オーバーしてる気が

「○○ができるようになりましょう (Ex. 「Python ができるようになりましょう)」と言うだけで相手に委ねるのではなく、具体的な範囲が分かるようなスキルマップを提示した上で「できるようになりましょう」と言うべきなのかな。

書籍に出てくる「民法マップ」のように「○○マップ」を誰が作るのかという問題。自発的に勉強する場合は勉強する人が作れば良いけど、「○○できるようになりましょう」という場合は、言う側が作った方が自然な気がする。

知的生産術に関することが体系的にまとまってて、普段何気なくやってたことは良いことっていう再認識ができたし、新たな学びもあったしで良本でした。

特に最後の「何を学ぶかを決めるには」は現状の自分に刺さる良い話でした

「ゴールを明確に」とか、そういえば、そうだった。つい、曖昧なゴールを考えてたことを把握

つまみ読みなので、読んでないとこも多いけど、よさそう。

必要に応じて読めばいいかな

『エンジニアの知的生産術』は凡百のアウトプット本の上位互換本だなあと思うので、エンジニアのためだけの本にするのはもったいないと思いました。

頭の手の使い方が分かる、脳内デフラグのための本。

｢エンジニアの知的生産術｣で不確実な目標(｢C言語できるようになる｣、｢本の内容を覚える｣みたいなの)による達成の実感しにくさ→モチベ低下が挙げられてた。これまんま若い頃の自分で笑えないな・・・

体感的に理解してたことが言語化されててすごくすっと腑に落ちるこの感覚が楽しい。

今週は「エンジニアの知的生産術」の書評ですー！素晴らしい本でした（情報量が多く読み解くのがすごく大変だったけど）

エンジニアの知的生産術の3章「記憶を鍛えるには」

かなり退屈だった。

俺はそんなの知りたいわけじゃない。

今日のかなりの時間を使ってエンジニアの知的生産術を読みきった。

本の内容理解を進めるにはこのあと本の内容を検証をすることが必要だと

『もし「今日やらないといけないこと」がすでに今日できる以上の量になっているなら、あなたがやるべきことは、そのタスクを頑張ることではありません。納期を変えるか、仕様を変えるか、やめるかしかありません』

エンジニアの知的生産術 p.54

のっけから情報の積み上げってところで頷きました。

深く掘る、というより、上に上に知識を積み上げていくんですね。

あと、Web+DB PRESS plusの本は紙質のせいか指切る率高いような気が

エンジニアの知的生産術で紹介されていた「8時間働くのだから25分間の単位で作業を行うポモドーロテクニックは16ポモドーロ実施できると思いがちですが無理です。私のばあいせいぜい4〜8ポモドーロ程度しか高い生産力は維持できません」という話たいへんよかった。

https://gyazo.com/3b303a9cd7840a249f932328d15d0304

私はコンピュータ書担当者ですが技術者ではないので自分の売場の本を読みふけることは少ないのですが、ぱらぱらとページをめくっていると手が止まらなくなる一冊でした。エンジニア・プログラマーは勿論、一般のビジネスマンなど誰が読んでもためになる本だと思います。（ 三省堂書店名古屋本店 長縄勇祐さんのおすすめ）

頭の中を整理、最適化するための手法が具体的に書かれていて、頭と手の動かし方が分かります。エンジニアだけの本にするのはもったいない。凡百のアウトプット本の完全上位互換本です。（ 丸善岡山シンフォニービル店 加藤一博さんのおすすめ）

「エンジニアの知的生産術」より、具体的な経験がないと抽象が理解できないって話しっくりくるな。設計はまじでこれなのでテスト自動化を進めて価値のある経験増やそう

良い→遅延評価勉強法：やりたいことに対して、必要になったところを必要なだけ学び、組み合わせていく勉強法。

指導教官からは、"輪読とか論文多読するとかもいいけど、replicateしたい面白そうな論文を1つ見つけて、自分でリバースエンジニアリングしていくのが一番力がつくよ。その過程で必要になったことを学んでいけばいい"と言われているのですが、まさに「遅延評価的勉強法だ！」となったわけです。

あまりにも面白いのでメモしながらゆっくり読んでる。

以前けんすうさんがお話されていたエンジニアの知的生産術読みましたが…何て良い本なんだ。

これシステムの書棚ではないところにも置いてほしい。

ここまで考え方や着想について具体的に、かつ体系化して記載されているものって見たことない！

頭がすごく整理されました。

西尾さんの『エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする 』

「第1章 新しいことを学ぶ」はモデリングの話が出てきます。モデリングといってもソフトウエア開発だけに限った話じゃないことがわかるはず。DDDの戦略編の助走に絶対読んでおいた方が本編が読みやすいです

１ページ、１ページがとても濃厚で高次元で明快で充実した内容です。技術系でこのような本は初めて体験しました。以前読んだ難解な哲学を読み解く本の話もでてて親近感を。最後のページまで著者の文章力が衰えない秀逸さ。再読する所存です。

「エンジニアの知的生産術」という本、だいたい知ってる内容だったんだけど、逆にいうとぼくの大学入学以降5年ぐらいの大事な学びめちゃくちゃいっぱい書いてあった。

「エンジニアの知的生産術」という本に出てきた「誰が顧客なのかがわからなければ、何が品質なのかもわからない」というのは声に出して読みたい日本語。

今年というかここ最近、物事の考え方や捉え方が良くなったような気がしてるんだけど、ここらへんの本のおかげな気がしてる。

勉強にもいろいろアプローチあるけど、学生の頃は意識しなかった。速読とか胡散臭い印象だったし、今考えるともったいない。

この現象、まさに「エンジニアの知的生産術」にあった貿易家戦略のすごい版？

「エンジニアの知的生産術」読了。我が意を得たり、な内容が言語化されて凝縮された良書でした。あとは実践のみ。

良い本なのはわかるけど内容濃すぎて全然頭に入ってこない。

LT などのプレゼン作りってとりあげるテーマだけでなくなるべく正しい情報を正しく表現する調査・明文化の工程（理解していることの9割近くはそのまま文章化すると自信が持てない）や、「あのプレゼンのようなああいう図表で表現したいんだけれどシュッとやるにはどうしたらいいんだ」みたいな、

「資料を作る」という具体的な手を動かす作業の慣れなさ・分からなさ・だるさが資料作りをおっくうにしてしまっているのかなという気持ちがあって（おっくうですよね）「発表資料作りを支える技術」みたいなノウハウが横に展開されているといいんじゃないかなって思った、

そもそもとして「資料作り」って短い四文字熟語のわりにタスクとしては大変でかいタスクであってそこに対するやる気の出し方のテクニックとしては西尾泰和さん著「エンジニアの知的生産術 - 第2章 やる気を出すには」で触れられているのでみんなも読もう！

「エンジニアの知的生産術」より、具体的な経験がないと抽象が理解できないって話しっくりくるな。設計はまじでこれなのでテスト自動化を進めて価値のある経験増やそう

エンジニアの知的生産術、読み始めたばかりだけど、自分の子供が中高生になったくらいに読んで欲しい本だ。

他の本からの引用ばかりで内容が薄かったです。

普段やってることが言語化されたり、自分が抱えてる問題を解決するためのヒントが書かれてて非常によい

Luo Yang ぼくがここ10年くらいかけてコツコツ身につけてきたソフトウェアエンジニアとしての学び方、戦い方が全部解説されてて、おお……という感じです。逆に言うと（ぼくにとっての）10年分全部入りなので、10年前のぼくが読んだとして理解できるのかは、ちょっとわからない。繰り返し、試しながら読むといい本かもしれません。

yasuhitoakita 既存の情報をどうやって自分に取り込み、どうやって新しい知識を産み出していくかを体系立てて解説してくれる素晴らしい本。著者の前著『コーディングを支える技術』にも通じるのだけれど、なぜこうなのか（論理による説明）となぜこうなったのか（歴史による説明）がバランス良く配分されているので説得力が高い。オススメ^^

このすみ 少し学術的すぎる本に加えて、抽象的な話が多いので、人を選ぶ本だと思います。 具体的な知識という1段目の箱がないと、上のレイヤーの知識をつけることが出来ないという話は、凄く刺さりました。 そして、モチベーションは重要であるという事実を、改めて再認識しました。勉強でも何であっても、嫌々やるのではなく、やる気を持って取り組む工夫をしないと駄目ですよね。

‍しき 以下のような章立てで構成されていて、いくつかはもうすでに実践できていて既知の内容だったけど、エンジニアとして仕事をしていく上で誰しも考える部分が綺麗にまとまっていて参考になる部分も多かった。目次開いて、自分の気になるところだけつまみ食いしても良いかも。 ・新しいことを学ぶには ・やる気を出すには ・記憶を鍛えるには ・効率的に読むには ・考えをまとめるには ・アイデアを思い付くには ・何を学ぶのか決めるには

YtoMoon 現在在籍中の大学院のＯＢでもある西尾さんの著書。冒頭から引き込まれました。地に足がついていない。と感じるのは経験としての「地」が足りないから。そういう方には半年後に読んでくださいという優しさ。何度でも読みたい本でした。積読本が増えてしまいがちな自分はまず読書速度のピラミッドを使って効率的に読む力を磨くところから。。。

Gotz タイトルにある通り，知的作業に関わる一連のプロセスが述べられている． 読書に関する記述は先日読んだ「読書の技法」にかなり似た内容だった． 以下は印象に残ったフレーズ： ・知りたいところから学ぶソースコードは全体を読む必要はない ・教科書を読んで、覚えるべき箇所を見つけ出し、シンプルな構造の問題にするといった認知的に高度な作業をした方が、記憶にとどまる ・学びとアイデアの発想はほぼ同じ事． ・知識を持っていることではなく，新しい知識を生み出す力が価値の源泉

maru エンジニアとして新しい技術を得続けるために、生産性を向上するための様々な工夫について書かれた本。効率的な読書などのインプットから、考えのまとめ方などのアウトプットまで、周辺の研究結果や書籍の出典も交え、著者の考えが紹介されている。全体的に手法の列挙で、大まかな流れはあるものの、細やかな流れはあまりないので、抽象的で全部頭にいれ、すぐさま実践というのは難しいなと感じた。読む時々のタイミングで刺さる部分と刺さらない部分がありそうなので、また1年後や3年後に読んでみると面白いかもって思った。

YUJIRO やる気の起こし方から、本の読み方、アイデアの発想の仕方までまとめた本。対象をエンジニアに特化しているのが珍しい。が、エンジニアにとどまらず、学生などすべての人に読んでほしいお勧めの一冊。同じ著者の作品の「コーディングを支える技術」は自分の実力不足で分からないところも多かったが、本書はビジネス書だけでなく哲学書や科学書も参照しており、分かりやすい比喩と合わせて理解しやすい一冊になっている。

Yushi koga 何を学ぶのかに、悩んでる人はまず第7勝から読んだほうが良い。 個人的には学習効率をあげることに関心があるため第3章と第4章が参考になった。 やる気の出し方の章は勉強習慣ができてないと悩む人に読んでほしい

えすかわ 著者がいろんな文献から知的生産術を学び、それを本書を書く際などに実践したことの記録

光瑠 ■情報収集だけやっても箱が平たく並んでいくだけで積み上がっていかない■4回繰り返しインプットするよりもその時間の一部をテストに回した方が成績は良かった■読書する際、インプットするだけでなく自分の経験等を組み合わせていく構造化していく、理解を組み立てるイメージが重要■フォトリーディングは効果が感じられなかった■本を読んで何かを学んだらそれを人に教えるブログ記事などを作り公開すると、自分の理解向上に役立つ■他人と同じ領域で打ち負かす必要はなく、その人の不得意分野で詳しくなれば差別化できる

おさとぅ エンジニアという観点に限らず、どのように自分の知識のアウトプットをしていくのかの方法論が書かれた一冊。まずはインプットを大量に行い、そのあとにインプットを全て洗い出し、洗い出した要素をまとめて体系立ててアウトプットするという流れが本書で最も骨となる。それぞれの章は、どうやってインプットするか？どうやって自分の主張を洗い出すか？アイデアをどうやってまとめるか？と言ったことに関して、様々なノウハウが書かれている。それぞれに対してまさに王道のやり方が紹介されていて、実務で経験されてきた人ならではの説得力がある。

ヒカル 様々な本で紹介される技術が凝縮された本。各本の共通点にも言及されていて興味深い。エッセンスのみでわかりやすく書かれていた。6章の後半（メタファの話）はよくわからなかったけど。ソフトウェアエンジニア向けという触れ込みだが、それ以外の人でも十分ためになる。

きをふし やる気とタスク分割のつながりを考えたことはなかったので新鮮だった。KJ法のモダナイゼーション。「100枚」という具体性がすごい。

たいそ 2018年。知的生産について。探索と利用のトレードオフ、タイムボックス化、15分ルール、連続スペシャリスト戦略について知ることができた。「過去の経験から一番良いと思う行動ばかりをしていたのでは、もっと良い行動を見つけることができない」「不確かな時は楽観的に」「本を読まなきゃと考えるときに無意識に手段の目的化が行われている」「フレームワークは習慣性のある薬のようなもの」「学びとアイデア創造は逆向きのことではなく、ほぼ同じこと」等を心に留めておきたい。「誰が顧客なのかわからなければ何が品質なのかもわからない」

大谷周平 おすすめ。エンジニアに限らず、情報収集から整理、アウトプットまでまとめた書籍。KJ法の運用をまちがっていた。

ニャンゴロ 徹底的な理系的（プログラマ）発想なところに共感がわく。

rtaguchi 「コーディングを支える技術」の著者の本。「コーディング～」が非常に良い本だったので期待して読んだが、ちょっと求めているのとは違った。ちゃんと本の説明を読んでいれば、自分の期待とは違うとわかったはずなので、この本の問題ではないです。

miwarin 知識を得るだけではなく、知識を使い再生産する方法。アタシ再生産

pochi 著者オリジナルの手法はないが，これまでに先人が提案してきた種々の生産術(仕事術)の位置づけを徹底的に整理している．結局，個々人の手法との相性の良さが結論になってしまうと思う．自分なりに試行錯誤して，自分の仕事術を確立していくことになるのだろう．しかし，試行錯誤の段階でも闇雲にいろいろ試すのではなく，その手法の意義を理解し，厳格に実験することが大切だと感じる(中途半端にかじってダメ手法と結論付けるのが一番良くない)．その意味では，本書は古今東西の”手法”を見取り図のように紹介しているので眺める価値はある．

Arnold １ページ、１ページがとても濃厚で高次元で明快で充実した内容です。技術系でこのような本は初めて体験しました。以前読んだ難解な哲学を読み解く本の話もでてて親近感を。最後のページまで著者の意欲が衰えない秀逸さ。再読する所存です。

ゆうがた 図や参考文献、コラムが充実しており、読みやすかった。知識を生み出すことが、価値を生む。言語化して整理し、新しい知識を得ようとする態度が大切だと感じた。

なんだか読んでて心地よいと感じるのは、全体に「私はこう思っています、何故ならこうだから。違う意見もあると思いますが、あなたはどうですか？」という雰囲気を感じるからだろうか。

初心に帰ろう

再発見している感じ。

自分の子供が中高生になったくらいに読んで欲しい本

エンジニアのための知識のインプットからアウトプットまでの一連の流れのモデルを示してくれる本。ここにたどり着くのに死ぬほど色んな勉強をしないといけないはずで、そこに最短距離で近づくことができる。他人から見ると表からしか見えないから、試行錯誤の部分が見えない、というのはなるほどと思った。

この間読んだ「エンジニアの知的生産術」という本によると目標は達成非達成が明確に分かるように設定するのが良いそうです。なので私の今年の目標は、①社外勉強会に12回参加する。②技術系非技術系に依らず記事を12個書く。にしたいと思います。

"モデルは、現実世界のしくみを説明するための簡素化された表現です"

この本、数ページごとにめちゃくちゃ勉強になる話が来る。

"モデルは現実の一部を抜き出したものなので、現実と完全一致はしません。このことを指して「すべてのモデルは間違っている」と言います。

モデルの価値は、現実との一致度ではありません。モデルの操作が、現実を直接操作することと比べてどれくらい低コストになるかです"

"速度の単位として名前を残している物理学者Ernst Mach (マッハ) は、多くの事実を少ない概念で記述して思考の労力を節約することが、科学の根本原理だと考えました。思惟経済説と呼ばれています"

今読み進めてる「エンジニアの知的生産術」での知識の抽象化ができずに実戦に進んでいる感じあるなぁて思った。

でも、プログラミングやり始めた人がこの本読むとも思えないし、読んでもピンとこなさそう…

２章の時間管理回りではっとさせられたわ…。学びが多い。

自分は食事や料理をメタファーにしているものがわかりやすいなと感じるのだけど、おそらく日常的に行われているものだから結び付きやすいのかなと思ってる。

エンジニアの知的生産術にはメタファーは主観的な経験だと書かれていたけど、食事や料理って教える側と教わる側のどちらもが主観的な経験として捉えられる事象を扱うのをアウトプットする時に意識すると良さそうだなと読んでる時に思った

エンジニアの知的生産術で「価値観はボトムアップに言語化する」のところで、価値観的なものはゴールから設定するのはやっぱり難しいのだと知って安心した

「無限が絡むと人間の直感はしばしば間違います。」「限られた視野で判断すると誤解してしまう」 / エンジニアの知的生産術

無限以外にも直感が間違うケースはあるはずで、何事においても十分な視野で見えているかどうか要注意と受け止めました。

『エンジニアの知的生産術』印象深かったポイント

やる気が出ないことをやるのは不可能(他の原動力がある場合を除く)

タスクの優先順位付けはそれ自体が難しいタスク

読む*4回 よりも (読む+思い出す)*2回の方が記憶の定着率は高いが、後者の方が自信は持てない (前者は理解度を過大評価傾向)

時間をおいたら印象変わりそう。また読み直す。

エンジニアの知的生産術やっと少しずつ読み始めた。

一章を読んだだけだが、ものすごい経験・調査・検証・実践の集積だと感じる。

少なくとも、自分の過去の認知心理という研究領域の知見が随所にあり、懐かしさと再発見が多々。

こんな形でCraik&Tulvingに再会するとは。

頷きながら読んだ例として、写経などでも処理水準を深くするとか、少し頑張って(明確な基準で) 達成できるものを目標にするとか、概念のラベリングなどで情報量を圧縮するとか。

教育心理を応用したい人にも、普段と異なる切り口のものとして推薦したい

学生時代は認知負荷理論 (Cognitive Load Theory) という、要約すると「認知資源は有限だから意味のあることに使おう」という日本でマイナーな理論を中心に研究してたんですが、改めてそのモデルを使っていろいろ捉え直してもやはり面白いなと思います。

エンジニアの知的生産術を目次まで。いつもと同じように、目次部分までを読みつつ書籍の全体像をざっくり知ることと、気になるワードを取り出す作業。この時点で良書の予感がする。というか自分が知っておくべき情報が書いてある気がする。

今までかなり愚直な方法で攻めてきたけれど、攻め方を見直すためにも読んでおくのはよさそうだ。一日30分でやってるわけだし、この本を読んで、その時間をより濃くできればいいなー。

エンジニアの知的生産術29ページまで。著者の考える学びのサイクルと、サイクルの要素である情報収集について。

情報収集、モデル化、実践検証のループ。具体的な知識を集め、組み合わせて抽象化、正しいかどうか検証した上で積み上げる。

やる気の話。社会人の学びにはより強いやる気が要求される。これを維持するために、行動と報酬のサイクルを考える。ゲームのチュートリアルとかイメージしやすい。このあたりの話は体感としても理解できる。やる気の維持には報酬が必要。別に金銭的でなくてもいいので。

情報収集の話。明確な目標は学習にとって重要なため、まず知りたいと思う部分から学ぶと良い。達成可能な目標駆動で学ぶ。そのために、知りたいことがどこに書いてあるかを把握すること。目次とか章見出しが有用。「知りたい」は理由があるはずなので、勝手に目標駆動になるし、便利で気楽だよねー。

目次と章見出しを読んで全体把握、詳しく知りたいところだけをピックアップして深く読む、みたいな方法はありだと思うんだけど、なんとなく落ち着かない気持ちがあるんだよなー。

エンジニアの知的生産術44ページまで。学びのサイクル、抽象編。昨日の情報収集の続きで、収集した情報を整理して使えるようにする話、かな。使ってみた時正しいのかは明日読む予定の検証の領域。

抽象とは重要箇所の抜き出し。よって、収集した情報の共通項を探す。パターンを見つける。複数の視点の情報を集めるのはここに理由がある。同じ領域の話をしている情報を複数集め、比較し、共通部分を探す。何が同じで、何が違うのかを知る。共通領域の広さを理解する。

このあたりは自分の考えていることとほぼ同一な気がする。パターンの名付けのコラムとか特にそんな感じ。ダグラス・エンゲルバート氏の話が興味深いな。深く知りたい。

タスクの大きさとやる気の関係、見積もり能力を鍛える話、そして記憶そのものの特性の話。

1つのタスクが大きすぎるとやる気がでない。見積もれたが必要時間が長すぎる、あるいは見積もれない場合などがこれになる。この場合、ポモドーロテクニックなど、タイムボックスを適用してタスクを時間で刻んで処理すると良い。

見積もり能力の話。予実比較の繰り返しで鍛える。見積もりを約束ではなく予想として使い、終わった後の検証に使うツールにする。何分違うのかがわかってくると、それを含めて見積もりができるようになる。ソフトウェアのパフォーマンスチューニングと同じで、まずは計測すべし。

記憶は繰り返すことで定着する、みたいな話はそのうち忘却曲線とかも出てきそうな話題だ。このあたりを活かして復習ができると効果的なんだろうなあ。

学習内容をテストすることによる記憶への影響と、その影響を活用した記憶法について。学ぶ→テストする→復習するという流れが一番記憶に残りやすい、という話。

学習内容をアウトプットを行うことで、記憶にその内容を定着させやすくなる。そのため、テストという形で学習内容をアウトプットすることで、記憶に学習内容を定着させやすくする。

間隔反復法について。テストと復習を使った方法が効果的ということなので、それを行う学習法。間隔を開けて復習する、という話。ライトナーシステムあたりは参考になる。

また、他にも問題を自分で作る、というのも良質なアウトプットになる。認知的に高度な作業ほど記憶に残りやすいため。

忘却曲線を思い出す内容だなー。このあたりは軽く知っていたけれど、学習に組み込む方法が微妙だった。いい感じの組み込み方を考えるかー。

本を読む目的、読み方と速度、Whole Mind Systemについて。目的、読み方、速度あたりの話題は自分でうっすら感じていたことなのですんなり入ってくる。

読む目的について。大きく分けて娯楽、情報探索、理解の組み立ての3種類。娯楽はスコープ外として、情報探索と理解の組み立て。つまるところ本を読んだときの「腹落ちする」感覚の説明。得た情報と自分の経験が組み合わさり、理解した時その感覚を覚える。

読み方と速度について。読み方には声に出さない音読、目でのみ追う、あるいは読まずに別ルートから情報を仕入れる、という大きく分けて3つの読み方がある。文章を読んだ時、音に変換して頭に入れるか、あるいは目で文を理解するだけか。後者のほうが当然早い。

Whole Mind Systemについて。本の読み方の方法論。一冊を一回じっくりと通読するのではなく、ざっくりと何度も読む。繰り返し読んでいく中で段階的に詳細化する。具体的な手順もこの本には記載されている。これは一度試してみたいなー。ちょっとどこかで一回やってみよう。

読書メモ。読まずに理解する、というところは「それってアリなの？」とか「それだと理解不足にならない？」とかになりそうで不安だけど、どうなんじゃろなー。

フォーカスリーディング、見出しを使う話、理解を組み立てる読み方について。理解したいときには速度を無理矢理落とす、のあたりは割とよくやるので納得感が強い。

見出しを使う話。見出し、と言っているが、すばやく読む時に見出し、図、箇条書きあたりを使うと効率的、ということ。見出しはそのセクションの内容の中で重要なキーワードが使われていることが多いため。また、本の内容の構造化にも使いやすい。

理解を組み立てる読み方の話。読み進める時は読みたい時に読みたいところから読み、読書ノートを取る。わからないところ、頻出単語をメモし、概念間の関係などを矢印で繋ぐ。キーワード、概念の関係性を図化する。

数学書と哲学書の話を出して、本の種類の違いを説明しているあたりが面白い。開いている本と閉じている本、かー。

「読む」というタスクについてと、得た情報の整理方法について。自分が無意識にやっていたことと重なる部分もあって面白い。

「読む」というタスクについて。「読む」という行為の完了条件を「対象物を理解する」に置くと達成困難なタスクになる。そこで、時間を区切って読むことや、読書メモを作ることを目標にするとモチベーションが維持できる。

記憶を定着させるために、読む上で何を目的とすべきか。記憶に定着させる、なんて達成困難な目的なので、達成可能で明確な目的を定義する。例えば知識の地図を作ることや、復習用の教材づくりなどは達成可能で明確な目的。

得た情報の整理方法について。書き出し法とKJ法の紹介。ざっくりとしたイメージとしては、脳内の情報をふせんなどに出力する、出力したものをカテゴライズする、カテゴリに名前をつける、カテゴリ内のアイテムの関係性を描く、説明する文章を書く。かな。文章書く時とか似たようなことやってたような？

脳内の情報をふせん100枚に出力、というのはなかなかの量だなー。まあ一気にやる必要はないみたいなので、気軽に挑戦してみるのがいいかもしれない。

169ページまで。KJ法のグループ編成と表札作りについて。ざっくりと言って多すぎる情報の圧縮法。既存の基準や、事前に用意した基準での分類には大きめのデメリットがある、という話が面白い。

グループ編成について。多すぎる情報の分類フェーズ。ふせん(など)に出力された情報を、なんとなく関係がありそうなもの、というざっくりとした基準でまとめる。その後、その分類した付箋を文章で簡潔に説明できなければ、その分類はバラして再度やり直す。情報の属性ではなく文脈に着目、かなー。

表札作りについて。グループ編成によりできたふせんの山それぞれに、そのグループを完結に説明する表札を作る。一言で言うとそのふせんの山は何か？ これにより情報を圧縮し、扱いやすくする。欠点として、詳細な情報を見る場合、解凍が必要になる。

表札ってつまりフレームなので、事前にやるとそのフレームに無理やり当てはめようとしちゃうんだろうね。ボトムアップ的にやって、後から「ああ、これってこういう内容だ」という気付きを得るようにしたほうがいい、みたいな感じかな。

187ページまで。KJ法のうち情報の関係を出力する話と、繰り返すことの重要性、そしてアイデアを思いつき利用するためのフェーズの話。KJ法で一度整理した内容を、時間をおいて再度やり直す、って話が興味深い。脳内のモデルを再編してそうな感じ。

情報の関係を出力する話。グループ編成が終わったら、ふせんの関係性を図化、文章化するフェーズに入る。グループ同士の関係を空間的に配置して、その後グループをバラして、ネストされたグループの関係を空間的に配置して、を繰り返す。最終的にふせんレベルになるまで。かな。

空間的な配置が終わったら、そのふせん、グループ間の関係性を矢印やマークなどを追記し、説明する。ここまでが空間的な情報整理。次に、空間的な説明ができたら文章化する。文章化すると、空間的説明では見落としていた厳密性が求められる。そこで再度関係性を見直せる。

アイデアを思いつくフェーズの話。いくつかのアイデア発想法を例に出し、共通部分として3つのフェーズを定義している。耕す、芽生える、育てる。情報収集と整理、思いつくのを待つ、思いついたアイデアの検証と修正。芽生えるフェーズは管理不可能、ってあたりが現実味にあふれるね……。

耕すフェーズでアイデアを思いついたら一応記録しておく、って話があったけど、これって芽生えるフェーズでフレームになったりしないのかな。いやまあ、タイムリミットがある状態だとこういった安全策が必要なのもわかるけど。

200ページまで。全然集中できなかった……。アイデアを発想する3フェーズのうち、情報収集のフェーズについて。問題に直面している自分自身を探索し、言語化と非言語化を使って、情報を取り出す。

情報収集において先入観、フレームの存在は厄介。取り払うことが重要になるが、無意識的にやりがちなのでまずは自分で練習する。問題に直面している自分自身が感じていることを、言語的、あるいは非言語的な情報を、扱えるようにする。

非言語的な情報を言語化する場合、価値仮説シートなどのフレームワークが役に立つ。使いすぎると認知フレームになるので使いすぎ注意。言語的な情報を非言語化すると、非言語的な領域での連想ゲームによって、発想が広がる。連想ゲームにはメタファが有用。

言語的、非言語的という単語自体は自分が勝手に言っているだけで、本には出てこないので注意。まあこの感想文自体そういうもので満ちているのだけれど、一応ね。要は表札作りに近い行為。自分の頭に圧縮した情報を入れるために、自分にとってわかりやすく短い単語に変換してる。

220ページまで。言語化されていない感覚の言語化の話と、アイデアを磨き育てる話。公共の言葉と私的な言葉のあたりの話が好き。やっぱモーリス・メルロー＝ポンティ氏の著作は読んでみるかねえ。

言語化以前の身体感覚、問題を前にして解決策を考えた時に覚える「解決に近づいている感覚」と「解決から遠ざかっている感覚」がある。これらを明確な言葉にする方法論としてTAEから辞書を使った言語化の方法論が紹介されている。公共(辞書)の言葉と私的な言葉の差分から発想する、という話。

アイデアを育てる場合、そのアイデアがどのような目的、どのようなコンテキストから来ているのかが重要。それによって育てるべき場所が変わってくる。リンスタのMVPが好例。また、育てる時に自分だけでなく、他の人の視点を求めることが必要。発想が凍り、目的からズレる可能性が出てくるため。

エンジニアの知的生産術読了。何を学び、どのように自分を運用するかという話。なんとなく考えていたあれこれ知っている人の価値がちょうど説明されていた。突出したスキルを持つ個人や組織の橋渡し役になれる、という価値。

何を学ぶのが正しいのか。基本的には学びたいものを学べばいい。それが見つからないのであれば、身近な問題を解決するものを学ぶ。社会人の場合、例えば仕事の効率化について学ぶ。仕事を効率化すれば、より多くの時間を取れるようになる。取れた時間を使って投資の時間を増やしていく。

ぼんやりと思っていたことが明確な言葉になって腹落ちした感じ。やっぱ同じこと考える人はいるんだなー。答え合わせのようで、多少安心する。

できれば新卒とか、学生のうちに読んでおきたかった本。ほんの効率的な読み方とか、早く知っておけば知っておくほどに意味があるし。個人的には本の効率的な読み方と、知識獲得を途中で諦めてしまわないための目標設定のあたりの話とかが特に有用な印象。

「エンジニアの知的生産術」で覚えたKJ法を使って、自動化という考え方の役割や位置付けについて考えごとなど。。

自分は理解したい本は

1. 線・コメントしながら通読

2. 1の箇所中心にメモ書きながら読む

3. アウトプット時参照

で3回読む派で、遅さに一抹の不安があったんですが、紹介されてる多様な読みを見て少し安心

本書では読みを「娯楽」「情報探索」「理解の組み立て」の3種に分類してますが、上の自分の読みは情報探索は2まで、理解組み立ては3までやってる。もちろん時間制約などで万全にできないこと (締め切りがある文書用の資料など) はあるけど。

線引きとメモの点では、Kindleは良い感じでした。メモ追加可能なハイライト部分がノートブックにまとまり、該当ページも同画面に表示されるので文脈確認できる。

編集容易性も関連するだろうが、紙は線を絞りがちで、ばんばん線引くKindleと使い方が違うのも面白いと感じます

エンジニアの知的生産術読了。

最終章の「何を学ぶかを決めるには」では一度の人生という制約下で、何をどう学ぶのが良いかの案を示している。

例えば領域一点特化でなく、領域横断で自身の独自性を高めるや、早い段階である領域で上位になって情報・経験が集まる状態を作り学びを加速させる、など。

高校で文理選択を迫られ、授業選択も制限されていたこと、文学や哲学が実用性の観点のみから批判されがちなこと、(無批判な) 就職前提の専攻選択に異論がある身として、とても共感する最終章でした。大学の教養学部は自分には学びが多かったです。(上の選択が自身の判断の結果なら異論ないです)

ある領域でトップクラスの人も、複数領域で平均以上のクラスに属する人も、単純比較はできないけどそれぞれ独自の価値があると思ってます。

横軸に領域、縦軸に知識量を取った書中の図で言うと、その面積が価値の基本値に成り得るかなと。

難しいのは、領域特化型は能力測定が外から見ても容易なので、価値実現・周知の手段の心配は少ない (場合が多い？)。

領域横断で総和で勝負する場合は、どう組み合わせて価値実現・周知するかに「より」リソースを払う必要がある。

就職や評価の難しさもこの辺関係し、勿体無い実情があるだろうなと。

「エンジニアの」と銘打たれてますが、学習・アイディア作り・アウトプットの整理・新しい視点の導入をしたい方全般にお薦めです。自分も読むだけでなく、ちゃんと日々耕して生産しなければ。

どちらかというとinputの話が多くて求めていたものとはちょっと違う感があった

”エンジニアの”って書いてあるけど、自走して学びたい人にはみんな当てはめられそう。

通読以外の本の読み方を知らないから、本の読み方の部分は別の本を探してもう少し詳しく知りたい。

突発的な割り込みや細切れの仕事が多くなり、1, 2時間集中してなにかに取り組む、ということができない。そういう状況で、どう効率的にインプットとアウトプットのバランスを取っていくか、というのを悩んでいて、この本がとても参考になった。

いろいろな学習や情報整理のプラクティスは、けっこうそれと知らずに普段からやっていた

「普段それと意識せずにやっていること」が改めて丁寧に整理されていて、それが有効であるよ、ということが示される

細切れ時間で四苦八苦しながら学習をしている人におすすめの本

(ポモドーロ紹介サイトへのリンク)

25分めちゃ集中して、歩き回って休む、みたいなやつなんですけど、今日試してみたし良さげ。

終わりが想定できているものは量で、できてないものは時間で区切るやり方は良さげ。

ちなみにポモドーロテクニックの話も『エンジニアの知的生産術』で見たから試したやつです

1ポモドーロの概念が目から鱗だった

先輩たち長く集中できててすごいなぁとか思ってたわ

「エンジニアの知的生産術」を5割ほどまで読んでるけど、どこかで聞いたことがある鉄板の知的生産ノウハウを集積した本で、説明や例示が激ウマなので丸呑みしたい。

この分野、紙とペンの時代に凄い本が何冊か出た結果、古い部分もあるけど今でもそれらの本が読まれ続けていた分野で、この本は次のスタンダードを取れると思う。（まえがきにも、次の50年のための川喜田二郎本を目指したと書いてある）

「知的生産の技術」とか KJ 法の本とかと同様に知的な活動一般に適用できる内容だけど、一部ソフトウェアエンジニアを意識した説明や例などが入っているので、もしかすると他分野の人の視界にはなかなか入らないかも（？）

具体的な経験(データなど)を、抽象的概念に落とし込む、それを実証・検証

これをループすると限りなく智恵に近づく

あるデータのあつまりをAとする、そのデータの中からパターンを見つける。(直感的な思考)、パターンと自分の経験を組み合わせ、経験的法則を見つけ出す(論理的な思考)、実証・検証

Zという知識とYという知識を結びつけ、２つの間にある隙間を見つけることが新しい知識の創造

イシューからはじめよ、読み終わった。いかに質の高い知的生産をするにはどのようなフローを踏んだらいいのか〜という感じの本で、自分の頭でフワッとやっていることを言語化して整理させてくれる本だった（ここはエンジニアの知的生産術もそうだった）→もうちょっと早く読んでおけば、大学のレポートとかもっとうまく書けたんだろうな〜と思う。社会人になる前に読めただけでも良かった気がするので、プレゼン資料作る前とかにまた読み返したいですね

コーディングを支える技術のコラム、エンジニアの知的生産術の布石が撒かれてる感じがある

『エンジニアの知的生産術』を読んで読書法を確立したけど、本当に学んでよかった。私の場合、マインドマップ作ってると目的が変わってしまうから、行わないけど質問作って読むのは本当に良い。現代文のテスト問題を地味に覚えてるのと似たような感じになる。

結城浩さんのプログラマの数学を読了。文系、プログラミング未経験でSEになり、今まで5年間独学でなんとかやれてこれましたが、もっと早く手に取っておけば良かったと後悔です。中学から数学は赤点ギリギリで、ずっと数学に苦手意識がありましたが見事に払拭されました。

すこし前に読んだ西尾泰和さんのエンジニアの知的生産術に「数学書はわからないものをそのまま放置して読み進めはいけない」と書かれており、それを意識してだいぶ頑張りました…。完全に理解できたのか、自分の言葉で説明できるのかと言われたら怪しいですが…。

数学ガールの秘密ノートも読んでみようと思います。ちゃんと数字を扱えるように、また数学的思考力を身につけてしっかりと自分の頭で考えて課題を解決していける社会人になろう。頑張ろう。

「エンジニアの知的生産術」を読んで、今日から実践する事

・ゴールは明確に設定する

・知りたいことから学習する

・今必要なことだけ学習する（YAGNI原則）

・タスクを一つに絞る/時間を区切る（ポモドーロ）

・忘れたタイミングで復習する

・シンプルに分けて覚える

・本は段階別に読み進める

アイデアを創造すること。

創造は主観的

事後的に客観的な説明をひねり出す。

主観も客観どちらも大切。自分がどちらの観点が考えているのか意識しおく必要がある。

プログラミング教育は、不変の知識を教えるフォーマットにプログラミングを落とし込もうとしてるようで、なんだか無理してるなーって感じ。現代的なプログラミングはもはや変わり続けるものを学び続けるもので、そういう知識を過度に固着しない学習技術を教えられないものかな。

「コーディングを支える技術」はプログラミングを一段抽象化したうえで平易に書かれてて良い内容ですね。「エンジニアの知的生産術」の方も、学び方を一般化してて必須知識が増え続け変化し続けるソフトウェア技術との向き合い方として類のない内容だと思います。

あたりまえを疑え。

エンジニアの知的生産術

本当にそうなのかそれとも自分の意識から目についているのかはわからないけど、重なる部分あるなぁ。

つまりはそれが今の精神の置き所なんだろうなと思う。

順不同のtupleを覚える効率のいい方法を最近どっかで読んだ気がするなと思ったら、『エンジニアの知的生産術』で紹介されてた「知識を構造化する20のルール」だった

「エンジニアの知的生産術」を5割ほどまで読んでるけど、どこかで聞いたことがある鉄板の知的生産ノウハウを集積した本で、説明や例示が激ウマなので丸呑みしたい。

こういうメタ知識の獲得って複利で効くので、今読んでる本を一旦すべて投げ出してまずこの本を読んだ方が良い気さえしてくる

この分野、紙とペンの時代に凄い本が何冊か出た結果、古い部分もあるけど今でもそれらの本が読まれ続けていた分野で、この本は次のスタンダードを取れると思う。（まえがきにも、次の50年のための川喜田二郎本を目指したと書いてある）

「知的生産の技術」とか KJ 法の本とかと同様に知的な活動一般に適用できる内容だけど、一部ソフトウェアエンジニアを意識した説明や例などが入っているので、もしかすると他分野の人の視界にはなかなか入らないかも（？）

本の読み方とかは頭のいい人が知的に生きている様子みたいなのがわかって楽しい。エンジニアリング知識の習得とかに限定せず幅広く応用できる、ある種の生き方指南っぽい印象。

エンジニアの知的生産術の「数学書の読み方」を読みなおしてみて

数学を”使う”学問は、ある事象を表現するのに、数学自体の定義を前提に置いて使うために学んでいる（定義を疑うこと必要がない）

数学科は定義すらをも疑えるように数学を学んでいる

という違いに気がついた

これって、プログラミングを学ぶことでも同じですよね。

フレームワークを使うだけならば、個々の機能を覚えたり、提供される各メソッドのI/Oを覚えて使えればよい

けれど、フレームワーク自身に手を入れようとするならば、厳密な定義（実装）を知る必要がある

よく考えたら、「なぜそうなのか？」を答えられることで枠組みの前提を疑えるようになるのは、数学やプログラミングに限らないな...

エンジニアの知的生産術って本に写経しろと書いてあって嬉しくなった

新しい分野を学ぶときに必要なのははいつの時代でもやっぱり愚直に写経をすることだ

試験勉強の時は俺も法律答案の束が天井に届くくらい全力で写経を繰り返したもんさ

この前読んだこの本にもあったとおり、ある分野の知識が身につき出すとそれに関する情報や質問が自分のところに寄せられるようになってさらに身につくってのは、この1年でかなり実感したところではある

『エンジニアの知的生産術』で「〇〇について語るなら××ぐらいは読んでおけ」について否定的だったのに救われた。自分は自分の時間で別の勉強をしてたので良いと思うことにする。人の時間は有限なんだし、読書体験は人の前提知識や経験に大きく依存するし、どうせ全部覚えてるわけじゃないし。

読んでおけと言う人も何かしらの目的があるはずなので、より低コストで目的が達成できる落とし所を考えてみるのが良さそうですね。言われた方も、歩み寄る余地があるなら、相手の目的は何か、自分は直近どのぐらいのコストをかける準備があるかを話してみるのが良さそうですね。

数学書の読み方のところすごく共感できる

「クリアファイル整理法では、クリアファイルに大きく番号を書いておき、書類をクリアファイルに入れ、その番号と中身の対応付けはデジタルデータにします」

『エンジニアの知的生産術』 p173

紙データのインデックスをデジタル化するの、やろうと思ってやれてないやつだ……………

『エンジニアの知的生産術』読み終わった。メタ学習の言語化すごい。

優先順位の付け方に関する言及が個人的に印象に残った。

不確実性の高いものにどう立ち向かっていくかの考え方が参考になった。

ケンブリッジ医学生のYouTubeチャネルを見てスゴいなと思った。心理学の研究成果に基づいた学習法をiPadで最適化している。要点は2つで、

- Spaced Repetition

- Active Recall

が単位時間の記憶定着を数倍に上げる。下線を引く、何度も読むのは非効率的な勉強法だとか

「エンジニアの知的生産術」にも載ってたやつだ。時間を空けつつ繰り返すこと、「思い出し」をすること。 Anki もそれで知った。

なお今それで中国語の学習を始めてみてる。

岩永先生にオススメいただいた「エンジニアの知的生産術」では、ゴールを明確にするとやる気が出るという話が具体的に書かれてましたね。

私が「運動の習慣化のため、まずは同じタイミングで5分を7日やりきる」と決めたのもそんな感じ。

間を空けながら読んでしまったためか、ガスが充満している感じ。

このまま消えてしまうか、銀河のように渦を巻いて星が生まれるか…

おさらいした後、時間を空けてから思い出しながら読み返してみようと思う。

読書の効率を上げたくて4章を読み直した。

3分/ページ以上、以下どちらの場合も…

複数回読む

読むポイントをポイントを意識する

復習のための教材づくりは、文字通りの復習だけでなく、組み立て直す作業そのものでもあると思う。

書籍では復習に焦点があたっているように思えた。

山里亮太氏の「天才はあきらめた」を読んで思うのは、すごくエンジニア的な考え方だな、と。西尾泰和氏の「エンジニアの知的生産術」に書かれている内容を、自分で気付いて実践されている。

前々から疑問に思ってた、『本当に優先順位つけれるの？』っていう自分の疑問に対して一つのストンと来る答えがかかれてる。

エンジニアの知的生産術を読んでから、これまで自分が自分のためにやってきた勉強めいたこと全般に、具体的な目標を設定できた。エンジニア向けの用語が出てくるけど、新しい分野に挑戦する時に、汎用的に使える考え方を示してくれてて、誰かにお薦めしたくなる。よきよ。

「情報量が多いと苦痛を感じるから圧縮する」など人間の心理的な面を考えて説明してるのが私の中では印象的だった

今まで感覚的に脳みそで処理していた持論が言語化されており非常に良い．