この記事はAkatsuki Advent Calendar 15日目の記事です。
昨日の投稿はyuyuさんのUnityでスライムを作ろう！でした。
はじめに
プログラマが新しい環境にジョインする際、その組織・チームで使用されている新しい知識を覚える必要があります。時間が無限にあれば全ての分野がカンペキになるまで技術のインプットを続ければ良いのですが、業務と並行してインプットをしなければいけないためそこまで時間をかけることもできません。全て先輩社員に聞いてしまいたい気持ちになりますが、こんな質問で時間を奪っていいのかなという気持ちにもなります。
というわけで本記事のテーマは「新しい・知らないことが多いチームにジョインするためのインプットの効率化」です。
このテーマに沿って僕が個人的に大事だなと思った事柄を7つ取り上げたいと思います。
テーマを選択した理由としては、僕自身が今年度にゲーム会社に新卒入社し6月に制作チームに配属されたため、ちょうどこの半年間ほど新しい環境で新しい知識のインプットを大量に行っていたという状態だったことがあります。
また、何も知らない状態からの素早いインプットに関して比較的得意意識を持っており、過去にも短期〜中期間のインターンなどでもそのテクニックが活かせる場面が多くありました。
普段何気なく行っている習慣や考え方を列挙していくので自分との考え方のdiffや参考にできる項目を日々の開発業務に生かしていただければと思います。
なお、ここで取り上げている情報はどこかで聞いたものも含まれますが基本的には僕の独断と偏見で述べているので正確でない部分もあると思います。その点に関しては煮るなり焼くなり好きにしていただければと思います。
インプットを効率化する7つの習慣
1. まずは公式ドキュメントではなく個人が書いた記事をざっと眺めることから始める
特定の言語、フレームワークにはほとんどの場合に公式ドキュメントが存在します。こうした公式ドキュメントは常に最新で正確な情報が載っているので信頼度が最も高いのですが、全てのケースで有用になるわけではありません。
ある程度その技術を理解している状態で正確な定義や挙動を求めて辞書的な感覚で用いる際には最適ですが、初学者が概要をつかむための教材としては適していません。
正確な情報が載っているからまずドキュメントを読むべきという意見もありますが、それは時間が無限に合って隅から隅まで読むことが許される場合の話です。
全くその技術について知らない状態や、概要だけ知りたいときに適しているのは同じ目線に立っていたプログラマによって書かれた個人的なブログなどの解説記事です。
正確性にこそ欠けますが、自分が求めている情報と同じ優先順位で解説が書かれていることが多いので要点のみの理解には最適です。
正確な仕様の把握はその技術を本格的に採用するときに初めて必要になることであり、そこを初めから注意深く拾っていく必要はないはずです。
2. 同じ箇所でも二回目までは迅速に質問する
自力で調べてわからない時には他のベテランメンバーなどに頼ることも多いと思います。また、一回聞いたけどやっぱりよくわかっていないというケースも起こり得ます。このような時、僕の中で人に聞くパターンは大体3つに分かれると考えます。
まず一つ目は「一回目に聞くとき」です。
これはできるだけ速やかに質問しましょう。よく15分同じところで止まってしまったら手を挙げた方がいいと言いますがそれくらいのテンポでいいかと思います。自分のプロジェクトに特有の事情を永遠にググり続けてるみたいな虚無を回避できるので初見でわからないことに関してはできるだけ早く解決しましょう。
二つ目は「一回聞いたがまだ曖昧な項目を聞くとき」です。
これを行う際はおそらく一回目の時とは違い、「この質問を投げかけて答えが得られれば解決するな」というのがイメージできていると思います。
もしすでに質問をしたという自覚がないことが起きる場合は一回目に聞いた時にメモや記事に残す等のアウトプットをしておきましょう。
一回聞いたなという後ろめたさがあるとは思いますが、一回目とは立ち止まるポイントやぶつけることのできる疑問が変わっているはずなのであまり気にせず
三つ目は「すでに二回質問をしているがわからない時」です。
このような場合は自力で解決することをお勧めします。二回質問をした時点で注目するべきキーワードや着眼点がある程度見えていると思うので適切な文献をあたることは難しくないはずです。
また、話を聞いたつもりでも相手の言っていることを正しく受け取れていないことがあるので下の項目にある「つまり〜ですか反復」などを効果的に用いると同じ話を繰り返し聞かなければいけないことが減っていくはずです。
3. ググる前に所属プロジェクト内で検索をかける
入ったばかりのメンバーが踏み抜くバグや疑問点は先人も経験していることが非常に多いです。
その場合、ネットの海から正しい情報のみを引き上げるより自分と全く同じ状況で質問をした先輩のメッセージログをプロジェクト内から探した方が圧倒的にゴールまでの道筋が楽です。
答えまで明記されていなくても誰に聞けばいいかが明確になりますし、何よりそれが一般的な言語やフレームワークに関する部分に起因するものでないと気づくことができます。
先程の項でも述べたとおり、メンバーに早めに聞くことの一番のメリットはこの「プロジェクトならではの暗黙知」に悩む時間を減らすことだ思っており、この判断を早くすることが効率アップにつながると感じました。
また、調べてれば出てくることに対して頑張って頭で考える人が周りに多すぎるようにも思います。優秀な先人が有益な情報を残してくれているので大人しくそれを参照しましょう。独創性が求められるような場合を除きそこで頭を使うのは非効率です。前例がなく一からロジックを考えないといけないようないけないケースでのみしっかりと頭を働かせましょう。
4. よく理解してから動かすのではなく、とりあえず動いたからヨシ！から差分を取る
これはコーディングが含まれるケースにおける話ですが、新しい技術を採用する際にはできることならその仕様を完璧に叩き込んでから実装に移りたくなります。
しかし時間が限られている場合はまず全コピペでいいので期待した動作に近い状態になるようにしましょう。
どうせそのコピペは清書時にはほとんど跡形もなくなるのでまずは何も気にしなくて良いです。
これを行うメリットとして、必ず動作する信頼のあるピボットを設定した上で自由にコードを破壊することができ、動作する/しないの原因と該当箇所の紐付けが容易になります。
初期段階ではエラーと自分の実装項目の対応が取れないため、どの変更が原因でどのエラーが生じたかを特定するサイクルを早めることが重要です。
何が必要/不要なのかをいちいち検索するよりも、結果から逆算してこれがここに関与しているなどの理解を得る方が開発効率としては高いと感じています。
5. 質問をするときの「つまり〜ですか」反復
わからない箇所を他のメンバーに質問するとき、必ず自分の中で噛み砕いた解釈が説明内容と一致しているか確認しましょう。
これは開発の現場に関わらず必要なスキルかもしれません。
相手の説明をキリのいい箇所まで聞いたらそれに対して「つまり〜という解釈でいいですか」とさも理解したかのように反復してみましょう。
この説明が相手の意図したものであれば頷いてくれますし、自分の説明と食い違う部分があれば相手はその場でうまく伝わってないことに気づき修正のコメントをくれるはずです。
これをせず「なるほどー」などのありきたりの返事を重ねていると理解しているんだなと相手も思い込み、結果ほとんど成果が得られていないということにもつながります。
たくさん説明しているのに何故か理解してくれないような人はこの状態になっているのかもしれないですね。
なお、メモをとっているかなどはこの要因には特に関係がないと思います。
メモをいかに丁寧に取っていようと相手の説明を捉え損ねていたら何の意味もないですからね。
むしろメモする脳のリソースを相手の話をしっかり聞く部分に費やした方がいいかもしれないくらいです。
ちなみに僕はメモは最低限キーワードのみにして、話し合いが終わった後で記憶が新しいうちに頭の中で再構成して改善版のようなものを作成するようにしています。
6. 進展が見られる直前のタイミングで休憩を入れる
作業をしていて核心となる情報を見つけた、今まで悩んでいたバグの原因を見つけた、など大きな進展が見られる場面に遭遇します。このような時には流れに身を任せてひたすら突き進みたくなりますが、そのタイミングで一度冷静になって休憩を入れるという方法があります。
この方法のメリットとしては、再開するときのハードルがとても低くなることです。
一時間に一回程度の小休憩はデスクワークを行う上で取り入れるべき習慣ですが、休憩から復帰する際にはリラックスモードから仕事モードに戻るためどうしても躊躇が生じます。
ここで再開後のタスクを大きな進展の得られるもの、やるだけのものに設定しておくことでこの心理的なハードルを下げることができます。
もちろん何もうまくいかずに疲れてしまった際の休憩も大事でこれは自然な認識として持っていると思います。
しかしそのような時だけでなく、好調な時も一旦机から離れて仕切り直すことでのちのパフォーマンスを持続させることができます。
7. メタ発言のようなログを残す
これはリモートワークを行なっている時に特に使える習慣なのですが、Slackなどを介してテキストベースで人に質問をした際、後から検索可能なログが残ることになります。
このログはその場で他の人が見ることのできるという価値ももちろんありますが、皆の記憶が薄れた頃に同じ疑問を抱いた他の人が救われるという大きなメリットがあります。
議論が加熱すると直接話した方が早いとなり部分的にzoom等を用いた口頭での話し合いに移行することがありますが、このようなケースでは重要な議論の部分がログから欠落することになります。
実際に僕も、内容としては完全に一致していて解決しているにも関わらずその核心部分が見当たらない（または他の箇所に分散されてしまっている）会話ログによく遭遇します。
この対策としては、スレッドが終了する際に「この件に関しては結局〜が原因で〜を行えばよかったんですね。ありがとうございました。」などのように誰かに説明するようなメタ視点ログを一言添えてあげることだと考えています。
これを行う副次的なメリットとして相手に論点の再確認を仰ぐことができますし、抜け漏れが生じていれば改めてそこで気づくことができます。
また、些細なことであってもコンフルなどのドキュメントに事の顛末を記すことで後々助かる人がいます。効果は忘れた頃にやってくるので有用性を実感しにくいですが、習慣化するべき内容だと思います。
おわりに
こういう開発時のマインド的な部分で他の人に共有したい気持ちはありつつもなかなかそのような場面に出くわさないので、今回初めて文字として書き起こすことで自分の思考も整理することができました。開発ツールやコーディングルール等と違って人から盗みにくいスキルなので、このようなノウハウの共有が少しでも開発効率のアップとストレスの軽減につながるといいなと感じました。