金融システム開発現場へのアジャイル開発導入 ～アジャイルコーチとしての経験～

株式会社 オージス総研 ○張 嵐、山内 亨和、島本 道夫、藤井 拓

経験報告：

オージス総研のアジャイル開発

• 継続的に実践

• スクラムからエンタープライズアジャイルへ（SAFe：Scaled Agile Framework)

• 普及活動

• 書籍、Web、コミュニティ

2

小

中

大

非ウォーターフォール 反復開発 エンタープライズ アジャイル

1995 2000 2005 2010

◎

◎ ◎

◎

◎

◎

一部アジャイル

UP アジャイル

アジャイル

アジャイル＋UP

一部アジャイル

2015

スクラム

当社アジャイル開発事例

目次

1. 金融システム開発におけるアジャイル開発導入の背景

2. プロジェクトの概要

3. アジャイルコーチによる導入支援のアプローチ

4. アジャイル開発の導入の結果

5. 今後の取り組み

3

1. 金融システム開発におけるアジャイル開発導入の背景

アジャイル開発の現状

• 日本国内

• 当社のアジャイル開発トレーニング売上の成長率の急激な向上に基づき、近年アジャイル開発が浸透に向けた普及フェーズにあると推定される

5

「11th annual State of Agile Report」、Version One、2017

アジャイル開発がもたらしたトップ3のメリット

優先順位 変更への対応

チーム生産性の向上

プロジェクト 可視化の改善

当社アジャイル開発トレーニング売上の推移 • 国外のWeb調査（2016年7月~12月）

• 94%のプロジェクトがアジャイルプラクティスを適用している

• 98%のアジャイルプロジェクトが成功した

ご参考：アジャイル開発導入の難しさに関する専門家の見解

• 日本のユーザー企業とシステムインテグレーターの関係

6

このモデルはうまく行きません…… フィードバックがなかったら、開発したシステムは貧弱になります。 顧客と開発側の関係もリーンにならなければいけません。

Dean Leffingwell さん突撃インタビュー https://www.ogis-ri.co.jp/otc/hiroba/specials/interviewDeanAug2012/

デジタルトランスフォメーションの波による金融システム開発の動き

• 2016年3月、ITを活用した金融の高度化推進に向けたワークショップより

7

「ITを活用した金融の高度化の推進に向けたワークショップ 第2回「ネットビジネスから考える銀行サービスのあり方」の模様」、https://www.boj.or.jp/announcements/release_2016/data/rel160314a1.pdf

アジャイル型開発は、中間段階で顧客に有用性を確認するスタイ

ルがウォーターフォール型と異なるだけであり、決してシステムの品

質を下げるものではない。過去事例をみると、ウォーターフォール

型開発の結果、顧客のニーズとの乖離が生じてしまうケースも見

受けられる。日本の金融システムは、品質を落とさずに顧客ニーズ

に対応していくアジャイル開発手法も修得・共有していけば、海外

企業とも十分勝負できると思う。

当社金融業界の顧客のアジャイル開発への取り組み

• アジャイル開発プロセス標準化への取り組み

• 2014年から、スクラムとXPの考え方をベースにアジャイル開発プロセスを整備し始め、2016年からアジャイル開発プロセスの本格適用を開始した

• アジャイル開発プロセスのイメージ

• 金融システムのフェーズ指向の開発プロセスに対応するため、リリース単位での準備段階、開発段階及びリリース段階を設ける

8

企画

初期要求定義

リリース計画

第1リリース 第mリリース

スプリント1 スプリントn

システテスト1

受け入れ1

・・・ 初期設計

環境構築

システム運用

システム

リリース

スプリント1 スプリントn

システムテストm

受け入れm

・・・ ・・・・・・

リリースm準備

準備段階 開発段階 リリース

当社の顧客がアジャイル開発導入時に抱えた課題

9

標準化されたアジャイル開発プロセスの現場への展開と浸透が不十分

アジャイル開発をどのように始められるか、自分達のプロジェクトに本当に合うかという現場の不安

アジャイル開発プロセスをうまく適用できず、アジャイル開発によるメリットが十分に得られない事例の存在

プロジェクト体制

2. プロジェクトの概要

弊社アジャイルコーチが支援したプロジェクトの概要（2016年度）

11

プロジェクト A B C D

開発規模（人月） 40 60 18 9

開発期間 12 9 6 3

リリース回数 2 2 1 1

ピーク時チームの人数 5 8 3 3

新規・改修 新規 改修 新規 新規

システム開発の目的 基盤の変更に伴うシステムの再構築 規制対応 ユーザー部署の業務効率化

複雑性 高 高 中 低

アジャイル開発導入の理由 エンドユーザーは全社であるため、より使いやすさを追求しながら、設計を確定していくため、アジャイル開発を採用

ウォータフォールを利用したフェーズ1リリース後、100弱の変更要望が提示された。よりユーザーに求められているシステムを確実に作り上げるため、アジャイル開発を採用

ユーザー部署の業務効率化を担っている開発部署であるため、より迅速にリリースできるように、アジャイル開発を適用する。また、部の全体の生産性の向上も期待する

アジャイルコーチの支援期間 6ヶ月 6ヶ月 6ヶ月 3ヶ月

4つのプロジェクトの共通点

12

アジャイルチーム構成及び契約 • アジャイルチームは複数のベンダーから構成される

• 契約は準委任契約である

アジャイル経験 • プロジェクトチームにアジャイル開発経験者がいない

エンドユーザー • ユーザー部署に所属し、拠点が開発チームと異なる

技術 • クラウドサービスやパッケージ製品を利用する開発

プロジェクト体制

3. アジャイルコーチによる導入支援のアプローチ

アジャイルコーチ＝Change Agent

金融システム開発

• 管理・計画重視

• 役割と階層

• システムの安定性

アジャイル開発

• 学び・フィードバック重視

• 顧客、チームの一体化

• 進化し続けるシステム

14

変革e

アジャイルコーチの役割

• アジャイル開発導入並びにプロジェクト目的の実現を支援することを通じ、顧客の組織に小さな変革を積み重ねる

• トレーナーとファシリテータ

• 現場の不安を解消する

• コーチ

• 現場の意識変革のきっかけを作り、アジャイルチームの構築を促す

• 支援者

• アジャイル開発を活用したプロジェクトの成功及び組織への展開準備をサポートする

• 伝道師

• アジャイル開発を現場に浸透させる

15

現場の不安を解消する

16

現場の不安 アジャイルコーチのトレーニング及びファシリテーションによる解消

準備段階 プロジェクトの関係者がアジャイルに関する共通認識を持たせる

アジャイル開発宣言、用語、概念を学ぶため、スクラムの体感ワークショップから支援をスタートする

プロダクトバックログに基づく要求管理はウォーターフォール開発にはない考え方

プロダクトバックログを作成するためのワークショップを開催し、ユーザーストーリーマップやDiscover To Deliverに基づくアジャイル要求手法を部分的に適用する

プロジェクト管理方法 すべての作業を全員に見えるようにプロジェクト運営の方法、及び開発の習慣に変化をもたらすため、可視化するためのツールの利用を促進する

開発段階 PDCAサイクルの構築 スクラムの各イベントを実施することによってPDCAのサイクルを構築する

トレーナーと ファシリテータ

現場の意識変革のきっかけを作る

変革モデル

• ADKAR変革管理モデル

変革のツール

• 予実、品質の可視化

• スプリント単位の振り返り

• チーム内の勉強会

• デイリースクラム

• チームメンバーと1対1の対話

17

Awareness 認識

Desire 欲求

Knowledge 知識

Ability 能力

Rein

forc

e 強化

コーチ

例： 透明性を持つ。都合の悪いこともなるべく包み欠かさず説明する ⇒ デイリースクラムで「困ることは・・・・・・」を必ず言わせる

顧客のスクラムマスターを育成する

• 以下の3ステップで、スクラムマスターをOJTで育成する

• お手本を示す

• ペアでスクラムマスターの役割を果たす

• フィードバックを通じスクラムマスターの1人立ちをサポートする

• スクラムの成果物への点検を通じ、POの役割の遂行、開発チーム機能の維持につながる

18

コーチ

OJTで スクラムチームの成長を促進する

プロジェクトの成功及び組織への展開準備をサポートする

• 目標、及び支援内容を、事前に開発プロセス標準化推進部署、支援先のプロジェクトと所属の組織と合意する

19

支援者

フェーズ

目標

自己組織化 生産性の向上

準備段階 開発段階

アジャイル適用・ 改善の仕掛け

•PDCA（改善）サイクルの形成 •ベロシティの安定

・自主性のあるチームの形成 ・分散された負荷 ・生産性の向上

•アジャイルに関する共通認識を持つ •PBLによる要求管理にシフト

チームの 方向付け

動機づけ 展開準備

アジャイル導入のロードマップ

1ヶ月 2ヶ月 3ヶ月

アジャイル開発を現場に浸透させる

• 勉強会の形式で、プロジェクトと一緒に、自社の標準アジャイル開発プロセスを確認し、自チームと標準の差を認識してもらう

• 週単位で、30分を利用し、特定のテーマに関して、ワークショップ、輪読及び討議の形で実施

• 例：勉強会で、待ち行列の演習を実施し、プロダクトバックログの効果、プロダクトバックログの手入れの必要性を理解する

• プロジェクト現場の状況と考えをプロセス策定の組織にフィードバックし、標準の改定に繋げる

20

伝道師

4. アジャイル開発の導入の結果

アジャイル導入の結果

• プロジェクト目的の達成＋アジャイル開発のメリットの享受

• 大きな事前計画など、開発手続きにかかる労力が低減できた

• スクラムの各イベントの実施、ツールによる可視化により、アジャイルチーム内部、アジャイルチームとユーザー部署間のコミュニケーションが円滑になった

• スプリント単位での開発により、ユーザー部署から定期的なフィードバックをもらうようになったため、よりユーザーがほしい機能を従来より短い期間で提供できた

• ペア作業、作業の可視化及び振り返りを通じ、メンバーの作業負荷の平均化が実現できた

• メンバーは計画策定に参画する意識、生産性を高めていくために自ら改善していく意識を高めることができた

22

後続のプロジェクトでもアジャイル開発プロセスの適用を選択した

例①

例②

例①ユーザー寄りのシステム開発

• 「ヒアリング→開発→デモ→フィードバック」のサイクルで、ユーザーの緊急度の高い要望に迅速に対応できた

• 優先順位高い機能から開発に着手し、実機ベースでユーザー確認を行える為、重要機能のシステム仕様/実装方法を早期にFixする事が出来る

• リリース1の後期に新たな要求が7件が提起された。その内2件のユーザーの緊急度の高い要望が本リリースに含めることができた

• リリース1終了後に、準備段階当初のリリース計画と比べ、17件の新しい要求が提起された。スプリント5で、リリース計画の見直しを実施した

23

準備段階 リリース1 リリース２

スプリント1～2 スプリント3～4 スプリント5～7 スプリント8～10

ユーザーからの新しい要求（件） 90 2 7 17 5

リリース1への割り当て（件） 16 1 2 0 0

リリース2への割り当て（件） 40 1 3 13 3

未計画（件） 34 0 2 4 2

ユーザーからの新しい要求の件数（時間順）

リリース1の後期であっても、変更を取り入れている

スプリント単位で、必要に応じリリース計画の見直しを実施

例②高生産性状態での安定化

• 各開発者は開発技術を習得し、担当する開発作業が増えた

• ベロシティの安定と向上を図っている

• 1人日あたりのSP ＝ スプリントにおけるPBIの規模（SP) / 作業時間

24

スプリント1 スプリント2 スプリント3 スプリント4 スプリント5 スプリント6 スプリント7 スプリント8 スプリント9

開発の作業実績 •開発の初期、開発は主に技術専門家が担当 •スプリント4から、各開発者は開発技術を習得し始め、担当する作業が増えた •作業負荷の平準化が実現 ※開発者2はスプリント7から退出

アジャイル開発導入の成功要因

• アジャイル開発プロセスや開発ガイドの現場への提供

• 企業のコンテキストに合わせたプロジェクトの手続き、チームの組成及びプロジェクトの進め方により、プロジェクトは迷うことなく、スムーズにアジャイル開発をスタートできる

• 例：PO代理の設置

• ユーザー部署と開発チームが物理的に離れている場合、業務を理解し、システム開発経験を持つPOの代理は、ユーザー部署と開発チームの架け橋として貴重である

• スクラムのワークショップの実施からのスタート

• アジャイル導入するチームに対し、スクラムのワークショップを実施することによって、アジャイル開発の目的に対する全員の共通認識が達成しやすく、チームの結束力を高められる

• アジャイルコーチ

• スクラムのイベントを根幹とするPDCAサークルの形成は少なくとも3ヶ月程度かかるため、アジャイルコーチによる支援は、最初の3ヶ月間は「半常駐」の形で、チームの傍で適切な支援を提供する

25

5. 今後の取り組み

アジャイル開発のさらなる普及及び大規模アジャイル開発の課題

• 当社の顧客は積極的にアジャイル開発を展開し、金融システム開発の変革を試みている。今後、アジャイル開発のさらなる普及及び大規模プロジェクトへのアジャイル開発の適用に関して、以下の課題がある

• ユーザーの要求が提起されてから、その機能が使われるまで、時間がかかる

• 開発の現場は、短いサイクルで動くものを作成できたが、リリースするための調整・ユーザートレーニング及び判定などにより、リリースまでかなりの時間がかかる

• 内製化率が低く、プロジェクト単位でベンダーを調達するやりかたは、自己組織化されたアジャイルチームの育成に不利

27

アジャイルコーチとして提供できる支援

• 顧客の個々のプロジェクトに対するアジャイル開発導入支援を通じ、チームレベルでのアジャイル開発の成功及び現場意識の変化に導く

• アジャイル開発に対する理解者・支持者を増やす

• 各部署でアジャイル開発事例を作ることによって、アジャイル開発に対する自信と能力を高め、大規模アジャイル開発に対応する準備を行う

28

ユーザー企業がアジャイルであれば、システムインテグレーターもアジャイルになれます。システムインテグレーターがアジャイルではない場合、ユーザー企業はアジャイルな振る舞いを要求することによって、インクリメンタルなリリースを可能にし、そして、必要なフィードバックを提供できるようにします。

Dean Leffingwell さん突撃インタビュー https://www.ogis-ri.co.jp/otc/hiroba/specials/interviewDeanAug2012/

まとめ

• 再掲

• 「金融システム」開発におけるアジャイル開発の導入ポイント

• チーム

• 標準化されたプロセス

• プロセスを現場へ適用する時の支援

• チームに寄り添う

• Small Step

29

「ITを活用した金融の高度化の推進に向けたワークショップ 第2回「ネットビジネスから考える銀行サービスのあり方」の模様」、https://www.boj.or.jp/announcements/release_2016/data/rel160314a1.pdf

日本の金融システムは、品質を落とさずに顧客ニーズに対応して

いくアジャイル開発手法も修得・共有していけば、海外企業とも十

分勝負できると思う。

参考資料

• 金融系IT企業におけるスクラムへの挑戦」、 Regional SCRUM GATHERING Tokyo 2016、http://www.publickey1.jp/blog/16/itregional_scrum_gathering.html

• 「エンタープライズアジャイルの可能性と実現への提言 アンチパターンとその克服事例」、エンタープライズアジャイル勉強会、2016年10月

• 「アジャイルコーチング」、オーム社、2017

• 「発見から納品へ:アジャイルなプロダクトの計画策定と分析」、BookWay、2014

30

ご清聴ありがとうございました！

31

ご清聴ありがとうございました。