こんにちは。言語化.fmは、あんな話やこんな話をキリンと伊達の2人で言う感じながら、言語化を試みるポッドキャストです。
はい。
やっぱ新年一発目だから語尾が長い感じなんですかね。
言えたーって思って。
言えた。確かに噛まずに言えたね。
そう。
最先がいいですね、今年は。
3回ぐらいちょっと敗北してたんで。
確かに。
はい、言いましたけど、今日はそうですね、あ、明けましておめでとうございます。
おめでとうございます。
はい、今年も。
いやー、だらだらやっていこう。
今年もだらだらやっていきたい。
ちょっとカッチリとかできないでね、我々は。
ゆるくやっていきたいと思います。
そうだねー。
これ言うとね、いやお前ら十分真面目やんって言われたことあるんだけど。
マジで?
うん。
あ、そう?
どう考えてもゆるいと思うんだよね。
そうかー、ね、どう考えてもゆるいっていうか、真面目にやれてなさすごい感じで。
真面目じゃないからね、なんか勘違いされてるみたいですけど、全然真面目じゃないんで。
わかんない、その方はもっと、もっとなんかわかんない、どろどろに溶けたぐらいのゆるさの人たちを見てるんだ。
なるほどね。
こんな日じゃないぞと。
わかんないけど。
わかんない。
語彙力もっとの、いやでも言語化、そのコンセプト的に真面目になっていく説はあるかもな、その、なんかさ。
コンセプトは真面目だよね、だって言語化しようなんてさ、真面目な人がやることじゃ知らないけどね。
だからなんか、オナズとちゃんと言語化していくことになるからさ、わかんないけどさ、ゆるさ突き詰めるとちょっと語彙力下げにいったほうがいいのか。
そうだね。
なんか。
あれがウェイで。
分かったよ、分かったよ、今度はゆるさを言語化しよう、そしたら。
この、このポトキャストのゆるさを言語化す会話。
ちょっとネタとに入れとくわね。
めっちゃおもろいな、いいね、やろう。
そんなゆるい感じで始まった新年一発目でございますが、今日は何でしょうか。
テーマ真面目だな。
テーマ真面目だね。
今日は完璧を捨てる勇気が大事かもという話を言語化していきましょう。
真面目ですね。
真面目ですよ。
真面目って言われちゃうよ。
はい。
はい。
今回は僕が、あの、これ僕とか言ってするじゃないですか、さすがにこういうのくびつくんですけどね。
僕が提案したんですけど、なんていうか、実体験的な話もありつつも、なんか自分の話ではないんですけど、
僕は結構不真面目な人間なんでどっちかっていうと、と自分では思っているので、こうなんか完璧に物をこうなすことはどちらかというと苦手なタイプなんですけど、
なんかお仕事とか日常生活において、なんか完璧にやろうとするがゆえに損をしているような人っていうのを結構出会っている気がしていてですね。
なんかその完璧、完璧に対する潔癖度合いをすればもっと、なんだろうな、他のことに有意見に時間を使えるんだけどなっていう風に、こうなんか狼狽しながらこう思うこともありまして。
例えばどういうことかっていうと、まあお仕事の面で言うと、なんだろうな。
えーと、やらなくてもいいようなリファクターをやってみたが、結果間違った方針でやっていたみたいなこととかがあってですね。
これ僕が直接関与しているものではなくて、また撃下話だったんですけど。
まあそういう話があったりとか、なんかあとは、仕組みとして、例えばCIみたいなものがあったときに、もう最初から全部整ってないと嫌だみたいな。
そういう潔癖さみたいな。
これはまあ個人によって考えは若干違うんだけど、もちろん結果としては全てがそういう風になっていた方がいいに決まっちゃいるんですけど、
でもそこまで持っていくプロセスを全部度外視している話になっちゃってて、結局それを整える能力だとか、
なんかそういうものを考えたときに、それは今やるべきじゃないよねっていうような合理的な判断ができるかどうかだと思うんですよ。
なんか、そこがすっぽり抜けちゃったまま理想ばかりを求めちゃって、結果本来時間を使うべきところに使ってませんみたいなことが起こりつつあるというか、
そういう事象にぶち当たっている人をちょいちょい見かけるようになってですね、
もっとより良くできそうだねっていうことを言ったこともありますっていう話。
それを突き詰めると結局は、みんなやっぱり完璧にやりたいんだなっていうのが、
100点を取りたいんだなっていうところもあって、それを言語化したいと思いました。
なんかだいぶしゃべっちゃった気がするけど。
いやー、でもなんか、特に僕らと同じくらいとか多くより、2,3年くらいだけキャリアが短いような人は多分絶対1回わさぼくしてる場面な気がするね。
すごいねー、苦い思い出が。
いや、苦い思い出って言ってたらあかんですけど。
これはだから僕らも踏んできてるんだよね。
そうだねー。
聞きながら思ったのは、なんか珍しく僕の中で言語化済みじゃないけど、ちょっと歩いてる言語化済みトピックに近くて、
思ったのは、シンプルに手段が目的になっちゃってる。
いくつかパターンあるかもしれないけど、一番最初に思いついたのは手段が目的になっちゃってるパターンがあるあるかなって気がしてて。
うーん、まあでも、例えばソフトエンジニアという仕事の話にスコープを食い入ったときに、さっきのリファクターの話とかCIの話みたいなのを100点取ろうぜみたいなときに、
この100点を取ろうっていう考え方を立てておき、それの先に何か真のゴールがあるわけじゃないですか、大抵の場合は。
仕事をしてるんであれば。事業でこういう機能が作らなきゃいけないとか、
CAとかだったらいろいろありますよね。デプロイを自動化して開発的な性を底上げしましょうとか。
そういう真のゴールがあるはずなんだけど、その真のゴールを達成するための手段として何点取るのっていう。
その結果100点が正解なら究極はいいと思うんですけど、そうじゃないパターンに陥ってるときも往々にしたるし、
大体今のソフトウェア開発の現実世界では、100点を取ることが最適解になることってまあそうそうない気がしてて、
結構ソフトウェア開発の強みって、スピードとか柔軟性とか、後でもすぐ直せるとかある気がしてて、
これがハードウェアの設計とか、家を建てる話だったらそれはもう100点取った方がいいんだけど、
なぜなら後から柱立て替えるなんて絶対無理なんで、厳密に言うといくつか後からパッチ当てられるかもしれないけど、
ソフトウェアより圧倒的にハードウェアが高いけど、ソフトウェアの強みはその後から70点と、
100点だけじゃなくて30点上乗せしやすい70点を取るとかっていうのもあるわけじゃないですか。
そのグラデーションの中で真のゴールがあって、その真のゴールにみんなで目線を合わせた時に、
じゃあこれがベターン選択したよねっていうのが僕的にはいい仕事の仕方だと思ってるんだけど、
完璧にこだわってる人はそのレールから外れてるから結構いい悪い話じゃないですか、
お互いに目線が揃わないっていうか、目的が違うから同じ言語を話してるようで全然違うみたいに落ちるのはすごいあるあるだよなーって気はするなーっていうのは
結構一定僕の中の一つの仮説としてはありますね。
なんか多分聞いてて、内的な要因と外的な要因が両方あるなと思ってて、
もちろんその人の気質とかによって何としても完璧に仕上げたいっていうような気質を持ってる人は確かにいるんだけど、
でもじゃあその人の気質が全てそうさせてるかっていうとそんなこともないと思ってて、
どっちかっていうと、例えば要はダイヤツがないから暇になっちゃってやってるみたいなところも多分あるんだよ。
プロジェクトが忙しければそんなことやってる余裕は普通ないので、
もうここは80点にとどめて次に行こうっていうようなマインドになりやすいじゃん。
だけどそうなってないのは本家の気質ももちろんあるが、結局プロジェクトのマネジメントがうまくいってないのではっていうようなところもあって、
そういう事象の人を見たときにそれをパッと思っちゃったんだよね。
面白い。確かにあるわ、そのパターン。何なら自分も結構気をつけないと落ちるなと思いながら生きてくわ。
あとは内的要因で言うとその人の解像度も結構あるなと思ってて、
プロジェクトを全部見えてる人からすると絶対そういう作業はしない方がいいんだけど、
その完璧主義に落ちちゃってる人のビューから見ると、実は例えばリファクタリングみたいなものが合理的に見えたからやっちゃったっていう。
でもそのリファクタリングは全体を見えてる人からすると、今からこういう作業をするはずだからそれはやっちゃいけないっていうふうな判断になっちゃうっていう。
確かにな。それこそ一番最初に、後出しみたいになっちゃうけど、一番最初にこのテーマを聞いたときに思ったけど、
局所最適じゃないけど、視野を広く持ててるかみたいな目線は絶対ある気がしてて。
そう、多分局所界の山を登っちゃってるって話だと思う。
さっきの俺が言ったのも多分、極論はそうな気がするんだよな。
そこのパーツだけ100点を取ることが目的ではなくて、
いやー、一周の全体像として何点を取るかっていう目線に立ててないと、何ていうか、それずれみたいな容易に発生する気がするね。
正解が何かって出すのはすごい難しいんだけど、少なくともチームとかプロジェクトとか会社がこれで何点を取ればいいのかっていうのはやっぱあるはずで、
これ全体で80点取ればオッケーのやつやでってときに、
なんか一人だけその局所界の山を登って100点を取りに行っちゃうみたいなことがやっぱり許されなくなっちゃってるよねっていうのはあると思うんで。
確かにね。
いやー、なんか何なんですかね。言うてもその局所最低の山を登りたくなる引力は結構理解はできるんですよ。
理解はできるというか、いやなんか僕は登らずに住んでるみたいな言い方をしちゃったけど、
その登りかけることはこの都市にとっても正直あるんですよね。
なんかさ、僕らはさ、もうブレーキかけられるじゃん、登っちゃいそうになったら。
ああいうの俺でやっちゃダメだっていう風な、なんかこれが何から来てるのかも多分掘っていくと面白いんだと思う。
そうなんだよ。なんでブレーキかけられるんだろう。
なんで僕らはブレーキをかけられて、彼らはブレーキをかけられないのかっていう。
うーん、まあでも視野は絶対あるだろうなー、なんか。
視野、パッと頭に思い浮かんだのは視野と経験だなー。
うん。
なんかその、いやーどこまで行っても一番なんだよなー。
まあでもなんか難しいな、これ言い過ぎるとなんかわかんない。
そうですね。その大義名分をもとに30点を取る人もいるから。
それをなんか、いやー、この他要はバランスおじさんにたどり着くの?
いやまあそういう年になっちゃったっていうのはあるけど、まあ結局はバランスで、
いやもちろん今の30点を取っていいのかって話は、これもまたケースバイケースなんだよね。
まあね。
一旦30点で置いといて、後で他のその依存関係を片付けてから、
その30点で済ませたところを一気に80点、90点まで上げるみたいな進む方法もあるじゃん。
うんうん、あるね。
っていう、なんだろうな、まあすごい小さい話で言うと優先度の並び替えなんだけど、
でもなんか構造的にもっと物事を見れると、そういうのがもっとやりやすいんだろうなって。
そうだねー。
うん。
いやーめっちゃ難しいなー。なんか頭の中ですごい考えたけど、
めっちゃいろんな観点で意外となんか向き合ってるなーっていう気がしたわ。
うん。
しかもこれ厄介なのがさ、昨日の判断は明日の判断じゃないっていうのがあって、
なんか特にスタートアップとかいると判断が一日でひっくり返るなんてことはまあ、
ザラじゃないですか。
ザラですね。
昨日は、昨日の時点ではこれを完璧に進めてもよかったんだけど、
今日の時点では、それはやっちゃいかっていう風なことになってることもあり、
そこを意外に何にクソ言わずに踏ん張れるかみたいなところもある気がするんだよなー。
確かになー。なんかちょっと散らかる予告をした上で、さっきぐるぐる考えたことを話すとなんか、
いやー。
なんか観点としてはまず、
いろんな突っ込みどころがあることを承知でザラザラと話すと、
一番大きな最終この課題を解きたいよねっていう課題があって、
そっからブレイクダウンしていって、いろんなちっちゃい課題があって、
その課題のうちの一つがソフトウェア開発だったり、試合の設定なのかもしれないし、いろんなものがあるけど、
一番上段の全部ひっくるめて、なるべく高い点をコスパよく取ろうよっていうのが、
まず共通目的にあるという前提で考える時に、
言うのがむずいな。
その観点をまず持ちたいよねって思ってるのと、その観点を持った上で、
局所と局所の取り組みで、どういう点をどういうふうに取ったら、上段の課題でいい点を取るってことになるんですかみたいなところが、
問いとして出てくると思うんだけど、
そこで弱バランスっていう言葉に逃げそうになるんだけど、
弱バランスってつまり何かっていうと、その時々で山のような変数があって、その中から適切なインジケーターを拾い上げて、
それぞれの観点をもとに、できればチームで開発してるんだったらチームの中で議論した上で、
今はこれがベターな選択肢だろうみたいな選択を細かく重ねていくっていうのが、
大枠としてはあるべき姿かなって思うのと、
でも一方でさっき言ってくれたようにさ、
今日と明日で真逆というかその意思決定がひっくり返るとか、事業方針が変わるとか、
それなんかいろんな大中小様々なことが起きると思うんだけど、
それにどう備えるのかみたいなところで言うと、
結構何の本で忘れたんですけど、
禁言だなと思ってることがあって、
一番いいアーキテクチャーは意思決定を後ろにずらせるアーキテクチャーであるみたいなのがあって、
どういうことかっていうと、
アーキテクチャー論の本だとアーキテクチャーっていう話をしてますけど、
これで行こうって決めたときに半年後に、
やっぱりちょっとこの観点で微妙だったなってなったときに、
首が回らない状態にならない方がいいに対して、
不可逆な意思決定とか、
身動き、取れる選択肢が減っていくような意思決定っていうのは、
なるべくなるべく後ろにずらせた方がいいよねみたいな、
文言の意図なんだけど、
これはアーキテクチャーに限らずいろいろ言える部分があるんじゃないかって気はしてて、
だからどっかのタイミングで言ったけど、
同じ70点を取れても、
70点取ってでもプラス30点取るのがめちゃくちゃしんどい70点の取り方と、
70点だけどプラス10点はもう、
エンジニアがちょっと手を動かせばめっちゃコスパよく取れて、
残り20点はちょっと工夫が必要かもねみたいな70点の取り方と、
その場の意思決定とかここまでこうしようっていうのをするときに、
後ろにじゃあ何か方針転換とか変数が増えたときに、
その理由図が効くような仕事の仕方というか成果の出し方あるんじゃないかなって気はしてて、
それはさっき言った大枠の下でそういうのを繰り返してくると、
大半の事業とか現場ではすごい良い働き方になるんじゃないかという気がしてます。
思ったよりは綺麗にまとめられた気がするんですけど。
結構わかりやすかったと思ってて、
選別的に決めないことを決めるっていうか、
あえて今決めないことをちゃんと明示化するっていうのはありで、
ありっていうかめっちゃ大事だと思ってて、
よくPRDを眺めるときにやらないことっていう項目があって、
今書かれてるところは明確にこれは今やらんっていうのが書いてあるのすごい良いなと思ってるんですよね。
大事だよね。
そういうことを他のドキュメントにもちゃんと転用して、
このドキュメントではここは書かないっていうか、
今これ決めないみたいなことが書いてあるだけで、
だいぶ見方が変わると思うんだよね。
一種のくさびにもなるかもね、
今日話してる局所最適に走ってしまう人っていう言い方っていうか、
そういう風に陥ってる人がそのタイミングで行ったときに、
いや、ここまで決めたいのだってっていうところはくさびになりそう普通。
やらないことは大事だよね。
やらないことは大事だね。
そう、デザインドックとかも。
ノンゴールとか書いたりするし。
そうなんだよな。
なんかその日常に潜む100点を取りたくなるやつの、
今ふと思ったのは日常に潜んでる100点を取りなくなる魅力を放ってるタスクは多分、
手を伸ばしちゃうのが良くないんじゃないかな、分かんないけど。
あとはその一度手を出したものをちゃんと勇気を持って撤退できるかなと思うんだよね。
それもあるね。
何だっけさ、直近で、別に話せる時には話すんですけど、
認可基盤周りのリサーチと設計をしたんですよ。
実はしてないんですけど。
リサーチが仕事で必要だったんでやって、デザインドックを書いたんですけど、
そういう結構話がでかいやつとかはノンゴールを決めないともう無限にやれちゃうし、
じゃあ完璧主義の欠柄性に陥りがちな人がその仕事をやった時に100点取れるかっていうと、
流石にそういう人でも取れないことは分かると思うんだよ。
100点取るなら15年かかりますみたいになっちゃうから。
そういうのはすごい分かりやすいんだけど、
なんか昨日開発した時にたまたま見つけたちょっとイケてないとその人目線では思う実装みたいな。
2時間ぐらいかけば直せちゃうかもなみたいなやつで、
なんか引き返す勇気というか、
前者とかより圧倒的に引きが強いから、
あの魔力は何なんだろうなっていう。
ちょっとあの魔力に話戻ってくるけど、
なぜ僕らは抗えてるのかって話だよな。
僕はさっきの大枠で考えてグッとブレーキをかけてるって感じだと思うんだけど。
僕はどっちかというと、そういう経験則的にやらない方がいいことも当然あるんだけど、
めんどくさいことをやりたくないので、
これはなんか難しいんだけど、
経験が大増していくにつれて、めんどくせえなって思うことがすごい増えたんだよね。
なんで今これやらなきゃいけないのかなっていうふうに、
いろいろ考えた結果、やらなくていいだったみたいなことは。
なんかその、伊達氏の表現で言うところのめんどくさいもその経験の積み重ねによるセンサー感ある気がするけど。
そうだね。どうしてもこれもいいことではないけど、やっぱりコスパタイパーを重視しに行った結果、
これ全然パフォーマンス良くないから今やらなくていいわっていうような判断に至ることが増えたような気がするんだよ。
なるほどね。増えてるって実感してるの面白いね。
どうなんだろう?あんまりわかんねえな。どうなんだろう自分。
いやでも俺たぶんね、引っ張られちゃう側だからすごい綱引きしてる、今でもしてる感覚あるな。
結果として減ってるかどうかは自己認識できてないけど。
まあどうなんだろう?なんかコストかけずに引き返したいんだよな、それで言うと。
そうなんだよね。そうなんだ。その辞めるっていう時もノーコストで撤退できるとは限らないからね。
そうだね。間違いない。
むしろそれをやり始めたのは何かしらのメリットがあるから手を付けて始めたはずなんだけど、
それをやめるっていうことはそのメリットは享受できないっていうことなので、
メリットだったらいいんだけど、逆にやらないことによるリスクもあるみたいな。
そうだね。
でもどっかのタイミングで伊達氏が言ってくれたプロジェクトマネジメントがそもそも機能してないみたいな話はもしかしたらあるかもな。
個人のイベントとして捉えちゃうと、そうやって個人の能力にどうしても依存しちゃうのでそうなっちゃうんだけど、
仕事でやってるうちはやっぱりプロジェクトの問題はチームの問題だとストライドするほうが合理的なんで、
アルシュマネジメントはうまくいってないっていうふうに思ったほうがいいかもしれない。
それで言うと今ふと思い出したけど、僕が引っ張られちゃってる時にやってることがあって、
今のチームで、なんで今のチームでやるようになったのかわかんないけど、
今まではやる必要がなかったからやったのかと思うかもしれないけど、やってることがあって。
朝会毎朝やってるんですけど、辞め隊で宣言をすごいするようになったんですよね。
朝会を辞め隊?
いや、朝会で。
朝会でってことね。
そうそうそう。今これやってるんですけど、それこそ伊達氏の言うところがめんどくさいとか、
それこそ2時間でサクッと回収できたらコスパいいじゃんっていうところが、
1時間やってもプラス5時間っぽいなみたいになった時に迷うというか、
その域分岐点が感覚して、頭では引き返した方がいいってわかってるんだけど、
俺の手はそれを許さんみたいな感覚というか。
時とかにぐっと手を止めて、8日朝の朝会でこれやっててこんな感じなんですけど、
辞めた方がいいですよねって言って、いいんじゃない、いいんじゃないみたいな感じでやってもらうみたいなのが結構、
自分がやってる工夫としてはあるなってふと思い出してます。
チームのスタイル、チームの開発の進め方によってこの工夫というかいろんな形の工夫がある気がしてて、
僕の今のチームの場合は結構プロダクト開発のチームじゃないから、
みんなで同じものをいじくりますというよりかは、それぞれデカめの石を持って少しずつ掘ってるみたいな感じだから、
結構独立性が高くて、そういう点で言うと、自分で持ち出さないとなかなかそういうのにはまってるっていうのが双方から見えづらいっていうのがあるから、
そういう形は落ち着いたんだなって話しながら思ったりはしたんですけど。
おすすめ。やめたいです宣言。おすすめじゃない、おすすめやな。
やめることに勇気を持つった方がいいよね。
あとは、経験も正直あるかなって気はするな。
あると思う。
痛い目見てるじゃないですか。
特にピチピチの新卒の頃に、こんな行動絶対におかしいって。
肩に挑んでみるんだけど、一周回って合理的だったみたいなね。
成功しちゃった、一周回って。そういうパターンもあるね、成功対決に。
これはいじっちゃダメなやつなんだみたいな。
そうなんです。
全然あるね。
懐かしいな。
新卒の頃に、なんでこんなおかしいんだよって思って掘りに掘ったら、
15年もののスケールサーバーのデータ量に基づくどうしようもない壁みたいにぶつかって、
帰ってきて、いまいちな実装に戻して、上司にダメだったでしょって言って、
ダメでした。
それは難しいね。
抗ってみたけど。
でも振り返ると、さっき言った典型で局所最適というか、
その時のそのソフトウェアにおける、ベストブラックですから駆け離れすぎでしょみたいなところから出発しちゃってるから、
あんまり良くないアプローチだったなっていう反省はあるし、思い出せる経験のうちの一つではあるんだけど。
そうだね。
そういうのを積んでいけるとっていう。
それで言うと、まあそうね。
普通にエンジニアってみんな積んでるのかな、そういう経験。
経験積まずに来てるパターンあるのかな。
別にエンジニアに限って話じゃないと思うんだけどね。
まあまあまあ、確かにね。
そういう局所界の山登っちゃいました体験がないと、なかなか気づかないっていうのがあるかもね。
またその登っちゃってることに、自分で気づけなかったとか、周りが指摘してくれなかったとかもあるからね。
指摘してくれたことはハッピーなんだよなみたいな。
間違いないね。
いやあ、そうなんだよな。
結論地味なこと言っちゃうと、だから一人よがりに判断しないのと、やっぱり特に経験がないっていう自覚があるんだったら、
しないのと、ちゃんとチームで合意形成を取るっていう。
そうね、まあまあ、確かに確かに。
そうだね。
あとなんか、もはやその、このスコープに留まらない話だけど、なんか指摘してくれるチームに社会人早々にアサインされるっていうのは結構大事かもなって気がする。
ああ、そうね。そこの判断のレベルが高いチームに見置くのはやっぱりいいよね。
めちゃくちゃ大事だと思う。
なんか、本当にマジで特定の誰かとか何かを言ってるわけじゃないっていうエクスキューズなんですけど、
その、この件に限らず、こういうまた劇で、40歳でその働き方で何がどうなったらそうなの?みたいなのがあるじゃないですか、世間一般的にも。
だと思うんだけど、なんか、指摘されない役人間にはまっちゃったんだろうなって年取って捉えるようになった。
ありそう。
誰もその指摘してくれる環境に多分見置くタイミングがなかった。
もしくは指摘されても無視してたとかもあるかもしれないけど、それで仕事ができてしまうっていう経験を何十年も積んできて、
本人はこれがもう一番ベストじゃんみたいになって、そこから抜け出せないみたいなのとかは応援してあるから、
このポッドキャスト聞いてる大学生の子がいたら、いいチームに入ってくださいっていう。
まあでもチームで仕事を対して、きちんと経調じゃないけど、
全員が完璧な人間じゃないから100点フィールドワークをくれるとはどんな組織にでも限んないけど、やっぱ素直に言いなりになるって言いたいわけじゃないけど、
他社からはどう見えてるのかとか、経験ある人からどう見えてるのかとか、すごく貴重な意見だなってしみじみ思いますね。
そうね。
確かに独りよがりね。
またチーム運営目線だと、おのずとせが拾えるようなフレームが作れるといいんだろうね。
それも難しいけどね。だってそれをチームが受ける訴状がないとそもそも意味がありませんっていう。
そうだね。
難しいことあるから。難しいな。
そこを掘っていくとプロジェクトマネジメント力の話になってくる気はするな。
そうね。
それこそ人とか作るものとかによって結構最適なスタイルって変わるから。
それも面白いと思うんだけどな。面白いと思うというか、面白いトピックだよね。
得意では全くないけど。
そうだね。
でも最近のエンジニアは割と求められてる気がするんだよな、その辺も。
だって結局そういう合理的な判断ありきでのものづくりじゃん。
そうだね。
ものづくりってあんまり言いたくないけど、開発ってそうじゃん。
確かにね。
ここで常にそういうメイクセンスな判断をしてくれるPDMさんに出会えると、
それはハッピーなんですけど、常にそういう人がいない場合はやっぱり誰かがそのロールを大体するしかなくて、
そうなった時に自分が出ていけるかどうかっていうのは一個あると思うんだよね。
確かに。
それで言うと最近知った言葉があって、それが思い出してたんじゃなくて、今手元で必死に探してるんですけど、
その仕様まで決めて働けるソフトウェアエンジニアみたいなのを何たらエンジニアなんだっけなって呼ぶっていうのを何かで知って。
あるんだ、そういう定義が。
そう。何だろう、チャットGPに聞くか。
便利な世の中ですね。
便利な世の中やな。
仕様まで自分で決めるソフトウェアエンジニアの名称。
そう、でも確かに時代の流れはすごい感じるかも。
フルスタックとかじゃなくて何だっけな。
マジ忘れてた。思い出したらツイートしときます。
チャットGPではちょっと違いました。
見ては知らなかった。
知らなかった。
特徴的な日本表現で一気通貫エンジニアとか出てきたかな。
何でもやエンジニアとか。
そうじゃないんだよな。
まあまあまあ。
面白いなあ、これ。
無限に話せるね。
ね。
めっちゃもやもやする。
強い気持ちで引っかえそう。
引っかえそう。
これは勇気ある撤退ですね。
勇気ある撤退で。
勇気ある撤退で。
勇気ある撤退で。
勇気ある撤退で。
勇気ある撤退で。
勇気ある撤退で。
撤退、勇気ある撤退ですね。
勇気ある撤退で。