2012年8月に、アメリカ・テキサス州ダラスで開催された Agile 2012 にて、藤井が Dean さんにインタビューを行いました。本稿はこのインタビューの内容を日本語に訳したものです。
Dean Leffingwell さんは米国コロラド州ボルダーを拠点とする企業家、著者、そしてソフトウェア開発方法論者です。近年、Dean さんが提唱されている「Scaled Agile Framework (SAFe)」は企業や事業部がアジャイル開発を活用して強力なプロダクト/システム/サービスを開発する姿を提供するフレームワークとして脚光を浴びています。以下に挙げるのは彼の著書の一部ですが、これを見るとソフトウェア開発方法論者としていわゆる統一プロセス（Unified Process）からアジャイルに至るまでの変遷を想像できるでしょう：
- Managing Software Requirements: A Unified Approach (邦訳：ソフトウェア要求管理―新世代の統一アプローチ、)
- Managing Software Requirements: A Use Case Approach
- Scaling Software Agility: Best Practices for Large Enterprises (邦訳：アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス, 翔泳社, ）
- Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise（邦訳：アジャイルソフトウェア要求―チーム、プログラム、企業のためのリーンな要求プラクティス, 翔泳社, 2014）
株式会社オージス総研では、2012年の7月から、同社のアジャイル開発センター長の藤井が中心となってDean さんの著書「Agile Software Requirements」を日本の読者に紹介する準備を開始しました。その一環として同年8月に、アメリカ・テキサス州ダラスで開催された Agile 2012 にて、藤井がDean さんにインタビューを行いました。本稿はこのインタビューの内容を日本語に訳したものです。このインタビューでは、以下の 5 つのテーマに渡り、藤井からDean さんに質問しました。
- Dean さんの経歴
- Scaled Agile Framework（SAFe）の誕生秘話
- Scaled Agile Framework（SAFe）の適用分野について
- 日本のアジャイル開発について
- Scaled Agile Framework（SAFe）のいくつかの用語の由来
Dean さんはユーモアのある人で、「私は短い話ができない、短い本も書けない」と宣言していました。以下では、Dean さんに突撃インタビューした内容をお届けします。
1. Dean さんの経歴について
-- Dean さんのこれまでの経歴を紹介していただけませんか?
私はついに自分のソフトウェア開発の第4回目の10年間を迎えました。（笑）
私は20代で、1人のソフトウェア開発者として、自分の職業人としての生活をスタートさせました。その後、すぐにソフトウェアに基づくビジネスを生業とする会社を起業しました。それは私が作った初めての会社です。そこで、CEOとして18年間も勤めました。その後その会社のビジネスから離れ、新たにRequisite Inc.,という会社を設立しました。私は実証可能なソフトウェアの安全性、つまり、本当に測定可能な高品質、高信頼性デバイスの要件の適応性などに関心がありますので、RequisiteProという製品を開発しました。このビジネスは4年間ほど続きまして、1997年にラショナル（※注：Rational Software）によって買収されました。
「犬のえさが売り払われたので、犬もついていかざるを得ない」というような話ですが、この買収に伴い、私もラショナルに入社しました。私は本質的に独立を好む人間なので、ラショナルに長く勤めることは初めから考えていませんでした。でも、大変驚きましたよ。ラショナルは私の経験の中でも最も楽しい学校のような場所でした。私はラショナルに4年間勤め、責任者としてObjectory(※注：オブジェクト指向開発プロセスの1つ)をラショナル統一プロセス（※注：RUP）に進化させ、商品化しました。RequisiteProやClearQuest（※注：IBMの製品です）の責任者を続け、UMLの普及にも貢献しました。Grady、Ivar、Jimとたくさん働き、それらの経験や方法論をまとめ、書籍として出版したりしました。ラショナルでは、上級副社長として製品ラインの大部分の責任者を務めていました。ラショナル時代は本当に楽しかったです。反対意見があってもお互いが認め合う風土がありました。そこでのキャリアも本当に好きでした。しかし、そのキャリアをおしまいにしたのです。
2001年に、私はラショナルを離れました。その後の10年間、まず小さなチームでのアジャイル開発をまず行いました。コロラド州の6つのスタートアップ会社に関与していたからです。
2. Scaled Agile Framework（SAFe）誕生秘話
2001年当初、子供が思春期に入り、難しいことがありました。子供と一緒の時間を確保するためには、ラショナルでの仕事時間は私にとっては長すぎました。そのため、ラショナルを離れた後、子供のために4、5年間はなるべく家に居るようになりました。そのおかげで、私がアジャイル開発手法にたっぷりの時間を注ぐことができました。
ある日、BMC社に勤めていた方から1本の電話がかかってきました。その方は今Cutter Consortiumに勤めています。彼はスクラムの大規模化について知りたがっていました。当初、彼のプロジェクトは400人の規模で、内100人がインドにいて、300人が米国国内にいました。大規模分散開発の方法について私に助言を求めてきたのです。
それがきっかけで、私がプロジェクトに関わることになり、そこでアジャイル開発のプラクティスであるXPとスクラムを適用しました。プロジェクトに必要なアーキテクチャーガイダンスやUXガイダンスなどを作成しました。また、複数のチームでの開発なので、チーム間の同期を取るために同じリズムで開発することを決めました。SAFeのたくさんの考え、及び最初の全体像はこのプロジェクトの経験から生まれました。その後、このプロジェクトで経験したことをまとめ「Scaling Software Agility」の本を書き始め、2007年に完成し出版しました。
「Scaling Software Agility」を出版すると、「私達は大規模開発を行っているのですが、支援してもらえませんか」というような電話がたくさんかかってくるようになりました。電話の大半は大企業からでした。こうした企業には機密保持のルール等があり、よい経験が共有されていないのが現実です。ただ、中に例外もあり、John Deere社、Discount Tire社、TradeStation社等は、自分達の経験を喜んで社外で共有しています（※注：これらの企業の事例については"Agile Software Requirements"のあちこちで言及されています。）。2006年から現在まで、私は多数の大企業で大規模アジャイル開発の支援を行いました。私が経験したもっとも大規模な開発プロジェクトでは5000人のアジャイル実践者が参加していました。
これらの経験により、SAFeの適用分野、適用規模等を検証することができました。もっとも適用が多いのは500人から1000人の開発者とテスト担当者のプロジェクトかもしれません。また、チーム間の協力と連携をより多く求められる場合、SAFeを必要とする可能性が高いとうことが分かりました。その場合、計画に関する既知のポイントや、ビジョンへのベクトル合わせ、システムインテグレーション等を用意しなければなりません。
このように、2006年から、私は大規模開発に関するコンサルティングを提供し、その経験に基づいて、ブログを書き始めました。そこでSAFe（私はフレームワークと呼びますが）が形をなしたのです。その後、「Agile Software Requirements」では、そのフレームワークをまとめました。その本は今あなたが翻訳していますね。
-- そうです。
本の中にある全体像は58回の改訂を経たものです。今あなたの手元にあるもの（※注：インタビュー時に頂いた全体像）は第97版です。つまり97回も修正しました。
「本を書くこと」について、1つ感じたことがあります。本を出版した後に、私は継続的に新しいことについて学習し続けています。書籍の出版はリーンではなく、純粋なウォーターフォール開発ですね。1冊の本を出すのに、たくさんの時間がかかります。ブログでは、感じたことを随時書いたり、修正したりすることが手軽にできますが、書籍は違います。書籍は一旦出版されたら、その印刷物は1つのブランドとして存在しています。容易に変更できません。新しいことを学習できていても、次の版の出版までに待たなければなりません。従って、潜在的な読者は、そろそろ次の版が出版されるかもしれないと思い、たくさんの販売につながりません。従って、書籍はリーンではない、情報の塊の巨大バッチだと思っています。SAFeのブログでは、私は単に図とかを貼り付けて、その内容について書くだけで済みます。
1年前に、何人かの方から「あなたは方法論を持っていますので、整理して、世に出しましょう」と声を掛けられました。彼らは現在私のビジネスパートナーとなっていますが。しかし、私は過去に方法論の戦争を数回経験していたので、それをもう1回やりたくなかったので、消極的でした。彼らは何回も何回も「私達は大規模開発をしていますが、あなたが持っているものは、他のどこでも見たことがありません。私たちはあなたと一緒に、これらの方法、考えを整理し、そして製品にしませんか」と説得しに来ました。そして、コンテンツの著作権は保留しつつ、コンテンツ自身は誰でも利用できるように無料で公開することで合意しました。そのため今では、SAFeがWebで公開され、人々がそれをリンクしたり、利用したり、必要に応じ修正したりすることができます。すべての考えが無料で入手できます。自分のニーズに合わせ、実装することもできます。このように、SAFeの利用について、私達がいなくでも利用者は自分で行うことができます。但し、私達はSAFeの概念や技術についての権利を持っています。概念的な一貫性がもっとも大事だと考えるからです。
SAFeは1つのシステムです。たくさんの作業があり、それを非常に良く実行しなければなりません。作業の各部分は関連性がありますので、全体ではなく、一部だけ選択して利用することはお勧めしません。例えば、もし、あなたがプロダクト管理やポートフォリオ管理について話します。内容の管理や内容のガバナンスについてのプロダクト管理者やポートフォリオ管理者の役割を理解しなければなりませんね。このように、すべてが繋がっています。スプリント計画だけを理解し、大規模はどうするというような断片的な理解の仕方では、適用は難しいです。このようなことから、結果的に、SAFeの全内容を公開し、更新し続けることを決めました。ご存知のように、インターネットはすべてを変えました。1つ大きな変化は、コミュニケーションのやり方を変えたことです。SAFeを形にし、ピアレビュー後に公開し、市場の反応を観察し、それによって新しい考えが生まれ、それをまたSAFeに反映しています。
最近、SAFeを実装する方々に向けて、トレーニングと認定制度をスタートさせました。こうして、彼らは自分でSAFeを実装できるようになります。SAFeはフレームワークであり、役割が定義され、個々の役割がすべきことも定義されています。但し、具体的にどのように実装するのかについては、トレーニングや認定に参加した方々の支援が必要だと思います。私自身がトレーニングの講師としても務めています。トレーニングのプロセスを通じ、人々に影響を与え、彼らが成長することはうれしいことですね。さまざまな会社がSAFeを利用し、よい成果を生み出しました。私にとって、チームの良い成果はなによりの報酬です。
-- それはそうですね。ちなみに、Dean さんはいつリーンと出会われましたか？
私にとって、それはアジャイルよりも前のことでした。1985年、私のビジネスの1つに製造能力を追加しようとしました。始めるや否や少し苦労し始めました。というのは健康手当や有給休暇などを追加して働き甲斐のある職場にしようとしたのです。しかし、ビジネスのコスト構造が変わってしまい、私達は損失が出始めました。私はR&Dの人間であり、ソフトウェア開発の人間ですが、同時に会社のCEOでした。私は自分達がもし製造に詳しくなければ、成功などできるはずがないと感じていました。そして、自分達がやっていることを精査しました。ちょうどその時 Eliyahu M. Goldrattの「The Goal」という本に出会いました。この本は、リーン以前の制約理論について書いていました。私はこの本を読んで、フローを明確にすることで、自分達のリソース配分やボトルネックの所在が分かるのではないかと感じ、自分達の仕事に有効であるかもしれないと思いました。それで、Goldrattのトレーニングコースに参加しました。その後、リーンを利用し、製造に関する業務の運営を成功させました。当時、今と違って、リーンはあまり知られていませんでした。今では、リーンの80%はトヨタ生産方式から由来していることが知られていますね。
2001年に私が関与していたベンチャー会社の1社はリーンな製造業のソフトウェアを開発していました。私はその会社の取締役員会のメンバーとして、リーン製造向けのMRPではない、MRPシステムを考える手伝いました。
私はアジャイルはリーンの1つのインスタンスでり、リーンの流れは我々の産業にあることを常に意識していました。そして、Donald G. Reinertsen（※注： 「The Principles of Product Developmnent Flow」 の著者）やDavid Anderson（※注："Kanban"の著者）を通じ、本当に理解しはじめました。アジャイルやスクラムはリーンプロセスだと思いました。私はスクラムのルーツを読みました。Jeff Sutherlandは「新新製品開発競争」（※注：竹内弘高、野中郁二郎両氏が1986年にハーバードビジネスレビューで発表した論文"The New New Product Development Game"のこと）からたくさんの考え方を参照し、2001年にスクラムを提唱しましたね。私にとって、リーンは常にそばにありました。しかし、スケールアップをしようとしたときに、意外に難しかったです。
プロダクトオーナーは常に十分な顧客のドメイン知識や経験をもっているわけでもないし、プロダクトマーケティング、プロダクトの位置づけ、ライセンス管理などについても詳しくなかったので、プロダクト管理は自分たちによって管理ができないことを分かっていました。こうした問題に対するうまい解決方法がありませんでした。しかし、リーンの哲学がこの状況を変えました。例えば、1つの組織にアプローチする時に、リーンの視点からソフトウェア納品の遅延に着目してみましょう。Al Shalloway（※注：Net Objectives社の創業者）はあるカンファレンスで素晴らしい話をしていましたが、彼によると、ソフトウェア開発の問題の多くは、開発中の遅延として顕在化するというのです。つまり、Bの時点で、Aということを行うのが間に合わなかったので、遅延が発生してしまいます。リーンの場合、製造の観点ではこの遅延は一種のムダです。同じ考えで、ソフトウェアプロセスの中にムダを探すことは生産活動そのものです。この活動によって、例えば、テストにタイプ1, 2のムダがあるかどうかを判断できます。遅延を識別し、そして防止できます。バリューストリームの観点からリーンを考えると、バリューストリームの分析ツールを利用し、遅延の識別ができます。
その後、Donald G. Reinertsenの 「The Principles of Product Developmnent Flow」 という本に出会いました。私はこの本が金の鉱脈だと思っています。この本を通じ、私はSAFeにはそれらの原則がすでに含まれており、有効だと分かりました。まだ、リズムと同期はSAFeのツールであることに気が付きました。この本の中には、これらの考え方はすべて原則としてまとめられています。本を読んで、それこそがプロダクト開発だ、製造の視点ではないと認識しはじめました。製造の視点はバラツキを制限し、ムダを削減することを教えてくれていました。プロダクト開発の視点では、私達は信じられないほど不確実性が高い世界にいます。（他のプロダクトとの差を生む）バラツキは重要です。バラツキは時として利用するものであり、見つけるものではありません。
「The Principles of Product Developmnent Flow」と出会った時、「Agile Software Requirements」はまだ書き終わっていなかったので、その後の半年は、「Agile Software Requirements」を一から書き直すことに費やしました。プロダクト開発フローの原則を、土台としてどのように利用するのか、考え込みました。そして、その本はアジャイルだけではなく、リーンに関する内容も盛り込むことになりました。私にとって、リーンは常に手の届くところにありました。分かったことは、チームを離れると、思考のためのフレームワークが必要になるということでした。
リーンは広いですし、実践には困難が伴います。リーンのツールの1つであるカンバンを利用しているという事例をよく聞きます。カンバンはとても良い方法ですが、ワークフローを管理する１つ方法であり、リーンのごく一部にすぎないです。リーンは管理をサポートし、管理を軸としています。開発者に教えるためのものではなく、マネージャーに教えるためのものです。しかし、アジャイルの場合、開発チームに教えますので、随分様子が違います。マネージャーは「鶏」となります。あなたは「豚」と「鶏」のストーリーはご存じですよね。このように、マネージャーはこのモデルを理解していないし、教えることもできません。そして、しばしば管理を「干渉」としてとらえます。リーンはこのようなアプローチではありません。リーンの基礎はマネージャーがリーンを理解し、リーンの原則やプラクティスを実際に適用できますし、教えることもできます。上のレベルに行くと、まずそのようなマネージャーを探し、さらに上のマネージャーを探します。それらのマネージャーを教育するのです。このように、チームにスクラムを教えることではなく、考え方を教えなければならないのです。また、リーンはスーパーセットであることも教えます。リーンとプロダクト開発フローさえ理解できれば、アジャイルのすべてに関する理解の助けになります。一方、それらはプラクティスにすぎません。やって、うまく行くのがプラクティスです。
スプリントの期間はU字曲線最適化のバッチサイズとオーバーヘッドに関わるものです。スプリントが長くなると、バッチサイズが大きくなります。処理コストが低くなりますが、大きな計画及びデモの時間等がかかります。これは1つの例に過ぎないのですが、1週間のスプリント、あるいは2週間のスプリントはどうでしょうか、これはU字曲線最適化のバッチサイズとオーバーヘッドです。U字曲線最適化なので完璧な答えはないですよね。1スプリントは1週間から4週間の範囲でうまく機能し、柔軟性があります。1週間、2週間、3週間でもよいが、4週間を超えると、バッチサイズが大きくなり、フィードバックが遅くなります。1週間のスプリントではフィードバックが迅速になりますが、計画のオーバーヘッドが発生してしまいます。この例はリーンの考え方が私達の大規模なソフトウェア開発で直面している課題の解決に役に立つことを示しています。
3. Scaled Agile Framework（SAFe）の適用分野について
-- 次の質問は大規模アジャイル開発についての質問です。スケールアップする場合、ある特定の分野がやりやすいといったことはありますか。
今日昼食の時、ちょうどAl Shallowayとこのテーマについて意見を交換しました。彼も大規模アジャイル開発の世界に関心を持っています。私達は考えているスケールアップのパターンが似ています。仮に、顧客を、ソフトウェア開発、IT、大規模ソフトウェア開発と3種類に分けます。彼らはそれぞれの課題を抱え込んでいますが、ふたを開けてみると、課題に対するソリューションは同じパターンに落とし込まれます。我々のツールとしては、まず、メンバーを1つのチームに入れて、チームに1つのバックログを持たせます。それから、チーム間は1つのプログラムバックログを基にお互い調整し合います。従って、主要な司令官は誰かが分かるし、プログラムバックログの目的が何であるかを理解できます。一言で言えば、問題がどこに由来しているかに関わらず、答えは似ているということです。私達はコンサルティングの仕事をしていますので、答えからのスタートは嫌ですね。しかし、これは予測可能な答えであるため、答えからスタートしなければなりません。そして、ゴールが明確になります。同じですが、1つのビジネスの変革を行う場合、期待された適応方法を利用します。このように、ゴールに構造を与えます。ゴールはリーンの原則を利用し、アジャイルについて考えて、恩恵について検証します。そして、できるだけ早くゴールに到達します。
-- 日本の場合、金融分野では多数の大規模プロジェクトがあります。米国の場合、この考えは金融分野でも利用できますか。
もちろん適用できます。私の経験から、金融サービス分野では、ソフトウェア開発より、従来のITに偏っていますので、彼らは常に1種の「後期採用者」です。不具合に対するコストが極端です。私は1つの金融の開発事例を見ていました。不具合なのか、ユーザの問題なのかは分かりませんが、彼らはとにかく全部ソフトウェアのせいにし、400,000,000米ドルの取引の間違いの口実にします。従って、新しい技術であるという理由だけでそれを採用することには彼らは恐らく消極的でしょう。しかし、最近は少し事情が変わりました。SAFeの認定トレーニングコースでは、大手の保険会社からの参加が多いです。彼らは、アジャイルとリーンを導入し始めています。そのような分野の95%の企業はまだアジャイルな企業ではありませんが、アジャイルの種がまかれています。このため、私の考えとしては、各分野は状況が異なりますが、リーン、アジャイルの適用には大差はありません。アジャイル開発のスケールアップの原則はその分野にでも適用できます。
-- 組込み開発はどう思いますか？
それも常に視野に入れています。ボルダーのある会社はホームオートメーションシステムやエネルギー管理システムを開発しています。彼らは1週間のスプリントで開発を進めていて、ハードウェアとソフトウェアの開発はともにあります。「John Deere」という会社、私のブログに事例を紹介しましたが、彼らはエンジン制御のためのユニットの組込みシステムを開発しています。トラクターやコンバイン等のガイダンスシステムや、この部屋より大きいハードウェアを開発しています。そして、ソフトウェアだけの開発ではないので（ハードウェアとソフトウェアの）開発は定期的に同期しています。ソフトウェアは柔軟性があるのに対し、ハードウェアはそうはいきません。例えば、ディスプレイに新たに1ピクセルを追加するのは無理ですね。しかし、ソフトウェアの場合、「OK、グラフィックを最適化するよ」で終わりです。
-- たくさんのアジャイル開発に関する本の中では、アジャイル開発事例を紹介しています。しかし、紹介した事例はサービスベンダー、クラウドサービスベンダーが多いと思います。Dean さんはアジャイル開発がエンタープライズ開発やITに向いているかどうかについて、どう考えますか。
BMC社は、私の最初の大規模アジャイル開発事例となった企業ですが、ここはITインフラ構築を行う企業です。BMCパフォーマンスマネジャーはネットワーク管理とモニタリングを行い、企業のITインフラの中で運用されています。このシステムの開発はアジャイルで行いました。やらなければならない振る舞いを定義し、小さなステップで開始しました。大きなプロジェクトも小さなプロジェクトも失敗します。成功させるためには、小さなプロジェクトを1つずつ成功させ、開発者とテスト担当者がペアで作業すること、プロダクトオーナーがローカルに意思決定を行える権限を持つことなどです。これらの原則やプラクティスは開発の分野と関係がなく、どこでも適用できます。
-- ビジネスアプリケーションを開発する際に、ビジネスプロセスとソフトウェア機能を一緒に検討しなければなりません。アジャイル開発では、ビジネスのプロセスとソフトウェア開発をどのように融合しますか？
それは大きい、全体的な質問ですね。部分的に答えると、チームがアジャイルを適用する場合、たくさんの良いものを捨ててしまいがちです。著しく新しいITアプリケーション開発のアプローチでは、それはパートナー、ベンダー、システムそれぞれの振る舞いを変えるので、この場合、モデリング技術の適用が有効です。ご存知のように、UMLはビジネスモデリングに有効なツールです。これを利用し、ビジネスとその抽象モデルを考えます。また、ビジネスモデリングツールとの組み合わせによって、ユースケース図を書きながら、フィーチャーやユーザーストーリー等を抽出できます。これは唯一のアプローチではないかと思います。反復をするだけで、振る舞いをもう一度変更したい、あるいは他のアプリケーションを配置したいという要望に対応できません。システムにある程度の意図的なアーキテクチャーが必要です。大規模になれば、モデルが必要になります。私自身はいまだにモデリングが大好きです。私の経験では、モデリングができるチームはモデリングをしないチームより、生産性が高い傾向が見られます。その理由はモデルが抽象化であり、ソフトウェアも抽象化であるからです。オブジェクト指向、汎化、特化、遅延束縛、等、これらをモデリングします。モデリングを通じ、共通性を発見し、共通クラスを作成します。また、振る舞いを共有していることが分かった時、それが抽象クラスだと気が付くことができます。抽象クラスは面白いです。何もしない、ほかの具体的なことを行うクラスのファクトリーとなります。これらは純粋なソフトウェアの考えであり、オブジェクト指向技術からくるものです。モデリングを検討する時にも役に立ちます。
私は依然根っからのシステム開発者です。モデリングも信じています。現在の状況（RUPやモデリングへの批判）は多分RUPやモデリングそのものが持つ複雑さに原因があったり、あるいは間違いを防ごうとして自らを縛ったのかもしれません。いずれにせよ、これはソフトウェア開発ライフサイクルであり、すべてを捨てるのではなく役に立つものは拾い上げなければなりません。例えば、ある開発プロジェクトの中でカンバンが効果があったからと言って、スクラムはダメということにはなりません。逆に、スクラムがうまく行ったので、カンバンもきっとうまく行くということにもなりません。
例えば、ユースケースの利用について、システムA、B、Cがあります、それらはお互い協調しながら、振る舞いを表現します。各システムにはストーリーがありますが、ストーリーの背景にある大きな文脈は果たして何でしょうか。ユースケースなしにこうしたことを表現するとしたら、悩みますね。
400、500人の開発者が同時に1つのシステムを開発する場合、そこには必ず何人かのアーキテクトがいます。通常、彼らはUMLを利用し、ユースケースモデルを作成し、ドメインモデルへと分解します。そして、皆が1つ共通の言語を用いることで、このシステムは何に関するものなのかをお互い話をすることができます。そして、命名できます。システムを何と呼ぶべきかについて、テキスト、アイコン、言葉、もの事など利用し説明できます。最初のモデルはドメインモデルであり、それを用いてシステムをより現実的に説明できます。現在のアジャイル開発では、モデリングはさほど重視されていないように思えますが、今後、再び重視されるでしょう。
-- Dean さんの見方では、要求の表現としてユーザーストーリーが一般的になってきているでしょうか？
そうだと思います。アジャイルチームでは、一般的になってきています。ユーザーストーリーの概念は素晴らしいです。我々は「システムはこうすべし」というような世界にいますが、「システムはどうこうすべし」にはだれも関心がありません。とても退屈な概念です。これに対して、ユーザーがシステムを利用して何ができ、それによりなんらかのビジネス価値を得ることを表現できるので、ユーザーにとって大変意味があります。しかし、チームがチームレベルで使いますので、依然小さな概念です。自らのコンテキストを提供しません。SAFeでは、フィーチャーという概念を導入し、コンテキストの情報を提供します。さらに、動作を詳しく記述するためにユースケースを使います。ユーザーストーリーはチームレベルで使える有用な概念で、このような素敵な概念を紹介してくれたXPに感謝しています。しかし、エンタープライズ規模ではユーザーストーリーだけでは対応できません。
-- 次の質問はプロダクトオーナーについてです。この役割はビジネスに関心があり、開発するシステムのスコープにも責任を持ちます。システムの機能を決めたり、優先順位を付けたりして、役割を果たすのはとても難しいと思います。この役割を担当する適任者をどのように探し出すべきでしょうか。
確かにこの役割は難しいですね。一般的に、この役割を担当する人は会社内部から育成します。外部から連れてくる場合、その人は会社のドメインに詳しくなければなりません。あなたが質問の中で述べた、優先順位を付けることや、重要な意思決定を行うこと、ユーザーストーリーを管理することなどは、アジャイルの問題ではなく、ソフトウェア開発の問題です。違うのは、スクラムではプロダクトオーナーという名前でそのようなことに責任を持つ役割を明確にしたという点です。最近、ある大企業で18箇月の現状評価を行いました。その際に、私は彼らに一番良かった点を聞きました。彼らは以下を挙げました。
- XPの技術プラクティスの導入によって、品質と生産性を大幅に向上できた。
- プロダクトオーナーがチームの原動力となった。能力のある人達が育つ過程でドメインを理解し始め、プロダクト管理者と連携しています。彼ら抜きでは、もはやソフトウェアをどのように開発したらよいか見当がつきません。
私の観点では、プロダクト管理者と一緒に作業するプロダクトオーナーグループはアジャイル開発の成功のための要点です。スケールアップに関しては、よく勘違いされる点があります。つまり、スクラムでは、プロダクトオーナーは受け入れ基準を書いて、すべてのフィーチャーを理解し、市場や顧客と一緒に作業をするという考えです。しかし、1000人以上のプロジェクトの場合、必ず100人くらいがアサインされ、彼らがフィーチャーに関する機能要求を決定し、ROIをフィーチャーレベルで決めることになります。1つの役割を分担することができます。それでも、プロダクトオーナシップ（プロダクトに対する全体的な責任）の役割は分担されません。プロダクトオーナーは顧客の要求をよりよく理解するためのチームの代理人にすぎません。プロダクトオーナーの定義はシンプルですが、仕事の内容は複雑なのです。
4. 日本のアジャイル開発について
-- 私は日本のユーザー企業とシステムインテグレーターの関係について、このイメージ図を作りました。ユーザー企業はエンドユーザーがいて、IT部門があります。IT部門はエンドユーザーの要求をまとめ、システムインテグレーターに発注し、システムを開発してもらいます。このモデルでは、典型的に以下2つの問題があります。
- エンドユーザーはビジネスの専門家ですが、ITについて分かりません。IT部門はシステムの可用性、メンテナンスに注力し、ビジネスに詳しくありません。また、新しいものへのチャレンジをためらいます。
- IT部門がシステムインテグレーターに発注する場合、一括請負契約が多く、固定コスト、固定スコープで高い品質を要求します。
このような光景は日本ではよく見られます。Dean さんの経験上、このような場合、システムインテグレーターがアジャイル開発の導入を成功させることは可能ですか。
とても面白い図です。これは「落下型」のプロセスですね。ユーザー企業内部でもエンドユーザーからIT部門の要求伝達が必要です。この要求伝達により、エンドユーザーの要求がシステムの機能になり、そしてコストを固定化できます。しかし、エンドユーザーが自分の問題を解決できるシステムをうまく説明できないので、この伝達はエンドユーザーの本当のニーズを反映できていない可能性があります。図からも分かると思いますが、フィードバックループが欠けています。
もし、システムインテグレーターが一括請負契約に気にせず、アプローチを少し変えられるのであれば、例えば、この関係を変え、直接エンドユーザーとやり取りすることによって、固定コスト、固定スコープの前提であっても、要求に応じた納品ができると思います。私がシステムインテグレーターであれば、固定コスト、固定スコープが前提であっても役立つシステムを作るためにインクリメンタルに納品します。ユーザーにフィードバックするや否や固定スコープの機能の中でユーザーがほしくないものが見つかります。一旦この事実が理解されたら、境界線が変わり始めます。ユーザーの方から「このような問題が分かったので、従来の契約は嫌になりました。」と言ってくれるかもしれません。さらにユーザーは契約等の問題を解消し、本当にほしい機能やソリューションが分かるようになります。さらにシステムインテグレーターやソリューションが変わり、固定スコープで予測していたのと異なる、より良い状態になるのです。
しかし、そのようなフィードバックループを持つことができない場合、本当のニーズの代わりのものが良いというふりをし、中間的に多くのリリースを提供して邪魔をしないように1年間やり過ごせばいいとして間違った場所に至ってしまうのです。結果的に、通常ユーザー企業は不幸になり、システムインテグレーターは損失を出し、両社の関係が悪化します。
また、ビジネスのモチベーションを考えると、ユーザー企業がIT部門を通じてシステムインテグレーターに発注するや否や、できるだけ少ない予算で可能な限り多くのものを得ることが経済的目標になります。一方、契約後のシステムインテグレーターの経済的目標は、納品するものをできるだけ少なくしようとします。このような状況では、双方が自分だけの都合を考えて、最適化されません。アジャイルでは、固定コスト、固定スコープという障害を打ち破りたいと思います。その方がうまくことが運ぶからです。インクリメンタルな納品であっても異なる結果が得られるでしょう。
ユーザー企業がアジャイルであれば、システムインテグレーターもアジャイルになれます。システムインテグレーターがアジャイルではない場合、ユーザー企業はアジャイルな振る舞いを要求することによって、インクリメンタルなリリースを可能にし、そして、必要なフィードバックを提供できるようにします。基本的にフィードバックがなかったら、開発したシステムは貧弱になります。例を挙げます。システムの開発期間を1年としフィードバックが遅かったり、なかったとし、ニーズが代理（IT部門）を経由して伝達されるとします。ビジネスニーズ、技術ニーズ等がうまく伝わらず、1年の間にはどのみちビジネスニーズが変化し、技術も変化します。開発したシステムは当初の要求を満たし、開発費用も回収できましたが、それでエンドユーザーが最終的にほしいシステムを提供できるかというと、そうはなりません。従って、これは基本的に悪い計画です。しかし、これが現実でもあるのです。
-- 米国で、このような状況を見たことはありますか？
しょっちゅう見ます。これは日本独特の状況ではありません。従来型のITアウトソーシングモデルですね。しかし、このモデルはうまく行きません。それで現在のような状況になったのです。そのモデルで生き残れなければ今ここにいないでしょう。このモデルは顧客との協調より、契約を重視しますので、最適な結果を出すことができません。世界は進化しなければなりませんので、顧客と開発側の関係もリーンにならなければいけません。システムインテグレーターは単に1つの購買先だけではなく、パートナーです。システムのコードは彼らの助けがなければ動きません。リーンの視点では、パートナーはエコシステムの一部であり、リーン企業の責務は自分のパートナーの能力を最大限にし、自分のニーズをよりよく満たすことです。アジャイルプラクティスの良いところは、大きなプロジェクトを小さく分割し、時間とともに価値を少しづつ提供するところです。リーンは問題に対処する言語を提供します。彼らが私のパートナーである以上、彼らのスキルを向上させ、彼と協調し、よい結果を生み出すようにします。トヨタのような強力な製造企業では、パートナーをシステムの一部として育てることによって、自分達の会社を素晴らしい会社に作りあげます。
従来のソフトウェア開発のモデルはリーン思考のモデルではありません。リーンはアジャイルやスクラムからは得られないツールを提供します。
-- 企業の文化をどのようにアジャイルに転換すればよいでしょうか。何か適用可能な方法論やテクニックはありますか？
魔法の薬はありませんよ（笑）。
1つの経験を企業全体に展開するというメカニズムは存在するでしょうか。そんな薬はありません。企業の文化を変えることは本当に大変な挑戦です。私が重視することは常にシンプルです。それは「勝つことは楽しい」という考えです。より良いプロダクトを提供できるソフトウェアプログラムはより楽しいものです。従って、企業の文化をよりよく転換しようとする際に、勝たせることでそこに楽しさを加えられるようにしましょう。企業文化がアジャイルチームに権限を委譲するのに前向きかを心配する必要はありませんが、隅にいるチームに権限を委譲し、結果を出させ、楽しさを感じられるようにし、ウイルスのように広げることが重要です。成功と楽しさは習慣になるものです。隅から始まり、プログラムまたはリリース列車に乗り、開始し、結果に注目します。ビジネスは結果に注目し、チームも結果に注目し、それによって皆がより幸せを感じるのです。
-- 日本の経営陣と若い人達はアジャイルやリーンの考え方に賛成しています。しかし、中間管理職の方々には少々抵抗があるように見えます。
私の1つの顧客は中間管理職層を「永久凍土層」と分類しています。「永久凍土層」は地表では柔らかいですが、6インチほど掘ると氷のように凍結しているというアナロジーです。彼らとは話はしやすいですが、何も変えられません。中間管理職層をどのように変えるか、我々のアプローチは彼らところに直接に行くことです。質問をしたり、リーンとアジャイルの取り組みをここに根付かせようというのは聞いているでしょう、それが立ち消えたりしません、うまくいきますよと話をするのです。マネージャーには、取り組みの邪魔をするか、取り組みに従うか、取り組みをリードするかの選択肢があります。彼らは取り組みをリードすることを選びます。しかし、業界にはそのようなマネージャー向けのものが用意されていません。マネージャーに対するトレーニングもありません。
SAFeは違います。マネージャーに直接アプローチします。SAFeではプログラムレベルが明示され、リーダーシップの重要性が示されます。彼らにトレーニングを提供し、問題についての考え方を教えます。このように、私達は彼らに対して直接「さぁ、あなたたちはリーダーであり、マネージャーです。あなたの取り組みをリードする能力次第で、失敗か成功かが決まります。」と言います。トレーニングを通じ、成功のためのツールを提供します。このようにして、彼らは自分のスキルを継続的に向上させます。
中間管理職を変化させるためには、直接「これが未来です。あなたーはマネージャーだ。あなたは未来の一部になりたいですか。あるいは列車にひかれたいですか。」と語り掛けます。直接的なアプローチです。本当のことでもあるので、このアプローチに感謝するかもしれません。彼らは一旦自分自身を変えられると分かれば、あるいは、あなたが彼らにリードして欲しいという答えを持っていて、トレーニングも提供しようとしていると理解できた時、彼らは喜んで自分の仕事をします。全体像の中に彼らの役割が描かれていますよね。これで抵抗するを止めます。そこに自分達が含まれているからです。逆に自分達が含まれなければ、抵抗します。
5. Scaled Agile Framework（SAFe）のいくつかの用語の由来
-- Dean さんの本の中でアーキテクチャー滑走路、リリース列車という用語を利用しています。滑走路や列車のような用語には何か特別な意図がありますか。
飛行機、列車というまぜこぜの比喩を使ってしまい、申し訳ないと思います。言い訳はしませんが、自然にこのような用語となってしまいました。
アーキテクチャーについて考えた時、英語で「landing（着陸）」という言葉がまず浮かびました。それは、「landing a sprint（スプリントを着陸させる」）、「landing a release（リリースを着陸させる）」というようなイディオムがよく使われているからです。「landing（着陸）」が広く使われている理由は、私なりの推測ですが、多分「Burndown（バーンダウン）」との関係ではないかと思います。バーンダウンの図は徐々に降下するように見えますから。「着陸」の成功をサポートするためには、フィーチャーだけではなく、その土台となるアーキテクチャーを用意しなければなりません。そのようにして「アーキテクチャー滑走路」というメタファーが育ったのです。
リリース列車のメタファーは違います。列車という概念によって、リズムと同期を表したかったのです。列車は時間通りに駅から発車します。元々はラショナルの時代に年2回Rational Suiteを出荷していたことが起源になります。顧客との間で、日程を決め、品質を固定し、機能を変更可能にします。顧客の貨物を列車に載せる場合、固定コスト、固定品質では運ぶことができません。（機能等）それ以上のことは約束できませんが、いつ発車するのかは明確です。貨物の量が多くても少なくでも、定期的に提供できます。そうすることで自分達が定期的に出荷する大きなプロダクトの一部を担っているのだという意識を持てます。SAFeでは、この定期的に提供したものを「潜在的に出荷可能なインクリメント（PSI: Potentially Shippable Increment）」と呼びます。提供期間は10週前後です。また、リリースを構成する各要素の開発を同期することもラショナル時代に学んだことです。リリースの時期が決まれば、各要素のAPIも同期することができます。各要素のAPIは個別に開発されますが、ある時点で同期させるのです。
つまり、アーキテクチャー滑走路はバーンダウンに由来し、そしてリリース列車は列車のメタファーに由来するということです。そう言えば自動車がないですね。（笑）
-- アーキテクチャー滑走路は離陸ではなく、着陸だったのですね。
バーンダウンに由来するので着陸です。リリース列車では飛びながらビジネスフィーチャーを作りますが、それを着陸させる必要があるのです。着陸するためには、新たなフィーチャーを追加するのに足りるだけのアーキテクチャー滑走路が必要です。そのため、アーキテクチャー滑走路は常に拡張されます。新たなPSIを着陸させるために、アーキテクチャーも拡張する必要があります。アーキテクチャー滑走路は、6ヶ月先を見て開発します。2年ではありませんし、2週間でもありません。単なる混ざり合ったメタファーであり、イディオムです。
レースカーも試みたのですがうまくあてはまりませんでした。結局、列車と飛行機になりました。
-- 質問は以上です。お忙しい中、ありがとうございました。
最後の質問は良い質問でしたね。楽しかった。ありがとう。
45分程度の比較的短いインタビューで質問数も少なかったですが、各質問に非常に誠実に回答して下さった姿がDeanさんの人となりを示していると感じました。インタビューアーとしては、「Agile Software Requirements」に記されていなかったSAFe誕生の背景やリーンとの出会い、アーキテクチャー滑走路などの用語の由来が聞けたのが非常に参考になりました。また、内製開発が多い欧米ではアジャイル開発の導入がスムーズに進んだのではないかと推測していましたが、欧米でも日本か直面しているような課題を解決してきたことが分かったことで少し心強い気持ちになりました。
最後に2012年に収録したインタビューを記事として掲載するのが遅れた点をDeanさんと読者の皆さまにお詫び致します。