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氏は，「⁠人が鍵」であると述べました。最初に全員が集まること，ミーティングを続けること，全員がチーム内の出来事を見られるようにすること，そして継続的な改善がアジャイル開発成功の秘訣であるとして，基調講演を締めくくりました。