このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その9「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます」についてです。
「今必要なものだけをつくる」ことと「将来の変更に備えて柔軟な作りにしておく」のバランスを取る
アジャイルでは「YAGNI＝you aren’t going to need it（いずれ必要にならない）」がモットーなので、将来必要になるかも知れない機能は確実に必要になったときに作ればよい、というのが基本的な考え方です。私もおおむね賛成で、「将来必要になるかも知れない」と言われた機能は実際に使われる可能性は極めて低く、さらに曖昧な要求であるがゆえに不具合の温床となることが多いように思います。
とはいえ、「将来必要になるかもしれない」機能を実装する場合に、既存機能を全て捨てて作り直さなければならなくなるような場合には注意が必要です。アーキテクチャに関わるようなものや、データの粒度（特に最小単位）に関わるような要件であれば、簡単に切り捨てるのはリスクが高いように思います。
それが本当に必要になる可能性がどれくらいあるのか、必要になったときの変更コストがどれくらいになるのか、詳細に見積もることは難しくてもそれらを関係者間で議論した上で将来を見据えた設計にしておくのか、現時点では考慮不要とするのかの意思決定をして作るべきだと思います。それを可能にする上では、ユーザー側でもおおよその設計を理解し、ある程度どの要件が対象機能の骨子を決めているのかを理解していなければいけないのではないかと思っています。
小手先だけの改修に走らない
設計フェーズで、ベンダー側で要件を満たすための設計案を松・竹・梅で出すことがよくあります。この時、工数の少なさに惹かれて安易に「梅」を選択するのは危険な場合があります。ベンダーの方からご提案いただく設計を聞くと「イケてるなーすごいなー」と思う時と、「うーんイケてないなー」と思う時があるのですが、「梅」はイケてない設計のことが多いです（抽象的な表現ですみません）。
少し具体的に表現すれば業務要件から導かれるシンプルな設計ではないけれど、結果としては同じになるような設計であったり、正しく運用されることだけを前提とした設計であったり、というのが「梅」案では多いように思います。確かにその分「松」案よりも構築コストが少なくて済む、というメリットもあるのですが、それで本当に運用が回るのか？正しくないオペレーションが行われたときにはどうするのか？という観点を考えずに構築すると、結局問い合わせが増えたり、リカバリに時間がかかったりと運用コストが高くなってしまうこともあります。
無駄にリッチな作りこみは不要ですが、松・竹・梅から選択する場合は設計のシンプルさや保守・運用負荷も含めた観点から最適な費用対効果を見極めることが大切です。俊敏性を重視するアジャイル開発であってもとにかく早く作ればよい、ではないということです。
第11回はアジャイル宣言の背後にある原則その9「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます」について、ユーザー側で考えるべき「設計に対する不断の注意」を紹介しました。
次回はその12「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
