DevOpsのテキスト研修

DevOps組織をどう作り、ソフトウェアアーキテクチャをどう設計するか

コンウェイの法則によれば、システムを設計する組織が作るシステムは、その組織のコミュニケーション構造を写し取ったものになります。つまり、チーム間の意思疎通や連携の効率が、ソフトウェアの限界になります。チームの構成はソフトウェアアーキテクチャ、IT、そして最終的には事業の成果にも影響します。

組織の構成が、どのようなソフトウェアを作るかを決める

多くの企業は、おそらくあなたの会社も含め、ソフトウェアデリバリー組織を複数のチームに分け、結果としてチーム数と同じ数の層を持つソフトウェアを作ります。対照実験でも、6チームで構成される組織にソフトウェアの開発を依頼したところ、6層のアーキテクチャができました。別の3チームの組織にまったく同じソフトウェアを依頼すると、3層になりました。同様の例は多数あります。

世界に86,000人の従業員を抱える著名な保険会社では、顧客、契約、請求書、サービスを管理するバックエンドを提供するIT組織が、たまたま二つの主要な職能別チームに分かれていました。一方はJava、もう一方はPL/SQLのストアドプロシージャを専門としていました。さらに、組織全体で一元化されたIT運用、データベース管理、ITインフラ、ネットワーク、ITセキュリティ、IT品質保証の各サービスデスクに依存しており、ソフトウェアを安全に届けることは一層難しくなっていました。

チームは分かれていても、アーキテクチャ上は、Javaのビジネス処理の調整ロジックとPL/SQLのデータアクセスロジックをうまく分離できていませんでした。何百もの機能を提供しましたが、一つひとつにJavaとPL/SQLのコードが複雑に絡み合っていました。そのため、変更や新機能の要望があるたびにチーム間で何十回も引き継ぎが発生し、小さな変更でさえ、長い待ち行列とリードタイムを要しました。この複雑な環境では、小さな変更が全体に与える影響さえ予測しにくく、本番の既存機能を壊してダウンタイムを繰り返しました。復旧にも長い時間や手戻りが必要で、上位者への報告が相次ぎ、ストレスが増しました。

この働き方から脱するため、二つの職能別チームを一つの製品チームに統合しました。データアクセス層をAPIの機能群に切り替えながら、段階的にソフトウェアを再設計しました。さらに、データアクセスAPIの内部の動作と完全に切り離した、新しい業務システムを構築しました。初期の段階から士気が高まりました。JavaとPL/SQL双方の専門家が、以前の縦割り部門の都合から離れ、共通の製品チームの成功のために働き始めたからです。疎結合なアーキテクチャによって、変更の影響を見極めやすくなり、変更を容易かつ迅速に実装でき、不具合の特定と修正も簡単になりました。その結果、新機能の平均リードタイムは4か月から3週間に短縮されました。チームの未処理インシデントは今ではほとんどなく、余力をコードベースのさらなるレビュー、リファクタリング、改善に使っています。

マトリクス組織、職能別チーム、コスト最適化の幻想

企業では、データベース、ネットワーク、運用、情報セキュリティ、品質保証、リリース管理、プロジェクト管理、製品管理などの専門分野ごとに、複数の職能別チームを編成します。プロジェクトチームは、異なる縦割り部門のメンバーで構成されます。事業用の製品やサービスを届けようとするマトリクス型のプロジェクト組織では、一般にプロジェクトマネージャーは何かを届けること、プロダクトマネージャーは適切なものを届けることに責任を負います。

この組織構成の問題は、職能別チームが自分たちの仕事がどこまで影響するかを、ほとんど理解していないことです。極端ですがよくある例では、職能別チームは全体像にも、自分たちが関わる製品やサービスのITおよび事業全体の成果にも関心を持ちません。プロジェクトがうまくいかず、責任のなすり合いが始まったときに、自分たちに落ち度がないようにすることを気にかけます。

職能別チームは通常、多数のチケットを抱えているため、プロジェクトを支援するまでに長い時間がかかります。プロジェクト同士が各分野の人材を奪い合い、自分たちの案件にすぐ対応してもらうには、上位の責任者に訴えるしかありません。それを繰り返すと、職場の雰囲気とチーム間の信頼が損なわれます。

チーム間の引き継ぎの繰り返し、遅延、品質問題、手戻り、ボトルネック、ストレスが日常業務の一部になります。実態の見えないコスト最適化の幻想を追い続ける限り、マトリクス組織にこれ以上を期待するのは難しいでしょう。品質問題、手戻り、遅延を考えると、職能別組織は、思いつくままに再編した場合よりもコストがかかる可能性さえあります。さらに、品質保証やIT運用などの重要な機能を遠隔地に外部委託しているなら、事業継続に欠かせない要求を満たし、安全にソフトウェアを届けるだけで、IT組織は手いっぱいのはずです。

この大きな問題にDevOpsはどう対処するか。製品・サービス別チームを作ります。

DevOpsでは、この問題を解決するために、職能別チームによる見かけ上のコスト最適化から、実証されたデリバリー速度の改善へと軸足を移します。正しく実践すれば、チームで速く継続的に届けながら、コストも削減できます。

DevOpsが勧めるのは、製品・サービス別チームです。独立し、職能横断的で、自律的に自己完結できる、通常は小規模なチームです。一時的なプロジェクトではなく、特定の製品やサービスを対象に、アーキテクチャの策定、設計、コーディング、テスト、実験、デプロイ、運用、保守まで、ソフトウェアエンジニアリングのライフサイクル全体を担えます。ソフトウェアの開発者以上に、運用と保守をうまく行える人がいるでしょうか。AmazonやNetflixの特に成功しているDevOpsチームが、リリース後も製品やサービスを手放さず、自分たちの本番システムで運用と保守も担うのは自然なことです。

資金を配分する対象を、一時的なプロジェクトから製品とサービスへ移す

事業の成果を伸ばすために、長期的な事業成果を具体的に評価するのが難しい一時的なプロジェクトには、もう資金を配分しません。DevOpsでは、組織のミッションと目的、そしてそれに沿った製品やサービスに資金を配分します。チームの成功は、ITと事業の成果によって評価します。社内外の顧客に製品、サービス、マイクロサービスを提供する事業領域で、どれだけの投資収益率を上げたかが基準です。チームは事業成果にほとんど関心を持たない縦割り部門の一員という立場から、自ら作って提供する製品やサービスの責任者へと変わります。

DevOpsチームとソフトウェアアーキテクチャをどう作るか

DevOpsは、組織で進行中の全プロジェクトを一度に解体して再編することを勧めているわけではありません。混乱を起こさずに効果を得る方法は、職能別の専門家にプロジェクトチームへ加わってもらうことです。品質保証、情報セキュリティ、データベース、ネットワーク、サーバー、運用など、必要な領域の専門家が加われば、チームが独立し、ソフトウェア製品やサービスを自力で設計、デプロイ、保守できるようになります。

新しい製品・サービス別のDevOpsチームでは、可用性、品質、性能、情報セキュリティ、コンプライアンスが全員の日常業務です。設計と開発を終えるまで非機能要件を意識しなければ、顧客が求める負荷やストレスに耐えられる、可用性が高く安全で高品質なアプリケーションを作れるでしょうか。ソフトウェアエンジニアリングのどの工程にも関与していない外部の専門家が、セキュリティや品質をどれほど正しく評価、検証できるでしょうか。高い成果を上げるDevOpsチームは、外部の専門家には助言を求めつつ、ライフサイクルの全段階で、すべての非機能要件に責任を持ちます。

もう一つの選択肢

とりわけ成功しているDevOps組織でありながら、製品・サービス別のDevOpsチームと職能別チームを広く併用しているのがGoogleです。Googleでは、両方のチームが、製品やサービスを通じて組織のミッションを果たすことを共通の目標と考えます。職能別チームは、テンプレート、チェックリスト、アプリケーションのひな型などの設計資産や、サーバーとネットワークを自力でプロビジョニング、設定できるセルフサービスの仕組みを作り、製品・サービス別チームを遅らせるボトルネックにならないようにします。また、ソフトウェアエンジニアリングの初期段階から製品・サービス別チームと連携し、設計、コード、テストを建設的にピアレビューし、継続して助言します。

DevOpsチームは何人が適切か

DevOpsチームの理想的な規模は5～10人です。この人数に抑えることで、チーム内の意思疎通や認識合わせの複雑さが減ります。チームリーダーとメンバーが、雑務や管理負担に多くの時間を費やすこともありません。チームが担当する製品やサービスの規模も一定に収まり、アプリケーションの複雑さや、保守と運用の難しさも抑えられます。小規模なチームでは、メンバー全員が全体像を理解し、組織の重要な使命を担う中で、一人ひとりが少しずつリーダーシップを経験できます。チームリーダーは経営上層部と連携して目標を理解し、メンバーにわかる形で伝えます。

10人以下のチームでは製品やサービスを担いきれなくなったら

新しい製品やサービスとして切り出し、別のDevOpsチームを作って引き継ぎます。製品やサービスは、料金を支払う社外顧客への提供物だけではありません。社内顧客のための製品、サービス、いわゆる「マイクロサービスAPI」と、それぞれのDevOpsチームも自由に作れます。たとえば、請求システムが10人以下のチームで扱えない規模になったら、データベースアクセスAPIを引き継ぐ別のDevOpsチームを作ります。オンライン決済APIやバッチ処理のチームを、さらに分ける場合もあります。継続的インテグレーションと迅速なデリバリーを実現し、組織として成果を出すため、全チームは共通のコードリポジトリとデプロイメントパイプラインを使います。

密結合のアーキテクチャでは、一つのアプリケーションへの小さな変更が、多数の業務の流れに悪影響を及ぼす場合があります。そのため、製品、サービス、マイクロサービスAPIは疎結合にします。各DevOpsチームが責任を負うのは、疎結合なアーキテクチャの一部分だけです。それぞれが独立してソフトウェアを設計、開発、デプロイできます。デプロイメントパイプラインには、コードのチェックインが悪影響を及ぼす可能性を、自動ですばやくチームに知らせる早期警告の仕組みを組み込みます。

最大10人のチームは、アーキテクチャから運用までの全工程をどう自力で担うか

チームの全員にジェネラリストを目指すよう促し、新たなスキルを継続的に身につけられるよう支えます。

現時点での知識や経験の水準にかかわらず、学習と成長に意欲のある人だけを採用します。固定された役割と責任の範囲内で評価されることを望む人は、採用を避けます。組織も、製品もサービスも、変わらないままではいられません。

今日変わらなくても、明日には需要が変わります。

まとめ

この章では、マトリクス組織と、それに伴う職能別の縦割り構造が期待どおりの成果を出せない理由と、DevOpsでの対処方法を説明しました。

DevOpsでは、製品、サービス、マイクロサービスAPIごとに、最大10人の小規模なチームを作ることを勧めます。

こうしたDevOpsチームは、設計から保守まで、ソフトウェアエンジニアリングのライフサイクルの全段階を自力で担える、ジェネラリストのフルスタックソフトウェアエンジニアで構成します。

DevOpsは疎結合のサービス指向アーキテクチャ（SOA）に基づきます。各DevOpsチームが、そのアーキテクチャの一部分に責任を持ち、運用します。