4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【一年目のやらかし】先輩、あの節はすみませんでした

4
Posted at

はじめに

前回の記事では、バッチについて書きました。

その記事を書いている中で、これまでのことを色々振り返っていました。

そこで今回は、少し初心に帰る意味も込めて、一年目の頃にやらかしたことをまとめてみようと思います。

一年目の頃、先輩にはかなり迷惑をかけました。

分からないことがあれば聞けばいいと思っていて、
「分からない → 先輩に聞く」をひたすら繰り返していました。

今振り返ると、もう少し自分で調べたり、考えたりしてから聞けばよかったなと思います。

今回は、そんな一年目の頃のやらかしをまとめます。

① 先輩への依頼で「なるはやでお願いします」と言う

先輩に何かお願いするとき、

「なるはやでお願いします」

と普通に言っていました。

今思うと、先輩に対してかなり失礼な言い方でした。
先輩にも予定があるのに、こちらの都合だけで急かすような言葉を使ってしまい、大変反省しております。

② Slackで送った質問をあとから書き換える

Slackで先輩に相談をしたことがあります。

質問を送ったあと、2時間くらいしてから、

「ここちょっと分かりづらいな」

と思って、質問文を編集しました。

ところが、先輩はすでに元の文章を読んで、それを前提に考えてくれていました。

そこに後から内容を変えてしまったので、話がうまく噛み合わなくなってしまいました。

最初の質問を前提に考えてくれている以上、あとから内容を変えたら混乱するのは当たり前です。今なら、編集ではなく追記するようにしています。

③ AIのJavaScriptコードをPHPファイルにそのまま貼り付ける

これも一年目にやりました。

AIにコードを書いてもらって、

「動きそう!」

と思ったので、そのままコピペしました。

しかも、JavaScriptのコードをPHPファイルに貼っていました。

当然うまくいきません。

先輩に見てもらって、そもそも言語自体が違うことを教えてもらいました。自分では動かない理由すら分かっていませんでした。AIが出したコードだから大丈夫、くらいの雑な信頼をしていたんだと思います。

④ AIに相談した内容を、自分の考えとして設計レビューで話す

設計レビューでもやらかしました。

「なぜこの実装にしたんですか?」

と聞かれたのですが、自分でもよく分かっていませんでした。AIに相談して、その回答をもとに実装していたからです。

当時はAIが出してくれた答えを、それが正解だと疑わずにそのまま使っていました。なので、AIから聞いた理由をそのまま自分なりに言い換えて答えていました。

でも、当然それでは自分が理解していることにはなりません。当時のことを振り返ると、AIに答えを聞くこと自体が悪かったわけではなく、その答えを疑わずに鵜呑みにして、自分の言葉で説明できるところまで消化していなかったのが問題だったなと思います。指摘されて、かなり困りました。

⑤ Gitのブランチを作るのに苦戦し、先輩に長時間付き合ってもらう

Gitのブランチの作り方も分かっていませんでした。

先輩に、

「これってどうすればいいですか?」

と聞いて、教えてもらって、

「じゃあ次はこれですか?」

「これは何ですか?」

と一つずつ聞いていました。

結果、ブランチを作るだけでかなりの時間、先輩に付き合ってもらうことになってしまいました。分からないことをどうやって調べればいいのかすら分かっていなかったので、「分からない → 先輩に聞く」以外の選択肢がそもそも頭になかったんです。

⑥ developをpullするはずがmainをpullしてコンフリクトさせる

あるとき、最新の状態に更新するためにdevelopをpullする必要がありました。

それなのに、なぜかmainをpullしてしまいました。

そしてコンフリクトしました。

「やばい、どうしよう」

となって、めちゃくちゃ焦りました。目の前のことでいっぱいいっぱいになって、予定していたミーティングを休んで対応していたくらいです。

まず何が起きているのか確認して、現在のブランチや変更内容を見て、一つずつ切り分ければよかっただけなんですけどね。「何かやばいことが起きた」と思った瞬間に頭が真っ白になって、それができませんでした。

⑦ SQLが分からず、先輩たちに長時間付き合ってもらう

SQLもかなり苦手でした。

分からないことがあって先輩に聞いたところ、最終的には複数人がかりで長い時間、一緒に見てもらうことになりました。自分一人ではどうにもできず、ずっと教えてもらっていました。

⑧ 開発環境で重いクエリを何回も実行して、環境を見られなくする

SQL関連でもう一つやらかしました。

開発環境でSQLをいろいろ試していたのですが、重いクエリを何回も流していました。

「ちょっと時間かかるな」くらいに思って、そのまま何回も実行していました。

すると、だんだん開発環境が重くなってきて、最終的にはまともに見られない状態になりました。

「やばい、どうしよう」

となって、先輩に相談しました。最終的にはプロセスをkillして対応しました。

当時は「重いなら、もう少し待てばいい」くらいに考えていて、何回も実行すれば負荷が積み重なることに頭が回っていませんでした。今なら、どのくらいのデータを対象にしているのか、時間がどれくらいかかりそうか、まず小さい範囲で試せないか、というのを実行前に考えます。当時は本当に「とりあえず実行してみる」の一択でした。

共通していたのは「分からないから聞く」

こうやって振り返ってみると、いろいろやらかしています。

でも、共通していたことがありました。

それは、

「分からないから聞く」しかしていなかったことです。

もちろん、分からないことを聞くのは大事です。

ただ、当時の自分は、

「どうやって調べたのか」

「最初に何を確認したのか」

「なぜそこを見ようと思ったのか」

「どうやって原因を絞ったのか」

みたいなところを聞いていませんでした。

先輩に答えを教えてもらって、

「なるほど!」

で終わっていました。

でも、本当に知りたかったのは答えだけではなくて、そこにたどり着くまでの過程だったんだと思います。

先輩と一緒に調査を追ってみる

一年目の頃は、先輩が問題を解決しているのを見ても、

「先輩だから分かるんだろうな」

くらいに思っていました。

でも実際には、いきなり答えが分かっているわけではなくて、

「まずここを確認する」

↓

「ここは問題なさそう」

↓

「じゃあ次にここを見る」

↓

「この可能性はなさそう」

みたいに、一つずつ調べていました。

当時の自分は、その過程を見ずに「答え」だけをもらっていました。

もし一年目の自分に戻れるなら、

「これってどうやって調べたんですか?」

「最初に何を確認しましたか?」

「なんでそこを見たんですか?」

と聞いて、先輩の調査を一緒に追ってみたいです。

そうすれば、同じような問題が起きたときに、自分でも調べられるようになっていたと思います。

おわりに

一年目は本当に分からないことだらけでした。

先輩にたくさん助けてもらいましたし、その分かなり迷惑もかけました。

今でも分からないことはありますが、少なくとも、

「分からないから聞く」だけではなく、「まず自分で調べてみる」

ということは意識するようになりました。

そして、先輩に教えてもらうときも、答えだけではなく、

「どうやってその答えにたどり着いたのか」

を聞くようにしています。

先輩方、本当にありがとうございました。そして、すみませんでした。

JISOUのメンバー募集中!

プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか?
興味のある方は、ぜひホームページをのぞいてみてください!
4
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?