こんにちは！ 内定者インターンとしてfluctの管理画面リプレースプロジェクトに参加している25卒内定者エンジニアのくま@k-kumakuraです！
去年の12月からfluctコンソールチームで実際に作業してみたところ、エンジニアリング以外にも「こうしておけばよかった！」と学ぶことが予想以上に多かったので、ここにまとめました。
同じように悩む方のヒントになれば幸いです。
特にこれから入社する25卒や来年入社を控える26卒の皆さんにはぜひ読んで欲しいです。 多くの先輩方からのアドバイスが詰まっているので間違い無いと思います！
- レビュワーはエスパーじゃない！前提共有は惜しまない
- 「PRデカすぎ」問題、でも「小さすぎ」にも要注意
- ドメインがわかったら、まずは現場の声をヒアリング！
- Slack連絡の極意：スレッドは控えて、チャンネル通知を意識する
- 遠慮なく質問して、手戻りを減らす
- 思考の整理には「なんでも書き留める」が効く
- 認知バイアスの一種『イケア効果』には要注意！
- おわりに
- 参考文献
それでは行きましょう！！
👇👇👇
レビュワーはエスパーじゃない！前提共有は惜しまない
最初は「先輩たちなら全部わかってるはず」と思い込み、PR（Pull Request）の説明を端折っていました。
でも実際には、自分が担当しているタスク領域をいちばん理解しているのは「自分自身」。
前提や背景までしっかり説明しないと、レビュワーも「何がしたいの？」となりがちです。 タスクのゴールや背景を丁寧に書くことで、レビューのスピードも上がるし、質問も的確になります。
私の失敗を共有します。
「レビューも速度が大事だからPRのDescriptionも結論ベースで書いてサイクル回していこう！先輩方のほうがサービス詳しいと思うからすこし省略して書いてしまっても大丈夫！文章が短い方が、認知負荷も下がるんじゃないかな...?」
これがまずダメでした。
相手リードで、あくまで向こうのほうが一番知ってるんだから、前提から話したほうが負担が大きくなると勝手に想像してしまっていました。 実際はそんなことないはずなのに...
結果として、説明時間が増えてしまい多く時間を消費してしまう形となってしまいました...
初めてのタスクは、相手が何も知らない前提で詳しく説明しましょう！詳細に書けば書くほど自分に足りてなかった知識もわかると思います！
「PRデカすぎ」問題、でも「小さすぎ」にも要注意
大きすぎるPRはレビューに時間がかかるし、認知負荷も高いので要注意。 nekoyaさんのZennの記事「そのPull Requestデカすぎませんか」 (そぷデカ)でも紹介されていますが、変更ファイルで大きくなったPRは怖いんです…。
特に、複数の機能変更を1つのPRにまとめてしまうと、レビュワーにとってはまさに爆弾💣。どこを重点的に確認すればよいのか分からず、結果としてレビューに時間がかかってしまいます。
実際、自分も機能を一気に実装してしまい、レビュアーから
- 「どこを重点的に見ればいいのか分からない」
- 「影響範囲が広すぎてレビューしづらい」
といったフィードバックを受け、結果としてレビューにかなりの時間がかかってしまいました。
また、自分自身も変更点を見直すのに苦労し、「どこを修正したのか」が後から分かりにくくなるデメリットも実感しました。
適切なPRの粒度とは？
だからといって、あまりに細かく分割しすぎるのも問題。 レビュアーが前後のコードを想像できないと、逆に「負のサイクル」を生んでしまいます。 処理や機能のまとまりを意識しつつ、適度な粒度でPRを出すことがベストかなと感じました。
アドバイスから感じた一番いいPR粒度は、
コードやファイルの量で判断するのではなく、アプリケーションごとにまとめること
であると思います。
「1つのPRで完結する範囲を明確にする」ことで、レビュワーにとって分かりやすいだけでなく、結果的にレビューのスピードや開発のスピードも向上しました。
PRの粒度に迷ったら、「この変更は1つの機能として独立しているか？」を基準に考えるのがポイントだと思います！
ドメインがわかったら、まずは現場の声をヒアリング！
あるプロジェクトにて、古くなった画面をリニューアルするタスクを進めていました。
作業が順調に進んだある日、実際に画面を使う方に確認をとったところ「実は誰もその画面使ってなかった！」という衝撃事実が判明。約1ヶ月作業していたタスクを途中で捨てることに...
「どうやって使われているかを早めに確認していれば、もっと効率よく進められたのに…」と思いました。
ドメインや仕様を理解したら、実際の利用者にヒアリングするのが一番の近道。 いらない機能を作らずに済むし、使い方の流れやユーザーの本音がわかると、改善の方向性もハッキリします。
なので、 エンジニアの視点だけでスタートするのではなく、ドメインが理解できたら、まず実装していく画面を使用する方にヒアリングをして現状把握を怠らないこと が大事だと思います！
またここでもう一つ大事なのは、自分が携わるタスクを「そのまま受け入れない」ということです
「アサインされたからこれは早急に遂行しなければならない」とエンジニアの方は実装に力を入れることがよくあります。しかしそれが逆に開発効率を落としていることにもなりえます。
だからこそ、自分で考えて「このタスクは本当に必要なのか？」を判断し共有できる勇気を持って欲しいです！！
それには、ただやらないという選択をとるのではなく、綿密なヒアリングと調査をして得た根拠を持った上で「行わない」選択肢も自分的にはありなのかなと思います。
Slack連絡の極意：スレッドは控えて、チャンネル通知を意識する
作業の確認やヒアリングをSlack上で行なっていく上で、むやみにスレッドを使いすぎると確認先の方やそれ以外で情報を持っている他の方の目に触れにくくなってしまうことも。実際にスレッドで質問した際に相手方に気づいてもらえなかった経験があり、せっかく連絡を早めに行なったのにも関わらず作業がスムーズに進まなくなってしまった経験があります。
しかし、今回はスレッドの禁止を促すわけではありません！スレッドを使わなくなってしまうと、チャンネル内が複雑になってしまうだけでなく、後で情報を終えなくなってしまうデメリットが発生してしまいます。重要なのは「使い分け」だと筆者は考えています。
自分は下記の2つを意識して連絡をするように現在は心がけています！
重要な連絡や、全体で確認すべき詳細はスレッドに書かず、チャンネルで共有
それ以降のやりとりはスレッドで行い、必要に応じてチャンネル通知を活用
また、必要に応じてチャンネルに通知が届く形にしておくと、知っている人が思わぬヒントをくれたり、気軽に情報共有が進んだりします。 「あとで確認しよう」と思ってスレッドが埋もれないように、状況に応じて使い分けるのが大事です。
参考資料として、前田@brtriverさんがまとめたCARTA TECH BLOGである「Slackで要件を書かずに「質問があります。詳細はスレッドに記載」をやめたほうがいい理由」があります！ぜひこちらの記事も参考に、チームに適したスレッドの使い方を検討していただけると嬉しいです。
遠慮なく質問して、手戻りを減らす
「質問すると相手の時間を奪うかな…」と躊躇しがちですが、質問をしない方が結果的に時間ロスが大きくなることも。 進捗をこまめに共有しつつ「ここがわからないです！」と声をあげると、周りの人も安心してサポートしてくれます。
分からないことをそのままにすると、間違った方向に進んでしまい、後から大幅な修正が必要になることも。手戻りが増えれば、自分だけでなくチーム全体の開発スピードにも影響を与えてしまいます。
そこで大切なのは、「適切なタイミングで、適切な形で質問すること」です。
これだけだと当たり前のことだと思います。 なので以下のような工夫をすると、質問がスムーズになると思います！！
- 事前に自分で調べる（公式ドキュメントや過去のPR、Slackの過去ログを確認）
- 「何が分からないのか」を明確にする（「〇〇の仕様について確認したい」など）
- 進捗を共有しながら質問する（「この実装を進めていますが、〇〇の部分で悩んでいます」など）
また、質問のタイミングも重要だと思っています。 例えば自分だと、20分ほど自分で考えても解決策が見つからない場合は、早めに質問するようにしています。
それとは別で、質問をまとめておき先輩の手が空いたタイミングで相談するのも効果的だと思うのでぜひ試してみて欲しいです！
質問をする側だけでなく、質問を受ける側も、自分の知識をアウトプットする機会になるのでWin-Winだと感じました。
なので、「相手もこの質問によって1つ学びになっている」という考えで勇気を出してどんどん質問しましょう！
思考の整理には「なんでも書き留める」が効く
自分は「くま議事録」というメモを独断で始めて、作業内容や学びを日々書き残しています。
そのおかげで、あとから振り返るときも迷子になりにくいし、今回みたいな記事を書くときにもネタがいっぱい。 大層なドキュメントでなくてもいいので、思考の軌跡や方針を言語化しておくと、自然と頭の中も整理されます。
認知バイアスの一種『イケア効果』には要注意！
イケア効果とは、自分で組み立てたものに過剰な愛着を持ってしまう心理のこと。 エンジニアリングでも「自分の実装は完璧」と思い込んでしまうことがあり、客観的なフィードバックを受けづらくなります。
実際、自分も「順調！」と思っていたコードを共有したら、想像以上に指摘があって…ショックもありつつ大きな学びに。
「自分のコードに酔わず、適宜ほかの人の意見を取り入れる姿勢」が大切だと思います！
自分が見た「順調」は、誰かから見たら「間違い」ということもあることに要注意
おわりに
インターンでの学びは、思った以上に「人とのやり取り」や「チーム開発の進め方」に関するものが多かったです。 自分が抱え込むよりも、積極的に共有・相談することで、結果的にスピードもクオリティも上がるなと実感しました。
これからも新人らしく、どんどん試行錯誤して頑張っていこうと思います！ 少しでも参考になれば嬉しいです。
読んでいただき、ありがとうございました！
いつもサポートしてくださる、fluctコンソールチームのチームメンバーの皆さんいつもありがとうございます！今の自分がいるのも、チームメンバーのおかげです🙇
参考文献
イケア効果
nekoyaさん『そのPull Requestデカすぎませんか』, Zenn
前田@brtriverさん『Slackで要件を書かずに「質問があります。詳細はスレッドに記載」をやめたほうがいい理由』, CARTA TECH BLOG
