優秀なエンジニアの条件
優秀なエンジニアとはどういったものなのか、どうなんでしょう、皆さん。
急にテーマがでかいですね。
優秀なエンジニアね。
いや、まあ、いろいろあると思うんですけど、最近ちょっとバズっていた記事で、
エンジニアが事業で勝つための概念整理のスキルについて、事業開発の現場で学んだ技術と事業をつなぐ思考法っていうノートの記事がちょっと話題になってたんで、
ちょっとこれを題材に今日話したらなと思っております。
はい。
この記事を軽く説明すると、前置きとして、最近のエンジニア、ウェブエンジニアは技術力で勝負がつかないよねっていう話が展開されてまして、
いろいろウェブサービスあるけど、機能として見たときには大体同じような機能が実装されているので、大きな違いがないですと。
いろいろ技術も発展してきたんで、特別衛星を飛ばしたり自動運転をしない限りは技術力だけでエンジニアとして勝負が決まることはないですよね。
じゃあそんな時代の優秀なエンジニア何ですかっていうことで、この人は課題を特定し、解決策を提示し、それを仕様に落とし込めるエンジニアが優秀なエンジニアと呼ばれるようになっていくだろうと考えてますっていうことを言ってるんですね。
技術だけじゃなくて、事業についてもちゃんと関わりを持っていって、技術とかエンジニアリングだけに限らずもうちょっとビジネス寄りの知識を持った上で、
ちゃんと事業と技術を橋渡しするみたいなことができるエンジニア優秀なんじゃねって感じなことを言っておりました。
技術だけじゃなくて、ビジネスについてもちゃんと知識があって関心があるようなエンジニアになりたいって言っている人はよくいると思うし、僕もそうなんですけど、
そう言ってるのって確かにここの記事で言っている通り、あんまり自分自身が技術力一本で割と差をつけるイメージっていうのは湧かなくて、
勉強とか続けていくつもりなんですけど、いろんな時代背景から差をつけるのは難しいかなと思っていて、
そうなってきたときにやっぱりより会社にとって価値がある方向は何なんだろうって考えるときに、
もうちょっとビジネス寄りのことも視野に揺れた上で実装の仕様を決めたりとか、デザイナーとかプロダクトマネージャーと話していろいろ交渉をして、
この機能こっちの方向でやった方がいいんじゃないですかみたいなことを言えた方が将来的により価値の高いエンジニアになるんじゃないかなって思ってたんで、
すごい全体的に共感できたんですけれども、お二人はどうでしたか。
概念整理の重要性
すごい自分もこれは共感できました。今の時代って元エンジニアで会社でかくして成功してる人って結構いるなと思ってて、
そういう人ってやっぱりエンジニアリングのスキルもあるし、事業の概念性のスキルもあるしっていうので、そこをうまくつなげてるからこそ成功してる人たちがエンジニアの人たちが増えてきてるのかなっていう気もしてるんで、
実際の現場見ててもこういうスキルある人が成功してるっていうのは実際出てるのかなっていう世の中の例としていうのは思ったりする。
チーズさんはどうでした。
この記事を読んで、エンジニアリングっていうものに対してのドメインモデリング力っていうものの貴重さが上がってきてるのかなって思ってて、
最初言ってた課題を特定し、解決策を提示し、それを仕様に落とし込めるエンジニアって言われた時にあんまりピンとこなくて、
ただその下に書いてある要件定義に必要な概念整理のスキルであったりとか、その境界とトリガーの話にはすごい理解できてて、
何が一番大事かなって思った時に、仕様を機械に伝わる言葉で話せるっていうか、それをPDMとも連携が取れる、そういうつなぎ込みができるエンジニアが貴重なのかなって思ってて、
それどうしたらできるかなって考えた時に、やっぱドメインモデリング力であったりとか、正しく指き足す言語を定義して、そのPDMとか関わる人たちが正しい会話ができる状態を作り上げる、そういうエンジニアが貴重なのかなって、この記事を読んでて思いました。
たしかに、言われて思ったけど、今チーズが後半で言ってたものは、どの場面のエンジニアにとっても大事かなと思ったんですけど、チーズがあまり分からなかったって言っていた、課題を特定し、解決策を提示し、それを仕様に落とし込めるっていうのは、確かに言われてみると、それがそもそもPDMの仕事なんだよみたいな気も聞きながら思って。
僕がこれに共感した理由は、たぶん小さい会社とかスタートアップで働いた経験が多いから、この部分に共感できたのかなと思ったんですけど、それより前の経験だけに限って、大きめの会社とかエンジニアとしてのチームが何個もあるような会社の経験だけを元に考えると、この辺ってあんまり必要と、ゼロとは言わないけど、そんなに重要じゃなさそうかもなとか思ったりした。
大事ではあるけど、そこが根幹じゃないなってこの記事にビョンって思った。
なるほどね。
それこそだって、なべちゃんも今独立して会社をやっているから、課題を特定し、みたいなところがすごい共感できたのかなみたいな。
これはすごい刺さるね。自分が今まさにやっているところであるから、自分でサービスを考えて、それを仕様に落としてって作っていかないといけないから、このスキルがないとそもそもやっぱり戦えないよね。全部自分でできないといけない。
そうだよね。
確かにちょっとね、2人の立場が違うよね。私が働いている場所がさ、結構大きめの2Bサースを運営している会社ってなると、たぶんここの1行においての捉え方全然違うなと思ってて。
それ想像したときに確かに違うなと思って。もちろんなんか、技術的なコードベースの塞いからくる課題とかがあったら、もちろんそれを特定してどうのっていうのはあると思うんですけど。
はいはい。
ビジネス的な直接的な課題を特定してどうのっていうのは、あんまり会社の規模によってはエンジニアとしては役立てるところはないかなって思ったりしたね。
2Bサービスにおけるモデリング
このね、記事の主軸が概念整理だからね。そういう意味では、一番ベースにおいてところは仕様に落とし込めるエンジニアっていうところなのかなと思って。
確かに。
機械とのコミュニケーション、PDMとかその他のコミュニケーションの部分にすごい重視している記事だなって。
そうなると、多分モデリング的な部分が重要なのかなっていうのが、その請求書の作成管理の例が書いてあって、すごい思った。
なんか、すごく最近、やっぱこういう結構近しいプロダクトを、この記事の執筆者さんと近しいプロダクトと向き合ってるような立場だと思うんで、私が一番ね、この中では。
そういう、業務に携わるto-be-susみたいな意味では。
いや、間違いないですね。
なんか、それで仕様の擦り合わせがものすごく重要っていう部分は本当に感じるんだよね。
いや、あるよね。
しかもその時に、ビジネスじゃないや、プロダクトマネージャーが思っていることを引き出して整理するっていうのもそうだし、
今後、PDM的に将来どういう機能を実装したいかとかいう将来像も聞くと、さらになんか実装した方がいい方向性変わってくるとかもあるもんね。
そういう展開というか、そういう将来設計のプロダクトの設計があるんだったら、今ここで細かいこういう実装するよりも、もうちょっと将来の拡張性を見据えた上で、こうやって情報整理するのどうですかみたいなのは、確かに日本の会社にいた時に話していたような朧げな記憶。
朧げな記憶。
そういうところ結構大事で、特にこういう2bisはず系って、携わるドメイン理解であったりとか、ドメイン知識とか、それをどのように機械の形、データベースの形であったりとか、モデリングしていくかとか、どう設計していくかってすごく大事だから。
それって私2c開発していた、2cのバックエンドやってなかったんだけど、ともそも2cの表面だけやっていく上ではあんまり携わらなかったんよ。
深くまでドメインのモデリングをする必要性っていうのが最初はわからなかったんだけど、本当にまさにこの記事で言ってる通りのエンジニア視点とユーザー視点っていうところの会話の例題、めちゃくちゃいい例題なんだよね。
なるほど。確かに僕2bサービス開発したことなくて2cサービスだけなんだけど、なんかちょっと考えてるのは確かに2bのほうがそのモデリング大事なんですかね。なんか2c系のサービス、自社開発でアプリとかサービス作ってますみたいなやつだと、
なんかどっちかっていうと、外の世界に初めからやりたいことが存在してるっていうよりかは、自分たちのプロダクトのビジョンから自分たちのやりたいように、やりたいようにという言い方が100%正しいのかわからないけど、自分たちの決めたルールの中でどんどんどんどん機能拡張していけるから、モデリングとか大事なんですけど、
なんか割と自由に後から修正聞く部分もあるかなと思ったんですけど、確かに2bの場合とかだと、そもそも既存の社会に解決したい課題とか複雑な課題があって、それをうまくソフトウェアの力で解決するってなったときに、その現実世界と自分たちのプロダクトの中身をつなぐモデリングって、なんか2cサービス以上に大事だし、そこで間違っちゃったら後からより苦しむのかなというふうに、
チーズの話を聞きながら想像して、いや確かにこれはチーズさんの仕事大変そうだなぁと思いました。
2cでもいろんな色付きあると思うし、継続的にお客さんが入るところで、単発的化とかで設計とか変わってくるし、2bサービスの中でも、どの業界に投じるサービスなのかによって、そのモデリングの重要さは変わってくるとは思うんだけど、
私は結構、お仕事全般みたいな、カバーするようなサービスとか、請求書の作成とか管理の例題、めっちゃ響くものがあるんだよね。
概念整理の重要性
なるほどなぁ。僕、この具体で読んだ時に、なるほどそういう例もあるよねぐらいで、まぁまぁぐらいの感じだったんですけど、確かにそうやって考えてみると、一旦この辺りに関わってから読むとさらにここへの共感性、共感高くなるのか。
めっちゃ高いね、これ。
今、そういう話を聞いて、マジですごい刺さってきた。今さ、自分は2bのシステムを作ろうとしてるから、課題を自分で設定しちゃってるというか、細かく聞いてるわけじゃないから、実際のお客の人たちに。
だから多分こういう課題あるよなぁとか、こういう風にしたらきっと多分役に立つよなぁみたいな、自分で思う課題ベースで2bのシステムを設計しようとしてたけど、確かに今話聞いて、確かに社会的にもこういう課題とかが多分あって、お客さんとかもこういう課題があってっていう声は聞くけど、改めてモデリングし直した時に本当にそれいいのかみたいなところが、全然考えられてなかったなっていうちょっと反省をしました。
おぉー。
なんかね、多分2bのそういうプロダクト提供する上で、ユーザーさんが自分が提供したいプロダクトに携わるまでの過程であったりとかを正しく整理しないと、それこそ概念整理をしないと、何かしら設計する上で抜け漏れると思うんだよ。
なんかそこの携わるものをフロー化してドメインモデリングとして落とし込んで設計していった方が抜け漏れなくできると思うし、それをPDMっていう立場の人いないと思うけど、まだスタートアップ時点で。
自分自身がPDMみたいな状態になると思うんだけど、会話できる状態の土台を整えるっていうのはめちゃくちゃ大事だなって、それを身近に得意としている人がいるんだけど、その人の仕事見てるとやっぱすごいし、それがドメインモデル図があってやっと理解できたっていう部分とかめっちゃあって、よく眺めてる普通に。
へー、なるほどね。
だからそういうの本当大事だなっていうのは、なんかこういう2Bの、特にお仕事にまつわるプロダクトを作っている上ですごい実感したから、この記事の概念整理であったり、そういう概念に対する設計に対しての重要度っていうのは、
なんか以前より、まあエンジニアになったっていうのもあるけどさ、なんかすごい実感する部分があって、だからこそ自分は最初のタイトルで書いてある優秀なエンジニアとはのところで、なんか課題を特定し、解決策を提示しっていうのは大事なんだけど、それ以上に主要に落とし込めるエンジニアが優秀っていうのを後ろの後半のところにすごい共感したできた立場なのかなって思ってる。
なるほどな、面白いな。いやでもこれ今回の話でもしかしたらラブちゃんの今後の会社の将来が大きく変わったかもしれない。
ユーザーリサーチの実践
チーズの。
変わったかもしれない。
めちゃくちゃある。
ラブちゃんのおかげで。
いやめっちゃあると思うよ。なんかこのまま言ってたらね、自分がこういうの欲しいからこういうの作ろうみたいな感じでさ、課題とかあんま考えずにさ、バーって作っちゃってもらいたいけど、なんか改めてこうドメインモデリングに落とし込んでどうかなみたいなちょっと考えていくと、いろいろ見えてくるものはありそうだし、ちょっとやってみます。
ラブちゃんはさ、今から作っていくプロダクトを提供するとするじゃんね。その利用者に近しい仕事であったりとか、報道ってやったことある人なの?
それはあるね。
それはあるんだ。
じゃあそれで自分のペイントかでも落とし込めるかもしれないね。自分がどういうアクションをしてきてみたいなところを整理できそうだから。
それがなんか仮に事実じゃなくて想像?ラブちゃんの想像になっちゃった場合、かけ離れてしまう可能性があるから、ちゃんとそれのプロとしている人がどのような仕事をしているかっていうのは、ちゃんとリサーチした上で、むしろそういう協力者を募って、そういう人とタッグを組んでプロダクト作りをしていったほうがいいんじゃないかなって思ったりした。
ありがとうございます。
めっちゃいいアドバイス。
未来変わったよ、多分。
ITトリオ。
事実と想像は違うからね。
違うね。
もともとリサーチャー的な部分を目指してたことはあるんだけど、なんかその人が丸々したいとかって、なんだったっけ、黒い皿のやつ。
黒い皿?
黒い皿。知らん。初めて聞いた。
黒い皿じゃないか。黒くて、違う、白くて丸い皿だっけ?違う、黒くて四角い皿だっけ?
銀の皿?
違う。また忘れた。
なんかそういう比喩があるってこと?
黒の皿って調べても、内装黒の皿、すしろ黒の皿しか出てこない。
何やっけ、ちょっと待って、ユーザーリサーチ的な話でよく出てくる、なんかユーザーは、なんか言葉では、なんか黒くて四角いお皿が欲しいとか言いつつ、
なんか本当に黒くて四角い皿と丸くて白い皿並べてたら、みんな丸くて白い皿を持っていったっていう話があるんですよ。
あったあった。
あった?なんだったっけ、黒くて四角いで合ってた?
抽象と具体のバランス
丸いお皿と四角いお皿で、丸いお皿、四角いお皿が黒で、丸いお皿が白か。
なるほどね。
まあ、顧客は自分の真のニーズを言語化できないということで、
そうそうそう。
実際に話をしてみて、黒くてかっこよくて四角いお皿が欲しいよって言っていたから、言っていたんだけど実際に、
いろんなお皿を並べて、好きなやつ持って帰ってくださいってなると、結局人気だったのは、白くて丸いお皿だった。
そうだね、普通のお皿が人気だった。
なるほど。
そんな感じで、なんだかんだ丸々したい、丸々欲しいとか言うけど、それって根本的じゃないから、
潜在的なニーズを引き出すためのリサーチをしていく必要はあるかなって、なべちゃんの話聞いて思った。
そうだね、それはあるね。
よく聞くのはマクドナルドの例で、サラダとかヘルシー向けのバーガー欲しいよみたいな要望がよくくるけど、
それを出すと全然売れなくて、結局ビッグマックとかそういう重たいやつが売れるみたいな。
確かによく聞きますね、それ。
よく聞くやつだね。
よく聞くやつね。
モデリング自体とは違うけど、それも確かに新しくサービス作るってなったらすごいその考え方も大事ですよね。
そうだね。
これはね、どっちかというとエンジニア、有志なエンジニアというよりかは、そういうプロダクトを作っていく、
その、なべちゃんみたいな人であったり、PDMの立場として。
確かに確かに、エンジニアという観点で言うと確かに、どれだけ仕様に落とせるかめっちゃ大事だね、確かに。
結構難しいよね、どっちも。
最近さ、PDMとお仕事することも多くて、それこそ若干デザイン側の業務を携わるようになったから、
そのPDMの研修とか顔出すこともあって、言葉にするのも難しいなってやっぱ思って。
そういう、モデリングしっかり自分たちが作っていくプロダクトを正しく言語で説明するってめっちゃむずいなって。
いやー難しい。
感覚ではそうなんだよね、みたいな。だったりとか、客観視点伝わらない言葉を使ってて、
あ、説明が足りなかったなとか、なんか思うことも多くて。
うーん、あるね。
なんか、そういうのを言語化するのって、ちゃんとそのものについての深い理解がそもそも必要っていうものもあるし、
なんかそれを人に説明するときにうまく言語化するのも難しいのがあるのかなと思う。
最近この記事も読んでちょっと思ったのが、また別で話題になってた記事で、具体と抽象を行き来するということみたいな。
はいはいはい。
話題になってて、なんか僕、うまく物事を理解した上で人に説明するときに、具体と抽象の良いバランスをとって説明するのすごい大事かなと思って。
なんか、例えば今回の放送で言うと、多分前半の方ってちょっと若干抽象的な話が多かったかなと思って、
この記事を読んで絵を上げた後にそれぞれの意見を話したんですが、その意見の中で多分あんまり具体的な例は最初の方は出てこなくて、
この話の流れでここに共感した、自分のこういったような経験というか学びがある過去に共感したっていう話をした後に、
なぶちゃんの授業の話とか、ユーザーリサーチの後の話とかで具体的な例を出して、いろいろ論じたと思うんですけど、
人に何か説明したり話したりするときって、具体例を1から10までただ並べるだけじゃあんまり理解されないしうまく説明できないし、
かといって抽象的な話だけをどんどんしていれば多くの人が理解できるかっていうとまたそれも別で、
なんで、その間の抽象的なジェネラルな話とかまとめたものと、その中のいくつかの具体例をうまく織り混ぜて人にアウトプットするっていうのは、
なんかすごいいろんなところで大事になってくるのかなみたいなのを思ったりしたんですよね。
でもなんかそういう抽象的な話って話せば話すほど難しい気もしているから、
いろんな人がそれをできるかっていうとまた別の話だとは思うんですけど、
なんかそういったことを。
なんか小倉くんの言ってたそれができるようになるために、たぶん知識があるレベルじゃダメだと思ってて、
ちゃんと理解してて言葉で相手がどのような情報を求めてるかも考えながら言葉にできるっていうところだと思ってて、
それってちゃんと理解しているっていう状態までいってないといけないかなって思ってて、
最近なんかそのさっき話したPDMの研修で話していて、
なんかドメイン知識って言葉は使いませんって。
それは知識があるだけで理解してないから、
ドメイン理解まで必ずドメイン理解っていう言葉を使うっていうのがある。
今記事送ったんだけど、
それ自分の中ですごい響いたんだよね。
私めっちゃドメイン知識って言葉作ってたから。
確かに、理解が必要ですね。
知識の整理と理解
話しながらなんかなんとなく受験を思い出してきました、僕。大学受験。
受験とか就活とか思い出したんだよね。
問題を、練習問題とかをいろいろやって、要するにやるだけじゃダメで、
ステップとして分かる、解ける、かけるみたいな。
単純に何か分かった気になるんじゃなくて、実際に解けますか。
解けたら理解できてますね。
それだけでもダメで、ちゃんとそこから自分の言葉でアウトプットできましたが、
アウトプットできるんだったらさらに自分の中で理解が進んで知識が整理されていますねみたいな。
単純に物事を知っているから人に説明できるの間には結構理解のグラデーションがあって、
その辺りがすごい、大学受験の時の気持ちと今回のトピックすごい自分の中で結びついて、
懐かしい気持ちになりました。
人に説明する時ってさ、自分の自己理解とかも大事なんだけどさ、
相手のことをどれだけ知ってるかも結構大事だと思ってて、
相手の前提、どこまで理解してるかとか、
その前提条件によってどこまで伝えたらいいのかどうかみたいな、
伝えすぎても説明が長くなっちゃって、結局何言っちゃうか分かんないし、
相手がある程度理解してるところからかいつまんで、そこにピンポイントで説明できないとやっぱり、
ちゃんとスッて理解してもらえないから、やっぱりそういうところが大事なのかなっていう。
人とのコミュニケーション
確かにね。
大事だわ。
求めてる相手のケースによって、引き出せる言葉を変えることができるって、
相当な理解が必要だと思ってて、
確かにな、なんか今の話は塾講師の仕事をしてた時のことを思い出しましたわ。
似てるよね、構図がね。
しかもなんか人に話そうとすることで自分自身の理解も深まるみたいなことも、
その頃言われていて、
確かにそれは今のトピックでも同じことが言えるなって、
なんか全部似てるなって思った。
確かに確かに。
なんかね、学生時代意外と大事だったんだな。
そうだね。
大事だったね。
やっぱなんか、もう学生終わってから5年以上経ちますし、
大学受験から数えたらもう10年ぐらい僕は経つんですけど、
思わぬところで聞いてくるものがあるので、
もし今日聞いている学生の方がいたら勉強頑張ったらいいと思いますね。
絶対身になるってことが分かったね。
大事だと思う。
なんか基本を詰まってるよね、本当に。
なんか知識そのものって言えるから、
それを知識を自分のものにするためのプロセスそのものがこう、
世界に出てから遠回りで役に立つみたいな感じですかね。
確かに。
まあなんか、勉強を続けていかなきゃなと思いましたし、
やっぱり人と話すことで理解深まるなっていうのも話しながらも思ったんで、
このITツールの日常に感謝しながら今後も生きていこうと思いました。
まあそんな感じかな。
ということで、この番組を気に入っていただけた方は、
Spotify、Apple Podcast、YouTubeなどで番組のフォローをお待ちしております。
そういえば最近合計のフォロワーが1000人超えましてありがとうございます。
ありがとうございます。
まだレビューとかしてない方がいたら是非いろんなプラットフォームでレビューもよろしくお願いします。
お便りも募集しています。
放送の概要欄にあるリンクからどしどし送ってください。
Xで関数を測る場合は、ハッシュタグITTRAILERでお願いします。
お祝いコメントも是非お待ちしています。
それではまた次回お会いしましょう。ありがとうございました。
ありがとうございました。
