チームサイズ＆アプリケーションの複雑さ

チームサイズ＆アプリケーションの複雑さ

　一般に、アジャイルでは数人程度で1チームを構成するというのが共通認識になっています。チームのサイズの決定は多くの要因に左右されますが、チームの役割と責任を持つアウトプットの量は重要な要因の1つです。これは突き詰めていくと、構築するシステムのコンポーネント構造へと行き着きます。言い換えれば、チーム感覚を維持できるような、独立性の高いコンポーネントアーキテクチャを意識することが重要です。

　また、評価プロジェクトならいざ知らず、実プロジェクトになるとアプリケーションの複雑さは格段に増していきます。ロジックそのものの複雑さだけでなく、ほかのシステムとの連携が求められたり、複数のプラットホーム（ハードウエア、ミドルウエア、ブラウザー等々）上で展開しなければならないなど、多くの要因が存在します。要求の抜けや漏れが生じたり、テスト項目の漏れやテスト作業そのものの負荷を増大させたりする直接の原因となります。

単なるアジャイル開発から“節度ある”アジャイル開発へ

　これまで、アジャイル開発をスケールアップするための留意点を見てきましたが、これらのポイントを見ると、技術論ばかりではないことにお気づきになるでしょう。アジャイルのメリットを損なわないように配慮しつつ、ビジネス面からの要求に応えられるよう、チームあるいは組織の運営をどう調整していくか、というのがキーとなります。

　これまでのアジャイル開発に関する議論の多くは、「反復の期間中に何をするか？」という開発者観点で語られていました。しかし昨今では、“エンタープライズ・アジャイル”と呼ばれるように、「より組織的に展開していくための要素」についての議論が始まっています。IBMでは、お客さまに“アジャイルの定義”を問われると、以下のように答えています。

------------------------
　必要にして適度なセレモニーのもとで、メンバー間のコラボレーションを重視して運営される反復型、インクリメンタル（進化型）のアプローチ。費用効果の高い、高品質のソフトウェアを頻繁に、かつタイムリーにリリースして、利害関係者のニーズの変化に応えることを目的とする
------------------------

　そして、それを実現するための原則として、次の6つを挙げています。

・コアとなる原則
- “適合し適正な”プロセス（“Fits just right” process）
- 継続的なテストと評価（Continuous testing and validation）
- 一貫したチームコラボレーション（Consistent team collaboration）
- 変化への迅速な対応（Rapid response to change）
- 開発過程にお客さまを組み入れる（Ongoing customer involvement）
- 稼働するソフトウエアを頻繁にリリースする（Frequent delivery of working software）

　IBMの製品開発チームも、ここ2、3年急速にアジャイル化が進んでいますが、当初は同じような課題に直面していました。しかし、急速にアジャイル化へとかじを切るきっかけの1つが、Eclipseプロジェクトでの成功体験であることは間違いありません。世界中に分散している開発者が会社の垣根を越えて1つのプラットホームを作り上げるというのは、ともすると“小規模向け”と語られてしまいがちのアジャイル開発のイメージを変えるものでしょう。そしてこのEclipseの開発モデルから生まれ出たプラクティス集が“Eclipse Way（図3）”です。

　次回では、実際にJazz.netの運営モデルを見ながら、Eclipse Wayのエッセンスを解説していきます。