やっと腹落ち「スプリント毎に動くモノをリリースする」〜ゼロから始めるメガバンクグループのアジャイル実践〜

メガバンクにおけるこれまでの開発方法と課題
三井住友銀行では、従来から綿密な要件定義に基づき慎重に進めるカッチカチの「ウォーターフォール開発」が主流でした。
しかし、最近では銀行グループとして提供するプロダクトの幅が広がり、状況に応じた柔軟な開発手法が求められるようになっています。たとえば、インターネットバンキングのように慎重な開発が必須のものもあれば、金融関連情報サイトのように一定の失敗が許容されるものもあります。これまでは後者であっても一律でウォーターフォール開発を適用していました。その結果、リリースまでに長い期間がかかり、ユーザーニーズの変化に対応しきれないことがしばしば発生していました。実際に、ニーズに合わないプロダクトをリリースし、それに気づくまで半年から1年が経過しているケースもありました。

メガバンクにおけるアジャイル導入の動き
こうした課題を解消するため、銀行でも一部のプロダクトにアジャイルを導入する動きが始まっています。
私が所属するSMBCグループの株式会社プラリタウンでは、法人のお客さまのDX・デジタル化支援を行っています。現在、その支援をさらに加速させるために新規プロダクトの開発を進めており、その過程でアジャイルをゼロから導入しました。このセッションでは、その経験から得た知見を共有します。

「スプリント毎に動くモノをリリースする」は大事、だけど難しい
従来の手法では、長期間の開発後に初めてユーザーの反応を確認するプロセスでした。今はアジャイルを導入したことにより、開発中からユーザーのフィードバックを細かく得られるようになり、ユーザーに真に求められるプロダクトを開発できるようになりました。しかし、最初からスムーズに進められたわけではありません。

具体的には、以下の課題に直面しました：

・プロダクトに必要な機能を細かく分け、スプリントごとに最小単位で作るという考え方が浸透していなかった。
・各機能の開発規模が見積もれず、短いスプリント期間内で動くモノを作る計画づくりができなかった。

これらの課題を克服し、「スプリントごとに動くモノをリリースする」体制を構築する上で重要だったポイントは次の2つです：

1. ユーザー視点でプロダクトバックログアイテムをスライスする方法を理解した。
2. 機能の実現方法について、開発者のアイデアを積極的に取り入れた。

これにより、プロダクトバックログを作成して作るべき機能を適切に分割できるようになりました。また、プロダクトオーナーである私一人で考えるのではなく、チーム内のエンジニアと協力することで、より現実的かつ実現可能なスプリント計画を策定できるようになりました。

このセッションでは、上記ポイントを深掘りし、具体的な手法や得られた気づき、学びをお伝えします。

Transcript

1. やっと腹落ち 「スプリント毎に動くモノをリリースする」 〜ゼロから始めるメガバンクグループのアジャイル実践〜
2. 自己紹介 SMBCグループ　株式会社プラリタウン システム企画部　プロダクトチーム チームリーダー 西本 拓視（たくみ） 略歴 2013年　　（株）三井住友銀行入行 2015年　　インターネットバンキングの企画開発やカードローンのプロモーションを担当 2018年　　外部企業に出向　→　家電の企画を担当 2020年　　（株）プラリタウンを設立　→　お客さま向けWebプロダクトや社内業務システムの企画開発を担当 2024年　　プロダクトチームを立ち上げ、アジャイル開発にチャレンジ開始！
4. 本日のセッションのアジェンダ • メガバンクでのソフトウェア開発あるある • アジャイル開発してみたけど上手くいかなかった話 • スプリント毎にリリースするためのやったこと • スプリント毎にリリースしたら良かったこと
5. まずはメガバンクでの ソフトウェア開発あるある
6. メガバンクの事情 • 決済システムの重要性から、カッチカチなウォーターフォール開発が必須 • 要件定義からテストまで、エンジニアの工数が一般企業の数倍 • 例えば、Webページの静的文言の変更でも1人月がかかることがある
7. ソフトウェア開発におけるあるある • 開発に半年から1年かかることが多い • その結果、実際のニーズに合わないプロダクトをリリースしてしまいがち • その事実に気付くまでにも時間がかかる
8. ソフトウェア開発におけるあるある 作るものを 検討する 作る リリースし 反応を見る ユーザーへの 理解が深まる
9. ソフトウェア開発におけるあるある 作るものを 検討する 作る リリースし 反応を見る ユーザーへの 理解が深まる 9ヶ月 3ヶ月 6ヶ月
10. ソフトウェア開発におけるあるある 作るものを 検討する 作る リリースし 反応を見る ユーザーへの 理解が深まる 分かったことを 次に活かせたとして 1年半後なんですが？
11. 具体的なあるある失敗事例 • やったこと ◦ カードローンの申込フォームの改修 • 問題点 ◦ 開発に割ける工数が限られていた ◦ レガシーシステムの仕様で変更できない部分があった ◦ 他にやることが多すぎて ユーザーへのヒアリングができなかった • 結果 ◦ 時間をかけたにもかかわらず、劇的な改善効果を得ることはできなかった • リリース後に気づいた超残念ポイント ◦ 会社名カナの項目に 15文字以内の制限があり、 16文字以上の会社名の場合は途中までしか入力 できなかった。
12. 具体的なあるある失敗事例 • やったこと ◦ カードローンの申込フォームの改修 • 問題点 ◦ 開発に割ける工数が限られていた ◦ レガシーシステムの仕様で変更できない部分があった ◦ 他にやることが多すぎて ユーザーへのヒアリングができなかった • 結果 ◦ 時間をかけたにもかかわらず、劇的な改善効果を得ることはできなかった • リリース後に気づいた超残念ポイント ◦ 会社名カナの項目に 15文字以内の制限があり、 16文字以上の会社名の場合は途中までしか入力 できなかった。 期間はめっちゃ長いのに ヒアリングや開発時間が 取れないのはなぜ？
13. ソフトウェア開発が うまくいかない環境を 改善するためにやったことは？
14. 短い期間で動くものを作り 作ったものを触ってもらうことでニーズに合わせていく • プラリタウンの取り組み ◦ 法人のお客さまのDX・デジタル化支援を行っている • アジャイルの導入 ◦ 支援をさらに加速させるために新規プロダクトの開発を進めている ◦ その過程でアジャイルをゼロから導入 • 銀行でのアジャイル導入事情 ◦ 情報提供サイトなど、比較的失敗が許容されるシステムの開発においてアジャイル導入が始まって いる そこでアジャイル！ ここが大事
15. これが理想 作るものを 検討する 作る リリースし 反応を見る ユーザーへの 理解が深まる
16. これが理想 作るものを 検討する 作る リリースし 反応を見る ユーザーへの 理解が深まる ここまでを1週間 学んだことも すぐに活かせる
17. アジャイルで良い感じ！ と思いきやそう上手くはいかず … 次はアジャイル開発してみたけど 上手くいかなかった話
18. 短い期間で動くものができない • 理由その① ◦ 価値提供ができるものを最小単位で作ると言われても … ◦ 「最小単位」ってどんなレベル？？勘所がなかった • 理由その② ◦ 1週間でものを作るということがイメージできない ◦ イメージできないので具体的な計画が立てられない
19. 初手から難しい 作るものを 検討する 作る リリースし 反応を見る ユーザーへの 理解が深まる 1週間で作れる 価値のあるもの？ なにそれ？
20. もうちょっと具体的に知りたい！ 「業務フロー見える化サービス」における 「価値があるものってこういうことでしょ？」 の例
21. 何を
22. 誰が 何を
23. 誰が 何を 何を 使って
24. 誰が 何を 何を 使って アイテム 候補
25. 誰が 何を 何を 使って アイテム 候補 追加空間
26. 誰が 何を 何を 使って アイテム 候補 追加空間 修正
27. 誰が 何を 何を 使って アイテム 候補 追加空間 修正 修正 交換
28. 誰が 何を 何を 使って アイテム 候補 追加空間 修正 修正 交換 削除
29. 誰が 何を 何を 使って アイテム 候補 追加空間 修正 修正 交換 比較対象 削除
30. 誰が 何を 何を 使って 隠せる 追加空間 修正 修正 交換 比較対象 削除
31. 価値があるものってこういうことでしょ？ • 業務フローの改善をするためには「誰が」「何を」「何を使って」を並べられることが 必要で、もちろん並べている間にミスすることや抜けていることに気づくこともある ので「削除」も必要だし「交換」することも必要。あ、最後尾に追加する時に追加の 仕方が分かりづらそうだから点線の枠を用意して追加できることを分かりやすくす るのも必要かも。それと、もちろん業務フローに並べるアイテムを全部書いていくの は面倒なので、よく使うアイテムは「アイテム候補」に入れといて配置しやすくする必 要もある。もちろん、業務フローの改善なので現在と理想の姿を比較することで改 善ポイントに気づけるので、現在のフローだけでなく理想のフローも作って比較する 機能も必要！ ここまでできればユーザーは現状の業務フローの改善点を理解できて 理想の業務フローに向けて進むことができる！
32. 誰が 何を 何を 使って 隠せる 追加空間 修正 修正 交換 比較対象 削除 つまりここまで 全部できてこそ １つの価値
33. 膨れ上がってしまって スプリント内に収まらない規模に 例で出したくらいだとやれちゃうかも…
34. 膨れ上がってしまって スプリント内に収まらない規模に 例で出したくらいだとやれちゃうかも… この時は率直に どんな気持ちでした？
35. この状況を解消したい！ スプリント毎にリリースするために やったこと
36. 改善するためにやったこと 1. プロダクトバックログアイテムを細かくスライス 2. 機能の実現方法は開発者に任せる
37. プロダクトバックログを細かくスライス • 業務フローの改善をするためには「誰が」「何を」「何を使って」を並べられることが 必要で、もちろん並べている間にミスすることや抜けていることに気づくこともある ので「削除」も必要だし「交換」することも必要。あ、最後尾に追加する時に追加の 仕方が分かりづらそうだから点線の枠を用意して追加できることを分かりやすくす るのも必要かも。それと、もちろん業務フローに並べるアイテムを全部書いていくの は面倒なので、よく使うアイテムは「アイテム候補」に入れといて配置しやすくする必 要もある。もちろん、業務フローの改善なので現在と理想の姿を比較することで改 善ポイントに気づけるので、現在のフローだけでなく理想のフローも作って比較する 機能も必要！
38. プロダクトバックログを細かくスライス • 業務フローの改善をするためには「誰が」(ｻｸｯ) • 「何を」(ｻｸｯ) • 「何を使って」並べられることが必要で、(ｻｸｯ) • もちろん並べている間にミスすることや抜けていることに気づくこともあるので「削 除」も必要だし(ｻｸｯ) • 「交換」することも必要。(ｻｸｯ) • あ、最後尾に追加する時に追加の仕方が分かりづらそうだから点線の枠を用意し て追加できることを分かりやすくするのも必要かも。(ｻｸｯ) • それと、もちろん業務フローに並べるアイテムを全部書いていくのは面倒なので、よ く使うアイテムは「アイテム候補」に入れといて配置しやすくする必要もある。(ｻｸｯ) • もちろん、業務フローの改善なので現在と理想の姿を比較することで改善ポイント に気づけるので、現在のフローだけでなく理想のフローも作って比較する機能も必 要！
39. 初めて細かくスライスする時にポイントになったこと • 小さくスライスしましょう！と言っただけでは進まない ◦ 開発ベンダーに一括で依頼していたので足りなかった時のリスクを気にする ◦ 少しずつ作っていく経験がないので最初は一緒にやる • 「ちょっとだけ良くなったね」で良い ◦ どうしても「私が今思う完璧なもの（恥ずかしく無いもの）」を考えてしまう ◦ 「これだけでもユーザーがちょっと嬉しくなりますね」 →プロダクトバックログアイテムへ ◦ 足し算の要素を分解する • ユーザーが本当に欲しいのはどこまでか分からない ◦ 実はこんなに網羅的にやらなくても十分かもしれない ◦ むしろ無い方が使いやすくなるものもある ◦ 最初のイメージからどれくらい引き算できるか、足さないで済むか
40. 機能の実現方法は開発者に任せる • 「考えている通りに作ってもらう」から「みんなでよりベターなものを作る」
41. 機能の実現方法は開発者に任せる • 「考えている通りに作ってもらう」から「みんなでよりベターなものを作る」 UIの詳細 機能の詳細 処理の詳細 スケジュール POが解決策まで考えて 考えたことが100%伝わるように 作るモノの詳細を伝える
42. 機能の実現方法は開発者に任せる • 「考えている通りに作ってもらう」から「みんなでよりベターなものを作る」 UIの詳細 機能の詳細 処理の詳細 スケジュール POが解決策まで考えて 考えたことが100%伝わるように 作るモノの詳細を伝える 解決したい 課題 UIの イメージ 受け入れ 条件 ユーザーが解決したいこと スプリントで達成して欲しいこと を伝える
43. 機能の実現方法は開発者に任せる • 「考えている通りに作ってもらう」から「みんなでよりベターなものを作る」 UIの詳細 機能の詳細 処理の詳細 スケジュール POが解決策まで考えて 考えたことが100%伝わるように 作るモノの詳細を伝える 解決したい 課題 UIの イメージ 受け入れ 条件 ユーザーが解決したいこと スプリントで達成して欲しいこと を伝える POの負荷が減ってプロダクトバックログアイテムを作る速度がアップ POが考えるより楽に実現できる＆メンテナンスしやすいモノができる
44. カイゼン完了！ スプリント毎にリリースしたら良 かったこと
45. スプリント毎のリリースはこんなに良い！ • ユーザーニーズとのギャップが小さいものを作れた ◦ セールス担当に何度もフィードバックをもらえた効果 • 徐々に質とスピードが上がっていった ◦ 集中すべきものへの理解やユーザーへの理解が徐々に高まってきた結果 • チーム内のコミュニケーションが闊達になった ◦ プロダクトバックログの透明性が高まり何をすれば良いか認識が合ってきた結果 • 反省点：初手から必要のない機能まで作ってしまったこともあった ◦ ここまで必要だろう！は外しがち … ◦ 細かくスライス＆高頻度なフィードバックの結果、すぐに機能を削除できたのでセーフ！
46. 余談：フィードバックをよりリアルにするために • スプリントレビューでセールス担当（ユーザー）にロープレを依頼 1. サービスを使う状況をレビュー参加者に共有する 2. サービスを使用する登場人物（ユーザー）を共有する 3. セールス担当にユーザー 1とユーザー2のロープレをお願いする 4. スクラムチームはロープレの様子を観察 5. ロープレ後にセールス担当に感想コメントをもらう
47. 今後に向けて • 中小企業の経営者に向けた新規プロダクトを企画中 ◦ 生成AIを活用したプロトタイプ作成 ◦ プロトタイプを用いたユーザーヒアリング ◦ 企画のブラッシュアップ • これからはより本格的にアジャイル開発を実践してきます • メンバーもチームも増やしていきたいのでメンバー募集中です！
48. 最後に言いたいこと • スプリント毎にリリースすることでユーザー視点でのプロダクトに近づける • 細かくスライスすることでスプリント内でリリースができる • 自分だけでなくチームで作ることで質もスピードも上がる
49. 最後に言いたいこと • ユーザーのフィードバックで自信とテンションが上がる • リリースでもレビューでも良いのでしょっちゅう触ってもらおう！ • しょっちゅう触ってもらうためにカイゼンを！
50. やっと腹落ち 「スプリント毎に動くモノをリリースする」 〜ゼロから始めるメガバンクグループのアジャイル実践〜