Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイル未経験の部署と取り組んだ銀行システム開発/Bank system development with agile inexperienced department

8f62db39ce3717b159970703a8040492?s=47 matsukurou
January 05, 2022

アジャイル未経験の部署と取り組んだ銀行システム開発/Bank system development with agile inexperienced department

RSGT2020での登壇資料です。

8f62db39ce3717b159970703a8040492?s=128

matsukurou

January 05, 2022
Tweet

More Decks by matsukurou

Other Decks in Business

Transcript

  1. アジャイル未経験の部署とどう取り組んだ? 〜新チームと部署の垣根を超えて取り組む銀行システム開発〜 Kazutaka Matsusaki / Kunihiro Kuroda

  2. 松崎 一孝(まつさき かずたか) ふくおかフィナンシャルグループ ビジネス開発部(アジャイル開発チーム)
 
 兼職 IPAアジャイルWG
 
 仕事 ゲームエンジニア 


       → スクラムマスター(3年)
      アジャイルエバンジェリスト(自称)
      → 組織にアジャイルを広める人
 
 趣味 野球・ゴルフ・マラソン・読書
    
 特徴 ヤクルトファン・極度の紫好き
 自己紹介
  3. 黒田 訓弘(くろだ くにひろ) ふくおかフィナンシャルグループ ビジネス開発部(アジャイル開発チーム)
 
 仕事 エンジニア(webフロントエンド) 
    → エンジニア(web全般)

    
 
 趣味 釣り・ドライブ・料理
    
 特徴 騎手を目指していたので特技は乗馬
 自己紹介
  4. 銀行での開発、どんなイメージですか? Discordにどうぞ〜!

  5. 思ってもらえると良さそうなこと 銀行がやっているなら 自分たちもできる

  6. 実際は 伝統的な長机 自由なレイアウト スーツ!!! 私服 おやつもね 新旧文化の融合

  7. RSGT2020でお話したこと https://speakerdeck.com/matsukurou/how-to-create-an-agile-organization ・初のスクラムマスターでの失敗 ・銀行内での取り組み ・銀行外での取り組み

  8. 2年で変わったこと ・スクラムマスター ・開発チーム 開発組織のベースはできてた ※ 人数・チーム数はイメージです

  9. 今回の挑戦 SM PO 開発チーム 同一部署 PO スクラム経験者 スクラム未経験者 他部署 SM

    開発チーム 同一部署 アジャイル?内 製?? スクラム? 知ってるけど… プロダクト 本業 制約いっぱい 関係者多数 開発チーム 新規事業
  10. ミッション 新チームの立ち上げ プロダクト開発を進められる状態にする チームとして成長し続けられる状態を作る 1 2 3 他部署との協働の実現 より良い活動の方法を模索する POの育成にも取り組む

    本業に関わる開発の実施 開発の勘所や注意点を探る あとに続く他チームへの展開 今回は話さない それぞれの視点 での取り組み ・開発チーム ・SM
  11. 経験から学ぶ はじめてのスクラム FFG ビジネス開発部 黒田訓弘

  12. エンジニア歴 2〜17年 平均年齢 31歳 男女比 1:1 チーム歴 1年半 キャリアチェンジ銀行員 x

    2名 中途採用エンジニア x 2名 メンバー構成 100%モブプログラミング 開発手法 ATDD ほぼ完全リモートワーク 僕たちの開発チーム
  13. 投資信託の申込関連サービス ↓ 銀行の本業 JavaScript(Vue.js) Java(SpringBoot) 技術スタック AWS インフラ MySQL 僕たちのプロダクト

  14. 今日お話ししたいこと 󰢏 経験と振り返りが大事 経験する(成功も失敗も) 振り返る(言語化・見える化)

  15. 本題に入る前に... 僕たちの振り返り手法 ・毎日の振り返り(鮮度重視)15分 ・スプリントの振り返り(深さ重視)1時間 Day1 Day2 Day3 Day4 Day5 Sprint

  16. 今日お話ししたいこと 󰢏 経験と振り返りが大事 経験したこと どう振り返ったか エピソードを紹介

  17. EPISODE I 開 発 手 法 の 探 索


  18. EPISODE I 開 発 手 法 の 探 索
 -

    チーム結成からほどなくしてモブプロ - オンボーディングも兼ねられた - 開発の遅延 経験したこと
  19. EPISODE I - スループットを上げたい - ソロ開発はどうか? - 品質低下の懸念 - チームを2分割して、それぞれでペアプロしよう

    - ナレッジ分散の懸念 - 実装後に共有会の実施 - 1スプリント毎にメンバー入れ替え 振り返ったこと 開 発 手 法 の 探 索

  20. EPISODE I 経験したこと - チームを2分割してそれぞれでペアプロ - スループット向上 - 共有コスト増・手戻り -

    チーム間の軋轢 - 実装方針やテスト粒度に対する意見相違 - メンバーが入れ替わってもチーム間対立は起き た! 開 発 手 法 の 探 索

  21. EPISODE I - スループットはあがったように見えたが... - 長期的に見ると下がっているのでは? - 手戻り修正が発生 - コードの一貫性が低下

    - 全員でモブプロする手法に戻してもいいのでは? - 結成当初よりメンバーの開発スキルが向上してい るから! 振り返ったこと 開 発 手 法 の 探 索

  22. EPISODE I - 再び全員でモブプロ - 手戻り修正の削減 - コードの一貫性が向上 - 以前ほどの遅延は発生せず

    経験したこと 開 発 手 法 の 探 索

  23. EPISODE I - チームメンバーや状況によって最適な開発手法は異な る - 過去に取り組みをやめた手法であっても、状況が 変われば採用できる 開発手法の振り返り 開

    発 手 法 の 探 索

  24. EPISODE II P O と の 関 係 性


  25. EPISODE II P O と の 関 係 性
 -

    最初期:週1のレビューを行う関係 - 大まかな課題・マイルストーンを共同作成 - リファインメント・プランニングは開発Tのみ - (POが物理的に時間を割けなかったため) - PBIも開発チームが起票 - 実装後「この機能、不完全じゃないですか?」 経験したこと
  26. EPISODE II P O と の 関 係 性
 -

    方向性のズレを検知するのがレビューのみ - もっと早い段階で検知したい - 課題に取り組む前に検知したい 振り返ったこと
  27. EPISODE II P O と の 関 係 性
 -

    過渡期:一緒にリファインメント・プランニング - POにも参加してもらう - 課題起票・更新は開発チーム - (POがツールに不慣れだったため) 経験したこと
  28. EPISODE II P O と の 関 係 性
 -

    まったく見当違いなことは起きなくなった - レビュー後の微調整は依然として発生 - もっと頻繁にPO確認したい 振り返ったこと
  29. EPISODE II P O と の 関 係 性
 -

    過渡期:一緒にデイリーも - POにもデイリーに参加してもらう - その日の成果物をデモ - POからフィードバック 経験したこと
  30. EPISODE II P O と の 関 係 性
 -

    その日の進捗をその日のうちに見てもらえる - POからのレビュー後の修正依頼はなくなった - デイリーが長くなった - デイリーをやる前に確認してほしい 振り返ったこと
  31. EPISODE II P O と の 関 係 性
 -

    最近:仮実装が済んだらPO確認 - 仮実装が済んだ時点でデモ - デモしながらライブコーディングで修正も - デイリーが短縮された - 日をまたがない修正イテレーション 経験したこと
  32. EPISODE II P O と の 関 係 性
 -

    コミュニケーション頻度はプロダクト品質に直結 - 早めの修正で無駄な時間を減らせる - ただしコミュニケーションの質にもこだわらないと本 質的でない注文も増える POとの関係性改善の振り返り
  33. EPISODE III ま と め


  34. EPISODE III ま と め
 - 自分たちの姿を常に振り返り続けること - 成長は振り返り・仮説・検証により生まれる -

    POとのコミュニケーション頻度向上 - プロダクト品質・改善スピードが劇的に変わる 経験したこと
  35. EPISODE III ま と め
 - 毎日の振り返り(鮮度重視)とスプリントの振り返り(深さ重視)の組み合 わせがシナジーを生んだ - どちらかだけでは片手落ち

    - タスクにフォーカスしがちだけど、チームとしての取り組みに目を向けるべ き - タスク単位だと再現性が低い 振り返りを振り返って
  36. EPISODE III ま と め
 - 振り返りを習慣化すること - メンバー相互に忌憚なく会話できる関係性の構築 充実した振り返りにするために...

    が大事
  37. EPISODE III ま と め
 そのための 確約(commitment)・勇気(courage)・集中(focus) 公開(openness)・尊敬(respect)

  38. EPISODE III ま と め
 あらためて チームメンバーに 感謝

  39. EPISODE III チ ー ム の 声(チームの活動で良かったこと)
 モブプロ POとの関係構築 チーム1on1

    いろいろ話せる いろんな意見が出る その分衝突もするけど 関係者全員での ふりかえり 異業界メンバー との交流
  40. ここからの話(SM視点での取り組み) 新チームの立ち上げ プロダクト開発を進められる状態にする チームとして成長し続けられる状態を作る 1 2 3 他部署との協働の実現 より良い活動の方法を模索する POの育成にも取り組む

    本業に関わる開発の実施 開発の勘所や注意点を探る あとに続く他チームへの展開
  41. PO・開発チームあるある • 会話をするのがプランニングとレビューの時だけ • 会話をする人が決まっている • 「POが」「開発チームが」という他責 • PO >>

    開発チーム の力関係 • 納期に追われ続ける開発チーム
  42. 内製開発チームを作ったものの 社内外注 あるあるが改善されないと…

  43. 目指したこと 一体感

  44. ありたいチームの姿 • PO、開発チームがプロダクトに集中できる • チーム全体で気軽にコミュニケーションがとれる • お互いに助け合える • チームが成長できる •

    締めるとこはシメる チームがいきいきと活動できる
  45. ありたい姿を実現するために POサイドに対して取り組んだ場作り • POとしての活動に集中 • チームで円滑なコミュニケーション

  46. なぜPOとしての活動に集中できない? 銀行員の働き方 • いろんな業務を抱えている • マルチタスクが当たり前 • 全員が手一杯な状態 • 残業めちゃ多い

    にも関わらず、だいたいの目標はやり遂げる(凄い)
  47. 現状のまま、1つのプロダクトに集中してもらう… ムリ! 集中できる場作りの相談

  48. 組織での協力が必要 集中できる場作りのために

  49. 本題に入る前に 小さな案件で アジャイル体験 集中できる場作りへの取り組み

  50. 見えてきた課題 + 感じてもらったメリット アジャイル開発の小さな成功体験 実際にやってみて

  51. 他部署の中に支援者を獲得 これまでできなかった簡単な分析や 試行錯誤しながらの改善が できるようになったのが良かった • 一緒に活動して良かったことは何ですか?

  52. 自部署からの協力 協働するにあたってのお願い(自部署から他部署へ) • 優先順位の低い企画ならば、内製開発を行わない • 優先順位が高いならば、集中できる環境は作れるはず

  53. プロダクトに集中できる環境作りの実現 プロダクト + 関連する周辺業務

  54. ありたい姿を実現するために POサイドに対して取り組んだ場作り • POとしての活動に集中 • チームで円滑なコミュニケーション

  55. コミュニケーションを取るのが困難 働く環境が違いすぎる(協働スタート時) PO 開発チーム SM 作業場所 出社(4階) リモート 出社(9階) +

    リモート メインのパソコン 開発PC 銀行PC 開発PC 課題管理 SaaS Excel SaaS ※ 開発PCと銀行PCは接続できるネットワークが違う ※ 階はイメージです
  56. コミュニケーション改善への取り組み コミュニケーションをとる 心理的なハードルの低減

  57. 心理的なハードルを下げる取り組み 自ら 相手から 全体に • 相手の環境に合わせて始める(ストレスを軽減) • 業務以外の会話にも切り込む(何でも話せる雰囲気) • 困りごとを聞いたらすぐ対応(相談しやすさ)

    • 近場の良き相談相手(味方がいる安心感) • 定期的な場作り • 相互理解を深めるイベント
  58. 心理的なハードルを下げるポイント 困ったらフォローしてくれる 自分のことを知ってくれている 安心感

  59. 取り組むときの注意点 伝言役にならない 安心して始めるための支援(場作り)が役割

  60. PO・ステークホルダーからのコメント • これまでの開発と違って良いと思う部分はありますか? デジタルなものを作っているけど、 関係性がウェットなこと

  61. PO・ステークホルダーからのコメント • 一番印象に残っているイベントは? 自己紹介! あれでどういう人なのか背景とか 知れて話がしやすくなった

  62. 気軽にコミュニケーションがとれる関係性 心理的なハードルの低減 + ツールの活用 (環境面の改善もお忘れなく)

  63. 特徴的な3つの活動 チーム1on1 関係者全員 ふりかえり 相互勉強会 • チーム全員が全員のメンター&メンティー • PO、ステークホルダーも参加 •

    スポットで関わった人も参加 • 活動の意味を認識 • 銀行業務理解、アジャイル理解 • 相互理解を深める オススメ
  64. ありたいチームの姿への前進 • PO、開発チームがプロダクトに集中できる • チーム全体で気軽にコミュニケーションがとれる • お互いに助け合える • チームが成長できる •

    締めるとこはシメる SMの場作り支援 + チームによる継続的な改善
  65. PO育成への取り組み 新チームの立ち上げ プロダクト開発を進められる状態にする チームとして成長し続けられる状態を作る 1 2 3 他部署との協働の実現 より良い活動の方法を模索する POの育成にも取り組む

    本業に関わる開発の実施 開発の勘所や注意点を探る あとに続く他チームへの展開
  66. 大事にしたこと 相談しながら・経験しながら 押しつけではない育成 POもチームの一員 必要性を理解したうえでの行動 自らの意思による決定

  67. 大事にしたこと(アジャイル推進) POというロールがなくなっても 行動が継続できるように

  68. まとめ POとしての活動に専念できる場作り 小さな成果でステップを踏む 支援者をつくる 円滑なコミュニケーションの場作り 支援者になって安全な環境をつくる POの育成 相談による育成

  69. 感じてもらいたかったこと 銀行がやっているなら 自分たちもできる

  70. 次にしてほしいこと アクション!!!

  71. 仲間募集してます