本文へジャンプ

ソフトウェア > Rational > Rational Developer Domain > Rationalソリューション >

大規模組織のためのアジャイルな構成管理

 
Rational software
レベル: 初級者向け
発表日:2006年8月
著者 : Peter Schuh
   
概要1〜910〜1415〜22

要旨

「高品質な製品を市場に送り出すために、より迅速かつ優れた方法を発見しようとすることは、有意義な目標である」という意見に異論を唱える開発マネージャーはいないでしょう。スピードと効率を求めて、多くのプロジェクト・チームがアジャイルなプラクティスや手法を効果的に採用しています。なぜならば、障害の少ない高品質なソフトウェアを小規模の頻繁なリリースで提供することに重点を置いて、開発というものを捉えているからです。

私の経験では、大規模企業よりも小企業のほうが、アジャイルなアプローチを積極的に受け入れています。これはおそらく、大規模企業のほうが変化への対応が遅れがちで、抵抗も大きいからですが、大規模企業には「アジャイルはリスクが高い」という認識があることも理由の1つです。これはつまり、分散したチームが大規模かつ複雑なプロジェクトを実施する場合にはアジャイル開発は不十分な品質管理の上に成り立っているという認識です。

しかし、実際はその逆です。大規模企業は、大規模かつ複雑であるからこそアジャイル開発の原則を採用する必要があるのです。現在の体制が変わらなければ、膨大な開発作業の進捗は遅くなり、サイロ化(孤立化)が生じます。ツール・セット、チーム、報告体制が分断されているために、障害の発生頻度が高くなり、チームが広い地域に分散しているために、コミュニケーションや調整が困難で時間のかかるものになります。これは事実上、「右手のしていることを左手は知らない」という状態です。こうした課題を考えれば、大規模な開発チームは、自動化、柔軟性、統合、接続への取り組みを可能にする構成管理の基盤を確立するべく、意識的に努力しなければなりません。

アジャイルな構成管理の基盤となる重要要素としては、堅固なソース管理システム、反復可能で自動化されたビルド・システム、テスト自動化フレームワーク、信頼性の高いデプロイメント・アプローチなどがあります。最も重要なのは、開発サイクル全体を通してプロジェクトをシームレスかつ迅速に進行できるように、これらのコンポーネントをすべて統合することです。さらに、誤ったコミュニケーション(誤った情報伝達)や引き継ぎの不備がプロジェクトの遅延を招くことのないように、複数のチーム間で情報を共有する必要があります。

アジャイルなプロセスが大規模企業にもたらす大きなメリットは、多くのデータによって、ますます実証されています。逆に、大規模企業はアジャイル手法の採用にもっと慎重になるべきだと主張する人はほとんどいません。分散した複雑かつ大規模な開発環境でアジャイル手法の採用を成功させるには、システムの自動化が不可欠です。アジャイルな施策の基盤として機能するシステムを決定する際には、アジャイルな施策を長期にわたって確実に成功させるために、全体的なアーキテクチャーが、柔軟性、スケーラビリティー、セキュリティー、自己文書化を促進するものであることに注意を払う必要があります。

分散環境の統合、スケーラビリティー、追跡可能性、セキュリティーなどの問題に取り組む必要のある大規模企業は、独自のシステムを構築・管理するよりも、アジャイルな構成管理アプローチの実装を支援する市販製品の使用を検討するほうが経済的でチーム効率も高いと判断するでしょう。そうした製品の1つであるIBM Rational Build Forgeを使用すれば、大規模な開発組織でアジャイルなアプローチを迅速に実現することができます。Build Forgeでは、開発環境が世界中に分散している場合であっても、ビルド/リリースの自動化と一貫した実行を実現できるフレームワークが確立されます。また、コーディング、ビルド、テスト、デプロイの各機能を統合することによって、プロジェクトが次のグループへスムーズに流れるようにし、開発サイクル全体の情報を取り込むことによって、管理者が十分な情報に基づいて意思決定できるよう支援します。さらに、ビルドの実行、結果の表示、エラーの診断などを各チーム・メンバーが独自に行えるように、セルフサービス機能を提供して、プロセスのボトルネックを解消します。Build Forgeソリューションは、最も大規模かつ複雑な複数の開発環境において妥当性が確認されており、生産性と品質の大幅な向上を実現しています。

上に戻る

インデックス
  1.はじめに:大規模な開発組織でアジャイルなプラクティスを採用する場合
  2.始める前に:用語の確認
  3.大規模企業におけるアジャイル・プラクティスの必要性
  4.アジャイルな構成管理プラクティス
  5.ソース管理
  6.ビルドの自動化
  7.移行およびデプロイメントの自動化
  8.テストの自動化
  9.継続的インテグレーション
  10.アジャイルな構成管理を大規模システムに拡張
  11.効果的なチーム調整:コード・ベースの共有とビルドの連鎖
  12.分散したチームや組織のサポート
  13.ツールとプロセスを柔軟に統合し、スケーラビリティーを実現
  14.検討するべきソリューション:IBM Rational Build Forge
  15.一貫性のあるビルド/リリース・プロセス管理
  16.エンド・ツー・エンドのライフ・サイクル・サポート
  17.スケーラブルなビルド/リリース・オペレーション
  18.自己文書化システムによる追跡可能性
  19.セルフサービスによるチームの生産性の向上
  20.プロセスへの安全なアクセス
  21.一部の業種における成果
  22.まとめ

上に戻る

執筆者について

Peter Schuhは「Integrating Agile Development in the Real World」の著者であり、便利で有効なソフトウェアをタイムリーにビルドして配布することを最重要視している、ソフトウェア開発分野のすべての人々に、有用な指針を提供しています。彼はソフトウェア開発プロジェクト・チームにおいて、プロジェクト・マネージャー、アカウント・マネージャー、コーチ、プログラマー、DBA、ビジネス・アナリスト、テクニカル・ライター、など、ほぼすべての立場・役割を経験しています。また、金融、リース、医療、e-コマースなどの業種において、ITプロジェクトの管理とコーチを行った経験も持っています。ソフトウェア開発というデジタル・ワールドでプロジェクト・チームと仕事をしているとき以外は、シカゴの小さなアパートメント・ビルの修理・管理に従事し、建築とビル管理という現実の世界で顧客としての役割も担っています。

Peter Schuh : agile@peterschuh.com

上に戻る
 
 
 
レベルマークについて

このページで紹介されている情報はレベル別にカテゴライズされています。

上級者向け
中級者向け
初級者向け
入門者向け