このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その10「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」についてです。
機能要求は「絶対に必要なもの」から
アジャイルでシステム構築していて良いと思う点は、ユーザからの過剰な機能要求を制御しやすいという点です。
要件定義をしていると「あれもこれも」と機能要求が膨らみやすく「絶対に必要」レベルの要求と「使うかわからないけれどあった方がいいかもしれない」レベルの要求が混在して上がってくる場合があります。こうした場合は「まずはSTEP1として”絶対に必要”レベルに絞って構築し、構築後必要があれば機能を追加しましょう」と提案すると同意を得られるケースがあります。STEP1で十分ということであればそのまま機能追加は不要になりますし、動くものが目の前に現れて初めて「当初言わなかったけれどこれができないと困る」などと新たな要求を発掘できることもあります。
初期構築では本稼働をゴールとして計画を立て、リソースを充てるので難しいことも多いかと思いますが、追加開発の場合は一定期間リソースを確保して定常的に開発を行うサイクルを作り、リソースも確保しておくことで細切れ対応にすることが可能になります。
結果的にまとめて開発した方が開発工数を抑制できた、という場合でも、不要な機能を追加しなくて済む場合もあるのでメリットはあると考えています。重要度の低い機能は要件も曖昧になりやすく、明確な要件を持たない機能は不具合も発生しやすくなります。重要度の低い機能の不具合によって重要度の高い機能のリリースが遅れるよりは、まずはコアとなる機能を構築してSTEP2、STEP３で肉付けしていった方が、結果的にはいいものが作れる可能性が高いと思われます。
変えない軸と走りながら変えるものを切り分ける
一方で、中途半端な投資にならないようにすることも重要です。工数抑制のために小手先だけの改修をしてしまい、根本的な解決にならないようなアプローチは避けるべきです。小手先の改修は仕様が不自然なものになりやすく、これも不具合の温床となります。あくまでも業務要件から導かれるシンプルな設計は曲げない状態で、開発単位を分割できるのであればコアなものから実装していく、という思想で実装すべきと考えます。
シンプルさは短期的な視点では作れません。アジャイルで構築しているとどうしても近視眼的になりやすいのが気を付けたいポイントです。システム全体の整合性・一貫性を担保しつつ、動かしながら作っていくという姿勢が大切です。そのためにも、業務・システム全体のを束ねる思想となるアーキテクチャプリンシプルが必要だと思います。
そう考えると、アジャイルアプローチは変えながら走る部分と、簡単には変更できない根幹を流れる思想や軸を明確に切り分けて進めていく必要があると感じます。
プロジェクトでは明確に定められたプリンシプルはありませんでしたが、例えばデータアーキテクチャを見ると疎結合アーキテクチャがベースとなっているので、システム間データ連携を考える際などは、それを担保した状態での改革を考えました。その他にも、明文化されていない部分に存在する何らかの意図や思想を、今後明確にしつつシステム運用を続けていけたらと思います。
第7回はアジャイル宣言の背後にある原則その10「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」について、ユーザから上がる機能要求のハンドリングと、長期的な視点からシンプルさを維持することの重要性について記載しました。
次回はその6「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
