「一気に導入」シナリオを実現するOSAM2.0

OGIS Scalable Agile Method（以降、OSAMと略します）2.0はハイブリッドではない形でアジャイル開発を適用するプロジェクトに向けたフレームワークです。アジャイル開発のメリットである「要求の変化に対応しながら開発する」際に生じる課題を解決するために考案しました。要求の変化に対応しつつ高い品質を確保するための手法やフレームワークの組み合わせです。

OSAM2.0は、要求の変化に対応しながら高い品質を確保して開発する際の課題を解決するために考案しました。変化する曖昧な要求をどのように定義すればよいか、反復毎に繰り返される受け入れの労力をどうすれば削減できるか、などの課題に対応します。

OSAM2.0では以下のフレームワークや手法を組み合わせます。
・スクラム
・アジャイル要求（DtoD）
・受け入れテスト駆動開発（A-TDD）
・SAFe（Scaled Agile Framework）

スクラム※＋ユーザーストーリーで足りないもの

スクラムを実行する際、スクラムの中で具体的に規定されていなかったプロダクトバックログ項目を定義する方法として、ユーザーストーリーで表現する方法が登場しました。しかし、スクラムとユーザーストーリーの組み合わせだけでは、要求を定義する上で不十分な点がいくつかあります。ユーザーストーリーの具体的な考案方法が示されていない、ソフトウェアの機能的な要求しか表現しないので非機能面での要求の抜けがある、プロダクトオーナーが単独でユーザーストーリーを考案するのは役割が重い、などです。
そこで、OSAM2.0では次に説明するDtoD（Discover to Deliver）というフレームワークを用いて、スクラムとユーザーストーリーで不十分な点を補うことにしました。

DtoDに基づいて要求（ユーザーストーリー）を検討、合意

DtoDは3つの時間軸とプロダクトの7側面という観点を用いて、プロダクトに対するニーズとその実現スケジュールを利害関係者間で話し合い、合意する、具体的な方法を示したアジャイル要求フレームワークです。

プロダクトの7側面には、ソフトウェアの機能的な要求の視点に加え、データや品質特性、環境と言った、プロダクト開発に関係する視点も含まれています。この7側面という観点を用いて、顧客、業務、技術という異なる視点の人々が参加するワークショップでニーズを多面的に理解して表現し、開発内容を検討して合意を形成します。従来の分析者がワークショップのファシリテーターやモデラーの役割を担って、プロダクトオーナーの役割を分担します。

DtoDによって、これまでプロダクトオーナーの重い負担となっていたプロダクトバックログ（要求）の抽出と優先順位付けを、異なる視点の複数人でワークショップを行うことで分担します。またプロダクトの7側面という観点を用いて要求を多面的に表現することで、要求の抜けや曖昧さが軽減することが期待できます。

さらに受け入れテスト駆動開発（A-TDD）で受け入れ基準の設定と受け入れ労力の削減を実現

受け入れテストとは、顧客がプロダクトを受け入れるかどうかを判断するために行うテストです。プロダクトを利用する側の立場で、プロダクトを用いて達成したいこと（要求）が実現されているかを確認します。開発者はプロダクトを構成するクラスやコンポーネント、また、プロダクトそのもののテストを行いますが、これらは開発者の視点で行うテストで、受け入れテストと視点が異なります。

受け入れテスト駆動開発（A-TDD）とは、受け入れテストを開発の初めに記述し、一部を自動化して繰り返しテストを実行できるようにして開発を進める手法です。以下のような特徴を持ちます。
・受け入れテストは受け入れ側と開発側が共同で、開発の初めに、全員が読める自然言語で書く
・繰り返し検証する必要のある重要な受け入れテストは、自動的に実行できるように自動化する

A-TDDを実施することで以下のメリットを享受することができます。

・受け入れテストを開発の早い段階から書くことにより、要求に対する受け入れ側と開発側の理解のギャップを早期に発見できる
・受け入れ側と開発側の全員が読める自然言語で受け入れテストを書くことにより、要求の妥当性が確認しやすくなる
・受け入れテストを書くことで受け入れ基準が明確に設定できる
・受け入れテストの自動化により、繰り返し、継続した検証が可能となる

自動化することだけが目的ではなく、受け入れ側と開発側の理解の違いや要求の妥当性を早期に発見する、という点も重要な狙いです。

また、A-TDDを導入する場合は通常の開発コストに加えてA-TDDを実施するコストがかかります。OSAM2.0では以下の指針を挙げて、A-TDDのメリットを享受しつつ、コストを抑えてA-TDDを実施することを目指します。

・A-TDDの実施対象は重要なビジネスロジックにフォーカスする
・受け入れテスト自動化の対象は、重要かつ繰り返し検証する必要のあるものとする

OSAM2.0で提案しているようにDtoDとA-TDDを組み合わせる場合は、DtoDで受け入れを行うためのシナリオやデータ例を「前提－場合－結果（GWT）」を用いて記述しますが、これがA-TDDの受け入れテストとなります。

大規模なアジャイル開発にはSAFe（Scaled Agile Framework）を組み合わせる

SAFeは、企業や事業部レベルでアジャイルのプラクティスを適用するために実証され、公開されたフレークワークです。複数のチームの編成が必要となるような、企業や事業部レベルの大規模なアジャイル開発を実行するときにSAFeを取り入れることを提案します。

SAFeでは、以下の3つのレベルを通じて企業や事業部全体が一体となって開発を進めることを提唱しています。

・ポートフォリオレベル：プロダクト等の企画を評価、審査する
・プログラムレベル：複数チームが連携してプロダクトのリリースを開発する
・チームレベル：1つのチームがプロダクトの自チーム担当部分を開発する

ここで、プログラムレベルとは複数チームで構成される大規模な開発体制のことを意味し、5～10チーム程度（開発者が50～100名程度）の規模を想定しています。SAFeのプログラムレベルは複数チームを連携させるための仕組みを取り入れていますが、この仕組みはスクラムを比較的自然にスケールさせたイベントや役割で構成されており、チームレベルでのスクラムの良さである自律性や自己管理を活かす形でスケールアップしています。

OSAM2.0基本形と発展形

OSAM2.0では、スクラム、アジャイル要求（DtoD）、受け入れテスト駆動開発（A-TDD）を基本形と呼び、基本形にSAFeを加えたものを発展形と呼びます。

OSAM2.0発展形では、SAFeのチームレベルやプログラムレベルでのイベント、役割、プラクティスなどを取り入れることで複数のチームによる開発を実現します。

※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。