とある日常
コードレビューで一度くらい指摘されたことはないでしょうか？
公式ドキュメントに使い方載っているので、それを参考にして修正してください
公式ドキュメントではそう書いていないはずです
時には、コードに関する質問をしたとき
これ読めばわかるよ。はいっ（公式ドキュメントのURI）
そんな時、どう思いました？
僕）
「読めって言われても...」
「読んでも結局何が言いたいか分からない...」
「英語のドキュメント読むのきついなぁ...」
「ChatGPTに使い方全部聞いたれ」
そう思ったことはないでしょうか？
まずドキュメントは読めるべきなのか
べき論になると、当然読めた方がいいに決まっています。
ただ、新人のうちから読める必要はないと思っています。
必要な情報をピンポイントで早く見つけるには一定の経験が必要なので、最初に読めないことで落ち込むことはない思います。
といっても、読める方がいいのです。
それなりに信頼できる
公式ドキュメントは、作者か作者の意図を理解している人が執筆しているので、ある程度の信頼性があると思っています。また、更新の早いライブラリの最新情報はAIに聞いても、古めな返答が返ってくることがあるので、公式ドキュメントで最新の情報をキャッチアップしたいです。
（ドキュメントによってはメンテされていないこともあるので一概に言えないのが辛いところ）
公式の書き方を学べる
公式ドキュメントには大体「Get Start」の項目とサンプルコードを用意してくれています。ちょっとした実装方法やコードの書き方のお作法を学び取れます。
自分は複数通りの書き方があった時、公式ドキュメントのサンプルを参考にすることが多いです。
網羅的に学べる
ライブラリのドキュメントなら、そのライブラリのオプションの一覧や他ライブラリとのコラボレーション方法なども掲載しています。
こういった網羅的な情報はQiitaなどの記事よりも、優れています。
※余談
Next.js のようなコミュニティの大きなフレームワークでは、ドキュメントが非常に充実しています。自分は技術選定の基準として、「ドキュメントが充実している」ことを考慮に入れています。
ドキュメントを読むのはめちゃくちゃしんどい
とはいえ、ドキュメントを読むのはとても体力を使います。
私もエンジニア4年目に突入しましたが慣れることはありません。（多分一生慣れない）
そして読むのが辛いのは大体以下の時です。
ドキュメント以外に分からないことが多すぎる
とあるライブラリだけが分からないのではなく、３つ４つ分からない概念がある。
よって、「何が分からないか分からない」状態に陥ります。
圧倒的な知識量によって情報オーバーロードになる時はマインドマップなどで整理することをお勧めします。「どこまで理解できて、どこから分からなくなっているのか」を分析するためです。
ドキュメントを読むための準備ができていない
準備と言うのは 「そのドキュメントがなんのために存在しているのか」を理解している状態 です。
ライブラリがあるのも過去に何かしら解決したい問題・ニーズがあったはずです。
こういった背景知識を簡単にでも頭に入れた状態で、公式ドキュメントを読んだり、手を動かした方がその技術の設計思想を理解しやすいはずです。
思想が理解できると「こんなメソッドが用意されてそう」「こんな感じで書けないかな？」と結構あたりが効くようになります（私の体感ですが）
公式ドキュメントを読むための土台を作るために、日本語の記事を読んだり・AIに質問することは大賛成です。ただ、「日本語記事だけ、AIに聞いただけ」はあまり賛成できません。必ず後で公式ドキュメントで裏をとることを推奨します。
公式ドキュメントを読む文化がない
悲しくもチーム・先輩が公式ドキュメントを読まないなら、若手にもその習慣は身に付くことはないです。チームを巻き込んで公式ドキュメントを読むなど、文化を育む努力も必要です。
チームに無能がいなくなる『メンバー全員で公式ドキュメントを読みあわせる』に感銘をうけた話。
という記事を読んでとても共感できました。
そういえば自分も公式ドキュメントの読み方を教わったことはないです。
「頑張って慣れるもの」と思い込んでいました。
こうした情報収集に関するメタ的な技術も教わる機会があってもいいかもと思いました。
「全員がドキュメントを読める訳ではない」というスタンスになると、コミュニケーションの方法が変わってくると思います。
ただ、「若手のみで読書会をする」ことに関して自分はあまり賛成しません。
慣れている人がドキュメントの勘所をピンポイントで教える方が圧倒的に効率的です。
何度もドキュメントを読む
公式ドキュメントを一発で理解するのは無理ゲーだと思っています。
（多分初回で読んでも5%も理解できていない気がする）
なので
- 実際に使うときに読む
- 空き時間で理解を深めるために読む
- 日を改めて読む
など、焦らず理解を深める機会を増やすことが必要です。
世界一流エンジニアの思考法 という本でも
「理解することに時間をかける」への言及があります。
「早く結果を出したい」「早くPRを出したい」と目先の成果ばかり求めて、
技術への理解を中途半端なまま放置してしまうことはありませんか？
（自分はその節がありました）
そういったスタンスが、成果物の質を下げる根本原因の一つのような気がしています。
理解に時間をかけることは情けなくないです。
むしろ偉いことだと思います。
学習初期こそ時間をかけて堅実に分からないことを一つずつ解消していきましょう。
※ 紹介した本の著者のnoteも勉強になるので、参考まで
プログラミングというより物事が出来るようになる思考
補足
弊社では「プログラミング未経験歓迎」のスタンスをとっており、その立場での考えです。
「経験をある程度積んだ社員が大半を占める」という状況では変わってくる話かもしれません。
まとめ
先輩
「ドキュメント読んだらわかる」発言には慎重になった方が良い
後輩
新人の頃に公式ドキュメントが分からないのは当然だから落ち込むことはない
公式ドキュメントは
- 信頼性がある
- 公式の書き方が載っている
- 網羅的な情報が載っている
から読むことに慣れる・理解できるように努力することは必要
一発で理解するのは無理ゲーなので、5％の理解を積み上げる
参考
チームに無能がいなくなる『メンバー全員で公式ドキュメントを読みあわせる』に感銘をうけた話。
プログラミングというより物事が出来るようになる思考