このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その12「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」についてです。
振り返りの重要性
プロジェクトは定義から考えてわかる通り、独自性の高いものです。
プロジェクトで起こる様々な事象は膨大な変数の組み合わせの結果であり、何がよかったのか？逆に何がいけなかったのか？を特定することは、とても骨が折れる作業であることに間違いはありません。
とはいえ、振り返りをしなくていいわけではありません。全ての因果関係を明らかにすることは難しくても、何か一つでも原因の仮説を立ててその部分を変えてみる、という地道な仮説検証のプロセスによって、少しずつでもプロジェクトの進むべき道をチューニングしていく必要があります。
しかし、そうはいっても次に活かすことのできる場がなければ、なかなか本気で振り返ることは出来ないでしょう。その点では、反復的に開発を進めていくアジャイル的なアプローチは有効です。
要件定義→設計→テスト→導入のサイクルを何度も回すことになるため、何かうまくいかなかった点があれば「次のサイクルではどうずればよいだろう？」と考える動機が必然的に生まれます。何も考えずに同じことが起きれば、いつか見た景色として「あれ、これ前も見たことある・・・」となりさすがになぜ同じループに入ったのか考えます。このように必然的に振り返りがなければ同じ失敗を繰り返す、という状況があれば、おのずと振り返りが促進されるのではないでしょうか。
自分自身「ああすればよかった」「こうすればよかった」と反省することばかりですが、少し時間が経てば「早めに失敗しておいてよかった」と感じることも多々あります。もちろん落ち込みもするのですが（笑）、上手くいかなかったときは少し立ち止まって都度振り返り、素早く軌道修正することで失敗を生かすことを心がけています。
担当領域のオーバーラップで柔軟な役割変更を可能にする
失敗を活かすというのは、誰がやっても限りなく失敗しようがない形で仕組みに落とすハード面での整備と、コミュニケーションの仕方やパスの見直しなどのソフト面の整備の両面があるように思います。特にソフト面の整備は機能横断的なチームを目指すアジャイルな進め方では非常に重要だと思っています。
この事例で紹介しているプロジェクトは、初期導入時における主要メンバーが徐々に卒業しており、世代交代のタイミングです。人への依存度が比較的高いアジャイルアプローチを取ってきたこのプロジェクトでのメンバーのローテーションは、プロジェクトにとっての新たな挑戦でもあります。
結局組織は個の集団であることを考えれば、メンバーの入れ替わりや職場環境の変化によってチームにとっての最適なやり方が変わってくるのは当然であり、内部要因・外部要因を敏感に捉えながら最適な役割配置を考え、定期的に調整していくことに終わりはないのだと思わされます。
また、調整をかけたいタイミングで調整可能にするためには、チームメンバー一人ひとりが自分の現在の役割に閉じず、日頃から担当領域の周辺領域に触れておくことが重要なのだと思います。ITプロジェクトでは担当領域を全うすることですら難易度の高いことですが、各担当領域をオーバーラップさせておくことで柔軟な対応が可能になると思っています。時に明確な役割区分のなさに戸惑うこともありますが、それがこのアプローチの楽しさでもあるのかな、と感じています。
第12回はアジャイル宣言の背後にある原則その12「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」について、プロジェクト活動の振り返りについて考えていることを紹介しました。
次回はいよいよ最終回！その5「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
