ロクモン@バックエンド専門のEM
@ToBeFreeFromJob
バックエンド専門のEM｜Go × AWS × 組織改善
現場でGoを書きつつ、EMとして「強いチーム」を模索しています。
｜技術探求： AWSの運用/Goの実践知
｜組織改善： チームビルディング・育成・採用・プロダクト開発
｜🚀 176人→500人目指して発信強化中！
222 フォロー中 202 ファン
ちょっと複雑だけど、ここでしか使わないから問題ない。そう思っていた時期が私にもありました。気づけば他の機能からも依存され、条件分岐がネストしまくり、完全に制御不能なバベルの塔が建っていた。どう成長するか予想すらできなかった自分の未熟さに絶望。
#エンジニア初心者#
もっと見る
エンジニアとして成長が早い人は「反省の解像度」が高い。失敗した時にただ自分を責めるのではなく、ネガティブな感情を事実として受け入れた上で、「次からどうすれば防げるか」を建設的に解釈している。自責でエネルギーを枯渇させず、継続するためのシステム思考を持てるかが成長の分かれ道だ
もっと見る
自己研鑽が続かない原因は気合に頼るから。大事なのはやる気がない日も動ける仕組み化です。私も「1日最低20分の読書」だけは死守すると決めています。たとえ不調な日が1週間続いても結果的に月2冊は読破でき、実務のアウトプットに直結する。最低ラインのルール化が成長の底上げになりますね
もっと見る
「これが唯一の正解だ！」と信じて疑わずに書いた数年前の自分のコード、今見ると負債の塊すぎて当時の自分を小一時間問い詰めたい。ソフトウェアに絶対の正解なんてなくて、あるのはその時の妥協の産物だけなんだと思い知らされる日々。
#エンジニア初心者#
もっと見る
リーダーになりたてだと「完璧でなければ」と焦り、つい周囲にも厳しく接してしまいがちです。私も過去に同じ失敗をしました。しかし引用元の①②のように、自分の小さな失敗や不安を素直に開示できるようになって初めて、本当の意味でチームを任せられる一人前のリーダーになれた気がします。
もっと見る
技術的負債を経営に説明する時、伝わらない原因は専門用語だけではない。過去の自分もそうだが「エンジニア自身が漠然とした不安を抱えるだけで、何が問題か分かっていない」ことが多い。相手にわかる言葉へ翻訳する前に、まず自分の頭のなかにあるリスクを具体的に整理することが本当に大事になる。
もっと見る
エンジニアの説明が通らないのは、仕組みから話し、用語を重ね、壊れたときの絵を見せないから
エンジニアは「どう動くか」から考え、経営層は「何が変わるか、リスクは」から考える
このズレで、聞き手は理解する前に「概念税」を払わされる
下げる技術は3つ
① 専門用語は1文に1つ（10秒で2つ置くと離脱）
② 用語 → ふつうの言葉 → なぜ重要か
③「これが壊れたら、誰が何を見て何を失うか」を1文足す
正確さ × 明快さ = 最強の翻訳者
もっと見る
「綺麗に書けた」と満足していた昔のコード。今見たら、変数名や関数名がトリッキーすぎて自分自身が騙された。未来の自分に「どう？このスマートな実装」とサプライズを仕掛けたつもりだろうが、今の自分にはただの負債でしかない。当時の自分を正座させて説教したい。
#エンジニア初心者#
もっと見る
「タスクは明確だけど目的を説明できない」まま振って、メンバーと衝突する失敗を何度もした。「目的を1文で書けないなら任せる段階ではない」は至言。丸投げは相手への信頼ではなく、マネージャー側の言語化のサボりだ。1行の目的を添えるだけで、作業の依頼は権限委譲に変わる。
もっと見る
「人は説明するまでわかってないことに気づかない」はマネジメントの真理。だから私は、タスクを振ってメンバーから質問がない時ほど「今の内容を私に説明してみて」とお願いしています。大抵は説明に詰まるので、そこを補足してから作業に入ってもらう。これで後工程での大きな手戻りが防げます。
もっと見る
本番障害の原因調査をしたらAPIの入力チェック漏れ。「フロントで必須にしてるから」とサボった自分のコードだ。ユーザーは想定外の手段で簡単に壁を越えてくる。バリデーションをサボった代償として、膨大なログ解析という苦行をさせられている。
#エンジニア初心者#
もっと見る
設計や技術選定の提案にビビって手が止まるのはエンジニアあるある。そんな時は「最悪どんな批判を受けるか」を紙に書くと冷静になれる。一方で退屈な運用作業には「15分で終わらせる」というタイムボックスが効く。不安は言語化で、退屈は制約で対処する。元ポストの解像度の高さに深く共感。
もっと見る
エンジニア組織でもよくある。本人は技術的に難易度の高い仕事を完遂した。しかし、会社の売上に直接レバーを引いたのは別の動きだった。評価会議で「どちらを上に置くか」を議論する時、マネージャーは個人の頑張り以外の外部要因も考慮せざるを得ない。この構造をどう納得してもらうか。
もっと見る
目標シートには、こう書いてあった
・月に10社、新しい会社を訪問する
・提案書を毎月3本つくる
・社内勉強会に毎月参加する
部下は、半年間すべてを達成していた
一方で、課長がA評価をつけた別の部下は
訪問件数が月に6社しかなかった
ただ、その6社のうち2社から、大きな契約が取れていた
課長が評価していたのは、契約につながったかどうかだった
それ自体は、間違っていない
会社が求めているのは、売上だからだ
問題は、それを一度も部下に伝えていなかったことだった
部下は、目標シートに書かれた数字を
半年間、まっすぐに追いかけていた
訪問件数を守るために
契約になりそうな会社に時間をかけるより
次の会社を回ることを選んでいた
もっと見る
新人の頃、ログ設計を適当に済ませていた。「動くんだからいいじゃん」と。でも本番で障害が起きた時、システムの内部状態を知る術がなくて青ざめた。勘だけで原因を特定するエスパー対応の連続。エラーなしを完璧だと勘違いしていたあの頃の自分に本番運用の恐ろしさを叩き込みたい
#エンジニア初心者#
もっと見る
LMSの課題は受講者が自発的に学んでくれないこと。解決策は学ぶ意欲を高めることではなく、コンビニのように「つい」寄ってしまう習慣を作ることにある。3年後もメンテできる保守性の高いコードを書くように、ユーザーの日常に長く定着してメンテされ続ける「習慣の設計」を組み込んでいきたい。
もっと見る
人事ルールに「なぜこの手順なのか」を改めて問い直すことは非常に重要。ただ、いざ見直そうにも人事部門のリソースが慢性的に不足しており、改善に着手するまでの時間が最大のネックになっているのが現場のリアルな実感。
もっと見る
昔はデカいコードにそのまま処理を追加して、さらに巨大化させる最悪のループにハマっていた。要件が増えるたびにコードがモンスター化して手遅れに。追加する時こそ、コードを小さく分けるべきだったと反省。
#エンジニア初心者#
もっと見る
作業手順だけ覚える人と、仕組みまで理解する人の差はここに出る。指示された通りに動くだけだと、ちょっとやり方が変わった瞬間に手が止まる。最初から完璧な効率化を求めず、あえて「一箇所だけ変えて動かす」実験を挟む方が、結果的に成長スピードは何倍も速くなる。
もっと見る
情報をどれだけ集めても、それ自体では不安は消えない。大事なのは「情報を増やすこと」ではなく「自分の判断に繋げること」。ニュースに振り回されて調べるループに入るより、事実と因果を切り分けて一歩目を決める方がずっと価値がある。
もっと見る
昔の自分はビジネスの関心事と技術的な関心事を混ぜて書き、テストが一切書けない黒歴史コードを量産していた。あの頃の自分を本気で止めに行きたい。DIを活用して関心事をきっちり分離し、テストしやすい状態を保うのが本当に大切。
#エンジニア初心者#
もっと見る
「とりあえずスキル」で会社を選ぶ若手は多いが、事業の「客単価」と「シェア」が低い会社は危険。安い客ほど理不尽な要求が多く、シェアが低いとプロダクトの改善サイクルが回らない。良い給与と良い開発環境は、結局こうした事業構造の土台の上にしか成り立たない。
もっと見る
