Paul Gorans氏 (IBM Global Business Services) と Philippe Kruchten (ブリティッシュコロンビア大学) は A Guide to Critical Success Factors in Agile Delivery を出版した。このガイドでは、アジャイルの価値や利点、および、その課題について触れ、連邦政府におけるアジャイル・デリバリー遂行ための重要成功要因について提議している。
infoQ は、Paul Gorans氏にインタビューし、アジャイル・プラクティスの遂行においてアジャイルが取得と調達にもたらす影響、アジャイルにおけるコミュニケーションの拡大、そして、レビュー方法について伺った。
InfoQ: アジャイル・デリバリーについてのガイドを執筆することに決めたきっかけは何でしょうか。また、誰に向けて書かれたのでしょうか。
Paul: IBMにおける米国連邦政府関係機関とのアジャイルプログラムのうちの 1 つで、 私が IBM Global Business Services で連邦政府という公的機関にて実施したアジャイルへの移行支援の成功について、IBM Center for the Business of Government の耳に入ったことです。彼らは、アジャイルの基本や、私がアジャイル・デリバリーに必要と感じる重要成功要因について、他の機関も理解できるよう支援するガイドを執筆するとともに、我々が度々質問を受ける連邦政府特有のいくつかの側面（e.g. アジャイルでどのようにリハビリテーション法第 508 条のテストを実施するのか）について書くことを私に勧めました。
InfoQ: アジャイル・プラクティスを効果的に遂行するために組織に必要なものは何だとご自身は思われますか。
Paul: ビジネス/ミッションの観点での幹部社員からの援助と CIO のサポートです。 このような後押しが得られれば、ガイドの中の 10 項目にも含まれますが、アジャイルの成功に要求される全ての要因への対応能力を得ることができます。
InfoQ: ガイドによると、取得プロセスの変更は成功要因のうちの 1 つであるとのことですが、なぜアジャイル・デリバリーにとってそれが重要なのでしょうか。
Paul: 私はこれまで、営利企業と連邦政府の機関の両者において、従来型のフェーズゲート、または、提供された価値ではなく、最も低コストなベンダや実績を評価しつつも、「アジャイル」を要求する取得プロセスを見てきました。これは、期間について直前の出資者の依頼により提案書に書き込まれたものの全ての関係者がまだ同じ考えには至っていないかもしれないという状況を示唆しています。このような状況では、パートナ/ベンダ候補もクライアントの要求が何なのか把握しきれず、その解釈はまちまちになり、提案を評価するのを難しくしてしまいます。どのような取得プロセス(その手段がどうであれ)におても、調達の段階では取引で必要とされること(概してITを含むビジネス上の課題に対するソリューション)は何か、ゴール達成に向けた最善のリーディング・プラクティス、そして、成功を導くために関わった全ての関係者に要求されることは何かが明確化されているべきです。
InfoQ: ガイドでは、口頭でのコミュニケーションとダッシュボードのさらなる活用を勧めていますが、これらの活用は拡大可能なものなのでしょうか。より大きな組織における適用例を伺えますでしょうか。
Paul: はい。口頭でのコミュニケーションとダッシュボードの両者とも拡大可能です。多数のアジャイルチームで編成されるプロジェクトでは、プログラムに合ったコミュニケーションプランが作成されるべきです (私は度々アジャイルにおいて従来型のプロジェクトマネジメントのやり方は今でも有意義であるという考えを示しつつも、PM（または、スクラムマスタ）は、詳細レベルで記述や振舞いを見直す必要があると考えていることにご留意ください。)。口頭でのやり取りには、各アジャイルチーム毎の日々の立ちミーティング、および、その後のチームの垣根を越えたミーティング (e.g. スクラムオブスクラム)があります。その目的は、遅延要因についての認識を高めることと、全てのチームに影響がある遅延要因がある場合は、そのサポートを求めることです。
IBMのプロジェクトにおいては、我々のアジャイルプロジェクトが弊社のプロジェクト・エグゼクティブ (PE) やデリバリーのキーマネージャと直接連絡をとることができるよう、IBMのメンバのみで行う日々の立ちミーティング/状況確認を取り入れました。これは、PEが何が起きてもほとんど驚かないであろうことを保証するとともに、日常的に若手のプロジェクトマネージャと直接交流したり相談に乗る機会にもなります。また、若手にとっては、重役レベルのクライアントやパートナとコミュニケーションを取るための情報を得る機会になります。その他のフォローアップとして、メールや1ページ程度の状況報告もまた、これらの口頭のコミュニケーションの目的をサポートするのに有効でしょう。
ダッシュボードについては、一部のコミュニケーションにおいて wiki が有効ですが、今や数々のアジャイルのツールや、複数のアジャイルチームやプログラム、そして組織までカバーするツールセットも存在します。このようなツールを利用することで、開発者と幹部社員は、詳細、または、集約された同じ情報を掲載され次第参照することが可能になり、ストーリー、統計、遅延要因、バーンダウンチャートなどが、色々なチームや関係者が物理的にどこにいても、それぞれのPCから閲覧できるようになります。
徹底した見える化のためのツール化の拡大にあたっての制約の 1 つは、組織における多様な業務分野でそれぞれ取得やマネジメントのための従来業務のツール化(e.g. 要件定義、テスト、コンフィギュレーション管理、デプロイ)について責任を担っていることです。この件についても、ビジネスの垣根を越えて働きかけができるよう幹部社員からのサポートを必要とします。そして、徹底的な価値を提供するソリューションを定義するために、ITグループの支援も必要です。
InfoQ: ガイドでは、アジャイルでは異なる種類のレビューが求められると触れていますが、詳しくお話頂けますでしょうか。
Paul: レビューには、製品完成時の製品オーナーによるストーリーのレビュー、または、スプリントレビューでの様々な関係者によるストーリーのデモンストレーションが(動作している製品の)がありますが、アジャイルにおいては、複数のアジャイルチームから構成されサポートチームの援助が受けられるような大きなプロジェクトでさえ、今では他のレビューの機会が提供されていますが、より効率的なものにするには、これらはもっと反復して行われるべきです。例えば、これはスタッフに、設計、リリース毎に生成されるコード(品質ツールにより自動生成されたコードを含む)、または、イテレーションやストーリーについての責任を要求することになるかもしれません。また、アジャイルチームをサポートするために、スタッフの日々の働き方を変えること(結果的にコストがかかるリファクタリングに至らずに済むよう、レビュー/フィードバックのサイクルにおける毎日のチーム間の意思疎通を行うこと)が必要になります。
さらに大きなプロジェクトでは、リリース時期 (Fixする時期, Fixするリソース)に向けて計画される機能/性能の優先順位について、幹部関係者を交えてレビューすることをお勧めします。 さらに大きなプロジェクトでは、リリース時期 (Fixする時期, Fixするリソース)に向けて計画される機能/性能の優先順位について、幹部関係者を交えてレビューすることをお勧めします。 あまりにも頻繁にチームは決められた終了日までに何が納品できるかについて、初期段階で予想を立てることなくアジャイル・デリバリーを開始します。そして、その時点では、彼らは大きな間違いをしているかもしれないし、アジャイルで幹部関係者のニーズやコミットメントをサポートするための計画を十分にできていないかもしれません。サンプルの速度(この検証は何回かのスプリントを経ても依然として重要です)が判明するのを待ってから見積るのとは対照的に、「過不足のない」見積りを導くために長年使われてきたテクニックがあります。これは、アジャイルがもたらす価値についてまだ確信を持っていないかもしれない関係者に対して納品可能なものは何かの目安を提供するとともに、信頼を得るための助けにつながります。
InfoQ: アジャイルを初めて適用する場合、または、適用中のアジャイルの結果を改善したい場合、組織はどのようにこのガイドを活用したらよいでしょうか。
Paul: アジャイルの適用を初めて検討している場合においても、進行中のアジャイルを簡易的に評価する場合においても、このガイドをご利用になることをお勧めします。そして、ガイドの記述を信じるなら、現状とのギャップを書き出して、それらに取り組むための計画を作成するべきです。信じない点については、独自に取り組んでも構いませんが、ニーズに相応しい能力を持ち合わせたパートナの援助は確保するべきでしょう。