本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。
また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。
著者も機械翻訳を下地にしたやり方に関心をもたれたようです。
The article translated to Japanese: https://t.co/4uynyyhm4E
— Gergely Orosz (@GergelyOrosz) 2023年9月3日
The author was transparent and noted that the article is a modification of an ML-translated article.
This person managed to translate the article in maybe an hour, from me replying with "sure thing."
ここから本文です。
ビッグテックのプロジェクトマネジメントとスクラム不在の謎
プロジェクトマネジメントは、多くの人が強い意見を持っているテーマであり、私も例外ではありません。さまざまな企業がエンジニアリングプロジェクトをどのようにマネジメントしているのかという質問に答えるため、私は業界全体に協力を仰ぎました。本稿では次の内容を取り上げます。
- 業界全体のプロジェクトマネジメントのアプローチ。 100社以上が参加した調査の概要と重要なポイント
- ビッグテックにおけるプロジェクトマネジメント。 どのように行われているのか？ビッグテックの組織体制は、プロジェクトの遂行方法にどのような影響を与えているのか？
- ビッグテックにおけるスクラムの欠如。 なぜこの有名なフレームワークがビッグテックのほとんどで行われていないのか？
- あなたのチームではどのようにプロジェクトを進めるべきか？ 私の個人的な見解をお伝えしましょう
その前に、プロジェクトマネジメントのアプローチがいかに重要であるかを説明するのが難しい理由についての個人的な話をしましょう。
この記事は The Pragmatic Engineer Newsletter に掲載されたものです。このニュースレターは、とくに高成長スタートアップや大手テック企業のエンジニアリングマネージャーやシニア以上のエンジニアに関連するものです。このような記事を毎週お届けしますので 購読してください 。
Skype、スクラム、そして大切なことの再認識
私が Skype 社に入社した2012年、Skype 社はスクラムを全面的に取り組んでいました。すべてのエンジニアとプロダクト担当者は、アジャイルマニフェストの創始者の一人がファシリテートする最高クラスのスクラムトレーニングに参加させられました。Skype 社はスクラムを全面的に取り組み、数四半期をかけてすべてのチームをこの手法に移行させました。
そしてスクラムへの移行は Skype 社では成功とみなされました。Skype 社では、主要な Windows アプリの出荷がせいぜい四半期に1回だったのが、毎月出荷するようになりました。ほとんどのチームは 2～4 週間ごとになにかを納品していました。チームはスクラムマスターの役割を交代し、アジャイルコーチがチームへのフィードバックに訪れ、Skype 社を買収したばかりの Microsoft 社は、デリバリーの速度向上からインスピレーションを得ることに関心をもちました。
しかし、Skype 社がスクラムに移行する一方で、競合他社は冷酷に遂行していました。Whatsapp 社のことです。Whatsapp 社はずっと小さな組織でしたが、毎月のように市場シェアを削り、主要なコミュニケーションプラットフォームとなりました。
Skype 社とは異なり、Whatsapp 社はスクラムのようなフレームワークには手を出しませんでした。初期の従業員は、この言葉を口にしたことすらなく、重厚なプロセスを意図的に無視したことを話しています。Whatsapp 社は Skype 社を凌駕し、Skype 社よりも信頼性の高いメッセージング体験を構築し、最終的にメッセージングコミュニケーションアプリの戦いに勝利しました。
会社の成功とプロジェクトマネジメントのアプローチは必ずしも相関関係があるわけではなく、この話はそれを思い起こさせます。プロジェクトの進め方が重要ではないと言っているわけではありません。しかし、集中力、リーダーシップのアプローチ、プロセスがなくても人々がどのように働くかなど、成果にもっと大きな影響を与えるかもしれないものは他にもあります。
プロジェクトマネジメントは、複雑で変化し続けるパズルのピースです。しかし、プロジェクトマネジメントは最終目標ではなく、その目標に対してより早く到達する手段や要因に過ぎません。
業界におけるプロジェクトマネジメント手法
企業はどのようにプロジェクトを運営しているのか？私はアンケートを実施して100人以上の回答を得ました。結果は興味深いものでした。
企業がどのようにプロジェクトを管理しているかの結論は「場合による」というものでした。 これはあまり驚くべきことではありません。5人で設立されたばかりのスタートアップと、1,000 人でゆっくりと成長している非技術系の企業では、成功の見方は異なるのでしょう。非技術系の大企業のグループ内でも、斬新なアプローチを試すところもあれば、何年もうまくいっている同じやり方に固執するところもあります。
| "標準" の方法論はあるか？ | もっとも一般的なプロジェクトマネジメント方法論 (順番に) | 通常エンジニアリングプロジェクトのリーダーは誰か？ |
|---|---|---|
| ビッグテック & 公開会社のテック企業 | ||
| - チームが働き方を選択できる (通常) - 推奨された方法論はあるが、チームが選択できる (頻度は低い) |
1. プランニング → ビルド (イテレート) → リリース 2. "正式な" 方法論はない |
- テックリード - そのチームのエンジニア |
| ベンチャー資金によるスケールアップ企業 (シリーズ B 以上) | ||
| - 推奨された方法論はあるが、チームが選択できる (通常) - チームが特定の方法論に従うことが期待される (頻度は低い) |
1. プランニング → ビルド (イテレート) → リリース 2. "正式な" 方法論はない 3. カンバン 4. スクラム |
- テックリード - そのチームのエンジニア |
ベンチャー資金によるスタートアップ (シリーズ A まで) |
| - チームが特定の方法論に従うことが期待される (通常) - 推奨された方法論はあるが、チームが選択できる (頻度は低い) |
1. プランニング → ビルド (イテレート) → リリース 2. スクラム 3. カンバン |
- テックリード - 専任プロジェクトマネージャー - そのチームのエンジニア |
非ベンチャー資金調達型テック企業 |
| - チームが特定の方法論に従うことが期待される (大半) - 推奨された方法論はあるが、チームが選択できる (稀) |
1. スクラム 2. その他 (カンバン、SAFe、Scaled Agile) |
- テックリード - 専任プロジェクトマネージャー - そのチームのエンジニア |
非技術系の大企業 |
| - チームが特定の方法論に従うことが期待される (大半) - 推奨された方法論はあるが、チームが選択できる (頻度は低い) |
1. スクラム 2. SAFe 3. その他 (プランニング → ビルド → リリース、カンバン) |
さまざまである。 - 専任プロジェクトマネージャー スクラムマスター プロダクトマネージャー／オーナー テックリード |
コンサルタント企業 |
| - チームが特定の方法論に従うことが期待される (大半) - 推奨された方法論はあるが、チームが選択できる (稀) |
1. スクラム 2. "正式な" 方法論はない |
- 専任プロジェクトマネージャー |
私はこれらのカテゴリーに基づいて企業を分別しました。
- 公開会社のテック企業: テクノロジーを中核とする公開会社。これらの企業の多くは、以前はベンチャー資金を受けていた
- ベンチャー資金によるスケールアップ企業: シリーズ B 以上の資金調達を受けたスタートアップ。これらの企業は通常、少なくとも3億ドルの評価を受けており、積極的に成長しており、数年後のIPOを視野に入れていることが多い
- ベンチャー資金によるスタートアップ: プレシード、シード、シリーズ A の資金調達を行うスタートアップ。これらは一般的にビジネスモデルがあまり実証されていない成長企業である
- 非ベンチャー資金調達型テック企業: ベンチャー資金を調達しておらず、株式公開もしていない老舗テック企業。これらの企業は、ベンチャー資金を得た企業よりも積極的な成長目標を持っていないことが多い
- 非技術系の大企業: 技術を中核機能としない上場／非上場企業
- コンサルタント会社: 開発サービスを提供する会社
今回の調査で各社が使用した 方法論 は次になります。
- "正式な" 方法論がない: 公開企業やベンチャー企業に多い
- プランニング、ビルド、リリース: 公開企業やベンチャー企業に多い
- スクラム: 大企業、非技術系の企業、非ベンチャー資金調達型企業、コンサルタント会社に多い
- カンバン：すべての企業で言及されている
- SAFe (Scaled Agile Framework): 大企業、非技術系の企業、非ベンチャー系企業で言及されている
- Shape Up: 少数のベンチャー企業で言及されている
この調査では、いくつかの興味深い発見がありました。"1 (満足していない) から 5 (非常に満足している) の尺度で、現在のプロジェクトマネジメント手法にどの程度満足しているか／幸せか？"
考察に値する洞察 は次になります。この調査はサンプル数が non-representaitive (訳注: 十分な数ではない？) であるため、慎重に扱うようにしてほしい。とはいえ、これらは私が確認できる見解でもあります。
- 専任のプロジェクトマネージャーがいるチーム は、一般的に公開会社やベンチャー企業では満足度が低い。しかし、ベンチャー以外の企業やコンサルタント会社では、プロジェクトマネジメントに非常に満足している回答者が何人もおり、その理由として専任のプロジェクトマネージャーの存在を挙げている
- 自分たちの働き方を選択できるチーム は、公開会社のテック企業やベンチャー企業でより一般的でした。非技術系の大企業や、ベンチャー企業ではない中小企業では、社内の全チームに同じアプローチを義務付ける傾向が強い
- チームの自主性と高い満足度は相関関係にあるようにみえる。 満足度を4または5と評価した人の多くが、自律性、自由度、柔軟性、チームレベルでの品質第一主義をポジティブな点として挙げている
- 苦戦しているチームは、方法論とはあまり関係がないことが多い。 うまくいかなかった理由として、ビジョンの欠如、優秀なエンジニアの離職、透明性の欠如、ツールの不備などが挙げられている。このようなチームにとって方法論を変えても問題は解決しない
- JIRAはネガティブなイメージで語られることが多い。 JIRA に関する 13 の言及 は、すべてこの設定でした。JIRA をあまり使わずにものごとを成し遂げられることは、ポジティブなこととして言及されました。さらに、最近 IPO した高成長のテック企業が JIRA に移行し、エンジニアの間で調査を実施しました。その結果、ネット・プロモーター・スコア (NPS) は -83 となりました。これは驚異的に低く、エンジニアの 83% が JIRA に対してアドバイスすることを意味します。対照的な意見として、安定した成長を遂げているある公開会社のテック企業のエンジニアリングリーダーは、彼らの組織が JIRA に大きく依存し、ナレッジエンジンとして使用していることを共有しました。彼らの場合、組織が JIRA を完全に採用した後、JIRA は大規模な調整にうまく機能しています。Linear は、私の Uber の元同僚が共同設立した課題管理システムであり、私が投資しているスタートアップ のほとんどが採用を決定し、高く評価しているツールです。なお、私は Linear とは何の関係もなく、これを書くためにお金をもらったわけでもありません。
1または2の評価を残した回答者によると うまく機能しないプロジェクトマネジメントのアプローチ にはいくつかの特徴があります。
- チームがコミットした見積りにエンジニアが関与していないこと は、よくある、なかなか解決しない問題です。私の考えでは、これはエンジニアのやる気を失わせる最も簡単な方法の1つであり、何人かは退職してしまうほどです。
- 専任のプロジェクトマネージャーがいても、要件が変わること はエンジニアにとっては不都合なことです。要件の変更が多いチームもあるが、そのようなチームでは通常、エンジニアがプロジェクトをマネジメントし要件変更に対処できます。しかし、専任のプロジェクトマネージャーがチームを要件の変更から守ることができない場合、回答者はこのアプローチを悪いと評価しました。
- 失敗したプロジェクト管理手法を変更する自主性がないチームも、低い満足度を記録しました。 このような回答は、すべてのチームが同じ方法論に従うことを期待されている企業で顕著でした。これは指示的 (directive) リーダーシップの一例であり、このアプローチは、創造性がほとんど必要とされない職務ではうまくいくかもしれませんが、通常パフォーマンスの高いソフトウェアエンジニアリングチームを構築する方法としては不適切です。チームが一緒に反復 (イテレート) し、自分たちの言葉でプロセスを変えることができれば、満足度と生産性は向上します。
ビッグテックによるプロジェクトの進め方
ビックテックは、他の業界と比較して、技術プロジェクトを遂行するときの取り組み方が異なります。私は有名な公開会社のテック企業の人たちと話すことでデータを集めました。ここでは、彼らが一般的にどのようにものごとを進めているかを紹介します。
| 会社 | "標準" の方法論はあるか？ | もっとも一般的なプロジェクトマネジメント方法論 (順番に) | 通常エンジニアリングプロジェクトのリーダーは誰か？ |
|---|---|---|---|
| Amazon | いいえ。チームが選択できる | プランニング (6-pager) → ビルド (イテレート) → リリース | テックリード |
| Apple | いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリード |
| Datadog | いいえ。チームが選択できる | プランニング (RFC) → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリードまたはエンジニア | |
| いいえ。チームが選択できる | プランニング (Design Doc) → ビルド (イテレート) → リリース | テックリードまたはエンジニア | |
| Netflix | いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| Shopify | いいえ。チームが選択できる | GSD (Get Shift Done, 6-weeks cycles) → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| Spotify | いいえ。チームが選択できる | プランニング (ERD) → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| Uber | いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
ビッグテックは、エンジニアがプロジェクトを遂行する方法において、いくつかの特徴を共有しています。
- ほとんどのプロジェクトは エンジニアがリードしています 。テックリードか、チームのエンジニアがリーダーになります。ソフトウェアエンジニアがどのようにプロジェクトをリードしているか については、こちらをご覧ください
- チームはプロジェクトマネジメント手法を自由に選択できます。 多くのチームは RFC のようなプランニングプロセスを採用し、ビルドを繰り返し、数週間以内にすべてをリリースします。他のチームは、よりカンバン方式に近いプロセスで、優先順位の高い項目から取り組みます
- チームレベルのプロジェクトに 専任のプロジェクトマネージャーはいません。 ほとんどの企業では、複数のチームが関わる大規模プロジェクトや、組織をまたがるプロジェクトには、テクニカルプログラムマネージャー (TPM) が介入します。Uber では TPM とエンジニアの比率は 1:50 程度でした。TPMについてもっと読む
- プロジェクトマネジメントの成果物やプロセス は、同じ組織内でもチームによって異なります。ほとんどのチームはプロジェクトバックログを持ち、チームが適切と考える間隔でスタンドアップを行い、時々レトロスペクティブを行います。
- このようなところでは、 一流の開発者用ツールが与えられるのは当たり前 であり、短いイテレーションサイクルにおいて大きな役割を果たしています。多くのチームはメインブランチで作業し、CI/CD システムから素早いフィードバックを受け、作業中の機能をすぐに他のチームメンバーと共有できます。
ビッグテックで働いたことのある人にとっては、この多くはおなじみのことでしょう。しかし、これと同じアプローチを伝統的な企業で真似しようとしても、おそらく失敗するでしょう。というのも、ビッグテックの組織構造は、チームがどのように遂行できるのか、そして遂行するのかに大きな影響を与えるからです。
ニュースレター
私の 週刊ニュースレターを購読して 、ソフトウェア・エンジニアリング業界についての考察や深堀り記事を毎週読んでください。このニュースレターは Substack の No.1 技術ニュースレターであり、このような声が寄せられています 。
プロジェクトに影響を与えるビッグテックの組織構造
ビッグテックがどのようにプロジェクトを管理しているかを理解するために、一歩下がって、これらの企業の多くが活動している環境を見てみましょう。シリコンバレーがソフトウェアエンジニアについて、伝統的な企業にはない "理解" を得ていること という記事で詳しく解説しています。
ソフトウェアエンジニアとチームの自律性。 伝統的な企業で開発者に期待されるのは、与えられた仕事をこなすことです。シリコンバレーのような企業では、ビジネスが抱える問題を解決することです。これは大きな違いです。このことはエンジニアの日々の生活に影響を与えます。
好奇心旺盛な問題解決者であり、頭を使わないリソースではない。 やる気のあるエンジニアは、言われたことしかやらない「工場労働者」の何倍もの影響力を簡単に生み出します。工場労働者のような態度の組織では、このアプローチは意図的に解釈の余地をほとんど残さない、より重厚なプロジェクト管理アプローチに偏るでしょう。
内部データ、コード、ドキュメントの透明性。 エンジニアに限らず、社員はしばしばリアルタイムのビジネス指標やデータソースにアクセスし、独自のクエリーを作成したり、カスタムレポートを作成したりできます。
ビジネスやビジネス指標に触れる。 エンジニアは、ビジネスの他の部分と交流し、非エンジニアとの関係を構築することが奨励されます。対照的に、伝統的な企業では、開発者が他のビジネス部門と交流することを不可能にしていることが多いです。
三角形のコミュニケーションよりもエンジニア間のコミュニケーション。 伝統的な企業は、情報の流れを遅くし、意思決定を遅くする階層的なコミュニケーションを奨励します。
フラストレーションの少ない開発者体験への投資。 エンジニアが迅速に問題を解決することを重視する企業は、様々なプラットフォームチームを立ち上げ、開発者の離職率を低下させます。
高いレバレッジによって正当化される高い給与。 エンジニアをうまく活用している企業は、市場のトップクラスに近い、あるいはそれ以上の給与を支払うことをいとわないです。
優秀な人材の採用。 このような企業は、上記のすべての組み合わせのおかげで、高い能力と高いモチベーションを持った人材を採用しています。これらの企業は、手厚い報酬体系と強力なキャリアアップの機会で知られているため、多くの人材から選ぶことができます。
エンパワーメントされた自律的なチーム は、これらすべての企業の構成要素です。またテック業界の多くの企業にとって、差別化の鍵となる要素でもあります。
ビッグテックのすべてのチームが完全にエンパワーメントされるわけではないが、これらの組織は、先進的な考えを持つスタートアップとともに、チームが可能な限りエンパワーメントされるようにする方法を実施することに最も近いです。
明確なオーナーシップをもつチーム は、ビッグテックのもう一つの構成要素です。5～15人で構成される各チームには、明確なビジョンとミッションがあり、それを実行するためのスキルと自律性があります。そのミッションとは、ホスピタリティ製品のプロダクトチームであれば「高齢者のためのワールドクラスの予約体験を構築する」であったり、プロダクトプラットフォームチーム であれば「労力をほとんどかけずに評価体験を統合できるようにチームを強化する」であったりします。
プロダクトに特化したチームは、通常、バックエンド、フロントエンド、モバイルエンジニアのようなクロスファンクショナルなチームメンバーで構成され、プロダクトマネージャー、データサイエンティスト、デザイナーもチームに加わることが多いです。プラットフォーム重視のチーム は、クロスファンクショナルでもなく、特定のドメインに縛られない傾向があります。
エンジニアが高度な専門性をもっていても、ビッグテックでは経験豊富なソフトウェアエンジニアの多くが幅広いエンジニアリング業務をこなせることを期待されており、面接プロセスにもこのジェネラリスト的アプローチが反映されていることに注意してください。
プロダクトマネージャーのはい／いいえ
ビッグテックとその他の企業とのもうひとつの不思議な違いは、プロダクトマネージャーの役割であり、チームに専任のプロジェクトマネージャーやプロダクトオーナーがいないことです。
これらの企業におけるプロダクトマネージャーの役割は、チームにおける戦略を定義すること、つまり「なぜ」です。そして、この戦略を実行するためのステップが「どのように」です。Facebook 社のプロダクトマネージャー Will Lawrence は このように表現しています 。
プロダクトマネジャーの役割は、どのようなゲームをどのようにプレーするか を考えることだ。戦略とは、我々がプレーするゲームを選択することである。投資する価値のある分野を見つけ、このゲームで成功するための説得力のあるビジョンを描くことだ。(...) 遂行とは、私たちがどのようにゲームをプレーするかということである。ミッションに向かって前進するための日々のプロセス、決断、行動である。
プロダクトマネージャーは、チームが正しいことに取り組み続けることを保証します。これは、ビジネス、データサイエンス、デザインと協力し、ロードマップを作り、計画を立て、仕事の優先順位をつけ、必要に応じてエスカレーションすることを意味します。大企業ではこれ自体がすでにフルタイムの仕事です。
多くの場合、大企業ではプロダクトマネージャーはプロジェクトマネジメントを担当しません。チームが遂行に責任を持ち、チームのリーダー (通常はエンジニアリングマネージャー) がこれを実現する責任を負います。
権限を与えられた自律的なチームでは、プロジェクトをトップダウンで管理することはほとんどありません。各チームによって異なりますが、私はエンジニア間でプロジェクトリーダーの役割を交代させることで、チーム全員がリーダーシップを発揮できるようになり、大きな成功を収めました。購読者は、🔒 プロジェクトリーダーの期待事項 にアクセスできます。
専任のプロジェクトマネージャーがいないことから、いくつかの疑問が生じます。エンジニアはプロジェクトマネジメントで手一杯なのか？プロジェクトを管理することは、エンジニアの時間を有効に使うことなのか？これらはすべて可能であり、私の見解は次になります。
チームレベルのプロジェクト では、専任のプロジェクトマネジャーがいない方が、結果的にプロセスを簡素化し、個人的な関係を強化できます。エンジニアのプロジェクトリーダーは、自分たちの利益のために、できる限りプロセスを増やしません。また、他のチームと協働する際にも、プロジェクトマネージャーを介さずに、プロジェクトを率いる他エンジニアや製品を所有するエンジニアとの関係を構築します。このようなエンジニア同士のコミュニケーションは、複数のプロジェクトマネージャーを介するよりも効率的です。
異なるオフィスやタイムゾーンにまたがる複数のチームにまたがる複雑なプロジェクト では、そのようなプロジェクトのリーダーはエンジニアにとってフルタイムの仕事になります。ビッグテックでは、こうした複雑で、しばしば戦略的なプロジェクトを管理するために、テクニカルプログラムマネージャー (TPM) を導入し、エンジニアの負担を軽減しています。
大手テック企業には、専任のプログラムマネジャー やプロジェクトマネジャーがまだ存在します。彼らは通常、対外的なコミットメントや顧客 (アップルとのパートナーシップのためのプログラムマネージャーなど) 、あるいはコンプライアンスプログラムのような長期的な構想と結びついている。TPM が単一のエンジニアリングチームに割り当てられないのと同様に、プログラムマネージャーやプロダクトマネージャーもエンジニアリングチームを持たず、多くのチームにまたがって仕事をします。
ビッグテックにおけるプロダクトマネージャーの役割が、多くの企業におけるプロジェクトマネージャーやプロダクトオーナーと、どのように異なるかを示す要約が、Facebook 社のプロダクト・マネージャー Ben Erez のツィートから伺えます。
In >1 year as a PM @ Facebook I've created zero tickets/tasks. We don't do sprints either.
— Ben Erez (@ViableBen) 2021年7月28日
PMs here focus on vision, strategy & partnerships. Less on project management & tasks.
Engineers carry most of the project management responsibility & create their own tasks.
It's great.
Facebook の PM として1年以上働いているが、チケットやタスクを作成したことはない。スプリントもやりません。
ここの PM はビジョン、戦略、パートナーシップにフォーカスしている。プロジェクトマネジメントやタスクはあまりやらない。
エンジニアはプロジェクトマネジメントのほとんどの責任を担い、自分たちでタスクを作成する。
素晴らしいことだ。
プロダクト重視の環境とスクラムの廃止
私が Skype 社で働いていたとき、スクラムチームがスクラムを完全にやめてしまうのを目の当たりにしました。私が Skype for Web チームに参加したとき、当初は2週間のスプリントを行い、通常のスクラムプロセスに従っていました。またソフトウェアエンジニアと QA に特化したエンジニアに分かれ、Microsoft 社内では Software Development Engineer in Test (SDETs) と呼ばれていました。しかし、チームのリリースサイクルは2週間ごとでしたが、私たちはもっと頻繁にリリースしたいと考えていました。
最初にやったことは、QA をエンジニアリングの一部にしたことです。"古い世界" のやり方では、エンジニアは自分の仕事を終えてブランチにチェックインし、チケットを更新して QA にレビューの準備ができたことを伝えます。QA は1日か2日後にこのチケットを受け取り、レビューし、問題が見つかればチケットをリオープンします。これは長時間の遅延でした。
私たちは、非公式に静かな変更を行い、すべての SDETs が本番用ソフトウェアも構築し、すべてのソフトウェアエンジニアが自分のコードをテストする責任を持つようになりました。これでコードを本番環境へリリースする前にフィードバックを何日も待つ必要はなくなりました。しかし、隔週のスプリントと数々のスクラムのセレモニーが次の問題となりました。
スクラムが日々のリリースの邪魔になったのでした。 スクラムの全体的な考え方は、スプリントを中心に展開され、スプリントの最初にタスクにコミットし、スプリント中にそれらに取り組み、最後にやったことをデモするというものです。
このプロセスは不自然で、動きの速いウェブチームからは押し付けられたかのように感じられました。私たちはすぐにカンバンアプローチを取り入れました、より流動的な働き方に移行しました。私たちはスプリントを気にするのをやめ、スクラムにつきもののセレモニーもほとんどやめました。私たちは、今何に取り組んでいるのか、そして次に何をするのかを知ることだけに集中しました。
インフラと開発者ツールは、多くのスクラムのセレモニーを不要にしました。 プロダクトオーナーへのデモ、作業の承認、そしてリリースといったスクラムのセレモニーは、いくつかのことを前提としています。
- プロダクトオーナーは、作業が仕様通りに行われたことを確実に検証できる人であること
- プロダクトオーナーが仕様書を書いていること
- 承認を行わずに成果物が本番環境にリリースされることありません
しかし、私たちの環境では、これらの前提にはしばしば欠点がありました。私たちが書いたコードはすべて単体テストでテストされ、必要に応じて統合テストやエンドツーエンドテストも行われました。私たちは、フィーチャーフラグで隠してコードをリリースし、チームへの新機能の導入から始めて、段階的な導入を経て検証しました。多くの "仕様" やチケットもエンジニアによって書かれ、エンジニアはそれが期待通りに動くかどうかを検証することができました。CI/CD、フィーチャーフラグ、実験ツールのおかげで、プロダクトオーナーに頼るよりも速いフィードバックサイクルが可能になりました。
ビッグテックの多くは、一流のインフラと開発者向けツールが、エンジニアリングチームの生産性に大きな違いをもたらすことを認識しています。これが、エンジニアリングの 30～40 ％がプラットフォームチームで働くことが多い理由であり、Uber がプラットフォームチームに多額の投資をした理由です 。ファーストクラスのインフラとプラットフォームがすぐに使える状態であれば、チームはインフラをどのようにセットアップするかとか、サービスをどのようにコンプライアンスに対応させるかといったことよりも、中核となる仕事の目標に集中できます。プラットフォームチームについて、私は次のように考えています。
プラットフォームチームは組織の効率を向上させます。(...) 規模を拡大し、素早くスケールアップするためには、プラットフォームチームは必須となります。(...) しかし、プラットフォームチームは直感的に導入できるものではありません。ビジネス視点の眼鏡でプラットフォームチームを見ると、ほとんど意味がありません。確かに、小規模な組織、あまり成長していない組織、うまく機能している構造を持つ組織では、プラットフォームチームは意味をなしません。
チームのメンバー全員が、私たちがなにを作っているのかを非常に明確に理解していました。 私たちの最終目標は Skype のウェブ機能をリリースすることでした。このアプローチはいくつかのサブプロジェクトから構成されていましたが、全体像はチームにとって明確でした。プロダクトマネジャーがハイレベルな戦略を設定し、私たちエンジニアがやるべきタスクをピックアップし、それを遂行しました。私たちは、スクラムの邪魔な部分を削ぎ落とすのに十分な権限を与えられていました。しばらくすると、残されたものはまったくスクラムではありませんでした。
スクラムの先へ
Facebook、Whatsapp、Google、Netflix や同様の組織のエンジニアと話すと、彼らのほとんどはスクラムを実践したことがありません。なぜか？それにはいくつかの理由があります。
有能で自律的な人材は、信頼できる質の高いアウトプットを生み出すために、より少ない構造しか必要としません。 大手テック企業は、このような人材を惹きつけ、余裕をもたせ、雇用できます。
有能なチームを活用するには、彼らに働き方を選択する自由を与えることが必要です。 これはほとんどの種類のエンジニアリングに当てはまることであり、官僚主義を減らして自律性を高めるという スカンクワークス のモデルが、優秀な人材を擁する多くの高業績チームが最終的に従うことになります。そこにはそれなりの理由があるのです。
エンジニアリング組織のスケーリングは、チームレベルのプロセスをはるかに超えるものです。 これらの組織に生産性に関する課題がないとは言わないが、これらの課題のほとんどは、重量級のプロセスで解決できるものではありません。これらの企業が取り組んでいる課題には次のようなものがあります。
開発者の生産性。 エンジニアがインフラの問題に振り回されたり、依存関係の問題を回避したりする代わりに、チームの目標を達成するためのコードを書く時間を増やすにはどうすればいいのだろうか？プラットフォームチームはその一助となるアプローチだが、ここではさらに多くのことを解明する必要があります。これについては、今後のニュースレターで取り上げる予定です。
技術とアーキテクチャの負債を返済する。 ビッグテックはどの会社も動きが速く、新しいチャンスに素早く対応します。そうすることで、企業はしばしば近道をし、技術やアーキテクチャの負債を抱えることになります。このような負債を「ビッグバン」と呼ばれる技術負債返済プロジェクトではなく、日常的なプロセスの一部として賢明な方法で返済するにはどうしたらよいだろうか？
組織の目標にあったチーム構造。 会社や下部組織の目標は定期的に変化します。チームの結束を乱すことを最小限に抑えながら、どのようにチーム構造にその変化を反映させることができるだろうか？
イノベーションと予期せぬ仕事のための余剰時間。 イノベーションを期待されているチームにとって、それを実現するための余分な時間をどのように作るか？
エンジニアリングチームの成長にあわせてペースを維持する。 エンジニアの数が増えれば増えるほど、多くのエンジニアに影響を与える意思決定やコミュニケーションにかかるオーバーヘッドも増えます。組織の規模が2倍になった後も、同じ速さで前進し続けるにはどうすればいいのだろうか？組織の規模に関係なく、チームが軽快さを保ち、迅速に動くためのプロセスや構造の選択とは？
耐久性のある卓越性。 どうすれば組織全体の処理能力を向上させながら、エンジニアも満足し、改善点が長期にわたって持続し、複合的に作用し続けることができるのか？「耐久性のある卓越性」という言葉は Will Larson による記事「Staying on the path to high performing teams」から引用しました。
スクラムの擁護
ビッグテックの多くがそうしているからと言って、企業はスクラムやその他の方法論を否定すべきなのだろうか？それは間違いです。
スクラムに切り替えることが完全に理にかなっており、生産性の向上につながるコンテキストはたくさんあります。 Skype 社は、この変更が会社の役に立った例であり、Whatsapp 社は Skype 社がどのような方法論を使ったかに関係なく、おそらくコンシューマー向け通話分野で勝利していたでしょう。
スクラムが良い選択肢となる状況をいくつか挙げてみましょう。
1. キッチンシンクチーム あらゆるものがこのチームに投げつけられます。一般的にスクラムのような重量級のプロセスでステークホルダーを管理することが勝利につながると気付きます。ステークホルダーは、進行中のスプリントを中断することはできないし、新しい機能要求には手入れが必要であることを理解するように教育されます。相反する優先順位を持つチームは、スプリント構造によってチームがこれらの中断を無視するスペースを与えられるおかげで、中断を少なくして遂行できるようになります。
"キッチンシンクチーム" は、非技術系の企業では典型的なもので、ビジネスがエンジニアリングの仕組みを理解していません。スクラムは、利害関係者をコントロールし、ソフトウェア開発プロセスについて教育するのに役立ちます。また初期段階のスタートアップ企業でもよく見られますが、そこでは1つのエンジニアリングチームがすべてを構築します。
"キッチンシンクチーム" は、プロダクトチームがあまりにも多くの責任を負わされる場合にビッグテックにおいてもたまに現れます。どのような場合でも、スクラムのようにチームに息抜きのスペースを与えるプロセスに移行することは、非常に理にかなっています。しかし、チームが自律し、権限を与えられるようになると、チーム憲章を更新する代わりに、チームが所有しない仕事にはチームメンバーがすぐにノーと言えるようになることが多くなります。
2. 新しいチームの「形成期」と「混乱期」の段階。 心理学者の Bruce Tuckman は、グループがどのように機能するかについての段階として「形成期、混乱期、統一期、機能期」という言葉を考え出しました。このモデルは、ほとんどのエンジニアリングチームがどのように進化していくのかにも適合します。
新しいチームが結成されたとき、そのチームはどのように仕事をするかを決める必要があります。スクラムのような既成のアプローチに手を出すことは、ほとんどの場合、お互いによく知らないメンバーがカスタムプロセスを考え出すよりも、あるいは全く考え出さないよりも、より良い選択です。スクラムのような文書化されたアプローチを採用することは、"正しい仕事の進め方" について相反する、または互換性のない意見をチームメンバーがもっている場合にも有効です。
スクラムの良いところは、レトロスペクティブがプロセスの一部であることです。これにより、チームは自分たちの仕事のやり方を振り返ることができます。時間の経過とともに、作業スタイルを変更する自主性を持つチームは、通常、必要のない重量級のスクラムルールをやめ、カスタムな作業スタイルを開発するようになります。
3. リリースを数週間に1回の頻度にスピードアップする。 この頻度がスプリントの長さを超えない限り、スクラムは週単位のスプリントとともに、チームがより頻繁なリリースに移行するのを助けます。デジタルファーストではない多くの組織にとってこのような加速は大きな勝利です。
リリースのスピードアップは、Skype 社が 2012 年にスクラムに移行した大きな理由の1つです。移行前は、チームは数ヶ月に1回リリースしていました。移行後、各チームは月に 1～2 回出荷するようになりました。これ以上の頻度でリリースすることになったチームは、スクラムをやめることを決めたチームです。
4. プロジェクトの進捗報告を統一することが必須と考えられている企業。 スクラムと JIRA は密接な関係にあり、JIRA ほど組織レベルのレポーティングに適したツールはありません。私は多くの組織がスクラムを導入し、リーダーシップチームがチームをより可視化し、支援が必要なチームを特定できるようになることを期待していることを見てきました。
統一されたレポーティングとチームレベルの優先事項への掘り下げは、Skype 社のリーダーシップもスクラムへの移行で見た利点の1つでした。当時 Skype 社でアジャイルコーチをしていた Chris Matts 氏は Strawberry-Jam-O-Meter と Wrong-Order-O-Meter をどのように実装したかを話してくれました。
Strawberry-Jam-O-Meter は、進行中のバックログ項目が最も多いチームを特定するために使われました。 Jerry Weinberg の "ストロベリージャムの法則" にヒントを得ました。Wrong-Order-O-Meter は、プロダクトオーナー組織が指定した組織全体のバックログに従って、間違った順序でアイテムに取り組んでいるチームを特定するために使われました。
私の個人的な見解では、権限委譲されたチームがいる組織では、目的および主要な結果 (OKR) 、主要業績評価指標 (KPI) 、目標は、報告のためにスクラムのような厳格な方法論を展開するよりも、チームを調整するためのはるかに優れたツールです。しかし、権限を与えられていない組織、チームや個人が自律的でない組織では、スクラムは代替案よりもうまく機能するかもしれません。
どのようにチームを運営すべきか？
さまざまな段階にある企業が、それぞれ異なるアプローチでプロジェクトを運営する傾向があること、また大企業はこのプロセスをうまく機能させるために多くの組織的サポートをもっているが、大企業が一般的に単一のアプローチを義務付けていないことを見てきました。
チームをどのように運営するかは、その企業の状況によって異なるはずです。関連する要素には、組織構造、一緒に働く人々、その人々の自主性とスキル、競合、「戦時」か「平時」かが含まれます。数え上げればきりがありません。
思考の糧として、次のアイデアを残しておきましょう。
反復的な変化は「ビッグバン」的な変化よりも常に効果的である。 リリースが非常に遅いことに悩んでいたヨーロッパのテック企業が、新しいエンジニアリング担当副社長を雇いました。この人物は、就任後数ヶ月で組織全体を NoEstimates 方式に移行させることを決めました。彼らは大きなイベントを企画し、ロックバンドを雇い、新しい仕事のやり方を発表しました。その後の数週間、数ヶ月は大混乱となり、組織は以前のやり方に逆戻りしました。
誰かに釣り方を教えるのは、その人のために魚を釣るよりも大変なことなのだ。 プロジェクトマネジメントに対する私のアプローチは、チームのメンバーを指導し、プロジェクトリーダーになるよう指導することでした。その結果、チームはより多くの成果を出し、人はより早く成長し、より早く昇進し、その人たちは同業者よりも早くエンジニアリングリーダーになりました。このアプローチは、権限を与えられた環境における私の最善の決断のひとつでした。購読者は、私の blueprint ドキュメント にもアクセスできます。
ディレクション、メンタリング、コーチングにはそれぞれ用途がある。 指示すること、つまり何かをする方法を正確に指示することは、彼らが自分でできるのにマイクロマネジメントになってしまいます。しかし、そうでない場合はサポートになります。指示するのか、指導するのか、コーチするのかによってアプローチを選び、人やチームの能力に応じてスペースを与えます。時間が経てば、指示することはほとんどなくなるはずです。しかし、最初はそうする必要があるかもしれません。
意思決定に必要な人数が少なければ少ないほど、意思決定を迅速に行うことができる。 あるエンジニアが、あるエンジニアと話をするだけでよいのなら、そのエンジニアがプロジェクトマネジャーと話をし、そのプロジェクトマネジャーがまた別のプロジェクトマネジャーと話をし、そのプロジェクトマネジャーがまた別のエンジニアと話をし、そのエンジニアがまた別のプロジェクトマネジャーと話をし......といった具合に、エンジニアがプロジェクトマネジャーと話をする必要がある場合よりも、その決断は早くなるでしょう。
レポーティングを最適化することは、信頼性の低い環境を最適化すること。 幹部レベルでのレポーティングは重要です。しかし、レポーティングのために重たいプロセスを追加するようなプロジェクトマネジメント手法を導入すれば、プロセスが増え、信頼が低下し、どんなレポーティングを作成しようとも、人々がギャンブルをするようになります。
コンサルタントは、自分の価値を証明する最も簡単な方法であるため、測定しやすい結果を出すことに偏る。 測定しやすい結果がよい目標であれば、コンサルタントは良い投資となります。ただ、それが価値ある目標であり、方向性が正しいことを確認してください。
直接の競合相手から学ぶことは過小評価されている。 動きの速い競合他社がやっていることを理解し、似たようなことを試してみるのは、非常に賢いやり方です。競合他社の同業者とコーヒーを飲むことは、プロとして、また人脈作りのための投資として素晴らしいものになります。
優秀なエンジニアの中には、マイクロマネジメントされるくらいなら辞めたいと考える人もいる。 とくに雇用市場が熱く、転職が容易なときには。
私のアンケートへの回答から関連する言葉を引用します。
最近、Cレベルのエグゼクティブが、すべてのチームに対して仕事のやり方を強制し始めた (全員が同じ方法論に従う必要がある) 。その結果、多くのエンジニアが辞めていきました。
私は、他の人たちからインスピレーションを得て、実験し、反復し、人々がやる気になるような信頼性の高い環境に向かっていくことを勧めます。これは 私が行ったこと であり、チーム、会社、そして私自身という全員の利益のために、チーム内のすべての人が成長できるような体制を整えた方法です。
推奨記事
- Execution at Facebook by Will Lawrence
- Staying on the path to high performing teams by Will Larson
この記事のレビューに協力してくれた Adriaan, Alexandra, Alex, David と Steve 氏に感謝します。
本稿のオリジナルの記事は次になります。
