Lean Conference Japan 2022 Autumn

官公庁領域における大規模SI開発プロジェクトでのアジャイル開発の適用事例
2022年9月13日

富士通株式会社
官公庁事業本部 官庁第五事業部
丸山 隆司
FUJITSU-PUBLIC

1© 2022 Fujitsu Limited

FUJITSU-PUBLIC

22© 2022 Fujitsu Limited

AgendaFUJITSU-PUBLIC◼ 官公庁領域のSIの特徴

4◼ 事例プロジェクトの特徴

5◼ 受託者側の主なリスク

6◼ プロジェクトスタート (1) ～ (2)7◼ スクラムで開発を進めてみたが・・・

9◼ 何が起きていたか・・・ (1) ～ (3)10◼ その結果・・・

13◼ 問題の本質は？

14◼ 問題点を解決するための5つの対策

15◼ 5つの対策の結果

25◼ 本事例の気付き、学び (1) ～ (3)27◼ 今後の展望30
3© 2022 Fujitsu Limited

官公庁領域のSIの特徴
ミッションクリティカル
大規模開発

複数年にわたる開発期間

国策対応・納期厳守

請負契約
FUJITSU-PUBLIC

4© 2022 Fujitsu Limited

事例プロジェクトの特徴
社会保険診療報酬支払基金 様

特徴

オンライン資格確認等システム
開発プロジェクト

日本では新しい取り組み

業務知識・ノウハウがほとんどない
エンドユーザー ≠ お客様
アジャイル開発が調達要件
引用：厚生労働省『オンライン資格確認 医療機関・薬局向け周知動画（導入後の業務と機能編） 』より利用しやすく、利用価値が得られるサービスをタイムリーに提供し続けたい
FUJITSU-PUBLIC

5© 2022 Fujitsu Limited

受託者側の主なリスク⚫ 請負契約×大規模アジャイル開発 = ??

請負契約のため完成責任がある開発要件追加・変更が多発する

アジャイル開発の経験不足

お客様の期待に対して、納期・品質・コストが果たして守れるのか？
FUJITSU-PUBLIC

6© 2022 Fujitsu Limitedプロジェクトスタート (1)
項目

2019年

2020年

7月

1月

10月

2021年
4月7月

▼実地検証①

10月

1月

2022年
4月

7月

▼実地検証②▲プレ運用▼保険資格連携開始

主なイベント▼総合テスト開始

1月

★本格運用

▼特定健診情報連携開始

機能追加・改善対応

資格確認関連機能開発

10月

運用保守

顔認証関連機能開発

システム開発特定健診情報管理機能開発
薬剤情報管理機能開発
医療費情報管理機能開発
医療機関等ベンダーテスト

外部テストイベント
FUJITSU-PUBLIC

運用テスト
7

© 2022 Fujitsu Limitedプロジェクトスタート (2)⚫ アプリ開発体制
お客様
プロジェクト
マネージャー

当社
プロジェクトマネージャー

最大

8

チーム
開発リーダー

プロダクトオーナー

プロジェクトルームに常駐し、一緒に開発チームリーダー

スクラム開発手法を適用

スクラムチーム

チームメンバースクラムマスター※スクラム経験者
スクラム支援業者
FUJITSU-PUBLIC

スクラムマネジメントアドバイザー
8© 2022 Fujitsu Limited

スクラムで開発を進めてみたが…
リリースバーンダウンチャート
問題点

1
進捗・生産性があがってこない

問題点

3

問題点

バックログが減らない、増える2
医療機関向けのSPのみ進捗が伸び、他が伸びてこない

FUJITSU-PUBLIC

テストスプリント*

開発スプリント*（1スプリント/1W）

9*スプリント
スクラム開発では、計画-設計-開発テストの一連の作業繰り返し実施する。その反復単位を表す。
© 2022 Fujitsu Limited

何が起きていたか… (1)問題点

1

進捗・生産性があがってこない

プロジェクトマネージャーとスクラムマスター間の意識の相違

メンバーの経験不足

スクラムチームで生産性の向上・改善が進まない
FUJITSU-PUBLIC

10© 2022 Fujitsu Limited

何が起きていたか… (2)
問題点

医療機関向けのSPのみ進捗が伸び、他が伸びてこない

2

エンドユーザーの医療機関、国民への価値提供・向上に向けた対応にプロダクトオーナーが注力

スクラムチームもプロダクトオーナーの意向を受けて開発を推進

エンドユーザーへの価値提供に直接つながらない機能の検討が進まない
FUJITSU-PUBLIC

11© 2022 Fujitsu Limited

何が起きていたか… (3)
問題点

バックログが減らない、増える

3

例外発生、異常発生時の検討・考慮が十分に実施されていない

スクラムチームごとに作成された成果物の品質にバラツキがある

これらの対応に必要なバックログが増える
FUJITSU-PUBLIC

12© 2022 Fujitsu Limited

その結果…
完成度

エンドユーザーが使う機能
請
負開発
範
囲

システム運用者・管理者が使う機能

システムとして当たり前に実装しておくべき機能

未着手

完成度

魅力品質
一元品質

完成度

当たり前
品質

高

未着手

低

未着手

成果物に対する進捗・品質のコントロールができていない
FUJITSU-PUBLIC

13© 2022 Fujitsu Limited

問題の本質は？
01

02

03

04

状況の可視化

見解の相違

スクラムチームの統制

品質の作り込み順序

調達要件にある成果物（機能）に対する出来高・進捗が見える仕組みがなかった。

スクラムマスターとプロジェクトマネージャーの間で “ものの見方・考え方”が違っており、状況に応じた対策が、適切なタイミングで取れていなかった。

チーム間の情報共有・課題解決の仕組みの立ち上げが遅かった。

アジャイル開発での“当たり前品質”に相当する機能・仕掛けを作り込むタイミング、プロダクトオーナーの関心を、どのようにコントロールすべきだったのかが、わかっていなかった。

※SPによるリリースバーンダウン
チャートだけでは気づけなかった※各チームがプロダクトオーナーと合意しながら開発を進めることもあり、チームの独立性が高かった※準委任契約と請負契約の考え方の違いも影響か!?

大規模開発＋請負契約でのアジャイル開発の経験不足
FUJITSU-PUBLIC

14© 2022 Fujitsu Limited

問題点を解決するための5つの対策■ 問題点とその本質
問題点1

進捗・生産性があがってこない

問題点2

医療機関向けのSPのみ進捗が伸び、他が伸びてこない■ 対策 ~Leanの考え方をAgile開発へ~

TMS*、リーンスタートアップの実践経験

状況の可視化

1 マネジメント指標の見直し・見える化
2 バックログの2s（整理整頓）
3 スプリント作業の改善
4 チーム間コミュニケーションの改善
MVP*(Minimum Viable Product)を5 用いた開発の実施

見解の相違

スクラムチームの統制

問題点3

バックログが減らない、増える

品質の作り込み順序*MVP（Minimum Viable Product)
目的を達成できる最小限の機能をユーザーに提供し、得られたフィードバック等を参考に機能改善等を推進する手法。リーンスタートアップの構成要素の一つでもある。

*TMS（Toyota way Management System) TPSを基本としてホワイトカラーの職場向けに進化したマネジメント。
グローバルな経営思想と理論をもとに革新的なマネジメントを展開し、設計開発から製造・販売まで幅広い分野に適用可能。

FUJITSU-PUBLIC

15© 2022 Fujitsu Limited

対策１：マネジメント指標の見直し・見える化 (1)ファンクションポイント（FS）を管理指標におき、⚫ バックログの消化状況と、成果物（機能）の出来高の予実をマネジメント。
⚫ バックログの変動に伴う開発ボリュームをコントロール。
◼ プロダクトバックログ-機能マトリクス
機能名
機能 A

プロダクトバックログ番号
1212

機能 C

13341

機能 B

機能 D◼ 進捗把握イメージ ※プロダクトバックログ番号3,5が完了の場合

52

112FS計・・・

5機能 A

3・・・

7機能 B

22・・・

6機能 C

11・・・

7機能 D・・・
FS計
FUJITSU-PUBLIC

プロダクトバックログ番号・・・

632

機能名

12

13413

1

445FS計・・・

54/53・・・

70/72・・・

63/6

1・・・

70/725

7/25

32

2

1
2

進捗・・・

6・・・
443

44625

FS計
16

3446

© 2022 Fujitsu Limited

対策１：マネジメント指標の見直し・見える化 (2)進捗管理表をもとに、成果物（機能）ごとに、プロダクトバックログの消化状況と成果物の出来高を把握し、マネジメントを実施。
■進捗管理表開発対象機能

業務名

進捗状況
集計
方法

機能名

バックログアイテム/
タスク分類

PBL
合計

(a)前回まで実績合計(スプリント２２完了後)

開発規模
合計
(FS)

仕掛
PBL

1.薬剤情報管理機
能PBL計画(b)今回スプリント実績(スプリント２３)

完了
FS

PBL

残FS

PBL

予定
FS

PBL

(c)今回まで実績合計(スプリント２３完了後)

仕掛FS

PBL

完了
FS

PBL

仕掛FS

PBL

(d)次回スプリント(スプリント２４)

完了
FS

PBL

残FS

PBL

予定
FS

PBL

FS

2

1,430

1716

1

1,073

1357

0000001716

1

1,073

1357

00

48

9,595

19

1,330

33

5,367

15

4,228126575850024

1,415

33

5,367

15

4,228

10646

02,37003400

1,4040966

0

167

0

22000361

01,4040966

0

164

6

2,286

1381

2

1,016

4

1,270

000000

1381

2

1,016

4

1,270

1

95

56

15,681

21

2,766

36

8,860

20

6,821

12

824

5

107

0

0

26

2,873

36

8,860

20

6,821

11

905

課題、追加案件付帯

2.薬剤情報閲覧機
能PBL

計画
課題、追加案件付帯③薬剤情報管理機能

3.薬剤情報提供制
御機能

PBL

計画
課題、追加案件付帯

4.マスタメンテサービス（薬剤情報）

PBL

計画
課題、追加案件付帯

合計

FUJITSU-PUBLIC

17© 2022 Fujitsu Limited

対策１：マネジメント指標の見直し・見える化 (3)⚫ 成果物の出来高から見るリリースバーンダウンチャート

Point

プロダクトバックログの消化状況と、成果物の出来高を連動して定量的に把握するマネジメント指標の見える化によって、リリースバーンダウンチャートも改善され、ことができ、バックログの変動にも柔軟に対応することが可能に。
×××

FUJITSU-PUBLIC

18© 2022 Fujitsu Limited

対策２：バックログの2s（整理整頓） (1)
プロダクトバックログにある案件を整理・整頓（調達要件に直結する案件か、付帯的な案件か、不要（取り下げ可）となった案件か等）し、バックログ増減管理を適正化。

バックログ発生の経緯を管理
バックログの調整状況を管理

FUJITSU-PUBLIC

19© 2022 Fujitsu Limited

対策２：バックログの2s（整理整頓） (2)⚫ プロダクトバックログの対応計画を可視化し、バックログの変動調整に有効活用。
⚫ リファインメントプロセスとして確立させ、スクラムのマネジメントプロセスに組み入れて運用。
■概略スケジュール

お客様にわかる言葉で、いつ、何を仕掛かり、何が出来上がるのかを整理
Point

FUJITSU-PUBLIC

20

プロダクトバックログの変動調整を行いやすい。

© 2022 Fujitsu Limited

対策３：スプリント作業の改善 (1)⚫ スプリントで実施する作業の流れを可視化し、正味作業を定義。
⚫ 正味作業に該当しない作業の作業改善を促すべく、振り返り（KPT）を実施し、作業改善に向けた様々な取り組みを実践。
スプリント作業の流れを可視化・正味作業を定義

改善

1

改善

2

振り返り（KPT）の実施

改善“7つのムダ”を観点に加え、KAIZENを実施

3

Point

見積時の想定生産性※12月は実地検証に向けたテスト作業が中心だったため除外

KAIZEN対象作業の細分化により、類似・重複・Outputに影響しない“ムダ”な作業を抽出。作業の削減・見直し等を推進し、生産性向上を実現。

FUJITSU-PUBLIC

21© 2022 Fujitsu Limited

対策３：スプリント作業の改善 (2)⚫ 正味作業の定義
週1回
全体作業⚫ KPTボードによる振り返り

スプリント計画
MTG

チーム内レビュー

リリース計画

Redmine
チケット登録

Redmineチケット更新スプリントレビュー

基本設計書
確認

Gitマスタへマージ

終了

Gitブランチ作成

GitへPush

セルカス定義書作成・コード生成

リリース申請

コード修正

デプロイ

テストコード作成（JUnit）

動作確認

テストコード作成（Selenium）

PO確認

Gitコミット

Redmineチケット更新週1回
全体作業

CI/CDのトリガー

スクラム開発のプロセス

FUJITSU-PUBLIC

正味作業の範囲22© 2022 Fujitsu Limited

対策４：チーム間コミュニケーションの改善
01

02

スクラム・オブ・スクラムの立ち上げ

スクラム推進MTGの立ち上げ

⚫ 目的：

⚫ 目的：

スクラムチーム間での情報共有・課題解決・品質の均一化／向上を目指す
コミュニケーションの場

スクラム開発に係る、マネジメントの方針・施策の方向性について意識合わせ、全体最適の視点に立ち、足並みを揃えた対応実施を目指す
コミュニケーションの場⚫ メンバー：各スクラムチーム⚫ メンバー：PM、PMO、スクラムマスター、⚫ 所要時間：毎日15~30分程度

スクラムマネジメントアドバイザー⚫ 開催頻度：週1回 90分程度

Point

技術的な側面での問題・課題解決に大きく貢献。

FUJITSU-PUBLIC

Point

23

マネジメント的な側面での問題・課題解決に大きく貢献。
© 2022 Fujitsu Limited

対策５：MVP（Minimum Viable Product）を用いた開発の実施
システム運用者・管理者が使う機能について、以下のように開発を推進。
⚫ 当社のこれまでのシステム開発経験をもとに、当社主体でMVPを開発。
⚫ プロダクトオーナーに実際に動くものを確認いただきながら、本稼働に最低限必要な機能に特化し開発。
プロダクトオーナーを中心としたスクラムチームで更なる価値提供を追求
当社のシステム開発の知見を活かしたMVP開発“スクラム・オブ・スクラム”を活用した品質の作り込み・底上げ

Point・プロダクトオーナーによる提供価値の追求と作業負荷を軽減。
・MVPを適用することで、メリハリがついた効率的な開発を実現。

FUJITSU-PUBLIC

24© 2022 Fujitsu Limited５つの対策の結果
01 マネジメント指標の見直し・見える化
全機能・予定通り本稼働を達成

02 バックログの2s（整理整頓）
03 スプリント作業の改善04 チーム間コミュニケーションの改善
05

MVP（Minimum Viable Product）を用いた開発の実施

エンドユーザーに対する提供価値の最大化にも大きく貢献
FUJITSU-PUBLIC

25© 2022 Fujitsu Limitedお客様の感想・コメント
私が拝見している限りですが、通常の官公庁系の開発に比べて、今回の開発メンバーの方々は、よりエンドユーザーの行動がどうなっていくのか、便利になっていくのか、について、意識が高かった気がします。
オンライン資格確認は、基本的には、インフラシステムで、IFはほとんど持たないものなので、従来のウォーターフォールでやっていた場合、エンドユーザーの行動を淡々と書面で確認するという感じになりかねないのではなかった、と思います。
その点において、アジャイル開発という旗は、この開発に携わった方々の意識に影響を与えていたと思います。意識変革という点では、支払基金の職員も同様だったと思います。
それだけでは、当然、開発は完遂できませんので、本資料にあるような取り組みが重要で、また、それ自体が試行錯誤の取り組みでご苦労されていた点だったと思いますが、結果としては、この意識変革とプロジェクトの完遂を両立させたことに非常に価値があると思います。
• エンドユーザーへの提供価値の追求と、その実現による達成感• アジャイル開発を通じて、プロジェクトメンバーの意識の変化・成長を実感
FUJITSU-PUBLIC

26© 2022 Fujitsu Limited

本事例の気付き、学び (1)

請負契約

アジャイル開発

請負開発範囲の確実な開発推進と、システムの提供価値追求の両立

プロダクトバックログと成果物の出来高を連動して把握・マネジメントする仕組みを確立すること
チームパフォーマンスの継続的向上に向けた取り組みを、チーム活動として実践し続けること
より高い価値提供に注力できる工夫が必要。付帯的な機能の開発は、ベンダー主導による開発も有用
PMとスクラムマスター間での全体状況、方針の共有、それぞれが持つ課題の共有と、“全体最適”の視点に立った対策検討を行う仕組み・場を、開発初期段階から確立・運用し、 “共通の価値観”の早期醸成を狙うこと
アジャイル開発の“型”にこだわり過ぎない。プロジェクト状況等に応じた“型”を追究・実践すること
FUJITSU-PUBLIC

27© 2022 Fujitsu Limited

本事例の気付き、学び (2)

大規模開発

アジャイル開発チーム間でのテクニカル面、マネジメント面の統制と“共通の価値観”の早期醸成

チーム間でのテクニカル、マネジメントに関する方針共有・課題解決を行う仕組みを開発初期段階から確立し、同じ物の見方・考え方に立って各チームが業務遂行できるよう、運用すること
チーム間でのマネジメントのバラツキを抑止する体制・仕組みを開発初期段階から確立・運用すること”当たり前品質“に相当する機能・仕組みの作り込みは、開発初期にチーム間でバラツキが出ないよう、テクニカ
ル統制をかける体制・仕組を確立し、開発を行うこと

FUJITSU-PUBLIC

28© 2022 Fujitsu Limited

本事例の気付き、学び (3)
本事例を通じて改めて感じたこと・学んだこと

03 日々のマネジメント、短いPDCA
サイクルでのマネジメント

02 プロジェクト・チーム

04 • 発言・意見が出やすい

メンバー間での“共通の価値観”の醸成

チーム作り• お客様含めた一体感の醸成・関係性の良質化

05 変化に柔軟に対応する

01 “目指す姿”“思い”

ための仕組みづくり・
土壌づくりの共有・共感

チームの雰囲気がかなりポジティブに変化。
自発的な活動・取り組みが多くみられるように。
FUJITSU-PUBLIC

29

アジャイル開発に関わったメンバーの意識の変化・成長（自立→自律へ）。
© 2022 Fujitsu Limited

今後の展望~自律型の事業・組織運営の実現に向けて~

リーン・アジャイルを通じて感じた変化を自組織へ展開・浸透させる
FUJITSU-PUBLIC

30© 2022 Fujitsu Limited

今後の展望 ~自律型の事業・組織運営の実現に向けて~自律的に取り組み、成し遂げる強い組織へ

Stage 3

Woven Practice for Director

組織のバリアを崩すStage 2

Woven Practice for Leader

チームのバリアを一部崩すStage 1

幹部社員

自組織の変革・マネジメントにLean・Agileの要点を取り込む

プロジェクトリーダ20名

Woven Basic
関連組織を含む全員160名

知識のバリアを崩す

Woven Work Designの組織適用を2022年9月よりスタート
FUJITSU-PUBLIC

31© 2022 Fujitsu Limited

Thank you© 2022 Fujitsu Limited