アジャイル DevOps: サイロを解体する

DevOps の成功に機能横断型チームがいかに不可欠であるかを学ぶ

DevOps を採用するチームでは、ツールを効果的に使用することが不可欠ですが、最大の効率とイノベーションを実現するには、古いスタイルのソフトウェア開発における従来型組織のサイロを解体することが重要です。連載「アジャイル DevOps」の今回の記事では、コミュニケーションを阻害するサイロのスタイルを採用するのではなく、コラボレーションを行う機能横断型チームのスタイルを採用する方向へ、組織を移行させる方法を著者の Paul Duvall が説明します。

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall は、Stelligent の CTO です。数々の主要なソフトウェア・カンファレンスでメインの講演者を務めている彼は、ソフトウェア・プロジェクトの開発者、プロジェクト・マネージャー、アーキテクト、およびテスターと、実質上すべての役割を担当した経験を持ちます。彼が中心的な著者となった共著書『継続的インテグレーション入門 開発プロセスを自動化する 47 の作法』(Addison-Wesley、2007年) は、2008年度の Jolt Award を受賞しました。また、『Startup@Cloud』、『DevOps in the Cloud LiveLessons』(Pearson Education、2012年6月) の著者でもあります。その他の本にも貢献し、developerWorks では 20 の記事からなる連載「万人のためのオートメーション」を書いています。彼は、継続的デリバリーとクラウドを利用して、高品質のソフトウェアをより短時間に、より頻繁に提供することに熱意を持っています。Stelligent.com で彼のブログを読んでください。



2013年 5月 30日

この連載について

開発部門は、運用部門から多くのことを学べます。同じく運用部門も開発部門から多くのことを学べます。この連載では、運用部門の考え方と開発部門の考え方を相互に適用し、ソフトウェア製品をこれまでよりも迅速かつ頻繁に提供可能な総体的要素として捉える場合の実用性を探ることに話題を絞ります。

私は、ソフトウェア製品やソフトウェア・システムを作る企業で働く人々から、「組織を実際に変えることなく、組織を変えるにはどうすればよいのでしょう?」という質問を頻繁に受けます。もちろん、この言葉通りに質問されるわけではありません (少なくとも、いつもこの言葉が使われるわけではありません) が、質問の意味はこの言葉の通りです。彼らはソフトウェアをリリースする上での手間やリスクを最小限にしたいと望んでいますが、そのためには彼らの権限や影響力が必ずしも及ぶわけではない組織も含め、組織全体にわたって変更 (文化面での変更と技術面での変更) を行う必要があるということを認識しているのです。

彼らが直面することの多い文化面での障害は、従来の開発チームや運用チームはサイロの中で作業する傾向があり、ソフトウェアのリリース時までチーム間のコミュニケーションが限られていることです (しかも多くの場合、そうしたコミュニケーションはイシュー・トラッキング・システムにおける一連のチケットに限られています)。成長を続けるソフトウェア企業は、よりコラボレーティブになる必要があり、そうしない限り、それらの企業は消滅することになります。ソフトウェア産業は (一部の人々の予想をはるかに上回る速さで) こうした方向に変わりつつあり、それはコンピューティング・リソースがより少なくて済むクラウド・コンピューティングと、ビジネスの要求の結果によるものです。進化しない企業は、進化する企業によってビジネスから追いやられることになります。

この連載導入記事で強調したように、組織の境界をまたいでのコラボレーションは、アジャイル DevOps の重要なポイントの 1 つです。今回の記事では、機能横断型チームを設立すること、そしてデリバリー・チームのメンバーのスキル・セットを拡大することが、コラボレーションを増加させて、ソフトウェアの継続的デリバリーを妨げていた従来の障壁を壊す手段になることを説明します。

機能横断型チームの登場

機能横断型チームは、ソフトウェア・デリバリー・サイクル全体にわたるエキスパート、つまり運用エンジニア、データベース管理者 (DBA)、テスター、開発者、アナリストなどで構成されます。機能横断型チームのメンバーは全員、バージョン管理リポジトリーにコードを格納します。例えば、運用エンジニアはインフラストラクチャーや構成をコードとして格納し、DBAは DDL (Data Definition Language)、DML (Data Modeling Language)、データセットをコードとして格納し、アナリストは要件をコードとして格納し、開発者はアプリケーションのコードと構成を格納し、テスターはテストをコードとして格納します。

スペシャリストの役割

マトリクス化されたサービス・ベースの組織で作業することに慣れているメンバーからなる新しい機能横断型チームの場合、機能横断型チームでの作業に慣れるまで少し時間がかかる可能性があります。チームの各メンバーのスキル・セットは狭い分野に限られたスキルである場合が多く、スキル・セットを広げる必要があります。こうした状況では、初期パイロット・プロジェクトの時点で組織のスペシャリスト (例えば、セキュリティーのスペシャリストなど) を招き、機能横断型チームのメンバーに対してアドバイスをしてもらう必要があるかもしれません。アドバイザーは、機能横断型チームのメンバーではなく、テストやコードを提供するわけではありません。アドバイザーの目的は、機能横断型チームのメンバーのスキル・セットを拡大することです。メンバーのスキル・セットが拡大するにつれ、チームはあまりアドバイザーに頼らなくなるはずです。

機能横断型チームでは、すべてのメンバーがデリバリー・プロセスに責任を持ちます。チームのメンバーであれば、ソフトウェア・システムの任意の構成部分を変更することができます。これに対するアンチパターンは、サイロ化されたチームです。サイロ化されたチームでは、開発部門、テスト部門、運用部門がそれぞれに独自のスクリプトとプロセスを持ち、同じチームには属しません。

つまり機能横断型チームは、ソフトウェア・システムの開発とデリバリーに責任を持つすべての部門の個人で構成され、各部門を個別の集中化されたサービス組織として扱うのではなく、デリバリー・チームが主要な組織構成体となります。デリバリー・チームは、ソフトウェアを絶えず提供することに専念して協力し合いますが、そこにはチーム同士が組織をまたがってコミュニケーションをする際に付き物の時間面での障害はありません。それぞれのチームを、(少なくとも) ビジネス・アナリスト、顧客代表者、DBA、開発者、プロジェクト・マネージャー、そして QA (Quality-Assurance: 品質保証) およびリリース・エンジニアで構成することを検討してください。機能横断型チームにすることで、同じ場所にいるチーム間、あるいは別の場所にいるチーム間のコミュニケーションを阻害する、「これは私の仕事ではない」症候群とその他の壁がなくなります。

すべての人が、あらゆることをする

しばらく時間が経つと、スキル・セットを身に付けたエンジニアやアナリストは、多くの場合、より完全なエンジニアやアナリストとなり、ソフトウェア・デリバリー・プロセスの一工程のみならず、さらに多くの工程を行い始めるようになるはずです。例えば、プログラマーが DDL スクリプトや DML スクリプトを作成したり、あるいは顧客の要件に基づくすべての変更に対して自動テストが実行されるように、ビジネス・アナリストが (Cucumber などの) 受け入れテスト・スクリプト内で要件を定義したりするかもしれません。チームの各メンバーは、自分でテストの作成、スクリプトの作成、バージョン管理 (「アジャイル DevOps: あらゆるものをバージョン管理する」を参照) を行い、自分が行うすべてを継続的システム (「アジャイル DevOps: クラウド内でのソフトウェアの継続的デリバリー」を参照) の一部とする必要があることを認識しています。このことは、すべてのソース成果物 (アプリケーション・コード、構成、インフラストラクチャー、データ) について言えることです。チームのメンバーがより多くのスキルを持つようになり、サイロが解体されると、コミュニケーションが改善され、古いスタイルのソフトウェア組織が抱えるボトルネックはなくなります。

プロセス

完全なソフトウェア・システムを構成するのは、スクリプト (つまりプログラム) または自動テストのいずれかです。ソフトウェア・システムを構成するものは、すべてがバージョン管理されて、継続的デリバリー・パイプラインに組み込まれます。このように、メンバーが作成したものがバージョン管理リポジトリーにチェックインされると、ソフトウェア・システム全体 (環境、データベース、バージョン管理された構成を使用するソフトウェア・アプリケーション/サービスなど) が作成されます。システムのすべてのコンポーネントはバージョン管理され、例外はありません。機能横断型チームのメンバーは完全にそのプロジェクトの専任であり、他のプロジェクトに関係することはありません。こうした方法により、コミュニケーションが強化され、プロセスのボトルネックが軽減されます。


機能横断型チームはどのように機能するのか?

DevOps を採用する上で最も重要なことは、組織の文化を変えることです。組織の文化を変えない限り、重要なことは何も起こりません。このセクションでは、機能横断型チームに移行するための ― そしてそのチームを効果的に機能させるための ― 概略手法について説明します。

パイロット・プロジェクト

大規模な組織を一度に変えようとすると、その試みはほぼ確実に失敗します。望ましい手法は、ビジネス価値のあるものを比較的短い期間で (理想的には 90 日以内に) 本番環境へ提供する、小規模なパイロット・プロジェクトから始めることです。パイロット・プロジェクトは戦略的なものにするべきであり、めったに更新されず、最小限のビジネス価値しかもたらさないアプリケーションにするべきではありません。この新しいチームは機能横断型チームであり、すべてのメンバーがこのプロジェクトの専任となります (彼らは他のプロジェクトの作業は行いません)。ソフトウェア・システムの開発に必要なすべての役割 (運用エンジニア、アプリケーション開発者、DBA、テスター等々) が、この機能横断型チームの一部となります。

サービス指向アーキテクチャー

効果的なコミュニケーションが行われる小規模なチームで作業を行うには、一体型のアーキテクチャーを解体する必要があります。他の従属システムが数多く緊密に結合されたアーキテクチャーは、不安定であると同時に変更が極めて困難です。これは、大規模なシステムを構築しないようにするということを意味しているのではなく、大規模なシステムは、単純なプロトコルを介して通信する複数のサービスが疎結合されたものにするということを意味しています。

1 つのプロジェクトで成功を実証できると、さらにいくつかのプロジェクトに拡大することができます。これらの別プロジェクトには最初のパイロット・プロジェクトのチーム・メンバーが含まれ、彼らは自分達の知識を新しいプロジェクトのメンバーと共有し、各メンバーは新しいチームの専任となります。これらのプロジェクトが成功したら、すべての戦略的プロジェクトが新しいモデルの下で運用されるようになるまで、その後のパイロット・チームを 2 倍または 3 倍に拡大します。

集中化される役割

サービス・チームはすべて小規模 (10 人以下) で独立しているため、どの組織機能を集中化すればよいのか、わからないかもしれません。組織はどれもそれぞれに異なりますが、DevOps と継続的デリバリーの原則を採用したチームの場合、集中化される機能は、ソフトウェア・デリバリー・チーム内の他のメンバーが使用するプラットフォーム・サービスを開発する機能や、システムの監視 (アプリケーション、ネットワーク、セキュリティーなど) を実行する機能です。リリース・コーディネーターの役割、ガバナンス、管理なども集中化されるかもしれませんが、集中化されたチームは、機能横断型チームの待ち時間を増加するようなアクティビティーを行ってはなりません (言い換えれば、集中化されたチームが提供するサービスは完全にセルフサービスです)。多くの場合、これらの組織では (プログラマー、運用エンジニア、DBA、テスターなどで構成される) サービス・デリバリー・チームが (通常はチーム・メンバー間の持ち回りで) 待機しており、本番環境での問題に対応して修正を行います。

セルフサービス・システム

自分で作成し、自分で実行する

自動化された変更のみがソフトウェア・デリバリーを実行するようにソフトウェア・デリバリー・システムを構築すると、(8 人から 10 人以下のメンバーで構成される) チームの誰もが本番環境に (または他の任意の環境に) 変更をデプロイすることができます。開発者 (インフラストラクチャー・コード、アプリケーション・コード、アナリスト・スクリプト、その他あらゆるものの開発者) にとっての最終的な顧客は、従来の運用チームではなく、実際のユーザーであるため、非常に高速なフィードバック・ループが形成されます。

DevOps の主な特徴の 1 つは、機能横断型チームのメンバーは、デリバリー・プロセスのアクティビティーを実行するために、決してそのチーム外のメンバーを必要としてはならないということです。すべてがセルフサービスでなければなりません。チームの全メンバーが本番環境へソフトウェアをデリバリーできる必要があります (囲み記事「自分で作成し、自分で実行する」を参照)。チームのメンバーがソフトウェア・デリバリー・システムの機能を設計する場合、チケット送信、e-メール送信、または他のコミュニケーション手段を使用するのに伴うデリバリー・パイプラインの待ち時間を生じることなく、その機能を使用できるように開発する方法を検討する必要があります。(これらのコミュニケーション手段は DevOps と継続的デリバリーを採用するチームでも相変わらず使用されている場合がよくあります。しかしデリバリー・パイプラインのコンテキストでは、これらの手段は自動化されています。)

パターン

すべての内部サービスをセルフサービス・モデルに移行することが大原則であるため、この連載のこれまでの記事で何らかの形で取り上げた特定のパターンが適用されます。そうしたパターンのうち、最も重要なものを表 1 に記載します。

表 1. DevOps による作業をサポートする重要なパターン
パターン説明
大きくて見やすいダッシュボード組織横断型チームが、ビルド・ステータス、顧客メトリクス、可用性など、ソフトウェア・システムの状態に関するリアルタイムの情報を得ることができます。
コロケーションコミュニケーションを強化するために、物理的に近い場所に複数のチームが存在します。
継続的統合変更のたびに、ソフトウェア (環境、アプリケーションなど) をビルドします。
機能横断型チームソフトウェア・デリバリー・チームは、プログラマー、テスター、アナリスト、運用エンジニアなど、さまざまな部門のエキスパートで構成されています。
多くのスキルを持つエキスパート機能横断型チームのスキル・セットを拡大することにより、スペシャリストのサイロを削減します。
スクリプト化されたデプロイメント環境へのソフトウェアのデプロイメントは完全にスクリプト化されており、1 つのコマンドでデプロイメントを実行することができます。
スクリプト化された環境環境の作成は完全にスクリプト化されており、1 つのコマンドで環境作成を実行することができます。
セルフサービス・リリース (自分で作成し、自分で実行する)チームで権限を持つ誰もが本番環境へのデプロイメントを実行可能であり、実際にデプロイメントを行います。
ラインの停止必要な場合には、誰もが継続的インテグレーション・システムを停止することができ、また停止する必要があります。
すべてがテスト駆動アプリケーション、インフラストラクチャー、その他すべてに対して自動テストを作成します。作成される可能性があるテストには、ユニット・テスト、受け入れテスト、負荷テスト、パフォーマンス・テストなどがあります。
すべてをバージョン管理インフラストラクチャー、構成、アプリケーション・コード、データなど、すべての成果物をバージョン管理します。

古いスタイルのソフトウェア開発の終焉

参加してください

developerWorks の Agile transformation ゾーンでは、皆さん個人、あるいは皆さんの組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

この記事では、DevOps を効果的なものにする上で重要なことの 1 つが、サイロを解体して、本番環境へソフトウェアをデプロイできる機能横断型チームを作成することであることを説明しました。調達およびデリバリーのサイクルが長い組織は、進化するか、ビジネスから排除されるかのいずれかです。大規模な組織では、進化に時間がかかり、また進化のためには組織の文化を変える必要があります。

この連載の最後の記事では DevOps ダッシュボードの作成方法について学びます。ダッシュボードを作成することで、開発チームや運用チームはソフトウェア・システムの状態を包括的に表示し、リアルタイムで監視することができます。

参考文献

学ぶために

  • How Netflix gets out of the way of innovation」(Adrian Cockcroft のブログ、2011年12月): Cockcroft が、Netflix の文化がどのようにイノベーションに影響を与えているかを語っています。
  • There's No Such Thing as a 'Devops Team」(Jez Humble 著、continuousdelivery.com、2012年10月): Humble 氏が、なぜ機能ごとのサイロや職務の隔離が問題を起こしがちなのかを説明しています。
  • アンドン: アンドン・コードがどのようにリーン生産方式に使用されているかを学んでください。ソフトウェア・チームは「ラインの停止」と同じ考え方を適用することができます。
  • Continuous Delivery: Patterns and Antipatterns in the Software Lifecycle」(Paul Duvall 著、DZone、2011年6月): 継続的デリバリーに関する 40 を超えるパターンとアンチパターンについて学んでください。
  • Amazon's CTO: 'Amazon is a technology company. We just happen to do retail」: (Brad McCarty 著、The Next Web、2011年6月): この記事に埋め込まれたプレゼンテーション・ビデオの中で、Amazon の CTO である Werner Vogels 氏は、彼の会社が「自分で作成し、自分で実行する」方式をソフトウェア・システムに採用していることを説明しています。
  • さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks のテクニカル・イベントで最新情報を入手してください。
  • 無料の developerWorks Live! briefing に参加して、IBM の製品およびツールについての情報や IT 業界の動向についての情報を迅速に把握してください。
  • Twitter で developerWorks をフォローしてください。
  • developerWorks のオンデマンドのデモで、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。

製品や技術を入手するために

  • IBM 製品の評価をご自分に最適な方法で行ってください。評価の方法としては、製品の評価版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。
  • developerWorks の Agile Transformation コミュニティーでは、コミュニティーに参加している個人あるいは組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, Open source
ArticleID=931691
ArticleTitle=アジャイル DevOps: サイロを解体する
publish-date=05302013