DX を推進する上での組織の重要性
DevOps State Report 2016 の内容
Google が毎年実施している DevOps State Report を分析した「Lean と DevOps の科学」において 2016、2017年度版を要約すると、以下の図のようになる。
ポイントは以下である。
- 「デリバリのハイパフォーマー」は品質も高い
- 「デリバリのハイパフォーマー」は「経営のパフォーマンス」(後述)も高い
- 「デリバリのハイパフォーマー」と「組織とアーキテクチャーが疎結合」、「テスト容易性が高い」の2点には相関関係があった
注意点としては左側のローパフォーマーの特性は書籍上明確に記載されているわけではなく、右側の特性と相反したものを列挙しているだけである。
今回掘り下げていくのは以下の点である。
- 組織とアーキテクチャーが疎結合
【参考】経営のパフォーマンス
ここでは「経営のパフォーマンス」とわかりやすく記述を変えているが書籍上は「組織のパフォーマンス」と記載されている。
デリバリのハイパフォーマーは「経営」のパフォーマンスも高く、デリバリのローパフォーマーの2倍も結果が異なる。
組織とアーキテクチャーが疎結合とは
組織とアーキテクチャーが疎結合とはどういうことか、書籍の中身を記載する。
アーキテクチャーが疎結合
これは本書 P.77 において以下の説明がされている。
コンテキスト境界と API により、大規模なドメインを、より小規模、より疎結合なユニットに分割する。
テストダブル(ソフトウェアのテストでテスト対象が依存するコンポーネントを書き換えた代用品)と仮想化により、サービスやコンポーネントを独立した形でテストする。
1点目はドメイン駆動設計のことを表している。詳細については以下の記事に記載されているが、要約すると意味のある領域でドメインを分割し、それらドメイン同士を疎結合に繋ぐという話である。まさに1点目のことを指している。
2点目は自分のサービスが必要としている対向のサービスが、実際には存在しなくても(開発中等)、自分のサービスはテストできることを意味している。具体的にはサービス仮想化の手法を用いて単独でテストできるという意味である。
サービス仮想化に特化したプロダクトをひとつ紹介する。
組織が疎結合
組織が疎結合とはどういうことだろうか。このことについては本書 P.76 に以下の記載がある。
チーム間のコミュニケーションの状態とシステムアーキテクチャとのこのような関係を最初に論じたのは米国のコンピュータ草創起のプログラマー Melvin Conway であり、具体的にはこう述べた — 「システムを設計する組織は＜中略＞その組織のコミュニケーション構造を反映した設計しか生み出せないという制約に縛られる」。これに対して我々の調査研究では「逆コンウェイ戦略」とも呼ばれる考え方 — 組織はチーム構造と組織構造を進化させて、望ましいアーキテクチャを実現すべきだ、という考え方 — を裏付ける結果が出ている。
長々と書いたが一言で言うと「逆コンウェイ戦略」である。
疎結合なアーキテクチャーを「ドメイン駆動設計」で描くことができたのであれば、そのアーキテクチャーに合わせた組織に変革する、ということである。描いたアーキテクチャーが理想的であり、かつ疎結合であるため、それに合わせて組成した組織も疎結合になるという寸法である。
「逆コンウェイ戦略」については、以下のスライドを参考にしていただきたい。「コンウェイの法則」は P.31 から丁寧に解説されている。
組織・アーキテクチャーが疎結合になることによるメリット
この記事を読んでほしい。この記事に全てが書いてある。
“ビル・ゲイツがこだわる“プロジェクトの同時進行”
テスラはモジュールを使っています。「ジャスティスの法則」というものがあり、それは製品のモジュールが会社の意思を決めるということです。
多くのチームは、お互いを待つことなく活動できます。ビル・ゲイツがその方法を教えてくれました。すべてのプロジェクトは、モジュールに分割されます。各モジュールはそれぞれのチームを持っていて、セントラルサービスを待つ行列を作るセントラルサービスチームを回避します。
（スライドを示して）ビル・ゲイツはプロジェクトをパラレルで同時進行で行うことにこだわっていました。なので、私が彼のチームのスクラムマスターだった頃、彼はミーティングに出ると必ず、このプロジェクト、作業はいかにパラレルで同時進行できるのかと聞いてきました。
モジュールに分けるとこのようになります。モジュール単位で分割していて、それぞれが独立したチームを持ち、お互いを待つことなく独立して作業を行います。そして最後に、ほかの部分との連携や統合のテストを行います。
＜略＞
（スライドを示して）「Model S Plaid」のバッテリーパックの図です。
この冷却水の出口と入口が互換性があるので、このモデルを変えたとしても、いつでも新しいものに更新できます。Web開発でも同様だと思いますが、アダプターをつけて、インプット・アウトプットに互換性を持たせれば新しいものがどんどん更新できます。モジュラー・アーキテクチャは、お互いを待つことなく数百のチームが並行して作業するのに有効です。
この入り口と出口に相当するのが分割したドメインが所持すべき API のエンドポイントである。API のインターフェースさえ変えなければ(チーム間のやり取りのインターフェースが変わらなければ)、サービスはチームの責務でどんどん変化させていける。他チームの許可は必要ない。必要ないようにドメイン駆動設計でドメインを区切ったからだ。
製品はモジュールに分割され、モジュールごとにチームが結成される。チームは独立して動き、疎結合であるために他チームの影響を受けない。数百のチームがパラレルで走る。
このような組織には従来通りのウォーターフォール＆モノリスで作業する組織では勝ち目がない。
DX State Report の要約を振り返ってみる。ハイパフォーマーとローパフォーマーでは 2 倍以上の差がつく理由がわかってきたと思う。
組織の構成方法と権限移譲
いくらアーキテクチャーを疎結合にし、組織を疎結合にした(つもりだ)としても、組織の構成次第では疎結合ではなくなる。
例えばサービスの Go Live を判定する QA が別部門であったり、サービスに脆弱性がないかを判断する Security 担当者がサービスの当事者とは別の組織に所属していれば、許可を得るために組織を超えたワークフローが発生してしまう。これは疎結合な組織とは呼ばない。
こうした機能カットで組織が作られたチームのことを「コンポーネントチーム」と呼ぶ。
対して、すべての機能を持たせたチームのことを「フィーチャーチーム」という。フィーチャーチームでは組織を超えた依頼事項は発生しない。組織の中だけで問題を解決できるため、待ち時間は非常に小さい。つまりバリュー・ストリームを短縮化するために考えられたチームの構成だ。
※ただし上述の Smart HR Tech Blog に記載があるようにデメリットも存在するので、デメリットを解消するような運用も必要となる。
参考までに日本 CTO 協会では、DX の取り組み度合いを計算するためのチェックリストを公表しており、その中にフィーチャーチームになっているかを問う項目がある。
ちなみにこの DX Criteria には疎結合アーキテクチャーについてのチェックリストも存在する。
各ユーザー部門がフィーチャーチームを結成して、全機能を所有した状態になると、チームにはある程度の権限が移譲される。
決裁権は CxO から市場に
IT とビジネスの関係を見てみよう。
1990年代は CIO に決裁権があり、IT は既存のビジネスモデルを手助けするような関係性だった。
2000 年代には既存のビジネスモデルに寄り添うような IT の立場は変わらないものの、CEO に決裁権が移る。
2010 年代に入ると新しいビジネスモデルに関わるようになり、IT は必須なものへ変動していく。
2020 年代に入ると新しいビジネスモデルの開発において IT はコアとなる。さらに CEO から市場に決裁権が移る。これは Data Oritented Business であることを意味する。
市場が決済権を持っていて、さらにデータによってそれを明らかにしている良い事例がある。
上記は DX が本来の意味とは別の方向に行ってしまっていることを嘆いた経済産業省のレポートになるが、その2ページ目を見てほしい。
和泉氏は、その例としてカーシェアリングサービスにおいて「走行距離0kmの利用者が約半数というデータ」が取得された際の取り組みを紹介した。普通ならば「使い勝手が悪くて利用できていないだけではないか」と考えがちだが、懸賞付きアンケートで能動的に生の声を収集したところ、「家のカギを忘れたためクルマの中で過ごした」「外回り中の電話ボックスとして活用」「防音室代わり」などと、予想だにしなかった使われ方がわかったという。そうした声からサービスを改善し、走行距離による課金よりも、簡単に短時間でも借りられるように利用者の利便性を向上させることで、ユーザーの満足度を高めることに成功している。
これはまさに市場が決裁権を持っており、データによってビジネスモデルを変革したよい事例だ。CEO に決裁を委ねていたらきっと走行距離が長くなるような明後日を向いた施策を行なっていたはずだ。
DX 推進において IT 部門によるガバナンスはもう古い
以下は AWS Summit 2021 でクレディセゾンが発表した資料の抜粋である。
モード1、モード2という言葉はすでに流行っていないかもしれないが、それぞれ SoR、SoE という単語に置き換えれば理解できるはずだ。
この中で重要なのは、SoE の世界ではユーザー部門(+ DX 推進部門)による分散管理になるということである。なぜならチームにある程度の権限が委譲されているためである。
まとめ
DX を推進する会社では(DX を推進するしないに限らないが)、組織とアーキテクチャーが疎結合である方が有利だということを見てきた。デリバリのハイパフォーマーがデリバリのローパフォーマーの2倍以上の経営のパフォーマンスを叩き出しているデータが存在する。
ここでいう組織というのは、コンポーネントチームではなく、フィーチャーチームである必要性も見てきた。QA だけチーム外です。なんてことになると、「行程移行ごとに QA の承認が必要です」となり、バリューストリームが極大化してしまう。
全機能を持ったチームを結成するとある程度の権限がチームに移譲され、これまで IT 部門が担ってきた構成管理であったり、リリース管理であったり、キャパシティ管理はユーザー部門に委ねられることになる。この部分だけ IT 部門に依頼しますとなると、フィーチャーチームを結成した意味がないからだ。部門を跨ぐ承認行為はバリューストリームを長期化させる。ITIL(R)v4 もそれを見据えた変更になっている。
ただし、ユーザー部門ごとに構成管理を実施したり、キャパシティ管理を考えたりすると、人材不足を加速させるし、サービスレベルを悪化させる要因にもなったりする。
そのため、こうした手間を自動で実施してくれるプラットフォームを選ぶ会社が多くなっていくと推察する。Kubernetes はその代表格だろう。
最後に
組織を変革しないままシステム、ワークフローを実装する会社で働いている人は根本原因を解決しないまま、延命処置(対処療法)を行なっているヤブ医者と同じだぞ。
