ロクモン@バックエンド専門のEM
@ToBeFreeFromJob
バックエンド専門のEM｜Go × AWS × 組織改善
現場でGoを書きつつ、EMとして「強いチーム」を模索しています。
｜技術探求： AWSの運用/Goの実践知
｜組織改善： チームビルディング・育成・採用・プロダクト開発
｜🚀 176人→500人目指して発信強化中！
205 フォロー中 188 ファン
耳が痛い。エンジニアとして知識を増やす楽しさに溺れ、アウトプットを後回しにした結果、成長が遅れた苦い経験がある。本を読むことが目的化すると危険。現場の課題を解決するために読み、自分の問いに変えて手を動かす。このサイクルがないと知識は自分の血肉にならないと実感している。
もっと見る
「勝算があるからやる」ではなく「失敗しても資産が残るからやる」という思考への転換。誰もが避ける泥臭い領域や、手を出したがらない課題に小さくエントリーして進めていく。これこそが打率に依存せず、確実に自分の希少性を高めていくエンジニアの生存戦略だと確信しています。
もっと見る
Webクローラの設計で一番シビアなのがシードURLの選定。大学サイトの全件なら大学ドメイン一択だけど、Web全体が対象になると一気に難易度が上がる。クローラがいかに効率よくリンクを巡回できるか、URL空間を地域特性などで小さく分割していく戦略が結局一番手堅い。
もっと見る
非常に良い話。成功の裏には必ず、誰かがやってくれた泥臭い作業や誰もが嫌がる仕事が存在します。これを単なる「雑用」で終わらせず、組織を支える重要な基盤だとメンバー全員が誇りを持てるように言語化し、評価していくのがマネジメントの役割だと強く感じます。
もっと見る
正直に言うと、私も働くのが苦痛で、一番マシだと思ったからエンジニアの道を選んだ。ただ、やっていくうちに新しい知識をインプットして実践する面白さに気づき、自然と情熱が育っていった。最初から「これが好き」でなくても、目の前の課題にコミットすることで天職に変わることは本当にある。
もっと見る
URL短縮の文字数を7文字にする理論根拠：62の7乗で約3.5兆通り作れるから。実装時、ハッシュ切り出し＋衝突判定ループだとDB負荷がキツいのでブルームフィルターを入れるのが定石。でも一意の分散IDを発行してBase62変換するアプローチの方がシンプルで堅牢な設計になりがち。
もっと見る
経営者側が「本音が見たい」と言うのも真実ですが、受ける側が「どこまで本音を出していいか」悩むのも当然のリアルですよね。特にハイクラス層ほど組織の課題をリアルに察知するからこそ、ネガティブの伝え方のバランスに迷う。完璧な答えを追う前に「課題への向き合い方」を言語化したい。
もっと見る
4人から2人に減った途端、役割を決めること自体が「押し付け」や「罰ゲーム」のように感じてしまう。まさに引用の通り、構造の不在を自分の対人エネルギーで補填しようとしていた。少人数だからこそ、感情を挟まずに回るルールが必要。今週中に雑用をすべて洗い出し、機械的な仕組みに変える。
もっと見る
URL短縮サービスを作る時の設計知識。301は「恒久的な移動」だからブラウザがキャッシュして2回目以降はサービスを経由しない。一方302は「一時的な移動」だから毎回サービスを経由する。アクセス分析（計測）を行いたいなら毎回リクエストが届く302を選ぶのが定石。
もっと見る
失敗したときに「自分は能力が低い」と凹む人に足りないのは、能力ではなく『分解の技術』。起きた事実だけを直視し、自分がコントロールできる可変要素を見つけ、次の一手を1つだけ決める。このステップをマネジメント側が伴走してあげるだけで、人は驚くほど打たれ強くなる。
もっと見る
繰り返す問題を自分で片付けるのは最大の罠という言葉が刺さる。作業をどう振るかではなく、それが1回限りか繰り返し起きるかという基準が抜けていた。今後は何度も起きることはメンバーに任せる仕組み化へ全振りする。目先の早さより長期の組織設計を意識していこう。
もっと見る
毎秒数万件のツイートを捌くID生成の裏側のXのSnowflakeアプローチはIDをビット単位で分割管理する。符号1、時間41、データセンター5、マシン5、シーケンス12。12bitのシーケンス番号がミリ秒内の衝突を防ぐ。シンプルで無駄のない分散設計の教科書。
#システム設計面接#
もっと見る
上司の仕事を巻き取り、言いにくいことを代わりに言う。これって短期的には自分の評価に直結しないから損に見える。でも、これを続けていると周囲からは「実質的なリーダー」として見られ始める。役職は後からついてくる。まずは役割を自分で作りにいくのが、実は一番確実なキャリアアップの道。
もっと見る
まさにタイムリーな話題。弊社でもメンバーの目標設定において「会社からの目標（トップダウン）の必要性」が議論に上がっています。目標管理がワークしている組織が、具体的に「誰が何をどこまで決めるか」をどう設計しているのか、他社のリアルな事例や運用方法をぜひ知りたいです。
もっと見る
OKRを導入した。
KPIを設定した。
MBOを見直した。
それでも目標が機能しない。
────
フレームワークの問題じゃない。
「誰が何を決めるか」が
設計されていないからだ。
────
目標管理が機能しない組織の共通点：
・目標は経営が決める
・手段は現場が考える
・判断基準は誰も持っていない
・振り返りは結果だけ見る
────
この構造では
どんなフレームワークを使っても
同じことが起きる。
現場は「とりあえず動く」
経営は「なぜ達成できないのか」
中間管理職は板挟みで消耗する。
────
目標管理に必要なのは
新しいフレームワークじゃない。
「この判断をした人間が
この結果に責任を持つ」
Decision Rightsの設計だ。
────
ツールを変える前に
構造を変えろ。
目標管理が機能しない理由は
フレームワークじゃない。
Decision Rightsがないだけだ。
もっと見る
Cassandraの書き込みと読み込みのパス。書き込みはコミットログとMemtable（メモリ）へ瞬時に行われ、溢れるとSSTableとしてディスクにフラッシュされる。読み込みはメモリになければブルームフィルターで対象のSSTableを高速に絞り込む。無駄のない美しい設計。
#システム設計面接#
もっと見る
仕組みで解決するアプローチ。他者比較の罠を防ぐため、月1on1で「過去にどんなスキルを活かせたか」を本人の言葉で書かせる運用を徹底している。比較対象を「過去の自分」にロックすることで、自然と自分の強みや成長に視点が向く。マネージャーの口癖だけでなく仕組み化もセットで効く。
もっと見る
資料が出てこない時、ただ待つのはお互いに損失。メンバーがクオリティを気に病んで抱え込んでいるなら、マネージャーの動くタイミング。「10%の出来でいいから一度見せて」と声をかける文化を作りたい。進捗を詰めるのではなく、途中で手放しても安全だと思える環境作りが何より大事。
もっと見る
大規模システムの障害対策三種の神器。
①ゴシッププロトコル：ハートビートの更新頻度でノードの死活を自律的に検知。
②いい加減なクォーラム：障害サーバーを無視して健全なノードで読み書きを継続。
③ヒンテッドハンドオフ：復旧後に変更を先送りして一貫性を担保。
もっと見る
仕事の悩みが頭から離れない人は、とにかく「別のことで脳をハックする」しかない。自分にとっての正解は筋トレとマラソンだった。この記事で紹介されているGemini Liveの英会話練習は、低コストで脳を強制終了させる新しい選択肢として試す価値がかなり高そう。
もっと見る
バグ調査が長期化するとき、サポートチームへの進捗共有を「何時までに一報入れるか」まで約束できる人は信頼される。調査に集中して抱え込むと、周囲の不安を煽ってしまう。「だろう」で進めず、相手の安心を作るために時間を区切って報告する。これだけで評価される側の動きになる。
もっと見る
