3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

YAMAP エンジニアAdvent Calendar 2023

Day 22

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

Last updated at Posted at 2023-12-21

書影

自分の環境に合わせて適用し創造性を高める

仕事をするうえで、どのように学び、整理し、アウトプットするのか。
ソフトウェアエンジニア向けに、プログラミングと執筆を具体例として、知的生産の方法を解説した書籍です。

サンプルコードの丸写しでは仕事に役立つプログラムを書けないのと同様に、
知的生産術も丸写しではあなたの役に立つものにはなりません。

本書では、数々の知的生産術を比較して学ぶことで、何が重要な原則なのかを体得し、
みなさんが自分の環境に合わせて手法を修正し、組み合わせ、新しく生み出せるようになることを目的とします。
また筆者が日ごろ行っている具体的な手法や、今までの試行錯誤も紹介します。

この記事について

上記の本『エンジニアの知的生産術』の要約です。
私は2019年に異職種からエンジニアへ転職しましたが、そのときの学習指針とした本です。
「エンジニアの」知的生産術というタイトルとおり、「エンジニアだけのための」本ではなく、知的生産に関わる全ての人々にとって有用な内容が書かれているため紹介することにしました。

※ 学習用にまとめた要約につき引用の範囲を越えていますが、著作者が以下のようにおっしゃっていましたので公開することにしました。西尾先生ありがとうございます。

僕は「エンジニアの知的生産術」や「コーディングを支える技術」のまとめをブログに書くのは、出典が書いてあるならOK、むしろ大歓迎、という立場です。

(https://twitter.com/nishio/status/1315546368153276416 より引用)

本書の内容

知的生産を行ううえで効率的な方法について解説

  • 知的生産=知識を用いて価値を生み出すこと (e.g.,プログラミング)
  • 本書で紹介されるプログラミングの学び方
    • 情報収集→モデル化→実践・検証の流れを繰り返す
  • エンジニアに限らず、様々な分野に応用可能

本書の流れ

目次

  • 第一章 新しいことを学ぶには
  • 第二章 やる気を出すには
  • 第三章 記憶を鍛えるには
  • 第四章 効率的に読むには
  • 第五章 考えをまとめるには
  • 第六章 アイデアを思いつくには
  • 第七章 何を学ぶか決めるには

インプット・アウトプットの効率的な方法とそのやる気を維持する方法について解説→最後に学ぶ対象をどのように決めるかを紹介

新しいことを学ぶには

■ 学びのサイクルの基本は「情報収集→モデル化→検討」

イメージで言うと、

  • 情報収集は箱を水平に並べていく。
  • モデル化=抽象化は水平に並べた土台の上に箱を積んでいく。

土台なしに空中に箱を置くことはできない。
→ 抽象的な概念だけを学ぼうとしても、ただ情報を丸覚えしただけになってしまう。

  • 箱を集めて並べることが情報収集
  • 集めた箱を眺めて上に積める箱を考えることが抽象化

■ 情報収集

本やドキュメントなど文字になった情報は、書き手がすでに抽象化したもの

抽象化された知識の前提となっている土台が足りないことがある。

→具体的な情報=データや実際に経験したことが足りない。

情報収集の方法

知りたいところから学ぶ
  • 学習におけるYAGNI ("You ain't gonna need it") の法則
  • やる気を維持しやすい。
大雑把に全体を学ぶ
  • 本や論文の目次、見出しに着目
  • コードの場合
    • ディレクトリ構造→ファイル構成→略語を調べる→関数どうしの呼び出し関係を把握→関数の中身を読む

片っ端から学ぶ

  • 何から学んでよいか分からず、全く知識を持たない人が最初の一歩を踏み出す場合に有用
  • 写経
    • 手を動かすことで「データや実際に経験したこと」が得られる。
    • 時間はかかるが確実な場合が多い方法

■ 抽象化・モデル化

モデル

  • 現実世界のしくみを説明するために簡素化された表現のこと
  • 複雑な現実世界を人間の認知能力でも扱えるように簡素化したもの
    • e.g., 高校物理学では、空気抵抗や摩擦を無視して問題をシンプルにして、高校生が扱えるようにする。
    • →モデルの価値は、現実との一致度ではなく、モデルを操作することが現実を直接操作することに比べてどれくらい低コストになったか

抽象

  • 世界を観察して繰り返し現れる共通のパターンを見出し、有用なものに名前をつける。
    • e.g., 四本脚で耳と目と鼻と口があり人間になつく生き物=「犬」
    • → 個体によって毛の色や耳の形が違ったりしてもその違いは無視している。
    • →重要でない部分を隠し、重要な部分を抜き出すこと (cf. 小室直樹『論理の方法』)

サンプルコードのコピペや丸暗記=全く同じ状況に適用可能だが、少し違う類似した状況に応用できない。
→複数のサンプルから共通するパターンを発見して一般化していく。

一般化

「ハトは飛ぶ」「スズメは飛ぶ」「ツバメは飛ぶ」→「鳥は飛ぶ」

応用

「鳥は飛ぶ」「ウグイスは鳥」→「ウグイスは飛ぶだろう」

抽象化の方法

「同じ」と「違う」に着目して「一部同じで一部違う」状態を見つける
たとえ話で説明できないか試す
具体的な経験を持たない状態ですでに発見されたパターンを学ぶことはできない。

誰かが積み上げたピラミッドの上の方の箱を見て、「あれはよいな、欲しいな」と思って持ってきたとしても、それを置く場所の土台が準備できていなければ、ただ地面に置かれるだけです。(p.43)

習得した知識をきちんと土台の上に置けているかどうか

  • 自分の言葉で説明できるか?
  • 自分の経験に基づいた具体例を挙げることができるか?
  • 自分の目的を達成するためにその知識を使えるか?
    などを確認してみる。

■ 実践・検証

プログラミングは、正しく理解できているかどうかがとても検証しやすい分野

  • 試行錯誤のコストが安い。
  • 大部分の間違いはエラーメッセージが教えてくれる。

コードを書く以外の検証方法

  • 自分で解説を書いてみる。
  • 問題集があれば解いてみる。
    など

やる気を出すには

やる気がでない二大要因

  • タスクを絞りきれていない
  • タスクが大きすぎる
    のどちらかを疑う。

■ タスクを絞りきれていない

  • 全体像を把握するために思いつくことを可能な限り列挙
  • 優先順位付けに固執しない。
    • タスクが大きいとコストが跳ね上がる
      • e.g., 値の大小を比較するアルゴリズム
    • 評価軸が複数ある
    • 不確実性がある
  • 「基地」を作る
    • まず領域を区切り、その分野だけは片付いている状態を目指す。
    • 気になること全ての処理には時間がかかりすぎるので、「今日やるべきこと」に集中して、それが整理されている状態を作る。

不確実性を評価する方法

探索と利用のトレードオフ

  • 探索の不足=過去の経験から最も良いと思う行動ばかりをしていては、もっと良い行動を見つけられない
  • 利用の不足=未経験の行動ばかりをしていては、過去の経験を活かせない
    を解消するためのもの

「不確かなときには楽観的に」という原理にしたがったアルゴリズム

  • 楽観的な間違いをしていればあとで修正できる
  • 悲観的な勘違いにはまって身動きがとれなくなる可能性が減る

■ タスクが大きすぎる

「4時間で終わらない」タスクは多くの人にやる気を失わせる。
→巨大なタスクは4時間以内に実行可能なタスクに分割する。

タスクを時間で区切る方法
→ポモドーロ・テクニックが有用

記憶を鍛えるには

記憶が強化される仕組みを紹介
→段階的に作られ、繰り返すことによって徐々に長持ちするようになる。

似た情報が繰り返し入ってくると、刺激に対して脳が鈍くなる。
記憶の強化にもインプットとアウトプットの繰り返しが重要
→テストを受けて記憶をアウトプットすること自体が記憶を強化するという調査も(e.g., 繰り返し学習群と思い出し学習群の比較)
認知的に高度な作業を必要とした記憶は残りやすい。
など

効率的に読むには

人間というハードウェアには、自分が抽象化したモデルを直接相手の脳に送信できる通信手段がない。

  • 言葉
  • 文字
  • 活版印刷
  • インターネット
    技術の進展による情報量の増加にかかわらず、知識表現は単語を一次元的に並べたものである。脳内のモデルを単語に分解して、それを受け手が自分で組み立て直す必要がある。
    →本に書かれている内容だけではなく、自分が経験したことも含めて個人的なモデルが組み立てられる。
    情報を見つけるイメージだけではなく、本から得た材料と自分の経験を組み合わせて構造化していく「理解を組み立てる」イメージを忘れてはいけない。

■ 本を読む速度について

  • 本を読む速度を改善したいとき、いまどれくらいのスピードで読んでいるか現状を把握することが必要
  • 計測なしで計画を立ててもうまくいかない
  • 多くの人の場合、頭の理解速度が読書速度のボトルネックになっている

■ 本を読むというタスクの設定について

本を読む目的≠本を理解する
→「本に書かれていることの総体」を知らないので、100%理解したかどうかを判定できない。達成不可能なタスクを設定することは、モチベーションを損ねる原因にもなる。

目的の例

  • 理解ではなく時間で区切る。
    • 1ポモドーロ(=25分)読む。
  • 書かれている内容の大雑把な地図の入手
    • どんな知識が書かれているかを把握して、必要なときに読み返せるようにする。
  • すでに持っている知識との結合
    • もともと持っていた問題意識と結合させる。
    • 経験によってわかったことを表現する言葉を持っていない状態で本を読むと、その概念に名前をつけられる。概念の名前がわかると、その概念が検索しやすくなるので関連知識を入手しやすくなる。
  • 抜き書きを作るを目的として読む。
  • 読書ノートを作る場合
    • 価値の低そうなものがずっと目立つところに残ると失敗
    • 価値の低いものが明示的な意思決定なしにフェードアウトする仕組み(e.g., Ankiなど)を応用する。Incremental Reading
  • 人に内容を教える。
    • 実際に教えなくても、資料を作るだけで記憶の強化に効果がある。

■ 読書の価値

寺田昌嗣『フォーカス・リーディング』

  • 読書の価値=著者の力×自分の経験×ビジネス力
  • 自分の経験=情報を取り出す力×いままでにした経験×経験と情報をもとにモデルを組み立てる力
  • ビジネス力=顧客のニーズを把握して経験をもとにモデルを組み上げる力

■ 読書の方法論

見出しに注目する方法

  • 見出しは本文よりもコストをかけて作られている
  • 書籍のタイトルは商業上の理由で不適切になることが多いので信用しない
  • 図は本文を作るよりもコストがかかるので注目する
  • 脚注やコラムを削るほうが楽なのにわざわざ載せているので注目

読む前の準備に重点を置く方法

  • 目的を明確にもつ
    • ただし本の内容を知ってからでないと目的を持てないこともある
  • プレビュー:大雑把に全体を把握する。目次や本文をざっと眺めて、キーワードをメモする。1冊5分程度でやる。設定した目的に適うか自問する
  • 本の内容についての質問を作る。このとき、答えを見つけようとしてはいけない
    • 熟成させる。できれば一晩置く
    • 熟成が済んだら、改めて本を読む。ざっくりつまみ食いをしながら読む。質問の答を見つけることが目的
  • 質問の答え、学んだことをメモしていく。マインドマップツールにツリー状にまとめるとよい
  • 最後に、自分が適切だと思う速度で止まらずに最後まで一気に読む。

難しい本を読む方法

  • 章の見出しを先に写経する。
  • わからないことは何でも記録する。
  • 用語・論理の道筋・問題意識の理解が不十分だと本がわからなくなる。
    • わかる=なぜそうなのかが言える
  • 本を理解できないときには意図的に速度を落とす。このときに必要なのが「写経」

考えをまとめるには

情報がまとまらない原因

  • 情報が多すぎるか、少なすぎるかのどちらか
  • どちらの原因によるものなのかを先に把握する。

関連しそうなことを全て書き出してみる。

  • この段階では情報の質を気にしてはならない。
  • 数単語〜1文程度でよい。
  • 50項目列挙を目標にし、足りなければ情報収集を続行
    • 目標を設定することでタスクを細分化でき、モチベーション維持にも役立つ。

挙がった項目を整理する。

  • 書き出したことで、思考の断片が消えなくなる。
  • 項目を一覧に並べることで、外部化した思考の断片を脳に戻しやすくする。
  • 関係する項目を近くに移動
  • 重複して挙がった項目は重要な場合が多い。

分類時の基準について

  • 適切な分類基準を作るのは困難。分類対象の全体像を把握していければならない。
  • 事前に分類基準を作ることは不適切。もし分類にそぐわない項目があれば、項目側を見直す。
  • 既存の分類に従うと、それを分類した理由の問いに既存の分類を使って答えることになり、分類によって言語化されていないものを言語化する効果を発揮できない。

アイデアを思いつくには

「アイデアを思いつく」というのは巨大なタスクなので、三つのフェーズに分解する。

  • 耕すフェーズ
  • 芽生えるフェーズ
  • 育てるフェーズ

耕す

  • 情報を集め、分類し、つながりを見出す。

芽生える

  • 情報を寝かせて、芽生えを待つ。
  • 管理できないフェーズ
  • タイムリミットがあれば、タイムリミットまでに芽生えたもので残りのフェーズをすすめる。

育てる

  • 生まれたアイデアが有用なものであるかを検証する。

■ 情報収集

自分から情報を引き出すには、言語化されていないものを言語化することが重要。つかみどころのないあやふやな状態のままにしないため、書き出すことで操作可能にする。
質問をトリガーにする。Symbolic Modellingと呼ばれるカウンセリング手法における質問

  • そのXはどんな種類のXですか
  • そのXについて、ほかに何がありますか
  • そのXはどこにありますか
  • そのXはどのあたりにありますか
  • そのXは何のようですか

言語化されていないものに対する違和感を見つける。
→人間が短期間に試行錯誤を成功させてきた理由:問題の解決に近づいているという非言語的な感覚を覚えることがあるから(Michael Polani)
「問題の解決に近づいている感覚」⇔「問題から遠ざかっている感覚(=違和感)」

アイデアを生むこと=「主観的な違和感や身体感覚、個人的なメタファを駆使して、誰も見たことのないものをたぐり寄せる」

何を学ぶか決めるには

掛け合わせによる差別化戦略

  • 分野 × 分野
  • 分野 × 組織

「知識の貿易商」戦略

  • 片方の組織で知識を習得し、その知識を別の組織に運んで利用することで価値を生む。
  • 知識は複製できるので、知識が自分を経由して流れていくようにすると蓄積される。

他人から学んだ知識は価値が低いことが多い。
新しく知識を生み出すことが価値の源泉

まとめ

情報を収集してモデル化し、それを現実に応用して問題を解決するというのは、
多くの人にとって仕事や日常の場面で実践する必要のある必須スキルと思うのですが、
本書ではその実践方法が具体的に書かれていて、
エンジニア以外の人にも参考になるのではと思います!
気になったら是非読んでみてください。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?