基幹システム関連のプロジェクトと言えば、アジャイルよりもウォーターフォール型が現在でも主流です。
しかし、長期間・大規模なシステム導入のプロセスを終えてから開始される、システム運用フェーズはどうでしょうか？
ユーザーの希望や業務の実態に合わせて、少しずつシステムを改修する、複数の追加要件から優先順位を付けて実装～レビューにまわしていく…
「これってかなりアジャイルなアプローチなのでは？」
実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その8「アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません」について、一定ペースで継続的なリリースを維持した時のメリットと、この手法を取る際に気を付けたいことを紹介したいと思います。
プロジェクトチームの学習効果
一定ペースで継続的に改修をリリースすることで、大きなメリットがありました。それはプロジェクトチームの学習効果です。
繰り返すことによる効果
小さな改修を繰り返していると、業務的には全く異なるシーンでもシステム的には類似する機能や同様のプロセスの改修がたびたび発生することがあります。すると要件を決めるタイミングで、ユーザサイドは「前回要件確認で聞かれたことはあらかじめ決めておこう」「前回受入テストで指摘した内容について、今回は要件定義時に明確に伝えておこう」など前回の改修を踏まえて要件出しをするので、要件を伝える能力が向上します。
また、基本的には要件を出したメンバーが受入テストをするので、要件を出す時点で無意識的に受入テストシナリオを想定しながら要件出しを行います。テスト可能な要件の網羅性・一貫性が高くなるため、ベンダーサイドにより正確に要件を伝えることができます。
要件定義、受入テストというV字モデルで対になる作業を短期間で繰り返し行うことで、受入テストでの気づきを次の要件定義に活かせるというのは、非常に効果的なことだと感じています。
継続的な活動がもたらすノウハウの蓄積
大規模なシステム導入プロジェクトでははじめましてのメンバーで体制を構築し、導入後は解散する、というのが一般的と思います。こうした体制ほど、ユーザサイドはプロジェクトチームが業務を深く理解できるよう主体的に働きかける必要があるのですが、業務プロセスを横断的に知っており、それを明確に可視化したり、または伝えたりできる人(＝社内に存在するビジネスアナリスト)がプロジェクト立ち上げ当初からユーザサイドにいることはまれだと思います。
しかし、たとえ小規模であっても継続的にプロジェクトを回していれば、少なくとも社内ビジネスアナリストのようなユーザサイドとプロジェクトチームを橋渡しする動きを担う人が誰かしら必要になるはずです。
こうした環境が整っていれば、いざ大規模プロジェクトが立ち上がってもノウハウが蓄積された状態でプロジェクトを開始することができ、プロジェクト成功の可能性を上げることができるのではないかと思っています。
仕様凍結期間は猶予を持たせて
一定ペースで継続的なリリースを維持するために、スケジューリングで気を付けたいことがあります。それは仕様凍結期間にやや余裕を持たせることです。
きちんと要件定義～受入テストを実施してリリースしたとしても、全く修正なく運用できることばかりではありません。大きな手戻りになるようなものは初期リリース時に実装しておくべきですが、軽微な部分ではエンドユーザが実際に使用し始めてから修正が発生することがあります。そうした場合に、ある機能をリリースした後にすぐに同一機能に対する改修に着手してしまうと、ちょっとした修正にも関わらず対応が後回しになってしまうということがあります。
具体的な事例を紹介すると、あるシステム運用・改修プロジェクトでは、6か月ほどかけて受注契約情報管理機能の改修を実施したのですが、最初の機能リリース（4月）直後の2カ月（4～6月）で同一機能に対して消費税率10％対応の2次改修を実施するスケジュールを引いていました。
そのため最初のリリース直後からいくつかの修正箇所が見つかっていたものの、その対応は2次改修後の7月まで待たなければならない、という状態になってしまいました。
今回の場合は増税対応であり、実際問題としてスケジュールを遅らせることは困難だったとは思いますが、2週間ほどでもリリース後の修正期間を確保していれば4月中に対応できた内容も、増税対応完了後に対応ということになってしまいました。 可能であればリリース後一定期間は引き続き仕様凍結期間としておくと、修正が発生した際に早めの対応が可能になるかと思います。
もちろん、一発リリースで満点を出せるのが好ましいとは思うのですが、それには莫大な工数がかかります。まずは業務上マストなラインを抑えて60～70点でリリースし、徐々に品質を上げていくという考え方も時には必要です。
そこで重要になるのは60～70点の見極めです。基幹システムでは業務上マストなラインが高くなる傾向にあるため、いくら満点でなくても良いといっても求められる水準はもちろん高くなります。
また、リリース後トランザクションデータが蓄積されてからのデータモデル（特にエンティティ間のリレーション）の変更は非常にインパクトが大きいため、初期構築で必ず押さえておくべきポイントです。 いくらアジャイルといっても最初の60～70点の見極めを誤ると壊して作り直しになるリスクもあるため、ここの見極めが勘所になると思っています。
第4回はアジャイル宣言の背後にある原則その8「アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません」について、一定ペースで継続的なリリースを維持した時のメリットと、この手法を取る際に気を付けたいことを紹介しました。
次回は、その1「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
