本記事では、まずOGIS Scalable Agile Method 2.0を考案する動機となった『要求に関する試行錯誤を可能な限り減らしつつ、高い品質を確保しながら、「要求の変化に対応しながら開発する」というアジャイル開発のメリットを活かす』ための課題を説明する。次に、「開発初期段階に開発要件を確定すること」と「開発要件を精緻に文書化すること」の長所と短所を中心に従来手法の問題点について論じる。
OGIS Scalable Agile Method 2.0を考えた動機
OGIS Scalable Agile Method (以降、OSAMと略す) 1.0 [1] は、ユーザー企業とSI企業に分かれた日本産業構造においてアジャイル開発を適用する課題を考慮し、それらの課題をスクラム [2]、アジャイルUP、測定の組み合わせで克服できるのではないかという解決策を提案した。
OSAM1.0は、フェーズと反復で構成されるハイブリッドアジャイルの1種であり、アジャイルUPの発展形であるDisciplined Agile Delivery (DAD)[3]と測定以外の部分は類似している。OSAM1.0を提案してから、このフェーズと反復で構成される反復開発やアジャイル開発は日本でも多くの開発プロジェクトで適用されてきた。また、ハイブリッドではない形でスクラムをチームレベルで適用する事例も増えてきた。
ハイブリッドアジャイルとそうではないアジャイル開発の大きな違いの1つは、要求を予め確定し、文書化するか否かという点である。前者は、既存の開発とのギャップが少ないために実践しやすいという長所があるが、逆に「要求の変化に対応しながら開発する」というアジャイル開発のメリットを活かしにくいという短所がある。後者の方式には、「市場への投入期間の短縮」や「開発途上で明確化するユーザーニーズへの対応」という点において前者の方式に対する優位性が期待できるが、同時に「要求に関する試行錯誤」や「要求の変化に起因する品質の低下」という点での潜在的なリスクもある。
要求に関する試行錯誤を可能な限り減らしつつ、高い品質を確保しながら、「要求の変化に対応しながら開発する」というアジャイル開発のメリットを活かすためには以下のような課題がある。
- イ) 軽量で開発依頼者にも定義しやすい形での要求表現
- ロ) 軽量で定義しやすい要求表現に内在しうる矛盾、抜け、あいまいさ等の解決
- ハ) 要求に基づいて実装された動くソフトウェアの受け入れ基準の設定
- ニ) 反復毎に実行される受け入れの労力の削減
ここで、受け入れ基準は「要求の変化に対応しながら開発する」場合に反復毎の計画(あるいはスプリント計画)が達成されているかの客観的な判断基準になる。そのため、先の課題の一覧に加えている。
- ホ) 自己管理や自己組織化というチームの連携を活かしたスケールアップ
これは、スクラムを実践する際の基本となる自己管理や自己組織化というチームの連携を活かした形のスケールアップということである。
OSAM1.0の提案以降にこれらの課題の解決策を求めた結果、スクラムに以下のようなフレークワークや手法を組み合わせることが解決策になり得ることが分かった。
- DtoD (Discover to Deliver)[4]:ロ)とハ)に対する解決策
- 受け入れテスト駆動開発(A-TDD):ハ)とニ)に対する解決策
- SAFe (Scaled Agile Framework)[5]:ホ)に対する解決策
これら3点とスクラムの組み合わせで構成される手法をOSAM2.0と呼ぶ。なお、OSAM2.0において、スクラム、DtoD、A-TDDの3点で構成されるものをOSAM2.0基本形と呼び、この基本形にSAFeを加えたものをOSAM2.0発展形と呼ぶ。
本連載では、OSAM2.0がDtoD、A-TDD及びSAFeを組み合わせることでなぜ解決策になり得るのかを説明することを目指す。
従来手法の問題点
以降では、業務システムを中心に従来手法の問題点を説明する。
従来手法の大きな問題点は、「業務に本当に役立つシステムや、新たなユーザーを獲得できるほど魅力的なプロダクトをタイムリーに開発できない」ということである。この結果が、ビジネス機会を逸したり、他社との差別化ができず、価格競争に巻き込まれるなどのビジネス上の優位性に大きく影響する。
従来手法の大きな問題点として先に挙げたことは、以下の2点の問題に分解できる。
- ニーズとのミスマッチ
- 開発初期に確定した要件定義どおりに開発したシステムが必ずしも業務やユーザーのニーズにマッチしていない
- 開発期間が長い
- 要件定義も開発も時間がかかる
ここで要件定義する内容と言っているものには、以下の2つが含まれる。
- 業務要件:システムで支援する業務内容(業務ルールや法規制を含む)
- システム要件:業務要件を満足することを支援するシステムの仕様
これらの両方に登場する要件定義に注目すると、これらの問題は従来手法の要件定義に対する以下の考え方に根ざしていることが分かる。
- 開発初期段階に開発要件を確定すべきである
- 開発要件は精緻に文書化すべきである
これらの考え方の妥当性について、以下の2つの観点で考えてみる。
- 開発初期段階に業務やユーザーニーズに合う要件を確実に定義できるか
- 開発要件は精緻に文書化すべきである
まず、Aについては「確実に定義できる」ものと、「確実には定義できない(困難)」ものがあるだろう。Bの「文書化」はAとして「確実に定義できる」ことを前提にしていると思われるが、Bのメリットとデメリットについては後で議論する。
開発初期段階に業務やユーザーニーズに合う要件を確実に定義できるか否か
業務やユーザーニーズに合う要件を「確実に定義できる」例としては、経理データの仕分けや合算など演算結果にビジネス価値が確実にあったり、経費精算などの定型業務でシステム化することで業務が省力化できるようなものが考えられる。これらのシステムを「要件を最初に確定できるシステム」と呼ぶ。
その一方で、業務やユーザーニーズに合う要件を「確実には定義できない」ものとしては以下のようなものが考えられる。
- 新たな業務
- 他に類を見ないような新たな製品やサービス
つまり、ITを活用して新たな価値を創出する業務、製品、サービスを作る場合である。例えば、営業支援システムやEC(BtoC)サイトであり、IoTであり、ネット系の保険販売であり、モバイルデバイスによる業務の革新であり、ビッグデータやデータ分析などである。
このような人間とシステムとの相互作用を中心としたシステムであり、そのシステムの価値を開発前に予測することは困難である。それは、そのようなシステムが想定している業務自身やユーザーの行動、さらにはシステムによる業務上の成果拡大に仮説が含まれるからである。
例えば営業支援システムを例に考えると、たいていの場合現状の営業活動上の課題とそれに対して考え得る解決策をまず考えるだろう。この解決策には、おそらくなんらかの業務の変更とそれに対応するシステムの変更が必要になるだろう。でも、この業務の変更やシステムの変更の効果はあくまで仮説であり、それらを変えてどの程度の効果が見込まれるかを予測することは困難である。
このような予測の困難さは、「既存の業務の延長ではない、新たな業務(複数の業務の構造の大きな見直しによるものを含む)を、それを支援するシステムとともに実行したこと(裏付けとなるデータ)がない」ことに起因する。このようなシステム、サービス、製品を「要件を最初に確定できないシステム」と呼ぶ。
「要件を最初に確定できないシステム」の対象となる業務がビジネス競争の核心に関わるものであればあるほど、その有効性を開発に先だって確認できるほどの時間的な猶予が無いだろう。
このような状況に対応するためには、「実証主義的にシステムを作る」という方針が有効である。つまり、システムのすべてを一気に作るのではなく、効果を確認できる単位で開発し、得られたシステムを稼働させたり、ユーザーに評価してもらうことで効果の確認を行うということである。つまり、システムのリリースを単位にしてPDCA (Plan Do Check Act) を回すのである。
次回の記事で説明するアジャイル開発でもっとも普及しているフレームワークであるスクラムでは、2週間程度のスプリントという単位で動くソフトウェアを作成し、各スプリントの最後でデモを行うことで開発依頼者に作成したソフトウェアが意図通りであるかを確認する形で開発を進める。さらに、複数回のスプリントを経てリリースが作成され、ある程度の業務をシステムで実行できるようになる。
アジャイル開発の利点の1つは、これら複数回のスプリントやリリースでPDCAを回し、開発しているシステムが業務に役立つかを確認し、仮説が間違っていた場合には開発を中断したり、軌道修正できる点にある。
開発要件を精緻に文書化すべきか否か
先に述べたように「文書化」というのは、「業務に役立つ要件を確実に定義できる」ことが大きな前提になると思われるが、それでも開発依頼者から開発チームに自らの要望を伝える何らかの手段が必要になる。
ここで要件定義と言っているものには、以下の2つが含まれる。
- 業務要件:システムで支援する業務内容(業務ルールや法規制を含む)
- システム要件:業務要件を満足することを支援するシステムの仕様
これら2つのなかで、文書量が多いのはシステム要件の方であり、システム要件を主に文書化することの長所と短所を考えてみる。
まず、システム要件を文書化することの長所としては以下のようなことが考えられる。
- 品質の向上
- 仕様書をレビューすることで、仕様の間の不整合や仕様の抜けに気づけたり、開発依頼者が自分の要望を満足するものであるどうかを確認できる
- 業務を「理解している」人の限定が可能
- 開発メンバーが業務を理解しなくても開発ができる
- 開発範囲の明確化
- 開発を委託している場合には、システムの詳細な仕様を規定することに、範囲の漸次的な増加を防ぐという開発者側のメリットだけではなく、納品されるシステムの機能を契約で規定するという発注者側のメリットもある
その一方で、システム要件を文書化することの短所としては以下のようなことが考えられる。
- 時間がかかる
- 文書化するための時間や作成された文書を確認(レビュー)するための時間がかかる
- 記述が難しい
- 開発依頼者にとって、業務上のニーズを説明できたとしても、その業務を支援するシステムの仕様を記述することはハードルが高い
結局、開発依頼者が述べた抽象度が高い要望を開発者側が仕様書という文書で具体化し、開発依頼者に確認してもらうというサイクルの効率が悪いのである。開発の出発点として「開発依頼者が自分自身の言葉で述べた要望」は尊重すべきであるが、その要望に対応するソリューションの確認というステップをもっと効率化する必要がある。
アジャイル開発では、「変化にすばやく対応するために変更コストを増大させるようなドキュメントをあまり作成しない」というのが基本的な方針となる。「精緻な文書」を作るというのはその方針に反するが、「精緻な文書」のメリットを残しつつ、デメリットを減らすような方策をアジャイル開発においても考えていくことには価値がある。
第 1 回の終わりに
今回の記事では、OSAM 2.0を考案した動機と従来手法の問題点について説明した。次回は、世界で最も普及しているアジャイルプロジェクト管理フレームワークであるスクラムとユーザーストーリーの概要を紹介し、スクラム+ユーザーストーリーの不十分点について説明する予定である。
参考文献
[1] 藤井 拓, オージス総研 アジャイル白書,
https://www.ogis-ri.co.jp/pickup/agile/docs/agile_wp_201305.pdf
[2] ケン・シュエイバー, マイク・ビードル, アジャイルソフトウェア開発スクラム, ピアソンエデュケーション, 2003
[3] Scott W. Ambler, Mark Lines, ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド, 翔泳社, 2013
[4] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプロダクトの計画策定と分析, BookWay, 2014
[5] Dean Leffingwell, アジャイルソフトウェア要求―チーム、プログラム、企業のためのリーンな要求プラクティス, 翔泳社, 2014