自律的なチームを作るためにTechPMがやらないこと

2026/10/30 Technical PM を語る夜 のLT資料です

Transcript

1. #JDDLayerXTPM Technical PM を語る夜 自律的なチームを作るために TechPMがやらないこと Technology & Development Div. Naoki Yo shitake 2026.10.30 © 2026 Japan Digital Design, Inc. 1
2. 自己紹介 経歴 • SIerでPM/アーキテクトを約10年経験。2023年11月から現職 • 生成AIプロダクトのTechPM • エンジニアチームのLead（ピープルマネジメント、チーム運営、組織マ ネジメント）、社内AI推進・ガバナンス整備、他PJアドバイザーも兼務 資格/出版 • 『AWS認定資格試験テキスト AWS認定SysOpsアドミニストレーター – アソシエイ ト』 • 『AWS vs Google Cloud アプリ開発七番勝負』 ※同人誌 Naoki Yoshitake Technical Project Manager Japan Digital Design © 2026 Japan Digital Design, Inc. 2
3. アイスブレイク エンジニアやアーキテクトの経験がある方？ © 2026 Japan Digital Design, Inc. 3
4. TechPMの職責とチーム TechPMの職責 プロジェクトを成功に導く チームのパフォーマンス そのためには プロジェクトが成功するための要因 TechPMの振る舞い それを左右するのが 今日の話 チームとの関わり方が成否を左右する TechPMの振る舞いがチームのパフォーマンスを上げる。チームがプロジェクトの成功に寄与する。 本日は、TechPMとエンジニアの役割分担のお話をします。 ※ 私がピープルマネジメントを兼務していることもあり、その目線も入るのでご了承ください。 © 2026 Japan Digital Design, Inc. 4
5. チームの実績 2026年上半期、チームが残した成果 高いリリース頻度と品質を両立している。 リリース回数 リリースしたテーマ テストで新しく見つかったバグ 15回 約60テーマ 67%減少 6ヶ月間の本番リリース 細かな内部改善やライブラリのバー 5〜6月と7〜9月の比較。 ジョンアップを含めるとさらに多数 4月は対応テーマの特性もあり除外 © 2026 Japan Digital Design, Inc. 5
6. 生産性が高いチームとは 自己組織型チーム （自律性の高いチーム）は生産性が高い 書籍 『世界一流エンジニアの思考法』 ⚫ TechPMになった直後に読み感銘を受けた一冊 牛尾 剛（文藝春秋、2023年） ⚫ 米マイクロソフトのエンジニアが、 自己組織型チームの強さを説いている。 第5章「生産性を高めるチームビルディング」 第5章で心に残った3つのこと 1 指示と管理で動かすより、自己組織型チームへ 2 リーダーはビジョンとゴールを示し、進め方はチームが決める 3 自己組織型チームは、生産性も満足度も高い 書籍の「自己組織型チーム」＝ 今日の「自律性が高いチーム」 © 2026 Japan Digital Design, Inc. 6
7. 研究のファクト：DORA チームの裁量の大きさは、 パフォーマンスと関連する ⚫ Google Cloudの研究チームであるDORAは、 4年分のState of DevOps Reportを分析し、 デリバリー性能を高める24の能力を例示 ⚫ 24のうちチームの裁量に関わる能力も含まれる チームが自分でツールを選べる 外部の承認なしに、 チームで実験や仕様変更ができる ツールを自分で選べるチームは、デリバリー性能が高い傾向がある ※ 相関を示した結果で、因果関係までは示していない 出典：Forsgren, Humble, Kim『Accelerate』（IT Revolution, 2018） 邦訳『LeanとDevOpsの科学』（インプレス, 2018） © 2026 Japan Digital Design, Inc. 7
8. 私の失敗談 ただ、自律的なチームを目指しても うまくいかないことがある 私が過去にやってしまった2つのこと © 2026 Japan Digital Design, Inc. 8
9. 失敗1：作り方まで決めた チームをリードしようとして 技術的な実現方法まで決めてしまった ⚫ AIを使った新規アプリケーションを、 0→1で開発したプロジェクト TechPMがエンジニアチームに伝えていたこと What / Why 要件とビジネス上の背景。ここを伝えるのはTechPMの役割 ⚫ 要件と背景だけでなく、技術的な実現方法まで TechPMが考えてからエンジニアチームに渡していた How 決めすぎた 例：「PDFがダウンロードされた回数を数える」という要件 → ダウンロードの方式や回数の記録方法までコメントしていた 結果 エンジニアが自身で考える余地が狭くなり、 自分で決めて作る楽しさを奪っていた © 2026 Japan Digital Design, Inc. 9
10. 失敗2：レールを敷かなかった 任せているつもりが、 放置になっていた ⚫ 「細かく指示しないこと」「管理しないこと」を 「自律」だと思っていた。 TechPMが決めていなかったこと 1 全員が同じ方向に進むための仕組み 例：どこまでドキュメントを作るか、 ⚫ 全員が同じ方向に進むための仕組みや 品質を積み上げる段取りを整えられていなかった。 FrontendとBackendの認識合わせをどうやるか、その場作り 2 品質を積み上げる段取り 例：テストについて、どの環境で、何のデータで、 どういう方法で行うか、メンバーの認識がバラバラだった メンバーの経験が異なれば、進め方のイメージも異なる © 2026 Japan Digital Design, Inc. 10
11. 結果と気づき 結果 気づき 開発開始から2か月弱で大幅に遅延 決めなくていいこと 部門全体で対策することに 最終的には他チームに応援を頼み、 なんとかリリースできた 失敗1の裏返し 詳細な実現方法 → エンジニアが考えて決める 決めるべきこと 失敗2の裏返し ゴール、制約、品質を積み上げる段取り チーム全員の進め方に対する認識をそろえる 自律性が高くても、向いている方向がそろわなければ、パフォーマンスは上がらない。 © 2026 Japan Digital Design, Inc. 11
12. では、どうするか では、TechPMは何を決めて、 何を任せるのか 失敗から学び、今のチームでやっていること © 2026 Japan Digital Design, Inc. 12
13. やるべきこと：レールを整える レールの幅 行き先 （ゴール） 走り方 不確実性の高い要因は早めに検証 TechPMが整える 設計と開発 タスク量が多い工程はスケジュールに余裕を持たせる 行き先 ＝ プロジェクトのゴール レールの幅 ＝ 守るべきQCDと、プロジェクトの制約（非機能要件を含む） 段取り ＝ 品質を積み上げるために、どこで何を確かめ、どこに時間を取るか エンジニアが決める 走り方 ＝ 技術的な実現方法（設計と実装） TechPMはレールを整え、走り方はエンジニアに任せる QCDに大きく影響しない範囲なら走り方は自由でよい。TechPMは、方向がずれていないかを見て、品質を積み上げる段取りを組む。 © 2026 Japan Digital Design, Inc. 13
14. 実際にやっていること 万事徹底：走っている方向が合っているか チーム内の認識が一意に揃うレベル ⚫ 進捗確認、議事録など当たり前のことを徹底する。 全てについてネクストアクションを確認する。 ⚫ ミーティング後、結局どうなったのかを 全員が一意に理解できる状態を作る 1 常に逆算して進捗を把握する テストやリリースなどのマイルストーン・工程に対して、 ネクストアクションは何かを確かめる 2 確認するのは行き先とレールの幅が正しいか 自律してゴールに向かっているか、レールの内側にいるかは確かめ る。 走り方には口を出さない。エンジニアに自分でタスク化してもらう。 3 ③への対応で入れているプロンプト 一意に伝わる文章で整理する 全員が一意に理解できる文章を書くのは意外と難しい。 AI議事録も、納得できなければ自分で書き直す © 2026 Japan Digital Design, Inc. 14
15. 任せると何が良いか エンジニアが自分で決めると、 生産性が上がり個人の成長も早まる ⚫ 冒頭の実績（15回のリリース、約60テーマ）も、 メンバーが自分たちで考えて動いたことが大きい ⚫ 任せた範囲のミスや回り道は受け入れる。 プロジェクトの課題やQCDへの影響が出ない限り、 口を出さない 1 自分で決めると進むのが速い 自分で決めたことは、指示を待たずに考えて進められる 2 失敗から学びエンジニアが成長する 人から注意されるより、自分で試して失敗したほうが身につく 3 レールがあるから安心して失敗できる 段取りの中で早めに気づける失敗は成長の機会になる © 2026 Japan Digital Design, Inc. 15
16. TechPMが力を発揮するところ PJ全体のコンテキストとバランスを考慮して、 技術的な判断を行う 例：セキュリティ・コンプライアンス・ガバナンスが絡む要件を どう実現するか、エンジニアやセキュリティ部門と一緒に考える ⚫ 任せても技術に関与しないわけではない ⚫ 機能の作り方はエンジニアに任せる。 アプリ、インフラ、ビジネス要件をまたぐ判断は、 TechPMが全体を見て行う。 システムの層 アプリ ⚫ 個人的にはアーキテクト的な思考が必要な印象。 ミドルウェア インフラ 全体を見て判断すること どの層で何を防ぐか セキュリティは多層防御 どこでどれだけ性能を出すか インフラとアプリの両方で どこまで作り込むか コストと事業の将来性を見て © 2026 Japan Digital Design, Inc. 16
17. チームへの任せ方はグラデーション チームに任せる TechPMが深くリードする 技術面も走り方も、自分で引っ張る レールを定め、走り方は任せる チームが成長するにつれて、任せる側へ移していく 立ち上げ期（0→1）のチーム どこに立つかを決める要素 安定してきたチーム 決まっていないことが多い プロジェクトのフェーズ レールが固まってきた メンバーのスキルや経験もバラバラ メンバーのアサイン メンバーのスキルや経験がそろってきた 今日の話 スキルセットと経験 どこまでリードするかは、チームの状態で変わる 本日お話ししたのは、安定してきたチームでのやり方。 TechPMには、技術で深くリードする力とチームに任せる力の両方が必要。 © 2026 Japan Digital Design, Inc. 17
18. まとめ TechPMがやらないこと2つ 決めるべきことは決め、決めなくていいことは任せる。 1 2 作り方を決めすぎる 「自律」という名の放置 走り方はエンジニアに任せる レールはTechPMが整える © 2026 Japan Digital Design, Inc. 18
19. さいごに 本日の内容は、小倉広さんの研修から大きな影響を受けています 参考書籍 小倉広『優れたリーダーはアドバイスしない』ダイヤモンド社、2025年 © 2026 Japan Digital Design, Inc. 19
20. Thank you. © 2026 Japan Digital Design, Inc. 20