知らなきゃヤバイ❗️現役の開発リーダーから教わった現場で戦力外扱いされる理由No.1は何か!
この記事の背景
自分は実務に入る前と入った後であることに悩んでいました。
「あー自分は本当に技術力本当にないなー。エンジニア向いていないのかなー」
と思って悩んでいました。
しかし、実際に開発リーダーやCTOのエンジニアから厳しめに指摘をもらったのは
技術力ではなかったです。実際のところ何でしょうか。
この記事の対象
1.これから開発エンジニアを目指す方
2.未経験エンジニアの方
3.経験が浅いエンジニアの方
結論
開発現場で戦力外扱いされる理由No.1はコミュニケーション不足です。
技術力よりもこっちの方が現場では致命的です。
開発リーダーのフリーランスエンジニア歴4,5年経験したエンジニアがおっしゃていたのですが、
「フリーランスなどの業務委託で1番戦力外通告される理由No.1はコミュニケーション不足で戦力外が多い」
とお話しをされていました。
開発エンジニアのコミュニケーションって何?
よく「コミュ力高いねー」とか言う人ってどう言う人を想像しますか。
ex)
明るい、社交的、自分の意見をちゃんと言える
間違っていないのですが、違います。
上の例はエンジニアが求めているコミュニケーションではないです。
自分なりに言葉にしてみたのですが以下の3点かなと考えました。
-
報連相がちゃんとできているか -
聞かれたことにちゃんと答えられるか -
相手に負担をかけないコミュニケーションが取れているか(相手から適切なアドバイスをもらえる質問力)
4. 相手が求めていることを正しく理解し自分の伝えたいことを正しく伝えるための言語化スキル
5. お客様 上司 同僚が求めていることを汲み取る力
6. 他の人がやっていることを把握しながらやる
当たり前なことを言ってますが、やってみるとなかなかできなかったりします。
自分も大苦戦しましたし、まだ自分でも反省することはあります。
コミュニケーション力がないと技術力は伸びない
堀江貴文さんも以前「プログラミングスキルはコミュニケーション力を上げないと伸びません」
とお話しをされていました。自分が以前参画した現場の開発リーダーの方や現役でエンジニアの採用をやっていた方も
「コミュニケーション力がないとそもそも技術力を上げる機会すらもらえないよ!技術不足は入社後とか他のメンバーでバックアップすればいい場合があるけど、ソフトスキルは自分自身でやってくるもので会社とかで育てることはできない」
とお話しをされていました。これは自分も納得です。
エンジニアの質問の仕方
エンジニアの質問のやり方は他の職種よりも緻密な印象です。
例えばこんな感じです。ざっくりで申し訳ないのですが、ご了承ください!
⚫︎解決したいこと、困っていること
〇〇のエラーが出ています。(プッシュしたURLを貼ったり、出ているエラーを見せる)
〇〇が解決できなくて困っています。
⚫︎調べたこと、試したこと、自分の仮説
〇〇の記事を読んで、〇〇を試してみたのですが解決できませんでした。
自分の仮説だと△△だと考えたのでこういうふうに試したのですが、解決できていないです。
これらを踏まえてご教授お願いします。
みたいな感じです。〇〇で困ってますだけだと「どういうふうに困っているの？」みたいな感じで、
不要なコミュニケーションが発生してしまい、３回で済むやりとりが6回、７回となってしまったりします。
以下の資料も参考にしてください!
なんで質問がうまくできていないのか
質問がうまくできない理由は自分の経験から以下の2つと考えています。
-
質問のやり方がわからない
これは知っていて練習していくうちに慣れて行きます。上の記事を読んでみてください! -
何がわからないのかわからない
自分が今何をしているのかがわからないと質問どころではないです。これまさに自分でした。
これでは質問どころではないです。
解決した方法は自分はこうやってコミュニケーション力が向上したという項目で説明して行きます。
これ現場で言われたら絶対ダメだー！って言われたこと
「進捗どうですか」と聞かれているようではダメです。
つまりコミュニケーションが取れていないため、他のメンバーを不安にさせている時に聞かれます。報連相ができていない、プルリクが上がってこないなどかなり致命的です。
この動画でも以前言及されていました。
コミュ力あるけど技術力が高くないエンジニアとコミュ力ないけど技術力があるエンジニアはどっちが現場にいてほしいか
結論コミュ力あるけど技術力が高くないエンジニアの方がいいって言ってました。
技術力もコミュ力も両方欲しいのが本音だけどコミュ力はソフトスキルなので、
これは会社で何か言う話でもないです。ご自身で磨いてくれ！って感じです。
技術力は周りでバックアップすれば何とかなったりするみたいです。
少数精鋭のハイレベルな案件やスタートアップだとキツいですが…。
実際の例
自分が過去に経験したことをベースで話していこうと思います。
ケース1
自分が開発現場の1ヶ月目の時に
「Figma(こういう画面を作るぞーというお手本を作るようなデザインツール)の修正をしておいて」と言われた時、修正後に修正したことを報告を忘れていました。
その時に厳しめの指摘が入りました。
「技術力以前にこういう報連相ができないとどの現場でも戦力外扱いになるぞ！」
ってリーダーから言われました。
技術力で詰められていないのですが、このような報告不足はかなり厳しめに指摘をされました。
ケース2
こちらも開発現場の1ヶ月目の時です。プルリクエストを出してGitHubでレビューをもらいました。その時に、コメントに対して何もコメントを返さずに次のプルリクエストを出しました。
これもかなり厳し目に指摘をされました。
「これ、もし君がフリーランスとかの業務委託ならこれだけでクビになるよ」って
かなり口調強めに言われました。
コメントってこんな感じです。雑なモザイクですみません💦
レビューにコメントがないとレビュアーはコメント見てくれたのかな?と不安になってしまいます。
ケース3
これは未経験時代で現場に入る前の学習をしていた時の話です。
現役エンジニアにエラーが出たので質問をしました。
その時に「つまり〇〇ですか。」とエンジニアの方が返信が来て
自分は「はい、〇〇です。」で終わってしまいました。
このやりとりを見て現役のCTOのエンジニアの方から指摘が入りました。
「自身が仕事で先輩の立場だとして、こういった返事があったときに「どういうアクションをとってほしいか」が読み取れます？
それだけだとい聞かれたことに答えるだけで指示待ちしてるだけですよ！
次の質問を相手に考えてもらって、してもらわないと動けないような聞き方になっています」
このようにどういう状況なのかを先輩がいちいち確認する手間ができてしまいます。
自分は当時質問を受ける側に配慮が足りていなかったのですね。
ケース4
こちらも自分が未経験の学習時代の話です。
現役エンジニアから指示を理解できていないと指摘されました。当時は頭が真っ白になってしまい指示や相手の意図をうまく汲み取ることができていなかったです。
（一見似ている別のものを同じだと思い込んでしまうことがあった。例えば vendor/bundle フォルダを消してと言われて、.gitignore の記述を探したり、.bundle について調べたりしていた、似ている言葉に引きづられているだけで、指示と全く関係ないことをしてしまっていた。）
ケース5
質問をするタイミングについてです。
わからないことは質問はした方がいいです。ただ 質問するタイミングも考えろ と
開発リーダーからアドバイスもいただきました。
「その先輩に質問するだけでも、先輩の手を止めることになるからそこも考えた上で質問しなよ ！だからいい加減な質問はしないように!」
スクールではないので質問する時も配慮しろ!ってことですね!
ケース6
他のメンバーの実装を見れていなかったのでコンフリクト発生してしまうことがありました。
目の前のことだけではなくプロジェクト全体が見えるようになっていく必要があると思います。
学習を始めた頃の自分を振り返ると
学習は始めた頃の自分はこんな感じでした。
前に言ったことを何度も繰り返してしまったり、自分で調べられることを調べていなかったり、いつの間にか全然違う方向で無駄に時間を使っていて相談が遅くなるようなタイプでした。エラーが出ると意味がわからなくなり頭が真っ白になってしまいました。自分みたいなタイプがもし実務プロジェクトに入ると、先輩や他のメンバーは疲弊してプロジェクトは進まないし、
自分も成長はしないしでいいことがなかったです。
自分はこうやってコミュニケーション力が向上した
そんな中でも自分は以下のことに取り組んで改善を少しずつしていくことができました。
1.フィードバック(メンターや先輩からと自分自身)
スクールなどは現役エンジニアがメンターをやっているとこを選んだ方がいいです。
現場目線でのフィードバックをもらった方がいいです。
質問の仕方も他の職種と比べたら最初はかなり苦戦します。
練習してフィードバックをもらわないとなかなか上達しないです。
質問の仕方以外にも、立ち振る舞いや相手への配慮など
ソフトスキルのフィードバックをもらえると尚良いです。
あとは自分でフィードバックすることも大切です。
相手にうまく伝わらなかった時は必ず「どうして伝わらなかったのだろー」
と自問自答する必要があります。
相手の理解度が低かったとしても「もっとこう言えばよかったなー」と自分でも改善して行きましょう!
自分もこれをやってから少しずつ改善されて行きました。
2.プルリクエストはなるべくこまめに出すこと
プルリクエストはこまめに出すことが大切だと学びました。
これが全くないとタスクが進んでいるのか進んでいないのかがわからないし、
他のメンバーを不安にさせてしまいます。
コードレビューをもらって少しずコードを改善していくものだと教わりました。
3.ドキュメントを書く習慣をつけること
その日で学んだことや実装したこと、指摘されたことや自身の改善点を自分なりの言葉で
ドキュメントに書く習慣があるとかなり成長します。
Qiitaやnoteなどでもいいですし、業務日報をつけるのでいいと思います。
僕が以前学んでいたオンラインスクールのメンターの方も
当初は全然実装などができなかったみたいですが、
Qiitaでドキュメントを書く習慣を身につけてから自分で考えて実装する習慣が身に付いたりと
かなり成長を実感したみたいです。
僕も未経験時代は質問する時もうまく質問がまとまっていなくて、
毎回毎回エラーなどが解決するのが他の人よりも時間がかかってしまっていました。
しかし、Qiitaで発信するようになってから質問がちゃんとまとまって
的確な答えがもらえたりするようになりました。
ドキュメントを書くのは自分なりに要点をまとめたり、言語化する必要があるので、
相手に伝える力はけっこう身に付きます。要は言語化する力です。
ぜひやってみてください!
4.コードを書く時は今何をしているのかを説明しながら書く
今自分が何をしているのか、何をしたいのか、チームから何を期待されているのか、
これがわからないと適切な質問はできないです。
これをやる習慣をつけるにはドキュメントを書く習慣があるとできるようになってきます。
5.タスクをやる時は自問自答しながらやること
実装している時に「なんで動かないんだろ?」「なんで動いた?」「何が原因？」「この記事が書かれたの古いなー。バージョンが古いのかな？それとも今自分がいる環境とこの記事が書かれた人との環境の違いはあるのかな？」
など疑問に持つことが大切です。
これもドキュメントを書いたことで少しずつできるようになって行きました。
6.指摘されたことはメモしてこまめに見直すこと(特にソフトスキル)
いくらフィードバックをもらっても忘れてしまっては意味がないので、
いつでも見返せるようにQiitaの下書きなどでメモをしていました。
7.共同開発、実務問わずチーム開発をすること
実際の現場だと嫌でもソフトスキルは求められますので現場に入って指摘はもらった方がいいです.
ただあまりにもひどいと戦力外扱いになり、開発とは違う仕事になったりして、
現場から外されることになってしまいます。
これはリスクですが、現場で指摘されるのがベストです。
理由はその方が実践しながら改善していけるので、自分で落とし込み安いです。
4,5は現役のCTOの方から教わったことで、それ以外は自分でやりながら自分で考えてやってきました。
今でも自分はソフトスキルに関しては反省することが多いです。
レスを速くする
レスを速くするだけで評価が上がります。レスが遅いだけで、評価下がります。
リーダーやPM、CTOなら忙しくて、返信が遅くなるのは仕方ないです。
自分が経験した現場のリーダーやCTOは基本返信は遅かったです。
ただ特にリーダーとかでないならレスは速くするべきです。
レスが遅いせいで痛い目にあったこと
自分が開発エンジニアになる前のあるSESの現場で、契約解除になったことあります。
理由は返信が遅いからでした。
お客さん側がいつ返信してくれるんだろーって不信感やストレスを感じてしまったんですね。
これがきっかけで開発エンジニアになってから返信を速くしようと決め実行してきました。
技術力はどうすればいいのか
エンジニア歴20年でエンジニア採用もやっている方が言うには
「1日に何時間も業務外に勉強は不要!その代わり業務外に毎日1時間は継続すること」
とアドバイスをいただきました。
勉強内容は基本実務の復習でいいと言われました!
分厚い本を読むだけではスキルアップにつながらないです!
あとは実務に慣れるまでは日報を書くことです。メモでもいいかなと思います。
自分は
1.業務でわからない言葉を調べる
2.業務での反省点、改善点、指摘されたことを書く
3.業務で学んだことを書く
4.業務で自信の良かったことも書く
この辺をまとめて自分で復習していくといいと思います。
自分の場合は上の４つをドキュメントにまとめて自分用に作ったり、
QiitaやZhennで発信したりしています。
未経験必見!こっちもできないとやばい!
結論何かというとGitを使ったチーム開発です。
個人開発だと他のメンバーのことを考えながら開発する経験があまりないですし、コードレビューなどをもらう機会はあまりないはずです。Gitを教えないスクールや教材もあるほどです。
Gitが全くわからないと仕事にならないので身につけておきましょう。
番外編
ソースコードなどの外部流出は問答無用でアウトです。始末書レベルの話になってしまいます。
誰かの記事を引用したり参考にする時は参考資料や引用表記は必ずしましょう！
自分は未経験時代に間違えてやりかけてしまいました。
Discussion