Developers Summit 2010

Agility@Scaleを実現する14のベストプラクティス

2つ目のセッションは19日の午後、「Agility@Scaleを実現する14のベストプラクティス」と題して、玉川憲氏（日本アイ・ビー・エム株式会社ソフトウェア事業 IBMソフトウェアエバンジェリスト、Rational 事業部テクニカルセールス部長）が講演を行った。

ここで「Agility@Scale（アジリティ・アット・スケール）」とは、「アジャイル開発をスケールアップするための考え方」を意味している。アジャイルは、小規模であったり同一地点で開発される環境で利用する手法だというのが定説であった。しかし、アジャイル開発による生産性や品質の向上、顧客満足度の改善といったメリットは、大規模開発や分散開発の現場にとっても魅力である。

とくに昨今の厳しいビジネス状況下では、大企業やオフショア開発であってもアジャイル手法を導入するというような、思い切った変化が求められているといってもよいだろう。玉川氏は、IBM社内での実例を引きつつ、大きな分散した組織がアジャイル手法を導入する利点とそのためのプラクティスを語った。

玉川氏が挙げたIBM社内の事例は、Jazzプロジェクトによる「Rational Team Concert（RTC）」の開発。Jazzプロジェクトは、2005年より7か国以上、約120名体制で行われており、その最初の成果が「Rational Team Concert（RTC）」になる。開発チーム自身がRTCを用いて、ScrumやXPといったアジャイルプラクティスを利用し、Jazz系の製品を開発しているところに特徴がある。

玉川氏はまず、アジャイル開発には様々な考え方があるとしつつ、基本的なベストプラクティスには共通点があるとして、「反復＆インクリメンタル＆適応型の開発」「短いタイムボックス内で動くコード」「小さな一口単位で開発」の3つのポイントを挙げた。

また、従来のウォーターフォール型開発からの大きなパラダイムシフトとして、スコープ（要求）を固定しないで管理することを挙げた（図1）。従来の開発では、顧客からの要求が固定されており、それに合わせてリソースと期日が見積もられる。しかしアジャイル開発では、逆に小さな単位でリソースと期日が固定されており、それに合わせた要求が見積もられる構図になる。

そのようなアジャイル開発だが、もともと小規模開発において生まれた手法であるため、大規模開発に対してはプラクティスによって向き不向きがある。玉川氏は、大規模開発でのアジャイルプラクティスとして、規模に関係なく適用できるものを7つ、さらに大規模だからこそ必要なプラクティスを7つ挙げた。

規模に関係ないものが「定義・構築・テストのコンポーネント・チーム」「2レベル計画作りと追跡」「反復型開発」「頻繁な小規模リリース」「コンカレントテスティング」「継続的インテグレーション」「継続的な考察と適応」の7つ。

大規模だからこそ必要なプラクティスは、「意図的なアーキテクチャ」「リーン要求開発のスケールアップ：ビジョン、ロードマップ、ジャストインタイムの詳細化」「アジャイルリリーストレイン」「高度に分散した開発の管理」「顧客とオペレーションへのインパクトの調整」「組織を変化させる」「ビジネスパフォーマンスを計測する」の7つとなる。

「Agility@Scale」を実践している現場の声だけに、いずれも説得力のある内容だった。なお、今回のセッションでも最後に参考書籍が紹介された。玉川氏の監修による『アジャイル開発の本質とスケールアップ― 変化に強い大規模開発を成功させる14のベストプラクティス』（Dean Leffingwell 著、翔泳社、2010 年）で、デブサミの会場で先行販売された新刊である。

（続きのページ）

図1：スコープを、固定せずに管理する