CTO、PM、全エンジニア必読‼️最強の開発チームの構築方法(ブリリアンド・ジャークはやばい😱モダンな技術を使えたら成果は出るのか🤔)
技術力、モダンな技術の経験、年数主義が蔓延しているけど。。。。。
よくSNS、エージェント、現役エンジニア、などでこんなことを言われています。
- エンジニアはとにかく技術力を極めるんだ
- モダンな経験を積んだりフルスタックになれば収入は上がる
- 経験年数が大事だ
実際にどうなんでしょうか。🤔
モダンな技術を使う、技術力が高いエンジニアを雇えば企業の利益は上がるのか？
よくモダンな技術ができれば、収入が上がる、リモートワークができる、優良企業に就職できる
みたいな話はよく聞きますよね。だけどこれだけで本当に企業は事業を伸ばすことはできるのでしょうか🤔
なぜ経験年数主義になるのか
結論SIerが多いからです。基本技術力、年数勝負になってしまいます。💦
そして資金力がない企業ほど年数が多いエンジニアをほしがります。
せっかく技術頑張ってもリターンが少なかったらモチベーション下がりますよね😅
企業から喜ばれるエンジニアになるためのチャンネル
このチャンネルの動画を見てみてください。
ブリリアントジャークはマジでやばい(協調性がない人は優良企業から相手にされない)
実力、経験年数主義がIT業界に蔓延していますが、以下の特徴がある人は優良企業ほど相手になれないです。実力があること前提です。結論協調性がない人です。
例えば以下の感じです。
- 人当たりがきつい人
- いるだけで雰囲気が悪くなる人
- マウントを取ったり自分より実力がない人を見下す
どれだけ実力があってもこういう人がいるだけでチームのパフォーマンスは落ちてしまいます。
エンジニアはチームで協力してプロダクトを作るので、
個人のパフォーマスだけでは成果は出せないです。
サッカーや野球、バスケでいくらスーパースターがいても勝てないのと同じです。
大谷選手が昔エンゼルスに在籍していた時も、大谷選手ともう1人凄い選手がずば抜けて強くて
他の選手の援護などがなくて勝てなかったりしました。スラムダンクの赤木も最初はワンマンチームで
全然勝てなかったです。これはエンジニアでも同じです。
Netflixは、ブリリアント・ジャークは絶対採用しないみたいです。
Netflixは「ブリリアント・ジャーク」問題にどう対応しているか？
No Brilliant Jerks - Netflixの「頭はいいけど嫌な奴、お断り」について調べた
こんなエンジニアは採用されない。気づかないうちにあなたもそうなってるかも？熟練のベテランエンジニアでも企業から見向きもされない特徴。
ベテランや技術力高めの人ほどマウント取りがち
ベテランの方や技術力が高い人ほど駆け出しや経験浅いエンジニアにマウントを取りがちです。
「自分はこれだけできるんだ」って伝えたいんでしょうが、こういうのがエンジニアが育たない
風潮を作っています。
自分だって初心者や駆け出しの時があったのに、その時のことを忘れてしまったのか、
天才だったのかわからないですが。。。
ブリリアント・ジャークがいる企業の特徴
こういう企業では遭遇する可能性が高いです。ビジネスの世界で命がけで戦っている人も
いるのであまりこういう表現はしたくないですが、あえて使ってみます。
- 資金力がない企業
- 技術力勝負の企業(プロダクトがない企業)
- SIer(全部のSIerがダメなわけではないです。)
エンジニアとしての価値
エンジニアとしての価値は企業への利益貢献です。
そのためにどうプロダクトを伸ばすかなど動いたり考えたりできる人がいいです。
ただ作って納品しましただと正直いいプロダクトはできないです。
こういうやり方そのものが社会課題かなと。。。
本当の価値はこうだと学びました。エンジニアとして生き残る上で大事なことです。
人間性 >>>>>>>>>>>>>>>>>>>>>>>>>技術力、経験年数
ブリリアンドジャークにならないために
自分もブリリアンドジャークにならないように気をつけます。
- 人を見下さない
- 相手ファースト
- 文面で強めの口調にならないようにする(絵文字を使うなど)
- 感謝を伝えるのを癖にする
主体的に動けるチームが強い
モダンな技術を使っていなくてもサービスが売れたらOKです。
モダンな技術=利益が出るではないです。面接して思ったことです。
優良企業が求めるエンジニア像、チームで大事にしていることで、
心理的安全性です。これがあると何がいいかというと
メンバーが主体的に動けるチームです。
メンバーが主体的に動いてリリース速度が上がると企業にどんなメリットがあるのか？
結論ビジネス層が実現できることが増えてビジネスチャンスが増えます。
実際に自分達がいいと思ってもユーザーが喜ぶのか、売上が上がるかは別問題です。
一度リリースしてからユーザーの反応などを見て改善していくのがいいです。
完璧主義ではなく、改善主義がいいと思います。
褒める、感謝を伝えると何がいいか
エンジニアは自己肯定感が低い印象です。CTOなどリーダー層などは褒められることが少ないです。人間褒められて嫌な人はいないです。
お互いに褒め合うことで、コミュニケーションがしやすくなり、
主体的に意見などが出やすくなります。
このようにメンバーがお互いにいい案を出したりしていけるといいプロダクトが出来上がるのだと思います。
お互いが話しやすい雰囲気作り
ビジネスサイドとエンジニア、デザイナー、QAでお互いが話しやすい雰囲気作りが開発効率をあげます。
1番簡単なことです。
-
褒める
これできない人意外と多いです。
メンバーの状況を把握する
メンバーの特徴、強み、弱み、どういう考えがあるのかを会話をしたりしながら把握するといいです。それでお互いのコミュニケーションが活発になっていきます。
この現場でやってよかったと思ってもらえることを目指す
こういう気持ちでやると他のメンバーはこのメンバーのために頑張ろうってなります。
これを目指すべきかと思います。
結局生産性が悪いチームって、メンバーがこの会社に貢献しようってなっていないのだと思います。
自分の経験談(リリース速度が速かったチーム)
自分が実際にリリース速度が速かったチームで一例を出します。
- メンバー
1.フロントエンジニア２名
2.PO(プロダクトオーナー)2名
3.QA2名
4.CS1名
5.デザイナー1名
他にもチームはあったのですが、自分達はこのチームで回してました。
チームで取り組んでいたこと
1.少数精鋭
人数が少ないので密にコミュニケーションが取れる関係でした。
大人数でマイクロサービスでもないのに開発すると、コンフリクトが大量発生してしまい、
作業が半日ストップしてしまうこともありました。
2.チームのメンバー同士の仲の良さ
お互いに雑談などをしていたりするので、気軽に相談しやすいのが良かったです。
こうすることで主体的にメンバーが意見や報連相ができる体制ができます。
3.お互いの褒め合う
感謝を伝え合っていたので心理的安全性が高かったです。
お互いにリスペクトが生まれるので、メンバー同士頑張ろうってなれます。
4.Zoomでいつも話せるようにする
いつでも話せる状態にしておきました。こうすることで気軽に相談できる体制に持っていくことができます。
5.スクラム開発
基本はスクラムでいいと思います。ただガッツりスクラムにすると仕様がごちゃごちゃになるので、
新規開発である一定のラインまではウォーターフォールにして、ある程度できたらスクラムにして
プロダクトを改善するのがいいと思います。
6.QAと一緒に動作確認
PRを出す前にQAの人と動作確認しながらやるとバグが減って手戻りなどが発生しなくなると思います。
7.ファシリテーターを当番で回す
MTGでも話さない人が出ないように、ファシリテーターは
全員がやるようにするといいと思います。
# 結論(コミュニケーションがちゃんと取れるチームは強い)
技術力以上にお互いのコミュニケーションを重視するチームが結局最強です。
サッカーでもどんなスーパースターを集めても勝てないことはよくあります。
結論チームワークがバラバラだったりすると勝てないです。
参考資料、動画
Discussion