2010年7月21日、秋葉原コンベンションホール（東京）にて技術評論社の主催によるイベント「Agile Conference Tokyo 2010」が開催されました。2009年から数えて今回が第2回目となります。

全セッションレポートの1本目は、ThoughtWorks社のJez Humble氏による基調講演、そして日本IBMの大澤 浩二氏によるセッション1の模様をお届けします。

基調講演「～Continuous Delivery（継続的デリバリー）～」

基調講演では、ThoughtWorks社のJez Humble氏がアジャイルソフトウェア開発宣言を企業が行うにあたり、その原則や進め方、問題点など、知っておくべき実践的な内容を紹介しました。

リリースの遅延は大きな機会損失

「Agile Conference Tokyo 2010」の開幕を飾ったのは、ThoughtWorks社のJez Humble氏による基調講演「～Continuous Delivery（継続的デリバリー⁠）⁠～」でした。Jez氏は中～大規模企業でソフトウェアをデリバリーする際の問題点として「恒常的な機能障害」を挙げ、世界的なISPを例に説明しました。この企業は4ヵ月ごとにソフトウェアをリリースしており、デプロイに2日、リリースの際には週末丸々かけるような状態でした。しかも、デリバリーの際にはシステムを一度ダウンさせる必要があり、そうすると1時間あたり3万5千ドルもの損失が発生していたのです。また、国際的投資会社のケースでは、1ヵ月分の遅延は500万ドルの機会損失になるといいます。

そこでアジャイルソフトウェア開発宣言が生まれることになるのですが、第一の原則として「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する」ことが挙げられます。その解決方法は「アプリケーションの開発体制に対して、コード・インフラ・構成設定に対する変更がある度に毎回、素早く自動化されたフィードバックを行う」ことであるとJez氏は言います。つまり、サイクルを短くし、常にプロダクションレディであること、初期や中期、いつでも変更を行い細かくフィードバックし、管理者すべてが把握できることが重要であるとしています。

開発の進捗における価値付加の流れでは、例としてそれぞれのフェーズにおける価値付加時間を「プロダクトの機会評価」に3日、「⁠プロダクト探索」に1週間、「⁠計画と見積もり」に10日間、「⁠開発」に7週間、「⁠最終テストと承認」に1週間、そしてリリースを迎えるという流れになります。ここで重要なことは、創りたいものを具体的にするということです。また、リリースまでの手順においては、段階的な開発、アイデア、継続的なユニークテストが重要ですが、これだけでは不十分。価値を提供しなければなりません。そのためには受け入れテストの自動化などによるアプリケーションレディの状態を保つことが鍵になります。

テストとリリースを何回も繰り返すことで苦痛を先取りする

Jez氏は、アジャイル開発の原則として「ソフトウェアリリースまでの、繰り返し可能な信頼できるプロセスを確立する」「⁠ほとんどすべてを自動化する」「⁠すべてを構成管理下に置く」「⁠苦痛があるなら、より頻繁にそれを行い、苦痛を先取りする」「⁠品質を確立する」「⁠リリースされた手段で実施する」「⁠チーム全員がデリバリーに責任を負う」「⁠継続的改善」を挙げました。特にバージョン管理と共通認識が重要とし、さらに苦痛の先取りではテストとリリースを何回も繰り返すことが大事であるとしました。ハイクオリティを維持するためには、前段階でのテストが欠かせないのです。

また、常に自問自答が必要なこととして、「⁠あなたの組織は、たった1行のコードの変更を配置するのに、どのくらい時間がかかりますか？」「⁠あなたはそれを繰り返し可能で信頼できる基盤の上で実施していますか？」また、「⁠ソフトウェアが『ドアの外へ出る』のを邪魔しているものは何ですか？」という文献（リーンソフトウェア開発）からの引用を紹介しました。

実践においては、「⁠一度にビルドするのはあなたのバイナリだけ」「⁠すべての環境で同じ方法でデプロイする」「⁠あなたのデプロイのスモークテストを実施する」「⁠あなた自身の環境を類似のもので維持し続ける」「⁠もし何かが失敗したら、ラインを止める」ことが重要であるとしました。常にフィードバックすることで問題を早期に検出し、素早く対応することが重要なのです。

最も重要なことは「人」とそのコミュニケーション

テストにおいては、ビジネス面と技術面、実装のサポートやプロジェクト評価など、さまざまなテストが存在します。これらはすべてを自動化するのではなく、ターゲットを明確にして使い分けることが重要です。また、テストを繰り返し実施していくことで、不要なテストも明確になります。こうした継続的な改善を小さい部分からコツコツと行っていくことで徐々にリスクが減っていきます。リリースの頻度を上げるほど変更箇所が少なくなるため、定期的なリリースのリズムを把握しながら頻度を上げていくといいでしょう。

原則と実践においては、「⁠ロールバックするのではなく、再デプロイする」「⁠『⁠芸術作品』を破壊する」「⁠すべての変更が同じプロセスを経る」ことが重要であるとしました。その手段として「青・緑デプロイ」と「カナリアリリース」という2種類のテクニックも紹介しました。最後にJez氏は、「⁠人が鍵」であると述べました。最初に全員が集まること、ミーティングを続けること、全員がチーム内の出来事を見られるようにすること、そして継続的な改善がアジャイル開発成功の秘訣であるとして、基調講演を締めくくりました。

セッション1「アジャイルなソフトウェアライフサイクルを加速するALMソリューション」

日本IBMの大澤氏によるセッションでは、アジャイル型開発を実践したくてもできないという状況の悩みを4つ症状に分けて紹介するとともに、これらを解決する仕組み「CALM」について説明しました。

アジャイル型開発導入への「超えられない壁」

日本アイ・ビー・エム（株⁠）⁠ ソフトウェア事業 ラショナル事業部のクライアント・テクニカル・プロフェッショナルズである大澤浩二氏は、セッション「アジャイルなソフトウェアライフサイクルを加速するALMソリューション」を行いました。このセッションは、地理的に分散した環境下での大規模受託型開発では、分散、大規模、受託型ならではの特性が原因でアジャイル・プラクティスを実践したくてもできないという状況を解決する仕組み「CALM（カルム⁠）⁠」を紹介するものです。

パッケージソフトウェア開発に最適なアジャイルですが、受託型開発（SI）に適用するには難易度が高くなっています。これは、受託型開発を取り巻く環境には大規模受託型開発が多いことや、ビジネス環境変化が加速していること、オフショア開発が中心になることなどの特徴があり、契約上の慣習やレビュープロセスの制約といった「超えられない壁」が存在します。この状況は、どの会社にも同様に存在するのではないでしょうか。これを解決するには、伝統的手法からの段階的な脱却が必要になります。そのひとつが「部分的なプラクティスの採用」であると大澤氏は言います。

ウォーターフォール型開発とアジャイル型開発では、成功の測定、マネジメント文化、要求と設計、コーディングと実装、テストと品質保証、計画とスケジューリングといった、すべてのプロセスにおいて大きな違いがあります。このためウォーターフォール型開発からアジャイル型開発へ移行するには、激しいパラダイムシフトが要求されます。そこで、オフショアの時空を超えて開発ライフサイクル全体の活動におけるシームレスなコラボレーションを実現する管理手法が必要になります。それが「コラボラティブ・アプリケーション・ライフサイクル管理（CALM：Collaborative Application Lifecycle Management）なのです。

コラボレーションにおける悩みを「CALM」で解決

CALMでは、「⁠合意形成の加速」「⁠地理・時間の壁を越えたリアルタイムコラボレーション」「⁠プロセスエンアクトメント」「⁠リアルタイムレポート」によってコラボレーションにおける悩みを解決すると大澤氏は言います。そして、その悩みを4つの症状に分けて紹介しました。その4つは「要求確定に手間がかかる」「⁠作業状況が見えにくい」「⁠受身型の開発スタイル」「⁠報告までの時間がかかる」という症状です。

ユーザとベンダ間における「合意形成の加速」では、1週間に一度の要件検討会議からリアルタイムに要件定義の状況を利害関係者が共有するという、コラボラティブな要件定義空間の提供があります。メールベースのやり取りでは情報が行き渡らないケースがあるため、ソフトウェア上にディスカッションの場を設けるわけです。また「ビジネスプロセス」「⁠用語集」「⁠ストーリーボード」「⁠ユースケース」「⁠画面スケッチ」「⁠リッチテキスト」と多様な表現形式を用意することで、ひとつひとつの事柄について関連性をもって情報共有できる環境を提供します。

さらに、「⁠ダッシュボード」によって要件定義の進行状況の見える化を実現します。ダッシュボードでは、最近の成果物の種類の表示や、更新された成果物の一覧を本日分、昨日分など時系列で確認できるほか、最近のコメントなどもひとつの画面上で確認できるようになっています。これにより合意形成を加速し、症状のひとつ「要求確定に手間がかかる」という悩みを解決します。

ベンダとオフショア間における「作業状況が見えにくい」という症状には「地理・時間の壁を越えたリアルタイムコラボレーション」が重要であるとして、バーチャル・タスクボード管理を紹介しました。これは、ネットワークを介したホワイトボードのようなものですが、たとえば「セカンドライフ」上でタスクボードを共有し、リアルタイムにコミュニケーションを行うというユニークなものです。

次に、ベンダとオフショア間における「受身型の開発スタイル」の解決策として、大澤氏は「プロセスエンアクトメント」を紹介しました。これは、コンパイルエラーやコーディングのルール違反などといったコーディングやルールの変更をツール側に設定するという手法です。ツールがオペレーションをガイドするため、「⁠没有（メイヨー：ありませんという意味の中国語」と言われることがなくなります。

最後に、ユーザとベンダ間における「報告までの時間がかかる」という症状には「リアルタイムレポート」が有効であるとしました。時間のかかる原因の大半はWBS管理にあるため、これにアジャイルプランニングを融合、電子的に項目を紐づけてリアルタイムのレポートを表示します。これにより、スケジュールの達成率や実際のスケジュールの遅延などを把握でき、リカバーできるかどうかは「健康状態」として赤、黄、緑の色で表示するため、ドリルダウンにより分析した上で必要な対策を講じることができます。

CALMを実装する日本IBMのソリューション

大澤氏は、これらすべての解決策を実装したソリューション「Rational Workbench for Collaborative Lifecycle Management」を最後に紹介しました。本ソリューションは、分析者向けの「DOORS Requirements Professional⁠」⁠、開発者向けの「Rational Team Concert⁠」⁠、テスト担当者向けの「Rational Quality Manager」で構成されており、Jazzプラットフォーム上で連係動作、「⁠合意形成の加速」「⁠地理・時間の壁を越えたリアルタイムコラボレーション」「⁠プロセスエンアクトメント」「⁠リアルタイムレポート」を実現するとして、セッションを締めくくりました。