ゆーちゃん
banner
yuchan314.bsky.social
ゆーちゃん
@yuchan314.bsky.social
エンジニアの年収とキャリアを劇的にアップデート🌟|元コミュ障エンジニアが年収UP&理想の働き方を実現🏆|あなたのキャリアと収入の最大化をサポート🚀|具体的なキャリア戦略と収入アップ術を発信中💰
【目標を二つ設定する】

地道に継続をすることが
やっぱり1番強いけど、
それが1番難しかったりする。

何か継続はしてますか?

ダイエット、あいさつ、笑顔、筋トレ、日記、家計簿、連絡、声かけ、瞑想、読書などなど。

自分の意思で続ける事が、
やっぱり一番自信に繋がる。

続けるコツは、ある。
January 25, 2026 at 3:03 AM
【コードレビューのコツ】
✅ 細かすぎる指摘はスルーもあり

「インデントが微妙にズレてる」とか、PRの本質と関係ない指摘してない?

✔︎ 大事な指摘と「趣味の違い」を分ける
✔︎ チームのルールに沿っていればOK。個人の好みは押し付けない
✔︎ 「カッコの位置が…」って言い出したら、もう宗教戦争

柔軟に考えられる人って、みんなから頼られるよね💪
January 24, 2026 at 3:09 AM
おはようございます。

最近のマイブーム、ジェルネイル。
初めてグラデーションに挑戦したら、いい感じにできた。

キーボード打つとき、ふと目に入るのが嬉しい。
小さな変化だけど、気分が上がる。

仕事のモチベーションって、意外とこういう些細なことで変わる。
自分の機嫌は、自分で取る。
January 23, 2026 at 10:03 PM
【最短距離を探し過ぎていないか】

どんな時にどんなフレーズを
使えば良いのか、
どんなメッセージを
送れば良いのか、
こういうのが良いよねっていうのは確かにある。

だけど、『答え』を
探し過ぎてしまうと、
あまり良くない。

と言うか、むしろ逆効果。

『答え』そのものより
もっと大事なもの、
January 23, 2026 at 3:06 AM
おはよう。

リファクタリングするかどうか、迷った機能があった。

結論、今回は見送り。

理由は3つ。
・動いてるコードを触るリスク
・今のスプリントに余裕がない
・「直したい」が自分だけの感覚だった

技術的負債は返したい。でも、タイミングがある。
「今じゃない」も、ちゃんとした判断。
次のスプリントで提案することにした。
January 22, 2026 at 10:03 PM
【コードレビューのコツ】
✅ 議論になったらちゃんと向き合う

指摘したら「いや、こっちの方がいいと思います」って返されたとき、どうしてる?

✔︎ 「なるほど、じゃあこういう選択肢もある?」と議論を深める
✔︎ 無駄に対立しない。目的は「勝つこと」じゃなくて「良いコードを書くこと」
✔︎ 「いや、俺が正しい」ってムキになるのはただのガキンチョ

頑固にならずにちゃんとオープンな姿勢で議論できる人ってかっこいいよね⭐️
January 22, 2026 at 3:03 AM
おはようございます。

今日、クライアントから「なんでこの設計にしたんですか?」って聞かれた。

正直、ドキッとした。
でも、ちゃんと説明したら「なるほど、納得です」って言ってもらえた。

設計の意図を言語化できるかどうか、大事だなと思った。
「なんとなく」で決めてたら、説明できなかった。

判断には必ず理由をつける。
それが自分の設計力を上げることにもつながる。
January 21, 2026 at 10:03 PM
【実力が無くても目に留まる人の特徴 】

実績も実力も
めちゃめちゃあるわけではない。

だけど目に止まって
気になる人っていますよね。

そんな人にはどんな特徴が
あると思いますか?

わざわざ
実績も実力もつけなくても、
あなたが今よりさらに もう一歩魅力的になれるヒントを
お伝えします⭐️
January 21, 2026 at 3:09 AM
おはよう。

今日、自分の作業を止めて、人の応援に一日使うことにした。

正直、自分のタスクも詰まってる。
「今日くらい自分のことやった方がいいんじゃないか」とも思った。

でも、応援することに決めた。

応援したいと思える人には共通点がある。
その人自身が、誰かを応援してる人だってこと。

自分のことばかりじゃなく、周りのために動ける人。
そういう人は、自然と周りからも応援される。

自分もそうありたいと思う。
だから今日は、人のために時間を使う。
January 20, 2026 at 10:03 PM
【実力が無くても目に留まる人の特徴 】

実績も実力も
めちゃめちゃあるわけではない。

だけど目に止まって
気になる人っていますよね。

そんな人にはどんな特徴が
あると思いますか?

わざわざ
実績も実力もつけなくても、
あなたが今よりさらに もう一歩魅力的になれるヒントを
お伝えします⭐️
January 20, 2026 at 3:06 AM
おはようございます。

「技術力があれば仕事が来る」って、昔思ってた。
でも、実際は違った。

技術力がある人はたくさんいる。
その中で選ばれるのは「この人に頼みたい」と思わせる人。

自分が変わったのは「相手が何に困ってるか」を先に考えるようになってから。
技術は手段。目的は相手の課題解決。

この順番を間違えると、技術だけ磨いて仕事が来ない状態になる。
January 19, 2026 at 10:03 PM
【コードレビューのコツ】
✅ エラーメッセージより優しくあれ

「改善してください」より「こうするのどう?」の方が受け入れやすい。

✔︎ 直せとは言わず、提案する
✔︎ できれば改善の方向性を示してあげる
✔︎ 人間はやさしさがなければエラーを発生しやすい

もし自分がレビューされる側だったら、そコメントを素直に受け入れられるか。
January 19, 2026 at 3:03 AM
おはよう。

今週、新しいツールを導入するか検討してた。

結論、見送り。

判断基準は3つ。
・学習コストに見合うリターンがあるか
・チーム全体で使えるか
・既存のワークフローを壊さないか

全部クリアしてなかった。
「便利そう」だけで飛びつかない。
導入しない判断も、立派な判断。
January 18, 2026 at 10:03 PM
【人は一人じゃ頑張り続けられない】

今まで変えられなかった事を、
一人で変えようと苦心していませんか?

人は一人じゃ変われない。

昔から人間はコミュニティを形成して生きてきています。

支え合い、助け合いながら。

なぜなら、一人でできることには
限度があるから。
January 18, 2026 at 3:09 AM
おはようございます。

バグ修正で2時間溶かした話。

原因、環境差分だった。
本番とローカルでNode.jsのバージョンが違ってた。

最初からDockerで揃えてたら起きなかった問題。
「面倒だから後で」って思ってた自分がいた。

環境構築の「後で」は、だいたい「永遠にやらない」。
今日からDocker化を始める。
January 17, 2026 at 10:03 PM
【コードレビューのコツ】
✅ 良いコードも褒めろ!いや、むしろ褒めちぎれ!

指摘ばっかりじゃモチベーション下がる。良いコードにはスタンディングオベーションを!

✔︎ 「ここのロジック綺麗!天才か?」と褒める
✔︎ 「この関数名、まるで詩的!」と持ち上げる
✔︎ 褒められたエンジニアは、2倍の速さで次のPRを出す(当社比)

ちゃんと良いところも伝えられた? 指摘ばっかりになってない?
January 17, 2026 at 3:06 AM
おはよう。

コードレビューで指摘するかどうか、迷う場面があった。

動作に問題はない。でも、読みにくい。
「これ直した方がいいな」と思ったけど、指摘を見送った。

理由は2つ。
・今回の優先度はリリーススピードだった
・本人が気づいて直す方が学びになるタイプだった

何でも指摘すればいいわけじゃない。
「今この人に必要か」を考えて伝える。
January 16, 2026 at 10:03 PM
【コードレビューのコツ】
✅ 意図が伝わるコードを書こう

「なんでこの実装になったの?」と聞かれることが多いなら、コードに意図を埋め込もう。

✔︎ 変数名・関数名で「何をしているか」を明確にする
✔︎ 必要ならコメントで「なぜこの実装なのか」を補足する
✔︎ 「コードを読んだだけで意図が分かるか?」を意識する

「コードは書いた人だけでなく、読む人のためにある」
未来の自分やチームメンバーのために、意図を伝える工夫を!
January 16, 2026 at 3:03 AM
おはようございます。

昨日、見積もりで痛い目を見た。

「このくらいでできます」って言ったタスク、
実際やったら想定の1.5倍かかった。

原因は技術じゃなかった。
相手の意図と、本当に困ってることを読みきれてなかった。

言葉通りに受け取って、その裏にある「なぜそれが必要か」を聞かなかった。
背景がわかってたら、もっと適切な提案ができたはず。

次から、見積もり前に「なぜこれが必要ですか?」を必ず聞く。
この一言で、ズレが防げる。
January 15, 2026 at 10:03 PM
【いつかやるか今やるか】
自分に自信が無い時って、
「自信がついたらやろう」と思っちゃいがちですよね。

私も、色々学びに走っていた時期がありました。

本当は恋人が欲しいのに、
本当はお金がもっと欲しいのに、
まだ語れる事がなくて自信が無いからと本当はやるべき事を後回しにしてしまう。
January 15, 2026 at 3:09 AM
おはよう。

今、請けてるプロジェクトが遅延してる。
メンバーにも負荷がかかってるし、資金的にもキツい。

正直、焦りと不安でいっぱいだった。
でも、その状態で動いても判断がブレる。

だから昨日、いつもより長く瞑想した。
「今」だけを見つめる時間を意識的に取った。

未来の不安も、過去の後悔も、一旦手放す。
焦ってるときほど、立ち止まる。

状況は変わってないけど、頭はクリアになった。
これで今日からまた動ける。
January 14, 2026 at 10:03 PM
【コードレビューのコツ】
✅ 小さな改善でも見逃さない

「まあ動くし、いっか」とスルーする前に、ちょっと立ち止まってみる。

✔︎ 小さなリファクタリングの積み重ねが、大きな品質向上につながる
✔︎ 「この変数名、もっと分かりやすくできないか?」の意識が重要
✔︎ 些細な改善を積極的に提案することで、より洗練されたコードに

「小さな違和感」を大切に。
その気づきが、チームのコード品質を押し上げる!
January 14, 2026 at 3:06 AM
おはようございます。

土日の使い方、今年から変えた。

去年までは「空いた時間で勉強」だったけど、
今年から「土曜午前だけ集中して、あとは完全オフ」にした。

理由は2つ。
・ダラダラやっても身につかない実感があった
・休息なしだと、平日のパフォーマンスが落ちてた

全部やろうとするより、「やらない」を決める方が難しい。
でも、決めたら楽になった。
January 13, 2026 at 10:03 PM
エンジニアとしてのスキルも、
対人コミュニケーションスキルも、
本質は実はあまり変わらなかったりする。

デザインパターンなんて覚えなくてもどうしたら人が理解しやすいか、読みやすいかを考えたら必然的にそのような形になってくる。
January 13, 2026 at 3:03 AM
おはよう。

昨日のMTGで反省したことがある。

クライアントから開発者に「このくらいなら明日の早い時間にできるよね?」と聞かれた場面。
開発者、その場で意見を言えなかった。

結果、朝4時まで頑張って出してくれた。
さすがに無理させてしまった。

すぐにねぎらいの言葉を伝えて、
「次から余裕を持った時間を提示してもらっていいよ」と伝えた。

クライアントにも、聞き方の注意を伝えようと思ってる。
「できるよね?」は、相手に断る余地を与えない。

間に立つ自分が、その場で空気を変えられなかったのが反省点。
次は開発者が言いやすい場を作る。
January 12, 2026 at 10:03 PM