はじめに
ヤプリでサーバーサイドエンジニアとして内定者インターンをしている籔本です！ 師走になり、いよいよ「インターン生」という肩書きが通用する期間が残り短くなり、気を引き締めなければ思い始めています。 以前に私が書いた、こちらのブログもぜひご覧ください！ tech.yappli.io
さて、私はヤプリのインターンに参加するまでに少人数開発しか経験していなかったこともあり、大規模開発をする上で大切なことがいろいろ欠けていることに気づきました。 そこで本記事では、インターン期間を通じて気づいた「エンジニアとして身につけるべき習慣」を書いていきます。 既にエンジニアとして活躍さている方にとっては当たり前かもしれませんが、優しい目で見ていただければと思います。
開発でつまづいた時
エンジニアは誰しも、開発においてインターネット検索だけでは解決できないことが度々遭遇すると思います。 ヤプリのエンジニアは全員優しいので質問したら答えてくれるのですが、解決策を回答してもらった時に「それなら質問しなくても自分で解決できたな...」と反省することがよくあります。 そのため、わからないなりに解決に向けて自分でできることは努力したいと考えています。
そこで、本章では私が気づいた他の人に聞く前にできること・やるべきことを書いていきます。
Slackを見る
Slackはその会社の脳と呼べるくらい、これまで開発に関わってきた方々によるノウハウが大量に詰まっています。 社員さんに相談したときに、解決策としてSlackのリンクを貼られるたびに「自分で解決できたな...」と申し訳ない気持ちでいっぱいになります。
わからないことがある場合は、まずSlackの過去ログを調べましょう。 自分が悩んでいるということは、同じように悩んでいる方がいる可能性があります。 某知恵袋と同じようにSlackを使えるようになりましょう。
ドキュメントを見る
もちろん、Slackに載っていない情報もあります。 機能・APIの仕様や設定すべき環境変数など、社内で定義されている情報はSlackに載せずにドキュメント化されていることが多いです。 Slackが知恵袋的な役割を持つ一方で、ドキュメントは辞書のような機能を持ちます。 仕様などの会社・プロダクト内で定義されそうな情報は、人に聞く前にドキュメント内を調べるようにしましょう。
人に聞く
これまで書いたことを実行しても解決できなければ、最終手段として社員さんに聞くことにします。 ただし、質問するだけではなく聞き方がとても重要です。
本章では質問するときに注意すべきポイントを書いていきます。
DMを極力使用しない
インターン生ということもあり、私には社員の方がメンターとしてついてくれています。 DMを通じてメンターの方と出勤予定日などのコミュニケーションを取るので、その流れで技術的な質問をDMにしてしまいます。
しかし、こちらの記事を拝見し、プライベートな会話以外をDMですべきで無いと意識するようになりました。 qiita.com ここでは公開チャンネルで質問した場合の「DMの相手以外にも質問・回答が共有される」「DMの相手以外も回答できる」ことによるメリットが解説されています。 DMで質問すると、特に相手が忙しい場合やDMを見逃した場合など、解決策を得るために長い時間待たなければならない可能性があります。 それに対して公開チャンネルで質問した場合、DMの相手以外も回答できるため、より早く回答が得られたり、議論が生まれてより良い回答が得られたりする可能性があります。
最初は公開チャンネルで質問するのはハードルが高く感じてDMの方が気が楽ですが、勇気を出して公開チャンネルで質問するようにしましょう。 後述しますが、公開チャンネルで質問することによって、質問と回答を社内のノウハウに蓄積することにも貢献します。
質問の仕方に気を付ける
開発でつまづいた時に「〇〇がわからないです、どうすれば良いですか？」ではなく「〇〇が上手くいきません。これを試したのですが、ダメでした。どうすれば良いでしょうか？」のように、今の状況の説明・自分が試した行動・自分の考察などをセットで質問するようにしましょう。
前者に比べて後者の方が、「質問者がどこでつまづいているのか、どこまで理解しているのか」を回答者が把握するコストが低くなり、回答のスタート地点やレベルを確認するための無駄な説明やコミュニケーションを省くことができます。 また、こちらの記事に記載されているように、自分がどれくらい理解しているのかを言語化することで自分の実力を把握することにも繋がります。 qiita.com
「詳細はスレッドに記載」を控える
これは、先日ヤプリのとあるエンジニアの方が共有した記事を拝見したのをきっかけに意識するようになりました。 techblog.cartaholdings.co.jp
私はチャンネルのページ全体を埋めてしまわないために積極的にこのような投稿をしていました。 しかし、「詳細はスレッドに記載」と投稿すると、メンションされた人以外のは詳細が書かれたスレッドを読まずに流してしまう可能性が高いです。 そのため、メンションされた方以外で答えられた人がいたとしても気付かれなくなってしまい、前述の公開チャンネルで質問するメリットが薄れてしまいます。
エラーログやプログラム等はスレッドに記載する方が良い場合もありますが、質問の概要はスレッドではなくメッセージに記載するようにしましょう。 これにより、質問を要約する力や言語化する力も身に付くと思います。
開発で気を付けること
本章は今までと毛色が違う内容ですが、普段開発を進める上で気をつけるべきだと思ったことを書いていきます。
15分ルール
私は個人開発ではひたすら自分で悩んで調べることが多いので、業務でつまづいた時もどうにか自分の力で解決したいと思ってしまいます。 しかし、業務として開発している以上無限に時間を費やしていいわけではいので、他の人に相談するタイミングが悩ましいです。
ヤプリの社員の方々からよく「15分聞いてわからなかったら質問した方がいいよ」と言っていただきますが、「たった15分考えただけで質問するの？」と思ってしまいます。 しかし、こちらの記事に書かれているように、15分以上悩むと自分の時間を無駄にしてしまう可能性が高いです。 tkybpp.hatenablog.com
以前、ヤプリの開発業務でつまづいた時に、3時間ほど悩んでいた箇所をSlackで相談したら数分で解決したことがありました...。 それ以降、私は15分で解決できなければ自分の実力・知識不足と腹を括って質問することにしています。
To Doメモを残す
大規模開発では、少人数開発とは異なり待ち時間が頻繁に生まれます。 私がインターンで経験した中では「技術質問に対する回答待ち」「QA（品質保証）待ち」「仕様決定待ち」がよくあるケースです。 その際、待ち時間に別のタスクを同時並行で進めることになります。 しかし、想定以上に待ちが長かった場合、そのタスクの開発の進捗・これから開発すべき箇所を忘れてしまうことがあります。
それを防ぐために、タスクに待ちが発生する度にTo Doメモを残すようにしましょう。 開発進捗を思い出す手戻りが不要になることで、より効率的に作業できるようになると思います。 メモを残すのは少し手間ですが、手戻りの手間に比べたら安いものです。
アウトプットを残す
これまで「Slackを見る」「ドキュメントを見る」など、先人の知恵にあやかることを中心に書きました。 しかし、先人の知恵で解決する場合だけでなく、自分が初めてその事象に出会うパターンももちろんあります。 そこで、他の誰かが困った時や、そもそも困らないようにするためにSlack・ドキュメント・ブログなどにアウトプットをすることがとても重要です。 自分が先人にあやかる分だけ自分があやかられることもあるので、意識的にアウトプットを実施するようにしましょう。
仕様や実装に疑問を持つ
これは新米エンジニアに限らないかもしれませんが、プロダクトにすでに実装されているアルゴリズムに対して疑問を持つことがあると思います。 私は自分のエンジニア経験が少なく、まだ自信がないので「先輩エンジニア方が仕様を決定・実装したから自分よりも正しいだろうな。」と勝手に納得し、流してしまうことがあります。
しかし、それでは自分の成長に繋がらない上に、プロダクトが成長しないケースもあると思いました。 実装した当時と状況が変わって、当時のプログラムが今に適していない場合があります（レガシーコード、技術的負債など）。 そのような箇所は、今の状況に合わせて修正する必要があるため、声を上げることが大切だと思います。 色々な事情で修正できない場合もありますが、自分がその事情を把握するためにも、まずは声を上げましょう。
自分が声を上げたことによってプロダクトの品質が向上すれば、自分に自信と実力が身に付くと思います。 もし自分が抱いている疑問が間違っていたとしても、何が間違っているかを取り入れて自分の糧になり、成長する機会になります。
おわりに
今回は、私がヤプリでのインターンを通じて気づいた、エンジニアとして身につけるべき習慣をまとめました。 主にこれからエンジニアとして開発に携わる方もそうですが、既にエンジニアとして活躍されている方にも役に立てたら幸いです。
