アジャイル開発プロセスの本質(前編)
〜ソフトウェア・エンジニアリングの基本から理解を深める〜

コンテンツ

2021/09/13

TC3株式会社 > コンテンツ > アジャイル開発プロセスの本質(前編)
〜ソフトウェア・エンジニアリングの基本から理解を深める〜

はじめに

本記事では、前編と後編に分けて、ソフトウェアエンジニアリングの基本に従いアジャイル開発プロセスを設計していくことにより、アジャイル開発プロセスの進め方、活動及びそこで使われる手法、並びに成果物がなぜそうなっているのかを知り、アジャイル開発プロセスへの理解を深めるということを目的としています。

 

例えば、開発プロセスとしてスクラムを使う場合、スクラムで決められたやり方をそのまま使うということではなく、一旦上記のような「なぜ」を知ることで、プロジェクトの特性に合わせて活動や成果物をテーラリングするなどして、より効果的にスクラムを使うことができるようになります。

 

<後編も含めた目次>

  • 開発プロセスの設計とは
  • 開発プロセス設計手順
    • プロジェクト、プロダクトの特性を明確にする
    • ソフトウェア開発ライフサイクルを決める
    • ソフトウェアプロセスを決める
      • スクラムのライフサイクル
      • 活動、成果物のテーラリング
    • 開発プロセスを実装する
    • 開発プロセスを改善する
  • 開発プロセスを超えて
  • 終わりに
  • コラム:要件定義はフェーズまたはプロセス?

 

開発プロセスの設計とは

開発プロセスは、大きく分けて以下の2つの要素から構成されます。

  1. 何をするのか?
  2. いつするのか?

 

1. 何をするのか?

1は、ソフトウェアエンジニアリングプロセスまたは単にソフトウェアプロセス(以下では、ソフトウェアプロセス、あるいはプロセスと呼びます)と呼ばれ、ソフトウェアエンジニアによって遂行される、開発、保守、及び運用に関する活動、例えば、要求、設計、構築、テスティング、構成管理などのことです。

ソフトウェアプロセスは、そのプロセスへの入力を出力に変換する相互に関連した活動、タスクの集合から構成されます。(図1)

また、個々のソフトウェアプロセスは、相互に時間的順序を持ちません。ソフトウェアプロセスの時間的順序(いつそのプロセスを実施するか)は、2のソフトウェア開発ライフサイクルによって決められます。

アジャイル開発プロセスの本質_図1

図1:ソフトウェアプロセス

2. いつするのか?

2は、ソフトウェア開発ライフサイクル(Software Development Lifecycle / SDLC)と呼ばれ、時間軸に沿ってソフトウェア要求を引き渡し可能なソフトウェアプロダクトへ変換していく段階(フェーズ)を表現したものです。最近では開発部分だけでなく、企画〜運用、廃棄まで含めたプロダクトのライフサイクル全体を対象としてプロダクトライフサイクル(Software Product Lifecycle / SPLC)と呼ぶこともあります。

 

いくつかの典型的なソフトウェア開発ライフサイクル(以降では、単にライフサイクルと呼ぶ場合があります)が提案されており、それらをソフトウェアライフサイクルモデルと呼びます(以降では、単にライフサイクルモデルと呼びます)。

 

代表的なライフサイクルモデルには、線形モデルと漸次拡張モデルがあります。双方における顕著な特徴は、ソフトウェア要求の扱い方にあります。線形モデルでは、プロジェクトの始動から計画の期間中にできるだけプロダクト全体に対する要求を開発し、その後は、開発した全ての要求に対して、全設計完了、全構築完了、全テスト完了と段階を経て、全体のリリースに到達します。一方、漸次拡張モデルでは、ソフトウェア要求の一部について、要求、設計、構築、テストを行い、引き渡し可能な部分を作成し、それを繰り返しながら全体のリリースに到達します。

 

線形モデルとして、皆さんもよくご存知のウォーターフォールモデルがあります。ウォーターフォールモデルでは、ライフサイクル全体を、要件定義(※)、設計、構築、テストというフェーズに区切って、各フェーズ期間では、それぞれ要求、設計、構築、テストのプロセスを実施します。

※:ここではプロセス名は「要求」、フェーズ名は「要件定義」と呼んでいます。記事内のコラムもご参照下さい

 

もう一つのライフサイクルモデルである漸次拡張モデルとして、今回の記事のメインテーマであるアジャイルモデルがあります。アジャイルモデルでは、ソフトウェア要求の一部分について要求、設計、構築、テストを行い、引き渡し可能なソフトウェアを作成していきます。

 

両者の相違を図2に示します。

アジャイル開発プロセスの本質_図2

図2:ウォータフォールモデルとアジャイルモデルの相違

 

開発プロセス設計手順

ここからは、具体的にプロジェクトへ適用する開発プロセスを設計する手順を説明します。

最初に開発プロセス設計全体の流れを図3に示します。なお、図には、設計したプロセスを実装及び改善する流れも記載してあります。

アジャイル開発プロセスの本質_図3

図3:開発プロセス設計の流れ

 

①プロジェクト、プロダクトの特性を明確にする

開発プロセスは、それを適用するプロジェクト及び開発対象のプロダクトの特性により、設計及び適応化する必要があります。組織の状況、プロジェクトの大きさ、企業文化、開発対象プロダクトのクリティカル性、要求がどの程度明らかになっているか、あるいは、市場等の環境により要求が変わる可能性があるかなどを考慮します。

 

また、近年のDX(デジタルトランスフォーメーション)の文脈におけるプロダクト開発においては、様々な変動性、不確実性に立ち向かう必要があります。例えば、何を作れば顧客に価値を提供できるのか(不確実性)、競合製品のリリースによる市場の変化(変動性)等が挙げられます。

 

詳細は後述しますが、これらの特性が、ソフトウェア開発ライフサイクルやソフトウェアプロセスの選定及び決定、並びにテーラリングに影響を与えます。

 

②ソフトウェア開発ライフサイクルを決める

ソフトウェア開発ライフサイクルは前述のように、プロダクトをどのような段階を踏んで、リリース可能な状態に持っていくかを決めることです。具体的には開発全体を複数のフェーズに区切って、各フェーズの入力基準、出力基準、あるいは、ゴールを決めていきます。

 

通常は、何もない状態からソフトウェア開発ライフサイクルを決めることはなく、既存のライフサイクルモデルから選択することになります。

 

ウォーターフォールモデルを選んだ場合、典型的には、図2に示したように、要件定義、設計、構築、テストの4つのフェーズがあり、それぞれのフェーズのゴールは、要件定義完了、設計完了、構築完了、テスト完了となります。

 

アジャイルモデルの場合、選択するプロセスフレームワークによって変わってきます。エンタープライズアジャイルフレームワークの一つであるDA(Disciplined Agile)では、以下のように方向づけ、構築、移行のようなフェーズが定義されています。

 

 

一方スクラムでは、フェーズという概念はなく、反復(スプリント)毎にゴールが設定されますが、DAの方向付け、移行と似たように、ビジョンの確立や運用リリース前の作業をそれぞれスプリント0、及びリリーススプリントという名称で行うこともあります。

 

どのライフサイクルモデルを選択するかは、前述したプロジェクト、プロダクトの特性により決めます。

 

前述のDXプロダクトのように最初から何を作ればよいか先が見通せないプロジェクトでは、設定した仮説を都度試し、そこでの発見に適応しながら漸次的に解決をはかる、時間を一定に区切った反復による漸次拡張モデルが適しています。

 

変化に対応しながら、早くリリースして不確実性や変動性に対応することが重要になります。それにより、無駄を省いて的確なゴールにより早くたどり着くことが可能になります(図4)。

図4:変化への対応

 

実際、アジャイル開発の最新の動向が掲載された「15th State of Agile Report参考ブログ」によれば、企業がアジャイルを導入する理由として「変化する優先度への対応する能力をつけるため」「ソフトウェア提供スピードを上げる」ことが64%と、トップに上がっています。

 

また、DXレポートの中でも、DXに取り組む企業の方向性として、「企業が競争上の優位性を確立するには、常に変化する顧客・社会の課題をとらえ、「素早く」変革「し続ける」能力を身に付けること、その中ではITシステムのみならず企業文化(固定観念)を変革することが重要」と述べられており、DXに取り組む組織は、アジャイルモデルを選択すべきです。

 

おわりに

前編では、開発プロセス設計のうち、図3の2番目のソフトウェア開発ライフサイクルを決めるところまでについて説明しました。後編では、ここで決めたライフサイクルに基づいてソフトウェアプロセスを決め、ソフトウェアプロセスの各活動、成果物をテーラリングする考え方について説明します。

 

■完全版 EBOOKは以下からダウンロード可能です!

 

【本記事の執筆者の紹介】

岸俊行

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

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

豆蔵独立後は、個人事業主としてモデリング、要件定義、スクラムのプロダクトオーナー支援等のコンサルティングに従事後、現在は、TC3において、Gigを活用したアジャイル開発プロセス(GigAgile)の開発に携わっている。

 

 

ーーー

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

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

 

デジタル顧客接点トータルサービス CTA

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

 

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

 

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