ビジネス研修で学んだエンジニアの働き方に活かせる19Tips
まえがき
新卒で入社したときに、ビジネス研修を受けたり、本を読んでくるような課題があったりしました。 僕の場合はビジネス職とも同じ研修だったので、そのほとんどが一般的な内容が多く「エンジニアとしては少し違うのではないか」と思うようなものもありました。
しかし、その中でもエンジニアの働き方に応用できそうなものがあり、1年半働いた今当時のメモを見返すと実際に活きているものがあったので、それをピックアップして紹介できればと思います。
根性論的なところはあまり好きではないのですが、考え方を少し変えるだけで大きな得になるものもあったので、そのあたりも合わせてお伝えできればと思います。 次の春から社会人になる学生さんなどの参考になれば嬉しいです。
積極的に手を上げて、打席に立つ
いい意味で「遠慮しない」ということは意識しました。 ちょっとしたリファクタリングや、入れたほうがよいけど緊急度が低いツールの導入など、「誰かやりますか？」のようになったものに対しては「やってみます！」とまず手を上げてアサインをもらいます。
そうすると、そこでやったことが業務でも役に立ったり、仕事の進め方で発見があったりしました。 少しでもやりたい気持ちがあれば（なくても）最初のうちは挑戦したときの学びが大きかったです。
3年間徹底的に働く
これは今でもまだ2年目なので意識しています。 会社の社長からも「将来的に結婚などをすると、コーディングしたりする時間はなくなってしまうから、コード書けるうちに書いておいたほうがよいよ」という応援をもらい、生活の中で仕事の優先度をかなり上げていて、土日も副業などをすることで意識的に実際にアウトプットをする時間を増やしました。
これが今後どう生きていくるのかは、4年目以降でまたふりかえってみたいと思います。
頼まれごとは試されごと
ちょっとした居酒屋の幹事や発表、会議のファシリテーションなど、開発以外のものを頼まれることがあります。 そんなときに「面倒だな」と引き受けるのか、「やってみよう！」と思って取り組むのかでは実際にやるときのクオリティに差が出てきます。
このように「お願いされることに対してのアウトプットがよいと、実際に開発を任せたときのアウトプットも出してくれそう」ということがあるかなと思っています。
101%のプラスアルファ
頼まれたことやチケットの完了条件に対して少しだけできることを上乗せして完了させるという考えです。
例えば新規機能の開発をしたときに、既存のコードの命名がわかりづらければリファクタリングして変更したり、理解しづらいコードが合ったときに次の人のためにコメントやドキュメントを残すなど、少しの積み重ねの結果でプロダクトの価値が向上すると信じています。
チャンスの神様には前髪しかない
「ピッと思ったらパッとやる」という言葉もありますが、例えば業務中に気になった技術をその日のうちに調べたり、出たいLTを見つけたらまずは応募してみるなど、何か気になったことに対してのフットワークは軽くするように気をつけています。
何のためにを意識する
チケットに「なぜ」を書いたり、新しくプロジェクトを始める際に「インセプションデッキ」を作ったりと、自分がやっていることはなぜやるのかを明確にします。
こうすることで、メンバー間の認識が揃ったり、開発をお願いされる案件に対してよりより設計や実装を提案できたりと、エンジニアとしてプロダクトやサービスに適切に貢献できるようになると思っています。
当事者意識を持つ
開発を行っていると、ついPull Requestを作成してマージしてリリースすることを目標にしてしまいますが、特に自社サービスの場合にはそのリリースを届けるユーザーの方々がいます。 「ユーザーに本当に役に立つ機能になっているのか」「価値が提供できているのか」を考えながら開発し、ときにPdMやデザイナーにもその観点で相談するような心構えだと解釈しています。
また、何か設計で悩んで決めきれないときにも「自分はどうしたいか？」を考えて、自分の意見を持った上で他のエンジニアに相談するようなことも意識しています。
重要度・緊急度でのタスク分類
当事者意識の中で、会社全体、あるいは部署やチーム全体としてどのように動いているかがわかれば、次に自分がやるべきタスクの重要度や緊急度を図ることができます。
もしわからない場合にはPdMにも相談しながらタスクに取り組む順番を決めていきます。
凡事徹底
これが一番大事なのではなにかと思っていることです。 一つ一つは地味でも、毎日ふりかえりをつける、時間を守る、などの当たり前のことを地道に継続していくことです。
作業時間のブロッキング
Pull Requestのマージまでの時間を短くするためには、コードレビューを早く返すことが大切になります。 しかし、MTGなどの予定が入ったり、自分の開発が忙しいとついレビューを後回しにしてしまっていました。
そこで今ではコードレビューの時間を毎日固定してMTGなどを入れないようにブロックし、一定のペースでレビューを返すようにしています。
会議後の10分でまとめる
MTGが終わると、れまで着手していた開発に戻りたい気持ちがすごく湧くのですが、それを少し抑えて、MTGで決まったことやそれぞれのタスクのアサインと周知、次回の議事録のテンプレの作成などまでやっておくと次の動きがとてもスムーズになるのでレバレッジが効きます。
また、最近ではSlackベースでのやりとりと口頭でのやりとりが混在することもあるため、口頭でやりとりがあった場合にはその内容をメモとしてスレッドに残しておくようなこともやっています。
ふりかえり
何か失敗や問題が起きた際にはどうすれば再発防止できるかを仕組みで解決します。 なるべく「意識します」「気をつけます」のような定性的なものではなく、再発防止ができているか検知できる測定可能なものだったり個人の責任にならないものにしてTRYしていきます。
また小さなことでも、毎日のふりかえりもしていきます。
/blog/tech/成長機会を活かすためのふりかえり活用方法
他者視点のインプット
エンジニアは専門職なので、エンジニアに閉じたコミュニティのほうが話しやすかったり、居心地が良いです。
しかし、社内で開発を依頼するのは他部署の人だったりもするので、なるべく会社の懇親会などで開発以外の人と話したり、ランチや業界のイベントなどの機会は積極的に参加して、いろいろな職種や人とのコミュニケーションに慣れるようにしておくようにしています。
好かれるようにする
ちょうど入社した際にふろむださんの『人生は、運よりも実力よりも「勘違いさせる力」で決まっている』という本を読みました。
エンジニアは技術力という指標がありますが、技術力だけで生きていくのは難しいのかなと、こちらを読んで思いました。 僕は天才的なエンジニアリングスキルがあるわけではないので、例えば普段から人を喜ばせるようにしたり、感謝を伝えるようにしたり、ちょっと面倒で引き受ける人がいないようなタスク（議事録とか、幹事とか）を積極的に行う「貢献」を意識して社会人生活を過ごそうと思いました。
嘘をつかない
当たり前のようですが、すごく大事なことです。 特に、何か自分のせいで問題を起こしてしまったときなどにはつい言い訳をしたい気持ちになったりします。
しかし、ごまかしたり嘘をつくと正しい問題の特定ができなくなってしまうので、一旦自分の中の罪悪感や羞恥心のような感情を一切除外して事実を包み隠さずチームや上長に報告します。
逆に、他の人がそのようなことを打ち明けたときには闇雲に攻めたりせず、チームとして仕組みで解決できないかを考えることが『心理的安全性』が高まるのでは、と思っています。
伝え方
エンジニアとして「仕事」をする以上はコミュニケーションは避けては通れません。 相手の技術への理解度、何を求めているかを踏まえた上でなるべく完結に伝える必要があります。
- 相手が知りたいことに対しての回答の結論から伝える（「〇〇って可能ですか?」→「**無理だと思います。**なぜなら〜」
- 言葉の中の「意味の含有率」を考えてなるべく簡潔に（「できそうもないと思っています」→「不可能です」）
- ファクトとオピニオンを区別する（「XXであっていますか？」→「〇〇というエラーがでました。そのうえでXXだと思っています。」）
- クローズドクエスチョンで質問する）（「プルリクエストのマージはどうすればいいですか？」→「（スクショを貼って）こちらのボタンを押せばマージできますか？」）
例えばこのようなものがあります。 質問の作り方は以前も書いています。
/blog/tech/新卒エンジニアに伝えたい、3ステップでよい質問をする方法
スキルを盗む
会社に入ったのであれば先輩社員がいるはずです。その人達が長年かけて養ったスキルを見ながら盗んでしまったほうがお得だと思い、すごく仕事の様子を見ていました。 また、わからないことは質問できるのも一緒に働くメリットでもあるので、ランチ等で仲良くなりながら色々教えてもらいました。
教えてもらったことは素直に実践したり、試したりして身につけていきます。 ここであまり自己流にしたりせず、まずはその仕事の型をできるようになるのが大事です。
終わりを決める
チケットやプロジェクトでも、「どうなったら完了か」をしっかりと決めておくことはが大事なのだとは実際に働いてから実感しました。 アサインされたさいには「いつまで」に「どうすればよいか」を確認します。
働き方でも同じことが言えます。スプリントで動く働き方をしているとついスプリント単位で成果を考えてしまいますが、個人では１日単位でやることを決めていました。 フレックス制等がある場合でも、「その日に最低限しなくてはいけないところはどこまでか」を決めておくことで安心して退社できました。
健康管理
リモートワークも広まるとなかなか生活のリズムがつかみにくかったり、残業などがあると食生活が乱れてしまったりします。 無理をした働き方を続けているとどこかで体調（身体・メンタル）を崩してしまうことにつながるので、「食事・運動・睡眠」これだけは何があっても手を抜かないように決めていました。
参考
図書
リンク
技術力以外の観点で参考にしたリンクをおいておくのでよければ参考にしてみてください。
https://studyhacker.net/jiatama-toha-nanika
https://zenn.dev/praha/articles/mentor-traits?redirected=1