皆様こんにちは、アジャイル開発＆DevOps推進担当の川上です。アジャイルは成長、変化に強い開発手法ですが、今回は新規のサービス開発だけではなく、既存業務やシステムの改善とアジャイルの良い関係について書いてみたいと思います。
部門横断にその道のプロを召集し、改善点を抽出
写真は、あるプロダクトの改善プロジェクトでユーザーストーリーマップを作成しているところです。（ユーザーストーリーマップについては、Jeff Patton氏の著書、ユーザーストーリーマッピングなどに詳細が記載されています）
写真に全員は映っていませんが、このユーザーストーリーマップの作成には、総勢10人のメンバーが集まって、ああでもない、こうでもないと議論しています。プロダクトオーナー、開発部門、運用部門、業務部門というメンバーでお題は「如何に早くお客様にサービスを提供する為に、バックヤードの業務部門はどのような改善を行えば良いか？」というものです。ユーザーストーリーマップの詳細説明は割愛しますが、ポイントは「業務に関わる部門のメンバーが全員参加しているか」という点になります。プロダクト（サービス）を良くする為に、今の業務の棚卸しと、改善ポイントの洗い出しを一緒にやることで、全員が同じ背景を共有した状態で、議論が出来ると活発な意見が出やすくなります。また、皆が壁のポストイットを見て話をしている点から分かるように、課題を洗い出すことに集中します。よく会議でありがちな、「誰々が悪い」という対立を生みづらい環境を作り易くするのです。
KPIを明確にしよう
改善のユーザーストーリーマップの1枚のチケットの記載内容には、ちょっとした工夫があります。ユーザーストーリーマップの各アクションで、「どれくらいの時間がかかり、月にどれくらいの件数があるのか」を明確にすることです。これを書く事によって、「今、自分たちがどの作業に時間を取られているのか」というのが明確になります。さらに言うと、どのアクションを改善するのが最も効果的かを定量的に判断出来る様になります。月に沢山件数があって、時間も掛かるアクションを改善すべきなのは誰の目に見ても明らかですよね。
ただ、その情報を、１人のメンバーで全てを書き出すことは困難です。ですから、業務を深く知っているメンバーがそれぞれの知識を全て出してもらうのです。また、こうやって定量化すると、優先度に納得感が出るという効果もあります。自分の業務を軽くして欲しいと誰もが思いますが、残念ながらリソースは有限です。その中で、改善効果が高い物から実施するという方針を取った時に、時間という効果が明確になりますよね。気持ち的なところは置いておいて、明確な判断規準があるということは、物事を決定する際に、大きなメリットになります。
小さな改善の積み重ねが大きな成果となる
1週間や、２週間で出来る改善というのは非常に少ないかもしれません。また、システム開発が必要な場合は、数ヶ月かかる場合ももちろん有ります。しかし、小さな改善を一つずつ積み重ねることが大きな成果に繋がります。リーンやアジャイルの小さく作って、大きく育てる考えはここでも活かされるのです。新規のサービス開発だけではなく既存の業務や、システム改善についてもアジャイルのアプローチは有効です。皆様も是非トライしてみてはいかがでしょうか？