技術力の低いエンジニアが貢献するための思考法
技術力で劣るエンジニアがどう会社に、チームに貢献していくべきか？
というテーマで話していこうと思います。
こんなエンジニアに読んでほしいです
技術力に自信が持てない
経験年数が数ヶ月~3年程度
周りのエンジニアが技術力の高い人ばかり
仕事での貢献感が薄い
わたしは現在創業5年のスタートアップ企業に務める経験4年程度の web エンジニアです。
自分自身開発業務においてできることは増えてしました。
しかし、まだまだ技術力が足りないと感じる場面も多く、周りの優秀なエンジニアの力を借りつつ日々、できない自分と葛藤しながら仕事をしています。
エンジニアになってからこれまで、周りの自分より経験も技術力もあるエンジニアの中で自分自身はどうやって、組織に貢献していこうかと考えてきました。
そのなかで、
技術力に劣るエンジニアが組織に貢献するための考え方を話していきたいます。
勘違いをしてほしくないのは、
"技術力が低くても他の方法で貢献すれば良い"
という主張ではないことです。
エンジニアである以上技術力で貢献する努力はするべきです。
しかし、一朝一夕ではなかなか技術力が高くなるわけではない。
だから、技術力を向上させる努力はしつつも、技術力の低いエンジニアが毎日の仕事で組織に貢献するためにはどうすればよいのかを考えるものです。
■めんどうくさい仕事を積極的に拾う
まず話していくのは
めんどうくさい仕事を積極的に拾うこと
です。
必要とされているにもかかわらず、だれもやりたがらない仕事はどの組織にも存在します。
自分が成長しそうな仕事かどうか、とかそういうことを考えずになにが組織に求められているかを考えて、求められているのであれば自分の意志とは関係なく仕事をやりきれる人は重宝されます。
そして、間違いなく信頼されます。
エンジニアの仕事でよくある、やってくれたら嬉しいめんどうくさい仕事の具体例を紹介します。
◎テストが不足している部分のテストを書く
めんどうくさい仕事の1つ目は
テストが不足している部分のテストを書く
です。
自動テストがしっかり書けていないプロダクトは多いと思います。
特に書けている場所はあるけど、特定の場所はあまり書けていない。なんてことは多くあると思います。
例えば、サーバーサイドは比較的書けているけど、フロントエンドはあまり書けていない。
なんてことはありがちです。
以前、技術力の高いエンジニアが多い企業の複業案件に参画させていただいたことがあります。
そこでやっていたことは、フロントエンドの E2E テストをひたすら書いていく、というものです。
技術的な難易度としては、その企業にいる正社員エンジニアでも十分過ぎるくらいにできる内容です。
しかし、その案件でめちゃくちゃ感謝されました。
テストはやらなければいけないけれどなかなか手を回せていない仕事、いわゆる
非緊急かつ重要タスク
と言えると思います。
そういったタスクをしっかりこなすことは大きな貢献です。
◎差し込み対応を積極的にやる
めんどうくさい仕事の2つ目は
差し込みの対応を積極的にやる
です。
どの組織においても、緊急度の高いPM からの依頼やビジネスサイドからのフィードバックや問い合わせという形で入ることが多いのではないでしょうか？
そんなとき、チームによっては誰が対応のボールを持つべきか、役割が明確になっていない場合も多いのではないでしょうか？
そういった対応が発生したら一番早く反応して対応しましょう。
わたしの会社では社内 Slack チャンネルにプロダクトに関する問い合わせやフィードバックを受け付ける専用のチャンネルがあります。
わたしは、そのチャンネルにメッセージが投稿されたらメッセージの内容やメンションに限らず通知を受ける設定にして一番早く反応するように心がけています。
ときには１人で解決が難しい対応もあるかと思います。
そういったときは、知見経験があるエンジニアに協力を仰げばいいだけです。
このようなフィードバック対応を積極的にやっていると、問い合わせをしたビジネスサイドのメンバーからめちゃくちゃ感謝されます。
単純にエンジニアの実装ミスによるバグで問い合わせを受けているケースも多いです。
しかし、こういったバグ対応にも迅速にかつ丁寧に対応しているとビジネスサイドからものすごく感謝されます。
また、ほかのエンジニアメンバーからしてもこういったボールを拾ってくれることは非常にありがたいことです。
◎インシデント対応の振り返り会を開催する
めんどうくさい仕事の3つ目は
インシデント対応の振り返り会を開催する
です。
いわゆるポストモーテムのこと
インシデント対応が発生し、1次対応を終わらせてなにも振り返らずにそのまま終わってしまうことはないでしょうか？
インシデント対応が発生したあと、対応したメンバーを集めて振り返りを行い学びを共有し、必要であれば2次対応を行うことは重要です。
例えば、プロダクトにおける根幹機能が使えないという事象が発生したとき、その事象をユーザーからの問い合わせで検知したとします。
しかし、
なぜプロダクト側のシステムで検知できなかったのか、今後同様の事象がおきたときにはシステムで検知する仕組みを導入しよう、など2次対応として仕組みの改善を試みることはなかなか振り返りの時間を作らないと難しいのではないでしょうか？
ポストモーテムを行う文化がまだない組織においては、積極的に開催をしてみましょう。
■業務の非効率を改善する
めんどうくさい仕事をこなして信頼されるようになったあとにできる大事なことを話していきます。
それは
業務の非効率を改善すること
です。
これまで、"めんどうくさい仕事を拾う"というテーマを紹介をしてきました。
この"めんどうくさい仕事"を積極的にこなしていると、あるとき気づく瞬間があります。
「あれ、この作業何回もやってるなぁ」
「おれがやる意味ないんじゃね？」
そう思ったときはチャンスです。
システム化できるかもしれません。
例えば、toC サービスにおいて規約違反ユーザを削除する依頼が PM から何回もあったとします。
そして、これまではエンジニアが毎回コードを書いて CLI を実行する作業が発生していた。
しかし、ユーザ削除機能を社内の管理画面に実装し、エンジニアがわざわざ作業しなくても PM 自らすぐにユーザを削除できるようにすることを提案すれば業務の改善につながるかもしれません。
もちろん、システム化しなくても他の方法で効率化できるのであれば、その方法での効率化を提案するべきです。
めんどうくさい仕事を積極的にこなすことは、短期的に貢献することだけでなく、作業効率化の余地に気づくチャンスでもあるのです。
効率化できそうな部分があれば積極的に提案していきましょう。
■さいごに
当たり前ですが、求められていることをしっかりとやってくれる人は信頼されます。
常にどんなことが組織に求められているのかを考えて、仕事で貢献できる人材になっていきましょう。