銀行でスクラムなんてどげんしよっと？
生きてます。アジャイルコーチ/スクラムマスターをしています、グナザウルスです。
「どげんしよっと？」は博多弁で「どうやってしているんですか？」という意味です(たぶん)
はじめに
私の所属している組織は、ビジネス開発部アジャイルチームという組織です。
その組織が具体的にどのような取り組みをしているかというと、こんな感じです。
※以下はリンク内容を一部抜粋
デジタル技術進展に伴うお客さまの行動変化や社会構造の変容に対応すべく、“お客さま起点で銀行ビジネス”の再構築を図る「DX（デジタルトランスフォーメーション）」を推進しています。
既存事業の改革はもちろんのこと、将来を見据えた新規事業の創出を並行で行っており、ビジネスの変化の速さに対応するためにシステム内製化組織（開発チーム）の立ち上げとアジャイル開発の導入を2018年から進めてきました。
特に新規事業の創出においては、開発チームが所属する部門に広い裁量権が与えられているため、トライ & エラーを繰り返しながら顧客ニーズにフィットしたサービスをスピーディに作ることができます。
要は、銀行における自社サービスの内製開発組織です！！
そのアジャイルチームが、
・どんな構成で活動しているのか
・スクラムなんてやれるのか
・実際のところどうなの？
なんて話が記事にできたらなと思っています。
銀行システムのイメージ
ところで読者の皆さん。
銀行での仕事だったり、銀行でのシステム開発って聞くと
こんなイメージありませんか？
(私の「銀行システム」「銀行のシステム開発」に対する偏見をダダ洩らします)
・ATMよく止まる
・電文めっちゃ送る
・テストめっちゃ多い
・仕様書山積み
・とりあえずJavaとOracle
・質問したら「調べたの？」と追い返される
どうですか？
イメージ一緒でしたか？
一概に銀行だからというより、「銀行のシステム開発の毛色」と「それを構築するプロセス」からできてきた文化な気がしますが・・・。
以降は、とにかくそんなことはないよ！！
を書いていきます。
数字で見るアジャイルチーム
ここ最近時点の、人数だったり数だったりを公開することで
アジャイルチームってどんな感じかを説明させていただきます！
まずは規模感が伝われば・・・。
(ちゃんと数えるのを諦めてある程度の数字を出しています。ごめんなさい)
・組織の人数：約40人
新卒：5人くらい。
中途：25人くらい。中途採用即戦力組(無駄にハードルを上げてみただけ)
社内公募：5人くらい。キャリアを変えて入ってくる意欲のある人たち
パートナー：5人(本当は6人な気がするけど、合計人数が合わなくなるため)
次にチーム数はというと、
・開発チーム数：7チーム(SRE含む)
SRE以外はプロダクトチームで、それぞれ別のプロダクトを開発しています。
なおスクラムマスターの人数は、
・スクラムマスター：4人
CSM：４人（うちA-CSM：2人）
(ハロー効果を狙って資格取得者を書いてみた)
全4名の多くのスクラムマスターが専任で活動しています。
(実際にどんなイベントをやっているのか？スプリントの期間は？などの詳細は別の機会に・・・。)
グナザウルスについて
全体の人数感が見えたところで改めて自己紹介となります。
以前の記事でスクラムマスターの対談記事を書いたのですが、諸事情により現在の私のステータスはもう少し違います。
支援しているチームは３チームあり(アンチパターンだなんて言わないで・・・)
・開発チーム１：3名
・開発チーム２：3名
・ビジネス企画チーム：5名
です。
どのチームにもロールを兼任せず、専任のスクラムマスターとして活動しています。
スクラムやれるの？
数字や構成で見るアジャイルチームをお伝えしましたが・・・
ここまでの間に
「スクラムマスターがいるからスクラムしてますって成り立たないよね？」
と思った読者の方。
そうです。
間違いないと思います。
ポジションにいくら人間がいてもスクラムマスターの振る舞いをしてくれないと意味がない。
むしろ、スクラムマスターの振る舞いができていれば、ポジションとしてのスクラムマスターは必要ない。
そうなんです。
私たちは例えば・・・
「スクラムガイドにハマったスクラムができているか？」というと
できていない
と思います。
しかし、スクラムの価値や原則という指針やアジャイルのマインドセットをベースに
必要なものを必要な形で取り込み
カイゼンしていく取り組みが
メンバー主体で行える環境があります。
どんな人たちがスクラムに取り組んでいるか
前述の通り、
「スクラムガイド的な”スクラム”」はできていないと思います。(個人の見解)
それでも、例えば”FFGのスクラムマスター”には、
「スクラムやる」ってなんだろう？
とかの疑問を持つスクラムマスターがいます。
「スクラムガイドを守ることがスクラムじゃないよね」
というスクラムマスターがいます。
チームのパフォーマンスのことを専任で考えるためにスクラムマスターがいます。
開発チームは
プロダクトの価値ってなんだろう？
インクリメントの価値ってなんだろう？
プロダクトバックログの価値ってなんだろう？
と話し合います。
そして、開発チームの壁を超えて
他のチームのサポートも
自チーム他チーム問わずメンバーのサポートも惜しみなくできる文化があります。
チームの、組織のパフォーマンスの最大化を考えられるチームがあります。
そんなメンバーがスクラムに取り組んでいます。
スクラムというかアジャイルな話
結局のところのアジャイルチームの空気感の説明をします！
どのチームも
自チームの納期に間に合えばいいというような縦割り状態ではありません。
そんな辛い状態にならないよう、部や課の単位で活動もします(たまに)
もちろん部を跨ぐ時も、「開発チームが納期までに完了できればいい」ではなく他部や他組織の全体と協力して開発をします。
アジャイルチームには
モリモリした計画や書類ではなく
縦割りの階層構造ではなく
正しいものを正しくつくりたい
というマインドがあるような気がします(気がすると言っておく)
とはいえ現実・・・
とはいえ、現実
みんながみんなハッピーアジャイルではありません。
アジャイルのマインドセットになりきれていないこともあります。
その状況もまた、その人にとっての正義で受け入れる必要があります。
どうしても受託ビジネスが長いことによる納品のための慣習みたいなものも出てくる時があると思います。
OutcomeよりもOutputをとることを選ぶこともあると思います。
ビジネス上の上位者とのコミュニケーションロスもあるでしょう。
それでも、ビジネス開発部は
そしてアジャイルチームは
何よりも私たちスクラムマスターは
銀行の組織や文化の変革のために
正しいものを正しくつくる
を一歩づつ進めています！！
まとめ
・アジャイルチームは銀行の内製のシステム開発部隊だ
・真面目にスクラムに取り組んでいる
・スクラムマスターだけでなく、開発者も取り組んでいる
・まだまだ道の途中
宣伝
ふくおかフィナンシャルグループはまだまだ仲間を募集しております！！
https://www.fukuoka-fg.com/recruit_career/requirements/
※効果検証のために「このブログを見た」って言ってもらえると喜びます