この記事はCocone Advent Calendar 2022の14日目の記事となります
昨日は@shiro_2bさんの「Donkey car + Jetson nano + Jetson inferenceで信号認識をしてみた」でした
はじめに
こちらは新卒の方やこれから社会人になる方向けに書かせていただいた記事になります
まず初めに、このお話にしようと思ったきっかけですが、社会人としてそろそろ9年目が見えてくる頃ともなり、新卒の方など若手の方の指導をさせていただく機会が増えてきました。
そして、お話をしながらしばしば「あー、自分も新卒の時同じこと言われたなー」とか「あの時教えられたこと、まだ使ってるなー」と思うことがあります。
そこでふと「自分が教えてもらって、さらに新卒の方にお話しすることを記事にしたらこれから社会人になる方など、若手の人に役立つかな？」と思いました。
ということで今回の記事は「新卒の方に教え継ぎたいこと」をいくつか思い出して、書くことにしました。
ちなみに、 今回の記事はガッツリ技術っぽいお話はありません！
コミュニケーション編
誰かに相談するときは「今お時間大丈夫ですか？」とまず聞こうね
最初に少し想像していただきたいのですが、あなたが急ぎの作業があって作業に集中しているとして、誰かから話しかけられたとしてどちらの方が良いでしょうか？
パターンA 「ちょっと並行で進んでる別件について相談したいんですが、この部分の実装工数どのくらいかかりそうですかね？」
パターンB 「今お時間大丈夫ですか？ちょっと並行で進んでる別件について相談したいんですが」
おそらくはパターンBの方が、しばらく待って欲しいとお伝えできたり、あるいは最初に一拍置いてくださっているので、思考の切り替えがしやすく、相談にも乗りやすいと言う方が多いんじゃないかなって思います。
つまり、皆さんそれぞれお仕事をしていて、中には今まさにめちゃくちゃ忙しい状態！って方もいらっしゃるので、「今お時間大丈夫ですか？」とまず聞いて、相談相手の方の状況をしっかり考えて相談しようね、というお話です。
私としてはこの中でも 「相手の方の状況を考える」 という部分がとても大事だと思っています。
会社では、多くの方と関わりながら仕事を進めていくためコミュニケーションは欠かせません。
そのコミュニケーションを、相手のことを考え、思いやりを持ちながら行うことで、お互いに安心して、遠慮や気兼ねなく意見を交わせるようになると思います。
エンジニアは特に、なぜか怖がられていることが多い印象なので、私自身も話しかけやすい優しいエンジニアと思っていただけるように、日々意識しています。
相談するときは何についてのお話かを伝えようね
再び想像してみてください。
あなたが作業中に誰かから相談を持ちかけられたとして、どちらの方がわかりやすいでしょうか？
パターンA 「僕の施策の実装で、追加で集計期間表示する必要があるんですが、(コードを指差しつつ)ここどうするのが最適ですかね？」
パターンB 「年末に開催される新規イベント実装の内容で、イベント開催期間は表示できていたんですが、終了後に追加でポイント集計期間も表示する必要が出ちゃって。開催期間と集計期間で表示部品を分けるか、分けないかどちらの方が今後の改修も考えると適切ですかね？」
パターンBの方がどんな問題が起こって、どんなことに悩んでいるか明白に感じられるのではないでしょうか？
パターンAだと、相談しにきた人が何の施策を実装しているかをあなたが知らない可能性もあります。
つまりこれは、あなたが誰かに相談するとき、相談相手の方は別の仕事をしているはずなので、いきなり相談内容だけを投げかけられても「なんのお話？」となってしまうので、しっかり最初に何についてかをお話しましょうという事になります。
先ほどは１対１でお話する例を挙げたため、「それはいつも意識しているよ」という方も多いかなと思います。
ですが、私個人としては1対1でお話するときは伝えやすいのに、大勢で話す場合や特にミーティングなどの場を持つと途端に伝わりづらくなる気がします。
そこで私は、大勢で話す場合には1対1で話すとき以上に、冒頭で「どんな目的で集まってもらったのか」や「何を決めたいのか」を意識して、明確に伝えるようにしています。
本質的には「相談する方と、しっかり何について話すのか、何を解決したいのかをしっかり認識合わせしましょう」というシンプルな内容に尽きると思うのですが、意外と難しいこともあるので、しっかり意識していきたいですね。
エンジニアならでは（だと思う）編
工数見積はバッファを取ろうね
こちらは初めて作業するにあたって、先輩のエンジニアの方から教えていただきました。
私の場合は、初めて教えてもらった時からあまり変わらず、 単純な見積時間*1.5くらいを工数として見積もっています。
なぜバッファを取るのかですが、既存の似た部品を使えるかと思ったら使いまわせなかったなど見積時にはわからなかった技術的に実装や改修が大変な箇所など、予期せぬ問題が発生することがあるからです。
また、実はエンジニアの毎日のお仕事ってコードを書いているだけではなく、相談やミーティングなどが差し込みで入ることも多いため、思うように作業時間が確保できない日もままあります。
だから、ギリギリの工数見積だと実装時間が足りず間に合わない可能性が高くなるためバッファをとる必要があったんですね。
「なんだか余分に時間を取るのが気が引ける・・・」という方もいらっしゃるかもしれません。
ですが、実装が間に合わずにスケジュールの調整など他の方に迷惑をかけてしまうより、しっかり余裕を持って確実に間に合わせる方が良いため、バッファを取ることは悪いことではないと考えています。
やることよりもやらないことを決めようね
これは開発中プロダクトで開発完了予定は決まっているけど、プランナーさんのやりたいことや気になることが溢れて、要望や要件の追加が止まらなかったとき、ヘルプで来てくださったエンジニアの方が教えてくれたことにまります。
まず最初に、これは「そんなのやだ！時間ないからやりたくない！」という事ではありません。
お客様に届けたい様々な価値がある中で、「最初のリリース時ではお客様が本当に求めてくださるか分からない機能は様子を見て、しっかり検討してからでもいいよね」だとか「この機能があると開発陣、運営陣は助かるけど、今はお客様に届ける価値を優先して作りたいから、一旦優先度を下げようね」といった、要望・要件の細分化と優先順位を決めるのが大事だよという事になります。
「要望・要件の細分化と優先順位を決めるのが大事って言うけど、エンジニアが優先順位決めちゃっていいの？」と思う方もいらっしゃるかも知れません。
確かに、お客様に届ける価値や、やりたいことの順位はプロジェクトマネージャーの方だったり、プランナーの方の思惑があってこそなので、尊重すべきだと思います。
しかし、エンジニアの作業の工数感や、要望・要件をそのままに作業しなくても工夫次第では工数を抑えられ、よりお客様に価値を届ける時間を捻出できることも多々あります。
エンジニアとしての観点で、どうすればよりよい価値をお客様に届けられるかを考え、提案していくことも大事かなと思います。
さいごに
今回いくつかピックアップして「新卒の方に教え継ぎたいこと」を書かせていただきましたが、いかがだったでしょうか？
ちなみに僕自身としては、先輩方に色々教えていただいたことはあるのですが、それらの本質として 「仕事仲間に思いやりを持つこと」「自分が関わっている意識を持つこと」 が大事かなと思い、それらを日々意識して仕事をしています。
これから色んなことを教わり経験することと思いますが、時に自分なりに噛み砕いて大事なことの本質を考えてみるのも良いかもしれません。
新卒の方や、これから社会人になる方に読んでいただき、何か少しでも参考になれば嬉しいです。