Tweet

アジャイル開発の広範な普及を目指して

Manager of Methods, IBM Rational, IBM
Per Kroll

2008/5/8

前のページ｜1　2｜第73回

大規模組織におけるアジャイルへの移行

　10人が作業を進める方法であれば、スキルの高いアジャイルの指導者が適切な人材に対して事細かく情報を伝えればアジャイルへ移行できるが、数百人規模の組織を移行するには信頼性の高いインフラの存在も必要になる。対応の必要なこれらの問題をいくつか見ていこう。

■ 大規模なナレッジの伝達

　クロノスの600人規模の開発チームでアジャイルへの移行作業を行うことになったインダストリアル・ロジックは、一握りの指導者に頼るのではうまくいかないことに気付いた。そこで、XPに関する基本ナレッジの習得のため、このチームはWebベースのトレーニングコースを構築した。これによって、指導者はXPの実用化をチームに指導するという、より価値の高い活動に注力できるようになった。

　EPFとIBM Rational Method Composerはこのようなパラダイムをさらに一歩先へと進め、ナレッジを各種組織やチームが簡単に修正できるよう電子化した。これは、ナレッジの移転を大々的に増加させる一方で、個々のプロジェクトの事情に合わせてナレッジを修正できるようにする。われわれの経験から、大規模な導入には、Webベースのトレーニングであれ、プロセスガイドであれ、チュートリアルであれ、電子的な手段で伝えられるナレッジで従来の指導モデルを補完しなければならないことが証明されている。

■ 人事ポリシーの変更

　アジャイル開発は、社員へのインセンティブや報酬、昇進、責務といった従来からある人事関連にも影響を与える。必要な変更を行うには、早い段階から人事部や管理職の支援が必要だ。

　アジャイル開発には、お互いを仲間と認めるグループ内の密接なコラボレーションが必要とされ、それがチームのリーダーシップの力学を変えることもある。通常、大企業における昇進（開発者からアーキテクトへなど）は、コーディングというつまらない仕事から逃げるための手段だと見なされている。しかしこうした企業には、崇拝される権利を得た監督者としてではなく、チームのリーダー役として指導者の役割を演じる専門知識と豊かな経験を持つ人材が必要だ。

　コラボレーションに重点を置くと、報酬や人事の評価方法も変わってくる。個人の生産性だけを評価するのではなく、個人がチームに提供した価値も評価する必要がある。チームにとって最も価値の高いメンバーが、個人としての生産性は最も低い場合も多い。ほかのチームメンバーの指導に大半の時間を費やすためだ。

　これらの人事関連の概念はアジャイルの価値を反映しており、組織が報酬や人事評価の指針にする価値を明確にするのは極めて重要なことだ［注4］。アジャイル開発が主流になるためには、必要な人事関連の変更やその実現方法をもっと明確にする必要がある。

■ スケーラブルなツール環境の実現

　アジャイルの鍵を握る原則の1つが、ツールよりも個人とコラボレーションに重点を置くことだ。そのためか、アジャイルを教える多くの指導者はツールに反対の立場を取っている。しかし、ツールはコラボレーションを大幅に促進することができ、アジャイルを主流にするためには極めて重要だ。確かに、従来のツールの中にはアジャイル開発を促進せず、有意義なコラボレーションを抑制するものもある。しかし、有望なものも出始めている。ソフトウェア開発のコラボレーションの側面に重点を置く次世代ツールの開発が進んでいるのだ。

　バージョン・ワンとラリー・ソフトウェア・ディベロップメントは、アジャイルプロジェクト管理ツールを発売し、速度、反復プラン、規模・活動予測、そして2日以内に達成できる単位への作業の分割など、アジャイルの核となるコンセプトをサポートしている。IBMのRational部門は先ごろ、IBM Researchと協力し、既存のアジャイルプロジェクト管理ソリューションの枠を超えてアジャイル開発作業そのものもサポートし、チームコラボレーション、透過的な開発、継続的統合、そしてテスト主導開発といったアジャイルコンセプトを主要機能として加えた「Jazz」というコードネームの技術を先行公開した。

大規模／エンタープライズ規模の開発が抱える問題

　アジャイルが主流になるためには、大企業が直面する地域分散型開発、大規模開発、そしてコンプライアンスのサポートといった問題への対処が必要になる。既存のアジャイルソリューションは、これらの問題に対するソリューションを明確にしておらず、ここを変える必要がある。

■ 大規模チームと、さらに大規模な企業や組織

　多くのアジャイルプロセスは、十数人以下のスキルの高い開発者で構成された少人数のチームを明確なターゲットとしているが、規模の大きいチームを扱うには、より多くの経験と指導が必要になる。大規模チームのサポートは、XP、スクラム、OpenUP、RUP、そしてアジャイルモデリングなどのプロセスで開発が進んでいる。例えばIBMでは現在、OpenUPの拡張機能セットとして構築するためRUPのリファクタリングを進めている。これは、SOA、コンプライアンス管理、地域分散型開発、パッケージアプリケーション開発、アジャイルコアプロセスなどの分野の手本になっていくだろう。

■ 地域分散型開発

　大規模開発企業の大半では、地域分散型開発が死活問題となっている。しかし、対面でのコミュニケーションは、アジャイル開発の基本原則だ。組織では、共有する物理的なプロジェクトルームがなくても、修正されたプラクティス（異なるチーム間におけるより効率的な作業分担など）［注5］と、インフラのサポート改善を組み合わせることで、それを補うことができる。

　Jazzの技術はチームの意識を高め、誰がいて、何をしているのかがチームのメンバーに分かるようになる。インスタントメッセージングなどの各種技術を使えば、完了した作業に基づいたコラボレーションが可能になる。Jazzソースコードコントロールシステムを使えば、開発者が変更セットを簡単に交換できるようになり、ビルド認識機能を使えば、失敗したビルドに関する情報を即座に得られる。技術を活用して、メンバー同士が遠く離れていても結束力のあるチームを作り出すことが目標だ。

■ コンプライアンス

　コンプライアンスとは、「自らの行動を明らかにし、明らかにしたことを行動に移し、行動に移したことを示す」ことだ。これはアジャイル開発との整合性に欠けるわけではないが、克服すべき課題が幾つかある。

　第1に、アジャイルコミュニティはプロセスをドキュメント化するという固有の恐怖を克服する必要がある。アジャイルチームは、自分たちにとって確実に機能するようプロセスを継続的に進化させる必要があるが、プロセスをドキュメント化すると、変更が難しくなってしまう恐れがある。EPFとRUPは、内容の豊富なリファレンス手法ライブラリと、チームが決めた特定のプロジェクトの進め方を書いた簡潔な説明書を切り分けることでこの問題に対処している。プロセスガイドの詳細にわたる大規模な変更は必要ない。その代わり、チームが自分たちの短いプロセス説明書と、関連する説明資料へのポインタに変更を加えるのだ。EPFでは2007年、チームが持つプロセスの所有権を保証できるよう、新たにWiki技術を搭載してこれらの変更をさらに容易にしている。

　第2に、チームは「行動に移したことを示す」という非生産的な作業を回避する必要がある。IBM Rationalの経験からは、監査合格に必要な帳簿処理が自動化によって必要なくなるか、もしくは最低限の作業だけで可能になることが分かっている。

■ まとめ

　アジャイルには、ソフトウェアプロジェクトの成功率に非常に大きな影響を与えるポテンシャルがある。それを可能にするため、アジャイル開発は主流となるための多くの課題を克服しなくてはならないが、2007年には大きな進展が見込まれている。主力SIer／ベンダ各社がアジャイル開発に投資をし、EPFによって分散しているアジャイルプロセス市場では買収も考えられ、アジャイルへの移行は「一か八か」の戦略ではなく、次第に長旅のようなイメージとなっていくことが期待される。

　アジャイル開発専用のツールも登場し始める。コンプライアンス、大規模アジャイル開発のサポート、地域分散型開発関連ではまだかなりの作業が必要だが、これらの分野でも各種手法やアジャイル開発を主流にするためのサポートインフラが登場しつつある。全般的に見て、2007年はアジャイル開発が隔たりを超えて主力開発組織にまで浸透する年になることが大きく期待される。

前のページ｜1　2｜第73回

	Page1 安全策を探す主要企業 ■ 業界の主要ベンダーによるサポート ■ 散在するアジャイルプロセスの統一 ■ 進化か？ それとも革新か？
	Page2 大規模組織におけるアジャイルへの移行 ■ 大規模なナレッジの伝達 ■ 人事ポリシーの変更 ■ スケーラブルなツール環境の実現 大規模／エンタープライズ規模の開発が抱える問題 ■ 大規模チームと、さらに大規模な企業や組織 ■ 地域分散型開発 ■ コンプライアンス ■ まとめ

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）