ObjectSquare [ 2014 年 2 月号]

[オージス総研の本]


アジャイルソフトウェア要求

アジャイルソフトウェア要求
チーム、プログラム、企業のためのリーンな要求プラクティス


Dean Leffingwell 著
藤井拓 監訳、株式会社オージス総研 訳
翔泳社 \5,200 + 税
変形B5版 445 ページ
ISBN: 9784798135328

目次 目次
本書の解説 本書の解説
本書の内容 本書の内容

目次

第 I 部 概観:全体像

第 II 部 チームのためのアジャイル要求
第 III 部 プログラムのためのアジャイル要求
第 IV 部 ポートフォリオのためのアジャイル要求

TOP ページのトップへ戻る

本書の解説

2001年にアジャイル開発の心得をまとめたアジャイル宣言が起草され、アジャイル開発が一躍表舞台へと躍り出ました。それから12年が経過し、欧米ではアジャイル開発はもはや新し物好きの技術者集団が好む開発手法ではなく、一般的に使われる開発手法の主流になろうとしています。この一般化する流れの中で、アジャイル開発が適用するシステムは大規模化したり、企業や事業部の標準的な開発手法としてアジャイル開発を採用する企業が増えてきています。

しかし、翻って日本の現状を見ると「要求が変化したり、不確定であるという特殊な状況に特化した小規模開発向けの手法」という印象がまだまだ多いというのが現実でしょう。ただ、日本でもeコマース、ゲーム開発、クラウドなどのソフトウェアの比重が高いビジネス、プロダクト、サービス分野では「要求が変化したり、不確定である」状況は当たり前になってきており、それが今後さらに様々な分野に広がっていくと期待できます。

本書は、「変化したり、不確定な要求に対応して開発を行う」というアジャイル開発の強みや特長を土台にして、企業や事業部の競争力を高めたり、大規模開発を行うための手法を解説するものです。この手法は、本書の刊行後にScaled Agile Framework (SAFe)と名付けられました。SAFeの大きな特徴は、以下の2点です。

以降、煩雑なので「プロダクト(システム)」を「プロダクト」と呼びます。

まず、SAFeの土台となるのがアジャイル開発です。プロジェクト管理面ではスクラムというフレームワークを用いることにより変化に対応して開発を行い、その際にコード品質を確保するためにXP (eXtreme Programming) の技術的なプラクティスを用いることを推奨しています。SAFeでは、大規模プロジェクトにスケールアップするためにいくつかの役割、作業、成果物を追加していますが、それらがスクラムを自然に拡張したものになっているという点が大きな特徴の1つになっています。

リーン思考とは、「注文を受けてから納品するまでの間で発生する、価値の創造に結び付かない時間を短縮する」ことを旨とする考え方でトヨタ生産方式 (TPS) を起源とするものです。本書の中で、プロダクト開発の一連の作業を「価値のストリーム」と捉え、これを継続的に改善することがリーンでアジャイルな企業のゴールであり、管理者をこれらの改善活動の推進役として位置付けています。

プロダクト開発フローは待ち行列理論と経済性を中心に、TPS やアジャイル開発の考え方を統合し、プロダクト開発を成功させるための数多くの原則にまとめたものです。プロダクト開発フローでは、8つのテーマを中心に原則が体系化されていますが、本書を通じてこれら8つのテーマがSAFeを裏付ける大きな柱となっています。

次にSAFeの全体像を説明します。SAFeを構成する3つのレベルは、以下のようなものです。

ここで言う「プログラム」とは、複数のチームで構成されるような大規模プロジェクトのことです。

これらのレベルを通じて、SAFeが実現しようとしているのは以下の4つの価値です。

3つのレベルでの取り組みにより、これらの4つの価値をどのように実現すればよいかを解説するというのが本書の中心的なテーマです。さらに、これらの取り組みをつなげる縦糸がエピック、ビジョン、フィーチャー、ユーザーストーリーで構成される「アジャイルソフトウェア要求」なのです。ソフトウェア要求は、著者Leffingwell氏のもっとも得意とする専門分野であり、本書ではアジャイルソフトウェア要求を生むためのプロセス、役割、モデリング手法、見積もり方法、さらには要求が実現されていることを開発途上で早期に検証する受け入れテスト駆動開発という広範な話題がカバーされています。

SAFeの構成要素の説明や事例はSAFe日本語サイトというサイトでも一般向けに提供されています。本書の内容を組織内で共有したり、SAFeに関する最新の情報を入手するためにこのサイトをご活用されることをお勧めします。

本書の内容

本記事の冒頭の目次に示されたように本書は、4 部で構成されています。これら 4 部の概要を以下に紹介します。

第 I 部 概観:全体像

まず、ウォーターフォール開発の起源からアジャイル開発までの開発手法の発展の歴史を説明し、それらの両者の大きな違いは「スコープ」を固定するか、「納期、予算」を固定するかの違いであり、さらに動くソフトウェアの市場への投入時間の違いから投資の回収における違いも生じることを説明しています。

次に、アジャイルなプロダクト開発を支える思想的なバックボーンを説明しています。まず、アジャイル開発についてはアジャイル宣言、スクラムとXPの概要を説明し、チームを超えて企業で共有できる理念としてリーン思考(リーンソフトウェアの殿堂)を位置づけます。さらに、リーン思考とアジャイル開発の考え方を統合する枠組みとしてプロダクト開発フローをその 8 つのテーマにより紹介しています。

さらに、本書を通じたテーマであるアジャイルソフトウェア要求によりプロダクト開発を行う企業の全体像を紹介し、その全体像を構成する 3 つのレベルの概要を説明しています。

最後に、本書を通じて用いるテンドリル・プラットホームというスマートエネルギー管理システムの事例を紹介しています。

第 II 部 チームのためのアジャイル要求

まず、チームレベルでの「要求」の表現であるユーザーストーリーの記述形式やINVESTという良いユーザーストーリーを書くための留意点を説明し、さらに技術的な調査を表現するためのスパイクという概念を説明しています。

次に、ユーザーストーリーの見積もり方法であるプランニングポーカーの手順や演習を紹介し、さらにプランニングポーカーよりもさらに簡略な机上での見積もり方法を紹介します。また、アジャイルで一般的な相対見積もりと、従来の時間での見積もりとの比較を行い、それらの両方の利点を取り入れたハイブリッド見積もりを提案しています。

さらに、反復による開発の進め方を説明しています。この開発の進め方は、ほぼスクラムに準じたものになっています。続いて、バックログの長さを短く保つべきかという議論から待ち行列理論のリトルの法則を用いて要求がバックログに入ってからそれが実装されるまでのサイクル時間を短くするためのいくつかの選択肢を論じています。このサイクル時間を短縮することはスループットを高くすることに対応するのですが、それを実現するための手段として仕掛かり作業(WIP)数を制限するカンバンシステムが紹介されています。

また、受け入れテストを始めとするテストの自動化とユーザーストーリーの関係について説明し、ビジネス向けと技術向けというプロダクトオーナーの2つの役割や優れたプロダクトオーナーが持つ5つの基本的な特質を説明しています。さらに、いくつかの企業においてプロダクトオーナーを養成(確保)した方法を紹介しています。

最後に、要求の元となるアイデアを発想し、絞り込む手段として要求ワークショップ、ブレーンストーミングを紹介するとともに、伝統的な手法であるインタビューを紹介しています。

第 III 部 プログラムのためのアジャイル要求

まず、プログラムレベルで要求を表現するために用いるビジョン、フィーチャー、ロードマップについて説明しています。フィーチャーは、ユーザーストーリーよりも大きな粒度で要求を表現するものであり、プログラムレベルのバックログの項目になります。さらにフィーチャーの見積もりやプロダクト開発フローの考え方に基づくフィーチャーの優先順位付けの方法を提案しています。

次に、ビジョン、フィーチャー、ロードマップを考えるプロダクト管理者という役割を導入します。さらに、このプロダクト管理者が従来のどの役割に対応し、従来のプロダクト管理からアジャイルなプロダクト管理への移行について説明しています。

さらに、プログラムレベルでの開発を推進するために複数チームが連携して開発するための枠組みであるアジャイルリリース列車に 1 章を割いて説明しています。そこでは、1 つのリリースあるいは潜在的な出荷可能なインクリメント (PSI) に対してアジャイルリリース列車でどのように計画を策定し、実行するのかという概略と、それらのリリースや PSI と外部リリースとの関係について説明しています。さらに、リリース計画策定についても 1 つの章を割り当てて計画策定の準備作業、2 日間の計画策定を実行するためのアジェンダの見本とともに実行方法が詳しく解説されています。

次に、非機能要求の取り扱いについて説明するとともに、フィーチャーやユーザーストーリーで記述が困難な複雑の要求分析テクニックとしてアクティビティー図等が簡単に紹介されています。これらの要求分析テクニックの中でもユースケースは、1章を当ててその概要を説明しています。

第 IV 部 ポートフォリオのためのアジャイル要求

まず、アジャイル開発ではあまり語られないアーキテクチャーの位置づけの説明から始まります。本書では、大規模な開発ではアーキテクチャーが自然に現れると考えるのは大きなリスクであり、実装を通じてアーキテクチャーが確定するということを認めつつも、先行してアーキテクチャーをある程度考えるべきだと論じています。また、そのような観点でアジャイル開発でアーキテクチャーを構築するための 8 つの原則を提案しています。それらの原則の中で最後のものである「フローによるアーキテクチャーの再設計」には 1 章を割り当てており、複数のプロダクトやアジャイルリリース列車を横断する共通のインフラやガイダンスを表すアーキテクチャーエピックという大きな開発上の取り組みを段階的に企画し、審査するためのアーキテクチャーエピックのカンバン方式というものを提案しています。

次に、アジャイルなプログラムポートフォリオ管理という企業や事業部全体でのプログラムを管理する方法について説明しています。本書では、従来この役割を担ってきたプロジェクトマネジメントオフィス (PMO) と対立するのではなく、アジャイルチームやプログラムの成功に PMO の専門的な技能や知識を活かすべきと述べています。そのために、従来のやり方からアジャイルに移行するための 8 つの提案を説明しています。

最後に、企業や事業部レベルで各プロダクト分野の予算枠を決定するための投資テーマやその投資テーマの予算に基づいて開発を行うプロダクトの企画であるビジネスエピックを説明しています。ビジネスエピックについては、アーキテクチャーエピックと同様にカンバン方式を用いて企画の段階的に詳細化し、審査することを提案しています。

TOP ページのトップへ戻る

アジャイルソフトウェア要求 読者プレゼント

今回特別に『アジャイルソフトウェア要求』を抽選で 1 名の方に読者プレゼントいたします。

締め切りは、2014 年 2 月 26 日(水)です。当選者の発表はご本人宛にメールにてお知らせいたします。

【個人情報の取り扱いについて】
ご応募で頂いた個人情報につきましては、本件「アジャイルソフトウェア要求 読者プレゼント 」プレゼントのご連絡のみに使用いたします。 お客様の個人情報は、当社の個人情報保護方針に基づき、適切にお取り扱いいたします。 また、ご本人の承諾なしに、第三者機関へ提供することはありません。

プレゼントの応募は締め切らせていただきました。
たくさんのご応募ありがとうございました。
抽選の結果、当選された方には 2/27 に案内メールをお送りいたします。
(2014/02/27)

記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。

© 2014 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP