このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その1「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」についてです。
機能改修のリリース単位は何を判断基準にするか？
ERPのシステム運用では、どういう単位で機能をリリースするか、どういう優先順位でリリースするか、ということを検討する際、その時の観点は顧客満足を最優先にしてきたつもりです。
例えばある機能の改修にあたり、2割が即リリースする必要のある緊急度の高いコア仕様、8割はそこまで緊急性の求められない仕様である場合、まず2割を開発してリリースすべきか、全てまとめて開発してリリースすべきか迷う場面があります。
まず2割のコア仕様を実装し、その後残り8割を実装するという2段階リリースの方式を取った場合、総工数は増えますがコア仕様のリリースタイミングを早めることができます。全てまとめて開発した場合、総工数は少なく済みますが、全ての機能の開発・テストを待ってリリースすることになるためリリースタイミングは遅くなります。
こうした場合、費用対効果の面から総合的に判断することが必要ですが、このプロジェクトでは2割をまずリリースするという判断を取ることが多いように思います(○○対応リリース STEP1、STEP2、と名の付く案件がよくあります)。
緊急度の低い仕様とまとめて開発した場合、開発工数が増えるだけでなく、当然テスト工数も増えることになります。また、最悪の場合緊急度の低い仕様でバグが見つかり、それが足を引っ張って緊急度の高い機能がリリースできないという状況に陥ることもあります。そうしたリスクも加味し、”顧客にとって”価値のあるソフトウェアを早期に実現することを目指してリリース単位を決定していきます。
頻繁に発生する優先順位変更で気を付けていること
優先順位については、運用回避の難しさや対象ユーザーの数、業務影響度、業務発生量などから決めていきますが、システム外の対応で運用回避策を用意するなどの施策を選択して優先順位を下げたり、逆に業務量の急増に応じて優先順位を上げたり、ということも頻繁に発生します。
そうした場合には開発チームに細かく状況を共有して、優先順位を入れ替えて対応してもらうようにします。ただし、ひとつ気を付けなければならないことはリリースの前後関係です。
例えばある機能Aと機能Bについて並行で開発しており、A→Bという順番でリリースする予定にしていたため、B機能はA機能が実装されている前提での仕様となっていました。しかし、急遽リリースタイミングを入れ替えることとなり、Bを先にリリースした結果Aがまだ実装されていないために正常に動作しなくなってしまった、ということがありました。
当たり前ですが前後関係のある機能についてはスケジュールの変更についても十分注意する必要があります。アジャイル的にやっているとスケジュールの入れ替えは当然発生することなのですが、プロジェクト全体を見渡して影響範囲を洗い出し、不整合が発生しない範囲で入れ替えを行うことが大切です。
第5回はアジャイル宣言の背後にある原則その1「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」について、リリース単位の決定方法と、優先順位入れ替えの際に気を付けたいことを紹介しました。
次回は、その2「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
