最近若手エンジニアから「技術書や記事からのインプットが遅い、あるいは浅いことに悩んでいる」と相談を受けました。
(自分のインプットの巧拙はひとまず棚に上げて)自分は技術書を読む際は予習と復習を結構するタイプなので、自分なりに工夫していることについて書き残してみようと考えました。超オレオレ理論ですが、悩んでいる方の参考になれば幸いです
本の予習と復習
自分は技術書を読む前後でこんなことをしています:
- (予習)その本にかける時間を決める
- (予習)本から学びたいことを書き出す
- (予習)胡散臭い人に書かれたと考える
- (復習)仮説を作り、検証する
- (復習)自分の行動の変化を書き出す
- (復習)記事を書くか、人に話す
結構面倒だと思いますが、自分にとっては効果的でした
0. その本にかける時間を決める
自分がこれから説明する予習と復習は、めちゃくちゃ時間がかかります
時間をかけるだけの価値がある書籍か吟味するのが大切です。自分にとって重要な内容とか、時の試練に耐えた名著とか、信頼できる人に推奨された書籍とか、そういうものに限って以降のステップを実行します
1. 本から学びたいことを書き出す
自分は本を読む前に、まず以下の点を書き出すようにしています：
- この本のテーマについて、自分は何を理解している(と思っている)のか？何が理解できていないのか？
- この本から何を学びたいのか？
事前準備の例
この本のテーマについて、自分は何を理解している(と思っている)のか？何が理解できていないのか？
例えばその昔「モノリスからマイクロサービスへ」を読む前に自分が書き出した内容を一部抜粋するとこんな感じです。
理解している(と思っている)
- マイクロサービスとは、独自にデプロイ可能な小さなサービスを組み合わせてユースケースに対応するためのアーキテクチャの一つ
- 関数やメソッドコールではなくネットワークを介した呼び出しを行うため、呼び出しの失敗について、通常のサービス開発より考慮することが増えるはず
- 各サービスは異なる言語で開発できる
この段階で記載する内容は誤っていても構いません。むしろ本を読む前なのだから間違っていて当然ぐらいの気持ちでガンガン書き進めていきます
理解していない
- データベースレベルのトランザクションが使えないため、楽観ロックや結果整合性に頼らざるを得ない？
- サービスの境界をしくじったときは詰むのだろうか？どうリカバリーするのだろう？
- 何が起きた時に「よし、マイクロサービスに移行しよう」と考えるのだろう？
- SOAと似ているが、違いは分かっていない
- サービス単位でチームが自然と分割されると思うが、チームを分割することで増えるコミュニケーションコストより得られるメリットが大きいケースは、そうそう無い気がする
- あるサービスを変更したとき、変更内容を知るべきサービスだけに伝える効果的な手段はあるのだろうか？
この本から何を学びたいのか
ほぼ「理解できていないこと」と対になるのですが、こんな具合にチェックリストとして書き起こしておきます：
- データベースレベルのトランザクションが使えないため、楽観ロックや結果整合性に頼らざるを得ない？
- サービスの境界をしくじったときは詰むのだろうか？どうリカバリーするのだろう？
- 何が起きた時に「よし、マイクロサービスに移行しよう」と考えるのだろう？
- SOAとの違い、どういう時にどちらを選択すべきなのか
- ネットワークを介した通信のリスクをどう軽減するのか
- あるサービスを変更したとき、変更内容を知るべきサービスだけに伝える効果的な手段はあるのだろうか？
- 今は不要だけどいずれ必要になるかもしれない、ぐらいのチームで事前にできることはないか？アプリケーション内でコンテキストに応じてサービスを分けておくとか(独自デプロイは不可だけど、いざという時に移行しやすい)
こんな具合に自分が求めている知識を明文化して眺めながら本を読んでいると「お、これ自分が知りたかったところだ」みたいな瞬間が度々訪れるので中だるみせず読書に集中できる...気がします。求めていることを決めずに「この本の内容を全部覚えるぞ！」と意気込んでいた頃は常に集中していたので疲れて肝心な所を読み飛ばしてしまう傾向があったため、メリハリをつけることに繋がりました
そこまで時間をかけたくない時は手書きのメモで済ませることもあります。むしろ手書きのメモの方が場所を問わず本の隣に置いておけるので向いているかもしれません
なぜ本から学びたいことを事前に書き出すのか
新社会人の頃に「仮説思考」を読んで「闇雲にデータを集めると重要ではないデータを集めるのに際限無く時間をかけてしまうので、仮説を作り、それを裏付ける根拠となるデータを探そう」という考え方に感銘を受けました
これは読書にも応用できる考え方ではなかろうか？と考えたのがキッカケです
闇雲に本を読んでも重要ではない知識を集めるのに際限なく時間をかけてしまうので、仮説を作り、それを裏付けるために本を読む
「なんとなくマイクロサービスについて知りたいな〜」という曖昧な検索条件より「トランザクションの実装方法が知りたい」の方が適合する情報を見つけたときに「あった！」感が強くて記憶に残る...みたいなイメージです
あと単純に読了後に過去の自分の知識と比較して成長を感じられるのでモチベーションアップに繋がりました
専門ではないのでエアプですがカクテルパーティ効果とかカラーバス効果を考えるに、人は 「欲しい！」と意識した情報ほど認識したり記憶できる 気がするので、案外心理学的にも裏付けがあったりしませんかね...？誰か詳しい人がいたら教えてほしい
分からないことが分からない時の対処法
マジで未知のテーマだと自分が何を理解していないのかすら理解していないから一歩も進めない事もあります。そんなときはどれだけ些細でも構わないので自分が知っていることを一つ挙げてそこから疑問を膨らませるのがオススメです。
例えばマイクロサービスについて知識ゼロだったとしても「いろんなサービスが協調して動いてる」ことはググればなんとなく理解できるはず
そこを起点に理解しているところから理解できていない部分を探してみます
- どうやって協調しているのか理解していない
- サービスのうち1つが壊れた時にどう処理すべきか理解していない
- 今までのサービスの作りと何が違うのか理解していない
今度は逆に理解していないことの中から、理解できている部分を探してみます。例えばマイクロサービスがどうやって協調しているのかは理解していないけど...
- 何らかの手段で通信を行うことは理解している
- 通信が失敗する可能性が0ではないことは理解している
また更に逆転して理解していることの中から理解できていない部分を探します
- 何らかの手段で通信を行うことは理解しているが、その手段を理解していない
- 通信が失敗する可能性が0ではないことは理解しているが、そのリカバリー方法を理解していない
こんなふうにループを繰り返していくと少しずつ「分からない事が分からない」状態から脱却していけるのではないでしょうか
蛇足ですが、コードリーディングにもこのアプローチは役立つ気がしています。初めて見るOSSの全容を最初から理解するのは無理だとしても、最終的にファイルを出力することが分かっているのであれば、まずはファイルを出力する1行を探して理解する。ファイルに出力する情報がどこかでまとめられているはずなので、情報をまとめている1行を探して理解する。情報をかき集めるはずなので、情報をかき集めている1行を探して理解する。これを繰り返すうちにコードの全体が理解できてくる、みたいな
2. その本は胡散臭い人に書かれたと考える
カーゴカルトとか確証バイアスにハマるかもしれないので自分の周りで一番胡散臭い人がこの本を書いたと考えながら読むと自然と批判的思考になるのでオススメです。
それか「サラリーマンなんかいますぐやめなさい」と「一番いいのはサラリーマン」みたいに、真逆のことを主張している本をセットで読むのもオススメです。批判的思考の叩きを作者にお任せできるので非常に楽。特にこの2冊に関しては同じ人が書いているのが最高にロックだと思います
3. 仮説を作り、検証する
新しい知識を仕入れたら 「Aが正しいとしたらBも成立するはずだから検証してみよう。逆にこういう事実が見つかったときは仮説を見直す必要がある」 と、仮説を作って検証してみるのがオススメです
「マイクロサービスがそんなに万能の概念なら採用した全てのチームが満足しているはずだ。逆に不満を抱えているチームがいればこの仮説は見直す必要がある」みたいな感じで調べるとGitHubのCTOがマイクロサービスの選択を過去10年で最大の間違いだと言っていることにたどり着いて「なんか銀の弾丸じゃないっぽいな。適用すべき条件をもう少し精査しよう」と仮説を訂正する流れにつながります
- 絶対（言われたことを全て鵜呑みにする）
- 相対（色んな意見があることは分かっているがどれが正しいのかわからない）
- 評価（検証や検討を通して最もらしい意見を選べる）
の順に発展していくのだとか。仮説を作ることで絶対から評価に移行している、と考えたら自分はなんとなく納得しました
時々「本を読むのが大事か、手を動かすのが大事か」みたいな議論を見かけるのですが、どちらも単体では片手落ちだと思うのです。鵜呑みにしてしまうと知識の使い方を誤るし、脳死で手を動かし続けても自分が無意識にできる行動を繰り返すだけだし。
新しい仮説を作り、それを検証するために手を動かした時に深い学びが得られるのではないかと個人的には考えています。時間はかかるけれども能動的な姿勢が濃密な学習には欠かせないのではないでしょうか。この辺については計画的な鍛錬の重要性を説いたTalent is overratedがオススメです
4. 自分の行動の変化を書き出す
コミュニケーションの目的は何か。僕はコミュニケーションの目的は行動変容を起こすことであるという定義が好きです。誰が言ったのか忘れたけど
本を著者と読者のコミュニケーションと考えると、読了後の読者に行動変容が起きていなければコミュニケーションが成立していません。なので自分は読了後に「じゃあ明日から自分の行動をどう変えるか」を書き出すようにしています
例えば「モノリスからマイクロサービスへ」を読み終わった時は一例として以下の行動変容を書き出していました：
- 息の長そうなサービスを次に作るときは、DBのスキーマ(PostgreSQL的な意味で)をドメインサービス単位で分割することを検討する
- 次にテーブル設計する際は、DBのトランザクションに頼り過ぎず結果整合性に任せられる部分がないか検討する
- いざモノリスによる苦痛が増えてきたとき、他の手段(サービスベースとかイベント駆動とかモジュラーモノリスとか)も検討する
なぜ「学んだこと」を書かないのか
なぜ学んだことではなく行動変容を書き出すかといえば、実務的な知識は活用した時に価値が生まれるため、具体的なアクション（知識をどう使うか）とトリガー（知識を使う条件）に整理した方が記憶から取り出しやすいと考えたからです。先ほど書き出した行動変容は句読点で区切られた前半がトリガーで、後半がアクションに該当します
5. 記事を書くか、人に話す
一説によると知識や経験則を抽象化して応用する思考力(特に文字の発明)こそが人間の強みだそうです。一方でそれは弱点でもあり、人は抽象化しすぎるあまり、本当は分かっていないのに分かったつもりになる傾向があります。読書でも頻繁に起きます。自分でも試しに30分前に読んでいた本を一語一句書き出してみたのですが、ほとんどの内容を忘れていて自分に引きました
なので本を読み終えたら内容を書き出すか、より効果的なのは人に話すことだと思います。人に説明するとツッコまれるので、そこで「アゥ...ア...」とカオナシみたいな状態になって初めて自分が分かっていたつもりになっていたことに気づけるのでオススメ
余談
余談ですが1冊を一気読みすると分かったつもりになりやすいため、自分は一気読みは避けて何冊か並行して少しずつ読書しています。学校の時間割も集中力を維持するためにあえて科目をシャッフルして新鮮さを演出していると聞いたことがありますが真偽は定かではありません
あと複数冊を並行読書する利点は書籍をいろんなところに配置して悪い習慣を克服するのに利用できることです
例えば自分はスマホを触る癖があるので引き出しの奥深くにしまい、手前にプロフェッショナルマネージャーをトラップのように置いています。「スマホ触る暇があるならこれ読めよ」と昨日の自分から暗黙のプレッシャーが伝わってきます
Switchの前にはエンジニアリングマネージャーのしごと、スタンディングデスクの上には戦略プロフェッショナル、机の上には失敗の本質を設置しています
イタい意識高い系ギャグみたいな有様ですが、習慣を書き換えるには実行するハードルを下げることが何よりも大切と昔読んだ本で解説されていたので実際試してみたところ色んな悪癖を軽減できたので個人的にはオススメです
結論
- (予習)その本にかける時間を決める
- (予習)本から学びたいことを書き出す
- (予習)胡散臭い人に書かれたと考える
- (復習)仮説を作り、検証する
- (復習)自分の行動の変化を書き出す
- (復習)記事を書くか、人に話す
こんな感じで予習・復習をしながら技術書や技術記事を読むと理解が深まるのではなかろうか!
Discussion