目次
はじめに
前編では、開発プロセス設計のうち、図３の２番目のソフトウェア開発ライフサイクルを決めるところまで説明しました。後編では、ここで決めたライフサイクルに基づいてソフトウェアプロセスを決め、ソフトウェアプロセスの各活動、成果物をテーラリングする考え方について説明します。
また、設計したプロセスの実装及び改善方法、並びに、アジャイル開発において重要なマインドセットの位置づけについても簡単に触れます。
③ソフトウェアプロセスを決める
ソフトウェアプロセスでは、基本的には、以下を決定します。
- ソフトウェア開発ライフサイクルの各フェーズで当該フェーズのゴールを達成するために、どのプロセス／活動をどの順番で行うか
- 各活動についての詳細（誰が行うか、入出力成果物は何か、どのように行うか等）
プロジェクトやプロダクトの特性に合わせて開発プロセスを適応させることをテーラリングと呼びます。ソフトウェア開発ライフサイクルを決める時点で既存のライフサイクルモデルを採用、または、ライフサイクルモデルだけでなく、スクラム等のプロセスフレームワークを選択している場合は、１についてはほぼ決まり、２がテーラリングの主な対象となります。
スクラムのライフサイクル
例として、スクラムを採用した場合の、ライフサイクルを図５に示します。
図５：スクラムのライフサイクル
各スプリントのゴールは図５のようになるので、各スプリントで実施するソフトウェアプロセスは以下のようになります。
- スプリント０
- 主に要求プロセスを実施し、プロダクトバックログを作成する
- スプリント１〜N
- 要求、設計、構築、テストプロセスを実施し、対象部分のインクリメントを作成してリリースする
活動、成果物のテーラリング
以下では、要求プロセスを例に、テーラリングの例を示します。
要求プロセスで実施すべき活動とそこでの主な実施事項は、以下のとおりです。
- 要求の抽出
- ユーザ要求を漏れなく抽出し、利害関係者と合意します
- 要求の分析
- ユーザ要求を理解し、詳細な定義を与えます
- 要求間の競合や不整合を検出して解決します
- 要求を様々な観点（機能／非機能、優先度等）でクラス分けします
- 要求の仕様化
- 要求を文書化します
- 妥当性の確認
- 対象が利害関係者のニーズ、要求を満たしていることを確認します
活動のテーラリングでは、これらについて実施有無、実施方法等を決めていきます。
テーラリングの詳細に入る前に、まず、要求の種類と構造を整理しておきます。
ここでは、文献「ソフトウェア要求」の分類の仕方から抜粋して説明します。
図６：要求の種類と構造
図６で、楕円は要求情報の種類を表し、長方形はその情報を格納する成果物を示しています。実線の矢印は、特定の情報が示された成果物内に格納されることが一般的であることを示しています。点線の矢印は、ある情報が別の情報の発生源である、または別の情報に影響を与えることを示しています。格納場所として「〜文書」とありますが、必ずしも紙文書である必要はなく、要求管理ツール等でも構いません。
- ビジネス要求
組織／顧客がそのシステムを作る理由、つまり組織が達成したいと望むビジネス上の利益、解決したい課題やニーズを表します。
（例）空港カウンター担当者のコストを25％削減したい - ユーザ要求
ユーザが実行できなければならない目標や仕事を表します。
（例）フライトにチェックインする - 機能要求
特定の条件下でプロダクトが示す振る舞いを表します。開発者がプロダクトに作り込むのはこの要求になります。 - 品質属性
ユーザ、開発者、保守担当者等にとって重要なプロダクトの特性を記述したものです。性能、安全性、可用性、移植性等があります。非機能要求の一部として分類されることもあります。
要求の分類方法や呼び方は、書籍、方法論等によって異なりますが、表現すべき概念の本質に大きな違いはありません。
ユーザ要求は、外部からの視点でプロダクトのユーザがプロダクトを使って行いたいことで、それを実現するためにプロダクト自身が持つべき機能が機能要求として表現されます。開発者が開発すべき項目は、ユーザ要求そのものではなく機能要求であることに注意して下さい。
開発プロセスで上記のような要求や成果物をどのように導出し、どのように表現するかも、プロセステーラリングの一部です。テーラリングの例を以下に示します（カッコ内は、その要求を格納する成果物です）
テーラリング−１では、以下のように要求プロセスは実施されます。
- ビジネス要求は、ビジネス目標、成功判定条件等の形式でビジョン／スコープ記述書に記載されます。
- プロダクトの利用シナリオを調べたり、利害関係者からとの話合いにより、ユーザ要求としてプロダクトのユースケースを洗い出します。
- ユースケースシナリオを分析してプロダクトとの境界の相互作用を明らかにすることにより、機能や非機能を見つけて要求仕様書としてまとめます。
テーラリングー２は、アジャイル開発プロセスでの進め方の一例です。
- ビジネス要求は、エレベータピッチの形式で記載され、インセプションデッキの一部として格納されます。
- プロダクトの利用シナリオを調べたり、利害関係者との話合いにより、ユーザ要求に対応するユーザストーリーや品質ストーリーを抽出します。
- 利害関係者との話合いを通じてユーザストーリーを詳細化していくことで、個々の機能を表現するより小さく凝集されたストーリー（詳細化ユーザストーリー）を見つけます。
- 要求仕様書は作成せず、抽出したストーリーは、プロダクトバックログに格納して管理します。
以下、用語について説明します。
インセプションデッキは、アジャイル開発でよく用いられる、プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメントで、１０の質問に答える形で記述されます。インセプションデッキの詳細はこちらを参照して下さい。
エレベータピッチは、インセプションデッキの一部として、プロダクトが対象とする顧客、プロダクトが解決する課題やニーズ等を簡潔に記載したものです。
ユーザストーリーは、新しい能力を望む人の観点から、ユーザ要求を簡潔に記述したもので、以下の形式で記載します。
＜ユーザの種類＞として、＜達成したいゴール＞をしたい、なぜなら＜理由＞だからだ
（例）フライトにチェックインする
➔ ＜旅行者＞として、＜フライトにチェックイン＞したい、なぜなら＜目的地まで飛行したい＞からだ
品質ストーリーは、「品質特定のパターン」の中で紹介されているもので、リリースで提供する必要のあるシステムの品質特性を特定し、ストーリーとして表現したものです。
プロダクトバックログとは、スクラムの成果物であり、プロダクトで実現したいことを優先順位を付けて一覧にしたものです。ユーザストーリー以外にも機能の追加や修正、設計課題なども含まれます。
ここまで、ソフトウェアプロセスと活動及び成果物のテーラリングの例をお話してきましたが、最後に、スクラムを使用した場合に、各ソフトウェアプロセスをテーラリングして開発プロセスを設計した例の簡易版をこれまでの記載と重複するところもありますが、まとめて表に表します。あくまで、開発プロセス設計のイメージを掴んで頂くためのもので、記述は簡易化しています。また、要求プロセス以外については、記載していませんが、実際には、設計、構築、テストなどのプロセスもテーラリングする必要があります。
表内のPOは、スクラムにおいてプロダクトの価値の最大化に責任を持つ、プロダクトオーナーを示します。
スクラムを使用した場合に、各ソフトウェアプロセスをテーラリングして開発プロセスを設計した例の簡易版
開発プロセスのテーラリングを行う際の判断のベースは、前述したように、プロジェクトやプロダクトの特性になりますが、それ以外に、そのライフサイクルモデルにおけるベストプラクティスからも影響を受けます。アジャイルモデルでは、アジャイル宣言やアジャイルの原則も取り入れます。例えば、要求の仕様化において要求の記述はユーザストーリーだけにして要求仕様書を作成しないという選択肢は、ドキュメントよりも顧客とのコミュニケーションを重要視するとか、無駄をなくすというプラクティスに基づいています。
一方、アジャイル開発プロセスに対して、要件定義はしないとか、要求仕様がなくても作れるという誤解があります。当たり前の話ですが、何を作るかが決まっていないと設計、構築はできないので、正しくは要求プロセスは行うが、要求仕様書の形では表現せず、ユーザ要求や機能要求の詳細は、POと開発者のコミュニケーションを通じて両者の頭の中で共有され、スプリント毎に動作するプログラムとして確認されるということです。
また、成果物のテーラリングにおいて、成果物作成の有無、作成する場合は形式も決めますが、成果物によっては、作成タイミングを決める必要もあります。例えば、アーキテクチャ設計書は、開発時は、ホワイトボードに書いた設計図のようなものでもよいですが、保守時は、非常に重要なドキュメントになるので、開発の最後に最終版を文書化するという選択肢もあります。
上記テーラリングの表では、プロダクト全体像を明らかにする部分とプロダクトバックログを作成する部分を両方スプリント０としていますが、前者の何を作るかという部分をDAの方向付けフェーズのように、企画フェーズとして分ける場合もあります。企画フェーズのプロセスについては、「DXキックオフパッケージ」という名称で弊社からも提供されているので、ご興味のある方は、ご覧頂ければと思います。
開発プロセスを実装する
開発プロセスの実装とは、定義したプロセスをプロジェクトメンバーが実際に実施できるようにすることです。具体的には、プロダクトバックログやスプリントバックログを入れるための管理ツールの設定をしたり、CI／CD（継続的インテグレーション／継続的デリバリー）を自動的に実施するための環境を作ったりします。
開発プロセスを改善する
開発プロセスは設計したものを開発中ずっと使うのではなく、実施した際の課題や更にこうした方が良いというアイディアを盛り込み、常に改善していきます。
スクラムでは、スプリントレトロスペクティブの中でこれを実施します。スプリントの中で発生した問題（Problem）や次回以降試したいこと（Try）をメンバーで挙げ、開発プロセスで対応できる部分はプロセスに変更を加え、次回以降のスプリントで適用します。
また、プロセス改善の一つの手段として欠陥分析があります。テストで見つけた欠陥がなぜ発生したのか、どこのやり方を変えれば起きないようにできたのかを分析し、プロセスを改善します。
開発プロセスを超えて
アジャイル開発プロセスでは、プロセスだけでなく、担当者のマインドセットも非常に重要です。アジャイル宣言、アジャイル原則にあるように、顧客を最優先に考えます、変化を歓迎します、意欲に満ちた人々を集めてプロジェクトを構成し、仕事が無事終わるまで彼らを信頼します等、開発プロセスの設計で扱えない事項に対しても非常に大きな配慮が必要です。
おわりに
これまでソフトウェア・エンジニアリングの観点から、アジャイル開発プロセスの設計を行ってきましたが、いかがでしたでしょうか。
ただスクラムを書籍に書いてあるとおりに実施するのでなく、アジャイル開発のイベントやプラクティスがどのような目的で何を行っていることを知ることによりアジャイル開発に対する理解も深まり、プロセステーラリング時にも適切な判断ができるようになります。
■完全版 EBOOKは以下からダウンロード可能です！
コラム：要件定義はフェーズまたはプロセス？
「アジャイル開発なので要件定義はやらない」という話を聞くことがあります。ここで言う「要件定義」とは、フェーズのことを指しているのでしょうか？それとも、プロセスまたは活動のことを指しているのでしょうか？
おそらく前者のことだと思いますが、要件定義で何を作るか決めないと開発は行えないので、正確には、「要件定義は行うが、要件定義フェーズという期間でまとめて行うことはしない」と言うのが適切です。
関係者間の正確なコミュニケーションのためにも、用語に対する定義を合わせておくことが重要です。
参考文献
- ソフトウェア・エンジニアリング基礎知識体系
- スクラム実践入門
- アジャイルサムライ
- ディシプリンド・アジャイル・デリバリー
- ソフトウェア要求
- スクラム現場ガイド
- アジャイル開発とスクラム第２版
- 15th State of Agile Report
- 品質の特定のパターン
- ２０１８年にリリースされた「DXレポート」
- インセプションデッキ
【本記事の執筆者の紹介】
岸俊行
TC3株式会社
Topcoder事業部 プリンシパル・コンサルタント
日本ラショナルソフトウェア及び豆蔵において、１５年以上にわたり反復型開発プロセスの導入のコンサルティングに従事。また、豆蔵では、SWEBOKをベースにしたソフトウェア・エンジニアリング研修の開発も担当。
豆蔵独立後は、個人事業主としてモデリング、要件定義、スクラムのプロダクトオーナー支援等のコンサルティングに従事後、現在は、TC3において、Gigを活用したアジャイル開発プロセス（GigAgile）の開発に携わっている。
ーーー
デジタルサービス開発のポイント＆事例の紹介資料をご確認ください！
顧客向けのサービス開発をアジャイル開発の手法を活用してご支援しています。顧客向けのデジタルサービスを開発する上でのポイントとあわせて、事例をご紹介している資料は以下からダウンロードいただけます。
『デジタル顧客接点トータルサービス』のご紹介資料を含めたウェビナー資料（事例も掲載しています）以下のフォームからご確認いただけます。（フォームが表示されない場合には、こちらからご確認ください）
資料ダウンロードは以下のフォームにご記入ください。
テーラリング−１
テーラリング−２
ビジネス要求
ビジネス要求
（ビジョン／スコープ記述書）
エレベータピッチ
（インセプションデッキ）
ユーザ要求
ユースケース
（要求仕様書）
ユーザストーリー
（プロダクトバックログ）
機能要求
機能仕様
（要求仕様書）
詳細化ユーザストーリー
（プロダクトバックログ）
品質属性
非機能仕様
（要求仕様書）
品質ストーリー
（プロダクトバックログ）
