オージス総研が考えるアジャイル開発のベストプラクティス

オージス総研が考えるアジャイル開発のベストプラクティスOGIS Scalable Agile Methodをご紹介します

Contents

アジャイル開発フレームワークOGIS Scalable Agile Method(OSAM)

OGIS Scalable Agile Method(以降、OSAMと略します) は、ユーザー企業とSI企業に分かれた日本産業構造においてアジャイル開発を適用する課題を考慮し、それらの課題の解決策としてオージス総研が考案したアジャイル開発フレームワークです。

OSAMにはOSAM1.0とOSAM2.0の二つのバージョンが存在します。どちらか一方のバージョンを推奨するというものではなく、アジャイルに取り組むプロジェクトの状況や優先する内容によって適したバージョンを選択すればよいと考えています。

OSAM1.0

OSAM1.0は従来手法から一歩ずつアジャイル開発に移行したいプロジェクトに適したフレームワークです。アジャイルUPのプロジェクト管理作業分野の作業を進める際に、スクラムの開発の進め方を取り入れます。アジャイルUPで定義された作業や成果物を参考にすることもでき、従来手法に慣れたメンバーが初めてアジャイル開発をする場合も取り組みやすい組み合わせと言えます。フェーズと反復で構成されるハイブリッドアジャイルの一種です。
OSAM1.0の概要はこちらをご覧ください。

OSAM2.0

OSAM2.0はハイブリッドではない形でアジャイル開発を適用するプロジェクトに向けたフレームワークです。アジャイル開発のメリットである「要求の変化に対応しながら開発する」際に生じる課題を解決するために考案しました。要求の変化に対応しつつ高い品質を確保するための手法やフレームワークの組み合わせです。
OSAM2.0の概要はこちらをご覧ください。

ページトップへ戻る

OSAM1.0|従来手法とのギャップを懸念するプロジェクト向け

OSAM1.0は、従来手法とのギャップがそれほど大きくなく、アジャイル開発に不安がある組織が最初に取り入むのに適したフレームワークです。

”お客様と開発者がより良いパートナーとして連携し、限られた時間と予算の枠内で、要求の変化への対応と技術的なリスクの管理を行いながらお客様のビジネスに役立ち、かつ高品質なソフトウェアを早く開発すること”を目標とし、この目標を達成するためOSAM1.0は以下の二つの要素で構成しています。

スクラムとアジャイルUPを組み合わせた開発手法
機能規模測定手法COSMIC法に基づく測定

スクラムとアジャイルUPの組み合わせで反復に慣れる

アジャイルUPはアジャイル開発の技術プラクティスを取り入れてUP(Unified Process)をアジャイル化した開発プロセスフレームワークで、Scott Ambler氏が考案したものです。
OSAM1.0ではアジャイルUPのプロジェクト管理作業分野の作業を進める際に、スクラムの開発の進め方を取り入れることを提案しています。アジャイルUPで定義された作業や成果物を参考にすることもでき、従来手法に慣れたメンバーが初めてアジャイル開発をする場合も取り組みやすいと言えます。

測定に基づいた契約、見積もりと改善

機能規模測定手法COSMIC法に基づく測定を行うことにより、見積もりや契約でのスコープ管理に活用したり、開発生産性などから開発をモニタリングして必要に応じて開発方法を改善したりすることができます。


OSAM1.0の詳細は「オージス総研アジャイル白書」の「第3部:OGIS Scalable Agile Methodの神髄」 をご覧ください。

OSAM2.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のチームレベルやプログラムレベルでのイベント、役割、プラクティスなどを取り入れることで複数のチームによる開発を実現します。

OSAM2.0の詳細は「OGIS Scalable Agile Method 2.0入門」をご覧ください。

>>次ページ:OGIS Scalable Agile Methodが提案するアジャイル導入の移行シナリオ

ページトップへ戻る

お問い合わせ

お問い合わせ

アジャイル開発に関するお問い合わせはこちら