新しいことを学ぶことを語るときに僕の語ること

こちらはクラスター Advent Calendar 2023（2枚目）の4日目の記事です。昨日は慕狼ゆにさんの「clusterの若手成長」でした。自分は若いことは目の前のことに必死で先のことを考えられていなかったので、しっかり前を見据えられているのはすごいですね。

枠が空いていたので飛び込みました。

クラスター株式会社のソフトウェアエンジニアは自分の得意領域を持ちつつも、別の領域にもチャレンジをする人が多いです。プロダクトに対するとオーナーシップが強い人が多いというカルチャー的な要因もあり、少しでもプロダクトをよりよくするために自然と領域の壁を越える人が多い印象です。

かく言う自分もこの半期は得意なサーバーサイドの領域を離れて Unity のタスクに挑戦していました。もともと Unity 3、4 のころに仕事で触っていたので、素養はあるので完全な初挑戦という訳ではないのですが。

本記事では領域を越えるときにやったことを思い出して書いて見ようと思います。

新しいことに取り組むときの心構え

「どうやるか」(How) よりも「なぜか」(Why) が重要。

なぜそうなっているのかに注力することで、本当にいま覚えるべきことが分かって効率よく習得できると思っています。また、ここで覚えた考え方は別のところでも役にたてることが出来るかもしれないのでお得です。

コードを書くのなんかは覚える気があれば誰でも出来るし、今度AIが発達すれば覚えなくても出来るようになるでしょう。

社内ドキュメントを読む

基礎知識があったので、ハードルになるのは社内事情だと思ったので、最初に社内ドキュメントを読みました。

基礎知識が必要な人は適当な本を一冊流し読みしてから公式ドキュメントを眺めたりするといいのではと思います。最初から公式ドキュメントを読んで理解出来る人に憧れたりしますが、自分は何かとっかかりが欲しいので本を読んだりします。

クラスターにはドキュメント文化が根付いているので、様々なドキュメントが存在します。自分で見つけられない場合も助けてーと言えば誰かが教えてくれるので学ぶ環境として恵まれています。逆に助けを求められたときは自分が持ってる知識を惜しみなく出すことで良い循環になります。

tech-blog.cluster.mu

Unityの領域では VRM Animation (.vrma)をUnity上で簡単に生成できるようにした話｜獏星(ばくすたー) の獏星(ばくすたー)さんが書いてくださった最高のドキュメントがあるので、まずはこれを読むと良いと思います。これが知の高速道路ってやつですね。

コードだけの変更で済むタスクをもらいにいく

これは Unity 特有の話題だと思うのですが、プレハブなんかを触り始めると急に分からないことが増えるので、まずはコードだけで完結するタスクを紹介してもらいました。コードを書くだけだったら、言語が C# に変わったとしてもなんとかなる自信があったので、まずはそこから手を出すことで覚えることの範囲を狭くして混乱しないようにしました。そのタスクを足がかりにしてちょっとずつ周りに手を出すことで「何にも分からない」状態から「ここは分かるけど、ここは分からない」と「分からないことが分かる」状態を保つようにしました。

これは新しいことに挑戦するときには重要だと思っていて、急に何も分からないことに挑戦するとさすがにストレスの方が強くてしんどくなってしまうので、出来るだけ好奇心の方が勝るように調整するようにしています。

質問しまくる

新しいことをやっているときはみんな初心者です。

初心者のときが一番質問がしやすくて、どんなしょうもないことを聞いても相手もまだ心穏やかな状態で答えてくれるバフがかかっていると思っています。せっかくバフがかかっているので、活用しないのは勿体ないのでどんどん質問しましょう。

普段は15分くらいを基準にしていますが、自分が初心者だと思っている間は10分くらい迷っても分からなかったら即聞くようにしています。たかが5分ですが、普段は10分くらいで方向性が見えてきて残り5分で答えを見つけるというサイクルな気がしていて、初心者のうちは最初の10分で方向性が見えないことが多く、残りの5分を無駄にしないためにも早めに聞いています。

クラスターでは #pf_unity_入門みたいな質問専用チャネルがあるのでここで聞くことにしています。他にもコードレビューで突っ込まれたときに

まあどんなときでも、分からないことを質問しないより、質問する方が圧倒的に良いので、常に質問した方が偉いという精神でいきましょう。

〆切がないが広範囲を見る必要があるタスクをとる

「もらいにいく」から「とる」に言葉を変えました。そろそろ勘所が分かってきていると思うので、自分でタスクを取りに行きましょう。タスクの選定をするのでも得るものがあります。

さて、ここで2つのポイントがあります。

〆切がないタスク

これを探すのは大変だとは思うのですが、まともな開発組織だったら、急いでないけどやりたいタスクなんかが転がっているはずなのでそういうのを狙ってください。完成させることが主目的になるので前提である「なぜ」に注力しにくいので、余裕を持てるタスクがおすすめです。

広範囲を見る必要があるタスク

自分が開発してところととか、不具合を直したところって、目的もなくコードを読んだところとか、教えてもらったことよりも覚えていたりしませんか。やはり目的があった方が身に付きやすいのですが、目的にするのはやはり仕事としてやるのが一番手っ取り早いし、タスクをやることを周りにも説明しやすいです。折角、やれるチャンスがあるなら出来るだけ広範囲を触るものを選びましょう。

自分の場合は機能開発のために追加されたフィーチャフラグを消していくタスクを取ることで、その機能で触っているところを満遍なくみていくということをしました。