他者から学ぶ：DB Systel 社の変革 (パート2)

最初のブログ投稿で、René Schneider と Andrea Sturm は、DB Systel の変革の旅の理由と方法について説明しました。ここでは、組織が現在どのように構成されているか、およびこの状態を達成するために取られたいくつかの手順について詳しく説明します。カット&ペーストで真似できるパターンではありませんが、彼らのストーリーには、あらゆる組織に適用できる気づきと洞察が見られます。結局のところ、DB Systel のような伝統的なレガシー組織が変わることができるのであれば、きっとあなたの組織も変わることができるでしょう。

DB Systel では、アジリティマスター (AM) とプロダクトオーナー (PO) を含む 5 人から 9 人で構成されるチームが中心的な組織構造です。従来のアジャイルフレームワークから着想と知識を得て、役割とプロセスは私たちのニーズに合わせて調整されました。たとえば、AM にはスクラムマスターの説明責任がありますが、雇用主としての義務の順守を促進する責任もあります。チームが少人数であることは、強固な関係性、意思決定の透明性、イノベーションに必要な多様性を可能にし、促進します。すべてのチームは小規模企業のように行動し、収益、コスト、人事、および個々の KPI を満たしながら、価値を生み出すための独自のビジネスケースを作成します。

チームには3つのタイプがあります。デリバリーチームは既存のビジネスにサービスを提供する責任を負い、アカウントチームは新しいビジネスを担当します。これらのチームを組み合わせることで、顧客との関係を築き、価値の創造に注力することもできます。 エンタープライズチームは、人事やガバナンスなどの分野でサポートを提供します。

変革: 一度に 1 つのチーム

この構造を実装するには、すべてのチームが新しい働き方を採用する機会と時間を確保できる変革プロセスが必要でした。これは 3 つのフェーズを経て達成され、能力と自信を高めることができました。

第 1 フェーズでは、チームに自己組織化とアジャイル手法の基礎を 3 か月間に渡って習得させます。チームは最初のアイデアを検証可能な仮説として発展させます。例えば、「我々が目指す俊敏な働き方とはどんなものだろうか？」や、「我々がお客様に対して提供する価値は何か？」といったものです。このフェーズの完了は、変革チームのメンバー、組織の従業員、サポート担当者、従業員協議会で構成されるグループによって認定されます。

第 2 フェーズでは、チームは仮説を 6 か月にわたって反復して検証します。これにより、働き方と原則を検証し、ビジネスケースをよりよく理解し、チームとしての一体感と有効性を築く機会を提供します。

最終フェーズでは、1 年以上かけてチームの開発を続けます。チームは担当するビジネスとその商業的側面に責任を持ち、課題に効果的に対処する回復力を示し、起業家であり雇用主としての義務を果たすことができることを証明します。

ほとんどの幹部社員に対しては、上記の各フェーズで 3 ～ 6 か月の追加期間が必要であることが分かりました。リーダーは変化を語りたいと思うかもしれませんが、実際にはチームと同じか、それ以上に変化する必要があります。ボタンを押すだけのトップダウンの組織変更は、まずうまくいきません。

従来のデータセンター運用から自己組織化されたアジャイルなクラウド運用への切り替えは、これらすべてがどのように統合されたかを示す好例です。チームは、データセンターの代替としてクラウドでサービスを提供し始めました。すぐに、調整が減って意思決定がこれまでより迅速かつ柔軟に行えることが明らかになりました。これは、チームが決定権を持っていたためでした。その結果、より費用対効果の高い方法でサービスを提供できるようになり、追加のビジネスを獲得するための時間が解放されました。こうして最初のクラウドチームが誕生しました。

この成功により、時間の経過とともに他のチームが形成され、既存のビジネスと新しいビジネスを徐々に引き継いでいきました。クラウドは自動化によって多くの活動を簡単かつ迅速にしましたが、これらのチームはクラウド以外にも対応しました。現在、これらのチームはクラウドで運用していますが、オンプレミスアプリケーションやその他のテクノロジーサービスも利用しています。

今日、私たちは DB Systel を、自己組織化、アジャイルなマインドセット、明確なプロセスモデルなどの原則に基づいたアジャイルな組織に完全に作り替える寸前まで来ています。これを支えていたのは、改善への絶え間ない欲求であり、私たちが予見できなかった重要な要素であり、既存の階層を段階的に解消するための実現手段でした。

階層との訣別

新しい構造により、中間管理職の責任はますますチームへと引き継がれ、従来の階層が不要になりました。この階層の解消は、ある時から一斉に切り替えたのではなく、むしろ、それは自然発生的に起こりました。

チームがビジネスの完全な管理責任を負うようになると、多くの同僚が負担を感じ、優先順位を調整しなければならなくなりました。たとえば、チームは従来の日常業務に加えて、ツールや標準の選択と導入などのタスクを実行しなければなりません。

これに対処するために、ユニットとクラスターと呼ばれるサポート構造が導入されました。これらは部門やマネージャーのことではなく、チームの自律性を薄めることなくチームをサポートするために共に働く構造です。これらの軽量構造のコストは、追加の売上を生み出すことでチームが負担しました。

ユニット

ユニットは、9 つのチーム間でシナジーを生み出し、サイロ化された部門の世界に戻ることなく、彼らの日常業務をサポートします。彼らは、自己組織化され、俊敏かつ継続的に改善するチームであり、サポートされているチームの AMたちと POたちで構成され、専任のユニット AM と PO が組み合わされています。

彼らが取り組む課題は、チームの成熟度によって異なります。ビジネスの構築、雇用主としての義務の遵守、またはチーム間の障害の解決に支援が必要な場合があります。成熟したチームに対しては、摩擦を取り除くために顧客を開発プロセスに統合するためのサポートが必要になる場合があります。

ユニットは、制度の「上」で機能し、サーバント・リーダーシップ (訳註：まず相手に奉仕し、その後相手を導くという発想のリーダーシップ) に基づいて運営されます。これは私たちにとって、新しいことでした。チームが属する制度とその周辺の制度を、継続的に開発し続けるのです。私たちが取り組んだ側面には、構造とチームの多様性、プロセス、ステークホルダー管理、レトロスペクティブ (訳註：スプリントの振り返り) 、自己組織化手法、キャパシティ計画、協力モデル、価値、回復力が含まれます。これらの改善は、ユニットによって促進され、チームの成熟度に関係なく継続的です。

クラスター

最大 9 つのユニットがさらにクラスターとしてまとめられ、包括的な顧客部門または事業部のために一緒に活動しました。クラスターもシステム上で動作し、包含するユニットの AM 達と PO 達で構成され、専任のクラスター AM および PO によってサポートされます。クラスターは、組織の全体的な能力を向上させ、分野横断的なプロセスを開発するために協力します。

クラスターは、予算や人員計画など、会社全体のプロセスに対応します。ここでユニットは、マネージメントと話し合うための計画作成と結果のクラスターレベルでの統合において、チームをサポートします。これにより、トップダウンとボトムアップの計画が効率的かつ効果的に統合されます。これは伝統的なアプローチのように聞こえるかもしれませんが、私たちの計画作成アプローチは通常、従来のトップダウンによる計画作成よりもはるかに野心的です。なぜなら、彼らは顧客との日々の関わりや、自分の仕事や周囲の傾向に関する深い知識を通じて、より多くの情報を得ていたからです。

リズムの確立と利益の一致

自己組織化されたチームが、シャワーヘッドを販売したり自転車を作ったりするのではなく、会社の利益のために行動するようにするにはどうすればよいでしょうか？！それには、企業戦略を広く深く理解することが必要であり、ユニットとクラスターがこれを支援します。

9 つのクラスターのそれぞれから AM と PO を集め、戦略を理解してチームが実行可能なフレームワークに変換するための管理しやすいチームを作成し、チーム自体からの情報も提供しました。リズムが確立されました。この戦略は、クラスターによって 3 ～ 6 か月ごとにエピック (訳註: アジャイルプロジェクト管理の用語。ニーズやリクエストに基づいて特定のタスクに細分化できるまとまった作業のこと) に変わり、さらにユニットによって 2 ～ 3 か月ごとに機能に変わりました。エピックは、古典的なユーザーストーリー形式 (誰のために ? 何を ? なぜ ? ) に従って、ビジネスの理論的根拠、目的、および受け入れ基準を定義し、チームが実装の「方法」を自由に決定できるようにしました。その後、チーム自身が 1 ～ 4 週間のスプリントで作業します。各サイクルは、レビュー、レトロスペクティブ (訳註: 振り返りミーティング) 、および計画作成で構成されます。

追加の役割

私たちの変革を可能にするために、他にもいくつかの役割が作成されました。 シニアコーチは、パフォーマンスやプロセスなどの側面について、変革の第 1 フェーズでチームにアドバイスします。 アジャイルマネージャーとアジリティインストラクターがこの後の支援を行います。アジャイルマネージャーは、特に既存のライン組織との対立が発生した場合にチームが変革するための安全なスペースを提供し、チームが独立し自己組織化された作業に適応するのを支援します。アジリティインストラクターは、アジャイルの価値と方法を教え、方法論の知識によってチームをサポートし、積極的にフィードバックを提供します。

現在、5,000 人の従業員を抱える会社に、約 80 人のアジリティインストラクター、40 人のアジャイルマネージャー、15 人のシニアコーチがおり、全員が社内で育成されました。はい、それは複雑で費用のかかるプロセスでしたが、マインドセット、手法、および手順を徐々に作り上げていくためには不可欠でした。

ガバナンスと標準 … 改善された！

私たちは、法務、コンプライアンス、およびガバナンスのために、個別のチームを作成しないことに決めました。これは、すべての対立と説明責任の弱体化を引き起こす、一元的な仕様開発の罠に陥るのを避けるためです。

代わりに、セキュリティなどの特定のガバナンス領域を担当する仮想の「ギルド」を作成しました。ギルドメンバーは主にデリバリーチームから来ており、ギルド活動に時間の一部を費やしています。これにより、仕様を実用的に翻訳できるようになり、チームは最小限の労力で仕様を実装でき、追加のメリットも得られました。これにより、オーバーヘッドと調整メカニズムの必要性が削減され、ガバナンスの問題に対する全社的な認識が高まりました。

成功へのもう 1 つの鍵は、各チームは小規模企業に類似しており、限られたリソースで経済的に行動する必要があることです。彼らには、すべての新しいトピックや必要とするツールに対応するための時間の余裕はありません。そのため、サポート体制の助けを借りて現在のベストプラクティス情報を交換したり、既に使用されているツールを採用したりしています。多くの場合、各チームは必要に応じて 1 つのツールに収束しますが、これはチーム自身によって決定されます。皮肉なことに、分権化された構造により、エンタープライズアーキテクトが以前は夢にも思わなかったレベルの標準化が会社全体で推進されました！

従業員のスキルアップ

トレーニングと認定は成功に不可欠であり、必須と任意の定義など、適正にするために幾度かの反復が必要でした。AM と PO のための数日間にわたる資格認定プロセスは、潜在的な候補者に DB Systel でのアジャイルで自己組織化された作業の基礎を教えるオリエンテーションから始まります。2 つの 3 日間の「資格キャンプ」では、自己組織化構造、アジャイルな姿勢と手法、段階的なチーム開発、問題解決、顧客フォーカス、レジリエンスなど、チームのライフサイクルの実用性に焦点を当てています。資格を得るには、通常、一緒に仕事をしない PO と AM が、学んだ内容をどのように適用するかを数時間にわたって複数のオブザーバーに示し、プロセスを通じてフィードバックを得ます。

重要な教訓は、AM と PO の学習ニーズは、個人の成長段階とチームが変革プロセスのどこにいるかによって、大きく異なるということです。私たちのアプローチにより、特定の状況に基づいて知識を調整することができます。

労使協議会と変革

他の多くの企業と話をする中で、私たちは変革のアンチパターンを見てきました。それは、利害関係者からの支持の欠如が変革を遅らせていることです。これを避けるために、私たちは最初から労使協議会に参加してもらいました。私たちは、労使の共同決定を必要とするすべての問題の解決策を見つけるために協力することに同意しました。これを達成するには、信頼の強固な基盤が不可欠でした。

私たちは、アジャイルの原則、採用、チームの編成と解散、職務定義などの重要な決定について、独自の労使協議会の合意を作成しました。従来の契約よりも、我々の契約は 3 から 6 か月ごとに新しい課題と洞察を取り入れて反復的に発展し続けるため非常に柔軟であり、かつ従業員代表の利益を保護するものになっています。

現在も進行中の私たちのジャーニーが、あなた自身のジャーニーへの洞察とインスピレーションを与えるものでありますように。

この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルはこちら）

Amazon Web Services ブログ