システム負債への対処

プリアンブル/tl;dr:私は最近、 The Lloyd Braun Principle of Agilityを発表しましたが、これは主に、典型的なとなりのサインフェルドのセリフ「今は平静、後は狂気」がどのようにアジャイルに関係しているかについてのばかげた、しかし真実の観察です。後で来る「狂気」にどのように備える必要があるかについての声明で、その投稿を締めくくりました.それを念頭に置いて、生産的なチームを構築するための私のアプローチを紹介します。システム負債を返済することです。

現代の技術チームは壊れています。私たちはシニアに頼りすぎて、ジュニアを活用していません。

私は昨年、複数のチームを「ニューノーマル」に適応させてきたので、この問題について何度も考えてきました。数か月前、採用担当者は後輩を採用すべきだという主張を支持する記事を書き始めました。効果的な議論を行うには、共通の懸念事項に対処する必要があることを知っていました。

あなたが管理に慣れていない場合、これは管理に関する私の「論文」です。これは、非常に効果的で生産的なチームを構築する方法に関するものであり、10 年以上にわたって複数の大規模なチームをうまく管理してきたことに基づいています。

以下は長い読み物です - したがって、 tl;dr は次のとおりです。

#TechnicalDebt についてよく話しますが、Technical Debt は、私がSystems Debt と呼んでいるより大きな問題の兆候です。

レシピは簡単です：

1) シニアにシステムの負債を返済するように指示し、仕事を楽にします。

2) 雇う。ジュニア。

3) 消耗戦をやめる。ジュニアは平均18～24ヶ月滞在します。彼らはさまざまな経験を望んでいます。彼らは他の仕事を探すでしょう。技術コミュニティとして、私たちはジュニアが年功序列への道でより多くの経験を積むことを望んでいます。それは彼らをより良くし、私たちをより良くします。それでは、消耗を受け入れましょう。彼らがこの 18 か月を最大限に活用できるようにすることに重点を置き、次のステップで彼らをサポートしましょう。

優れたデリバリー チームは、ユーザビリティを重視します。ユーザビリティを推進する原則は、パレートの原則、 おばあちゃんテスト、十分の原則など、さまざまな形で現れます。そして、彼らは皆、非常に人間的なことを考えています。これは必要以上に難しいことでしょうか?

使いやすさを優先し、明確なビジョンに重点を置いたミニマリストのデザイン。他のすべては気を散らすものであり、膨満感です。

リーダーシップ、マネジメント、ワーク/ライフ バランス、リモート/対面での仕事について話している人はたくさんいます。すべてが再評価されています - そして何ヶ月も私の心に残っている質問は、単に「仕事は必要以上に大変ですか?」ということでした。これは決して新しい問題ではありませんが、私のキャリアのほとんどを通して織り成されてきた糸です。私はコードを書いたり、製品を作ったりするのが大好きですが、全体的な見方をすると、より多くのコードが必ずしも答えではないことがわかります。コードが増えるということは、トレーニングとメンテナンスのコストが増えることを意味します。

あなたが新しいマネージャーである場合、この質問を心に留めておくことは非常に価値があります.マネージャーには多くの責任があります。あなたは各個人を支援し、成果物と個人の目標を達成します。あなたはチームの結束と方向性に責任があります。多くの場合、プロセスとポリシーを確立する責任があります。次に、リソースの割り当てと計画、および有給休暇スケジュールの調整があります。しかし、これらすべての指針となるのは同じ質問です。これは必要以上に難しいのでしょうか?

最後に内部メカニズムを評価したのはいつですか?配送チームを製品と考えた場合、消費者 (ビジネス/運用チーム) が目標を達成するのはどれほど簡単ですか?また、ビジネス全体を製品として考えた場合、顧客が自分のビジネスを達成するのはどれほど簡単ですか?

人々に注目すると、同じ質問が当てはまります。あなたのチームが仕事をするのはどれくらい大変ですか?どのような構造、フレームワーク、不自然なプロセス、ヒエラルキーが存在し、あなたのおばあちゃんがあなたが物事をどれだけ複雑にしているかに首を横に振りますか?

借金の入門書

内部プロセスを批判的に評価するこの一連の思考は、実際、見過ごされがちなアジャイル哲学の一部です。チームは、完全にアジャイルである、または「アジャイル ハイブリッド」であると主張していますが、詳しく見てみると、彼らが意味することは、ずさんな製品をより速く提供するために、単に不便なコーナーをカットしているだけであることがわかります。ソフトウェアに関しては、ベテランの開発者なら誰でも、これが増え続ける技術的負債のレシピになることを正確に知っています。コーダーの間で流行っている冗談は、最後の人が間違ったことをしたというものです。これは、怠惰や能力不足によるものではありません。グリーンフィールド作業は、すべての技術的負債がなくなるため簡単ですが、同じ悪いプロセスを放置すると、再び成長するだけです.

技術的負債は症状であり、積極的に返済することに長けている場合でも、症状を治療しているだけです。この症状は、アジャイルとは単にソフトウェアを提供することだと考える誤りから来ています。

技術的負債の適切な定義は、「リファクタリングが必要な作業の蓄積」です。前述のように、配信に集中するときに近道をすることから発生します。積極的に返済しない限り、急速に成長します。技術的負債が多すぎると、脆弱性と不安定性が生じます。

最良の場合、技術的負債は意図的な決定です。後で返済することを意図して、何かを信用に置くことです。そのような場合、技術的負債は悪くありません - 負債を返済することに熱心であれば。技術的負債のより悪質な化身は、意図せずに負債を増やしたり、さらに悪いことに、追加したことに気付いていない場合です。

技術的負債はテクノロジーを扱いますが、プロセス負債には同様の概念があります。古いプロセスは古くなり、機能が低下し、摩擦が生じ、チーム間のダイナミクスに影響を与え、役割が変更されたために適用されなくなる可能性があります。 Process Debt は、非技術的な運用上の欠陥をカバーします。

デリバリーに影響を与える他の形式の負債はまだあります: 設計の負債、アーキテクチャの負債。

もちろん、借金は本質的に悪ではありません。健全な額の金銭的負債を戦略的に負うことができるのと同じように、これらの形態の負債を引き受けることは戦略的な決定です。車に 20,000 ドルを一度に支払う代わりに、自動車ローンを組んで、支払いを 10 年に分割します。同様に、使用するテクノロジー スタック、チームのスキルセットを構築する方法、それらの役割の年功序列、ビジネスを推進するプロセスは、一定期間にわたって返済される負債の形をとります。

ただ - 時々私たちはそれを払いません。さらに悪いことに、私たちは借金を返済していると思っていますが、実際にはさらに増えています.

導入: システム負債

私がシステム負債と呼ぶ概念を紹介したいと思います(システム理論におけるシステムと同じです。システム理論の詳細については、Donnella Meadow の素晴らしいThinking in Systems をお読みください)。

システムの負債は、ビジネス、技術、アーキテクチャ、またはプロセスの決定によるものであるかどうかにかかわらず、配信を妨げたり、悪影響を与えたりする下流の形式の負債の全体的かつ根本的な原因です。それは、ビジネスで計算された近道を取り、仕事を信用に置いた結果です。システムの負債は、その構造設計を通じてシステムの機能を妨げます。

Thinking in Systems で Meadows は、システムの簡単な例であるバスタブを提供しています。システムへの入力は蛇口で、出力は排水口です。 Meadows は、さまざまな要因によって浴槽が満タンにならない、水平に保たれない、またはオーバーフローしない原因について説明しています。最適なシステムは、水の残りのレベルです - 入口 (蛇口) と出口 (排水) が同じ速度で流れます。システムの負債は、システムを構成するときに近道をした結果です。浴槽の例えを広げると、蛇口の取り付けが不十分で、最終的に水が漏れる可能性があります。排水口の場所によっては、特定の領域に水が溜まり、浴槽が完全に排水されない可能性があります。多分私たちの水は軟化する必要があり、石灰が蓄積する原因になります.

これらの場合、すぐに影響はなく、最適なシステムを作成することは可能ですが、システムに負担をかけている負債の蓄積が隠されています。漏れを補うために蛇口をより速く流す必要があるか、蛇口の流れを遅くし、浴槽がいっぱいになるまでに時間がかかります。

Meadows の本に精通している場合、彼女の例の多くは現実に根ざしており、モデルは一般に静的なビジョンを提供します。システムは時間の経過とともに変化しません。彼女の目的にはぴったりですが、個人、チーム、運営、ビジネスに関して言えば、今日の私たちは明日の私たちではありません.

システム負債を少し異なる方法で定義するには、次のようにします。

システム負債 = システム理論 + 成熟度モデル

ソフトウェア チームでは、システムの負債のマニフェストをいくつかの方法で確認できます。

• 時間の経過とともに、管理されていない場合、チームはますます「部族の知識」を開発します。これらは、善意の習慣、近道、および回避策として現れます。それらは短期的な効率を生み出すため、長期的な欠陥を見逃す結果となります。それが支払われなければ、定期的な消耗によって知識が失われる明らかなリスクがあります。これは、チームがピボットして立ち上げなければならないため、生産性の低下につながります。 （「ジョーはこれを知っていましたが、彼が去ったので、それを理解するのに時間を費やす必要があります。」）または不慣れによる技術的負債の蓄積。 (「そのコンポーネントを更新することはできません。サリーが作成したもので、私たちが触れるたびに壊れます...」)
• チームは、ローカル フローを最大化するカスタム デザイン パターン、非公式の開発ルール、または契約に依存しますが、これらのパターンは変化しにくいものです。これは、何かが確立されたパターンと一致しない場合に配信を妨げ、ビジネス チームを技術的な決定に人質にします。 (「カスタム インスタンスをスピンアップすることはできません。そのように設計したことはありません。」)
• 現状に満足しているチームは、破壊的なふりかえりよりも現状維持を優先します。彼らはまだふりかえりを開催するかもしれませんが、実際の問題に対処する能力に対する信頼を失った場合、彼らは些細なことを修正することだけに集中するでしょう. (「私たちはインシデント リクエストで過負荷になっていますが、とにかく、それらを解決し続ける必要があると思います...」)
• 対処可能な摩擦にもかかわらず、持続可能な速度を達成することに伴う倦怠感または無関心。持続可能な速度は、誤った効率性を生み出します。 (「本当にプロセスを変更する必要がありますか? 私たちは一歩踏み出したのに、なぜそれを中断するのですか?」)

プロダクト & オペレーション チームでは、システムの負債を同様の方法で見ています。

• 「すべての顧客からの電話は火災報知機だ」という手抜きは、リリースの遅延、速度の低下などの小さな問題を迅速に修正するために開発チームに関与していました(「私はチームに、怒っている顧客によって提起された問題を見てもらう必要があります。 20分しかかかりません...」）
• 最後に話した人が最優先の混乱により、チームは常にコンテキストを切り替える必要があり、1 つの問題に集中して完了することができません。
• 優先順位付けが、誤解を招く指標を使用することによる近道である場合。たとえば、ビジネス目標に合わなくなった高額の顧客などです。スタートアップの初期には意味がありましたが、ビジネスが成熟するにつれて、同じ顧客がより問題になるようになりました. （「この顧客を維持したいかどうかはわかりませんが、彼らは私たちに多額の支払いをしているので、そうする必要があります...」）

繰り返しますが、すべての形態の負債は、後で修正するつもりで、今すぐ近道をすることを選択した場合です。技術的負債は、コードでこれを行う場合です。プロセスの負債とは、正式なプロセスでこれを行う場合です。システム負債は、これを組織レベルで行う場合です。私はそれを「組織の負債」ではなく「システムの負債」と見なすことを好みます。なぜなら、組織をシステムと考えると、技術、プロセス、設計の負債はすべてシステムの負債によって直接引き起こされることを意味するからです。私たちが技術的負債を負うようになった要因は、最終的にはシステムの負債に関連しています。 （「川で溺れている人を救えるのは、川の上流に目を向けて、なぜ彼らが転落し続けるのかを判断する前に限られます。」）

例:開発チームは、適切に計画され、コストが設定された新機能をリリースしています。チームは順調に進んでいますが、最終段階で恐ろしい問題に直面することになります。問題に適切に対処してリリースを遅らせるか、最小限の修正を行ってから次のイテレーションで適切に解決するか?彼らは技術的負債を引き受けることを選択します。「次の反復でそれを取得します。」

これが、システム負債が方程式に入り始めるところです。チームは本当にそれに対処できるでしょうか？チームはリファクタリングに十分なスキルを持っていますか?ビジネスは「それで十分です。先に進む必要があります」と応答しますか?将来のコスト計算で、正しい方法を実行するにはコストがかかりすぎることが明らかになるでしょうか?優先順位の変更や緊急の問題の急増によって、修正が突然、別の繰り返しで遅れることはありますか?それから別の繰り返し、そして別の...

さらに、上流に目を向けると、問題が発生するまでになぜそんなに時間がかかったのですか?どのような悪い仮定がなされましたか?それらは悪い仮定でしたか？ゲームの後半になるまで判断できない問題は常にありますが、なぜそれがリリースを遅らせる問題になったのでしょうか?約束が早すぎた？もっと大きなバッファがあったはずですか？ Aさん（上流の営業担当者）がFさん（下流の開発者）にもっと短い連鎖で話しかけていたら解決したのでしょうか？

もう 1 つの非常によく知られている例は、ビジネスが 3 ～ 5 年でどのように拡大するかという仮定に基づいて、早い段階で自分自身を固定するインフラストラクチャ、アーキテクチャ、およびホスティング モデルに関するものです。小規模なチームは、最高の DevOps 原則に従うよりも、迅速なデリバリーを優先して、早い段階でインフラストラクチャとアーキテクチャの負債を負うことを選択する場合があります。

もちろん、詳細がなくてもこのようなシナリオを描くのは簡単ですが、詳細やその詳細の言い訳に関係なく、システムの負債が発生します。それは避けられません。それは問題ありません - 常に注意を払う必要があり、維持可能なレベルまで下げることに集中するだけです。

補正ショートカット

私たちは、近道として、システムであろうとなかろうと、負債を引き受けます。システム負債とその返済方法について深く掘り下げる前に、まず一歩下がって、近道を選ぶ理由を考えてみましょう。ショートカットは、負債と同様に、本質的に悪いものではありませんが、詳細に分析する必要があります。

物理的な近道について考えることは、始めるのに最適な方法です。歩行者や自転車に乗ったことのある人なら、物事が最初に車両用に設計され、次に歩行者用に設計されていることに気付いたことでしょう。歩くと、多くの「近道」を取り、道をたどらないことになりますが、もちろん、これらは近道ではありません。これらの近道は、車が通れない場所に行ける歩行者にとって最適な経路です。実際、歩行者が多い地域で主に車用のルートを構築することは、[別の形](別の形)のシステム負債です。

ビジネスの世界では、時間の不足、予算の不足、リソースの不足、説明責任の欠如、広い視野の欠如などを補うために近道をします。時間、予算、リソースのすべてにスポットライトが当てられますが、説明責任と広い視野がまさに私の最初の質問の核心です。人が川で溺れるのを防いでいるとき、それは上流に目を向けること(広い視野)と、人を押し続けている人(説明責任)を指し示すことです。

言い換えれば、システム負債について真剣に話し合う場合は、全員が会話に参加する必要があります。ローカライズされた取り組みはこれまでのところしかありません。

では、システム負債をどのように返済するのでしょうか?

先ほどの質問に戻りましょう:デリバリー チームにとって、デリバリーはどれくらい簡単ですか?この質問について考えたことがない場合は、いくつかの指標を取得する時が来ました!これらの指標から必ずしも答えが得られるわけではありませんが、出発点としては重要です。 KPI に関して私がこれまでに受けた最高のアドバイスは、個々の KPI は悪くも良くもないということでした。客観的には単なる数値、値です。それはあなたの通常のビジネスです-そして、あなたはその数を上下に調整したいかどうかを決定します. OKR システムや SMART 目標のファンなら、これは素晴らしいことです。KPI を知ることで、簡単に定量化できるより良い OKR を作成できるからです。

それでは、いくつかの基本から始めて、雑草に取り掛かりましょう。以下は包括的なリストではなく、あなたのグループに適したより良い質問があるかもしれません.このリストは、より良い質問をするための出発点と考えてください。

配達：

• 優先度の高い/緊急のアイテムのリードタイムとサイクルタイムは?
• 優先度の低いアイテムのリードタイムとサイクルタイムは?
• 負債を返済するためにいくら割り当てましたか?
• あなたの借金はどのくらい増えていますか？

これらの質問は、チームのパフォーマンスを追跡する人にはなじみがあるように思えるかもしれませんが、組織レベルでこれらを尋ねることを忘れないでください.開発者のリード タイムは、チケットが作成された時点から始まっている可能性があります。

リソース:

• 現在のチームの内訳 (シニア vs ジュニア) は?
• 先輩と後輩の離職率は？
• 高齢者を失うことのコストはいくらですか.
• ジュニアを失うことの代償はいくらですか？
• 採用にかかる費用と期間は？
• 面接/オンボーディングの長さはどのくらいですか?
• トレーニング/立ち上げ期間はどのくらいですか (また、どのようなリソースを関与させる必要があり、生産性が低下しますか?)

ビジネス バックログ:

• プロダクト マネージャーの戦略的フレームワークが定義されていると仮定すると、いくつの例外が作成されますか?
• 財務と時間枠の両方に結び付けられた、客観的に定義されたビジネス ケースに根ざしていないエピック/機能はどれくらいありますか?
• セールス/ビジネス開発パイプラインは、最終的にソフトウェア バックログにどのようにフィードされますか?また、それらのリード タイムとサイクル タイムはどのくらいですか?
• 高レベルのビジネス目標はどのくらいの頻度で変更され、その混乱はダウンストリームの取り組みにどの程度影響しますか?
• ビジネスの長期的な成長目標は何ですか? チームのスキルセットとリソース計画はどのように一致していますか?

オペレーション バックログ

• 毎日何件の顧客の問題が提起されていますか?
• Tier 1、2、3 サポートに行く必要がある顧客の問題はいくつありますか?
• 解決までの平均時間は？
• 顧客の問題のリード タイムと、最初の呼び出しから開発チケットが作成されるまでの時間は?

何かが開始されてから利用可能になるまでにかかる時間を簡単に把握することは、特にそれが顧客の問題である場合、非常に啓発的です。

上記の指標を改善するのに役立つリソースは多数ありますが、これらすべての背後にある重要な哲学は、1) 測定、2) 分析、3) 解決、4) 反復です。 Tier 3 が Tier 2 にオフロードできる問題が多いほど、Tier 2 が Tier 1 にオフロードできる問題が増え、Tier 1 が顧客が独立して解決できる問題が増えるほど、全員の生産性が向上します。

開発者:

• ソースを取得してビルドするのにどれくらいの時間がかかりますか?
• 新しい開発者に資格情報をプロビジョニングするのにどのくらいの時間がかかりますか?
• 彼らはどのくらいの速さで立ち上がって、作業中のより低い環境と対話できますか?
• 開発者がコードを本番環境にリリースするのにどのくらいの時間がかかりますか (雇用日から測定)?
• SDLC とプロセスの立ち上げにはどのくらいの時間がかかりますか?
• 彼らがスプリントの途中から始めた場合、彼らはどのくらい傍観者になるのでしょうか?
• 全体として、現在の学習曲線はどのくらいですか?

参考までに、Etsy は効率性の良い例であり、優れたベンチマークになります。 Etsy は、開発者が 初日に本番環境にデプロイできるようにします。

総合的な見方：

• 開始から利用可能になるまでの配送過程はどのようなものですか?ワークフローを計画する - 最適化できるか?
• 販売から収益 (およびそれ以降) までのカスタマー ジャーニーとは?
• RPO と RTO とは何ですか?
• Accelerate: The Science of Lean Software and DevOps で説明されているように、ビジネス パフォーマンスはハイ デリバリ パフォーマーと比較してどうですか?
• 悪夢のような災害シナリオのトップ 10は?これは、FedEx が業務を改善し、現在の会社にするための社内の「プレイブック」を作成するために行ったことです。

上記のすべての数値と指標を考慮して、これらの数値のいずれかが通常のビジネスを表していることを繰り返します.それらは本質的に悪いものでも良いものでもありませんが、システム負債により、これらの数値を長期的に維持することが難しくなります。一部の数字は驚くべきものであり、そのような債務がすでに影響を及ぼしている可能性がある分野を明らかにしている.

次のステップは、成熟し、成熟し続けるにつれて、これらの指標が時間の経過とともにどのように変化するかを検討することです。例として、コア製品を構築したエンジニアは、スケーラビリティの限界に近づいているアーキテクチャにあなたを閉じ込めました。このような場合、チームは技術的負債をどのように返済できるかを検討しますが、システム負債はどうでしょうか?リソースが限られており、減少のリスクが高まり、ビジネスが成熟している場合、技術的負債を返済しながら配信 KPI を維持するにはどうすればよいでしょうか?

「ダーリンを殺せ」、「ロックスター」に火をつけ、「隠された工場」を破壊し、役に立たない

これらは、1 つの見出しに大胆なステートメントをまとめたものです。要点は次のとおりです。プロセスをショートカットするのに「役立つ」ことは危険な場合があります。 「測定されるものは実行される」という考えに同意する場合、役立つことの問題は、測定されないことが多いことです。

移動が速すぎてポータルのレコードを誤って削除してしまったという顧客からの電話を想像してみてください。彼らは時間がなく、記録を復元するプロセスを経ることができません。彼らが電話をかけてくると、カスタマー サポートの従業員は、役に立ちたいと思ってすぐにデータベース エンジニアにエスカレートし、データベース エンジニアは役に立ちたいと思って、すぐにレコードを復元します。お客様はわくわくし、NPS スコアが上がります。すべてが素晴らしいですよね？

誰かが実稼働データベースを更新することの明らかなリスクを一瞬無視すると、役立つ情報が失われてしまう貴重な情報がたくさんあります。

• そもそも顧客が間違いを犯すほど簡単に劇的なアクションを実行するのはなぜですか?
• 劇的なアクションを元に戻すのが非常に難しいのはなぜですか?
• カスタマーサポートが対応できなかったのはなぜですか?
• 役に立ち、 コンテキストを切り替えることで、生産性にどのような影響がありましたか? (一見単純な 20 分のタスクが、生産的なフローに戻るまでに時間がかかるため、最終的には 35 分以上になります。)

はっきりさせておきますが、私の見出しは太字です。しかし、私は顧客を支援することを否定しているわけではありませんが、そのような行動には根本原因の分析が必要だと思います.過度に正式なものはありませんが、将来同様の問題を回避するためのものです。

ある組織では、プレイブックを実装するだけで、開発チームの生産性が 50% 向上しました。お客様から電話があり、解決に向けて明確なワークフローに従うカスタマー サポート担当者が丁寧に対応します。彼らがそれを解決できない場合は、問題を 1 回だけエスカレートできるように、フィードバック ループがあります。その結果、カスタマー サポート チームの能力とスキルが向上し、開発チームの中断が少なくなり、全体的なストレスが軽減されました。そして、重要なことに、顧客は満足していました。

要点は、有用な作業が影で発生すると、根本原因を修正できないということです。

スキルの低いチームを補うためにあまりにも多くの仕事と責任を負っている Rock Star の開発者にも同じ問題が見られます。彼らは不満を募らせ、燃え尽きて、離れていきます (壊滅的なコストになる可能性があります)。 Will Larson の素晴らしい本 - an Elegant Puzzle - は、あなたの「ロックスター」の扱い方について素晴らしい仕事をしています。

ジュニアの力…

高齢者は、組織と製品の成功にとって重要ですが、同様に最大のリスクの 1 つでもあります。

たとえば、上級開発者はコードベースを徹底的に知っています。彼らは、何が文書化され、何が文書化されていないかを知っています。彼らは、それがどこでうまくスケールし、どこでバラバラになるかを知るでしょう.彼らは骸骨がどこに埋められているかを知るでしょう。機能の構築と設計、ソリューションの設計、最も厄介なバグの解決を支援するために、私たちは頻繁に彼らに頼っています。彼らはどんな質問にも答えることができる知識の達人です。彼らは若手スタッフのトレーニングと指導を行い、ソリューションを開発する際に相談を受けます。

とは言え、先輩社員からの依頼は多い。彼らの経験と、おそらく組織の成功に対する既得権益を考えると、それは明白な声明です。ただし、これが最もシステムの負債を負う場所であると断言します。

成果物を進めるシニア スタッフ メンバーは、システム負債を発生させる近道です。

誤解されやすいので繰り返します。上級チーム メンバーに成果物を作成してもらうことはできますが、その際に発生する負債を返済する計画を立てる必要があります。

成果物をシニアに依存することは、壊れたモデルです。特に、多くのジュニアおよびスキルの初級レベルの候補者が存在する今日の世界では、中級者から上級者の減少のリスクが高く、コストがかかります。

リモートの仮想労働力により、上級スタッフの離職の影響を減らしながら、下級/中級チームを昇格させることが組織にとってより重要になっています。これはシニアスタッフを削減するという意味ではありませんが、アプローチの構造的な違いを意味します。

一般化すると、今日の上級チームは、システムの背後にある複雑さに大きく責任を負っています。彼らの経験と専門知識は成熟したシステムを生み出し、より小さなタスクベースのコンポーネントはより若いチーム メンバーによって実装されます。

これはまさに、上級チーム メンバーが退職した場合に問題となるモデルであり、システム負債が発生する構造でもあります。このような状況では、上級者が複雑な問題に責任を持ち、下級チームが成果を上げられないときに介入して支援することができます (例として、「ロックスター」開発者)。

この問題は、現在のスタッフの離職率によってさらに悪化しています。たとえば、ジュニア開発者は全国的に 18 ～ 24 か月(大企業ではより長く) 職務にとどまります。言い換えれば、ジュニアがより重要な貢献をし始めることができるポイントに到達するまでに、彼らは退場している.

組織は、シニア スタッフを維持するために戦い、ジュニア スタッフを維持するために (ある程度) 戦います。そして、常に知識の流出に悩まされています。最終的には、これは負け戦です。たとえスタッフが維持されたとしても、新しいチーム メンバーが加わったとしても、彼らは多額のシステム負債を返済しなければならない立場にあります。

良い仕事をより簡単にし、避けられないことを受け入れる

ミシュランの星を獲得した小さなレストランを想像してみてください。料理長はプレートの製造に深く関わっており、料理は複雑すぎて料理人チームに分配することはできません。この場合、シェフはレストランです。

これを、より広範なフランチャイズ レストランと比較してください。あなたは会社に戻り、顧客が消費する料理を作らないという責任を負っている料理長を持っています。代わりに、彼らの目標は再現可能な料理を作ることです。簡単に再現できる料理（おいしさをそのままに）。学習曲線が最小限になるように最適化された料理 - 新しい料理人が料理を作るように簡単にトレーニングでき、最終的に離れてしまうことによる影響が少なくなります。また、料理長は効率化の専門家と協力して、フランチャイズ加盟店のキッチンを配達用に最適化する方法を検討しています。

これは、現代のチームを考えるときに使用すべきモデルです。上級チームの責任は、製品の複雑さであってはなりません。トレーニングと立ち上げ、セットアップ時間、ビルド時間を簡素化し、リードタイムとサイクルタイムを合理化する (販売/製品ソリューションからイテレーション計画、リリースに至るまで) など、提供を簡素化することに完全に焦点を当てる必要があります。

従業員を 18 か月しか維持できないことがわかっている場合、どのように物事を構成しますか?実際、18 か月の契約を結び、最後に強制終了するとしたら、どのように構成しますか?ランプアップはできるだけ速く、短くする必要があります。専門家のチームは、新規採用者が数週間で増強できるようにして、効果を最大化できるようにする必要があります。専門家のチームが、効率を最大化する回転式ドアを維持し、支援に介入しないようにする必要があります (負債を構築するリスクがあるため)。

短期間の雇用を受け入れて活用できる、より適応性の高いシステムを構築することで、シニアチームメンバーを失った場合の影響を軽減できます。知識は人ではなく過程で不滅になるからです。

タグ、あなたはそれです

鬼ごっこは誰に教わったの？世界のどこにいても、他の子供たちからこのゲームをプレイすることを学んだことでしょう。大人は子供たちに鬼ごっこを教える必要はありません。

私たちはミームを面白いイメージと考えていますが、ミームの本来の定義は、模倣やその他の非遺伝的手段によってある個人から別の個人に受け継がれる文化または行動システムの要素です。

タグはミームです。誰もルールを所有していません。ゲームを改善する責任は誰にもありません。実際、ルールはシンプルでありながら、Freeze Tag のようなバリアントもサポートしています。さらに、さまざまな環境に適応することができます。それは、最終的にクールすぎるティーンエイジャーに変わる子供たちの回転ドアのために設計されています.

Tag のようなゲームのシステム負債はほとんどありません。 Tag を、より多くのプレーヤーやより多くの機器を必要とする他の遊び場ゲームと比較してください... British Bulldog、Dodgeball、Duck Duck Goose、Cops 'n Robbers、Red Rover。これらのゲームをプレイしたことがあるかもしれませんし、プレイしていないかもしれません。これらのゲームには、システム負債がわずかに多くなります。より多くのルール、より多くの機器、またはより多くのプレーヤーは、より多くのファシリテーターが必要であることを意味します。

では、タグのように操作するにはどうすればよいでしょうか。

1. 高齢者を活用して水準を下げます。高齢者は、タッグを組んだり、仕様を伝えたりするためにそこにいるわけではありません。彼らの目標は、ハードルを下げることです。どうすれば人々はより速くトレーニングし、より早く価値を提供できるでしょうか?影響の少ないリスクで、頻繁に、段階的に、定期的にリリースするにはどうすればよいでしょうか? (*せきせき* DevOps、アジャイル)
2. プロセスを計画し、フローを計画し、チョーク ポイントを特定します。おそらく、問題はソフトウェア チームではありません。専任のテストチームが不足しているわけではないかもしれません。問題は上流にあるのかもしれません。競合する優先順位により、ビジネスが配信パイプラインに過負荷をかけているのではないでしょうか?
3. 人々が休憩を取る原動力は何ですか？休憩を取ることはまったく悪いことではありませんが、多くの場合、休憩は欲求不満の根底にある驚くべきヒントです.誰かが離れた時期と理由を追跡することは、非常に有益です。コードのコンパイルとデプロイに時間がかかるため、離れたのかもしれません。直面している課題についてもっと深く考える必要があるため、離れてしまったのかもしれません。 (これは悪いことではありませんが、複雑さを軽減するために問題を分解できたのでしょうか?)顧客のニーズが彼らを苛立たせたために、顧客が離れたのかもしれません。新しい機能が再設計を余儀なくされたり、悪い仮定が明らかになったりするため、それらは公開する必要があるかもしれません。
4. 休憩がないことに注意してください。彼らは立ち去ることができません - 彼らの注意が必要です。これは、誰かへの依存度が大きすぎるか、作業と範囲が広範に定義されすぎているか、基盤となるシステムが必要以上に複雑であることを意味します。
5. シンプル化の文化を構築します。つまり、マネージャー、シニア、インターミディエイト - 誰もが、「これは本来よりも複雑です。どうすればこれを簡単にできるでしょうか?」と言う権限を与えられる必要があります。フィードバックを集める - 特に後輩から。ジュニアは十分に評価されていません。彼らの経験の欠如は、彼らがナイーブであることを意味すると誤解しないでください.ジュニアは、より良い方法があることを常に知っているとは限りませんが、自分のエネルギーをどこに費やすか (そして浪費するか) について非常に率直です。
6. シニアが配達に貢献するたびに、その理由を見つけてください。毎日。時間。製品の P0 バグには、緊急のホット フィックスが必要でした。低レベルのコードを変更する必要がありました。ある顧客が話し合いを必要としていました。経営陣は最新情報のためのプレゼンテーションを必要としていました。

上げ潮はすべての船を持ち上げます。高齢者は、ボートではなく、潮であるべきです。

証拠はプリンにある

私のキャリアを通じての指針は、問題が生産性にどのように影響するかを理解することでした。より効率的なチームを作ることではなく、より影響力のあるチームを作ることです。プロダクト マネージャーには、アウトプットではなくアウトカムを測定するというマントラがあります。自分が何をしているかを理解している場合、効率は重要であり、それをより速く実行する必要があります。衝突は、不定形で、定義が不十分な、移動するターゲットです。適応が必要です。アジャイルの原則、OKR、リーン、カンバンが正しく使用されると非常に強力になるのはそのためです。

システム全体の成果に焦点を当て、システムの負債を返済することで、さまざまな方法で影響力を発揮する機会が得られました。

• SaaS ビジネスの場合、販売前の初期段階から本番環境へのコードのデプロイまでの基本的なプロセスを計画します。ボトルネックを特定するために、各段階の観点からリードとサイクル タイムを測定します。それを 1 つのシステムと見なすことで、クライアントのタイプに基づいて、より適切に認定し、より適切に不認定にする方法と、販売および実装プロセスをいつどのように再構築するかを特定できます。作業をプッシュするのではなくプルするかんばんアプローチを適用し、厳密な WIP 制限を設定し (スラックを考慮しながら -ゴールドラットのドラム-バッファ-ロープの類推を参照してください)、完了の定義を形式化することで、ワークフロー自体を継続的に改善することができました。最後に、この場合のもう 1 つの原則は、プロセスが生産性を妨げないようにすることでした。加速トラックを作成することで、可能な場合 (つまり「近道」) に物事をより速く進めることができますが、ベースライン プロセスがどこで失敗したか (つまり、システム負債の返済) の分析が常に行われました。自己管理体制になりました。
• ジュニア ファースト フィロソフィーを採用したことで、6 か月でチームの規模を 4 倍にすることができました。立ち上げ時間を短縮し、上級チームをジュニアの生産性に集中させることで、避けられないことを受け入れ、減少を予測できるようになりました。このアプローチにより、2 年間の目標を達成したジュニアには 2 つの魅力的な選択肢が残されました。スキルセットを成長させ続けながらジュニアを可能にすることに焦点を移す、より中間的な役割に卒業するか、チームと協力して円満に終了するかです。この透明性は、ジュニアがキャリアの不確実性に直面したときに感じる 2 年間の悩みに対処するのに役立ちました。
• 運用チームと開発チームを 1 つのプロセス傘下にまとめます。これによりチームが調整され、ワークストリームが並行するのではなく、循環するようになりました。運用チームのアウトプットが開発チームのインプットとなりました。開発チームのアウトプットは運用チームのインプットになりました。戦略的なフィードバック ループを備えた「生きた」プレイブックを実装することで、チームはますます自給自足できるようになりました。これにより、上級チームは運用に関与する必要がなくなり、リード タイムが 7 か月以上から 3 週間に短縮されました。
• SaaS 開発チームの視点を、ソフトウェア開発段階 (定義、実装、検証、リリース) から、完了に最も近い作業を優先しながらも、影響を重視してクライアントに焦点を合わせたものに変更します。これにより、デリバリー チームは影響と優先順位をよりよく理解できるようになり、ビジネスは影響の少ない仕事/クライアントをより認識し、重要視できるようになりました。
• ビルドと展開の時間を短縮することで、反復的な開発プロセスを合理化するための投資。これは、長いビルド/デプロイ プロセスの無力さのために、チームが頻繁に立ち去る「休憩を観察する」瞬間の 1 つです。重要なことは、修正が完全に技術的なものではなく、プロセスに基づいていたことです。新しいプロセスを確立することで、デリバリー チームの生産性が 200% 向上しました。
• プロセスの非効率性のためにソフトウェアを構築しない。興味深い問題を解決するためのコードを書くのは好きですが、新しいコードは最後の手段にすべきです。コードに近道がなく、それ自体に技術的負債がない場合でも、コードを維持する必要があります。あなたはより多くのシステム債務を導入しました - そして問題の根本に対処していません.これらのケースは蔓延しており、見過ごされがちですが、床にバケツを置いて屋根の漏れを解決するのと同じです.根本的な問題に対処することでこれらの修正を排除すると、計り知れない効率が生まれ、チームは重要なことに取り組めるようになります。

しかし、私は中間レベルのマネージャーにすぎません。組織全体の変更を実装するにはどうすればよいですか?

先に、ローカライズされた取り組みには限界があると書きましたが、私はそれを支持します。組織全体がより効率的になる方法を批判的に検討するとき、そこに真の改善が見られます。局所化された取り組みは、これまでのところしか達成できませんが、実際に達成され、達成されると、影響力の資本がもたらされます。

テイクアウト

これらの最終原則で締めくくります。

1. システム負債は、あらゆるビジネス ショートカット (ソフトウェア、設計、プロセス、またはその他) に対して発生します。それ自体は問題ありません。
2. 多額の借金は悪いことであり、継続的かつ意図的な返済が必要です。
3. この支払いはシニアチームが行う必要があります。上級チームは、将来の負債を負うリスクを軽減する方法にも焦点を当てる必要があります (最初にローカルの非効率性を探し、次にシステム全体の非効率性を探すことによって)。高齢者は成果物に取り組むべきではありませんが、行うときは 1 回にする必要があります。 「なぜこれが必要なのか、今後どのように防止できるのか」を尋ねるフィードバック ループを確立します。
4. システム負債の健全性を測る良い尺度は、新人チームのオンボーディングの健全性を確認することです。ジュニア チームが 18 か月後に退社するように計画します。それで大丈夫です。シニアチームができるだけ早く効率的になるようにします。
5. 問題を特定するためにジュニアチームの声を大胆にします。単純な問題でさえ、より深刻な問題を示しています (「電子メール アドレスを取得するのはいつですか?」、「テスト データを取得するにはどうすればよいですか?」、「私たちのチームは何をしますか?」、「ソース コードを取得しただけで、ビルド エラーが発生しています。」)
6. 役割に関係なく、18 か月後に退職する人を計画します。これもOKです。上級チームは、中断があっても継続的な配信を可能にするプロセスとパイプラインの構築に取り組む必要があります。彼らは、自給自足のプロセス、自己管理および自己組織化のチームを構築する必要があります。ジュニアチームは、繰り返しの作業になるため、最終的には飽きてしまうはずです。チーム メンバーは、常に積極的に自分自身を冗長で不必要なものにする必要があります。
7. 18 か月を超えて滞在する方向けのプランです。人員削減に取り組んでも、効率を高める仕事がなくなることはありません。結果重視の効率性に合わせて、ジュニアを中級者、中級者を上級者に昇格させるキャリア フレームワークを定義します。
8. 初日を最後の日のように扱う: 仕事の初日、従業員はオンボーディングに何が必要かについて最も良い視点を持っています。彼らは次のことを考えるべきです: 私が去った後に他の誰かが参加した場合、これはどのように改善されるでしょうか?
9. 愚かな質問のみのミーティングを定期的に開催します。人々が最もばかげた質問を (匿名で) 送信できるようにします。この方法で、最大の知識のギャップ (および問題) を見つけることができます。これらに対処する必要があります。
10. 定期的な「ペイ ダウン」ミーティングをスケジュールする: シニア チームを集めて、非効率な点を探します。それらの影響を犠牲にします。彼らの解決を犠牲にしてください。 (このリストが、あなたのシニアチームの仕事が尽きることがない理由です。)
11. アジャイルの最も重要な部分は、その適応性です。頻繁に調整してください。フィードバック ループがあります。以前は機能していたことが、常に機能するとは限りません。それは問題ではありません。それが標準です。絶え間ない変化と実験に抵抗する人は、彼らが認識しているよりも問題の大きな部分を占めています.
12. 最後に、おそらく最も重要なことですが、これは「チーム」の演習ではありません。これは、全社的な演習である必要があります。チーム内で局所的な効率化を推進することはできますが、それは限界にすぎません。そうは言っても、組織全体のアプローチに影響を与える立場にない場合は、マネージャーの賛同を得てから、チームを外部要因から隔離する憲章を作成してください。マネージャーと協力して、小規模なシステムの範囲、その入力と出力を定義し、システム負債をどのように評価、拡大、および返済するかについて承認を得ます。

それで全部です！ （彼は、彼の最長の記事を書いたことの完全な皮肉を認めて書いた。）