このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その2「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」についてです。今回でやっと12の原則のうち6まで来ました。引き続き頑張って書いていきますので、よろしくお願いします。
変化は受け入れるが、不要なもの・曖昧なことを無くす
この原則にあるように要求の変更は悪ではありません。業務要件が変化しているのであればそれに合わせてシステムも変えていくべきです。しかし業務要件は変わっていないが、単に潜在的に言語化できていなかった要件が後から出てきただけ、という場合も多いと思います。こうした部分は可能な限り減らしていくべきだと思います。そのために気を付けていることを2点紹介します。
その１：やらないことを決める
やることの合意形成は放っておいても行われるので、やらないことの合意形成にも同じくらい注意を払うようにしています。基本的にユーザサイドがやってほしいと思っていることの方が、ベンダーサイドが要対応だと受け取る範囲より大きくなることが多いので、ふたを開けたら
ユーザ「え、そんなこと言わなくてもやってくれると思ってました」
ベンダー「え、言われてないのに対応できるわけないじゃないですか」
となる悲しい場面を私自身何度も目にしてきました。
そこでグレーだなと思う部分に対しては「ここは対応しない認識ですがよいですか？」と双方に細かく聞くようにしています。また、スコープの認識がずれるのは最終的なゴールが共有できていない、または明確になっていないときに起こるので、いきなりシステム要件から話すのではなく、業務上課題になっている点や実現したい業務要求、利用シーンなどをなるべく細かく聞く・伝えるようにしています。
その２：具体と抽象を行き来する
特に設計フェーズでは、システム寄りの会話が多くなってくるため「要件を満たす仕様になっているか」をユーザが判断するのがやや難しくなってきます。そこで、ユーザには「この仕様で実装した場合、こんな場面ではこんな表示・操作になりますがよいですか？」と具体的な業務シナリオに置き換えて説明するようにしています。具体的な業務がイメージできて初めて「それでよい」「それでは困る」という会話に至ることが多いからです。具体例を出す、というのは簡単に思えて意外と面倒な作業です。しかし「例えば100万円で新規契約があって・・・」と話していくと「こういうパターンもあるんですが対応できますか？」とユーザの方から質問があがったり、自分自身で矛盾に気が付くこともあります。モノが出来てからではもっと面倒くさいことになるので、ここで横着せずに具体的な例で検証しておくことが大切です。
これらの工夫で要件の取りこぼしは最小限に抑えるようにしているのですが、とはいえそもそも「最初から完璧に要件を洗い出し実装していく」という考え方に無理があるからこそ生まれたのが”アジャイル”という考え方だと思っています。そこでもうひとつ、契約面での工夫も紹介します。
仕様の変更を契約上どう取り扱うか
このプロジェクトでは（他にもさまざまな要因はありつつも）要件の難易度によって請負契約で開発するか、準委任契約で開発するかを分けていました。小規模な追加開発等は準委任契約で実施し、中規模以上の開発や新機能の開発になると別プロジェクト化して請負で実施することが多かったです。比較的規模の小さな案件であれば受入テストの中で仕様変更が発生したとしても軽微な修正にとどまることが多いので、準委任契約でその場で修正してリリースした方がよいことが多いからです。一方、中規模以上の開発となると開発後期での仕様変更は設計全体に影響を及ぼすこともあり、投資対効果が得られなくなるリスクも大きくなります。そのため最低限の明確な要件に絞って請負で開発した方がよいという考え方です。
もちろん、どちらのやり方もメリットデメリットがあるので一概にこのやり方がよいという訳ではありません。ただし、お客様自身どちらの契約形態も経験しているからこそ、双方のメリットデメリットを理解し始めているように思います。
請負のメリットとしては、瑕疵担保責任があるためリリース後一定期間の間に瑕疵にあたる不具合があった場合には無償での補修対応を依頼することができます。デメリットは、要件定義までは準委任で進めそこで決定した要件に従って開発を進めるため、追加要件が後から発生してもその契約内で追加することは出来ないことです。準委任のメリットはその逆で、開発・受入テストをしている内に当初要件に入れていなかった部分で追加要件が出た場合、その場で対応を依頼することができます。
いきなり大規模な開発にアジャイルを取り入れるのはリスクが高く、市場でも基幹領域、大規模プロジェクトでの事例はまだあまりないと思います。そうした場合は「できそうな規模の案件だけアジャイルを適用する」という部分適用もありではないでしょうか。一部でもやってみることでノウハウが蓄積されてより大きな規模に適用できる可能性もありますし、既存の手法と並行で実施することで双方のやり方のメリットデメリットも見えてくるように思います。
今回はアジャイル宣言の背後にある原則その2「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます」について、要件の取りこぼしを防ぐ工夫と、アジャイルの部分適用の事例を紹介しました。
次回はその10「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
