Agile Consortium BelgiumとUNICOMは1月22日，ベルギーのブリュッセルで，Scaling Agile for the Enterprise 2015会議を共同開催する。
この会議では，絶対的な思想的リーダであるDean Leffingwell氏とMark Lines氏と実践家が協力して，共有すべきベストプラクティスを見出していきます。運用中のアジャイルメソッドに関与している，あるいは実例として調査している人たちにとって，自身の関わる組織をさらにアジャイル化する上で，またとない1日となることでしょう。
InfoQでは，このイベントをQ&Aやニュース記事，アーティクルの形で報告する予定だ。今月初めには，その最初の記事をいくつかお届けしている。
InfoQは，Agile Consortium International次期会長のArie van Bennekum氏と，Agile Consortium Belgium会長のJan de Baere氏にインタビューして，Agile Consortiumが主導する活動，アジャイルをスケールする上でソフトウェア産業が直面している問題，アジャイルのスケールに成功した企業のストーリなどを聞くことにした。
InfoQ: Agile Consortium Internationalを読者に紹介してください。コンソーシアムやその支部がどのような活動を行っているのか，説明をして頂けますか？
Arie: コンソーシアムの役割には２つのエリアがあります。ひとつはイノベーションと共有です。アジャイルの目的は，常にイノベーションにあります。Agile Consortiumはそれを推進する団体なのです。イノベーションには，それを進めるための継続的なループがある，と私たちは考えています。メンバは，作業部会に参加したり，(イベントなどを通じて)知識の共有をすることができます。新たなイノベーションを獲得できたならば，イノベーション共有の原則に従ってそれを公開します。公開が終われば，それに関連したイベントを開催します。これでひとつのサークルが閉じられたことになります。
ふたつめは認定です。コンソーシアムには “Certify-to-Inspire” プログラムがあります。私たちは，ただ一つの方法を信奉しているのではありません。自分の決めた仕事の進め方の基本となるものが，どのようなアジャイルメソッドであれ，そのメソッドの価値観と原則の範囲内にあるのならば，あなたはアジャイルであると言えるのです。私たちは何年か前に，このような認定の必要性に気付きました。ひとつのメソッドを使用するのは自由ですが，それが絶対的な教義になることはありません。
コンソーシアムではメンバ組織などを対象に，メソッドに依存しない，非営利の認定プロセスを推進しています。認定は，Foundationレベル(基本概念の価値観と原則の理解度を測る，多肢選択形式の試験)，Practitionerレベル(実施済みのプロジェクト概要，それに対して最適なアジャイル実施方法のデザインとその適用，そこから得られる改善，といったことを内容とする，１時間の口頭試問)，Masterレベル(実際に行われたアジャイル転換を題材に，受験者が個人，チーム，ないし組織のアジャイル化を行うに足る能力を備えていることを確認する，丸１日のアセスメント)の３レベルに基づいて行われます。
Agile Consortiumは組織のための組織で，企業，非営利団体，教育機関，フリーランサを対象としています。
コンソーシアムには，今回のスケーリングイベントのようなイベント開催の責任を負う委員会があります。イベントには国際イベント(コンソーシアム全体で主催する)と，オランダやベルギー，イタリアといった支部が主催するローカルイベントがあります。支部ごとに，年５ないし６回のイベントを行う予定です。
InfoQ: アジャイルのスケーリングに関するイベントを開催する理由は何でしょう。なぜこれが重要なのでしょうか？
Arie: コンソーシアムを運営しているのは，メンバ組織の人々です。彼らはそれぞれ，自分たちの希望を持ち寄ります。今回のテーマは，ベルギー支部を始めとするメンバからの要望によるものです。
Jan: スケーリングの必要性は，市場動向からも，あるいは個人的な体験からも感じられます。チームレベルでアジャイル原則の適用は，広く理解されるに至っています。問題なのは，複数のチームでもこれが可能か，という点です。どのように協調すればよいのか？計画を共同で行うにはどうすればよいのか？組織の他の部分 - デプロイメント対象以外 - をアジャイルにするには，どうすればよいのか？スケーリングフレームワークとその原則が切り込もうとしているのは，このような部分です。
カンファレンスのセットアップでは，主要なアジャイルスケーリングのフレームワークと原則の２つを，それぞれ交互に配置しています。それぞれに対して実際の例が挙げられて，なぜスケーリングが必要なのか，どのように行ったか，その結果はどうだったか，などを説明します。
InfoQ: 現時点において，アジャイルスケーリングに関する最大の問題点は何だと思いますか？ソフトウェア業界はそれを，どうやって扱おうとしているのでしょう？
Arie: 一番の大きな問題は，チームでの活動を，それよりも大きなスケールでマッピングすることです。ほとんどの組織は(さまざまな理由から)アジャイルではありませんが，アジャイルを実施しています。組織には遺産や歴史，文化といったものがありますから，これは理解できます。組織が本当にアジャイルになるためには，時間が必要なのです。彼らが選択したアジャイルメソッドに固執するのは，彼らが選択したことです。元々のメソッドのほとんどは，チームレベルしか扱えないものですから，これをより大きな環境への転換は困難を伴います。チームレベルでのステップの実施例は少なくありません。しかし，その次に何をするかは必ずしも明確ではないので，私たちはこれを解決しなければなりません。
InfoQ: アジャイルのスケールアップに苦慮している組織はたくさんあります。アジャイルのスケールに成功した企業の実例はありますか？その違いをもたらしたものは何だったのでしょう？
Arie: 成功例はあります。違うのは真のマインドセットと，そして垂直コミットメントです。さらに，現状を維持しようという，従来的な束縛の回避も必要になります。事態が困難になると，組織や従来型のマネジメントは往々にして，“これまで慣れ親しんだ古い方法に立ち戻る”という落とし穴にはまり込むことがあります。常に“期待したレベルにはまだ達していないのであって，もっとよくすることができる”というコンセプトでなければなりません。
InfoQ: あなたは「アジャイルソフトウェア開発宣言」の作者のひとりですが，宣言の書かれた2001年には，スケーリングに関する議論はあったのでしょうか？スケーリングの対処方法として，当時の考えを教えてください。
Arie: スノーバード(訳注：アジャイルソフトウェア開発宣言が書かれた場所)セッションでの議論では，そのような話をした記憶はありません。ですが，取り組みはその当時から，ずっと続いていると思います。私の関わるプロジェクトは，いつも複数の分野にまたがっています。全体の環境との統合が必要な，複数のチームやプロジェクトで構成されていることも少なくありません。“組織の変革”を意識する必要はありません。エンドユーザの規模や操作から，品質保証や監査証跡に至るまで，必要な変更のすべてに対応して，求められるソリューションを完全な形で提供することに注力してください。