エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESSプラスシリーズ)

著者 : 西尾泰和

• 技術評論社 (2018年8月10日発売)

感想・レビュー・書評

[amano225さんの感想 · 2018年9月17日]

知的生産術についての本。タイトルにエンジニアとあるから興味があって買って読んだのだけど、いまいちなぜエンジニアとタイトルにつけたのかよく分からなかった(エンジニア以外にもあてはまるというよりも、エンジニアはあまり関係なくないかということも多かった)。
エンジニアにあてはまるという意味では、新しいことを学ぶときは写経するのがいいということ。読んで満足することも多いけど、自分も写経するようにして勉強していこうと思う(どうでもいいけど、ずっと写経を「しゃけい」と読んでいた。変換できないなと思ったら、正しくは「しゃきょう」と読むとググって分かった)。
それにしてもこの本の著者、ずっとサイボウズのエンジニアだと思ってたのだけど、そういう側面だけではなく東京工業大学の准教授でもあるらしく、12000人以上という大規模なやる気が出ない人の調査をしたことがあるらしい。どうやって調べたんだろう。アンケートサイトか？
ただ、自分の問題だと思うのだけど、全体的にどうにも頭にうまく入ってこない箇所が多かった。なんというか、哲学的な話っぽくてわざと難しく書いているような感じ。比喩とか例えとかもよく書いてあったのだけど、それもよく分からなかった。

[ネクさんの感想 · 2022年5月8日]

情報収集、抽象化/パターン化、検証
　抽象化
　　共通点、差分、たとえ話

タスク
　洗い出し、一覧化
　　具体的な行動が不要なものは、ゴミ/資料/保留に分類
　　具体的な行動が複数なものはプロジェクトに
　　次に取るべき行動が
　　　2分以内ならすぐにやる
　　　他の人にやってもらうことなら依頼して連絡待ちリストに
　　　特定の日時ならカレンダーに登録
　　　どれにも当てはまらないなら次に取るべき行動リストに

不確かなものは楽観的に
　探索と利用のトレードオフ

目標はボトムアップで
　現在の行動
　現在のプロジェクト
　注意を向けるべき分野、責任
　1,2年後の目標
　3,5年後の目標
　人生の目標、価値観

タスクの切り方
　タイムボックス
　　1ポモドーロ（25分)1タスク

アウトプットが記憶を鍛える
　テスト後の復習
　　思い出せるだけ思い出してからもう一度読む
　忘れてから復習
　　ライトナーシステム
　　　やさしさ係数
　　　Anki
　認知的に高度な作業
　　問題を自分で作る

知識を構造化するルール
　最小情報原則にこだわる
　　問題を可能な限りシンプルに
　順序の定まらない集合を覚えようとするな
　複数のものの並びを覚えようとするな
　穴埋め問題は覚えやすく効率的
　理解できないことを学ぼうとしない
　　ドイツ語ができないのにドイツ語で書かれた教科書を暗記する等
　暗記する前に学ぶ
　　知識の全体像を把握
　基礎から積み上げる
　干渉を見つけて取り除く
　　似たような英単語を同時に覚える等
　他の記憶と関連付ける
　個人の体験や具体例と絡める
　感情と絡める
　言い回しを簡潔にする
　　モデルに名前をつける
　出典を示す
　日付を記録する

読書
　目的を明確に
　概要を把握
　　目次などに注目
　キーワードを抽出
　質問を作る
　熟成させる
　　10-20分、できれば一晩寝かせる
　答えを探す
　マインドマップにまとめる
　人に教える
　
　残像が消える前に別の本を読む
　　アイデアの結合
　読書メモを定期的に読み返す
　　間隔反復法
　　　読書メモへのリンクをAnkiに登録する等

アウトプット
　KJ法
　　アイデアメモを書き出す
　　　100枚目標
　　　重複などは気にしない
　　並べて一覧性を高くする
　　　並べてる途中に思いついたものも記録する
　　グループ編成
　　　関係ありそうなものをまとめる
　　　　事前に分類方法を決めない
　　　グループに名前をつける
　　図解化する
　　　関係などを図示
　　　　類似、対立等
　　文章化する

アイデア
　インプット
　　情報収集、加工
　　言語化
　　　身体的感覚に注目
　　　絵に書く
　　　たとえ話を考える
　　　　課題からキーワードを選ぶ
　　　　キーワードを別の空間に紐付ける
　　　　メタファの空間で連想する
　　　　連想したものを課題空間に引き戻す
　　自分の枠に囚われない
　寝かせる
　アイデア誕生
　ブラッシュアップ
　　最小限の実装で製品化する
　　　顧客を明確にして品質を定義する
　　フィードバックを分析する
　　　意見の違いに着目
　　フィードバック反映
　　　機能の改善
　　　アイデアの作り直し

　暗黙知
　　暗に知ること
　　　問題の解決に近づいているか、近づいていないかを感知する非言語能力
　　　　言葉にできない違和感
　　　　　重要だと思う身体的感覚に関するキーワードを書き出す
　　　　　キーワードに対する辞書の説明と自分の感覚を比較する
　　　　　キーワードを使って短文を作る
　　暗に知っていること


知識
　拡大再生産戦略
　　知識を使って
　　　時間を得て、その時間を知識獲得に投資
　　　お金を得て、そのお金を知識獲得に投資
　　　立場を得て、その立場を使って知識獲得
　差別化戦略
　　複数分野をまたいだコミュニケーション
　　　社内の複数組織
　　　社内で学んだことを社外へ発信
　　　社外の情報を社内に発信
　　　仕事とは別のボランティア活動

[honnyomimannさんの感想 · 2020年3月4日]

インプット、記憶、アウトプット、やる気の保ち方など
それぞれに大量量産型ビジネス本がありそうなテーマに対してこれまた色々な方法論や有名な教訓などをつらつらと書いている。抽象的な絵に落として綺麗に伝えている風に見せたりしているが総じてくどい。

例え話がIT寄りでそこが"エンジニア"要素なだけに過ぎない。

本当に"知的生産"を必要とする人は自分で考えてここで紹介されている原点に当たったり、実践したりして自分のものにしていることだろう。この一冊を読んで生まれ変われたら人間苦労しないだろと思わせられる系の本。

途中リタイヤ

[全ての本さんの感想 · 2020年1月5日]

速読をすればたくさん学べる、フレームワークを使う、優先順位付けをする、など、誰も疑わずに当たり前だと思っていることが、いかに考えずに行われているかがわかる。自分が、日々周りに対して感じていたけど、何がおかしいのか言語化できていなかったようなことが、的を射るように書かれていた。
自分がこの本を読んでいくらなるほど！と思ったとしても、エンジニアの場合、これをチームに浸透させる必要があるのが難しいと思う。

[えんどぅーさんの感想 · 2019年10月16日]

非常に良かった。
エンジニアだけではなく、社会人の限られた時間でいかに効率的に知識を獲得するのか?と言った話もあって、大変勉強になりました。
特に7章「何をまなぶべきか」の部分で語られていた、「新しい知識を生み出すのが価値の源泉」といのはこの本を通して、最終的に卓越すべき状態である事も明確にイメージができました。

読書メモはこちらにまとめています。
https://scrapbox.io/fendo181/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E7%9F%A5%E7%9A%84%E7%94%9F%E7%94%A3%E8%A1%93

[馬場久志さんの感想 · 2019年8月12日]

amazonのレビューにあるとおり、様々な方法論がごった煮で書かれている。この1冊ですむと考える人もいるだろうが、本当に学びたいなら原典に当たりたい。また、脚注や筆者の経験がやたらたくさんあるが、「その情報いる？」と首をかしげたくなる情報がほとんどに思えた。
最初は真面目に読み進めていたが、上記のような実態に気づき、大部分は読み流した。

新たに学んだ点:
・タスクの優先順位を付けること自体が難しいタスク。
・昔に比べて本を出版するハードルは下がっているため、以前に比べると本の情報の信頼度などは下がっている。

[komazarariさんの感想 · 2019年1月24日]

情報収集、モデル化、検証という学びのサイクルにおいて何を行うかが具体例豊富にまとめられている。エンジニアの〜 とあるが頭脳労働全般に活用できそう。

全体としては、効果的なインプット、そして情報整理による新たな関連の認識などが大きなテーマに見えた。フェーズや概念には適宜名前を付けて説明されているので一つ一つがわかりやすい。

また著者が活用しているテクニックについて具体的な名前を広く拾うことができる。この本だけでも要点は説明されているが、連鎖的に元ネタをたどるための入り口としても非常に助けになる。
個人的には読書技術についての学びがとても大きかった。

[chrojuさんの感想 · 2018年8月20日]

KJ法、ポモドーロ・テクニックなどの数多の見知った方法論が引用されているものの、それをどう使うのか、なぜそれを使うべきなのかというのが具体化されているので腑に落ちる。

最もよかったのは「差異に着目する」という点で、これは似ているな、同じだなと思ったときに、完全一致するわけじゃないのであれば、何が違うのかをきちんと言語化せよというのが響いた。「ああ、これ見たことあるわ」で流しがちなことは確かに多かったし、本書のKJ法などの記述も見たことある話ではあるのだけど、じゃあ他の本と何が違うのか？を考えることで身についてくる。相対化して抽象化ができる。この姿勢は大事にしたい。

[kaiさんの感想 · 2023年11月23日]

Twitterでおすすめされてた

創作においても、仕事においてもいい本だった

・・・以下メモ・・・
★は自分が思ったこと

■知的生産とは

他人から与えられた知識を使うだけでは大した価値にはなりません
→自ら新しい知識を生み出すことが価値の高い知的生産のためには重要
→→サンプルコードをコピペするだけでは目的を達成できない。噛み砕いて理解し、あなたの置かれた状況にあわせ、修正し、組み合わせ、新しいプログラムを作る必要がある

■知的生産術とは
①アイデアを思いつく
②理解を深める
③パターンを発見する
→共通の要素がある


■プログラミングの学び方
具体な情報収集
比較してパターン発見
実践して検証
→★★全く同じ！

■出力について
人間は脳内の知識を他人に丸ごとコピーできないので、脳内の知識ネットワークを、切り取り、束ね、並び替えて、言葉や図に変換していく作業が必要です

■モデル化・抽象化
情報収集は箱を並べるイメージ
モデル化は箱を積むイメージ

本になる文字は支えとなる箱が削ぎ落とされて抽象的な内容になっている
具体的例をいれたいけど、見る人がどんな知識を持っているかわからないので支えの箱が足りない。あなた自身が考えることで足りない箱を作り出していく必要がある
→★★★これは仕事でも創作でもとても共通する

数学は高く積み上げられるが
その他の分野は多くの箱でピラミッド型に積まないと崩れる

■実践・検証
試行錯誤は見えにくい
プログラミングでも書いて最初に実行した時高い確率で機体と違う動きをする

■チュートリアルは実戦に近いほどいい
→〇〇をマスターしよう、では頑張れない。
★このjava3本を単体テストまで終わらせる、と指示する

■知りたいところから
→必要になった順

■そんなの必要ないよ
yagni原則
→必要になるまで機能を追加してはいけない

■matz まつもとゆきひろ　ruby作者
・全体を読もうとしない
面白そうなところをつまみ食いして、先人の知恵を学ぶ
・目的をもって読む

■知りたいことから学ぶための前提条件
・目標が明確化されてる
・目標が達成可能である
・大まかに全体像を把握している
→どこを探せば良いのかがわかる

■大雑把に
全体像を把握は、ゴールではない

■抽象
具体的な対象から注目すべき重要な部分だけを抜き出す意味

■モデル
mvcだと、プログラムの本質的な部分
→表示、と、操作に関わる部分を取り除いた部分

■人間の知能を増強する方法
①人工物
→計算機など
②言語
③方法論
④教育

■例え話
どこが同じでどこが違うかを、明確にしないと混乱する

■パターン本から学べばいいか？
あなたが具体的な経験を持たないままパターンだけを習得することはできない

誰かが積み上げたピラミッドの上の方の箱だけを見て、あれはいいな、ほしいな、と思ってもってきたとしても、それを置く場所の土台が準備できてなければ、ただ地面に置かれるだけ

■アイデア
耕す
芽生える
育てる

■芽生えは管理できない
管理できないものは管理しない

■言語化
自分の中から情報を引き出すためには、まだ言語化されていないものの言語化を促すことが大事です
言語化して紙に書けばそれは掴んで動かすことができます

人は語れる以上のことを知っている

■フレームワークのメリットとデメリット
フレームワークは盲点を埋めることに有益
一方で、フレームワークはそれ自体が既存の固定化した思考の枠です
→★これはmjにも言えること、枠組みにとらわれることなくさらに考えていかないと未来はない

本当に新しいものは、既存の枠の外にあります
→★確かに、、、

フレームワークは習慣性のある薬のようなもの。適切なタイミングで少しだけ使えばとても有効ですが、乱用し継続的に使用し続けると有害なります
→探索と利用のバランスが重要

■創造は主観的
芽生えてから、それを育てるフェーズで、事後的に客観的な説明を捻り出すのです。
主観的になることで、既存の枠を壊すこと
→★これ大事、最初に引っかかる言葉を置いちゃうこととか

■例え話　アナロジー
例え話は個人のこれまでの経験によって機能する、主観的な道具
→凧揚げをしたことのない文化圏の人をイメージしても、凧揚げのイメージがわかない

■シンボル
その○はどんな種類の
その○について、ほかになにかありますか
その○はどこにありますか
その○はどのあたりにありますか
その○らなんのようですか

それから何が起こりますか
次に何が起こりますか
そのすぐ前には何が起きますか
それはどこから来るのですか

○と✖️はどういう関係ですか
○と✖️は同じですか、違いますか
００と✖️ほ間には何がありますか
○が起きた時、✖️には何が起こりますか
→たこと、風など

質問を繰り返してシンボルの位置や特徴や関係を明確化していくことで徐々に発展する

注意
個人的なメタファーも生まれ出たそのままの形では有効に働きません。なので他人に伝わる形に修正を繰り返す必要があります
→★nkykさんはこれができてなくて唐突感ある

■まだ言葉になってないもの
水面に一番近いもの
→違和感、暗黙知

もし何を探し求めているかわかっているなら問題は存在しないし、もし何を探し求めているかわかっていないなら何かを発見することは期待できない（プラトン）
→部屋の財布を探すように簡単じゃない

■言語化まとめ
身体感覚、経験、違和感に注目する
→まだ言葉になってない
→言葉にしようとすると例え話や、メタファの形になることがよくある

出てきたばかりの言葉は説明なしには人には伝わらないかもしれない
でも、つたわらないことを恐れる必要はない
まず、自分の中から取り出し、書き留めて消えないようにして、それから人に伝わる形に改善すれば良い

言葉は把手であり、あった方が操作しやすくなる

鳥の声のように、把手である言語から、身体感覚が外れてしまっていることもよくあります。
その場合、身体感覚におりていって、取っ手を繋ぎ直してやる必要があります
→★なるほど。


あなたの中にある、
・まだ言語がされていないもの
と、きちんとつながった
・言語されたもの
を、作ることがここでの目的

つながってない、根無草のような言葉を使っても意味がないのです
→★経験や身体感覚のない言葉
これもnkykさんに感じる

■最小限の実現可能な製品
誰が顧客なのかがわからなければ、何が品質なのかもわからない

■
良いアイデアは自分で育つ（Young）
→見た人を刺激して、その人が積極的にフィードバックをくれるから

■自分の中にかわきたじろうエミュレータ。作る
ある機械の動作を別の機械で模倣することをエミュレーションと言い、その模倣する機械をエミュレータと言います。たとえばゲーム機によっては、昔のゲーム機のゲームを遊ぶことができる機能を提供しています。これができるのは、新しいゲーム機の内部に
古いゲーム機のエミュレータがあるからです。

■スペシャリスト戦略

その新人研修で教わることをまんべんなく習得したところで、その知識は低い価値しか生みません。その知識は同じ職場の全員が知っていることで、まったく差別化につながらないからです。分野をずらし、卓越を目指す必要があります。
ここで連続スペシャリスト戦路を取るなら、まず新人研修や先輩の模版によって分野Xの知識をある程度学んでまあまあ評価されたら、分野Xの知識をさらに高めるのではなく、新しい分野Yの知識を手に入れることに時間を投資することになります

■言葉は取って

そういう名前の付いていない概念や考え方に、本を読むことによって名前が付くことがあります。

そのうまく表現できない考えを説明したところ「ああ、それは『損益分岐点』だね」と言われ、新しい言葉を手に入れました。名前がわかると、それについて検索できるようになり、関連した知識を入手しやすくなります。

こうやって言葉を手に入れると、その言葉を使って思考をすることができるようになります。つかみどころのないモヤモヤとした考えに「言葉」という「取っ手」が付き、その取っ手をつかんで操作できるようになるのです。
不定形な水はそのままでは持ち運べませんが、容器に入れると持ち運びができるようになるイメージです。

[bob-taniさんの感想 · 2023年8月8日]

インプットサイクルの名著。
フレームワークの構造化のデメリットも示唆し、KJ法を筆頭とした発想法にも触れている。
好きなU理論やGTDに具体と抽象を踏まえた学習サイクルが見て取れる。
読むことそのものも章としてさいており、何から始めればと考える学習者に向いている。
情報基盤を作る必要性がインプットサイクルには求められていると考えると
ここで語られる整理とアウトプットに目的は欠かせない。
優先順位をソートの視点でそもそも付与することに力を使う視点がよい。
私はAnkiの設計に驚き、学習サイクルに暗記することの重要性を噛み締めたい。
また、ソースコードに「物語」はないというMatzの考え方は学びで、
プログラム学習者を対象とした書籍ならではのベースもある。
プログラミングは高速なテストサイクルと考えると学習者としての素地があると言える気づきがあった。

情報基盤の本ではあるのでアウトプットの話はあるのだが、
それ以上にボトルネックが情報の組み立てと考えるとインプットサイクルの見え方が変わる点で、インプットのやり方の本としての魅力を語りたくなる。