株式会社オージス総研お客様のシステムが環境の変化に対応し長期間持続していくための「百年アーキテクチャ」を私たちは目指しています。Deliver)」のご案内アジャイル要求(DtoD)でスクラムとユーザーストーリーを補うスクラムでは、ユーザーストーリーと呼ばれるユーザーと開発者の両方が理解できる言葉でプロダクトの価値やシステムの振る舞いを定義することが一般的です。ユーザーストーリーは簡単な形式でユーザーニーズを表現できるという点で大きな利点がありますが、ユーザーストーリーを考案する具体的なプロセスが不明確である、業務やユーザー、技術などの複数の利害関係者が関与する開発の内容を判断するにはユーザーストーリーに書かれた情報や観点だけでは不十分である、といった課題があります。オージス総研では、これらの課題をアジャイル要求(DtoD)を実践することで解決することを提案します。合意する“DtoD”DtoDは3つの時間軸とプロダクトの7側面の観点を用いてプロダクトに対するニーズとその実現スケジュールを利害関係者で話し合い、合意するためのフレームワークです。DtoDが生まれた背景スクラム※の普及2001年にアジャイル開発宣言が起草されて以来13年が経過し、欧米ではアジャイル開発が当たり前になりつつあります。そのようなアジャイル開発の普及に大きく貢献したのが「アジャイル開発のミニマムセット」と呼ばれるスクラムというコンパクトなアジャイル開発フレームワークです。スクラムは、単純化すると以下の4つの特徴を持ちます。スプリントという一定の期間毎に動くソフトウェアを作る要求はプロダクトバックログという優先順位付けされた一覧表に保管される各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定するスプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行う1.のように一定期間毎に動くソフトウェアを作ることを時間枠(タイムボックス)納品とここでは呼びます。スクラムは、優先順位付けされたバックログ項目の優先順位順に動くソフトウェアを作り、作成されたソフトウェアを評価することで開発依頼者や市場のニーズに即したソフトウェア(プロダクト)をすばやく開発することを可能にしました。これがスクラムの普及の大きな原動力となったのです。プロダクトバックログ項目を表現するユーザーストーリーその一方で、スクラムはコンパクトなアジャイル開発フレームワークとして誕生したために以下のようなことの具体的な実行方法が当初規定されていませんでした。Jefferiesの3C(カード、会話、確認)の3段階でユーザーストーリーを発展させる方法が提案されました。ユーザーストーリーマッピングという手法が登場し、ユーザーストーリーをリリースや要求種別を軸に並べて各リリースの内容を考えることが提案されました。これらの方法により、開発者ではないプロダクトオーナーが自分の理解できる言葉で要求を表現したり、それらについて開発者と会話したり、リリース計画の計画策定に参加したりすることが可能になったのです。スクラムとユーザーストーリーの組み合わせにおける課題ただ、これらはユーザーストーリーの表現形式やそれを検討する過程を3段階で発展させ、さらに計画と結びつけた方がよいということについて優れたアドバイスではあるものの、ユーザーストーリーをどのように考案するのかという具体的な方法を示すものではありません。具体的な方法が示されてもその方法によりプロダクトオーナーが単独でユーザーストーリーの考案や優先順位付けを実際に行えるのかという問題もあります。ユーザーストーリーはソフトウェアの機能的な要求しか表現しておらず、データや品質特性、環境などプロダクト開発に関係するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することには役不足です。言いかえれば、従来開発の分析に相当する作業が入りこむ余地があまりないのです。確かに従来開発の分析作業はある程度の専門性が求められ、時間もかかるし、文章を中心とした成果物を作るという点でもアジャイル開発とは相いれないものと思われるかもしれません。業務システムのように多数の利害関係者が関与するプロダクトに対するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することが求められる場合も多いのです。Consulting社のエレン・ゴッテスディーナーさんとメアリー・ゴーマンさんが考案したフレームワークであり、従来開発の分析作業を以下のように変えてアジャイル開発とうまく組み合わせられるものに発展させたものです。いう異なる視点の人々が参加するワークショップを開催して、迅速にニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成する。多様なモデルの活用ワークショップで、ニーズや開発内容を軽量でとっつきやすい様々なモデル(短文記述を含む)により多面的に表現し、理解する。これらは、「プロダクトの7側面」という形でまとめられる。分析者がワークショップのファシリテーターやモデラーの役割を担うことで、プロダクトオーナーの役割を分担する。ここでプロダクトと言っているのは、開発の結果として作成されるものであり、一般消費者が使うソフトウェアやハードウェア製品やクラウドサービスだけではなく、業務システムのように特定の企業の業務を支援するシステムも含みます。行うワークショップを計画/分析セッションと呼びます。DtoDの計画/分析セッションは、複数のリリース(全体ビュー)、次のリリース(事前ビュー)、次の反復(現在ビュー)という3つの計画策期間に対して開催します。先の説明ではスクラムを補うものとしてDtoDを説明してきましたが、DtoDはこれらのセッションの開催のタイミングを調整することで、カンバン(フロー納品)や従来開発(従来納品)の中でも活用することができるのです。・DtoDに基づくアジャイル要求入門DtoDの概要について詳しくは以下の資料をご覧ください。この資料ではDtoDを構成する概念を説明し、さらに、地域リユースオークションサイトを題材にして事前ビューの計画/分析セッションの進め方の概要を説明します。「DtoDに基づくアジャイル要求入門」のWeb版は「オブジェクトの広場」に連載しています。2014)』というDtoDの解説書をお薦めします。当書籍ではDtoDおよび、それらを支援するテクニック群を解説しています。通常の業務アプリ開発に近い例として、ガラス清掃業のためのシステム開発を題材とした事例を掲載しています。合意する方法を2日間で学習できるトレーニングをご用意しています。グループワークで、要求獲得セッションを一通り体験できる内容です。詳細・お申し込みはこちらからオージス総研は1990年代から、反復開発やアジャイル開発に取り組み、大規模アジャイル開発の経験等を通じてノウハウを蓄積してまいりました。アジャイル開発の導入、推進等に関して、お気軽に、お問い合わせください。