はてなブックマーク

この登壇の中で伝えたかったことのひとつに、「採用の前提が変わりつつある」という話がある。 今回はその中でも エンジニア採用市場における変化 について、自分の考えをまとめてみたい。 採用における前提が書き換わりつつあるこれまでは、「このスキルがあるから採用」「実装力があるから採用」というように、一定の技術力があることが前提として求められていた。 しかし、GitHub CopilotやCursor、さらにはDevinなどの出現により、エンジニアの“生産性の前提”が大きく変化し始めている。 Before： 個人のスキルに依存していた コーディングや設計、レビューなどもすべて人力 インプット量や経験年数で成長が測られていた After： AIが知識や経験を補完する タスク実行や設計支援はAIとの共創になる AIを活用できるかどうかがパフォーマンスに直結する つまり、これまでのように「この言語で5年

人はツールや方法論ではなく、信頼できるリーダーについていくと思う。アジャイルもガントチャートも結局は人間関係のツール。最も価値あるスキルは ・悪い知らせを早く伝える勇気 ・困難な状況でも冷静さを保つ姿勢 ・チームの貢献を可視化する能力 まだまだできていない事ばかりなんで頑張る！ — すぅ| PM & PdM🐈 (@suh_sunaneko) April 4, 2025 これはほんとにそうで、「実際にやってること」と「やってると認識されていること」って、全然違ったりする。 特に、目立たないけどめちゃくちゃ助かってる貢献って、往々にして埋もれがちなんですよね。 “見えてること”だけが成果として扱われてしまう現実たとえば、プロジェクトで炎上を防いだ予防的な動き。 メンバー間の関係性を整えた地味なフォロー。 エンジニアじゃなくても動けるけど、誰かがやらないと詰まる雑務の引き受け。 これらは、事後

PM（プロジェクトマネージャー）とEM（エンジニアリングマネージャー）って、よく混同されがちだけど、実際には役割も視点も結構違う。 最近、「結局この2つの違いってなんなんだろう？」と考えることがあったので、まとめてみる。 1. ゴールの違いまず、2つのマネージャーの「ゴール」が全然違う。 PMは「プロジェクトの成功」を目指す スケジュール通りに進んでいるか 予算内で収まっているか スコープは守られているか とにかく、「決められた期間・予算・スコープの中で、プロジェクトを成功させる」のがPMの役割。 EMは「チームと組織の成長」を目指す メンバーのスキルが伸びているか チームの生産性が上がっているか チームの心理的安全性は確保されているか つまり、「持続的に成果を出せるチームを作ること」がEMの役割。 PMは「短期的なプロジェクトの成功」を追い、EMは「長期的なチームの成長」を追う。 この違

「ファシリテーション」というと、「会議をスムーズに進める技術」と思われがちだ。 確かに、議論を整理し、参加者の意見を引き出し、時間内に結論を出すのは重要なスキル。 でも、本質的にはファシリテーションは「会議を回す技術」ではなく、「問題解決・合意形成を進めるためのリーダーのスキル」 だと思う。 1. ファシリテーションのゴールは「会議を回すこと」ではない会議をスムーズに進めても、結局何も決まらなかったら意味がない。 むしろ、「会議がうまく進んだ」=「良いファシリテーションだった」 とは限らない。 本来のファシリテーションの役割は、 適切な問いを立て、チームが考えるべき方向性を示す 議論を深め、問題解決のための意思決定を促す 合意形成を支援し、関係者の納得感を高める ことにある。 だから、「時間通りに終わった」「発言がスムーズだった」ではなく、 「本当に必要な結論が出せたか？」が重要になる。

企業経営にはPL（損益計算書）経営とBS（貸借対照表）経営のバランスが重要と言われる。 PL経営は売上・利益を最優先し、短期的な成長を重視する。 BS経営は資産・負債・投資を意識し、長期的な企業価値を高める。 事業のフェーズによって、どちらにフォーカスすべきかが変わる けれど、 現場レベルでは「PLもBSも経営の話でしょ？」と感じることもある。 ただ、エンジニアリングマネージャー（EM）として組織を支える立場でも、このバランスを意識して動くことが重要 だと思う。 じゃあ、PLとBSのバランスを取るために、EMとして何ができるのか？ そんなことを考えたので、まとめてみる。 1. PL経営とBS経営、それぞれの視点でEMの役割を考えるEMの役割は「エンジニア組織のパフォーマンスを最大化すること」。 そのために、PL的な視点とBS的な視点の両方で考えることが大事になる。 PL経営の視点（短期的な

プロダクト開発を進めていると、「PdM（プロダクトマネージャー）とEM（エンジニアリングマネージャー）の距離感ってどうするのがベストなんだろう？」 という問題にぶつかることがある。 PdMはプロダクトの方向性を決める人 EMはエンジニアリング組織をマネジメントする人 と役割は分かれているけど、完全に分業するわけでもない。 近すぎると「どっちが決めるの？」みたいな話になり、 遠すぎると「開発がプロダクトの意図を汲み取れない」という問題が出てくる。 結局、PdMとEMの距離感は「どこまで重なるべきか？」 というバランスの問題なんじゃないかと思う。 そんなことを考えたので、まとめてみる。 PdMとEMの距離が近すぎるとどうなる？PdMとEMがガッツリ関わりすぎると、こんな問題が起こりがち。 1. PdMが開発に口を出しすぎる 「この仕様、こう作ったほうがいいんじゃない？」 「技術的にはこっちのほ

エンジニア採用の難易度が年々上がっている。 いい人材はどこも取り合いで、求人を出したからといって簡単に応募が来る時代ではない。 そんな中で、「ジンジニア（人事 + エンジニア）」という役割が注目されるようになってきた。 エンジニア採用に特化した専任のポジションを置くことで、よりスムーズな採用活動ができるのでは？という考え方だ。 ただ、エンジニア採用専任のジンジニアを置くことには賛否がある。 「そんな役割が本当に必要なのか？」 「エンジニアが自分で採用活動をすればいいのでは？」 今回は、エンジニア採用専任のジンジニアは本当に必要なのか？を考えてみる。 エンジニア採用の「普通の人事」では難しいポイントエンジニアの採用は、一般的な職種の採用と比べても特有の難しさがある。 技術の理解がないと、求職者と適切なコミュニケーションが取れない 言語やフレームワーク、技術スタックの理解がないと、候補者が「こ

エンジニアリングマネージャー（EM）をやっていると、「どこまで現場に関わるべきか？」 という問題にぶつかることがある。 開発の細かい仕様や技術選定にまで踏み込むべきなのか、それとも組織づくりや戦略に集中すべきなのか。 どっちかに偏りすぎると、 「マネジメントだけやっていて、現場のことが全然わかってない人」 「プレイヤーに近すぎて、マネージャーとしての役割を果たせていない人」 みたいになりがち。 ということで、「EMはどこまでプロダクトチームの現場をキャッチアップすべきか？」 についてまとめてみる。 EMの役割と現場理解のバランスEMの役割は、大きく分けると 「チームの成果を最大化すること」 に尽きる。 このために、次の2つの軸をバランスよくやる必要がある。 プロダクトと技術の理解（現場の知識を持つ） チームの環境づくり（組織やメンバーの状態を整える） どちらかに偏ると、以下のような問題が出