チームに 150 人を参加させることはできますか?ファストアジャイルはイエスと答える

FAST アジャイルは、私がここしばらく学んだ中で最も興味深い組織実践です。今日は、FAST アジャイルとは何かを共有し、それを実験する価値があるかどうかを探ります。 TL;DR?非常に説得力がありますが、まだ実験的です。

ファストアジャイルとは何ですか?

1. FAST Agileはアジャイル ソフトウェアのバリアントです。 FAST は、非常に大規模なチーム内の自己組織化に焦点を当てています。このような大規模なチームはコレクティブと呼ばれます。数名から最大 150 名までの場合があります [1]。

週に 2 回、コレクティブは集まります。ミーティングにて：

• チームメンバーは、自分たちがどのような進歩を遂げたかを示し、伝えます。
• プロダクト リーダーはビジョンを繰り返し説明し、方向性を設定します。これらはトッププロジェクトに関するコンテキストを提供します。作業が完了するか、優先順位が変更されると、新しい優先順位が導入されます。そして通常、優先順位は壁や仮想的な同等物に視覚的に表示されます。
• コレクティブ内の人々は、最優先の仕事を遂行するために自己組織化し、自己選択して小さなチームを作ります。

FAST アジャイルの最も興味深い部分は、これらの自己組織化チームです。そのため、これについてもう少し詳しく説明します。

会議ごとに、人々は自発的にチームをリードし、人々は自発的にそれらのチームに参加します。誰かがチームの管理者を志願するとき、彼らは前に出て、「私は（トッププロジェクトの1つ）に取り組むつもりです」と言います。その後、人々は作成されたチームに参加し、その分野で作業します。チームの最小人数は 2 人であるため、チームを結成するには「自分の足で投票」する人が必要です。

結成されたチームは次のことを行いますいいえ製品が定めた優先順位に従う必要があります。たとえば、デプロイ パイプラインの改善や不安定なサービスの監視の改善を中心にチームを結成できます。

人々は、週に 1 時間の会議以外の時間のほとんどを、自分で選択し、自分で組織したチームで過ごします。理論的には、週に 2 回チームを変更することもできます。しかし実際には、人々は最終的に誰と一緒に働きたいのかを見つけ、チームは最初の 1 か月ほどで落ち着く傾向があります。

ビジネスニーズの変化や、さまざまな分野で専門知識を持つ人材が必要になったときに人材が移動できるよう、十分な流動性を維持しています。チームの移動は予期された、労力の少ない変更です。これが意味するのは、コレクティブ ミーティング中に、人々が自分のチームを再構築するパターンはあるものの、その構成は想像しているほど変わらない傾向があるということです。

バグやオンコールの処理方法など、他にも多くの詳細があります。これらのトピックのいくつかについては後ほど説明します。しかし、FAST アジャイルの基本的な核は、より大きな集団内でプロジェクトに取り組む、これらの自己選択チームです。コレクティブミーティングは構造化されており、ビジネスのニーズに関する背景を提供し、それらの優先事項に対する進捗状況を伝達することに重点を置いています。

相違点のまとめ

FAST は、今日のほとんどのアジャイル ソフトウェア組織の運営方法とは大きく異なります。私が見た違いは次のとおりです。

ご覧のとおり、FAST は、現在ほとんどの企業が行っているアプローチとは大きく異なります。

では、トレードオフは何でしょうか?

私が見たところ、FAST アジャイルのトレードオフは次のとおりです。

• FAST は組織の拡張性を向上させる可能性があります
• FAST は段階的に試すことができます
• FAST を使用すると、再組織化が少なくなるはずです
• FAST により、優先順位の変化への対応が容易になります
• 内発的動機付けと維持には FAST の方が優れている可能性がある

しかし…

• 多くの環境は FAST と互換性がありません
• 自己管理が必要になるかも知れません
• FASTには多くの作業が必要です
• FAST の資料には専門用語がたくさんあります

それぞれについて順番に説明します。

FAST は組織の拡張性を向上させる可能性があります

組織を拡大する場合、通常は「水平」に拡大します。組織は一度にチームごとに成長します。これらの各チームは製品の一部を所有しており、多くの場合、製品チームをより効果的にするためのプラットフォーム組織が存在します。

組織の複雑さは、人数が増えるにつれて爆発的に増加します。エンジニアリングに 10 人がいる場合、全員が相互にコミュニケーションをとることができます。エンジニアリングに携わる 100 人全員が互いに話すことはできません。そして、コードベースは誰の頭にも収まりません。そこで、この複雑さを複数のチームに分割し、各チームが注力できる領域を確保します。

FAST が興味深いのは、組織を「垂直」に拡張する試みであるためです。 FAST はチームを追加する代わりに、コレクティブと呼ばれるより大きなチームを作成しようとします。コレクティブは依然としてコードを所有していますが、そのコレクティブ内の自己組織チームはコードを所有していません。そして、やはりコミュニケーションを細分化する必要があります。しかし、チームはよりダイナミックで、継続的に進化しています。再組織化を通じてチームを再構築するのではなく、それは継続的かつ運営方法の一部として期待されています。

チームの規模は、多くのエンジニアリング責任者にとってよく知られたトピックです。チームはどれくらいの規模にすべきでしょうか? FAST がどのように拡張性を向上させるかを理解するのに役立つので、このトピックを少し掘り下げてみましょう。

チームはどれくらいの規模にすべきでしょうか?

エンジニアリング担当副社長の周りで時間を過ごしていると、エンジニアリング チームの規模についての話題が時々出ることがあります。小規模なチームに対する議論もあれば、大規模なチームに対する議論も聞くことができます。どちらの側にもメリットがあります。

小規模チームの利点

• チーム内の調整とコミュニケーションのオーバーヘッドが軽減されます。
• 結果的に素早く動けるようになります。
• 作業の流れが少なくなるため、集中しやすくなり、成果が得られます。
• 管理が容易になります。

大規模チームの利点

• よりフラットな組織。 150 人のエンジニアを擁するエンジニアリング組織の場合、10 人のチームには 3 ～ 4 人のディレクターが配置されます。 5人チームで6～8人のディレクターと1～2人の副社長で構成される。組織内の混乱はどこから来るのでしょうか?おそらくリーダーシップなので、大規模なチームは混乱を減らすことができます。
• さらなる回復力。誰かが休暇を取っても、チームは問題なく継続できます。

したがって、小規模なチームはチーム内では優れていますが、チームの数が多すぎて組織が複雑になるため、あまり理想的ではありません。チームが大きいほど、組織全体の複雑さには優れていますが、各チーム内のパフォーマンスはあまり理想的ではありません。

多くのリーダーがとるアプローチは、より少ない作業の流れに集中する大規模なチームを作ることです。これにより、チーム内部の複雑さが軽減され、組織の複雑さも軽減されます。

FAST は、途方もなく大規模なチームを通じてさらに大きな組織の簡素化を達成しようとするアプローチとして見ることができます。そして、小規模な自己組織チームを持つことの利点も得ようとしました。

組織の拡大は困難な作業です

私のコンサルティング ビジネスの多くは、組織が規模に対処するのを支援することにあります。組織が直面するスケーリングの課題には、いくつかの段階があります。

通常、最初の障壁はエンジニア 15 ～ 25 人の位置にあります。これは、アメーバが大きくなりすぎたので、分割する必要があるときです。次のような種類の問題が発生します。

• 通信チャネルが無効になります。
• エンジニアリング部門では納期や品質の問題が発生し始めます。
• マネージャーやリーダーは圧倒されているように感じます。人を増やせば状況は改善されるどころか、さらに悪化するでしょう。

そして第二の壁はエンジニア約60名です。この時点で、さらに多くの調整の問題が発生し始めます。

• チーム間のプロジェクトが成功することはほとんどありません。
• 製品の作業がプラットフォーム チームに多忙になる、またはその逆。
• 大規模な取り組みを完了できない。

私は、優秀な人材が組織の複雑さの中で段階的に変化していく中で、何度も失敗するのを見てきました。私の予感としては、管理レイヤーを追加すると、これらのステップ順序が複雑になるのではないかと考えています。

エンジニアリング組織を成長させることは真のスキルです。組織と人々がどのように機能するかを深く理解する必要があります。次のようなことについて学びます。

• 人々のグループが協力するための調整モデル。
• ストリームに合わせたチームと機能的に設計されたチーム。
• ビジネスの優先順位の変化に応じて人材とコードを変更する再組織の方法。
• 製品投資と重複する技術的責任の領域に製品を分割する方法。
• チーム周囲のコミュニケーション チャネルを設定する。
• 製品を効果的にサポートするためのオンコールおよび信頼性プログラムを設定します。
• 複雑さと闘うためにプラットフォーム組織と開発者エクスペリエンスへの取り組みを立ち上げる。
• 等。

たとえこの専門知識を持った人材がいたとしても、スケーリングに対処するには管理チームに多大な労力が必要です。したがって、FAST がより適切に拡張できれば、管理チームが別のことに集中できる可能性が大きく広がります。また、ステップ順序の変更の頻度がはるかに低いため、組織の管理が大幅に容易になる可能性があります。

FAST アジャイルに関する思考実験

そこで、チームの規模を拡大できると想像してください。チームを 5 人や 10 人で構成するのではなく、効果的な 20 人のチームを編成できたらどうでしょうか?それとも60人チームでしょうか？

一見すると、これはばかげた提案です。それほど大規模なチームは効果的ではありません。 12人チームでも無理がある。 20人、30人に報告をさせた人の履歴書を見ることもあります。私の即座の反応は、彼らがひどい会社で働いていたのではないかということです。これだけの直属の部下がいるのは「組織臭」です。

FAST アジャイルの中心的な前提は、この大きな集団内に自己組織化と自己選択のチームを追加すると、チームをより水平方向に拡張できるということです。各チーム (FAST ではコレクティブと呼んでいます) はさらに大きくなる可能性があります。そして、人々が日常的に一緒に働くチームは、それらの集合体内で自己組織化されます。

大規模なコレクティブが効果的であれば、組織の複雑さは大幅に軽減されるでしょう。典型的なソフトウェアスタートアップは、責任分野を分割しなければならないまでに何年もかかる可能性があります。コードベースを各チームが所有する領域に厳密に分割する必要はありません。これにより、マネージャーは管理時間が大幅に解放され、製品とチームに集中できるようになります。

したがって、これが私たちがテストする必要がある中心的なことです。自己組織化と自己組織化は、より小規模で設計されたチームと同じくらい効果的な運営方法を提供しますか?

そうなれば、組織を拡張するのに一桁優れた方法が提供される可能性があります。なぜそこまで？サイズ 6 人のチームで成長する組織と、サイズ 60 人の「チーム/コレクティブ」で拡大する組織を比較してみましょう。

この議論には多くの仮定が組み込まれており、いくつかの穴を突くことができるかもしれません。しかし、そうするとしても、FAST では基本的に、より大きな組織単位が製品とコードベースの領域を所有できるようになります。

FAST は新しいものであるため、FAST チームが従来のアジャイル チームと同じくらい効果的に機能するかどうかについての証拠は現時点ではあまりありません。しかし、その質問に対する答えは「イエス」だと思います。私がそう信じられる理由はいくつかあります。まず第一に、ジム・ショア氏のこれに関する予備的な経験は非常にポジティブなものであり、彼は私が信頼できる人物です。

私が FAST に対して強気な 2 つ目の理由は、自己組織化を行う大規模なグループに携わった経験があるからです。そして、それがうまく機能したことに驚きました。

もちろん、中小企業では、多くの自己組織化が見られます。しかし、企業が成長するにつれて、物事は標準化され、チーム内を除いて自己組織化は排除されます。しかし、私が参加した中で最も興味深い実験の 1 つは、New Relic での大規模な自己組織化イベントでした。私たちはすべてのチームを再設計し、50 のソフトウェア チームの全員に、どのチームに所属したいかを選択するよう依頼しました。各チームに必要なスキルには制約があり、全員が所有する必要があるスキルを定義していました。それは、私たち主催者さえも予想していたよりもはるかに成功しました。

したがって、陪審はこれについては判断していませんが、私の直感では、この慣行は適切な状況下で多くの可能性を秘めていると思います。

FAST は段階的に試すことができます

これは FAST の資料には記載されていませんが、FAST の興味深い点の 1 つは、段階的に実験できることです。

実験として 1 つのチームに FAST アジャイルを実装し、時間をかけて追加のチームを飲み込む BLOB アプローチを使用できます。それがうまくいけば、追加のチームを飲み込み続けます。そうでない場合は、実験を中止します。

FAST を使用すると、再組織化が少なくなるはずです

組織には変化が起こります。優先順位は変わり、人々は去り、製品の分野は予期せぬ成長を遂げます。以前の技術的な決定が邪魔になり、追加の作業が必要になります。投資を必要とする新たな機会が生まれます。

これらすべては組織の構造に影響を与えます。一連のチームがあり、それぞれが独自の所有領域を持っています。この変化が起こると、時間をかけて組織をリファクタリングして、可能な限り最高のパフォーマンスを発揮します。これらのリファクタリングは「再組織化」であり、成長する組織では頻繁に発生する可能性があります。

FAST を使用すると、再組織化の頻度が大幅に減ります。再編成の単位は非常に大きいため、それほど頻繁に行う必要はありません。

これの潜在的な欠点は、定義された責任領域を持つチームが存在しないことです。そのため、責任が分散され、コードコモンズの管理が不十分になる可能性があります。 (これについては少し後で説明します)

FAST により、優先順位の変化への対応が容易になります

従来の構造のチームで優先順位が変わると、その作業を行うためにチームをセットアップすることになります。そのチーム構造が新しい優先事項をサポートしていない場合は、組織をリファクタリングする必要があります。

FAST の場合、優先順位の変更はより流動的かつ継続的になります。責任がコレクティブ内にある限り、チームは仕事を中心に組織するだけで、まるで別の日のような気分になります。

また、集合的な会議の構造により、優先順位の変更があまり劇的に行われなくなります。基本的に、週に 2 回、オールハンズが組み込まれています。 Collective ミーティングでは、継続的に状況を伝え、顧客と市場についてチームを教育することができます。これは、チームの連携をより良く保つのに役立つはずです。

このアプローチを四半期ごとの OKR のようなものと比較すると、そのアプローチの方がより流動的で、人々の調整に効果があるように思えます。コンテキストと優先順位を継続的に共有するには、プロダクト リーダーの献身的な努力が必要です。しかし、私がこれまでに所属してきた最高のチームのいくつかには、プロダクト リーダーがこのようなやり方で行動していたので、これは有意義な時間を費やしたのではないかと思います。

内発的動機付けと維持には FAST の方が優れている可能性がある

多くのチームは、自分たちのプロセスが人々をコントロールするツールとして設計されていると感じることがあります。そして、それは組み立てラインで働いているように感じるかもしれません。

FAST は、設計の基本的な要素として自己組織化を採用しています。これは非常に基本的なものなので、自己組織化がなければ機能しません。管理にはまったく異なるツールキットが必要であり、トップダウンの階層的アプローチとはほとんど (完全ではありませんが) 互換性がありません。

ダニエル ピンクは、内発的動機付けの 3 つの側面を概説したことで有名です。

• 自律性– 自主性を持ちたいという欲求により、コンプライアンスよりもエンゲージメントが高まります。
• マスタリー– よりスキルを高めたいという衝動。
• 目的– 意味があり重要なことをしたいという欲求。目的を重視せずに利益のみを重視する企業は、顧客サービスが低下し、従業員が不満を抱くことになります。

FAST を使用すると、仕事を自主的に行うことができ、自主性を感じることができます。自分のスキルを向上させ、熟練した感覚を得る仕事に集中することを選択できます。また、自分の仕事がビジネスにとって重要なこととどのように結びついているかを常に思い出し、目的意識を感じることができます。したがって、保証されたものではありませんが、FAST を導入している組織では高い定着率が得られる可能性があると私は考えています。

自己組織化は、人々のコミュニティがより良く連携できるようにするための便利なシグナルも提供します。 「嫌なマネージャー」タイプの人は、自分の行動が歓迎されていないというシグナルを受け取ります。どうやって？彼らはチームを率いるために前に出て、自分がやりたい仕事を言います。誰もチームに参加しない場合、作業は行われず、チームは形成されません (チームには少なくとも 2 人か 3 人が含まれていなければ、チームは形成されません)。

自己組織化により、他の会社では注目されないような仕事のつらい側面にも対処できるようになります。たとえば、テストスイートがひどい場合、誰かがその問題を修正するチームを率いるために名乗り出ることができます。明らかにビジネス上の優先事項ではない仕事を行うのは完全に合理的です。しかし、それは公の場であり、それが起こるためには他の人も参加する必要があります。これにより、機能ファクトリーにいるような気分を避けることができます。

最後に、毎日一緒に仕事をする人を選択できるようになりました。過去に自己組織化チームを見てきたとき、これは予想外の利点でした。人々は一緒に働きたい人たちと働くことを選ぶのです。そしてそれらのチームは私が予想していたよりもはるかに強かったです。

これらすべてのバランスをとるのは、人々が FAST で経験するであろう新たな苦痛です。課題の 1 つは、非公式の権力関係、または潜在的な政治にあるかもしれません。

多くの環境は FAST と互換性がありません

FAST は非常に新しいため、実装にはリスクが伴います。あらゆる状況で「速い」という言葉が意味を成すわけではありません。そして、さらに不明な点があります。実験的なアプローチとして考えるのが最善です。

FAST を試すのに最も適した環境はどれですか?では、FAST を避けるべき場所はどこでしょうか?

このリストに含まれる品質があなたの会社にあるほど、FAST への適合性が高くなります。

• 経営革新と実験に興味がある。
• 信頼性が高く、恐怖が少ない環境。あるいは、少なくともリーダーシップにおける指揮統制を避けたいという願望。
• プロセスの優れたガイドまたはファシリテーター。効果的な集合会議を運営し、プロセスを設定し、評価し、積極的に管理できる人。組織の力学と、グループ内の人間がどのように連携するかを理解している人。 （このために私を雇ってもいいでしょう）。
• 優先順位の変更率は中程度から高程度です。優先順位が変化していない場合、FAST はあまり役に立ちません。
• 協力的で自主性があり、高いパフォーマンスを発揮し、継続的に学習するチームです。
• 優先順位を理解できるリーダーシップチーム。
• 各 Collective ミーティングで優先順位やビジネスの背景について話すことができるプロダクト リーダーがいます。そして、彼らは効果的にコミュニケーションをとることができます。

これらの特性が当てはまらないほど、FAST でより多くの逆風に直面することになります。完璧な環境に身を置く必要はないと思います。ある意味、実際にそうなることよりも、これらになりたいと思うことの方が重要だと思います。したがって、おそらく最も重要な成功要因は、リーダーシップがそのためのスペースを作ることに協力していることです。

自己管理が必要になるかも知れません

自己組織化システムは効果的に機能します。しかし、それらは無料ではありません。彼らはコミュニティを管理することに似ています。

正しい行動を促すための制約と手段を作成する必要があります。そして、物事が軌道から外れないよう注意深く監視し、管理する必要があります。

どのような組織にも、悪意のある人物や、そのコミュニティの利益と一致しない人々が存在する可能性があります。かつてあるエンジニアと話したときのことを覚えています。そのエンジニアは、雇用主のために価値を生み出す義務があるとは思っていないと言いました（冗談ではありません）。エンジニアの中には、自分を雇用する会社にとって良いことよりも、自分のスキルを開発したり、自分をより価値のある従業員にすることに焦点を当てたいと考える人もいるかもしれません。

FAST では、人々のコミュニティを管理するためにサインアップします。

従来の状況では、階層構造により、誰がこの責任を負うのかが明確になります。 FAST では、衝突を避けて「メンバーに解決してもらう」のが簡単なのではないでしょうか。この結果、非公式の電力ネットワークが構造のない一種の専制政治を支配することになる可能性があります。 FAST を使用する場合、これは避けるべきことです。

もう一方の極端な方法は、グループに問題を解明させず、経営陣に完全に対処させることです。これも有害である可能性があります。

したがって、FAST には、優れた促進、注意深い観察、および時折の介入が必要です。

FASTには多くの作業が必要です

FAST を試したくない最大の理由は、FAST には隠れた作業がたくさんあるからです。組織内で不慣れな運営方法に多くの変更を加える必要があります。

FAST は、新しいコンピューター プログラミング言語で作業することに例えることができます。この新しい言語は、人間工学に基づいた新しい機能を多数備えており、これまでに見たものよりもはるかに優れているように見えるため、有望に思えます。しかし、この新しい言語で書かれたフレームワークやライブラリはありません。したがって、多くの部分を自分で構築する必要があります。

したがって、FAST の最大の欠点は、これが十分に確立された手法ではないことです。 FAST の動作方法と従来の慣行との間の非互換性に対処するには、多くのことを構成する必要があります。ここではいくつかの例を示します。

パフォーマンス管理はどのように機能しますか?

従来のチームでは、仕事を監督し、個人を指導するマネージャーがいます。業績評価があり、誰かが適さない場合は、マネージャーが介入することができます。業績評価には問題がありますが、ほとんどの人は自分の働き方を理解しており、組織内で目的を果たしています。

FAST チームでは、パフォーマンス レビューを行う明確な方法が実際にはありません。その人のマネージャーは、その人が何をしているのか、どのように働いているのかさえ知っていますか? 「チーム」は一時的なものなので、評価することもできません。

したがって、パフォーマンス管理の概念全体を再発明する必要があります。いずれにせよ、それは良いアイデアかもしれませんが、それは思考と発明を必要とするものです。

FAST におけるエンジニアリング マネージャーの役割は何ですか?

エンジニアリングマネージャーの役割を構築する方法はたくさんあります。私は通常、エンジニアリング マネージャーにプロジェクト管理を担当させることをお勧めします。そうすることで、パワーの差が問題を引き起こす領域にエンジニアリング マネージャーを置くことなく、チームと協力して作業できるからです。エンジニアリングマネージャーの役割を定義する有効な方法はたくさんありますが、私はこれに惹かれる傾向があります。

FAST では、エンジニアリング マネージャーの役割はそれほど明確ではありません。長く存続するチームは存在しないため、エンジニアリング マネージャーが直属の部下と協力して働くことは困難です。

エンジニアリング マネージャーに、自己組織化されたチームを率いてもらうこともできます。あるいは、彼らに純粋な人材のマネージャーになってもらうこともできます。あるいは、選手兼コーチになってもらうこともできます。

これらすべてにはトレードオフがあり、かなり大きな欠点もいくつかあります。 FAST により、エンジニアリング管理の必要性が軽減されるようです。雇用し、パフォーマンス管理を行い、プロセスを監督する人材が依然として必要です。しかし、従来の組織ほどではないでしょうか?

私は多くの組織が規律としての管理を重視していないために苦しんでいるのを見てきました。しかし、FAST 組織では管理の必要性はそれほど高くないと思います。

私はこれがうまくいくかどうか非常に興味があり、FAST を実験している組織から話を聞きたいと思っています。経営って何をするの？

所有権の領域がない場合、コードの品質をどのようにして確保するのでしょうか?

コードの所有権は、コードの品質を高く保つための自然なインセンティブをもたらします。将来の自分は現在のコードで動作する必要があるため、それはあなたの利益になります。

コードの所有権が共有されている状況では、コードの品質を確保するために、より多くの努力をする必要があります。私がお勧めするのは、必須の練習としてペアリングまたはモビングです。

コード パターンに関するより強力な標準も必要になります。コードのリンティングが必要になります。そして、ある種のアーキテクチャ上の意思決定が必要になります。フロントエンド コードで状態を処理する方法について 20 のパターンを用意する必要はありません。これらはほとんどのソフトウェア組織で発生する問題ですが、FAST を使用している組織ではより差し迫った問題になります。

多くの組織が投資が不足していることの 1 つは、効果的なソフトウェア設計パターンに関するトレーニングとコミュニケーションです。そして、どのアプローチをいつ使用するかについて全員の意見が一致していることを確認するための会話。これらは、FAST 組織ではおそらくさらに重要です。

コード所有権の共有は、いくつかの前例がある慣行です。 FAST で進める場合は、時間をかけて成功する方法を掘り下げる価値があります。

複数のコレクティブがあり、コレクティブの境界を越えるとどうなりますか?

集団の境界を越える作業は、FAST では基本的に定義されていません。また、高度な調整を必要とする大規模な取り組みも、FAST では十分に規定されていません。したがって、これらの状況に対する解決策を発明する必要があります。

FAST を使用する複数のコレクティブを持つほど大きな組織では、クロスコレクティブ プロジェクトが実行されます。これらの問題に対処するためのパターンは、より小規模な問題を解決する方法と類似または類似しています。しかし、私の知る限り、これはほとんど未知の領域です。したがって、これらの問題が発生した場合は、いくつかの調整モデルを使用して解決する必要があります。発明行為になります。

FAST はオンコールにどのように対処しますか?

オンコールについては、 FAST ガイドでは特に言及されていません。したがって、それに対処するためのスキームを考案する必要があります。

従来のチームでは、オンコールに関する標準的なアドバイスは、各チームに独自の業務の責任を持たせることです。そして、チームの全員が待機できるようにすることです。これは、負担がそれほど大きくないように、少なくとも 4 人のチームを構成する必要があることを意味します。チームが作業成果物のオンコールを行うことで、チームに信頼性を組み込む動機が与えられるという考え方です。これにより、適切なオンコール スケジュールを確実に確保することができます。

FAST を使用すると、段階的なオンコール ローテーションを作成できます (このランブックに従い、問題が解決しない場合はエスカレーションします)。そして、誰が何をサポートできるかのマップを明示的に保持する必要があります。これはあなたのチームにはマッピングされません。

これは非常に難しいことではありませんが、従来のオンコール業務に比べて一般的ではないため、管理者の注意が必要になります。

バグの修正やサポートのエスカレーションについてはどうですか?

FAST には、「機能スチュワード」と呼ばれるオプションの役割があります。彼らは特定の機能の専門家のようなもので、その機能に関する利害関係者との連絡窓口となります。その機能に継続的に取り組む必要はありませんが、継続的にその機能を理解することが求められます。

オンコールと同様に、機能をその機能の専門知識を持つ担当者にマッピングする必要があります。これは、バグとサポートのエスカレーションの両方にとって重要です。また、オンコールと組み合わせることもできます。問題を適切な担当者に優先順位付けする何らかの方法が必要になります。

また、専門知識が 1 人か 2 人に孤立している場合に、知識のギャップを埋めるためのメカニズムを確保する必要もあります。

決定しなければならないことの 1 つは、バグを修正するためのポリシーです。それらを常に修正して、他の機能の動作を遅らせたいですか?バグは紹介者によって修正されたのでしょうか、それとも別の仕組みが必要ですか?また、バグの優先順位付けの責任者をどのように決定しますか?おそらく何らかのローテーションでしょうか？

サポートのエスカレーションにもある程度の労力が必要です。連絡先は、エリアの機能スチュワードです。しかし、機能管理者が休暇中だったらどうなるでしょうか?おそらく、各分野に精通した人が複数人必要になるでしょう。そして、サポートの質問に作業が必要になった場合はどうすればよいでしょうか?仕事をただこなすだけですか、それとも中心的な優先事項に取り入れますか?

これらはいずれも解決するのが難しい問題ではありませんが、管理作業です。そして、何をするにも、集中力と反応性のトレードオフが発生します。

信頼性に関するインシデントやインシデントの振り返りについてはどうですか?

FAST はインシデントの処理方法を定義しません。オンコールのパターンによってインシデントの処理方法が大きく決まり、状況を解決する方法を知っている人が巻き込まれる可能性があります。

FAST では、インシデントの振り返りの処理方法については説明されていません。次のようなことを行うことをお勧めします。次の集団会議の前に、インシデントの振り返りをスケジュールすることです。回顧展の目的の 1 つは、インシデントの原因となった可能性や重大度を軽減するために実行できるいくつかの作業を特定することです。もう一つは、その出来事からできる限りのことを学ぶことです。

事件直後の集団ミーティングで、私は学んだことを共有し、また、振り返りで特定された作業の一部を実行することを次のサイクルで自動的に優先するようにしました。

New Relic では FAST を使用していませんでしたが、同様のポリシーがありました。私たちはそれを「事件を繰り返さない」（DRI）と名付けました。これは、信頼性に関して私たちがこれまでに行った中で最高のものの 1 つでした。 DRI 作業は自動的に他の優先事項よりも重要になるというルールがありました。したがって、インシデントが発生すると、常に範囲が狭くなるか、期限が延期されることになります。

デザイナーは FAST でどのように作業しますか?

多くのデザイナーが抱えている課題は、エンジニアリング チームとの共同作業、またはエンジニアリング チームよりも先に作業を行うことに集中することです。または、両方の方法で動作させることもできます。どちらの働き方についても強い議論があるでしょう。

FAST はこれがどのように機能するかを指定していないため、自分で決める必要があります。デザイナーは作業するチームにサインアップしますか?それとも、彼らは物事を先取りして取り組み、人々が何かを必要とするときにコンサルタントとして機能するサービス組織なのでしょうか?決める必要があります。おそらくデザイナーにサインアップしてチームの一員になってもらうと思いますが、これも FAST を採用する際に必要な決定の種類の一例です。

プロダクト マネージャーは FAST でどのように機能しますか?

FAST における製品の役割は主に、優先順位を付け、優先順位を伝達することです。それ以外の作業については、FAST マニュアルには実際には説明されていないことがたくさんあります。

FAST マニュアルでは、プロダクト マネージャーがインスピレーションを与えてコミュニケーションを図り、その後エンジニアが機能に取り組むという前提になっているようです。

できる限り、私はエンジニアに顧客と話をさせ、彼らが取り組んでいる製品分野の専門知識を習得してもらいます。理想的には、エンジニアが作業を実行し、顧客にデモを行い、顧客からそれに対するフィードバックを得ることができます。 。プロダクト マネージャーにそれを促進してもらい、それを効果的に行うエンジニアの能力をレベルアップすることは、彼らの仕事の貴重な部分となる可能性があります。

このモデルには多くの柔軟性があります。一般的な製品からエンジニアリングへの引き継ぎを行うこともできますし、顧客と一緒にスペースを発見して問題を解決してもらうこともできます。

ご覧のとおり、FAST には多くのギャップがあります。残りの問題を解決する必要があります。

FAST の資料には専門用語がたくさんあります

FAST の Web サイトとマニュアルがわかりにくいと感じるかもしれません。 FAST アジャイルの極意を理解するには、多くの専門用語や煩わしい用語を理解する必要があります。例として、 FAST ガイドのバージョン 2.12で実践を定義しようとする FAST アジャイルのひどい定義を次に示します。

「流体スケーリング技術とは何ですか？」 Fluid Scaling Technology は、Open Space Technology と Open Allocation を組み合わせて、仕事の周りで人々を組織するための軽量で理解しやすく、習得しやすい方法、つまりスケーリングを作成します。 FAST は、Fluid Scaling Technology の頭字語です。アジャイル向けの流体スケーリング テクノロジは、FAST アジャイルです。」

それで。悪い。そしてこれは非常に代表的なものです。コレクティブ、バリュー サイクル、オープン テクノロジー、ティール トランスフォーメーション、理論 Y などへの言及が数多く見られます。これらはすべて説明なしで提示されており、たとえ説明されたとしても役に立ちません。彼らはアジャイル理論家というニッチな聴衆に向けて話をしており、有用性よりも帰属に焦点を当てています。

結論

それでは、私たちはどうなるでしょうか？ FAST アジャイルは試してみる価値がありますか?

その答えは「はい」であると私は信じていますが、適切な状況下で注意が必要です。個々のチーム内で試してみることができます。また、リーダーのサポートがある場合は、より大きな組織内で徐々に試してみてください。

実験した場合は私と共有してください。あなたの組織でそれを展開するのに協力が必要な場合は、私に連絡してください。私が直接あなたを助けるか、助けてくれる人をつないであげます。

ありがとう

この投稿の初期バージョンは…本当にひどいものでした。批評してくださったセス・ファルコン氏とデイビー・スティーブンソン氏に感謝します。二人とも、この投稿に関するいくつかの大きな問題点を指摘したため、私は立ち直り、自分のアプローチを再考することになりました。そして、彼らはいくつかの優れた点を指摘し、私はそれを投稿の独自のセクションに組み込みました。結局、投稿の大部分を書き直しましたが、その結果にはとても満足しました。ありがとう！ Seth はエンジニアリングのリーダーシップに関するニュースレターを発行しているので、ぜひチェックしてみてください。Daviy は (私と同じように)スタートアップのアドバイスやコーチングを行っています。

Jim Shore が私に FAST アジャイルを紹介してくれました。彼はその経験について素晴らしい話をしています。そして私たちは何度か会って、FAST の意味と実装について話し合いました。 Jim は、 『The Art of Agile Development』の著者です。

KennonによるPixabayからの画像

脚注

1. おそらくコレクティブにとって 150 人という人数は手に負えないと思います。最大人数は 60 名が適切だと思います。