- 100社を超えるビッグテック企業を調査した結果
- ビッグテックのプロジェクト管理方式を整理すると ⇨ 「ケースバイケース（It Depends）」
- 多くは決まった方法論や業務方式を持たず、チームが自分たちに合うものを選択
- 上場企業や資金調達を受けた企業では専任PMがいることへの満足度が低かった一方、資金調達を受けていない場合は満足度が高かった
- チームの自律性と満足度には高い相関がある
- 問題を抱えるチームも、方法論自体より、ビジョンを十分に示せないことや、透明性・ツール不足などが悪化の理由だった
- JIRAには否定的な回答が多かった
- うまくいかなかったプロジェクト管理の方法
- エンジニアがプロジェクト期間の見積もりに参加しない
- 専任PMがいても要件が変更される
- 失敗したプロジェクト管理手法を変える自律性がないチームは、満足度が低かった
- ビッグテックがプロジェクトを進める方法
- エンジニアがほとんどのプロジェクトをリードする
- 決まった方法論はなく、チームが自由に選べる
- チーム単位のプロジェクトには専任のProject Managerはいない。複数チームまたは全社が関わる大きなプロジェクトにはTechnical Program Managerを置く。Uberではおよそ1:50の比率
- 一級の開発者ツールが与えられ、これが短いイテレーション周期に大きく影響する
プロジェクトに影響を与えるビッグテックの組織構造
- 基本的な環境
- エンジニアとチームが自律性を持つ
- 無自覚な労働力（工場労働者）ではなく、好奇心のある問題解決者である
- 社内のデータ、コード、文書が透明に公開されている
- エンジニアもビジネスやビジネスメトリクスに触れている
- 階層的なコミュニケーションではなく、エンジニア対エンジニアのコミュニケーションで素早く進む
- 失望の少ない開発者体験に投資する
- より高いレバレッジで正当化される、より高い給与
- より優れた人材を採用できる
- 権限委譲され、自律的なチーム
- 明確なオーナーシップを持つチーム
Product Manager はYes、Project Manager はNo
- プロダクトマネージャーの役割は「What game we're playing」と「How we're going to play it」を把握すること
- 多くの場合、ビッグテック企業のプロダクトマネージャーはProject Managementをしない
- チームが実行責任を持ち、多くの場合は技術マネージャー（チームリード）がプロジェクト管理を担う責任を持つ
- 権限委譲され自律的なチームでは、プロジェクト管理がトップダウンになることはまれ ⇨ 全員で一緒に進める
- 専任のProject Managerがいないときに気になる点
- チーム単位のプロジェクト：プロセスを簡素にし、個人間の関係を強化する
- 複雑なプロジェクト：ビッグテックはTechnical Program Manager（TPM）を置く
- 専任のProgram Manager / Project Managerが存在することもある。一般には外部、顧客、長期実行計画などとの接点に結び付く
- プロダクト中心の環境でスクラムをしない理由
- スプリント単位で進めるスクラムは、素早くデプロイする状況にはあまり適していない
- インフラや開発者ツールが、スクラムの多くの活動を代替してくれる
- ビッグテック企業は、インフラや開発者ツールへの投資が生産性向上をもたらすことを理解している
- Facebook、Google、Netflixなどはスクラムを使わない。なぜか？
- 有能で自律的な人材には、こうした構造がそれほど必要ない
- 有能なチームにどう運営するかの自由を与えれば、彼らをレバレッジできる
- エンジニアリング組織をスケールさせることは、チームレベルのプロセスをはるかに超える
- だからといって、誰もがビッグテックにならってスクラムをやめるのは間違い
→ スクラムを使うのが適切な状況はあり、より高い生産性を出せることもある
- キッチンシンク型チーム：1つのチームがあらゆることを解決しなければならないとき（初期段階のスタートアップ）
- 新しいチームを立ち上げる時点
- 数週間ごとに一度デプロイする場合
- 統一された形式のプロジェクト進捗報告を必須にしなければならない場合
チームはどう運営すべきか？
- 反復的な変更は「ビッグバン」型の変更より常によい
- 魚を与えるより、魚の釣り方を教えるほうが難しい
- 指示（Directing）、メンタリング、コーチングにはそれぞれ用途がある
- 指示とは、本人たちが自力でできるはずだができないときに限って、補助的にマイクロマネジメントすること
- 意思決定に必要な人が少ないほど、より速く決められる
- 報告に最適化することは、より信頼の低い環境に最適化することでもある
- コンサルタントは測定しやすい結果を提供することに偏りがちであり、それが自分たちの価値を証明する最も簡単な方法だからだ
- 直接の競合他社から学ぶことは過小評価されている
- 優秀なエンジニアの中には、マイクロマネジメントされるくらいなら辞めることを選ぶ人もいる
8件のコメント
「JIRAはほとんどが否定的な反応だった」
どんな形式であれ、イシューを管理することは必要だと思いますし、私自身もJIRAに否定的だったので、あえて別のツールも試してみました（GitHub Issues、Trello、Asana など）。
ですが、やはり古いものにはそれだけの良さがあるのか、結局JIRAに戻ってきました……
ただ、もっと良い方法があるのではないかと、今でも考え続けています。
どういう点で、古いもののほうが優れていると思われたのでしょうか？
私はYouTrackが好きです。JetBrainsが作ったPMツールで、私に必要な範囲ではプロジェクトを管理できるんですよね。
私たちのチームはLinearに乗り換え、全体的な満足度がかなり上がりました。一度検討してみることをおすすめします。
この製品のようですね、https://linear.app/。興味深そうです。
私が利点だと感じる部分は
このくらいだと私は感じています。
大手テック企業はどのようにプロジェクトを進めるのだろうか
ファーストクラスの開発者ツールは何をするものなのでしょうか？
原文の雰囲気を生かすためにそのまま持ってきたのですが。
現時点で組織が提供できる最高の開発者ツールだと言えそうです。