1. ITトリオの日常
  2. 評価されやすいエンジニアって..
2024-06-10 29:46

評価されやすいエンジニアってどんな人だろう? / 新卒時代は評価制度に不満を持ちがちだよね

評価されたい!お賃金あげて!

と思うエンジニアは多いと思いますが、そのためには成果をアピールしなきゃいけないです。

新卒時代の不満を振り返りながら、あれこれ喋ってみました。

ちーずさんはお休みです!


今回取り上げた記事はこちら

評価されやすいエンジニアとは、成果を効果的にアピール出来るエンジニアのこと。

https://blog.tinect.jp/?p=86582


▼▼▼ 今週のジャンプ感想


ヒロアカと呪術廻戦が同時に休載😭

先生方、お大事に・・・


▼▼▼ おたより待ってます!

番組の感想や話してほしいお題や質問など!

https://forms.gle/sqzWk2Yb79cMvFGg8


▼▼▼ X もよろしくです

ハッシュタグは #ITトリオ で!

https://twitter.com/TorioIt


▼▼▼ 公式HPはこちら

https://it-trio-no.com/

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

サマリー

彼は能力を発揮する上で、成果を効果的にアピールできるエンジニアだと考えられています。彼が自分の成果を言語化できるかどうかは、日々の仕事で重要です。新卒時代には、評価制度に不満を持ちがちなエンジニアに関する話題が取り上げられています。エンジニアとしての評価には、プロモーション活動やマネージャーとのコミュニケーションなどが重要だと示唆されています。マネジメントやリスペクトに関する話題も取り上げられ、エンジニアの思考や働き方についても言及されています。

評価されやすいエンジニアの特徴
評価されやすいエンジニアってどんなエンジニアだと思います?
自分が思うに、まあ、いろいろあるけど、大きく分けると、ちゃんと自分の成果を言語化できる人と、
あと、ちゃんと、なんていうのかな、スキルとか、何かしらの能力を発揮できる人だよね。
確かにその通りだと思います。今回は、なんかそんな感じで、評価されやすいエンジニアとは、成果を効果的にアピールできるエンジニアのことっていう記事が
バズってたんで、それについて話そうと思います。よろしくお願いします。
ちょっと、本題に入る前に、今回、知事さんがお休みでして、僕と鍋ちゃんの2人でお届けしますね。
知事さんめちゃくちゃ忙しくて、収録の前日に朝5時半まで仕事をしてるって言ってたんで、それは、さすがに休んでくれって言って。
本当にね。
休んでもらいましたね。いや、もうなんか無理しなくていいから、休んで欲しいから、みたいな感じで。
特勤なんかITトレーヤーのみんな体調悪いから、本当に気をつけたくないとね。
気をつけたいですね。
体調に気をつけながら評価もされていきたいという感じなんですけど。
そうですね。
えっと、今回触れる記事は、6月4日に新崎さんが書いてた記事なんですけど、このメディア、僕、見たことないんですけど、
ビジネスパーソンを励ますウェブメディア Books and Apps っていうところで書かれてた記事ですね。
いつもの通り、放送の概要欄にリンク貼っておくので、ちょっと読みながら聞いていただきたいって感じなんですけど。
成果の言語化とストーリーテリング
タイトル通り、成果を効果的にアピールできるエンジニアは評価されやすいですよってことを言ってますね。
で、まあ、記事の詳細は読んでほしいんですけど、最初の方にポイントがまとめてあるので、それだけまとめてあるところだけ読んでみます。
この記事で書きたいのは、だいたい以下のようなことです。
評価されやすいエンジニアとは、ちゃんと自分の成果を言語化してアピールできるエンジニアです。
アピールというと苦手意識を持つ人が多いのですが、必要なのは自分を大きく見せることではなく、具体的な達成状況の可視化です。
自分の成果を言語化できるかというのは、日々の仕事で能力を発揮する上でとても大事です。
成果を言語化する上では、ちゃんとストーリーを考えることも大事です。
ストーリーといっても、別にありもしない物語を作れという話ではなく、組織が持っているビジョンや方向性に合致する結果になっているかという話です。
特に新人さんには、組織のストーリーに沿った成果の言語化を意識するようにお願いしています。
以上です。よろしくお願いします。というのがバトルですね。
なるほど、なるほど。
いやーこれ、実際社会に出て、評価される状況になって働いて、なんか3年ぐらい経つと、
なんか僕の方でも言語化はしてないけど、確かにそうだよなと思える立場というか、
分かる分かる。
確立されてた気がするんだけど、この部分をちゃんと理解するのにするまでの新卒時代ってすごいなんか、
辛いというか、
分かる。すげえやきもきするこれ。
そう。
すごい分かる。
エンジニアだから、評価されるためのコード、人に評価制度があって、それのなんか多分フィードバックシートみたいなのがいろいろあって、
それに書かないと成果されないというよりかは、エンジニアだから書いたコード自体とかで、ちゃんとなんか評価されてほしいというか、
分かる分かる分かる。
評価されてほしいし、なんかそうあるべきなんじゃないかみたいなことを新卒時代はなんか思って、
それもあるからなんか余計、
そういう評価されるために自分の成果を整理して書くとか、
なんか相手に伝わりやすいように、そういうストーリーを作って伝えるとかっていうのがすごい苦手だったなあっていう。
レジュメの重要性とビジネス的な価値
うん、そうなんだよね。なんか本当に作ってきた成果物っていうのが目に見えて分かりやすいから、
それで評価できるでしょうとかって思ってて、自分としてはこういうことやってきて、
こういうこと、こんだけやってるんだから評価してほしいって思ってても、ちゃんとそのなんていうのかな、
自分の会社の場合はMBOっていってその目標制度があるんですけど、
目標制度とちゃんと照らし合わせて、こういう目標を立てて、こういうところを達成して、でこういうところが会社にとって良かったんで、
ここの部分をちょっと評価してもらえると嬉しいですとか、
そもそも会社の評価制度を照らし合わせて、自分の投給要件というか、評価の基準みたいなのがあるから、
今僕の評価の基準ってここら辺が足りてないとか認識されてると思うんですけど、こういう成果残して、こういうところでこういう行動したんで、
そこちょっと認めてほしいですみたいな。それで評価としてはこれぐらいで、見てくださいみたいなことを説明しないといけないっていうのに気づくまですごい時間がかかってた。
それは誰か教えてくれるわけではなかったから。
ほんと?誰か教えてくれるというか、なんかワンワンとか上司から、それで書いたほうがいいよみたいなことはちょくちょく言われるけど、
あ、そうなんだ。
ちょくちょく言われるというか、評価のために説明みたいなことはされるけど、なんか腹落ちしていないからできないというか、
あ、わかるよ、それも。
腹落ちしてないし、
確かに。
なんかまあその、なんなら他の周りの他のエンジニアの人もやってるけどめんどくさいめんどくさいって言いながらやってるから、
いやーなんかこれ本質的じゃないんでは?みたいな感じのことを、若者しぐさというか新卒しぐさで思ってしまって、
余計自分のそういう成果を整理したりとか、評価シートに書くみたいなことが億劫になって余計書けないみたいな。
わかるわ。最初ほんとそうだったな。なんか今はだいぶ慣れて、
もうこうやってこうしたらこうで、こうなるから、これ大丈夫でしょみたいな、なんか割とほんとすぐできるし、なんか抵抗とかも全然なくなったんだけど、
あーすごい。
そう。でも最初の頃ほんときつかったなって、なんて伝えたらいいかもわかんないし。
うん。
割と言うと、僕なんか最初にそういうちゃんとした制度があった会社に勤めてたんだけど、それを2年、ちょっと2年半弱で辞めて、他の会社に移ってしまったんで、
で、他の会社はそんなにちゃんとした評価制度というか、そこまで細かい評価制度なかったので、
僕なんかこうやって理解したふうに話してはいるものの、言うてたら多分なんかちゃんとこういうのを書くっていうのが、多分まだそんなスムーズにできないですよね、僕。
あーなるほどね。
多分、たぶんやってないから、でもなんか今、社会人6年目ですか?になると、ここらへんの大切さというか、
やっぱその会社の、会社というかなんだろう、会社でもどこでも多分、今の社会だったらそうな気がするんですけど、
なんか自分のやってきたことをビジネス的な文脈において、ちゃんと評価される方向でボディをつけて、相手に伝えるっていうのをしないと、
たとえ自分がいいものを作ったり、いいコードを書いたとしても、ビジネス的な価値と耳についてなければ、そういう資本主義の今の世の中ではあんまり意味をなさないんだなみたいな。
あーそうだね。本当にその、同じことやってきた人であっても、伝え方が変わるだけで、全然評価が変わってくると思う、本当に。
そう、なんかそれがね、いろんなところで見るなというか感じるなってことは思って、なんか似たようなことを僕、最近カナダの就活でも思って、
なんかどこでもアピール必要なんですけど、自分の評価を。自分の評価をどこでもアピールすること必要なんですけど、特にレジュメを今書いてて、カナダの企業に送るように英語で。
で、あまり僕レジュメ自体を書いたことがなかったんですけど履歴書。
あ、そうなの?転職とかに書かないんだ。
僕が使ったサービスって、なんていうんですか、転職したい人とされたい企業のマッチングサイトみたいなのが多かったんで、
自分のプロフィールとかをウェブ上で登録するんだけど、そんなになんかちゃんと書かないというか。
会社の履歴となんとなくの役職とちょろっと説明ぐらいで、あとはマッチングした後のカジュアル面なんで最初に話すみたいな。
なるほどね。
で、まあ新卒の就活もレジュメ書かずになくそんなマッチングサイト的な方を多く使った気がするんで、そんなにちゃんとしてなくて。
で、まあ今回カナダに来て初めてエンジニアとしてレジュメをちゃんと書いてるわけなんですけど、
ここでなんか評価されやすいエンジニアになるためには、もろにこの成果を効果的にこの1枚の紙の中でアピールしないとダメだなっていうのがすごい感じで。
なんか単純に自分がやった、実装したタスクとか使ったフレームワークとかを書くだけではダメで、
それをした結果ビジネス的にどういうインパクトがあったかっていうのをなるべく具体的に魅力的に伝えるっていう。
そうだね。
なんか例えば大きなアプリのリファクタリングをしましたっていうのはエンジニア的に見たら、
なんかこの言語からこの言語にリファクタリングしましたって言うだけで、なんかすごいことやったかもねって思うかもしれないんですけど、
レジュメの上では全然それ意味なくて、この言語からその言語にリファクタリングをした結果、こうこうこういう価値があって、
例えばユーザーの使い心地が上がったりとか、アプリの速度が上がって具体的にCVR5%上がりましたとか、売上げに何パーセント貢献しましたみたいなところまで具体的にレジュメでは書くことが求められていて、
これってまさに今回触れる記事と構図一緒だなと思って、なんかすごいそれで心に響いた感じがしましたね、僕はなんか。
しかもこれ、記事の中で言われているの、この言語化するために日頃から日頃のタスクをどういう世界に結びついているのかっていうのを意識しながらやるみたいなことを。
そうだね、それはすごい大事だと思う。
そう言ってて、確かにそれ日頃から意識しないといざ評価されたい時に情報整理しようと思っても、なんかそもそも自分の中に情報溜まってないからできないんだよなみたいな。
そうそうそうそう、なんかね結びつかないんだよね、今までやってきた行動と全体の目的みたいなところが、そうなんだよね本当に。
そこの辺って今ラベジャンはどうしてるんですか?日頃からなんかメモ取ったりとかしてるんですか?
してるし、なんか目標を作るからさ、うちの会社の場合は。その目標を作る時点で会社にとってどんなインパクトがあるかっていうのをまず考えてるから、だからそもそもなんていうのか目的を考えた上で走るから、なんか最初からちゃんと定めてるから、見失わないというか、それはあるかも。
その目的は、もうなんか自分で納得できるものを設定できる感じなんですか?なんか僕新卒時代思い浮かべると、そもそもその目的も、なんかなんだろうな、いろんな文脈の上で設定しなきゃいけない目的だから、自分としてはなんか半分ぐらいしか納得していないというか。
半分ぐらいしか落ちしていないので、目標立てたとしても日頃の中で忘れがちだし、なんかどうでもいいやと思っちゃいがちな時があるんですけど。
でもそうだよ、俺も100%納得はしてない。それはやっぱり、なんか半分納得できればもういいかなっていう気持ちがある。
半分でいい方なんだ。
なんか結局さ、お金もらえてるわけだからさ、ある程度やっぱり会社の方針には従わないといけないわけで、会社の方針全部壊したいんだったら自分で起業するとか、極端なしではね、とかって話になるもんね。
評価制度に不満を持つ新卒エンジニア
50%でもあれば、自分の好きなことは50%持ってるわけだし、それはそれでいいのかなって最近は思えるようになってきた。お金もらえて好きなことも得れるから、50%。
確かにな。
何か感覚。
自分の好きなことをやれるか、そこにいるっていうよりかは、いるじゃなくて、まあそうだよね、お金もらえるから契約してそこの会社に所属しているわけで。
そうだね。
まあそうだよね、会社の立場の方が確かに大きいもんね。ああ、そりゃあそっか。
そうそうそう。
なるほど。
まあそれで、自分の中では心の折り合いはついてるかな。
うーん、なるほどね。そこの部分で大人にならないといけないですよね。
ああ、そうかもね。そうかもね。最初そこ苦戦したな、本当に。
いやあ、そうだね。
なんかさ、会社にとっての自分が歯車というか、歯車でありたくないみたいな感じがすごい強かった。
ああ、あるね。
で、自分が会社を変えてやるんだぐらいのさ、なんだろうね、意気込みだったから最初の頃って。だから自分の力をすごい過信してたみたいなのがすごくあってさ。
で、なんか会社の方針的にはこうやって言ってるけど、いや自分だったらこうやってやって、こうやってやったらもっと知られる自信あるぞみたいなぐらい。
なんだろう、カプターに言ったらね。ぐらいちょっと生きてたけど、まあでもね、やっぱり生きてもね、やっぱり周りがついてこないと結局成果って出ないんで。
そう、周りがついてきてもらいつつ、うまいこと進める方法っていうので。
表面上はやっぱりさ、こっちの目的でっていう話をもちろんするし、自分もそっちに割合としてはちょっと多めに言うけど、
でも実は本音的には目標としてはこうやって言ってるけど、こういうふうに動いたりとか、ちょっと目標と多少ずれるけど、動き方変えてみたりとか、そういうのはある。
そこでは、最終的なアウトプットとしてはちゃんと合意したものとしては出すんだけど、ちょっと寄り道するみたいなことは全然あるかもしれない。
なるほどね。できる範囲で。
ITトリオ。
いやまあ、そうっすよね。生きちゃうとね、自分がいいと思う方向で貫いてとしても、自分がいいと思ってるだけで別に会社的な良さの基準とは違うから、
むしろマイナスみたいな。世界に正義を訴えたいわけじゃないですからね、会社員として。
そうだね。
会社員としての求められる振る舞いをしないとっていう。
うわあ、なんか大人になったなあ。
本当にね、極端な話したらさ、ブラック企業の話とかすればさ、もうとにかく杖小屋ずつ働けみたいな世界なわけじゃないですか、ブラック企業。
はいはいはい。
で、それはもう、求められてる人としてはさ、考えたらアーダーコーダーいう人よりもとにかく行動を動く人が求められてるような話でさ。
そこまでいかないけど、うちの会社は。全然ホワイトだけど、考えるうちはすごいあるし、個人の財力も大きいけど。
まあ、やっぱり会社がそういう方針だったら、それに従うわざるをえんなっていうのを、すごい大人になったなって思う、自分は。
いやあ、そうだよね。それに納得できないんだったら、転職するとか。
そうだね。
起業するとかで。
そうそう。
自分の納得道を探さなきゃいけないんですけど、自分が納得するために今いる環境を変えようと思うのは、なんか若干ちょっと方向性が今の社会だと違うのかなっていうか。
そうだね。
今の環境を変えたいのが、会社の目的というかビジネス的な目的と一致するから、今の環境を変えたほうがいいんじゃないですかみたいなのは、多分、筋が通ってるんですけど。
そう思う、そう思う。
それの関係なく、自分がちょっと働きにくいからとか、自分がやりたい方向性と違うからっていうだけで、環境を変えようとするのは、むしろマイナスになってしまうという。
そうだね。マイナスになる気がする。
そこの気持ちの折り合いというか、納得して行動するのが大事ですよね。
そうなんですよ、ほんと。新卒だとね、新卒であればあるほどそうなっちゃいがちなのかなっていう気もするけどね。
まあ、でかい、そういう人のほうがなんか多い気がして。
なぜなら、社会に出て評価されてみないとそういうのを感じたり考えるきっかけあんまないかなと思っていて。
そうだね。
もしかしたら、どうなんですかね。大学のサークル運営とかであるのかもしれないですけど、僕はそれにしてなかったので知らない。
どうなんだろうね。結局さ、人間関係でしかないわけじゃんね、大学とか高校とかって。評価がされるのって、まあ、有定試験ぐらいかあるとしても。試験は完全にもう目に見える数字としての評価っていうのが結構大半なわけで。
なんか、大きいサークルだったらちょっとあるかなと思って、なんか企業にスポンサーついてお金動いている系のやつだったらあるのかなとか思ったりしてた。
ああ、そういうことね。確かにそれはありそう。確かに確かに。
エンジニアとマーケティングの関係
なんかこの評価されやすいエンジニアの話、なんか構図的には何ですかね、なんか会社のビジネスの方向と一致しないといけないっていうのと、あと中身がどれだけ良くてもそれを外に周りの人に分かる形でアウトプットしないと許可されませんよみたいな構図あるかなと思って。
これ、なんていうのか、なんかプロダクトの良さとマーケティングの関係みたいなのとも一致するかなというか、なんか似てるなみたいなことをちょっと感じたりして。
なんかちょっと最近別文脈で考えてたんですけど、なんかプロダクトの良さ、プロダクト自体の良さとプロダクトの中で使われてる技術とプロダクトが売れるかどうか利益が出るかどうかって、なんかあんまり相関ないなっていうのをなんか最近感じてて。
なんかプロダクトがいくら良くてもちゃんとそれを宣伝とかマーケティングしないと広がっていかないし、プロダクトに使われてる技術がどれだけ最先端でもそもそも作っているプロダクトがビジネス的に意味がなければあんまこう利益出ないし、
でもエンジニア的にはその3つ、エンジニア的にはってかあれか、でもエンジニアの立場だけから考えると、なんか中で使われてる技術最先端でというか綺麗な方だけで本当は全部うまくいってほしいんですけど、現実問題それだけではないっていう。
特にそのプロダクトが良くてもマーケティングして宣伝しないと広がらないみたいなのはほとんどのプロダクトに当てはまる気がするんですけど、なんかそれがこういくら仕事ができても周りに見つからなければというか伝わらなければ評価されないみたいなとなんか似てるなーみたいな。
近いかもしんないね、確かに。
評価をされるというか、日々のタスクをして実績を作るっていうのは、なんか良いプロダクトを作ること自体で、評価されるために行動するっていうのはある種なんかマーケティングというか、外向けの広報活動みたいな。
そうだね、確かに確かに。
かなーみたいなのをうっすら思ったりしたんですよね。
なんかさ、ただ一個だけちょっと違うなというか思うのは、自分を見てくれるマネージャーとかっていうポジションの人がいるわけじゃんね。
その人はプロモーションしなくても、本来そのサービスをすごい使い続けてくれてる、ある意味ワイヤーみたいな話なわけで、プロモーションしなくてもその製品の良さとか知ってくれてるはずなんだよね。
個人の話だよね。
理想論はそうな気がするんですけど。
理想論的にはね、そう。
現実問題その上司も多分複数人の人を見なきゃいけないし、その上司も自分の仕事をしながら評価のときに忙しくなって、いろいろ情報整理するから、
そういう人がいたとしても、やっぱり評価されるための自分のマーケティング活動というか、もちろん情報を何も持ってない人向けにマーケティングするのではないので、やりやすさとかやるべきことは多少違いども、
やっぱり評価されるための行動っていうのは一定求められるよねっていう。
評価のための行動とワン・オン・ワン
なんか双方にやるべきだと思うんだよね、俺は。
双方?
メンバーももちろんそのプロモーションすべきだし、マネージャーもプロモーションしてる内容をキャッチアップしに行くべきなんだよね、僕は思ってて。
普段の行動から、なんかその子が言ってる、メンバーが言ってることを、どれだけ信憑性があるのかっていうのをちゃんと判断できないといけないからやっぱり。
なんか、ワン・オン・ワンをちゃんとしていれば、評価メンバーみたいなのは、実はそんなに時間必要ないみたいなことを言っている人もたまにツイッターで見るときも。
そうかもね。
ワン・オン・ワンでちゃんと日頃からコミュニケーション取れてれば、その中で自然と自分がやってきたことみたいな言語化とか、ビジネス用の結びつけっていうのは本当は自然とできるはずなので、日頃からのコミュニケーションを密に取れるワン・オン・ワンをちゃんとやってれば評価もだいぶしやすいみたいなのは聞いたことがありますね。
そんな気がする。
うん。
なんかワン・オン・ワンってすごい大事だと思うな、本当に。
ワン・オン・ワンやらなくていいみたいな会社にはあんまり行きたくないかもしれないな。
そうだね、俺もそれは同意だわ。
評価に限らずね、そういうコミュニケーションが密に取れてるから、評価されるされない関係なく自分が持っている課題感とか、ちょっと疑問みたいなものをコミュニケーションを取って解決しやすいっていうのは、ワン・オン・ワンをする会社で働いてきて常々感じていたので。
うんうんうん。
それはね、あってほしいですよね。
ほんとほんと、すげー大事な文化だと思う。
うん。
ITトリオ。
まあ、いろいろ話したんですけど、今回の本題はそんな感じで、まあちょっとエンディングトークやりたいなって感じですね。
お。
チーズさんいないとね、話しにくいよね、やっぱね。
まあそうだね、ちょっと話しづらいかも。
最近、あのカナダで、このITトリオの日常を聞いてくださっている人と話したりもしたんですけど、てかそれ以外のトリオと話して出てくるのが、やっぱチーズがすごい、なんか話し広げたりまとめてくれるから、すごいいいよねってこと言っている人多くて。
ああ、そうなんだ。
まあ僕編集しながらもそれ感じてるから、やっぱそうなんだよなーと思いながら。
チーズさん大事なんで、やっぱり体ちゃんと治してもらってっていうか、そもそも体壊せないような生活済みのリズムにしないといけないね。
まあね、性格的にたぶん突っ走るタイプなので、たぶん。
そうだね。
うーん、そんなに変わらないだろうなと思いつつも、ちょっと体に気をつけてやってほしいなって感じですね。
そうだね、体に気をつけてほしいな、ほんと。
あと最近、ITトリオのハッシュタグでつぶやいてくださっている方見つけたので、また触れていきたいですね。
お願いします。
まあ名前は出さないんですけど、さっきあったのが、
今日から聞き始めました。お三方のおっしゃってることをちゃんと理解できるようになるまでどれだけかかるんだろう…モチベーション上がるというつぶやきですね。
駆け出しエンジニアの方らしいですね。
どうなんだろうね、すぐわかるんじゃない?
話題によると思う。
話題によると思うけど。
それこそ前回のマネジメントがマジって話とかは、まあ1、2年たったりして、マネジメントしなくてもマネジメントする人を、
マネジメントやリスペクトについて
何ですか、マネジメントすることを身近で言ってみないとたぶん、あんまり船落ちないというか、わかんないかもなーって感じはあるけど、
どうなんすかね、まあ話題によりますね、トピックによるかな。
そうだね、話題が結構幅広いから、まあ全部わかるのは難しいかもしれないけど、そもそも。
でもそれが良さでもあるかなと思って、IT棟梁の。
割と実際にエンジニアとして話している僕たち、今回いないけど、1人いないけど、3人がエンジニアが何か日頃働いてて思うこととか、
エンジニアの観点で何か勉強になった感じの記事とかを取り上げて話しているんで、話題もそうだし、たぶん話の節々で、
たぶんエンジニアしぐさというか、エンジニアっぽいなーみたいな話がたくさんあると思うので、
まあね、聞いてるだけできっと勉強になると思います、はい。
そうなるといいなと思ってやってます。
何かあんまり、何て言うんですかね、初心者の人向けには、こういう何か聞くだけで勉強になるというか、
ちょっと先を走っているエンジニアの思うことが共有できて勉強になるっていう方向性で伝えればいいなと思ってて、
何か自分と同じ年代というか、僕たちと同じような何て言うんですか、ティアのエンジニアの人とかには、
何か共感が届けられたらいいなと思っていて、
僕たちより上の方の人向けには、何て言うの、
最近の中堅エンジニアってこういうことを考えてるんやなーみたいなことが伝わったら面白いかなと思って、
なるほど。
個人的にはやってますね。
めっちゃ考えてるやん、すご。
そう。3人で飲み会とかしてないからそういうの伝わらないんだけど、考えてるんやな。
まあ、こんだけ遠いとはなー。あ、でもカナダはそろそろ行こうかな。
あ、マジで?
1回ぐらい。
おー。
今が一番暖かいよね、カナダ。
もうちょっと後かな。今でも十分暖かいけど。最近まだ雨多いからな。
あ、そっか。梅雨なんだ。
梅雨とかはないですけど、梅雨とは言わないですけど、バイオレンスにないから。
あともう一個つぶやきあって、これも前回の放送を聞いてくれた方のつぶやきなんですけど、
マネジメントで変えられるというより、結果として変わるなのかも。
変わるか変わらないかはその人の選択なので、他人に選択が共生できると思わない方がいいと思う。
馬を水目に。
温泉はコーフォートゾーンのことかな。
主題とあまり関係ない話で申し訳ない。
というつぶやきもありまして。
いやー。
プラスフォートね。
人を変えられると思うのは傲慢な考えなので。
人を変えるのは難しい。
結果として変わることはあっても、
そうだね。
それなんかマインドコントロールとかそういうことするわけじゃないよね。
そこはちょっと一定謙虚になって、望まなきゃなと改めて思いました。
ね。
なんでなんでとかなっちゃうからね、変えられるとか思うと。
そう、気をつけたいですね。
そうね。
リスペクトがやっぱ大事ですから、お互いに。
リスペクト、ほんと。
まあ、そんな感じでいろいろ話したんですけれども、
今回の放送はこれくらいにしたいと思います。
この番組を気に入っていただけた方は、
Spotify、Apple Podcasts、YouTubeなどで番組のフォローをお待ちしております。
ビブもぜひよろしくお願いします。
なんですけど、6月中にGoogle Podcastが使えなくなるんですよ。
ああ、そっか。
うん。
Google Podcastをもし使って聞いてくださっている方がいたら、
ぜひ他のプラットフォームに行こうお願いしたくて、
今言った通りSpotifyとかApple Podcastでも聞けますし、
YouTubeにもRSS登録してあるので同じように聞けますね。
YouTube自体とYouTube Musicでも聞けるんで、
Google Podcastを使っている方はぜひ何かしらのプラットフォームで移動して、
フォローよろしくお願いしますって感じです。
お願いします。
はい。
エンジニアの思考や働き方
お便りも募集しています。
放送の概要欄にあるリンクからどしどし送ってください。
Xで感想を呟く場合は、
ハッシュタグITTRIOでお願いします。
今回みたいに話題に挙げるかもしれないです。
お願いします。
はい。
それではまた来週、
Git Cheeseと一緒に出会えることを願って今回は終わりにしたいと思います。
ありがとうございました。
ありがとうございました。
And now, a short commercial break.
現在、エンジニアの採用にお困りではないですか。
候補者とのマッチ率を高めたい、
事態率を下げたいという課題がある場合、
Podcastの活用がお勧めです。
音声だからこそ伝えられる深い情報で、
候補者の興味、関心を高めることができます。
株式会社HITOPAでは、
企業の採用方法に役立つPodcast作りをサポートしています。
Xまたはホームページのお問い合わせよりご連絡ください。
気になる方はカタカナでHITOPAと検索検索。
29:46

コメント

スクロール