フロントエンドチームEMのこん(@k0n_karin)です！
先日、社内のLT大会でこのタイトルで発表したので、せっかくだしブログにもしてみました。きっかけはこの記事の不具合でした。
記事を簡単にまとめると、ある問題に対して、フレームワークの処理を追って不具合の裏側にあった根本の原因を正しく理解する、という内容でした。振り返ってみると、この記事の問題に遭遇してから記事を書くまでに、多くの学びがありました。
- 要素が存在するが画面にないなら
ResizeObserverを使うと解決できる（問題の暫定的な解決策） document.contains()で要素がdocument内のDOMツリーに存在するか確認できる（調べて得られた学び）- Suspenseは隠しコンテナを使ってslotのコンポーネントを描画する（調べて得られた学び）
- SuspenseはTransition
mode="out-in"と組み合わせると挙動が異なる（調べて得られた学び） - mermaidのシーケンス図の書き方（ブログを書いて得た学び）
これは、一つの問題から複数の学びを得ている例だったと思います。もし、とりあえず問題を解消しただけだとしたら、その場しのぎの解決策を学んだだけになってしまいます。エンジニアの業務は労働集約の側面よりも知識集約の側面が大きいため、学びは少しでも多く得たいものです。
では、どうしたら多く学べるでしょうか？
深く理解する
私は普段から、できる範囲で事象を正確に捉え、深く理解することを重視しています。それが長い目で見て自分の血肉になると思っているからです。 知らないことを深く理解しようとすると、その過程で様々な未知の概念や知識に触れます。それらに出会うたびに、一つ一つ丁寧に理解を積み重ねていくことで、多くのことを学べます。
当然、このように正しく深く理解するには時間がかかります。理解に時間をかけるべき主張は、牛尾さんという方のnoteがすごく印象に残っています。
若い時の苦労は買ってでもしろ、みたいな話も部分的にはこれだと思っています（理不尽な苦労をせよ、という話ではない）。理解に投資するのが早ければ早いほど、長い人生に対して長く効いてくれます。
一方でタイパを重視したいのもわかります。やりたいこと、やらないといけないことはたくさんある中で、どこに時間を割くべきかはいつも悩みます。短期的に見たらタイパも大事かもしれませんが、長期的には時間をかけるべきものもあると思っています。実際に「何に時間をかけるべきか」についてはよく考えていきたいですね。
とはいえ、世の中思ってもみなかった場面で役に立つ知識もあるので、できる範囲で理解に時間をかけていくのがいいと思います。
言語化する
記事を書いたり他人に説明したり、何かしらアウトプットしようとすると、その過程で言語化する必要があり、言語化するには深く理解していないと難しいです。私も冒頭の記事を書く過程で気付いたことがとても多く、その都度理解する機会を得られ、言葉にする中で今自分が理解できていることと理解できていないことが明確になりました。アウトプットはやはり大切だと思います。
記事を書かずとも、どこでもいいので文字で書いたり、独り言のように口に出すのもおすすめです。私は一緒に暮らしている猫によく相談しています。
調べる力を養う
深く理解するには、前提となる知識と調べる力が一定必要です。今はAIを使って調べられるようになりましたが、ソースの正確性はチェックしたいですね。OSSであれば、DeepWikiはリポジトリに基づいているし、ブラウザでサクッと調べられるのでよく使います。もっと細かく調べたいときは、ローカルにクローンしてきてコーディングエージェントを頼るのも良いと思います。
実際に動かしたり検証するのも良いですね。StackBlitzやCodeSandboxはブラウザで簡単に検証でき、複製・共有もすぐできるので非常に便利です。仮にOSSの不具合だったとしたらこれをIssueに添付もできます。
ちなみに、私がプライベートで使っているStackBlitzのプロジェクトには、300個くらいプロジェクトがあり、VueやReactなどのミニマムなリポジトリを作っておくと、気になったときや時間があるときにフォークしてすぐに検証できるのでオススメです。
調べる力を養うと、わからないことがわかる場面が増えていきます。調べるのが早い人や得意な人が周りにいたら、是非聞いて参考にしてみましょう！
好奇心を持つ
好奇心を持てと言われて持つのは難しいと思いますが、好奇心を持って取り組めると、ここまで挙げたこともすべて楽しく取り組めると思います。純粋な「なんでだろう？」という好奇心に突き動かされて、ただ気になるから調べたい！という気持ちが最も簡単に理解を促進すると思います。
視点を増やす
理解の深さとは別の切り口でも考えてみましょう。
ロールやポジションが変わると、考える視点や角度が変わります。視点が増えれば当然それぞれの視点で学びがありそうですね。
特にコミュニケーションの場では、相手の立場・ロールに立って考えてみることが大切だと思います。エンジニアならPdMやデザイナー、あるいはビジネスサイドの目線で考えてみる。マネージャーならメンバーやCTO・VPoEの目線で考えてみる。逆も然りですね。その人がどんな考えに基づいて発言してるかわかると、スムーズになるかもしれません。最初は難しいので、直接どんな事を考えているのか聞いたり教えてもらうのもいいですね。
こうやって少しずつ考える視点が増えていき、得られる学びも増えていくと思います。自分もまだまだ足りないところが多いので、引き続きやっていきたいところです。
おわりに
ヤプリでは、1つのことから多く学びたいエンジニアを大募集しています！是非カジュアル面談でお話しましょう！（お互いに学びが得られると思います😉）
