概要
技術ドキュメントを読む際に、如何に要点を素早く抑えてインプットをするかで仕事の効率は大きく変わる。
ドキュメントの読み方については、巷に読書術の書籍が多数溢れていることから分かる通り、絶対的な正解は無く、人によって最適な読み方は変わる。
ここでは現在の私にとって最適なドキュメントの読み方を整理して記述する。
いきなり全部読もうとしない
ドキュメントを読む上で最も意識していることは、いきなり全部を読もうとしないということだ。
全部読みきることができず、本質的な学習を出来ないまま終えることが多い。
数学など積み上げ型の学問の場合は、今学習している範囲をちゃんと理解していないと次に進めない、あるいは本質的な理解が得られないまま進んでしまうということもあるが、大抵の技術ドキュメントはそこまで積み上げ型の知識は要求されない。
目次と章毎の要点をつかむ
技術ドキュメントを読む過程においては、全体を把握してどこに必要な情報があるかという情報のマップをインプットすることが重要だ。
ここである程度全体を把握していれば、詳しく調べたくなった事柄が出てきたときでも、どこに必要な情報があるかの見当をつけることが出来る。
目次をざっと読んで、その章の最初とまとめを読むことで、章毎の概要と情報のマップを脳に入力する。
公式ドキュメント以外は基本的に読まない
非公式ドキュメントは一度書かれるとそのまま更新されないことが多いため、情報がすぐ陳腐化する。
またその質もまちまちであるため、何よりも情報のマップを構築するのが難しいため、情報を収集するコストが大きい。
公式の技術ドキュメントはチュートリアルやリファレンスが既に整備されていることが多く必要な情報も探しやすい。
多くは簡易な英語で記述されているため、英語に抵抗感さえ抱かなければ日本語と比べてそれほどコストが大きいものでも無い。
理解していないところだけを読む
技術ドキュメントにおいて殆どの情報は、必要なときに適宜参照すれば良い情報であり、読んだとしてもすぐ記憶から消えてしまう。
このような情報のために集中力と時間を使うのはあまり効率的ではない。
ここで意識することは、理解していない点を明確にして、理解していないと自覚したところのみ集中して時間を使うということだ。
自分が理解していない点を明確にする作業は意外と難しいが、自分の場合は、「単元ごとに1キーワードを設定して、そのキーワードをホワイトボードを使って説明できるか」ということを理解しているかどうかの基準にしている。
ホワイトボードでよどみなく説明できるなら理解しているということだし、説明できないなら理解していないということである。
理解していることと理解していないことについて明確に基準を設ける。
理解しにくい点があったらサンプルコードを打ち込む
これの適応範囲は限定的だが、サンプルコードを打ち込むことにより、インプットとそれに対応するアウトプットのパターンを圧倒的に増やすことが出来る。
インプットを自由に設定出来ることで、自分の理解していない点を対照実験から明確化出来るため、理解のスピードは劇的に早くなる。
まとめ
現状の私の技術ドキュメントを読む上で意識していることは以上の通りだ。
前述したとおり、人によって最適な読書法というのは、その人の性格や経験によって左右されるものであるのであるので、私自身にとって今後絶対的なものでないことを留意しておく必要がある。