【先輩に聞いてみた！】新しい技術を効率よく学ぶには？

あらすじ

「新しいフレームワーク、早くキャッチアップしないと…」
次のプロジェクトで未経験の技術を使うことになったユウタ。
真面目に技術書を読み進めてはいるものの、読んだ内容が実務と結びつかず、焦りばかりが募っていた。
思い切って先輩に相談すると、返ってきたのは意外な一言だった。
「ユウタ、勉強の仕方、ちょっと“もったいない”かもな」

先輩
「まず一つ目。
公式ドキュメントのHello WorldとかGetting Startedを、とにかく動かす」

ユウタ
「全部理解しなくても、ですか？」

先輩
「しなくていい。というか、最初は無理」

ユウタ
「えっ」

先輩
「最初から全部分かろうとすると、だいたい挫折する。
だからまずは、コマンドを打って、サンプルを動かして、“あ、こういう感じか”を掴む」

ユウタ
「たしかに……読むだけだと、ずっとフワフワしてました」

先輩
「そう。“動いた経験”があると、あとでドキュメントを読み直したときの理解度が全然違う。
点だった知識が、線でつながり始めるんだ」

ユウタ
「まずは完璧じゃなくていい、ってことですね」

先輩
「その通り。完璧は後回し」

ユウタ
「でも、動かしたあとって、何から手をつければいいですか？」

先輩
「そこで二つ目。
小さなアウトプットを先に決める」

ユウタ
「アウトプット……例えば？」

先輩
「Todoアプリでもいいし、一覧画面を作るだけでもいい。
ポイントは、“全部作ろう”としないこと」

ユウタ
「それ、やりがちです……」

先輩
「ゴールが小さいと、“今必要な知識”だけを調べればよくなる。
すると調べ物が減るし、覚えも早い」

ユウタ
「確かに……今までは、とりあえず全部読もうとしてました」

先輩
「それは“勉強してる感”は出るけど、“使える感”は出にくい。
アウトプット前提だと、“この書き方、今すぐ必要だな”ってなるだろ？」

ユウタ
「なります。
なんか……勉強が目的になってた気がします」

先輩
「実務では、“使えるかどうか”が一番大事だからな」

ユウタ
「アウトプットまで作れたら、だいぶ分かりそうです」

先輩
「最後がこれ。
社内の既存コードを読む」

ユウタ
「えっ、もう見ていいんですか？」

先輩
「むしろ、早めに見た方がいい。
公式サンプルは“教科書”、既存コードは“現場の答え”だ」

ユウタ
「現場の答え……」

先輩
「ディレクトリ構成、エラーハンドリング、命名のクセ。
“この技術、うちではこう使う”が全部詰まってる」

ユウタ
「本に載ってない情報ばっかりですね」

先輩
「そう。
しかも“なぜそうしているか”を考えながら読むと、設計の勉強にもなる」

ユウタ
「読むの、ちょっと怖かったですけど……見方が分かれば大丈夫そうです」

先輩
「最初は分からなくて当たり前。
“全部理解できない”より、“何が分からないか分かる”状態を目指そう」

ユウタ
「……なんだか、気持ちが楽になりました」

先輩
「いいね。その感覚。
新しい技術は、“怖いもの”じゃなくて“慣れるもの”だから」

ユウタ
「よし……まずはGetting Started、動かしてみます！」

先輩
「それでいい。困ったら、また声かけな」