『エンジニアの知的生産術』を読んだ

意識高そうな本を読んで意識が高まったので書いています。たぶん寝て起きたらもとに戻っています。

どんな本か

gihyo.jp

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

とのこと。著者は西尾泰和さんという方で、現在はサイボウズ・ラボにお勤めで、コーディングを支える技術の著者でもあります。平たく言ってめっちゃデキる人間のようです。昨年8月に発売され、かなり話題になっていました。

なぜ読んだか

知的な生産性をあげたいからです。自分はオッサンに分類される年齢ですが、エンジニアを名乗るにはあまりに能力が足りないと自覚しており、やるべきこと、やりたいことが山積みです。それらを愚直にやっていくには人生が足りなさすぎますし、若者たちに淘汰されて終了しそうです。本書は特にエンジニア向けに書かれているとのことで、目次をチラ見してこれはイイゾとなったので読みました。

読んでどうだったか

良かったです。どこかでみたことあるような…という内容も多い気がするものの、ある程度学術的に意味のあるリファレンスと紐付いて各手法が紹介されています。また、著者が本書を書くにあたって実践した内容もあわせて紹介されており、読みやすく有益な内容にまとまっています。とはいえ、これらを実践していかないと意味がないです。ついついこういう意識高い本を読んで満足しがちなダメ人間なので、今回こそ実践していきたい気持ちでいっぱいです。

以下、印象に残った箇所のメモや感想など。

やる気のでるタスクを設計する

知的生産性の研究者である著者が、学習のサイクルを回す原動力を「やる気」というエモい言葉で表現しているのが印象的でした。その上で、脳に報酬を与えてやる気を維持するタスク設計について理路整然と書かれています。

明確な目標設定が重要です。例えば「Pythonをマスターする」とか「DDDを理解する」というのは曖昧な目標であり、やる気を阻害します。仕事など必要に迫られるのがベストですが、そうではない場合にも「ブログを書く」「人に説明する」など、アウトプットという形で達成したか否かが計測可能な目標を設定します。ここで、目標自体が大きい場合、さらに分割します。例えば、「○○という本を読んで得た知識をブログに書く」という目標の前段階として、「得た知識を付箋に100枚書き出す」という過程の目標を置きます。これがいいのは、タスクが小さいことと中断可能なことです。このように、やる気を維持するには、「達成したいこと」に対して、闇雲に向かうのではなく、タスク設計をちゃんとやる必要があります。

自分がよくやってしまうのは、「○○を検討する」とか「○○を整理する」みたいな、達成点が曖昧なことをぼんやり頭に残っている状態です。信じられないくらい進捗が無になります。時間で区切ったり、だれかに説明したり、社内共有のドキュメントにまとめたり、なるべく具体化する作業をやるべきです。頭ではわかっていますが、それ自体がだるかったりします。ちゃんとやります。

全体像を把握する

技術書を普通に通読するとかなりの時間がかかります。そこでボトルネックとなっているのは、ページ送りや目の動きではなく、脳の理解であり、さらには「理解の組み立て」です。この組み立てを効率よく行うために、まず目次を把握するという方法や、ページをパラパラと読んでキーワードを抜き出す、など、全体を把握する読み方が有効だとしています。これはコードを読む場合も同じで、READMEやドキュメントを読み、ディレクトリ構造を把握してからコードを読んだほうが効率的です。自分も本に応じて、また読書の目的に応じて、読み方を変えたいです。すぐ通読しようとしてしまいます。グッと堪えます。

自分は小~中学生のころけっこう本を読む人間でしたし、その後も主に小説を好んで読んでいたりして、通読するクセみたいなものがついている気がします。あと、脳が負荷を避けているのもありそうです。目次を読んで頭に入れたり内容を想像するのは、トータルでみると効率を上げるはずですが、思考疲れというか、文字を追うだけの読書に逃げている感覚です。その意味で、学習のための読書はかなり消耗することを自覚し、ちゃんと休みましょう。

いったんぜんぶ書き出す

「GTD」というメソッドが紹介されています。この文字列はどこかでみたことがあったのですが、内容は初めて知りました。Getting Things Doneです。「やる気が出ない人の65%はタスクを1つに絞れていない」らしいです。わかる。人間の脳はマルチタスクができないように作られていないみたいですし、自分は特にそうです。コンテキストスイッチは想像以上に消耗します。タスクを絞るためには全体を把握します。

GTDはDavid Allenというひとが開発したメソッドで、なんと日本版公式サイトもあります。概要はそちらをどうぞ。超絶雑にいうと、「いま気になっていることを全部書きだし、それを上から順番にやっていく」です。一般的なタスク管理と違うのは、「タスクかどうかにかかわらず気になることを全部書く」という点と、「優先順位をつけない」という点です。それら自体が重い作業なので、放棄する、というものです。

タスク管理はそれ自体が目的になって、きちんとやりたくなってしまいますが、そこにかけるコストを自覚してバランスをとっていきたいです。タスク管理をあまりがんばらないようにします。仕事ではいまはAsanaを使っています。一日の頭にタスクを整理する時間をとっています。この前段階としてGTDをやる時間をとってもいいかもと思いました。

不確かなときは楽観的に

GTDで優先順位をつけないとはいえ、現実にはそれぞれのタスクには時間的な制約があり、優先順位をつけざるを得ない場面がほとんどです。優先順位付けというタスクが重いのは、不確定要素のためです。「不確かなときは楽観的に」というのは、ポジティブバンザイ脳ではなく、ちゃんとした根拠があります。強化学習の領域だと「探索と利用のトレードオフ」と言われたりしますが、超絶雑には以下のとおりで、2つの勘違いは対称ではない(悲観的な勘違いのほうが深刻)ということです。

  • 楽観的な勘違い:実際に行動するため、結果をみて悪い選択だと気づける
  • 悲観的な勘違い:その選択をしないため、結果が得られず悪い選択だと気づけない

とはいえ、不確かさがなるべくない状態での判断が一番確実で負荷も少ないため、なるべく不確かさを減らす努力もするべきかもしれません。

記憶のために知識を使う

人間の脳の記憶は、よくコンピュータの記憶媒体に例えられるためか、「ファイルを保存」みたいなイメージを持ちがちです。ところが実際はむしろ、筋力トレーニングに近いらしいです。つまり、単一の知識についてインプットとアウトプットを複数回おこなうことにより、記憶が定着していきます。

人間の脳に海馬という部位があります。この中にあるニューロンという神経細胞で起こる、長期増強という現象が、記憶を司っていると言われています。その内容についてはWikipediaとかをみればいいとおもいます。重要なのは、「記憶は繰り返し使うことで増強される」ということです。とにかくアウトプットです。復習のためのテストを自分で作りそれを解くことをオススメされています。AdaBoost的な発想です。

モチベーション的にも記憶的にも、「必要なことを学ぶ」と、必然的にアウトプットするので、学習の効率がよさそうです。遠い将来を追いかけるよりもまず目先の課題と向き合おうと思いました。ごめんなさい。必要に応じて学んだ知識を体系化してまとめておくことも自分には必要だと思いました。本書でいうところの「復習のための教材をつくる」的なことです。本を読んだり、技術的な何かをやったら、咀嚼・言語化してブログに書きます。自分のために。