オブジェクトの広場は株式会社オージス総研グループのエンジニアによる技術発表サイトです

アジャイル

OGIS Scalable Agile Method 2.0入門 第2回

スクラム、ユーザーストーリーとそれらを補うOGIS Scalable Agile Method 2.0
株式会社オージス総研 技術部アジャイル開発センター 藤井 拓
2016年1月14日

本記事では、アジャイル開発のフレームワークとして最も普及しているスクラムの概要とスクラムのプロダクトバックログ項目として用いられるユーザーストーリーという要望の表現方法の概要を説明する。次に、これらスクラムとユーザーストーリーとの組み合わせの不十分点について説明する。最後に、スクラムとユーザーストーリーとの組み合わせの不十分点をDtoD (Discover to Deliver) [1]、受け入れテスト駆動開発(A-TDD)、SAFe (Scaled Agile Framework)[2]で補うというOGIS Scalable Agle Method 2.0(以降、OSAM2.0と略す)の基本コンセプトを説明する。

スクラムとユーザーストーリー

2001年にアジャイル開発宣言が起草されて以来14年が経過し、欧米ではアジャイル開発が当たり前になりつつある。そのようなアジャイル開発の普及に大きく貢献したのが「アジャイル開発のミニマムセット」と呼ばれる「スクラム」[3] というコンパクトなアジャイル開発フレームワークである。「スクラム」は、単純化すると以下の4つの特徴を持つ。

スクラムの開発の流れ

  1. スプリントという一定の期間毎に動くソフトウェアを作る
  2. 要求はプロダクトバックログという優先順位付けされた一覧表に保管される
  3. 各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する
  4. スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行う

1.のように一定期間毎に動くソフトウェアを作ることを本記事では時間枠(タイムボックス)納品と呼ぶ。

スクラムは、優先順位付けされたバックログ項目の優先順位順に動くソフトウェアを作り、作成されたソフトウェアを評価する形で開発を進めることに可能にした。その結果、開発依頼者や市場のニーズに即したソフトウェア(プロダクト)をすばやく開発することが可能になった。この利点がスクラムの普及の大きな原動力となったのである。

その一方で、スクラムはコンパクトなアジャイル開発フレームワークとして誕生したために以下のようなことの具体的な実行方法が当初提示されていなかった。

  1. プロダクトバックログ項目の表現形式
  2. プロダクトバックログ項目の定義プロセス

これらについては、スクラムが発展する過程で、XP(eXtreme Programming) [4] というアジャイル手法の考え方を取り入れて 1. として下図に示すようなユーザーの声形式の「ユーザーストーリー」を用いることや、2. として Ron Jefferies の 3C (カード、会話、確認)の3段階でユーザーストーリーを発展させる方法が提案された。

ユーザーストーリー(ユーザーの声形式)

  • カード:1 枚の情報カードにユーザーストーリーを書き記す
  • 会話:カードは、ユーザーストーリーの詳細をさらに会話する約束を表す
  • 確認:カードに記されたユーザーストーリーが完了したかどうかの判断のための受け入れ基準を設定する

さらに、ユーザーストーリーマッピングという手法が登場し、ユーザーストーリーをリリースや要求種別を軸に並べて各リリースの内容を考えることが提案された。これらの方法により、開発者ではないプロダクトオーナーが自分の理解できる言葉で要求を表現したり、それらについて開発者と会話したり、リリース計画の計画策定に参加したりすることが可能になった。

ただ、これらはユーザーストーリーの表現形式やそれを検討する過程を3段階で発展させ、さらに計画と結びつけた方がよいということについて優れたアドバイスではあるものの、ユーザーストーリーをどのように考案するのかという具体的な方法を示すものではなかった。また、具体的な方法が示されてもその方法によりプロダクトオーナーが単独でユーザーストーリーの考案や優先順位付けを実際に行えるのかという問題もあった。

また、ユーザーストーリーはソフトウェアの機能的な要求しか表現しておらず、データや品質特性、環境などプロダクト開発に関係するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することには力不足である。言いかえれば、従来開発の分析に相当する作業が入りこむ余地があまりないのである。確かに従来開発の分析作業はある程度の専門性が求められ、時間もかかるし、文章を中心とした成果物を作るという点でもアジャイル開発とは相いれないものと思われるかもしれない。しかし、業務システムのように多数の利害関係者が関与するプロダクトに対するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することが求められる場合も多いだろう。

前節まで読まれた方は、本節で「要求」という言葉が登場したことに戸惑われたかもしれない。本記事では、「要求」をシステム/プロダクトが満足すべきことを仕様書よりも抽象度の高い形で表現するものという意味で用いる。また、そのような要求を満足しているかどうかの判断は開発されたシステム/プロダクトの受け入れテストに基づいて行われると考える。

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

前節で説明したスクラムとユーザーストーリーとの組み合わせで規定されていないことは以下のとおりである。

  1. プロダクトバックログの項目をどのように定義するか
  2. プロダクトバックログに対応して作成されたものをどのように受け入れるか

A は、前回の記事の「OSAM2.0を考えた動機」の節で課題に挙げた「イ)軽量で開発依頼者にも定義しやすい形でどのように要求を表現するか」と「ロ) 軽量で定義しやすい要求表現に内在しうる矛盾、抜け、あいまいさ等をどのようにすばやく解決するか」に対応する。B の受け入れ方法には、「ハ) 要求に基づいて実装された動くソフトウェアの受け入れ基準の設定」と、「ニ) 反復毎に実行される受け入れの労力の削減」という課題が含まれる。

さらに、スクラムを実践する上で以下のような点が課題になることも多いだろう。

  1. プロダクトオーナーの役割が重すぎる

また、「従来手法の問題点」の「開発要件を精緻に文書化すべきか否か」の節で挙げた以下のような課題もある。

  1. 仕様が暗黙知化し、開発者の理解の違いで仕様の不整合や仕様の抜けが発生するのを如何に防ぐか
  2. プロダクトの最低限の品質をどう確保するか

E を考える上で、一般的に以下の2種類の要求を出発点とする。

  • 業務要求:ビジネスルール等の業務を行う上で本来的に満たすべきこと
  • システム要求:画面レイアウト等の業務要求に対応するプロダクトが満たすべきこと

システム要求は、さらに以下のように分類できる。

  • 機能要求
  • 非機能要求

さらに、要求が満足されているかどうかの確認作業はこれらの要求種別に対応して以下のように述べられる。

  • 業務要求 → 妥当性確認
  • システム要求 → 検証

本文書では、妥当性確認を行うためのテストを「受け入れテスト」と呼ぶ。

また、検証を実行するためのテストは要求の種類やシステムの構造に基づいて複数存在する。

  • 機能要求 → 機能テスト等
  • 非機能要求 → 性能テスト等

品質を確保するためにまず大事なのは、以下の点である。

  • 開発したシステムやプロダクトが業務要求やシステム要求を満足しているかを確かめるテストを考える

言い換えれば、ユーザーストーリーのような要求から如何にしてテストを考えるかということがまず大きな課題になる。

次に、アジャイル開発の場合に機能の開発が終わってから、システム/プロダクトのリリースを迅速に行うためには以下のような原則を守ることが大事である。

  • スプリント(反復)毎に開発したものの品質を確保する

これを実行するためには、アジャイル開発で発生する開発途上のスコープ変動やすでに開発した部分に対する要求変化に対応するための以下の点が課題になる。

  1. スコープの変動に合わせてテストを開発する必要がある
  2. デグレードを早期に発見し、修正する必要がある

また、1 に付随して「OSAM2.0を考えた動機」の節で課題に挙げた「ニ) 反復毎に実行される受け入れの労力の削減」する必要が生じる。

最後に、開発を委託する側の立場の人の関心事として、さらに以下のようなことも気になるだろう。

  • プロダクトのドキュメントをどうするか
  • リリースの見通しをどのように検討すべきか

リリースというのは重要なマイルストーンであるが、リリースの内容をユーザーストーリーのような形式で表現した場合にそこに内在するシステム要求の複雑さや難易度を想像して見積もりを行うのは難しい。

その一方で、アジャイル開発においてリリース毎に提供する価値をある程度計画し、その計画を達成することが最低限の規範となる。つまりリリースで計画した機能を「概ね」提供するということが最低限守るべきことになり、そのリリースでどれくらいの価値を提供できたのかということが問われる。

最後に、観点がまったく変わるがプロジェクトの規模の拡大に対する対応についても考える必要がある。スクラムが想定しているのは前述した7±2名のメンバーから成るチームであり、スクラムの開発の進め方を活かした形でより多くのメンバーが必要な開発をどう進めるかという点も解決しなければならない。これが「OSAM2.0を考えた動機」の節で上げた「ホ) 自己管理や自己組織化というチームの連携を活かしたスケールアップ」である。

OSAM2.0の基本コンセプト

「OSAM2.0を考えた動機」の節での説明とも重複するが、OSAM2.0の基本コンセプトは前節で述べた課題を以下の2つの方法で解決するというものである。

  1. スクラム+ユーザーストーリーをDtoD+A-TDDで補う
  2. SAFeにより1を複数チームの体制で実践したり、企業や事業部の戦略と連携することを可能にする

1 をOSAM2.0の基本形と呼び、2 をOSAM2.0の発展形と呼ぶ。

以下がOSAM2.0の基本形における開発の進め方を図示したものである。

OSAM2.0基本形の開発の流れ

前節で挙げた課題をそれらの解決策としてのDtoD、A-TDD、SAFeの対応関係を表にまとめると以下のようになる。なお、SAFeについては「複数チームが構成される開発体制」を前提とした解決策になる点に注意して頂きたい。

課題DtoDA-TDDSAFe
A. プロダクトバックログの項目をどのように定義するか
B. プロダクトバックログに対応して作成されたものをどのように受け入れるか○(入力)
C. 仕様が暗黙知化し、開発者の理解の違いで仕様の不整合や仕様の抜けが発生するのを如何に防ぐか
D. リリースの見通しに関してどのように検討すべきか
E. プロダクトのドキュメントをどうするか○(入力)
F. プロダクトの最低限の品質をどう確保するか
G. プロダクトオーナーの役割が重すぎる

この表で「入力」とは、課題を解決するための「入力」になり得ることを意味する。

第 2 回の終わりに

本記事では、アジャイル開発のフレームワークとして最も普及しているスクラムの概要とスクラムのプロダクトバックログ項目として用いられるユーザーストーリーという要望の表現方法の概要を説明し、これらスクラムとユーザーストーリーとの組み合わせの不十分点について説明した。さらに、スクラムとユーザーストーリーとの組み合わせの不十分点をDtoD、 A-TDD、SAFeで補うというOSAM2.0の基本コンセプトを説明した。

次回の記事では、OSAM2.0の構成要素の1つであるDtoDの概要を説明する。

参考文献

[1] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプロダクトの計画策定と分析, BookWay, 2014
[2] Dean Leffingwell, アジャイルソフトウェア要求―チーム、プログラム、企業のためのリーンな要求プラクティス, 翔泳社, 2014
[3] ケン・シュエイバー, マイク・ビードル, アジャイルソフトウェア開発スクラム, ピアソンエデュケーション,4 2003
[4] ケント・ベック, XPエクストリーム・プログラミング入門―変化を受け入れる, ピアソンエデュケーション, 2005