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

あなたが、モダンでアジャイル、そして自己組織化する組織へと変革させるための対象組織を選ぶとしたら、どこにしますか？世界最大の運輸会社の 1 つであり、ドイツ国営で 150 年の歴史を持ち労使協議会もある鉄道会社の組織を選びますか？おそらく選ばないでしょう。ですが、ドイツ鉄道 ( Deutsche Bahn ) グループの一部である DB Systel 社は、適切なリーダーシップ、粘り強さ、そしてマインドセットがあれば、どんな組織も変革できることを示しています。AWS での会議で、DB Systel 社の前 CEO である Christa Koenen が、変革の成功だけでなく失敗についても話されていたことを思い出します。これは、変革が実際にどのように起こるのかについての、バランスの取れた見方です。

この最初のブログ投稿では、この変革に深く関わっている René Schneider と Andrea Sturm の二人が、DB Systel 社が従来の階層組織から自己組織化されたチームにどのように変革し、素早く、費用対効果が高く、多くの組織を悩ませる官僚的オーバーヘッドを削減できたかを共有します。DB Systel 社は、今では 20％ 多くの収益を実現しつつ、改善するためのさらなる方法を探し続けています。このアプローチにより、DB Systel 社は AWS クラウドへの移行を予想よりも 18 か月早く完了し、従来の IT サービスプロバイダーではなく、デジタル化の推進者、そして価値提供者となることができました。 それは私を大いに勇気づけるものでした — 読者の皆様もそうなることを願っています。

ドイツ鉄道 ( DB ) グループは巨大で、基本的な鉄道運営とロジスティクスを担当し、ドイツ最大のレンタカー会社と不動産ポートフォリオのホテルを運営し、エンジニアリングと重工業に携わっています。 銀行業以外の全てです！ 32 万人を超える従業員を擁するこの企業は、ヨーロッパで最大かつ最も複雑な企業の 1 つです。

ほとんどの組織と同様に、ドイツ鉄道は、柔軟性、スピード、変化する顧客行動の要求に対応するために、数年間をかけてビジネスのデジタル化に注力してきました。 既存の事業へのコスト圧力と、新しい技術及びイノベーションの要求を考えると、それは困難な取り組みでした。DB Systel 社は約 800 ある子会社の一つですが、グループに専門的なスキルをもたらし、クラウドインテグレーターかつイネーブラー、そしてデジタル化の推進役としての役割を果たしています。

この変革の旅の早い段階で、書かれた仕様をそのままドイツ鉄道全体で使用するための統合された新サービスに変換するというアプローチでは不十分であることが、すぐに明らかになりました。顧客や市場が要求する速いペースの変化に適応するには、より根本的な変化が必要であり、回避するべきブロッカーではなく、イネーブラーになる必要がありました。 古典的なテイラー主義の指揮統制による企業構造は、変化する必要がありました。

変革が完了することは決してありませんが、今日私たちが変化させたものは、すでに私たちの期待を超えています。このブログでは、私たちがどのように変革を達成したかについての物語をお話しします。悪魔は細部に宿る（訳註：一見良さそうなことも、細かいところに落とし穴があるかもしれない）ものですが、これが皆様自身の組織をより良いものにするための旅路にインスピレーションを与えることを願っています。 眠っている組織の真の可能性が解放されたとき、何が起こるのかワクワクします！

私たちの挑戦

より迅速な変革を可能にするためにクラウドのような革新的なサービスを採用したにもかかわらず、私たち自身の組織構造と長年にわたって作り込まれてきたサポートプロセスにより、私たちは需要に追いつくことができませんでした。たとえば、数回のクリックで利用可能な AWS の新しいクラウドサービスは、社内調整作業のために、お客様が利用できるようになるまでに数か月かかりました。組織の複雑さ、部門の利己主義、および複雑な意思決定がこれを悪化させました。 欲求不満に陥った顧客は、しばしばこれらのサービスを自分自身で購入して活用していました。

新製品はさらに悪く、長く複雑なプロジェクトが必要でした。 さまざまな部門のさまざまな専門分野で構成されるプロジェクトチームは、30 人からなるチームが一般的であり、調整会議やディスカッションが増えました。これによりコストは上昇し、顧客のほとんどのビジネスケースが台無しになりました。

さらに悪化させたのは、ますます増える空きポジションを埋めるための従業員を探すという課題でした。テクノロジー業界は失業率が低く、旧来のデータセンターを運営している埃っぽい IT サービスプロバイダーであるという我々の評判により、我々の会社は入社する魅力のない企業になっていました。

現在の状況

私たちは過去 7 年間、私たち自身の期待を上回ってきました。今日の DB Systel 社に利益をもたらす前向きな開発の多くは、以前は明らかなものではなく、これは変化のためにアジャイルアプローチをとる必要性を強調しています。

アジャイルな働き方は、生産性を高めて来ました。 私たちは一定の速いリズムを持っており、それは透明性が高く各自の役割が明確なものです。仕事を時間制限のあるサイクルに分割することで、分析麻痺（訳註：いつまでも分析を続けて行動に移せなくなること）を防ぎ、行動することに集中できます。

働き方に多くの変化があったことを考えると、従業員の満足度が高まったことは驚きでした。こうした変化により、作業がより簡単で楽しくなることを従業員が理解していることが、すぐに明らかになりました。管理のための調整オーバーヘッドなしで意思決定を行う権限を与えられたことは、私たちを自由にしました！従業員の離職率は減少しました。議論の対象は、「懸念や課題」から「本当に解決する必要があるときだけ問題を解決すること」に変わりました。

これらすべてによる 1 つの結果は、今日 DB Systel 社がドイツを代表する企業向けクラウドインテグレーターの 1 つになっており、他のドイツ企業より 18 か月以上先を行き、550 を超えるチームが IT 領域およびそれを超えるそれぞれのビジネスを継続的に開発するようになっていることです。

基礎を築く

変革の開始時に、私たちは新しい仕事の仕方への旅の前提条件について深く考えました。 旅がどのように展開するのか、最終状態が実際にどのようになるのかは、分かりませんでした。 私たちは、外部の視点を攻撃ではなく歓迎すべきインプットと見なし、絶えず批判的にそれ自体に疑問を投げかけるシステムを確立することでこれに対処しました。

トップマネジメントのコミットメントがなければ、私たちは失敗したでしょう。 これは単なる支援以上のものでした。 彼らの積極的な参加は変化を形作り、能動的に問題に取り組むなど行動で示されるリーダーシップを実証するのに役立ちました。これは DB グループを前進させるために、自己組織的でアジャイルな方法で作業するという、シンプルで明確なビジョンによってサポートされていました。私たちはすでに、たとえばクラウドに関してポジティブな成果を経験していました。クラウドの真の可能性は、意思決定とコミュニケーションのプロセスを変えることによってのみ、解き放つことが可能です。ボタンを押すだけでテクノロジーを変えることができるのに、実際にボタンを押す決断を下すのに 3 週間かけているとしたら、問題があります。

同じくらい重要な成功要因として、従業員代表の関与があります。共有されたビジョンにより、一般労務契約が変革のために交渉され、生きた文書として作成され、経験と学習に基づいて進化することを可能にしました。

これらの前提条件に加えて、変化の途中で私たち自身が守るべき原則を定義しました。 中心となる原則は、組織横断のアジャイルチームの形成で、各チームは最大 9 名までとし、各チームが構造を決定することとしました。私たちは Douglas McGregor の 1960 年代の XY 理論を踏まえ、人間は制御ではなく意味とオーナーシップを求めて努力することを認識しました。仮説の使用は、決定をテストし迅速かつ継続的に学習することを奨励しました。これにより、不要な作業とリスクが軽減されました。私たちは、休暇計画、給与管理、予算管理など 110 の典型的な管理タスクを分析し、これらをチームの各メンバーまたはチーム自体に割り振りました。これによりチームの責任が増し、より多くのオーナーシップを取る意欲が生まれました。各チームは、コスト、収益性、チームメンバーの継続的な育成など、彼らのビジネス全体の責任能力を発展させていきました。

その過程で、従来の管理構造は不要であることに気づきましたが、これによりチームが行う必要のある作業も増え、適切な構造で日常業務をサポートする必要性が高まりました。これらの構造はサーバント・リーダーシップ (訳註：まず相手に奉仕し、その後相手を導くという発想のリーダーシップ) に基づいているため、チームから説明責任が失われることはありません。中間管理職の概念は冗長になりました。

2 番目の原則は、適切なビジネスリズムに合わせて働くことでした。 各作業サイクルは、次の作業サイクルへ情報を伝えました。レトロスペクティブ (訳註：スプリントの振り返り) では、目的の明確さ、付加価値、および測定可能な受け入れ基準を確立するためにどんな変更が必要かを特定しています。以前のプロセスとは異なり、これらのレトロスペクティブではテクノロジー、人、プロセス、そして関係性といった包括的なトピックにフォーカスしていました。何年にもわたって毎週のレトロスペクティブを実践してきた成熟したチームでは、技術的なトピックではなく、日常の業務サイクルの中でのサポートチームや顧客の巻き込みといった「関係性」に多くの時間を費やしていました。

DB Systel 社の戦略的方向性が、独立して作業するチームによって確実に守られるようにする方法について、すぐに疑問が生じました。ここでの原則は、「何を」と「どのように」を分離することでした。経営層は戦略的ゴールを設定し、それはサポート構造を介してチームにカスケードダウンされ、戦略はビジネス目標に変換されます。これらの目標は「何を」達成する必要があるかを定義するだけであり、「どのように」目標を達成するかについての責任はチームにあります。

開始する

私たちは「はじめに苦痛ありき！」という原則から変革を始めました。 苦痛とは、DB Systel 社がデジタル化の推進役ではなく障壁と見なされていたことでした。私たちは、アジャイルの原則に基づいた、複数の専門分野にまたがる変革チームを設立しました。そのチームは、継続的な学習に基づいて、変革を進めるためのガイドラインを作成するという任務を負っていました。当時、変革がその途中のほとんどすべてに影響を与えるとは思っていませんでした。

私たちの最初から今も変わらないゴールは何でしょうか？それは、短期間での反復作業と素早いフィードバック、そして高度な透明性によって変化を予測することにより、絶え間ない変化に対処しつつシンプルに顧客の利益を最大化することです。 基本的に、私たちはビジネスへの重要な貢献者として理解されたいと思っていました。

新しく結成されたアジャイルチームはすぐに成功しました。 クラウド環境では、以前と比べてより効率的で柔軟、かつ高い費用対効果で顧客要件が満たされました。この成功により、より多くの自己組織化されたアジャイルチームが開始され、ほとんどすべてが内部リソースになりました。 既存および新規のビジネスは、段階的にこれらのチームに移行しました。私たちは、従業員がこの新しい働き方の一部になりたいと考えていることに気づきました。

私たちの新しい働き方は、ビジネスパートナーだけでなく、チームメンバーにとっても解放され、やる気を起こさせ、DB Systel 社全体の才能を解き放ちました。

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