このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その7「動くソフトウェアこそが進捗の最も重要な尺度です」についてです。
この原則を「プロジェクトの外にいる人たちとのコミュニケーション」と「動くソフトウェアづくり」の2つをテーマに紹介してみます。
プロジェクトの外にいる人たちとのコミュニケーション
「動くソフトウェアをリリースしてはじめてお客様へ価値が届くのだ」ということは忘れないようにしたい観点です。プロジェクトチームにいると要求整理・要件定義・設計・受入テスト…と様々なステップを踏んでいくので日々前進しているような錯覚に陥ってしまうことがあるのですが、機能がリリースされるまでお客様はソフトウェアの価値を享受することは出来ず、目の前の課題と毎日向き合っている現実は変わらないままです。そう考えると、特にプロジェクトの外にいる人達にとってはまさに動くソフトウェアこそが進捗を表す尺度なのだと思います。
追加開発においては小さな機能であっても出来上がったらすぐリリースできることが大きなメリットだと思っています。何か新しい機能をリリースすると、何かしらのフィードバックを得ることができるからです。長期的な取り組みほど、方向性がずれていても「いまさら止められない」という暗黙の圧力により当初の目的を失っているにも関わらず走り続け、結果満足のいく結果が得られない、といったことが起きるリスクがあります。しかし、少しずつでも機能をリリースしていきフィードバックを受けることで、業務理解が進み優先度の調整や要件定義の精度が上がっていきます。また、全ての要望に対処することは出来ませんがプロジェクトの目的に適合するような要望であればできる限りタイムリーに対処することで「言えば検討してくれる人たちだ」と捉えてもらい、業務上の課題をさらに共有してくださったり、リリースした機能自体に対してコメントをいただき今後の開発に活かすこと出来たりします。
さらに、新しい機能を少しずつリリースしていくと、時折思いもよらないところから隠れたステークホルダーが現れることがあります。自分が担当しているシステムとは別のシステムを担当している方から声をかけられることがあったり、物理的に距離が離れた支店の方からご連絡をいただくこともあり、そうした日々のコミュニケーションの中で各部門の「シャドーBA（ビジネスアナリスト）」的な方を発掘し、ネットワークを築いておくことで、次回以降はリリース前にそうした方たちとコンタクトを取り、スムーズな業務移行のために草の根的にリリースを事前にお知らせしたりすることもあります。
動くソフトウェアづくり
最近つくづく痛感しているのが、「もれなく要件定義を行えば”動くソフトウェア”が出来る訳ではない」ということです。もちろん要件を明確に決めないことには何も始まらないので要求整理、要件定義は非常に重要な工程ですし、わたしはやっぱり要件定義好きなのですが、その後の設計、テスト、教育、移行を経てリリースし、ソフトウェアが正しく動き始めて初めてシステム導入は実を結ぶのだということをとても感じています。
頻繁に機能をリリースしていると、結構頭を悩ませているのが改修の影響範囲の洗い出しとデグレの確認です。影響範囲の洗い出しについては、SAPだとある程度はソースコードスキャンなどで改修対象の項目を使用しているプログラムの洗い出しが可能なのですが、それでも完全ではなかったり、SAPに改修を加えたことによる周辺システムへの影響の洗い出しなどは担当者の頭の中にある知識に頼らざるを得ない場合があります。
このように上流での影響範囲の洗い出しはなかなか一筋縄ではいかないことも多いので、テストフェーズで「変更しなくていい部分が想定外に変わってしまっていないか？」を確認する目的でデグレチェックを行うのですが、ここについてはオンライン処理・バッチ処理など機能の特性によってやり方を変えなければならなかったり、テストデータも改修に関係ない部分についても様々なパターンを集めなければならなかったりして今まさに苦戦しているところです（改修に関係のある部分は狙ってデータ集めを行うのでやりやすいのですが、関係のない様々なパターンのデータ、となると狙うと集まらないデータだったりするので難しいのです）。
頻繁に改修が入ることを考えると基本的なパターンのテストは自動化する、などまだまだ工夫できる余地がありそうですが、「要件通りのシステムになっているのか確認・検証する」という部分はまだ自分の中でノウハウが足りないのでこのあたりのスキルももう少し勉強してちゃんと「動くソフトウェア」を届けられるようになりたいな、と思うのがこの頃です。
第10回はアジャイル宣言の背後にある原則その7「動くソフトウェアこそが進捗の最も重要な尺度です」について、「プロジェクトの外にいる人たちとのコミュニケーション」と「動くソフトウェアづくり」の二つのトピックを紹介しました。
次回はその9「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
