Agile Japan 2020 Day1

プロダクトオーナーから見た初めてのアジャイル開発の価値～攻めのITを3社の共創で実現～
2020年11月17日

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

目次

1. スピーカー紹介
2. 銀行におけるシステム開発の現状
3. アジャイルに取り組んだ経緯
4. どのように取り組んでいったのか
5. アジャイルをやってみた価値

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

1１．スピーカー紹介

Copyright © 20152020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

2１．１．三井住友信託銀行株式会社のご紹介►信託銀行は、いわゆる「銀行業務」に加えて、「信託法、信託業法」で認められた業務も併せてサービスを展開しています。

資産形成層個人のお客
さま

就職

結婚
子供誕生

シニア層

退職前後
子供独立

投資信託・財形・積立貯蓄・平準払保険（中長期運用）

住宅ローン・リフォームローン
不動産仲介（自宅購入）

退職

老後

相続

投資信託・ファンドラップ・個人年金（安全性重視）アパートローン・リバースモーゲージ
不動産仲介（売買）・有効活用

年金運用

年金給付
遺言信託・遺産整理・事業承継

法
人のお客
さ
ま

社会・環境変化に対応するための企業の様々な財務・非財務ニーズ
経営企画・社長室

総務・管財

人事・労務

財務・経理

コーポレート部門の複合的な経営課題をワンストップで吸上げ
ファイナンス

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

不動産

年金運用

証券代行
3

１．２．プロダクトオーナー紹介田中 聡（たなか さとし）
三井住友信託銀行 法人企画部 業務プロセス・デジタル化推進チーム
主任調査役
■経歴
・1981年生まれ
・大学卒業後、住友信託銀行（現三井住友信託銀行）に入社
・年金事業で約10年、数理計算や確定拠出年金の商品開発・企画業務に従事した後、企業買収（M&A）に関するファイナンス業務に従事
・2018年からシステム開発を担当し、当社で初めて本格的なアジャイル開発となる本日紹介するプロジェクトを担当
・現在は、本件含めて2つのアジャイル開発PJでPOを務める傍ら、社内業務ルールの制定や、勉強会などアジャイル開発の社内浸透に奔走中■プロダクトオーナーとして心がけていること
・1分でも長く、開発メンバーと時間を共有
・自信をもって即断即決
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

4

１．３．スクラムマスター紹介
寺田 達彦（てらだ たつひこ）
日本電気株式会社 ソフトウェアエンジニアリング本部
経歴：
物流・流通業を中心としたエンタープライズ領域のシステムエンジニア
統合開発環境製品の企画・販促・開発
ソフトウェアエンジニアリングの社内適用・展開■アジャイルとの出会い
2011年に社内でアジャイル開発に関するガイドラインを整備していたところに担当していた製品開発で試行する形で初めて経験。
スクラムマスターとプロジェクトリーダーの違いに苦悩する日々・・・
この経験をもとに社内の開発現場への支援や実プロジェクトでの実践を積んでいく。

日本電気株式会社
事業内容：
社会公共事業、社会基盤事業、エンタープライズ事業、ネットワークサービス事業、グローバル事業
会社HP
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

https://jpn.nec.com/
5２．銀行におけるシステム開発の現状

Copyright © 20152020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

6

２．１．まさにデジタルシフトへの過渡期►FinTech、ブロックチェーンなど新成長領域への創造と改革、既存領域の改善の真っただ中►クラウドネイティブへのリフト＆シフト►ウォーターフォール開発文化にアジャイル開発を導入し、IT資産・システムライフサイクルの変革を促す※2020/9/8 AWS Summit Online JapanAWS で実現する信託プラットフォーム～三井住友信託銀行のデジタルへの挑戦～
執行役員常務 上田 純也 講演資料より抜粋
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

7

２．２．銀行におけるシステム開発の現状►大手銀行としての責任。各システムは社会的影響、利用者影響、規模などを考慮して重要度を設定►ウォーターフォール方式で重要度に応じてきめ細やかな開発業務管理規程が存在►利用部門は要件定義後、UAT（ユーザー評価）までは実質、システム実態が把握できない状態
上位会議体
利用部門
開発ベンダー
ステークホルダ
IT業務推進部システム化企画

対象者が多い！
開発計画

投資判断
要件定義

イメージ図

かなり早期から様々な文書を作る必要がある

品質管理レビュー

開発承認者レビュー

設計(業務AP/基盤/運用)

品質管理レビュー

工程移行判定運用マニュアル
作成

品質管理レビュー

工程移行判定AP実装

要件定義後、システムの実態が初めて見れるのはこの段階

基盤構築
運用実装
試験・評価

ユーザー評価移行評価
移行作業

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

運用引継ぎ

品質管理レビュー

工程移行判定リリース判定本番S-in（運用開始）
8

３．アジャイルに取り組んだ経緯

Copyright © 20152020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

9３．１．銀行から見たアジャイルへのアプローチ►法人事業の営業担当者の業務を改善→革新していくシステムにアジャイル開発を採用►アジャイル開発採用の理由は事業環境、時代背景、開発スタイルの3つの要素を考慮►正解のない中、継続的な改革が求められ、変化する実現イメージを具現化するために挑戦• 事業環境から– 法人のお客様の課題は刻一刻と変化するので一個システムを作って終わりではない– 基幹系ではなく営業系なので必要な機能から出すことで営業担当者にとって効果がある
効用の最大化は全部決めてからではなく順次投入が適している• 時代背景から– SaaSが台頭してきた昨今、IT投資に対してMake or Buyの選択を迫られる– 事業環境と照らし合わせ、果たしてSaaS導入が適しているのか？
作るとしてもウォーターフォールで対応できるのか？
開発中に都度、軌道修正できる柔軟なスクラッチ開発が良い• 開発スタイルから– ユーザー（法人営業担当者）の思いをストレートに伝えられるやり方が必要– 要件を確定させていない状態で開発に携わる全員が全力で走れるスタイルは？

欲しい機能が間違いなく、優先順位の高い順に提供される
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

10

３．２．開発ベンダー側のアジャイルへのアプローチ►三井住友信託銀行様の法人営業支援システムを刷新、新規構築する案件の提案►自社サービスや製品開発ではなくSIをアジャイル開発で行うという、意欲的なプロジェクト►初物の試みが多く、仮説検証型で進めるのにアジャイルは適している• 案件化の切り札がアジャイル開発– 1年半に渡って提案をしてきた領域だが、投資効果の説明が難しく案件化が困難– アジャイル開発を採用することで、初期投資を抑えて段階開発をする方針に転換– PoCを受注、無事に完遂して好評価を得たことで、本格開発につながった！

• 本番稼働する新規システムをアジャイルで開発する– マイクロサービスやDevOpsの導入など挑戦的要素も多く、仮説検証型の開発が適している• 超短納期でのSI– 案件立上げから6か月後、開発スプリント開始からは4か月後に本番稼働開始する
短期計画

ウォーターフォール文化のお客様からの受託SIをアジャイル開発で行うには、何を計画するかNECもお客様自身も手探りの中、プロジェクトがスタート。苦しい局面あったが、一体感をもったチームで無事に本番稼働し、継続強化中。
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

11

３．３．コンセプトやアジャイルを仮説検証►開発予定のシステムの価値が利用者に認められるか検証►初めて取り組むアジャイル開発が新たな価値提供に柔軟、かつ迅速に対応できるのかを検証►小規模のチームを組んでわずか2か月のスピードで検証し実証
作業内容

1W

2W

3W

4W

5W

6W

7W

8W

コンセプト HCDプロセス検討(ワイヤーフレーム策定)
開発の優先順位に従い、段階的に提示
策定
HCDプロセス検討(デザイン策定)
ワイヤフレームをもとにデザインを決定
準備スプリント
開発スプリント#1
開発スプリント#2
開発スプリント#3

開発スプリント#4
リリーススプリント

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

12３．４．仮説検証の様子：その１►システムのコンセプトを確立するためゴールの明確化、課題を共有するワークショップを開催►ペルソナの詳細な定義、利用シーン・シナリオを組み立て►プロダクトオーナーと開発チームの認識共有してからのスタート

画面仕様調整ワイヤフレーム検討

ワークショップの様子
ここでコンセプトを確立する

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

13

３．４．仮説検証の様子：その２►固定したプロジェクトルームを持たない流浪のチーム►関係者が立ち寄りやすく、多くの銀行関係者に見学に来てもらい、スクラムイベントを体験►アジャイルの良さと実際適用するにあたっての課題を事前に把握し、対策を検討▌要求ワークショップ

プロダクトオーナーもプランニング
ポーカーによる見積もりを体験！

銀行側も参加▌デイリースクラム

小規模な雑居ビルの一室・・・

来客用会議室・・・
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

14

４．どのように取り組んでいったのかCopyright © 20152020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

15

４．１．初期リリースまでの道のり
 初期リリーススケジュールと本日のポイント

4月

5月

マイルストン

準備期間

4.3.WaterFall

6月▲要件定義相当
品質管理レビュー

基盤

8月

9月

▲外部設計書
品質管理レビュー

本番稼働移行判定(9/20)▲▲運営引継ぎ（特別調整）

4.3.WaterFall

AP基盤方式設計
機能仕様詰めWorkshop

S-in▲

4.5.Arrange

準備SP

4.8.Scope

開発SP
ﾘﾘｰｽ
SP

7月

#1

#2

#3

4.10.Growth#4

4.4.UnDone!!
4.3.WaterFall
4.7.Quality

基盤方式設計

詳細設計

開発環境
構築

#1
開発環境
評価

#2
本番環境
構築

本番環境
本番環境
単体・結合 分散運用基盤
評価
評価

UATUAT

移行リハーサル

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

移行16

４．２．スクラム体制

Agile支援Qさん

DevOps支援
Pさん

NES
Rさん
デザイン会社

三井住友トラスト・
システム＆サービス

システム上席本部長代理

営業上席事業部長

Product Owner
法人企画部
Xグループ長 Yチーム長田中

Project Manager
Uさん

NEC営業
Tさん

投資部門
IT業務推進部
A部長 Bチーム長
C調査役
三井住友信託銀行

Eさん
Fさん

支援チーム
Scrum Master

ユーザー側の情報システム会社(S&S)も参画
S&S：今後の新たな開発スキル習得
NEC：銀行業務、システム運用ノウハウの把握

寺田
NEC
Nさん
基盤関係支援

NES
Sさん

NEC
Oさん

NES
Gさん
Hさん
Iさん
Jさん

NEC
Kさん

三井住友トラスト・
システム＆サービス

Dさん

開発パートナーLさん
Mさん

DevOps基盤構築

基盤チーム
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

開発チーム
17

４．３．システム開発規程を全て変えたわけではない►自システムの開発に閉じて進められる訳ではなく周辺システムやNW機器、基盤運用部門も関連してくる►周りはみんなウォーターフォールで進むため、連携部分をアジャイルに進めるのは難しい►従来の開発規程の重要となるポイントは変わらず押さえて対応することが円滑なサービス開始に必要
アプリケーション開発以外の作成文書例 ※イメージユーザ部門

文書種類

作成計画
要件定義書
他システム

…

クラウド基盤(AWS)

Gateway

本システム
ELB

機能階層図
業務フロー図エンティティ候補ワークシート
非機能要件一覧
機能/シナリオ対応表
業務タイムチャート図
実現施策/機能対応表
全体システムイメージ図
機能情報関連図
外部インタフェース一覧
情報種一覧
エンティティ候補ワークシート

△○
○
○
○

Gateway…
外部接続サーバ

業務サーバ△‐‐
システム開発計画書
△△
△
△
-

DB

運営部門

システム開発概要
収集データ項目
見積もりとリソース
リリーススケジュール
成果物作成計画書
テスト計画

Web API
企業公開情報,名刺情報
Web Site(企業公開情報)
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

18

４．４．始めから上手くは行かない►挑戦的要素があるからこそ、アジャイル。アジャイルだからこそ最初から上手くは行かない►同じ失敗を繰り返さないためにチーム一丸となって対策を施し、巻き返しを図る►ポイントは早めのアクションを取ることで、それぞれが抱え込まないで進めること
この時点でエスカレーション

大ピンチ!!

開発スプリント#1のバーンダウンチャート

早期エスカレーションでプロダクトオーナー側の上席者と調整、理解頂いた上でのスプリントレビュー
アジャイルは技術面で挑戦的な要素のある案件が多く、プロダクトオーナーへの随時状況報告や、立ち上がり時の支援メンバの確保は極めて重要
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

19

４．５．アジャイルの良さを引き出すために変えたこと►銀行内のシステム開発のため、品質基準もしっかり設定し、品質を作りこむ必要がある►一方で一律厳しく基準を設けることで俊敏性が失われることを懸念►機能を段階的に開発するアジャイルだからこそバックログごとに柔軟に緩急をつけることができるNo

ユーザーストーリーランク001○○ができるようにしたいA

002△△を使えるようにしたいB

003□□が見られるようにしたいS

004

××を常に利用したい

S

005▽▽まで閲覧できるようにしたいB006◎◎を登録できるようにしたい

ストーリのランク

Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

UT相当

FT相当

S

Aランクに加えて、データバリエーションを確認する
データバリエーションは事前に業務内容の有識者であるS&S様にご確認いた
だくか、スプリントレビューで報告する

ランクAに加えて、テスト項目をレビューし、項目の妥当性を確認する

A

C1カバレッジ100%

テスト密度として30件/KL

B

C0カバレッジ100%

テスト密度として25件/KLA

20

４．６．開発ベンダーが考えるアジャイルの初期導入►アジャイル開発の採用は手段であり、「これだとアジャイルじゃない」など、スタイルは気にしない►チームは成長する！を念頭に門戸を広く、誰でも参加できる、誰でも成長できるチームビルディング►開発ベンダーの価値はお客様満足と今までになかったシステムライフサイクルを実現、提供すること▌NECのアジャイル導入支援の考え方– 誰でもアジャイル！
誰でもアジャイル！

• 都合よくスキルをもった要員が集められるとは限らない• 開発経験が不足、プログラミングを知らない人でも活躍できる！！
–

30点のアジャイルでも100点のリリースを！
30点のアジャイルでも100点のリリースを目指す！

• アジャイルを最初から上手く適用することが目的ではない。ビジネスを成功させる一手段• 最初から満点は取れない。習熟具合に応じて柔軟に支援。成長イメージを持って臨む
環境・習熟度合に合わせた品質作りこみへの取組み• お客様の業種やシステムの特性、チームの習熟度によって品質に対するアプローチは様々• アンチパターンと言われるやり方もゴール、目的に対して必要ならやってみる• 成長度合いを見ながら振り返りで議論をしてやり方を徐々に変えていく
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

21

４．７．大事なのはリリースに対して自信を持つこと►審査ゲートも大事だが、一番大事なのはチームが品質に対して自信を持つこと→安心につなげる►あえて価値を生まない品質作りこみのスプリントを置くこと、徹底した品質分析を実施►NECの品質会計のノウハウ、考え方を注入し、初めてのアジャイル開発でも安心してリリースに臨む

品質分析の例■作りこみ原因
直接の原因：MSの返却値から部門コードのキーが消えていたため、画面側で部門コードを取得すると“undefined”になっており、情報開示制御で正常に処理ができなかった
なぜ？：クラスの設定で値が空文字の場合にキーごと削除する設定になっていた
真因：フレームワークの初期設定としてキーごと削除することになっていることを認識していなかった■見逃しの原因
直接の原因：認証機能と連動させて、上席者の設定（担当部署コードの設定なし）で評価をしていなかった
なぜ？：認証のFT相当で本事象を見抜けなかったため、上記評価をする必要を認識していなかった
真因：ユーザID、管理番号を見て認証可否を判定するのみの評価だったため、上席者の場合の部門コードの取得有無が確認できていなかった。（担当者はやっている）■1+n分析
作りこみ観点：サポートに問い合わせた結果、キーごと削除する設定の変更は利用者判断と言われ、現時点での対応（対象16件）はリスクがあるため空文字を取得した場合の挙動を確認（シナリオ７）
見逃し観点：上席者の場合、部門コードのキーが保持されていて、空文字が入っていることを確認
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

22

４．８．リリースに向けたスコープ調整►スプリントレビューでのデモから新たなアイデアは数多く生まれる►リリースに向けてどこまでやるかをスコープを調整する場は必ず必要になる►プロダクトオーナー、開発チームで意見を突合せ、本番運用を考慮したリリース範囲を決める
要望の追加
スコープ調整 プロダクトバックログ：321→417(約1.3倍)» レビューで盛り上がる！

 開発チーム観点スコープ調整例» Wantのバックログの一部を次回ずらす» 機能実装をやめて、運用にて回避» 実装方式を簡易に実現できるよう法に変更

最終的に334ポイントに落着▌プロダクトオーナーから見たスコープ調整の視点
ユーザにとって次回（3か月後）まで待てる物は劣後。1stインプレッションで影響のない物
 予めこのようなバックログも持っておくことが重要と感じた

最低限許容できるユーザベネフィットはどこまでをリリースすれば得られるか？
バックログの積み忘れはプロダクトオーナー側責任で次回開発に回すセキュリティの観点で安全サイドに倒す形で仕様を簡易化（危ないものは見せない）
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

23

４．９．アジャイル開発チームとしての成長►MVPとして初期リリースした後はリリースサイクルを短くする取り組み(半年→3か月→3か月&+1か月)►システムの価値は情報提供の一元化→情報の蓄積→情報の活用→業務の変革へシフト►利用部門からの追加要望も多く、チームのスキルの成長とともに規模も成長していくことに

業務改革は新機能によるデータの蓄積から分析、活用が重要になってくる
煩雑な管理業務のシステム化(2019/12-2020/2 2020/4-6)

ユーザ部門
他システム

…
利用頻度の高い部門の業務効率化機能(2019/10-11,2019/12-2020/2
2020/4-6,2020/7-9,2020/10-継続)

クラウド基盤
Gateway

戦略立案支援機能のシステム化(2020/7-9,2020/10-継続)

本システム
LB
Gateway

…
業務サーバ
DB

企業基本情報の取込み、閲覧(2019/10-11)
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

新聞情報のAPI参照(2019/10-11)
・記事情報
・人事情報/訃報
・表彰など

Web API
企業公開情報,名刺情報
Web Site(企業公開情報)

24

５．アジャイルをやってみた価値

Copyright © 20152020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

25

５．１．プロダクトオーナーから見たアジャイルの価値►アジャイルは銀行の営業担当者の仕事のやり方に近く、親和性が高い►現場に意思決定が早く下せるから開発スピードも自然と上がる►営業支援のみならず、他でも同じ進め方でデジタル改革ができるものと考える• 銀行業務はウォーターフォールの進め方では難しい。システムだけが特別なやり方ではない！
– 銀行業務もお客様の課題を見つけ、営業視点で必要なリソースを結集して解決する– 契約が全て取れなくてもお客様が喜ぶ形で期末に向けて仕上げていく– 皆の知恵を持ち寄り、同じ目標に向かって進める
違和感なく受け入れられる開発手法• 開発スピード– まずはやってみる！だめなら直せばよい。下が決めても後で何とでもなる– 従来のやり方を守るべき領域とTry & Errorでできる世界(Agile)があるはず
後者は金融機関のシステムに対する価値観を変えられる• 今後の展望– 事務進捗管理や銀行ならではのモニタリングサービスの開発にも適用できる– 蓄積したデータをBIツールで分析したり、AIやRPAの導入など夢が広がる！
組織内の仕事のやり方を変えられる
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

26

５．２．最後に・・・►今後のDX領域への挑戦にはアジャイル開発は欠かせない►銀行内のクラウドへのリフト＆シフトの中、業務の変革にアジャイルで切り込んでいくことは重要►チームの成長→システムの成長→ビジネスの成長につながるための一つの事例

変える勇気

変えない勇気攻めの営業業務への変革

ユーザベネフィットの最大化

初心者大歓迎！

品質への考え方、取り組む姿勢

大切なモノ

今後に向けて開発チームから提案を受ける空気

プロダクトオーナー人材を増やす

お客様システムの開発に対する責任

柔軟なスケール

上段：田中
下段：寺田

ご清聴ありがとうございました。
Copyright © 2020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.

27

End of Presentation
Copyright © Sumitomo Mitsui Trust Bank, Limited. All rights reserved

本資料に関わる一切の権利は、他社資料等の引用部分を除き三井住友信託銀行に属し、いかなる目的であれ本資料の一部または全部の無断での使用・複製は固くお断り致します。
28
本資料の内容に関して疑問に思われる点、ご不明な点等がございましたら、弊社営業担当店部等にご照会くださいますようお願い申しあげます。

Copyright © 20152020 SUMITOMO MITSUI TRUST BANK Ltd. all rights reserved.