1. エンジニアストーリー by Qiita
  2. #006 ミノ駆動さんと考えるエ..
2022-10-21 21:26

#006 ミノ駆動さんと考えるエンジニアの未来〜健全な技術を進展させていくために〜

READYFOR株式会社にてバックエンドエンジニア/アプリケーションアーキテクトを務めるミノ駆動さんがゲスト。『良いコード/悪いコードで学ぶ設計入門 』著者のミノ駆動さんと番組ホストの清野隼史が 「エンジニアが発揮できる価値」「エンジニアの生存戦略」「エンジニアコミュニティへの貢献」といったテーマでお話しします。

<ミノ駆動さんのQiitaページ>
https://qiita.com/MinoDriven
<Twitterハッシュタグ>
#エンジニアストーリー
<メッセージフォーム>
https://forms.gle/ZgRruUzqG6b8DGNCA

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:00
今回のテーマは、「ミノ駆動さんと考えるエンジニアの未来」です。
前回、前々回と続いて、ミノ駆動さんにいろいろお伺いしてきましたが、
今回は一緒にエンジニアの未来についてお話しできればなと思っています。
今回もゲストには、良いコード、悪いコードで学ぶ設計入門、
著者でReady for株式会社のミノ駆動さんにお越しいただきました。
ミノ駆動さん、よろしくお願いします。
よろしくお願いします。
では、今回はミノ駆動さんと一緒にエンジニアの未来について、
いろいろお話しできればなと思っています。
まず、未来についてお話しする前に、ミノ駆動さん、
エンジニアとしてのキャリアも結構長いと思うので、
最近のエンジニアコミュニティ全体に対して感じていることだったりとか、
エンジニアとして活動している中で感じた変化とか課題みたいなところがあれば、
まずお伺いしたいです。
あくまで自分の観測範囲にすぎないと思うんですけども、
僕含めて、僕以外にも著名なエンジニアの方が、
例えばメイクロ設計だったりとか、
そういう普及活動を有志にされてきて、
ようやっとこの10年、10数年ぐらいで、
少しずつ設計っていうものがだんだん浸透してきたかなっていうような肌感はあります。
ちゃんと単に機能開発だけじゃなくて、
ちゃんと品質を考えて技術的不採用を作り込まないようにとか、
いうことを考えてやっていくっていうのが、
じわじわ広がりつつあるかなっていう印象ですね。
10年、10数年ぐらい前から、
リーダブルコードっていうコードがあって、
あの本っていうのは、例えば主に命名だったりとか、
家族性を主軸にした本で、
ちゃんと命名とかしっかり考えて書きましょうねっていうところにはリーチしてる内容であって、
そこはファーストステップとしては、あれはあれですごく良かったなっていうふうに思ってましたけども、
構造的な部分、例えばメソッドだったりとか、
クラスをどういう構造にするかっていうようなところまでしっかりやりましょうっていうところは、
自分の観測範囲では今に比べてまだ不十分というか認知度がまだ低いような状態であって、
ただそれがいろんな著名なエンジニアさんの活動によって、
それがだんだん認知度が高くなってきたかなっていう印象ではあります。
ただ、まだまだ足りてないという感じだと思います。
テストコード書いたりとか、テストしやすいようにクラス設計するとか、
ビジネス概念をちゃんと解釈してそれをモデルに起こしていくっていうようなことを
広くやられてるかっていったら、まだまだそれはやられてはいないんじゃないかっていうふうに思ってて、
03:02
実際それっていうのが経済産業省の資料にもあって、
2025年までには、額はちょっと忘れちゃったんですけども、
国家予算に匹敵するぐらいの経済的な損失が技術的負債によって発生するっていうようなレポートがあって、
石鹸がちゃんとどこでも普通にやられてますっていったら、そんな数値が上がってくるはずがないんですよ。
っていうことは、まだまだ全然我が国としても、
広く改善しなきゃいけない装置はまだ全然あるんじゃないかなというふうな認識であります。
まさに今の現代の設計だったり、そこら辺のフェーズって、まず課題を全員認知している状態な気がしてて、
前はそもそもその課題を知らなかった、そういうもんだっていう状態で住んでたのが、
もっとやっていかないといけないよね、だけどやれてないっていう状態が今の気がするので、
次は多分その次のステップとして、じゃあみんなでやっていこう、やんないとダメだよねっていう状態に
持っていかないといけないってことですよね、多分。
そこでぜひ未来についていろいろお伺いしたいなと思うんですけど、
まさにそういう設計のところももちろんそうだと思うんですけど、
エンジニアを取り巻く環境ってどんどん変わってきていると思うんですよね。
最近って静的な、リンター的なところもすごい賢くなってきていたりしますし、
あとはGitHubコーパイロットみたいな、そういうツールとかも出てきていたりするので、
コードを書くこと自体がどんどん効率化されていったりとか、
ちょっと言い方あれですけど、適当に書いてもきれいなコードにどんどん直していってくれるような仕組みがどんどんできているので、
そこをしっかり考えていくというよりも、やっぱり何を作っていくかみたいなところに
最近エンジニア自体は時間を使うようになってきている気はするんですよね。
その中で、ただプログラミングをするだけではない、他の変わらないエンジニアの価値って何なんだろうっていうのは
結構僕も何なんだろうなと日々考えることがあって、
エンジニアだからこそ、人だからこそできることとか、今後バズワード的なところで言うとAIみたいなのを
最近よく言われたりすると思うんですけど、
そういうのには奪われない、自分たちだからこそ発揮できる価値って何なのかというところを
ぜひミノクドウさんのご意見を伺いたいなと思っています。
難しい話ですけども、結構そのエンジニアの未来っていうか、
未来何が起こるかってちょっと分からないっていうところがあったりとかするので、
トレンドの何が口に来るかっていうのを予測できない不確実性っていうのもあって、
それどうなっていくんだろうとか、急にある技術が出てきて、
それが結構働き方のイノベーションを起こしたりとか、
今までのやり方を全然変えてしまうっていうものもあったりとかするので、
一概にじゃあ我々の未来を、未来でどう考えればいいんだろうっていうところが、
僕としても言及しづらい部分はあるんですけども、
06:01
自分の考えるところだと、
ソフトウェア工学的な基礎の部分っていうか、
画法技術的な基礎の部分っていうところは、
基礎っていうのはあまり変わらないから、そこを大事にしていくっていうか、
そこを深く学んでいく必要はあるんじゃないかなって思っています。
なんでそんなこと言うかっていうと、
例えばフロントのフレームワーク知識ってものすごく日進月歩で、
すぐにフロントの技術って陳腐化しやすい。
せっかく実装するために覚えた知識っていうのが、
古くて使い物にならなくなってしまう。
全然使い物にならなくなってるわけじゃなくて、
もちろんフロントをどういうふうにして実装していけばいいんだろうっていうような、
共通的なスキルとか知識っていうのはもちろん残っていくと思うんですけども、
フレームワーク特定の知識っていうのは、
ある種陳腐化次第捨て去らなきゃいけないっていうところがあったりとかして、
どうしても寿命年は長くないっていうそういう欠点はありますよと。
ただ、エンジニアの生存戦略的な話し方にちょっとなってしまうと思うんですけども、
結局ソフトウェアで解決したいことって一体何なのっていうようなところっていうのは、
それはソフトウェアっていうものが登場して以来、
それは僕は何も変わってないと思っていて。
それは何かって言ったら、別にソフトウェアに限った話じゃないんですけども、
テクノロジーっていうのは人間の能力を拡大縮小するためにある。
何らかの目的のために。
例えば、どっか目的地に移動するっていうことに関しては、
人間は太鼓から二足歩行システムになるものを使ってきたわけですよ。
自分の人間の足を使って。
でもそれじゃ遅いと。
だからその代わりになるものとしても、
例えば馬車だとか、もっと時代は進んで、
例えばそれが自動車とか、電車とか、飛行機とか、
そういうより早く、より遠くにっていうようなシステムが編み出されてきたわけですね。
だから自分たちの作っているテクノロジーって言ったらいい。
我々が使っているソフトウェアっていうのも、
何かしらこうしたいっていう目的があって、
その能力をスケールアップさせるためにシステムを作ってるんだっていうことは、
それは絶対忘れちゃいけなくて。
例えば商品の売り買いにしても、
昔から実際に人と対面し、
現場でお金を渡して物をやり取りしてっていうことをやってきましたけども、
でもそれはAmazonさんとか楽天さんに代表されるように、
それをウェブシステム上でできるっていうシステムにすることによって、
わざわざ対面しなくても、
09:00
家にいながらでも商品を注文するっていうことが実現できてるわけですよ。
だからこそビジネスを理解する必要があって、
それをどうやったら目的を達成するために、
自分たちの強みだったり能力を拡大できるんだろうっていうようなところを着目して、
そのためにはどういうふうなテクノロジーって使えるんですかって、
そこに着目して技術を学んでいく姿勢っていうのがすごく大事だと思います。
だからそこさえ忘れなければ、
今現状の世の中ではどういうことが求められててっていうようなことを着目すれば、
じゃあそこの目的を早く達成するための技術って何なんだろうっていうようなところを、
自分で調べて、自分でそこに足りない知識っていうのを
自分で調べて学んだりとかってそういう歩みを、
知識を深めたりとかっていうような歩みを進めることができると思うんですよね。
だからそこを軸にしていけば、
キャリア的な話になっちゃうんですけども、
次一体何のフレームワーク技術を学べばいいんだろうだったりとか、
そういう迷いっていうのは低減できるんじゃないかなっていうふうに思いますし、
これからのエンジニアの未来どうなんだろうっていうのも、
僕が今言ったように、
自分たちが一体どういう能力を拡大させていきたいのか、
どういう目的を早く達成するためにどういう技術が使えるんだろうっていうようなところを
考えるべきにはなるんじゃないかなというふうに思います。
今現れてどんどん使いやすくなっていっているものって、
いわゆるコードをどう書くかとか、
実際に何かを作るタイミング、具体化されたタイミングがすごい、
その部分は効率化されていっていると思うんですけど、
そもそも何を作るのかとか、何を達成するためにどういう技術を採用するのかは、
やっぱり人間である僕たちエンジニアだからこそできるところ。
だからこそそこをちゃんと考えながら、
いろいろキャッチアップして勉強していって、
いろんなものを使ってみるというところが大事ということですね。
IT、インターネット業界に強い転職アプリ、グリーンは、
今話題のテック企業、プロダクト開発、DX案件など、
グリーンだけの良質な求人を数多く揃えています。
正式応募前に企業の中の人とカジュアル面談ができるので、
仕事内容やメンバーのことをしっかり理解した後に先行に進めます。
カジュアルに始める転職活動にグリーンをご活用ください。
ちょっと話題を変えさせていただくんですけど、
今のエンジニアのコミュニティって言っちゃうんですけど、
IT産業って過去のエンジニアの人たちの知識の発信だったりとか、
新しい発明というところによって作られてきていると思うんですよね。
聞いたお悲壮でもあるんですけど、やっぱり情報共有ってところをどんどんしていくことが、
次の未来のより大きな社会全体の成長につながっていくと思っているので、
12:06
そこをどんどん発信を増やしていきたいな、みたいなところは思ってはいるんですけど、
そもそもそういうところのエンジニアコミュニティに貢献をするのって、
なんでなんだろうっていうところをまずお伺いしたいなと思っていて、
ある意味で貢献活動ってちょっとボランティアっぽい側面はあるんですよね。
そこの貢献活動っていうのを、過去の人たちは事実としてやってくれていて、
そのおかげで僕たちは今いろんな技術だったりとか知識を発展させているとは思うんですけど、
そもそもなんでそういう活動を、
ミノクドローさんもQiitaでも発信していらっしゃったりとか、
いろんなところで発信活動していらっしゃると思うので、
ぜひそこのモチベーションみたいなところをお伺いしたいです。
やっぱりちゃんと、正しくと言いますか、
正しい思考作務ができるような場なんじゃないかなっていうふうに思います。
そういう技術発信するっていうのは。
やっぱり皆さん、エンジニアさんそれぞれって、
技術が皆さん得意不得意っていろいろあったりとかして、
自分の伸ばしたいスキルが、
まだ道半端で中途半端っていうところももちろん、
皆さんあったりとかすると思うんですよね。
そういう時に、自分たちの技術って、
自分が持っている技術だったりとか、
どう伸ばせばいいんだろうとか、
いうようなところっていうのは、
それはやっぱり何かしら、
ただ仕事やってればいいとか、
会社から言われたことをこうやればいいっていう頃だけでは伸ばせないと思います。
やっぱりそれっていうのは、
思考作務が必要だと思ってて、
やっぱり自分がトライしてみたい技術だったり手法があったりとかして、
自分はこういうことをやってみたとか、
それによって得られた結果ってこうだったみたいな感じのところを、
自分で考えて、
それをちゃんと言葉に表して、
発表してフィードバックを受けるっていう、
しかも会社以外の、
自分の会社以外の人たちのエンジニアの目に触れられて、
そのフィードバックを受けるっていうのは、
それは自分でどんなフィードバックを受けるんだろうっていうようなことも考えて、
いろいろ悩んだりとかすると思うんですよね。
もちろん周りから、
例えば聞いた記事を確認しても、
周りからどんな反応が来るんだろうみたいな感じで、
悩ましい部分もあったりとかして、
どういうふうにしたら自分の意図を、
自分がこういうふうに試しました、
自分はこういう解釈ですっていうようなことを、
どうやったら誤解なく人に支えられるかっていうようなところも、
いろいろ考えて、
頭つかで試さなきゃいけないっていうところがあったりとかします。
ここで大事なのが、
やっぱり人間って、
分かってることだけを言葉として表現できる。
自分が分かってないことって、
そもそも言葉で表すことすらできないんですよ。
だから僕もいろいろ記事書いたりとか、
自社もテクフォルムで書いたりとかしてますけど、
15:02
やっぱり分かってない部分だったりとかすると、
やっぱりあれって自分でどういうことを言いたかったんだっけっていう、
迷ったりする部分ももちろんあったりとかしますし。
だからそういう試行錯誤っていうのが、
ある種技術の発展につながりますし、
そもそもエンジニアリングって、
ニアリーイコール試行錯誤だと思ってるんですよ。
はいはいはい。
いわゆるビジネス的にこういう実現したいことがあって、
そのために技術をどういうふうにして使うか、
いろんな手法はあるけども、
どれを使ったら一番妥当かなとかっていうところを考えて
取捨選択していくっていうような行為そのものなので、
そういう試行錯誤をするために、
あれこれ考えたりとか試行錯誤自体が、
エンジニアとしての筋力をつける。
スポーツ選手にしたら普通に基礎的な筋力って必要じゃないですか。
それと同じように、
エンジニアがエンジニアがたるべきっていうか、
エンジニアリングしていくためには、
基礎としてまず試行錯誤をするっていう、
そういう脳の筋力って言い方するのもちょっとおかしいんですけども、
基礎力を身につけるためにはやっぱり試行錯誤ってすごく大事だと思います。
それがもちろん自社の中だけの記事として書き起こしてっていうことも
もちろんできると思うんですけども、
それだと結構やっぱりこう、
ある種ちょっとエコーチェンバー効果が働いてしまうっていうか、
同じような技術だけ持ってる人だけで、
そういう話が進んじゃったりとかして、
いまいちこう、
例えばそれが良くない古い技術を使ったりとかしたら、
それもブラッシュアップだったりとか、
フィードバックっていうのは十分になされないと思うんですよね。
それがちゃんとファブリックな、
いろんなエンジニアさんの目に触れられるようなところで、
いろんな反応を伺ったりとか、
いろんな人の目に触れるっていうことをやっぱり緊張感を持って、
言葉を紡いでいくってことになるので、
じゃあどんな言葉で書けばいいんだろうって、
頭を使ったりとかっていうこと自体が、
いろんなそういう、もちろんそういうことすること自体が、
技術が高まりますし、
試行錯誤の基礎的な力が身につくと思うので、
そういうKiitaさんの記事を書くとか、
技術発信していくっていうことは大事なんじゃないかなというふうに思います。
なるほど。
アウトプットってところ、
周りの人のためにってそこにもちろんあると思うんですけど、
どっちかっていうとエンジニアとしての、
成り割としてアウトプットっていうのはプロセスに入っているっていう感じなんですかね。
その試行錯誤っていうスキルを身につけていくためにアウトプットするし、
それ自体が新しいインプットにも自分のインプットにもなっていくしっていう、
その取り組みをしていく中でお互いに成長し合って、
ここまで今エンジニアリングっていうのは発展してきているみたいな感じなんですかね。
はい、だと思います。
ありがとうございます。
では最後にですね、リスナーの皆さんに井野九郎さんからメッセージあればいただければなと思うんですがいかがでしょうか。
エンジニアリングってすごく広いんで、
18:02
いろんな技術に触れてみたものを、
自分って何者なんだろうみたいな、何者になれるんだろうみたいな感じで、
すごく迷いがあるエンジニアさんもすごく多いと思うんですよ。
僕は僕でアーキテクトっていうのははっきりとした形として、
そこに向かって走ってはいますけども、
そうじゃなくて、じゃあ自分は一体どこに向かって突き進んでいけばいいんだろうっていうのに関して、
やっぱり迷いがあったりとかする部分も当然あると思います。
そこっていうのもやっぱり分からないなら分からないなりに、
言葉として表現するっていうのはすごく大事なことなので、
やっぱりそれは自分のノートに書いてまとめるでも、
もちろんそれでもいいと思いますし、
外に対して技術発信しようとして書いてるうちに、
だんだん考えが整理されてきて、
自分でこういうのが向いてるんじゃないかっていうふうに、
分かってくるような部分もあったりとかすると。
繰り返し技術発信していると、
やっぱり見てくれる人っていると思うんですよ、世の中に。
僕の場合はまさしくそうであって、
ツイッターでずっと設計とかリファクタリングのことをずっとツイートしてたから、
うちに来ないかみたいな感じの声がかかって、
転職の契機になったりもしましたし、
ツイッターで風刺動画を作ってたっていうことが契機になって、
良い行動、悪い行動で学ぶ設計入門っていう本を書くきっかけにもなったわけですよね。
だから何かしら発信してると、
ただ見る人がいるわけなんで、
そういう繋がりから自分のキャリアを変える、
それは代償ともかくとして、
いろいろ自分のキャリアにものすごく影響があると思うんですよ。
だからそういう面で、
やっぱりどんなちっちゃい頃でも発信していったりとか、
それに伴って技術発信、試行錯誤したりとかってするのは、
今言ったようにエンジニアリングとしての起走力がつくとか、
それから自分のキャリアはどっちに向けばいいんだろうっていうことを整理につながったりとか、
あわゆくは誰かが見てくれて、
それが自分の大きなキャリアの展開につながるっていうことにつながっていくと思いますので、
こういうことも書いちゃったら、
まさかに飛んできちゃったらどうしようなんてちょっと心配な部分もあるかもしれませんけども、
そこは勇気を持って一歩踏み出すことで、
また新しく世界が変わっていくんじゃないかなと思いますので、
例えばKiitaさんとかで技術発信していくとか、
そういうことをお勧めしたいと思います。
ミノクドさん3回にわたりありがとうございました。
ぜひ機会があったらまたお待ちしております。
楽しかったです。ありがとうございます。
ありがとうございました。
今回はミノクドさんと一緒に、
エンジニアの未来っていうところについていろいろお話しさせていただきました。
アウトプットの意味だったりとか、
それをやっていくことの自分自身の価値みたいなところもいろいろお伺いできたので、
ぜひリスナーの皆さんは今日きっかけにしたアウトプットみたいなところも
21:00
試していただけるといいなと思っています。
ミノクドさんとは前回、良いコードと悪いコードについて、
そして前々回は設計とエンジニアキャリアについてお話ししていますので、
ぜひこちらのエピソードもお聞きください。
さて、この番組では感想や質問、リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
ツイッターではハッシュタグエンジニアストーリーをつけてツイートしてください。
そしてAppleポッドキャストやSpotifyのポッドキャストではレビューもできますので、
そちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社はエンジニアを最高に幸せにするというミッションのもと、
エンジニアに関する知識を記録、共有するためのサービスKiita、
エンジニアと企業のマッチングサービスKiitaJobs、
社内向け情報共有サービスKiitaチームを運営しています。
ぜひカタカナでKiitaと検索してチェックしてみてください。
お相手はKiitaプロダクトマネージャーの清野俊文でした。
21:26

コメント

スクロール