【何十年後も生き残れる!?】最前線を行く”強いエンジニア"の共通項は！？~Engineer Blog #01~

はじめに…

気付いたらもう11月下旬ですね！来月で今年も終わり…早すぎる１年でした！！
最近は冷え込む日々が続いていますが、みなさま体調はいかがでしょうか？

さておき、こちらはOwned株式会社 CTO 黒光俊秀 によるエンジニアブログです。

前提として、このブログは［5年間エンジニアを積んできたエンジニアの個人的見解］であって、［他者を非難するもの］ではありません。 共感していただいたり、誰かの今後のエンジニア人生の励みになったり、エンジニアを志す支えとなるコンテンツになれば良いなと思って書いているのでぜひ最後まで読んでいただけると嬉しいです！

今回は、私が思う"強いエンジニア"の共通項についてお話ししていきます！

【募集ページ】

【合わせて読みたいownedインタビュー】

そもそも"強いエンジニア"って？

強いエンジニアといっても捉え方は人それぞれ...
繰り返しになりますが、このブログは5年間エンジニアを積んできたエンジニアの個人的見解です。
ご了承ください。

では、”強いエンジニア”とは...

このブログでは、

💡 強いエンジニア ＝ 顕在化した問題や課題を言語化して、最短工数で解決できる方

と定義して書き進めていきたいと思っています！ ※工数とは

なぜ"顕在化"した問題や課題を言語化する必要があるのか？

ここからは、

💡 強いエンジニア = 顕在化した問題や課題を言語化して、最短工数で解決できる方

の『なぜ顕在化した問題や課題を言語化する必要があるのか』についてご説明していきます！

顕在化した問題や課題を自分の中で留め、解決することはもちろん可能なこと...

しかし、それは会社のアセット、他者へのアセットとして残らないんですよ...
もし、同じ事象の問題が発生したとしても、それを他のエンジニアが解決できないですからね。
これは属人化の一途をたどりがちな事態になってしまうので気をつけたいところ…
※アセットとは, 属人化とは

また、顕在化した問題や課題をbizに的確に説明できないということは、 本当は開発しなくても解決できる問題や課題を開発してしまい、最短工数で解決できないという事態も発生してしまう可能性がありますね。

"顕在化"した問題や課題の言語化について詳しく

先ほど、【顕在化した問題や課題を言語化する能力が必要】ということを理由と共に説明しました！
これからは、顕在化した問題や課題についてやその対処方法について書いていきたいと思いますね。

これらを読めば、【言語化能力がいかに大切か】ということが解像度を高めながら伝えることができると思います。

そもそも、顕在化した問題はどんな時に現れるのかについてお話していきます。

顕在化した問題はどんな時に現れるか、
それは【機能開発をリリースした時】、【インシデントが発生した時】に起こります。
※リリースとは, インシデントとは

この問題に対処する方法としては、

ーーー

• エラーログを記録、Slack等に通知できるようにしておく。※エラーログとは
• 問題の発生を上長や関わりのある開発メンバー、bizに伝える。
• • BtoB, BtoCに問わず、お客様に報告説明する必要があるため。※BtoB, BtoCとは
  • 問題解決する人員を増やすため。
• エラーログの通知内容を読んで理解する、ググる、chatgptを利用する。
• • 複合的要因により問題が発生している場合、問題の切り分けを行う。※問題の切り分けとは
• 【顕在化した問題を言語化する。】
• • 何が問題だったのか？
  • いつからその問題は発生していたのか？
  • 問題の影響範囲は？※ 影響範囲とは
  • 問題をどのように解決するのか、暫定的対応策、恒久的対応策。
• 対応策に沿って対応。
• パッチをリリース。※パッチとは
• お客様へ報告説明。

ーーー

などがあげられます。

次に、課題はどんな時に現れるのかとその対処方法について。

下記に２つの要件とそれぞれの対処方法についてまとめました。

ーーー

• 機能要件 ⇒ 機能開発を行う前の仕様、設計取り決め時 ※仕様と設計の違いとは 機能要件、非機能要件とは
• • 基本的にbizから作りたい機能要件は依頼される。
  • 機能要件を開発する目的をbizから説明してもらう + 不明点などを質問する。
  • 本当に開発する必要はあるのか伺う⇒工数削減でき別の課題に取り組める可能性が高まるため。
  • 開発に大幅な工数がかかる場合は代替案を提案できないか伺う、段階的リリース等。※段階的リリースとは
  • 優先度はあってるのか伺う。
• 非機能要件 ⇒ 開発してて不便を感じた時、開発文脈でもっとこうした方がいいなと感じる時
• • output / 開発時間を計測して検知する。outputが悪い要因を言語化する。
  • 非機能要件はbizからすると見えづらい課題なので、課題に取り組む前に適切に状況を説明する。

ーーー

上記を読んでみて、言語化能力がいかに大切かということがより伝わったのではないでしょうか？

"最短工数"にて問題、課題解決できる能力を身につけるには？

ここまでで、言語化能力がいかに大切かということが伝わったと思います。

次は、

💡 強いエンジニア = 顕在化した問題や課題を言語化して、最短工数で解決できる方

の『最短工数で解決できる方』について詳しく説明していきたいと思います！

知識を持ってるだけでは、エンジニアに価値はありません。
知識を経験に変換して、体系的に学習していく必要があるんですよ。

では、最短工数にて問題、課題解決できる能力を身につけるにはどうすれば良いのか？

下記に箇条書きでまとめてみました。

ーーー

• フロントエンド、バックエンド、インフラ、Webアプリケーション、Nativeアプリケーション問わず、毛嫌いせずタスクに取り組む。
• • フロントエンド、バックエンドとは
  • インフラとは
  • Webアプリケーションとは
  • Nativeアプリケーションとは
• タスク単位で時間を松竹梅にて決めて取り組む。
• • やるべきことを細分化しよう。
  • 不安要因を確認しよう。不安要因 = 開発を止める阻害要因。実装したことがなくどれくらい時間がかかるのかわからない等。
  • 細分化した要素に時間を割り振る。
• タスクを取り組む上での不安要因を、最小工数で解消する方法を知っておく。これらが、最短工数にて問題、課題解決できる能力を身につける為のフローになります。
• • 不安要因を解決するために適切なタイミングで質問する。
  • 問題解決できるか15分考える。
  • 自分の無知レベルの解像度を明確にして質問を分解する。 (参考: https://qiita.com/seki_uk/items/4001423b3cd3db0dada7)

    - **0OI: 全部分かっている**
        - 「答え」を持っている。あとは書き写すだけで完成する。
    - **1OI: 分からないことが分かっている**
        - 答えを得るための「質問」を持っている。
    - **2OI: 分からないことが分からない**
        - 「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。
    - **3OI: 分からないことが分からない状況を何とかする術を知らない**
        - 2OI→ 1OI → 0OIと進んでいくためのプロセスがない状態です。
    - **4OI: 無知にレベルがあることを知らない**
    - **0OI: 全部分かっている**
        - 「答え」を持っている。あとは書き写すだけで完成する。
    - **1OI: 分からないことが分かっている**
        - 答えを得るための「質問」を持っている。
    - **2OI: 分からないことが分からない**
        - 「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。
    - **3OI: 分からないことが分からない状況を何とかする術を知らない**
        - 2OI→ 1OI → 0OIと進んでいくためのプロセスがない状態です。
    - **4OI: 無知にレベルがあることを知らない**
    - **0OI: 全部分かっている**
        - 「答え」を持っている。あとは書き写すだけで完成する。
    - **1OI: 分からないことが分かっている**
        - 答えを得るための「質問」を持っている。
    - **2OI: 分からないことが分からない**
        - 「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。
    - **3OI: 分からないことが分からない状況を何とかする術を知らない**
        - 2OI→ 1OI → 0OIと進んでいくためのプロセスがない状態です。
    - **4OI: 無知にレベルがあることを知らない**
    - **0OI: 全部分かっている**
        - 「答え」を持っている。あとは書き写すだけで完成する。
    - **1OI: 分からないことが分かっている**
        - 答えを得るための「質問」を持っている。
    - **2OI: 分からないことが分からない**
        - 「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。
    - **3OI: 分からないことが分からない状況を何とかする術を知らない**
        - 2OI→ 1OI → 0OIと進んでいくためのプロセスがない状態です。
    - **4OI: 無知にレベルがあることを知らない**
    

  • 質問する。（質問テンプレートを作っておくと良い。） (参考: https://qiita.com/e99h2121/items/95129fe0e94d2ed1120b )
  • また質問は相手の状況を考慮して行うことが大切。（質問の解像度が低かったり、質問の仕方次第で相手を怒らせてしまうことも。） (参考: https://qiita.com/haihaikazuma/items/f2940008a50084030096?utm_content=buffer3d651&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer&fbclid=IwAR34YJ3e--8wgN9xN9I-H99eZvA96_TpD9o_scPpesERCCW2qUe3c3sAIt8_aem_AZeBmsN3DNmpSQs1FPiDwZXaUWz3OVLHPhiA29mSvy5nbuXlieG25tQ30EgWfE4AZJ0)

ーーー

その他に身につけておいた方が良いこと

最後に、その他に身につけておいた方が良いことについてご説明いたしますね。

その他に身につけておいた方が良いことは大きく２個です。

• 自己管理 = パフォーマンスを毎日一定以上出せるように自己管理を行う。
• • 適度な運動
  • 食事
  • 睡眠

• 調べ物をするときは一次情報から
• • 一次情報とは
  • 開発文脈で言うと、公式のドキュメント。 例: https://developers.line.biz/ja/services/messaging-api/
  • こいつらは違う。https://zenn.dev/ , https://qiita.com/
  • 根本的な仕様は公式がまとめているため。

最後に...

今回は、私が思う【強いエンジニア】についてご紹介いたしました！

『強いエンジニア』になることができれば、『何十年後も生き残ることができるエンジニア』になれること間違いないと思っています！

この記事を読んで 「考え方に共感できる！」 「こんなエンジニアを目指したい！」 などと思ってくださった方が１人でもいらっしゃったら嬉しいです。

また、今回の記事含めてOwnedに興味を持った方はエンジニアの募集も行っていますので、ぜひお問い合わせください！

最後までお読みいただきありがとうございました！

<よくある質問>

Q. 新しい言語などのインプットはどのくらい重要ですか？

エンジニアをするにあたって、インプットは常に必要です。なぜかというと、エンジニアは技術の流行り廃りの激しい領域だからですからね...
では、インプットをするうえで大切なことをお話していきますね。
大切なポイントは全部で3つです。
1つ目は、実務で使われる or エンジニア募集でよく見られる、汎用的な言語を学習すること。使われない言語を学んでも使う機会がないと、結局満足度が低くなってしまうんですよ。
2つ目は、実務を通して足りていない要素を見つけ、学習を行うことです。 何から学ぶべきか迷う心配を減らすため、必要知識 = 実務と紐づけることができるんです。
3つ目は、少し勇気がいるかもしれませんが、上司に足りていない力を素直に直接聞くことです。 私は、これらを大切にしていくことが重要だと思っていますね。

Q. 強いエンジニアとしてのマインドはどのような過程を経て得ましたか？

私は、環境の影響が大きいですね。環境というのは、『優れた上司』、『裁量権が与えられる』、『退路を断っておくこと』等です。優れた上司というのは、当たり前の基準が高い人、なんでもできる人ですかね。裁量権については、エンジニア文脈にて1事業を1人で見るくらいの裁量権は欲しいと思っています。
また、この点では自分自信で事業が伸びそうかもしっかり判断することが大切ですよ。
退路を断っておくというのは具体的に、「25歳までに結果を出さないと実家帰る」などといった制約をかけることでう。自分に厳しく制約をかけることはかなり大事だったと思いますね。

Q. 人間性面で一緒に働くエンジニアに求めていることはありますか？

私は、相手の求めること、周辺情報を読み取って、コミュニケーションや仕事ができる人を求めています。予測して考えるスキルやコミュニケーション力は仕事をするうえで重要なことだと思っていますね。

Q.強いエンジニアになるメリットは何か？

強いエンジニアになるメリットとしては、
〇『給与上がること』
〇『仕事に困らないこと』
〇『紹介で仕事がやってくること』
〇『スムーズに上流工程にも対応できる (顧客の意図を的確に理解できる、エンジニアの気持ちを汲み取れる etc... )こと』
だと思っています。かなりかなり大事な部分のメリットだと思っていますね。

※上流工程とは

Q.いつまで(年齢または経験年数)に強いエンジニアになるべきか。

これは、早いに越したことはありません。
日本で働くことに限ると25歳までには欲しいスキルですね。

Q.今から強くなりたいエンジニアは優れた上司や裁量権のある環境はどうやったら見つけられるか

優れた上司、裁量権を見つけるには、『IT企業であること』、『10~20名で構成されてる小規模なこと』、『東大発などと書かれていること』、これは、なぜかっていうと、なんか賢い集団が集まっていることが高からですね笑。
また、学生企業という会社を見ると、少し抵抗を持つ方もいるかもしれませんが、私はそれでも構わないと思っています。経験を圧倒的成長でカバーしてくる人は存在するんですよ。
弊社も現役慶應生だった石井CEOが設立しましたが、圧倒的成長を遂げているエンジニアが多いですもんね。

Q.マネージャーやCTOやテックリードが、部下から強いエンジニアを作るためにやっていること/やるべきことは何か

『「わかんない」という部下からの声は躊躇わず聞け』と指導していますね。
なんでそうなったのか、なんでそう判断したのか。
背景/目的を説明することは大切ですし、質問する時もなんでそうなったのかを突き詰めるようにして、腑に落ちるまで根気よく話すように促しています。

また、結局1個のことができるエンジニアに価値ないって思ってる(技術の変化が激しくて総合力が求められるようになったと思う)ので、あえて様々なタスクを依頼するようにもしてます。

【募集ページ】

【合わせて読みたいOwnedストーリー】

Owned株式会社では一緒に働く仲間を募集しています！

• プロジェクトマネージャー
• WEBエンジニア
• PM｜エンジニア
• 開発
• • WEBエンジニア
  • Webエンジニア
  • エンジニア
  • エンジニア｜圧倒的成長環境
  • 学生エンジニア｜圧倒的成長
  • 学生エンジニア
  • エンジニア｜圧倒的成長
• ビジネス
• • プロジェクトマネージャー
  • PM｜エンジニア
  • PM｜マネジメント
  • SEOライター｜マネジメント
  • 法人営業
  • インサイドセールス
  • 経営企画｜事業成長
  • 渉外｜法人営業
  • セールス｜営業・戦略スキル
  • 経営企画
  • 法人営業
  • Web広告｜マーケティング
  • Webマーケティング
  • SNS広告運用
  • Meta広告運用｜マーケ
  • PM｜事業をグロース
  • PM｜事業拡大マネジメント
  • 広告運用｜リスティング
  • Webマーケ｜リスティング
  • Webマーケター｜新卒採用
  • Webマーケター｜広告
  • Webマーケター｜成長環境
  • PM｜成長加速
  • Webマーケティング
  • SEOライティング
  • SEOライター
  • Webメディアリーダー