アジャイル開発における要件定義とは？ 〜DXプロダクト開発における要件定義の理解を深める〜

1. はじめに

前回の「アジャイル開発プロセスの本質」（前編・後編）では、ソフトウェア・エンジニアリングの基本に従いアジャイル開発プロセスを設計していくことにより、アジャイル開発プロセスの進め方、実施する活動、作成する成果物についてなぜそうなっているのかを知り、アジャイル開発プロセスへの理解を深めました。

本記事ではその続編として、DX（デジタルトランスフォーメーション）の文脈におけるプロダクトをアジャイルに開発していくにあたり、特に要求プロセス部分に絞ってソフトウェア・エンジニアリングの基本とアジャイル開発プロセスでの対応をより詳細に解説することで、DXプロダクト開発における要件定義の理解を深めるということを目的としています。

本記事のタイトルにある「要件定義」という言葉はフェーズではなく、要求を決めるまでの活動の分類＝要求プロセスという意味で使っています。この使い方の違いについては、前回の記事のコラムを参照して下さい。

 

2. 要求プロセスにおける概念

2.1 要求と要件

要求プロセスの活動の説明に入る前に、まず、要求の用語の定義と種類及び構造を整理しておきます。

要求の原語である「Requirement」のIEEE（Institute of Electrical and Electronics Engineers）の定義には、もともと2つの意味があります。

 

1. A condition or capability needed by user to solve a problem or achieve an objective.
2. A condition or capability that must be met or processed by a system or system component to satisfy a contract , standard , specification , or other formally imposed

 

１は、目的を達成するためにユーザにより求められる必要な条件や能力であり、２は、システム自体が満たすべき条件や能力を表します。これらの２つの意味を日本語では、「要求」と訳したり、「要件」と訳したりしていることで、少なからず混乱を招いています。すなわち、「要求」や「要件」と言った時に、その示す意味が、組織や個人により異なっているのです。

かと言って、上記１、２について、統一的な日本語訳の定義があるわけではありません。実際、SWEBOK（Software Engineering Body of Knowledge）の日本語訳においても、以下のような使い分けがされているのにとどまります。

 

• ■SWEBOKの用語訳：要求／要件
  初期段階の要求は、曖昧を含む広義な意味を持つので、「要求」と訳し、定義された要求は、その定義度や定義に関わる組織、環境の如何にもよるが、「要件」と訳することがある。「要件」は、主に開発者視点で用いられる。

 

IEEE、SWEBOK以外でも、１と２を表す概念を表す用語は定義されています。そのうち、CMMI（Capability Maturity Model Integration）及び書籍「ソフトウェア要求」の定義を以下に示します。

• ■CMMI：顧客要件／成果物要件
  • □顧客要件：
    顧客が受け入れ可能な形で、成果物の直接の利害関係者のニーズ、期待、制約、およびインタフェースを引き出し、整理統合し、そしてそれらの間の不整合を解決した結果
    必ず顧客の用語で記述され、表記法も顧客やユーザに理解できる表現である必要があります
  • □成果物要件：
    顧客要件を開発者の言葉で精緻化したもの。開発者は、成果物またはサービスの設計と構築を導くために、成果物要件を使用する

 

• ■書籍「ソフトウェア要求」：ユーザ要求／機能要求
  • □ユーザ要求
    ユーザが実行できなければならない目標や仕事
    (例)フライトにチェックインする
  • □機能要求
    特定の条件下でシステムが示す振る舞いを示したもの
  • 
    ユーザ要求は、外部からの視点でプロダクトのユーザがプロダクトを使って行いたいことで、それを実現するためにプロダクト自身が持つべき機能が機能要求として表現されます。

 

いずれの定義においても、要求には、顧客／ユーザ視点で述べられたものと、それを受けて開発者視点で述べられる２つのレベルがあり、それぞれは、以下に示す重要なポイントを含んでいます。なお、本記事では、書籍「ソフトウェア要求」の用語に従い、前述IEEEの１の概念（要求）をユーザ要求、２の概念（要件）を機能要求と呼びます。（注記）

• ・ユーザ要求は、ユーザの理解できる表現で記述しなければならない
  　→　ユーザ要求はユーザがレビューでき、利害関係者で合意できる必要がある
• ・開発者が開発すべき項目は、ユーザ要求そのものではなく機能要求である
  　→　開発者が何を作ればよいかが明確に表されている必要がある

 

（注記）

　最近では資料や書籍「正しいものを正しく作る」にあるように、１を「要求」、２を「要件」と呼ぶことも多いようです。

　また、機能要求は機能的な要求だけを含みますが、要件は、非機能的なものも含みます。

 

後述するアジャイル開発においても、ユーザ要求／機能要求に対応する概念は存在します。

ユーザ要求／機能要求については、他にも以下のような性質があるので、併せて覚えておくとよいと思います。

• ・ユーザ要求が変われば、多くの場合、それから導出された機能要求にも影響が出る
• ・１つのユーザ要求に対して、複数の機能要求の選択肢がある

これを見ると、開発者が無意識に使っている「要求変更」と「仕様（要件）変更」という用語にも違いがあることが分かります。すなわち、ユーザ要求が変更になる場合（＝やりたいことが変更）と、ユーザ要求に基に導出された機能要求が変更になったか（＝やりたいことを行うのに必要な機能が変更）の相違です。

アジャイル開発においては、ユーザ要求の変更も、機能要求及び画面仕様の変更も積極的に受け入れるので、上述した「要求変更」と「仕様変更」の違いを意識する必要性はなくなってきています。

ただ、どのような用語を使うかに関わらず、ユーザ要求／機能要求（要求／要件）の違いとそれに対応する用語を皆が同じ使い分けを行うことは、誤解のないコミュニケーションのためには、重要なことです。

 

2.2 要求の構造

前回の記事でも書きましたが、要求には、要求間の依存関係の構造があります。書籍「ソフトウェア要求」に示された構造を図１に示します。

 

1. ビジネス要求
   組織／顧客がそのシステムを作る理由、つまり組織が達成したいと望むビジネス上の利益、解決したい課題やニーズを表します。
   （例）空港カウンター担当者のコストを25％削減したい
2. ユーザ要求
   ユーザが実行できなければならない目標や仕事を表します。
   （例）フライトのチェックインを乗客が直接できる
3. 機能要求
   特定の条件下でプロダクトが示す振る舞いを表します。開発者がプロダクトに作り込むのはこの要求になります。
   （例）システムは、ユーザが選択した座席を予約済にする
4. 品質属性
   ユーザ、開発者、保守担当者等にとって重要なプロダクトの特性を記述したものです。性能、安全性、可用性、移植性等があります。非機能要求の一部として分類されることもあります。
   （例）フライトへのチェックインは、２４時間、３６５日行うことができる

 

依存関係のある要求間では、Why-Howの関係が成り立ちます。すなわち、上位の要求は下位の要求が「なぜ必要なのか」を表し、下位の要求は上位の要求を「どのように実現するか」を表します。

上記の例で言えば、ビジネス要求である「空港カウンター担当者のコストを削減する」ために「フライトのチェックインを乗客が直接できるようにする」というユーザ要求が必要であり、そのユーザ要求を実現するために「ユーザが選択した座席を予約済にする」という機能要求が必要になります。逆に、「ユーザが選択した座席を予約済にする」という機能要求が必要な理由は、「フライトのチェックインを乗客が直接できるようにする」ためになります。

この要求のWhy-Howの構造は、以下のような場面でも役に立ちます。

１つ目は、ユーザからヒアリングした内容が「ユーザ要求」なのか「機能要求」なのかを区別することにより、ユーザ要求を満たす最適な機能要求を提案することができます。

前述したように、１つの「ユーザ要求」を実現する「機能要求」は通常複数あり、ユーザが指定した「機能要求」が最適とは限りません。例えば、ユーザが乗客の情報を画面から入力したいと言った場合、乗客の情報を登録するという目的のためには、他にもっと優れた方法（機能）があるかもしれません。このように、開発者は、その「機能要求」の基になっている「ユーザ要求」を確認の上、最適な「機能要求」を提案しなければなりません。

２つ目は、システム開発の目的であるビジネス要求に貢献しないユーザ要求や機能要求を排除することができます。全ての依存関係（トレーサビリティ）を明らかにしないまでも、基本的には機能要求やユーザ要求は、どれかのビジネス要求に繋がっているはずです。どこにも繋がらないユーザ要求や機能要求は作っても使われない要求（機能）になります。（注記）

 

（注記）

　正確に言うと、実装手段の制約などからくる機能要求もあり、必ずしも全ての機能要求がユーザ要求に繫がっているわけではありません。

 

2.3 アジャイル開発の場合

それではアジャイル開発における要求の分類や構造はどうなっているのでしょう。

説明に入る前に一つ補足しておくと、本記事では、アジャイル開発における要求プロセス設計の説明をしますが、正確には、アジャイル開発が向いているDXプロダクトにおける要求プロセスの説明であり、業務システムにアジャイル開発を適用する場合は、あまり考慮していません。

 

2.3.1 ビジネス要求

図２に示すように、ビジネス要求は通常ビジョン／スコープ記述書のような形でまとめられます。

 

アジャイル開発の場合、インセプションデッキ／エレベータピッチ、または、リーンキャンバスのようなものがよく使われます。

ここでは、リーンキャンバスを例に取り上げて説明します。リーンキャンバスでは、以下のような内容を明確にします。

 

［リーンキャンバス］

1. 課題と顧客セグメント
   対象とする顧客セグメントと、その顧客が抱える上位３つの課題
   既存の代替品
2. 独自の価値提案
   あなたが他と違っていて、注目する価値がある理由
3. ソリューション
   上位３つの機能
4. チャネル
   顧客への経路
5. 収益の流れとコスト構造
   収益モデル、粗利益等
   顧客獲得コスト、流通コスト等
6. 主要指標
   計測する主要活動
7. 圧倒的な優位性
   簡単にコピーや購入ができないもの

 

これらの項目が要求の生成源（後述）となり、ユーザ要求などの要求が抽出されます。

リーンキャンバスのサンプルを図３に示します。

 

2.3.2 ユーザ要求

ユーザ要求を表現する方法としては、ユースケースやユーザストーリーが使われますが、ここではユーザストーリーを例に説明します。

ユーザストーリーとは、「新しい能力を望む人、通常はシステムのユーザまたは顧客の観点からフィーチャを簡潔に記述したもの」であり、以下の形式で記載します。

 

［ユーザストーリー］

＜ユーザの種類＞として、＜達成したいゴール＞をしたい、なぜなら＜理由＞だからだ

（例）フライトにチェックインする

　＜旅行者＞として、＜フライトにチェックイン＞したい、なぜなら＜目的地まで飛行したい＞からだ

 

ユーザストーリーは、前述したユーザ要求の持つべき属性「ユーザの理解できる表現で記述され、ユーザがレビューでき、利害関係者で合意できる必要がある」を満たしています。

ここでは、ユーザ要求を表現する手段としてユーザストーリーを挙げましたが、実際のプロジェクトでは、機能要求も含めてユーザストーリーとして表現することも多いようです。

 

2.3.3 機能要求

機能要求は、ユーザストーリーを分析することにより明らかになったシステムの機能として表現されますが、それをどのように表現するかや、どのように呼ぶかについて、特に決まりはありません。例えば、以下のような方法があります。

 

1. ユーザストーリーを機能要求レベルまで分解して詳細なユーザストーリーを作成する
2. 機能要求に相当するユーザストーリーは作らず、ユーザとの話し合いを通じて、ユーザストーリーに必要な機能を作り込む（ユーザとの話し合いの結果については、何らかの形で開発完了までには残しておく）

 

ユーザストーリーは、従来の機能要求仕様に比べて記述が荒いので、開発者は不明点を常に顧客に確認する必要があり、そのためには、アジャイル原則にあるように、顧客のそばで作業を行い、常に対話ができることが必須になります。

 

2.3.4 品質属性

品質属性の表現の仕方の一つとして、「品質特定のパターン」の中で紹介されている品質ストーリーがあります。品質ストーリーとは、リリースで提供する必要のあるシステムの品質特性を特定し、ストーリーとして表現したものです。

品質属性は、各ユーザストーリーの中に受入基準として盛り込むこともできますし、まとめて一つの品質ストーリーにまとめてバックログで管理することもできます。

 

例えば、注文の口座からの支払いの「応答時間X秒以内」という品質属性を各ユーザストーリーの受入基準に記載することもできますが、応答時間の支払い方法毎の要件の相違がないのであれば、まとめて「システムはピーク時の操作で１時間あたりY件のトランザクションを処理できなければならない」という品質ストーリーを作成することができます。

 

2.3.5 要求の構造

アジャイル開発においても、トップレベルにあたる要求は、顧客の課題やニーズ、顧客に与える価値となります。前述のリーンキャンバスの場合は、主に「課題」、「独自の価値提案」が、これにあたりますが、その他の項目もユーザ要求や品質属性に影響を与えます。例えば、「圧倒的な優位性」として処理速度が早いことがあれば、性能という品質属性に影響を与えます。

アジャイル開発（DXプロダクト開発）における要求の構造の例を図４に示します。

 

3. 要求プロセスにおける活動

ここでは、要求プロセスの活動と実施項目についてソフトウェア・エンジニアリングの観点から簡単に説明し、アジャイル開発における活動のテーラリング方法について、いくつか例を挙げて説明します。

要求プロセスにおける活動と実施事項は、以下のとおりです。

• ■要求の抽出
  • □ユーザ要求を漏れなく抽出し、利害関係者と合意します
• ■要求の分析
  • □ユーザ要求を理解し、詳細な定義を与えます
  • □要求間の競合や不整合を検出して解決します
  • □要求を様々な観点（機能／非機能、優先度等）でクラス分けします
• ■要求の仕様化
  • □要求を文書化します
• ■妥当性の確認
  • □対象が利害関係者のニーズ、要求を満たしていることを確認します

アジャイル開発においても同様の活動を行いますが、進め方としては図５に示すように、各反復において要求の抽出〜妥当性の確認を繰り返しながら進めます。

 

3.1 要求の抽出

「要求の抽出」の目的は、ユーザ要求、品質属性を漏れなく抽出して、利害関係者間で合意することです。そのためにまず要求の生成源を洗い出し、それぞれの生成源に適切な方法で要求を抽出します。

要求の生成源としては、以下のようなものが挙げられます。

 

• ■プロジェクトの目標
  ビジネス目的、成功要因
• ■ドメイン知識
  アプリケーションドメインに関する知識
• ■利害関係者
  ユーザ、顧客、市場分析者等、システムに関わる役割
• ■ビジネスルール
  ビジネス自体が持つ構造、または振る舞いや制約に関する記述
• ■運用環境
  ソフトウェアが運用される環境
• ■組織環境
  組織の構造、文化、並びに内部駆け引き等

 

また、要求の抽出の技法としては、以下を利用することができ、対象となる生成源に対して適切なものを適用し、要求を抽出します。

 

• ■インタビュー
  システムの利害関係者が何を必要としているのか聞いてみる
• ■シナリオ
  ユーザがシステムを使用するシナリオを作成し、そのシナリオを実行するためにシステムに実装しなければならない要求を導き出す
• ■ユースケース
  システムを使用してユーザが実行するタスク、あるいは、ステークホルダーに貴重な成果をもたらす相互作用を作成する
• ■ワークショップ（進行役付き会議）
  様々なステークホルダーから並行して要求を引き出すためのセッション
• ■観察
  ユーザの業務実行のそばにいて、タスクの実行を観察する
• ■アンケート
  大人数のユーザから情報を引き出すのに適しており、安価に実施できる技法
• ■システムインタフェース分析
  対象システムに接続するシステムを調査する
• ■ユーザインタフェース分析
  既存システムのユーザインタフェース（UI）を調査する
• ■文書分析
  要求仕様書、ユーザマニュアル等の既存のシステムの文書を調査する

 

要求の抽出には、上記のように多くの技法がありますが、ユーザインタフェースを持つシステムの場合、ユーザの使い方を中心に考える技法が有効です。これは、必要なユーザ要求／機能要求を抽出できるとともに、ユーザの思いつきで、実際には使われないユーザ要求／機能要求が開発に含まれるのを防ぐことができます。

例えば、あなたがテキストエディタの開発を依頼されて、あるユーザから「エディタに表示される各行に行番号を表示して欲しい」という要求を受けたら、あなたはどうしますか？

行番号を表示する機能を追加するでしょうか。また、追加するとしたらそれはなぜでしょうか。

その答えを出すためには、ユーザがエディタをどのように使うかのユースケース（例えば「コーディングを行う」）を分析してみることです。

 

1. ユーザは、エディタにソースコードを入力する
2. ユーザは、エディタに入力したコードをコンパイルする
3. エラーがある場合、コンパイラはエラーメッセージとエラー発生行をユーザに提示する
4. ユーザは、エラーが発生した行をエディタで表示して、エラー原因を調べる

 

もしエディタに行番号を表示する機能がなかったらユーザは、ソースコードのどこでエラーが起きたのかを知ることができず、ソースコードの修正が行なえません。従って、あなたは、この要求を追加する必要があります。

逆にユーザが要求した機能でも実際には使われない機能というものも数多くあります。

ここでは、機能とユースケースの例でしたが、要求されたユースケースが本当に必要かどうかはどのように判断するのでしょうか。

業務システムの場合、それは、業務すなわち業務フローです。業務で使われない機能は、決して使われることはありません。

筆者が以前に倉庫の在庫を管理するシステムの開発に携わった時に、システム開発の依頼主である倉庫管理者のユーザから、出庫処理は通常は別会社の倉庫使用者が行うが、倉庫使用者から依頼された時に対応できるように、倉庫に保管された商品を出荷する機能を付けて欲しいという要求を受けて、その機能を作り込んだことがあります。

システム上は、商品の状態属性を出庫済に変更するだけですが、実際には商品の出荷管理は、その商品を管理する倉庫の利用会社が行っており、倉庫管理会社自体も、出庫を依頼されて出庫状態にするという業務はなかったため、その機能は、作られ、テストもされましたが、決して使われることはありませんでした。

 

3.2 アジャイル開発における要求プロセス

以下では、前述した要求プロセスの活動について、アジャイル開発におけるテーラリングの例をいくつか紹介します。

 

3.2.1 要求抽出の方法

アジャイル開発の場合も通常の場合と同様、要求の生成源を特定して、シナリオ、ユースケース、インタビュー等の抽出技法を用いて要求を抽出することができます。

以下では、アジャイル開発の要求抽出の方法をいくつか紹介します。

 

（１）シナリオ（使用方法）を分析して要求を抽出する

使用方法を分析して要求を抽出する手法として、ユーザストーリーマッピングがあります。

ユーザストーリーマッピングとは、ジェフ・パットンが開発したユーザストーリーを抽出するための技法です。

ここでは、書籍「正しいものを正しく作る」で紹介されている方法を紹介します。（図６）

 

1. ユーザを明らかにします
   ペルソナ等を使い、どんな属性のユーザがシステムを使うのかを確認します。
2. ユーザが関わるシーンを洗い出します
   例では、ECサイト利用中というシーンを想定しています。
3. シーン毎にユーザの行動を洗い出します
   商品の検索等、ECサイトでユーザが行う行動を洗い出します。粒度は異なりますが、ユースケースと同様にユーザがどのようにシステムを使用するかに対応します。
4. 各行動に対して課題を挙げます
   行動を取るにあたっての課題や行動をとるからこそ発生する課題をあげます。
   オリジナルのユーザストーリーマップにはありませんが、これがほぼ最初に説明した「ユーザ要求」に相当すると考えられます。
5. 課題解決に必要なユーザストーリーを取り出します
   課題毎に必要なユーザストーリーを洗い出しますが、これがほぼ「機能要求」に相当すると考えられます。

 

 

ユーザストーリーマップは、プロダクトのペルソナ（ユーザ）、利用する状況（シーン）、使用する流れ（行動）、解決したい課題（課題）を調べることにより、機能要求（ユーザストーリー）を網羅的、かつ視覚的に洗い出すことができます。

 

（２）課題からトップダウンに要求を抽出する

ビジネス要求にあたるビジネス上の課題からトップダウンで要求を導出する方法です。ここでは、「ディシプリンド・アジャイル・デリバリー（DAD）」の方向付けのケーススタディで説明されている、古いPOSシステムを使った販売現場を改善する例を紹介します。

（末尾の（）内は、そこで使われる要求抽出技法の例です）（図７）

 

1. ビジネス上の問題を特定し、根本原因を分析します（ブレインストーミング）
   （例）頻繁に故障するキャッシュレジスター、本部に接続されていない等
2. ビジネス上の問題を解決するソリューションを明らかにします
   （例）古く時代遅れのPOSシステムを、バックオフィスシステムと統合された新しい管理ソリューションへ刷新する
3. ビジネス上の課題、ニーズ、フィーチャ（注記）を明らかにする（ブレインストーミング）
   （例）
   ニーズ：レジ係りを増員せずに処理量を増やせる
   フィーチャ：お客様はレジ係りの援助なしにセルフ会計で食料雑貨を購入できる
4. ソリューションのフィーチャからユーザストーリーを導出します（ブレインストーミング、ユースケース）
   （例）お客様として商品のバーコードをスキャンして購入したい

 

 

DADの方向づけのゴールは、プロジェクトビジョンの特定し、初期の見積もりとリリース計画を作成することなので、全てのユーザ要求／機能要求が洗い出せるわけではありません。開発のための機能要求を漏れなく洗い出すためには、（１）の方法などを併用する必要があります。

 

（注記）
フィーチャという用語は、方法論や書籍等により色々な定義がありますが、DADでは、「ニーズを満たすシステムの能力」と定義されています。

 

3.2.2 仮説検証型の要求プロセス

ここでは、DXプロダクト開発においてよく使われる仮説検証型の要求プロセスについて説明します。

業務システムの場合、システムに必要な機能は、どのような業務設計にするかにかかっているため、ある程度時間をかけて新業務の分析やそれにともなうユースケースの分析を行います。

一方、DXプロダクト開発の場合の要求の抽出にあたっては、以下を考慮することが非常に重要です。

• ・分析すべき既存システムや文書、及び観察する業務がない
• ・リーンキャンバスで記載した課題も解決策も全て仮説であり、いくらインタビューやワークショップ等の要求抽出の技法を用いても正しい答えを持っている人はいない

この場合、最初のビジネス要求は以下の仮説から始まります。

• ・想定した課題・ニーズを持つ顧客はいるか？
• ・ソリューションは、その課題・ニーズを解決するか？
• ・顧客は、ソリューションに対価を払ってくれるか？

仮説検証型の要求プロセスにおいては、要求の抽出に時間をかけるより、エレベータピッチやリーンキャンバスで仮説として設定した顧客に対して、顧客がその課題を持っているか、また、ソリューションは、その課題を解決できるかを判断（＝妥当性の確認）してもらうというサイクルをいかに早く回すかということが重要になります。

仮説検証の方法は色々とありますが、書籍「実践リーンスタートアップ」では、以下の２つのインタビューを行うとしています。

• （１）課題インタビュー
• （２）ソリューションインタビュー

 

（１）課題インタビュー

課題インタビューでは、顧客と顧客セグメントの仮説を検証します。

• ・何を解決するのか？（課題）
• ・競合は誰なのか？（既存の代替品）
• ・誰が困っているのか？（顧客セグメント）

課題を理解するためには、要求抽出の手法であげた「観察」で、顧客の作業を観察することも有効です。

 

（２）ソリューションインタビュー

ソリューションインタビューでは、ソリューションをテストします。

• ・誰が困っているのか？（アーリーアダプター）
• ・課題をどのように解決するのか？（ソリューション）
• ・どのような価格モデルにするのか？（収益の流れ）

要求プロセスの妥当性確認活動は、様々な成果物に対して顧客のニーズを満たしているかという観点で行われますが、上記のインタビューは、ビジネス要求自体の妥当性確認（課題インタビュー）を行っていると言えます。

 

4. 終わりに

本記事では、ソフトウェア・エンジニアリングに基づき、要求の用語／概念、要求抽出活動を中心に要求プロセスの基本を説明した上で、DXプロダクト開発を対象としてアジャイル開発のプラクティスがそれらにどのように対応しているかを説明しました。

今回はあまり触れませんでしたが、要求の分析、要求の仕様化、妥当性確認、要求管理についてもアジャイル開発の目的や特徴に沿ったテーラリングがされています。それらについては、また機会があれば説明したいと思います。

 

■参考文献

1. アジャイル開発プロセスの本質
   https://www.tc3.co.jp/essential-agile-from-softwareengineering-pov-1/
2. ソフトウェア・エンジニアリング基礎知識体系
   https://shop.ohmsha.co.jp/shopdetail/000000004031/
3. 開発のためのCMMI1.3版
   https://resources.sei.cmu.edu/asset_files/WhitePaper/2011_019_001_28778.pdf
4. ソフトウェア要求
   https://www.nikkeibp.co.jp/atclpubmkt/book/14/P98390/
5. 今更きけないシリーズ第3回：ソフトウェア工学（要求工学編）
   https://mamezou.connpass.com/event/232151/
6. 正しいものを正しく作る
   http://www.bnn.co.jp/books/9859/
7. ２０１８年にリリースされた「DXレポート」
   https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
8. アジャイルサムライ
   https://shop.ohmsha.co.jp/shopdetail/000000001901/
9. インセプションデッキ
   https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
10. 実践リーンスタートアップ
    https://www.oreilly.co.jp/books/9784873115917/
11. 品質の特定のパターン
    https://codezine.jp/article/detail/12943
12. ディシプリンド・アジャイル・デリバリー
    https://www.shoeisha.co.jp/book/detail/9784798130613
13. アジャイル開発とスクラム第２版
    https://www.shoeisha.co.jp/book/detail/9784798171524
    
    

 

岸俊行

TC3株式会社
Topcoder事業部　プリンシパル・コンサルタント

日本ラショナルソフトウェア及び豆蔵において、１５年以上にわたり反復型開発プロセスの導入のコンサルティングに従事。また、豆蔵では、SWEBOKをベースにしたソフトウェア・エンジニアリング研修の開発も担当。

豆蔵独立後は、個人事業主としてモデリング、要件定義、スクラムのプロダクトオーナー支援等のコンサルティングに従事。

現在は、TC3において、Gigを活用したアジャイル開発プロセス（GigAgile）の開発に携わっている。

 

ーーー

デジタルサービス開発のポイント＆事例の紹介資料をご確認ください！

顧客向けのサービス開発をアジャイル開発の手法を活用してご支援しています。顧客向けのデジタルサービスを開発する上でのポイントとあわせて、事例をご紹介している資料は以下からダウンロードいただけます。

 

『デジタル顧客接点トータルサービス』のご紹介資料を含めたウェビナー資料（事例も掲載しています）以下のフォームからご確認いただけます。（フォームが表示されない場合には、こちらからご確認ください）

 

資料ダウンロードは以下のフォームにご記入ください。

 

キャッチ画像は İrfan Simsar on Unsplashを活用させていただきました