【エンジニア一年目】先輩からもらったフィードバックをまとめた

## はじめに
:::note info
本記事は[リンクアンドモチベーション Advent Calendar 2024](https://qiita.com/advent-calendar/2024/lmi)の20日目を担当しています。🎄
:::

こんにちは！リンクアンドモチベーションの宮田です！

今年も気づけば残りわずかとなりました。**年末は振り返りの時期**。「気持ちよく今年を終えよう」という言葉がよぎるものの、まだあまりできていないのが正直なところでした。

振り返りをしっかり行い、今年の経験を来年につなげるためにも、この記事では先輩から頂いたフィードバック（FB）を整理し、改めて考察してみたいと思います。

この記事を読んでいただいた、同じような経験のある新人のエンジニア、社会人の助けになれば幸いです。

## 目次

- [はじめに](#はじめに)
- [思考プロセスまで質問する](#思考プロセスまで質問する)
- [どうしてほしいのかを明確に](#どうしてほしいのかを明確に)
- [ファーストレビューは早めに](#ファーストレビューは早めに)
- [どこまでわかっているのかを整理しておく](#どこまでわかっているのかを整理しておく)
- [報連相の種類を示す](#報連相の種類を示す)
- [最後に](#最後に)


## **思考プロセスまで質問する**

    
    今後も応用して使えるような学びを得るために、
    なぜそう考えたのかを聞いたほうがいいよ

言われたこと・教わったことに対して受け身になるのではなく、「どうして先輩はこうしようと思ったのだろう？」とその**思考プロセス**を聞くことが大事だというアドバイスです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924509/ed703a6f-4a53-81ce-f9aa-0a0a6ac207fc.png)

特にペアプロをしている時、細かい技術的な部分に目が行きがちではありますが、**次回以降は自分ひとりで再現できそうか？** という観点に立つと、次のような点を知ることの重要性に気づきます。

先輩は
- **どんなインプットを得たのか**
- **どのように処理し、そのアウトプットに至ったのか**

### 質問例
以下のような質問を投げかけることで、先輩の思考プロセスをより深く理解できそう。

:::note info
- **「どうしてその考えに至ったのですか？」**  
- **「なぜその方法を選んだのですか？」**  
- **「どの部分が面倒だと感じたのですか？」**  
:::

こうした問いを通じて、先輩がどのようなインプットを得て、それをどのように処理し、どんなアウトプットに結びつけたのかを理解することができます。

### 結果だけでは学びが浅くなる

ただ結果を眺めるだけでは、先輩の「思考プロセス」を十分に掴むことはできません。特にペアプロをしている時など、先輩が高速にコードを書く場面で、技術力に感心するだけで終わってしまうのではもったいないです。

しかし、そこで一歩踏み込んで、**「なぜそのコードを書いたのか」** を尋ねることで、**より深い学びが得られるはず！** ということです。


:::note info
- **先輩がどんな情報を収集したのか** 
- **どのような選択肢を比較検討したのか**  
- **判断に至るまでの論理や基準**
:::

これらを聞き出すことで、技術的な引き出しが増えるだけでなく、思考の柔軟性や応用力も鍛えられそうです。

## どうしてほしいのかを明確に

    、、で、どうしたらいいんだろう？

振り返りの中で見つけた課題の一つに、「**期待する反応を引き出すためのメッセージ設計の不足**」が挙げられました。  

つまり、**自分がどうしてほしいのか、相手に何を求めているのかを明確に伝えることができていませんでした。**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924509/f36ee618-56c2-48e9-a21a-43ce5a2f8c14.png)


僕が良くやってしまっているのが、

#### 「これで大丈夫でしょうか？」
という質問です。
もちろん、場合にもよるとは思いますが、この質問をされただけだと

:::note warn
**先輩はどうしてそれを聞かれたのかの背景がわかりません**し、このように確認を求めるだけでは、**相手の反応を受動的**なものにしてしまいます。
:::


### 先輩の立場に立って考えてみると

「大丈夫だよ」というのは簡単ですが、**どこまで理解してこれをもってきたんだろう？** と不安になる気もしますし、こうしたアプローチの仕方だと、**先輩に一生確認を求め続けることになりかねません。**

仕事を任せられる後輩になるためには少し頼りなく映ってしまいそうです。


### じゃあどうする？

:::note info
- **「この方向性で進めようと思っていますが、いかがでしょうか？」**  
- **「こう考える根拠は〇〇です。この点で懸念はありますか？」** 
:::

こうした伝え方をすることで、先輩からも建設的な意見や具体的なアドバイスを引き出しやすくなりそうです！


その場合、根拠が間違っていても、一回思考を挟んでいるので、**どこで間違えたのか・認識の差分が生じたかを特定してもらうことが出来ます**

なので、どうやって考えたのかを整理して持っていけると良さそうです。



ただ、そもそもの根拠を見つけられなくって困っているなら、その旨を伝えて助けを求めるというアクションも大事になりそうです。


## ファーストレビューは早めに

    タスクのとっかかりが違うと、勿体無いから今後は気をつけよう！

### **早めのレビューと方向修正の重要性**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924509/413f9fc6-6d84-9a41-a1dc-518fafc51ee2.png)

**タスクの最初の取りかかりが違っていた**という場面もありました。

:::note alert
**「午前中やっていたこと、結局何の意味もなかった、、、、」**
**「今日なんも進んでない」**
:::

このようなケースを防ぐためには以下のようなことを意識した方がよさそうです。

- **早めにレビューを依頼する**  
  仕様やタスクの全体像が不明瞭な場合は、早い段階でレビューを依頼し、方向性を確認する

- **「完璧なアウトプット」を目指しすぎない**  
  完璧な成果物を出すことに固執すると、方向性のズレに気づかないまま進んでしまうリスクあり。まずは早めに初期段階のアウトプットを共有することが重要。



## どこまでわかっているのかを整理しておく

    「わかっていること」と「わかっていないこと」が混ざった報告になっているね

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924509/229c0c46-558f-9d51-3b5e-4273ca9fa2f9.png)



これにより、先輩が何を伝えるべきか、どのようにサポートすればよいか判断できないという状態になりました。

具体的には

    -> 選択肢
    -  「間違ってるよ」
    -  「それは調べたらわかるよ」
    -  「教えてあげるよ」

先輩が**どれを言ってあげるべきか**の判断がすぐにつかないということです。
こうした状況を防ぐためには、

- **どこまでわかっているのか**
- **なにがわかっていないのか**

の現状の整理が欠かせません。

#### 「どこからわからなくなったかわからない」は放棄

これも実際に受けたFBです。
    
    「どこからわからなくなったのかわからなくなりました、、、」
    
    「どこまではわかっていたの？？」
    
    「、、えーと」

ただ「**わからなくなった**」を伝えるだけでは、ただの状況説明に留まり、問題解決につながらない。それは、相手に解釈を委ねる「放棄」になってしまうということです。

大切なのは、自分でどこまで理解しているのかを整理し、明確に伝えることだということがわかりました。

きちんと整理する習慣をつけることが出来れば

:::note info
- **自分の理解を深められる**
- **効率的なフィードバックを受けられる**
- **相手に無駄な手間をかけない**
:::
のようなメリットが得られるはずです。

ただ、色々考えていると**自分の思考の現在地を見失う**こともあることにはあるので、それを防ぐために、個人的には、Slackで自分のやったこと、考えていることのログを取るようにしています。先輩からも見えるようになっているので、どこが違うのかも確認してもらうことが出来ます。

:::note warn
場合によっては、自分が何がわかっていないのかがわからないということもあると思うので、その場合はその旨を伝えた上で壁打ちをお願いするのも必要なはず。
:::

## 報連相の種類を示す

    これの意図は何だろう？


「報連相が大事」と考えるのは正しいものの、その目的を明確にしないまま連絡を取ってしまうことがありました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924509/386aba98-15d3-1d14-4c8e-6ac2263e7bf5.png)


同期で報告するときは、だんだんと意図は何かを伝えることは癖づいてきましたが、非同期の時にとりあえず、現状報告はしておかないと！という考えで、自分のログをほとんど整理しないままSlackで送信してしまったことがあります。

報連相が大事だと考えていましたが、それが相手にとって意味のある情報になっているかどうかは別問題でした。

### この連絡の目的は何か？

:::note info
- **進捗報告**
    - 遅延 / 順調
- **種類**
    - レビュー / 質問 / 相談 / 報告
:::


送り手の意図が曖昧だと、受け手側にどんな対応をすればよいのか考えさせるコストを払わせることになることを学びました。

「**どうしてほしいのかを明確に**」のパートに通ずるところがありますが、連絡を送る前に一呼吸おいて、相手に何を伝えて、これによって相手にはどんな反応を期待するのかが明確にイメージできることが大事だなと思いました。

**究極は相手からの内容に関する確認を必要とせずに一発で意図が伝わること**だと上司に言われたので、それを目指したいと思います。

## 最後に

今年はエンジニアとして多くの技術的なインプットをした１年だったと思います。しかし、振り返ってみると、**ロジカルシンキング**や**ロジカルライティング**のスキルがまだまだ不足していることを痛感しました。

自分の思考を整理し、相手に伝わるメッセージを設計する能力は、エンジニアとしてだけでなく、ビジネスマンとして非常に重要なスキルだと思います。

もちろん、これらのスキルを身につけるには日々の練習が欠かせないと思います。振り返りと実践を繰り返しながら、少しずつでも確実に成長できるよう努力を続けていきたいです。来年の自分が、今年よりも大きく成長していることを目指して頑張ります！