仕事を任せられるエンジニアになるために意識してほしいこと

皆さんこんにちは。エンジニアの西尾です。

今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。

もともとは社内向けに公開したものです。

この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今の食べチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。

意識面

作業の見積もりができる

技術力が低い（コーディングができないなど）よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。

見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要素を洗い出せていない、そして自分たちのスキルを正しく理解していないということです。

作業タスクを細かく洗い出すことができる、TODOを作ることができる

作るべき機能や設計を正しく理解していれば、作業を細かくタスク化できます。 タスクを細分化できないのならば、作るべき機能の理解が足りないということです。

TODOを作って細かくタスク分解をして作業を進められると、あとどのくらいでタスクが終わるのかをおおまかに把握できます。 紙にタスクを書き出すでもなんでもいいので、タスクを細分化できるようになってください。

進捗を正確に報告する

進捗報告は重要です。これは本当に重要です。

あと1日で終わりますと顧客に報告して、できていなかったら印象は最悪です。次の仕事をもらえなくなります。

もうすぐできますといって根性で何とかしようとする（徹夜してでも終わらせようという）のもやめてください。 徹夜して次の日のタスクがまともにできないのは困ります。重要なのは”正確に”進捗を報告することです。

遅れそうならば、遅れる旨を伝えましょう。 できてなくても、こういう理由で遅れそうとちゃんと伝えれば、お客さんもわかってくれます。 まわりもサポートしてくれます。できないのならば”できない”といいましょう。

言われたことだけをしない

「詳細設計書にはこう書いてあったから、変だと思いましたがそのとおりに作りました。」という人がたまにいます。 設計書に書いてあったからと行って、そのままうのみにして作らないでください。 変だと思ったらちゃんと報告してほしいし、そのへんはちゃんと自分の頭で考えてみてください。 言われたことだけをするエンジニアはいらないです。

優秀なエンジニアの方は、こんな機能も必要だと思うからつけておきましたっていう提案しつつすでに実装してた、みたいな方もいます。 報告なしで勝手な機能つけられるのは困りますが、そういう提案してくれる方のほうが、仕事をまかせたいと思えます。

わからなかったら相談する

わからないまま何日も考えて全くタスクが進んでいなかった、という人がたまにいます。 その方に割当てていた作業スケジュールが狂ってしまいまわりに迷惑をかけるので、早めに相談してほしいです。 プロジェクトが忙しくなると、リーダーも全員に意識がまわらなくなるので、その人の作業が進んでないということに気が付かないこともあります。

30分考えてわからなかったら、相談してください。 けど何も考えずによくわかりませんといってとりあえず相談するのも、やめてください。

自分が何ができて、何ができないのかを理解する

誰にでも得意・不得意分野があります。不得意で時間がかかりそうならば教えてほしいし、なんなら別の方にタスクを渡しても大丈夫です。 なんでもできますといわないでください。 スケジュールが狂うし、できていなかったときにまわりが尻拭いをしないといけなくなり迷惑です。

なんでもできるとは言わない

これは先輩の言葉です。

僕が思うプロっていうのは「この壁に窓つけたいんだけど」っていうお客さんに対して「できるけど、西日が差し込んで使い勝手が悪いし、隣の土地には家がすぐに家が建って埋まっちゃうことになるからやめときな」って返すことであって、後先考えずに「ハイではこれがお見積もりです」ということではない

— ハイパーむとう (@masa_edw) May 31, 2012

生産性のマイナスを理解する

エンジニアの生産性は、人によって10倍も100倍も違うといいますし、実際そのとおりだと思います。 そして生産性にマイナスに働く方がいるのも事実です。

設計・プログラムが適当すぎて、次に機能を作る人が全部作り直す、みたいな事になる場合があり、そういう仕事をする人は生産性にマイナスに働いています。 マイナスに働く人は居ない方がましなので、そうならないようにしてください。

成果物をすぐ見せる

優秀な方は作ったものをとりあえずでもすぐに見せてくれます。 逆になかなか成果物をみせてくれない人もいます。 いざ作業完了の期日になって見せてくる人もいます。そしてもう期限が無いのでこのままいこう、みたいな提案をしてくるのは最悪です。

方針が間違っていないかを確認するためにも、とりあえずすぐに成果物をみせてください。 プログラムを書く人ならば、最低でも1日1回はPRを送りましょう。 設計する人なら、雑でもいいので考えたことを文章なりなんなりでみせてください。

作った機能に責任を持つ

機能をとりあえず適当に作って放置し、バグがでても他の方にまかせるといった方がいます。 自分が作った機能は自分が最後まで面倒を見る気でいてください。 自分が作ったものに責任を持てない人には、仕事はまかせられないです。

技術に責任を持つ

新しい技術を採用するとき、なんとなく流行っているから、自分がやってみたいからだけで採用しないでください。 採用するのならば、自分が一番のプロフェッショナルになって、なんなら他の人に啓蒙するくらいの気持ちを持ってください。

触ったことのない技術をいきなりプロダクションで採用するとかもやめてください。 自分が詳しくないのにとりあえず新しい技術を入れて、まわりもよくわからずにシステムが崩壊するというのは、誰にとっても不幸せです。

スピードとクオリティのバランスを考える

フェーズや開発箇所によって開発スピードが求められる場合と、クオリティが求められる場合があります。

お金を扱う機能、契約を扱う機能など、この機能はバグってたら絶対にダメだろうというところは、開発スピードを落としてクオリティを上げることに神経を使ってください。逆に管理画面とか、まあバグってても大丈夫だろうというところはスピード重視で機能開発するなどしてください。

作る機能に興味を持つ

これから作るものに興味・関心をもってください。

ここはどうなってるんだろうとか、こういうパターンだとどうなるんだろう、実際に業務で使うときはどういう使われ方をするんだろうとか、想像して機能を作ってください。興味もなくとりあえず動けばいいや、みたいな考えで機能は作らないでください。

難しいタスクにもトライする

いつも簡単そうなタスクだけをとって、難しいタスクにはチャレンジしない人がいます。 難しいことをやって進捗がでなくなってしまったら印象が悪くなる、とかそういうことを気にしているのかもしれませんが、リーダーの方はちゃんと技術わかっているので、難しいタスクなんで時間かかったんだなとか理解してくれますし評価してくれます。 簡単そうなタスクだけやってとりあえずたくさん仕事してる、みたいなのは、見る人が見ればわかるし評価できないです。

優先順位を理解する

自分がやりたいタスクから着手ではなく、優先順位が高いものから着手しましょう。 最悪できなかったときに、どうでも良い機能作っていて遅れたとならないように。

集中力をあげる

プログラムを設計する、あるいはコードを書くには相当な集中力が必要なことを理解しましょう。 集中力を上げる努力をする、そして作業の割り込みをできるだけ少なくする努力をしましょう。

一日の集中力には限度があることを理解する

エンジニアが一日に集中できる時間には限界があります。

システム開発は神経を使う作業です。 そんなに長時間ずっと作業できないですし、そういうものだとちゃんと理解して作業しましょう。 徹夜して仕事したら、次の日は絶対作業効率が落ちますし、ダラダラ長いあいだ仕事していても意味ないです。

長時間労働＝仕事しているとは考えない

どういうわけか、いまだに長時間労働している人＝できる人だと勘違いしている人がいます。 長い間働いているようにみえても、実際全然成果を上げていない人もいます。 海外だと長時間労働してる人は、時間内に作業ができないやつだと思われて評価低いですし、私もそう思います。

１日の集中力には限度があることを理解しましょう。 ダラダラ仕事してるくらいならば、短い時間でさっと仕事を終わらせて、残った時間で新しい技術でも勉強するとか、そういう時間に使ってください。

体調が悪いときは休む

体調悪いまま仕事しても成果はあがらないです。 集中して作業しないと成果はでないです。 休んでください。

何事も効率化する

同じ作業を何度もするのならば、なにか効率化できないか考えてください。 エンジニアは作業を効率化する人であってほしいです。

タスクを持ちすぎない

タスクを持ちすぎないでください。 なんでも自分で面倒みないと気が済まない、なんでもやりたがる、自分の能力を過信している、あるいは単純に人が足りていないのが原因かもしれません。 タスクを持ちすぎると、すべてのタスクがうまくいかなくなります。 他の人もそのタスクに振り回されることになります。

自分が処理できる限界を超えたタスクをもたないでください。 タスクが増え過ぎたらアラートを上げる、他の人に渡す・まかせる、あるいはやらないときめてやらないなどして対応してください。 やらないという決断ができる人は優秀な方です。

小さなタスクは大きなタスクより時間がかかることを理解する

1時間でおわるタスクが8つと、1日かかるタスクが1つある場合、前者のほうが圧倒的に作業に時間がかかります。 コンテキストスイッチにはコストがかかることを理解しましょう。

成果を0から1、1から9、そして完成にもっていくまでの作業時間は線形ではないことを理解する

何もない状態から機能を作るのと、ある程度作ってからの作業時間はイコールではありません。 そして完成にまで持っていくのはもっと時間がかかることを理解しましょう。 9割完成しているからといって、作業時間はあとちょっとではありません。

会議は人の時間を奪うということを理解する

何の考えも無しにとりあえず会議を要求するのはやめましょう。 会議は他の人の作業時間を奪っているということを理解してください。 どうしても会議が必要ならばアジェンダを決める、ゴールを決める、必要な人だけを呼ぶ、そして会議の時間を短くと決めましょう。 会議を効率化する努力をしましょう。 1時間以上の会議は集中力も続かず効率が落ちるので、無駄です。

Y理論で管理する、あるいはされるエンジニアになる

驚くことに、事細かに作業を指示しないといつまで立っても作業を進められない、してくれないエンジニアは一定層います。 細かく指示を出してくれないと何もできないと主張したエンジニアも過去にはいました。

あの人はいつも怠けている、仕事を命令しないとやってくれない、そう思われるエンジニアにはなってほしくないです。 まわりの優秀な方も、マネージャーがマイクロマネジメントに走るようになると迷惑です。

自主的に行動できるエンジニアになってください。 タスクは与えられるものではなく、みずから作れるようになってください。 X・Y理論でいうY理論である職場であってほしいです。

設計面

ビジネスを理解する

ビジネスあってのシステムだということを理解しましょう。 機能を使う人の身になってシステムを作る努力をしてください。 この機能はどういう使われ方をするのか、今現状はどういうフローで作業しているのか、あるいはどういう機能にしたら使いやすいのか、ビジネスサイドの業務を理解してシステムを作ってください。

業務系システムほど使いにくい傾向がありますが、多くの場合エンジニアが実作業を理解していないことが原因です。 エンジニアにまかせて作った画面は使いにくい、そう言われないようにしてください。

将来の事を考える

その場しのぎの機能を作らないでください。 新しい機能を作るときは、将来どういう拡張がされるのか、どういう機能になっていくと思うかを想像してシステムを作ってください。

いきなりすべてを作る必要はありません。 ただし設計・想像をする努力はしてください。 一部のケースに対応できないためにすべてがひっくり返される、機能を全部作り直す、そういうことは往々にして発生します。 一度動き出したシステムを変えるのは容易ではありません。優秀な方ほど、先を見越してシステムを設計・開発します。 千里眼を身に着けてください。

影響範囲を理解する

新しい機能を足す、あるいは既存の機能を改修するとき、どの機能にどういう影響があるのか、影響範囲を必ず洗い出すようにしましょう。

保守にも手間がかかる事を理解する

新しい機能を何も考えなしに追加しないようにしましょう。 作って動き出した機能の面倒をみるのも、コストがかかるのです。

機能をシンプルに保つ

優れたシステムほど、驚くほど機能がシンプルです。 条件分岐が多いシステムは品質が下がり、開発、保守、テスト工数が指数関数的に増加します。 パターンを増やさない努力をしましょう。

異常系に目を向ける

正常系よりも異常系の設計をする方が難しいです。 そして異常系にどれだけ対処できるのか、設計できるのかがエンジニアの技術レベルの違いに現れます。

バリデーションが正しく書けるようになってください。 自分の思ったとおりのデータを入れて動いた、だけでは不十分です。 この項目は空のままサブミットしたらどうなるんだろうか、不正な入力値を入れたらどういう挙動をすべきだろうか想像できる人になってください。 ユーザーは想像もしないような操作をするものです。

テストの仕方を理解する

ソフトウェアテストの基本を学んでください。 テスト設計ができないと、品質の高いシステム設計はできません。

テストとはとりあえず適当に画面を叩くことではありません。 正しい要因（水準・因子）やシナリオを洗い出し、組み合わせを考え、さまざまなパターンを想定することです。 テストもまともにかけない、できないエンジニアは技術レベルが低いと断言できます。

本質を理解する

お客さんの言っている言葉を鵜呑みにしないでください。

「こういう機能が必要で、こういう画面にしたらいいと思うんだけど」。そういう提案をしてくる顧客はいますが、そのとおりに作る必要があるかは自分の頭で考えてください。 お客さんの言ってることをそのまま作っても、多くの場合良いシステムはできません。 うまくいかなかったとき、責任を顧客になすりつけないでください。自分から改善案を提案してください。

実装面

サーバーサイドでのバリデーション

バリデーションは必ずサーバーサイドでも実施してください。 クライアントサイドバリデーションは、UI・UXのために行うものです。データを扱うのはサーバです。 画面でいくらブロックしても、不正な値が保存されてしまう状態ができてしまうのでは、意味がないです。

何も考えずにコピペしない・わからないものをそのままにしない

ネットにあったコードをコピペして良しとしないでください。 よくわからない機能を放置しないでください。自分で考えてコードを書いてください。

開発時もログを見る

開発時にログを全く見てない人がいます。 見ればエラーだとわかるし、N+1のようなパフォーマンス問題も見つけられます。 そういう基本的な問題を見逃さないでください。

割れ窓を直す努力をする

割れ窓理論、というものがあります。 建物の窓が割れたままの建物を放置すると、その周辺の治安が悪くなるというものです。

システムも同じです。 汚いコード・設計が入ると、その周辺の治安が悪くなり品質が下がります。 窓を割らない努力をしましょう。 そして汚いところを見つけたら直す努力をしてください。

コードレビュー

レビュアーはテスターではない

コードのレビューを出す時、明らかに動かないコードを提出してくるエンジニアがいます。 自分でちゃんと動かしていますか。コードを書き換えて、自分で”テスト”してからレビューに出してください。 コードを書いて、一回も自分で動かさないままレビューを出すのは失礼です。 レビュアーはテストする人ではないのです。最低限のマナーを守りましょう。

強い言葉を使わない

「このコードは駄目だ」、「ひどい設計だ」、人の人格を否定するような言葉は避けましょう。 いくら優秀な人でも、言動に問題あるような人には仕事を任せたくありません。 その人の発言によって、まわりのモチベーションや生産性を大きく下げる可能性があるためです。

よりよいエンジニアになるために意識してほしいこと

新しい機能を自分で作れるようになる

既存の機能は改修できるが、新規の機能設計・開発を任せると全くできない、あるいは品質が著しく低いものを作る方がいます。 自分で新しい機能を生み出せるよう技術的な研鑽を積んでください。 新しいものを作れないのならば、いつまでたっても仕事はまかせられません。

昔から使われている技術を理解する

いまどきRDBは流行らない、Linuxの運用なんてマネージド・サービスに任せれば良い、そういって基本的な技術を理解していないエンジニアがいます。 昔から使われている技術を勉強するモチベーションを持ってください。 今なお使われているのには理由があります。 基本ができていないエンジニアは、応用もできません。

新しい技術を理解する

常に新しい技術をキャッチアップする努力を惜しまないでください。

ソフトウェア業界は技術の流れがとても早いです。 去年流行っていた技術が今年は廃れている、よくあることです。 重要なのは新しい技術を追い、なぜ流行っているのかを理解することです。 毎日仕事が忙しくて新しい技術を追いかけていなかった、のではいつのまにか使えないエンジニアになってしまいます。

巨人の肩の上に立つ

自分が最初に全く新しいアイデアを生み出すことは、ほとんどありません。 必ず前例があるはずです。誰かが作った成果物を真似し、その上に新しいものを作ってください。 巨人の上に乗れば、よりよいものを早く作れます。

関数型言語を勉強する

一度で良いので関数型言語を勉強してください。 優秀なエンジニアは関数型言語の基本を理解しています。 副作用のないコードを書く、命令的ではなく宣言的に処理を書く、正しく処理を分割する。 関数型の基本を学ぶと、プログラムの設計・書き方も大きく変わります。

一つの言語・技術を極める

自分の強みをもってください。 浅く広く勉強するのも大切ですが、何の特技もないのではどういう仕事を任せていいのかわかりません。

複数のプログラミング言語またはフレームワークを勉強する

1年に1つは新しい言語・フレームワークを学ぶ努力をしてください。 優秀なエンジニアは、必ず複数の言語を勉強しています。 他の言語から新しい考えを学ぶことができます。Rubyできれいなコードをかける人は、JavaだろうがPHPだろうが言語が変わってもきれいなコードがかけます。

デバッグ力を上げる

プログラムのデバッグができるようになってください。 バグが発生したら、なぜそのバグが起きたのだろうかとすぐ想像できる力を身に着けてください。 障害対応をするのは、大抵優秀なエンジニアです。

技術力を貯金する

休みの日に仕事ばかりしないでください。 新しい技術をみにつける努力をしてください。 技術力は貯金が必要です。 仕事と関係のない技術でも、必ずいつかプロジェクトの役に立ちます。

人の評価を気にしない、当てにならない

あなたの事を一番分かっているのは、あなた自身です。 人から評価されるように仕事をする、振る舞うよりも、自分が納得できる最高の仕事ができるよう、日々努力してください。

最後に重要なこと

楽しく仕事をする

仕事を楽しんでください。 つまらない仕事、興味のない仕事を続けていても成長はできないし成果も上げられません。 まわりにもその空気は伝わりますし、生産性・モチベーションに大きな影響を与えます。 つまらないと思うのならば、潮時なのかもしれません。

今やっている仕事を楽しむ、興味を持つ、より良くしていきたいと思えるようになってください。

www.wantedly.com

www.wantedly.com