チームをチームにするEM

人は集合するだけではうまく働けない。
メンバー同士のやりたいことや方向を揃えて、全員が成長できる環境、それが良いチームだと考えます。
私はマンガメディアチームでアプリケーションエンジニアとして長く働き、チームの初期から関わってきました。
エンジニアとしてチームにいた人間がEMになると、信頼関係や文脈を活かして強いチームを作ることができると考えます。
今日はチーム内EMの仕事を紹介します。

Transcript

1. チームをチームにするEM hitode909 2025.12.8 Hatena Engineer Seminar #35 「エンジニアリングマネージャー編」 1
2. やっていることは一緒 • エンジニアとして長く在籍していたチームで、チーム内EMに • 大きなキャリアチェンジに見えるけど、やっていることは一緒 • 今日は、この「地続き」の道のりと、チーム内EMの具体的な仕事を紹介します 2
3. 3 私のこれまで
4. 学生時代〜今まで • 学生時代 ◦ ペアプロが遊び ◦ 研修所を借りて開発合宿 • 新卒入社 ◦ ブログチーム ◦ インターンメンター ◦ アルバイトメンター ◦ 他人へのおせっかい ◦ 面倒見のいい人と言われてきた 4 インターン生におにぎりを持っていく様子(2012)
5. マンガメディアチーム • マンガビューワGigaViewerを開発 ◦ ビューワ＋連載ページ＋管理ツール ◦ 17社・26サービス（2025年11月時点）に導入 • チーム初期から在籍（2017年〜） ◦ 最初の1サービスの時期から 5 https://hatena.co.jp/solutions/gigaviewer
6. 関心の変化 • エンジニアとしての生活のなかでの変化 ◦ 関心の変化：技術→人→環境→文化 ◦ 活動範囲の広がり：人→開発ライン→チーム全体 • これらの関心や活動範囲の広がりを通じて、自ずとEMになった 6
7. 技術への関心から、人への関心へ • 技術が好き ◦ プログラミングが好き。行き詰まったら散歩して悟りを得て帰って来る • 技術を使う人に関心が出てくる ◦ 人間が揉めるとプロダクトが完成しない、リリースできない ◦ 技術的な問題は解消できるが、人間関係の問題はなかなか解消しない • 複数人での技術の使い方、向き合い方を揃えるための活動 ◦ 認識を揃えるための図、誰が書いても同じになるようなフレームワーク 7
8. 環境への関心 • シニアエンジニア(2017〜)やテックリード(2019〜2020)のロール ◦ 社員のメンターとして振る舞う ◦ 遠方メンバーと会話するため月1で出張 • チーム内エンジニア全員のメンターを担当 ◦ あちこちで話していると、誰がどんなことで困っているか把握できていく • 共通の困りごと ◦ ふりかえり会・KPT会のTRYなどを使ってボトムアップに環境改善 8
9. チーム文化への関心 • チームの特徴や文化について考える ◦ メンバー同士のことを、どのくらい分かり合っておきたいか？ ◦ 皆が信じられる目標とは？ • メンバーの自発やボトムアップだけで手を入れるには難しい領域も存在する 9
10. EMへの転機 • ディレクター交代にあたって、新ディレクターをエンジニア側から支援したい ◦ チーム内のエンジニアの様子見、新ディレクターへの橋渡し ◦ これまでの経緯やチーム事情などの案内、エンジニアとの通訳 ◦ 昼会で誰でもなんでも質問できる「よくわからなかったことコーナー」 • 半年ごとの人事評価で「EMの評価軸の方がしっくりくる」 • 今年2月からEM見習い、今年8月からEM • EMになることで、主語が私からチームに、責任を持って全員を巻き込む 10
11. 11` チーム内EMが目指すもの
12. 全員が全員を助け合う環境 • 開発、リリースといった短期的な成果だけではなく、長期的な成果を生み出す環境を重視 ◦ メンバー間が助け合い、成長できる環境 • 1on1で目標達成へのアクションを話し合う • 1on1on1でお互いの目標を見せ合い、助け合う ◦ 「この人はこんな目標だから、この人の支援のために私はこうします」 ◦ 「この人の成長のためにタスクのアサインを入れ替えよう」 • 締め切りも助け合い ◦ タスクを配りあうなどして、マイルストーンは守る ▪ 急にタスクを引き取れる関係づくり 12
13. チームの言語化 • チームビジョンを作成する過程で、メンバーの認識や方向を揃える ◦ チームの強み・弱み、どうなりたいか、をアンケート ◦ 定期的に見直し、全員で確認して刷新 • 環境の変化に強いチームを目指して、スローガンを「ロバストネス集団」に決定 • フレーズをこだわりすぎて、日常生活で使えないという課題もあり、現在見直し中 13
14. 14 3つの施策
15. 成長を軸にしたアサイン • 「誰に任せたら一番伸びるか」で仕事を決める ◦ 期日・品質と成長機会の両立 • 文脈と信頼があるから実現できる ◦ メンバーのこれまでの経験や、新しく直面する部分が分かる ◦ 過去のプロジェクトとの関連がわかる ▪ 技術的に、まったく新しい？似た構成のプロジェクトがあった？ ▪ 前のプロジェクトの進行ではどこで苦労した？ • 経験のあるメンバーには、アドバイス係として活躍してもらう • 簡単に達成できる仕事では、来たときよりも美しくなるよう応援 15
16. チーム主体のスプリント運用 • チーム主導での計画づくりのため、スプリントの整備 • スプリントの立ち上げ、ルール化、運用 • 認定スクラムマスター資格取得、メンバーにも促進 ◦ プロダクト開発の基礎知識として • チームのロードマップをメンテナンス • 新しい仕事をいつ始めるか、スプリント単位で計画できるようになった 16
17. 移譲を成長機会として活用 • 村制度：2〜3名のエンジニア＋企画で村を構成、村長が設計・技術判断 ◦ スプリント計画も、まずは村内で ◦ 見通しを持って開発し、村内助け合いができるようになった • デリゲーションポーカー：決定権の擦り合わせ ◦ 以前は忙しい時期は即断即決で、「こうしたらいいんじゃない？」を伝えていた ◦ 「助言する」から「尋ねる」に、移譲レベルを上げる ◦ A/B案ではなく「イチオシ案を持ってくる」練習 17
18. やっていることは一緒 • 関心の変化：技術→人→環境→文化 • 活動範囲の広がり：人→開発ライン→チーム全体 • やっていることは一緒：コードのデバッグ→チームのデバッグ • エンジニアからEMへのキャリア変更は地続き • EMだから特別なことはなにもない。個人としてではなくチーム目線で考える視線が大事 18