Ivar Jacobson Internationalの“Agile Essentials”は，１組のカードの形で提供される，アジャイルプラクティスのスターターキットだ。カードを使ってゲームをチームでプレイすることでアジャイルプラクティスを学び，作業の方法を試したり，実際に適用したりすることができる。
InfoQでは同社プリンシパルコンサルタントのRoly Stimson氏に，Agile Essentialsを開発した理由，プラクティス実践や適用方法改善の面で期待できる効果，EssenceやSEMATとの関係，ソフトウェア開発のプロがAgile Essentialsでプレイ可能なゲームなどについてインタビューした。
InfoQ: Agile Essentialsについて，InfoQの読者に簡単に説明して頂けますか？
Stimson: ポーカーサイズのトランプのパックです。私たちが経験から得た，成功したアジャイルチームが実践している７つのアジャイルプラクティスが紹介されています。
InfoQ: Agile Essentialsを作ろうと考えた理由は何だったのでしょう？
Stimson: アジャイルプラクティスに関しては困惑するほどたくさん議論されていますし，これが唯一と思えるような有名なアジャイルプロセスもあります。ですが，成功しているアジャイルチームを見ていると，いくつかのプロセスをうまく組み合わせて，非常に実用的な方法で選択して採用している傾向が見られます。しかもその結果として得られるプラクティスのセットが，とても似通ったものになっていることが多いのです。
このように選択されて組み合わされたプラクティスを，簡単に利用可能な形にしておく価値があるのではないかと思ったのです。特に経験の浅いチームや，アジャイル導入の“嵐”の中にいるチームを，もっと穏やかで生産的な水域に導くには有効だと考えました。
InfoQ: Agile Essentialsのアジャイルプラクティスをひとつ，紹介してください。チームがプラクティスを実践する，あるいはプラクティスの適用方法を改善する上で，Agile Essentialsがどのような効果があるのか，詳しく説明して頂けますか？
Stimson: プロダクトオーナシップを例にしましょう。
プロダクトオーナシップは，ユーザニーズとチームのソリューション開発との間を結ぶ領域として，非常に重要な役割を果たします。基本になっているのはプロダクトオーナというコンセプトですが，この役割に対する単純で安易な解釈が原因で陥りやすい落とし穴があるので，それを避けられるように，チームを支援するためのアドバイスが加えられています。
そのために私たちは，プロダクトオーナシップのカード“Product Ownership”を用意しました。その中ではプロダクトオーナの必要性に加えて，それ自身では役割を果たせないという事実も強調しています。プロダクトオーナは利害関係者のネットワークの中心にいます。チームの一員であり，チームのサポートが必要なのです。
利害関係者のネットワーク構築を説明した“Build a Stakeholder Network”というカードもあります。また，利害関係者が誰であって，彼らとどのように関わり合えばよいのかを明確化，視覚化する方法を説明したカードも用意しています。
製品のデモンストレーションを頻繁に行うという重要なアクティビティを説明した“Demonstrating the Product”や，そのフィードバックを通じて段階的に承認を獲得する“Achieve Acceptance”といったカードもあります。
製品に対するビジョンの共有を強調した“Product Vision”，フィードバック対応や学習を通じてビジョンを発展させていく“Evolve the Product Vision”といったカードも用意しました。
ですから，要するにプラクティスとは，一般的で明確なアドバイス(プロダクトオーナのコンセプトのような)を組み合わせて，優秀なアジャイルコーチやスクラムマスタが口頭でチームに伝えているような，基本的で実践的なアドバイスを補足したものと言えばいいでしょう。ただしそれは，短くて簡潔でなくてはなりません – ですから，これまで説明したものはすべて，７枚のポーカーサイズのカードに収まってしまいます。
InfoQ: InfoQは2013年に，ソフトウェアエンジニアリングの本質についてIvar Jacobson氏にインタビューしたことがあります。Agile Essentialsは，EssenceやSEMATとどのような関係があるのでしょう？
Stimson: カードのデザインにはEssence言語とカーネルを使用しました。そうすることに多くのメリットがあったからです。
まず第１に，一貫したルックアンドフィールと視覚的な手掛かりをカードに与えてくれています。例えば，そのプラクティスのアドバイスがどの分野(ユーザ，ソリューション，あるいは作業)を対象としたものか，どのような種類のアドバイスか(実践すべきアクティビティなのか，求めるべき何らかの価値なのか，あるいは作業を視覚化する上で重要な観点を提供するものなのか)といったことです。
第２に，カード同士の結合を可能にするための，自然な結合手段あるいは連結機構として機能しています。アクティビティカードを例にするならば，そのアウトプットについて説明したカードの道筋をたどることもできますし，そこからバリューチェーンに沿って，そのアウトプットを利用するアクティビティまでたどることも可能かも知れません。
そして最後に，Essence Kernelの提供するソフトウエア開発の問題空間のシンプルな標準モデルを中心に，プラクティスを構築することによって，スタンドアロンで利用可能であるだけでなく，同じように設計された他のプラクティスとも組み合わせて使用することのできるプラクティスの設計が可能になります。
InfoQ: ソフトウェア開発のレシピ化に反対意見を唱える人たちもいると聞きますが，Agile Essentialsについてはどうなのでしょう，これもレシピと呼んでいいのでしょうか？
Stimson: このカードは，標準として従うべきレシピを提供するものでは決してありません。例えばパイを焼く時のように，ステップを追って従うべきものではないのです。さらに言うならば，もしあなたがパイ屋で働くシェフになろうというのであれば，ペーストリの作り方や肉の焼き方，グレービーソースの作り方などは，知っておかなくてはならないことのはずです。もっとも，どのようなパイを焼くかについては，顧客とチームが一緒になって決めなくてはなりません。そのためにどのような既存のテクニックを利用するのかも決める必要があります。さらにはその過程で，新たなアプローチを開拓することもあるかも知れません。
このカードは，スクラムやSAFeのような既製のフレームワークとを使う方法と，その対極にある，各チームに“自分で考えろ”と言い放った上で，(願わくば)共有される価値観に基づいたアプローチをスクラッチから構築する方法の中間に位置するものなのです。
違う表現をするならば，このカードはイケアのフラットパックではなく，ハンマーや釘，接着剤，ドライバといったツールキットに近いものです。
InfoQ: Agile Essentialsのカードを使って，ソフトウェア開発のプロがプレーできるゲームの例をあげて頂けますか？
Stimson: これまでに発明されたゲームは，アジャイルチーム作業を基本として，アジャイルコーチやスクラムマスタと行うものがほとんどです。その中ではカードパックを，作業の取り掛かりや，あるいは作業方法の確認や支援の目的で使っています。
その一例がPractice AssessmentのTic-Tac-Toeです。これはチームが3×3のグリッドにカードをレイアウトして，一方の軸はその重要性(重要，重要でない，無関係)を，もう一方はうまくできる，あまりうまくできない，今はまったくできない，という項目を配置する，というものです。その上でチームは，今後新たに行ってみたいこと，あるいは別の方法でやってみたいことを決定します。
チームは例えば，自分たちが強いプロダクトオーナーシップを持っている，と思っているかも知れません。ですが実際には，主要な利害関係者が誰なのか，十分なインプットやフィードバックを獲得する上で彼らがどの程度関係しているのか，といったことを十分に把握していないかも知れないのです。
InfoQ: Agile Essentialsを利用する場合，ゲームのプレイに関するエクスペリエンスを交換したり，新たに開発したゲームを公開できる場所はありますか？
Stimson: Agile EssentialsというLinkedInのグループがあって，Q&Aやエクスペリエンス，発見，革新などについての他，新しいゲームの紹介も行っています。