4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

エンジニアキャリアについてあなたの考えをシェアしよう!

エンジニアに必要なことは本当にプログラミングスキルだけですか?

Last updated at Posted at 2023-07-20

ウルジマクとは何者か

こんにちは。地方で会社員エンジニアやってます、ウルジマクと申します。エンジニア歴で言えば、2000年から、23年の経験を積んでることになります。

社会に出る前から、卒論でMATLABを使ったシュミレーション計算プログラムを組んでみたり、専門学校の卒業制作で Open GL を駆使したC言語でのゲームプログラムを組んでみたり、アルバイトでゲームプログラマとして数ヶ月働いてみたり、我流でガムシャラにプログラムを身につけることをやってた時期もありました。

アマチュア時代も含めると、プログラムと向き合ってきたのは、26年くらいになります。

2000~2015年頃まではオンプレミス業務アプリの開発・保守・運用がメインでした。この頃は都内にいました。

2015年以降はクラウドの波に乗り、SalesforceなどのSaaSに触れ、現在では、Webアプリケーション開発がメインです。2017年に実家都合により、地方に戻っています。

現在は、主に業務では以下に触れてます。

  • Java(8~17)
  • Spring Boot
  • Maven
  • Heroku
  • AWS
  • Salesforce

他にも非業務で、自身の関心により以下に触れています。

  • JavaScript(React, Next.js)
  • Python
  • Go
  • Ruby
  • PHP(Laravel, CakePHP)
  • Docker

他にも色々つまみ食いしていたと思いますが、思い出せないのでこのくらいで。

エンジニアに必要なことは本当にプログラミングスキルだけですか?

早速本題に入ります。

タイトルの「エンジニアに必要なことは本当にプログラミングスキルだけですか?」ですが、エンジニアを生業とされている方々からすれば、何を今更…プログラミングスキルだけでやっていけるわけはないでしょう、と反応されるでしょう。

私は今の会社で他社の新入社員向けJavaエンジニア講師も担っています。

受講者から聞く声で、素朴に「技術スキル」だけを習得しようと考えている方がまだまだ多いことを実感しています。

また、私自身2000年にこの業界に飛び込んだ時点では、今持ってるプログラミングスキル一本で、本気で人生を乗り越えていくつもりでした。

プログラミングスキルに先鋭化してさえいればなんとかなるだろうと考えていました。

さらに、エンジニア業界から外の世間の声を聞くと、「プログラミングスキルがとにかく高ければ儲かる」「誰とも喋らずにコンピュータに向かって黙々と作業ができるんでしょう?」などというイメージが未だに先行しています。

多くの場合では誤った認識となる状態で、エンジニアを目指したり、業界に飛び込んだりすると、業界や会社、その本人にとってもお互い非常に不幸です。

「こんなはずじゃなかった」と明確に思い至れば、自力で道を修正することもできるのでまだ良いです。

しかし、前提認識が違っている状態で、漠然と仕事をこなしていると、どこかで違和感や疑問を感じながら仕事することになります。

この状態が不幸であることは想像に難くないでしょう。

思い返せば、私は最初の10年くらいこの状態で不幸でした。

ということもあり、もし、今のキャリアを積んだ私が、23年前のキャリアを積み始めた私に言えることがあるとしたら何を伝えるか?という、現実では実現不可能なことですが、このタイトルを問いかけたい。

ですから、エンジニアキャリアというテーマを目にしたときに、このタイトルが真っ先に思いつきました。

自身の経験も踏まえて、記事を投稿しようと思い至りました。

それで何を言いたいのか?

タイトルの「エンジニアに必要なことは本当にプログラミングスキルだけですか?」という問いに対する、私の回答は「いいえ」です。

一つ断りを入れておきます。

歩んでる人生は人それぞれです。

人によっては「はい」が回答になる方もいらっしゃるでしょう。

これは私の推測となりますが、「はい」と回答できる方は、エンジニアに必要なプログラミングスキル以外のスキルを、ナチュラルに既に習得済み、意識せずともパッシブスキル化しているのだと考えられます。

または、プログラミングスキル以外のスキルを持った協力者がいるため、本人はプログラミングスキルだけに集中することができる環境をお持ち、または、手に入れたのだと考えられます。

私を含め、能力はあとから学習・習得する必要がある人、環境を持っていない人、つまり、いわゆる普通の人々は、プログラミングスキルだけではやっていけないという現実を認識しておかなければなりません。

これから、エンジニアを生業とする人は増えていくでしょう。

私のように会社員エンジニアや、フリーランスエンジニアともにますます増えていくでしょう。

義務教育でのプログラミング教育は始まっています。

今後、エンジニアリングとしては新人研修などを必要としないような人材がどんどん増えてくるのかもしれません。

そんな中で、プログラミングスキルだけを極めるという道はとんでもなくハードモードの人生を選択しているように思います。

ハードモードなのを承知な上で、その道を選択された方は問題ありません。

寧ろそのような方は私は応援したいです。

私が警鐘を鳴らしたいのは、とにかく狭い選択肢を極めて行けば、必ず、明るい未来が待っていると信じてしまっている人々です。

つまり、兎に角努力をすれば報われるを信じて疑わない方々に、この記事が特に読まれることを望んでいます。

私の考えは、その他大勢の努力の方向性として、エンジニアは掛け算スキルを持つことで幸せになれる、です。

いや、スキルというと範囲が狭いので、掛け算できる肩書をピックアップしてみて、それらを磨いていくことで、それぞれのレア度をもった競争率の低い場を見つけることです。

以下、堀江貴文さん著作の「多動力」の言葉を引用します。

「100人に1人」×「100人に1人」の掛け算により、「1万人に1人」の人材になれる。これだけでも貴重な人材だ。(出典:多動力 堀江貴文 (著))

少なくとも私は、この掛け算論に乗っかることで、現在40代後半ですが、今後のキャリアも面白く明るいものになりそうだと思えるようになりました。

ご参考までに、私自身が意識している掛け算を羅列していきます。

あくまで私自身の場合ですので、参考程度に見てください。(もし、一致する方がいる場合は、お仲間ですので、コメントや連絡ください)

少しでも今後のエンジニア人生において導きの星となれば幸いです。

掛け算 その1:コミュニケーションスキル

月並みですが、コミュニケーションスキルです。

就活・転職サイトやコミュニケーション専門のサイトにテクニックの詳細は記載があるので、コミュニケーションのテクニック的なものはそちらを参照ください。

私がここで申し上げたいのは、基本的な動作についてです。

今すぐにできることを列挙しています。

  1. 挨拶をしてくれたら、同じくらいのトーンで挨拶を返す。
  2. 挨拶をしたほうが良い場面では、自分から挨拶をする。(相手が挨拶を返さないとしても)
  3. 謝罪ではなくお礼を言う。("すみません" を "ありがとうございます" に言い換える)
  4. 複数人で会話中に話者が喋っている会話内容は最後まで聞き終わってから喋り始める。(途中で遮ったり割り込んだりしない
  5. 相手からの質問に対して回答する。(質問に回答せずに話し始める人、案外多いです)
  6. 5W1H(場合によって5W2H)を省略せずに、丁寧に述べる。(それは誰のいつのことで、事実なの?所感なの?的なこと)

これらをできない人…というよりできるのだけれどもしていない人、ベテランさんでも案外と多いです。

どれも、できていない人と対峙すると、指摘するほどでもない(というより指摘するほどのコストをかけたくない)ですが、許せる人リストには入りにくいです。

ここで、許せる人リストという言葉が出てきましたが、次のようなことです。

例えば、会議の予定があり予定時刻になっても来ない人がいるとします。

  • 遅れてきたのはAさん。通常であれば時間を守るし、仮に遅れるのであれば事前に連絡もある。いつも、気持ちの良い挨拶をしてくれる。今日はどうしたのだろう…?
  • 遅れてきたのはBさん。何度も、開始時間にも遅れるし、普段から不遜な態度。こちらが話をしていると割り込んできて、突然間違いを指摘するし、まぁ、言っていることは正しいのだけれど…出勤してきてもいつの間にか席に付いているし、何なのあの人?

どちらが許せる人リストに入っているかはもうおわかりですね。

返報性の原理という心理作用があります。

これは、相手から何かを受け取ったときに「こちらも同じようなお返しをしないといけない」という気持ちになる心理効果のことです。

普段から与えている人は、許せる人リストに入りやすいです。これは、爽やかなコミュニケーションをもらっているため、返報性の原理が働いて、許せる人リストに入る、ということです。

1.~6.であげた行動は、いずれも与えているコミュニケーションと言えるでしょう。
何を与えているか?

それは、自己肯定感です。

爽やかなコミュニケーションを取ることにより、自己肯定感、つまり、相手の存在を認めることをしています。

相手の存在を認めてどうするんですか?って?

それは、良好な人間関係を築くことで、チームワークの向上、生産性の向上を目指します。

そんなこと言っても、もう、自分は新人じゃないんだし…テクニカルスキルや大きな案件やプロジェクト、交渉事で実績を上げているんだし、やる必要ないでしょ?周りはその実績を認めてくれているから今の位置にいるし、給料または報酬もそれに見合ったものがもらえているし、そんな事する必要ないよね。

…と思った人!

ちょっと考え直してみてください。

だれでもすぐにできることをわざわざやらない理由はなんですか?

ベテランだから?
自分の立ち位置を確立しているから?
そんなキャラクターじゃないから?
新人みたいなことして気恥ずかしいから?
今までやっていないことを急にやり始めたら周りがどう思うか気になる?

一度、深呼吸をして次の言葉を声にだして自問してみてください。

”これらの行動に(金銭的な)コストはかかりますか?”

かかりませんよね。

あえてかかっているコストとしてあげるとしたら勇気です。

そう、勇気が足りていないのです。

心理学の三大巨匠の一人、アルフレッド・アドラーは言いました。

誰かが始めなければならない。他の人が協力的でないとしても、それはあなたには関係ない。私の助言はこうだ。あなたが始めるべきだ。他の人が協力的であるかどうかなど考えることなく。(出典:嫌われる勇気 岸見 一郎 (著), 古賀 史健 (著) )

私は、この言葉から非常に勇気をもらっています。

以前の私は、やってみたいな、やったほうがいいかな、と思っていたことでも、何かに付けて、やらない理由を探して、ことごとくやらない・行動しない、という思考・行動パターンを選択していました。

そのため、沢山の機会を失っていました。

未体験で知識ばかり詰め込んでいる状態だとどうなるか?

自分に自信が持てなくなります(未体験・未経験だから)。

そのため、更に行動しない…という負のスパイラル状態にハマっていました。

私は、この負のスパイラルから抜け出すのに、結果として勇気が必要だった、ということを体験しました。

対人関係は勇気の問題。

アドラーのこの引用の言葉は、私を変えてくれた金言の一つです。

掛け算 その2:哲学

先程、アルフレッド・アドラーの話をした流れで、「哲学」を掛け算としてあげておきます。

あれ?アドラーは「心理学」じゃなかったっけ?

と思った方! この記事をよく読んでくださいましてありがとうございます!

なぜ、ここで「心理学」ではなく、「哲学」としたか。述べていきます。

哲人:他の心理学がどんな姿であるのか、わたしはよくわかりません。しかし、アドラー心理学に関して言えば、明らかにギリシア哲学と地続きにある思想であり、学問であるといえるでしょう。(出典:嫌われる勇気 - 第1章 トラウマを否定せよ - 知られざる「第三の巨頭」より)

「嫌われる勇気」を最初に読んだとき、私はこの文に大いに混乱しました。

心理学なのに、哲学?

私自身、「哲学」については、大学の教養部で選択せざる得なくて、選択した程度の知識しかなく、そもそも漠然としていました。

哲学と聞くと難解であるというイメージを持つ人は多いかもしれませんが、プラトンの対話篇には、専門用語はひとつも使われていません。
そもそも、哲学が専門家にしか通じない言葉で語られるのはおかしいのです。哲学のもとの意味は、「知」ではなく、「知を愛すること」であり、知らないことを知ろうとすること、知に至る過程こそが重要だからです。(出典:嫌われる勇気 - あとがき - 岸見一郎 より)

私もこの「難解であるというイメージを持つ人」の一人でした。

哲学者 岸見一郎さんの「嫌われる勇気」を通じて、「難解であるというイメージ」が誤解であったことを理解しました。

もう一つ、引用します。

哲人:あなたがアドラーを知らなかったことは当然かも知れません。アドラー自身、こんな事をいっています。「わたしの名前を誰も思い出さなくなる時が来るかもしれない。アドラー派が存在したことすら、忘れられてしまうかもしれない」。しかし彼は、それでもかまわない、といいます。アドラー派の存在そのものが忘れられること、それは彼の思想が一学問分野から脱皮して、人々のコモンセンス(共通感覚)となることを意味するからです。(出典:嫌われる勇気 - 第1章 トラウマを否定せよ - 知られざる「第三の巨頭」より)

創始者アドラーが願ったことはまさに「知を愛すること」であり、コモンセンスは、エンジニア界隈的な言い方をすれば、人のあり方のオープンソース化と言えるでしょう。

以上のことから、「心理学」ではなく、「哲学」という言葉を選択しました。

エンジニアが「哲学」をなんの役に立てるのか?

チームビルディングです。

チームビルディングがなぜ必要かというと、エンジニアはプロジェクトごとにチームを作るからです。

1ヶ月、3ヶ月、半年、1年…と期間に違いはあれど、その時々でチームメンバも変わりますし、プロジェクトリーダやプロジェクトマネジャーも変わります。

短い期間で継続的に成果を出すために、対人関係が良いことが必要であることは自明でしょう。

古来より、人は対人関係を良くしようと知恵を出しています。

温故知新的なものから、現代自己啓発的なものまでを知り、実践してみる価値はあります。

そういう意味でも、エンジニアこそ、哲学のすすめなのです。

ファシリテーション、コーチング、アサーション、レジリエンス、傾聴、心理的安全性…など、対人関係のテクニックは様々あります。

ただ、これらたくさんの情報があるにも関わらず、活用できている人は多くはないように思います。

なぜか?

「やり方」だけ知っていても、どこかで心にブレーキがかかってしまい、止めてしまうからです。

各種哲学で語られている通り、対人関係の「あり方」も習得することにより、適切な心のあり方と行動をすることができるようになります。

私のエンジニアキャリアの中で、今後もっと広げていきたい領域です。

私もまだまだこの分野は勉強中および実践・実験中で修行中の身ですが、賛同してくださる人が一人でもいらっしゃると嬉しいです。

掛け算 その3:オカルト

ここに来て、急に話が怪しくなってきました…

エンジニアとオカルトにどんな掛け算ができるんでしょうか?

誰もエラーを取り除けなかったプログラムをコンパイルするときに、祈祷するとコンパイルが通るスピリチュアルエンジニアがいる!

とか

だれも知らないサーバルームのサーバ筐体の内側にたくさんの御札が貼ってあって、文字通り封印されているサーバがあった!

とか

エンジニアあるある(?)話をして、場を和ませる(凍りつかせる)…というわけではありません。

オカルトの中でも、怪談界隈の話から。

既にIT怪談師やエンジニア怪談師を名乗る方々はいます。

その話の内容はエンジニア特有のもの…ということはなく、本人または体験者から取材したガチの実話怪談であることが多いです。

実話怪談というジャンルは、1990年代から出始めて、実に30年くらい経っているものですが、2010年頃から急速に盛り上がってきました。

私もこの頃から、怪談イベントに聞き手として、ちょくちょく参加することが増えてきました。

ちょうどIT業界では、仮想化技術やクラウドコンピューティング、Dockerなどが出てきて急速に広まり始めた頃と重なります。

youtubeやニコニコ動画が普及し始めた時代とも相まって、個人が音声や動画を生配信できる仕組みができたことも、オカルト話が広まり始めたキッカケであると思われます。

1990年中頃に発生した日本中を震撼させたある事件をキッカケに、しばらくは地上波ではオカルト系の番組が敬遠されていたことも、影響していたのかもしれません。

オカルト大好きな人達の鬱憤を晴らすかのように、テレビとは異なるプラットフォームで、2ちゃんねる、ネットラジオ、youtube、ニコニコ動画では、とても活発に活動していました。

私は元々育った環境(山の中の田舎で60年以上経過していた古民家で育った)と時代(1980~1990年代のオカルトブーム)も相まって、オカルトがとても大好物になった人です。

UFO、UMA、都市伝説、怪談、陰謀論、オーパーツ、予言、etc… どれも、大好物です。

月刊ムーは愛読書…と言いたいところですが、今はもう書籍の方は読んでなくて、超ムーの世界R からの シン・オカルト倶楽部を視聴しています。

怪談にしろ、都市伝説にしろ、語り部やテラー達の語り口には、プレゼンテーション的な部分で非常に参考になる部分があります。

嘘か真かわからない、日常生活をしていれば普通に考えたら荒唐無稽な内容を、メディアやプラットフォームを通じて、堂々と発信しています。

考えてみれば、ソフトウェアは物理的実体を持たないものです。

物理的な実体を持たないものを定義したり、設計したり、実装する。

物理的な実体を持たないもの、という意味でオカルトとは共通項があります。

特に、プレゼンテーションで実態のないものをいかに説明するか?は、オカルト話、主に都市伝説の構成や強調部分には共通するものがあります。

例えば以下のように。

国が主導する 人知を超えた究極目標 「人が身体、脳、空間、時間の制約から開放された社会を実現」
SF作品に出てきそうな一節ですが、これは2050年までを目標に日本の内閣府が本気で取り組んでいる「ムーンショット目標」のひとつです。(出典:コヤッキースタジオ都市伝説 Lie or True あなたは信じる? コヤッキースタジオ (著) )

上記のような都市伝説は結論から述べます。

そこから権威のある(らしい)もの、過去に実際に起きた(もっともらしい)ことを積み上げていって、最終的には、「なるほど、有り得そうやな…」という方向に持っていきます。

これは、ソフトウェアのプレゼンテーションでも同じ方式を取ります。

一方、怪談は違います。

最初にオチや結論を持ってくる、出オチパターンは殆どありません(まったくないということではありません)。

というより、オチがない、というもののほうが多いです。

なぜならば、怪異の多くは人間の論理が通用しないからです。だから、怖い。

なぜ、体験者はこんなに酷い目に遭うのか、体験者の周りの人々は何の因果があって、理不尽な目に遭うのかわからない

この、わからないということが、より一層不気味さと好奇心をくすぐってきます。

人に披露する怪談話としてまとめる場合、「わからない」だけで終わってしまっては物足りないことが多い。

そこで、推論や仮定をするために、取材などで情報収集をする。

起きた怪異とその場所、事件、事故、人物、日付、時刻になにか因果がないか推測してみる。

そうすることで、より話しが広がっていく。

いろんな可能性があって怖い上に、なるほどそういう事かもしれない、と、推論として、話をまとめることができるし、腹落ちしやすくなります。

ところで、怪談サークル とうもろこしの会 会長 吉田悠軌 氏によれば、実話怪談と都市伝説は以下の区別をするそうです。

イベントなどで怪談を披露しあっていると、たまに体験者の存在が確認できない話が出てきたりします。そんな時、我々はよく「この話は都市伝説かもしれないけど・・・」と注釈をつけます。
実話怪談は体験談の出処がハッキリしていることが大前提です。しかしこの場合、誰かの体験だと保証できなかったり、不特定多数に広まった噂なので「これは『都市伝説』ですよ」と念を押すのです。(出典:一生忘れない怖い話の語り方 すぐ話せる「実話怪談」入門 吉田 悠軌 (著))

情報収集、推論・仮定、話の持って行き方、話のまとめ方はエンジニアには非常に役に立つスキルです。

私は、とても参考にしています。

掛け算 その4:メンター

私は副業として、エンジニア向けメンターもしています。プラットフォームは、MENTAを利用しています。

冒頭でも触れた講師業の集合研修タイプとは違い、1対1の個別指導という形を取ります。講師業のノウハウと重なる部分もありますが、案外重ならない部分も多いです。

大きな違いは、満足してもらう相手が違います。

集合研修は、受講者本人、というよりは彼らが所属している会社の方々(人事担当、採用担当、育成担当)に満足いただかなければなりません。

受講者本人にもある程度脱落せずに継続してもらえるように加減しつつ、所属会社には次年度も申し込んでもらえるよう様々な注意を払わなければなりません。

一方、メンターは、メンティー本人がお金を払ってまで、知識を得よう、スキルを習得しよう、問題を解決しようとしています。したがって、メンティー本人が満足する必要があります。

私がメンタリングした、内容の一部をご紹介します。

  • RESTful アーキテクチャスタイルについて解説
  • Salesforceのサポート
  • eBayAPI が通信できなくなったためエラーを解消するまでサポート
  • React×CakePHPによるREST API作成と連携についてエラーを解消するまでサポート
  • Nuxt.js × Netlify × MicroCMSでJamstackブログを公開できるまで
  • プログラミング言語のユーザ定義型について説明

今のところ私が手応えを感じているのは以下の2パターンです。

  • "REST"や"ユーザ定義型"のように、概念やプログラミングのふわっとしたところ、メンティー本人の細かい疑問にも答える形の解説や言語化のサポート
  • 特定のエラーが発生しているので解消したい → エラーを解消後にも発生する問題も一緒にサポート

テキストメッセージやチャット、Zoomを使用した画面共有をしながらビデオ通話によるサポートも行います。スケジュール調整には、TimeRex を利用しています。

副業とは申し上げましたが、始めて10ヶ月ほど経過で、稼ぎとしてはまだまだ駆け出し状態です。

しかしながら、人に技術を教えたり、発生している問題の解決方法を提示したり、解説したりすること自体は、私は苦にならないため、メンター業は向いていると考えており、今後も活動を継続していきたいです。

今後もっと活躍していきたいです。

肩書をミックスしてみます

  1. エンジニア × コミュニケーションスキル
  2. エンジニア × 哲学
  3. エンジニア × オカルト
  4. エンジニア × メンター

現在の私が掛け算できるキャリアは以上です。

元々本業につながるものから、一見全く接点のなさそうなジャンルまで、こうやって言語化してみると、案外つながります。

実際、新規事業や企画を立ち上げる際や、基礎をマスターした後に突き抜ける際に、これらの掛け算が役に立ちます。

点と点を線で結ぶような感覚に似ています。その感覚は、非常に爽快感がある体験になります。

「エンジニア」という言葉や最初からマネタイズに囚われすぎず、インスピレーションを得て、続けられるものを掛け算してみることを勧めます。

では、肩書を作ってみます。

コミュロソフィ―・オカルトメンター エンジニア

(Comunication + Philosophy = comulosophy = コミュロソフィー 勝手に作った造語)

そのまま繋げてみました。っぽいような気もします。

せっかくなので、AIにも手伝ってもらいましょう。ChatGPTに投げてみました。

「エンジニア、コミュニケーション、哲学、オカルト、メンター これら5つのキーワードは全て含めて、ロマンシングサガ風の連携技のような肩書のアイディアをいくつかあげてください」としたら以下が出てきました。

  1. メンタルマギテック・フィロソフィカル・サイバーエンジニア
  2. オカルティック・テクノコミュニケーション・ソーサラー
  3. レガシー・インテリジェント・コミュニケーション・エンジニア
  4. メタファイジカル・ネットワーキング・マスターメンター
  5. デジタル・フィロソフィカル・オカルト・マギティシャン

なんだか本当に連携技のような感じで出てきました。

ロマサガから連想してファンタジー要素が強すぎました。

「ファンタジーの世界観は外して、もう一度」としたら以下になりました。

  1. メンタル・コミュニケーション・マエストロ
  2. 哲学的オカルト・テックウィザード
  3. エンシェンテッド・コミュニケーション・エンジニア
  4. オカルテック・メンタリスト・エンジニア
  5. フィロソフィカル・マスターメンター・オブ・エンジニアリング

イマイチしっくりこないので、結局「コミュロソフィ―・オカルトメンター エンジニア」とします。

おわりに

私事から掛け算の話へ、そしてオカルト的ななにか話とほか諸々からのChatGPTという、現在の私の頭の中を吐き出してみました。

テーマは「エンジニアキャリアについて、あなたの考えをシェアしよう!」でした。

精一杯、私の考えはここに言語化しました。

読んでくださった人が何かの参考になれば幸いです。

参考にならなくても、こんな考えの人もいるんだなと思ってもらうだけでもこれ幸いです。

それでは、本稿はここまで。

よい、エンジニアライフを!

4
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?