東京都デジタルサービス局

東京都アジャイル型開発に係るプレイブック

2024年3月

目次
1章 アジャイル型開発のすすめ…p08

2章 デジ局のアジャイル型開発における取組事例 …p17
3章 アジャイル型開発の流れを知る…p27

4章 デジ局のアジャイル型開発への参加方法

…p44

付録集

…p48
2

今、この文章を読んでいるそこのあなた。

そう、あなたです。
あなたには、もしかして次のような思いがあるのではないでしょうか？
「今の仕事の進め方に不満がある」「チーム一丸となれば、もっと良い仕事ができる気がする」「ぶっちゃけ “アジャイル型開発” っていう単語が気になっただけ」「さらにぶっちゃけ、表紙が目についただけ」

いいですね、とても良いです。
そんなあなたに知ってほしいことを、この先のページでお話しします。

3

【アジャイル型開発】と聞いて、あなたはどのようなものだと感じるでしょうか。

「開発手法のひとつ？」正解です。「ウォーターフォール型とは違うやり方？」これも正解です。
しかし、このプレイブックでは、もう少し大きな概念としてアジャイル型開発を位置づけています。
つまり、アジャイル型開発とは、「顧客にとってより良いものにするために、見直しすることを躊躇しない開発手法のこと。
またそのマインドセット、および価値観のこと。」
それが、私たちが伝えたい「アジャイル型開発」の神髄です。
4

まだ具体的にはイメージしにくいかもしれませんが、まったく問題ありません。
なぜならこのプレイブックは、アジャイル型開発には詳しくなくても興味を持ってくださった
あなたのような方に向けて、一人ひとりが新しい価値を生み出すきっかけを創出し、それをワンチームで実現させ続ける道しるべとして作られたのですから。
あなたが“まだ実現していない新たな価値”を生み出し、仲間とともに”より良い世界”を実現させたいと願うとき、
このプレイブックは、あなたが目指す未来へ向かうための、ひとつの道しるべとなるでしょう。

5ところで・・・
デジタルサービス局がなぜ、アジャイル型開発について発信しているのか、ご説明できていませんでしたね。

従来のウォーターフォール型開発だけではなく、開発手法のひとつの選択肢としてアジャイル型開発も都庁内に浸透させたい…と考えています。
都庁に馴染むものなのか、どういうことに気をつける必要があるのか…
私達も日々、悩みながらトライしている最中です。
このプレイブックは、まだ完成版とは言えませんが、アジャイル型開発がどういうものなのか、少しはイメージできると思います。
まずは、少しでも興味を持っていただけると幸いです。
また、ご意見などもお寄せください。

6

このプレイブックでは、次の5人のキャラクターがあなたと一緒に「アジャイル型開発」を学びます。
プロダクトオーナー（PO）です！アジャイル型開発に参加した
各局職員が担当した役割です。よろしくお願いします！
プロダクトオーナーアドバイザー（POA）です！僕の役割は、受託事業者が担当しています。

PO

POA

デベロッパー/開発チーム（Dev）です！受託事業者のエンジニアやデザイナーが担当します。

スクラムマスター（SM）です！
私の役割も受託事業者が担当します。

SM

Dev

全体統括です！
デジ局職員が担当します。
詳しい役割紹介は第3章へ！

全体統括(各局支援)

78

アジャイル型開発を理解するうえで、まず初めに知っておきたいことがあります。
それはアメリカで2001年に発せられた、「アジャイルソフトウェア開発宣言」です。
「アジャイルソフトウェア開発宣言」のポイントとして、以下の3点があります。
【参考：アジャイル領域へのスキル変革の指針 アジャイルソフトウェア開発宣言の読みとき方 2020年2月 IPA】
【https://www.ipa.go.jp/files/000065601.pdf】

ポイント①
顧客視点の
アプローチである点

ポイント②
マインドセットであり、根本的・根源的な開発に取り組むための姿勢である点

ポイント③
従来の開発手法にも価値があることを認めている点「顧客視点」は東京都の「デジタルサービスに係る行動指針」ともあっているね！
アジャイルソフトウェア開発宣言って、どんな内容なんだろう？

PO

POA

9

「アジャイルソフトウェア開発宣言」では、次の考え方を重要視しています。

Dev

SM

以下のIPAの読みとき方を参考にすると理解しやすいですね！
•「対面コミュニケーション」を重視：個人同士の対話を通じて相互理解を深めることで、よりよいチームが作られる。
•「実働検証」の実施：動くソフトウェアを使って繰り返し素早く仮説検証し、その結果から学ぶことがよりよい成果を生み出す。
•「顧客とのWin-Win関係」を築く：お互いの立場を超えて協働することにより、よりよい成果と仕事のやり方を作ることができる。
• 「変化を味方に」つける：顧客のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉える。
10

アジャイル型開発は、従来型の開発とは異なる点が数多くあります。
どのような点に違いがあるのか、 IPAの資料で見てみましょう。
【参考：アジャイル型開発適用のヒント IPA/SECにおける非ウォーターフォール型開発に関する調査検討結果から 2012年7月 IPA】
【https://warp.da.ndl.go.jp/info:ndljp/pid/12446699/www.ipa.go.jp/files/000005367.pdf】

プロジェクトの要素に違いがあるね！
次のページで、あなたの案件はどちらに向いてるか、一緒に考えてみよう！

Dev

PO

11

【ワーク】 あなたの案件について考えてみましょう。
A

B☐

初めに決めた要件で進め、完成させたい。

☐

開発途中でもニーズの変化を柔軟に取り入れていきたい。

☐

命令系統を重視したい。

☐

互いに尊重しながら一緒に作り上げたい。

☐

開発中に何を作ろうとしているのか、どういうテストをしようとしているのか、必ずドキュメントで確認してから進めたい（要件定義書、設計書、テスト仕様書、マニュアル等）。

☐

開発中は動くものが見られればドキュメントは無くてもよい。
そのドキュメントも最低限あればよい（要件定義書、設計書、テスト仕様書、マニュアル等）。

☐

生命や金銭を取り扱うもの、または基幹システムである。

☐

生命や金銭を取り扱うものではなく、基幹システムでもない。

☐

やりたいこと、実現したいことの内容やボリュームが明確になっている。

☐

ぼんやりとやりたいこと、実現したいことはあるが明確になっていない。

☐

意思決定のための関係者が多い（担当や課を超えて関係者が多く、コミュニケーションに時間を要する）。

☐

意思決定のための関係者が少ない。

☐

発注までは多くの時間を割いてもよいが、開発期間中はあまり時間を割けない。

☐

開発期間中も時間を多く割ける。
または割いてもよいと考えている。

☐

基本的に全機能を一度にリリースしたい。

☐

全機能が揃わなくても使えるものならリリースし、改善を繰り返していきたい。

12アジャイル型開発では、「ワンチーム」となってプロジェクトを進行していきます。

POA

計画にコミットするのではなく、より良くするためには何が必要なのかをチームで考え、最善のプロセスで進めることが成功のカギになります！
アジャイルソフトウェア開発宣言の背後にある原則の中には「自己組織化チーム」という受発注の考え方だけでなく、全員がキーワードも出てきますね！
1つのチームとして協力しあうことも大事だね！
次のページで見てみましょう！

SM～～～ 「自己組織化チーム」となるための心構え ～～～・ チームは、プロジェクトの達成すべき目的や目標と、それを支える規律・ルールを共有しましょう。
・ チームは、自分たちで規律・ルールを決めましょう。
・ メンバーは、自ら率先して作業の改善や課題の解決に取り組みましょう。
・ メンバーは、自分の不得意な作業、領域についてもチャレンジして取り組みましょう。
・ メンバーは、お互いの作業状況をオープンにし、共有しましょう。
・ メンバーは、困っているメンバーがいたら、助け合いましょう。
【参考：アジャイル領域へのスキル変革の指針 アジャイルソフトウェア開発宣言の読みとき方 2020年2月 IPA】【https://www.ipa.go.jp/files/000065601.pdf】

13

発注する人・受注する人・開発する人が全員で共通の目標に向かうことが、アジャイル型開発では大切です。

アジャイルソフトウェア開発宣言の背後にある原則でも「ビジネス側の人と開発者」という表現がありますね！
発注者が開発に非協力的だと、新しいイノベーションは起きにくくなるかも……

SM

IPAの資料にも大事な行動規範の記載ありました！

POA～～～ 全員で共通の目標に向かうための心構え（理想） ～～～・ ビジネス側の人と開発者は、全員一緒の場所で働くことを理想としましょう。
- 一緒の場所で働けない場合は、工夫して、方向性を共有しましょう。
・ ビジネス側の人と開発者は、一緒にビジネスを成功に導くという共通目標を、日々確認しましょう。
・ ビジネス側の人と開発者は、全員で双方向のコミュニケーションが図れるようにしましょう。
- ビジネス側の人は、要求の出しっぱなしはやめましょう。
- 開発者は、フィードバックをもらうために、頻繁にリリースをすることから始めましょう。
・ ビジネス側の人と開発者は、全員が共通認識を持つために、必要最低限のドキュメントを書きましょう。
【参考：アジャイル領域へのスキル変革の指針 アジャイルソフトウェア開発宣言の読みとき方 2020年2月 IPA】【https://www.ipa.go.jp/files/000065601.pdf】

1414

【ひとやすみ】 デジ局への質問コーナー
全体統括を担当しているデジ局です。何かご質問はありますか？

このプレイブックでは、アジャイル型開発に挑戦した、都庁各局の職員の記録を読めると聞いたよ。どんな目的で作ったか気になる！

PO

いい質問ですね！プレイブックを作った目的は、都庁各局の職員にアジャイル
型開発について関心を持っていただくためです。そのうえで、次年度のデジ局のアジャイル型開発への参加も検討いただけると幸いです。
どうしてゲーム風のデザインなんだろう？

Dev

全体統括
(各局支援)

するどい質問ですね！アジャイル型開発では、目的達成のためにメンバーがワンチームで協力することが重要です。その雰囲気を感じていただくために、勇者（PO）が仲間とともにゴールを目指すRPG風のデザインを採用しました。
15

ところで、東京都庁内の10のチームが、 「アジャイル型開発」を実践しました。
そのうちの3チームの事例をここでは紹介します。

港湾局
UMI-MAP

東京消防庁
Project-Hiyari

産業労働局
AGRI-EX

彼らはどのような課題を抱え、どういう困難を乗り越えて、どんな成功を実現したのでしょうか。
その一端を、彼らの思いと合わせて、少しだけ覗いてみましょう。
読み終わるころにはきっと、いま抱えている課題の解決方法について、
あなたは 『1つの可能性』 を手にしているはずです。
16

17

事例① 概要「東京みなとDXのプロトタイプ開発」（通称：UMI_MAP）

港湾局「東京みなとDXプロジェクト」のユーザビリティ検証に活用できるプロトタイプを先行開発する!
Before
情報が分散◆このプロジェクトの目的
After
GIS上で一元管理

東京港の港湾・海岸施設情報を一元管理できるようにする。
①GIS※1をベースとしたプロトタイプを港湾局職員に体験してもらう。
②港湾・海岸施設の日常点検業務もデジタル化したい。

◆現状の課題・様々な部署・システムで港湾・海岸施設情報を分散管理している。
・2024年度に本開発を行う「東京みなとDXプロジェクト※2」のユーザビリティの検証に活用できる知見がたまっていない。
・市販のGISソフトで実現できることと実現できないことの整理ができてない。
※1 GISとは…地理情報システム（GIS：Geographic Information System）の略であり、位置に関する情報を持ったデータを視覚的に表示できる仕組みの総称。
※2 「東京みなとDXプロジェクト」とは…東京港の各種情報をプラットフォーム上に一元化することで業務の生産性向上・迅速な災害対応・オープンデータ化を実現するもの。

18

事例① スケジュール「東京みなとDXのプロトタイプ開発」（通称：UMI_MAP）

港湾局

開発期間は2023年8月から2023年10月まで、約2か月半のプロジェクトとなりました。

8月

9月

10月

ヒアリング
チームビルディング
インセプションデッキ作成
初期プロダクトバックロッグ作成
開発(スプリント)

１

２

3

4

5

6

7

8

※1週間単位の開発サイクルを8回繰り返しました。

19

事例① プロダクトオーナーへのインタビュー「東京みなとDXのプロトタイプ開発」（通称：UMI_MAP）

港湾局「POとして不安がありましたが参加させてもらってよかった。
短い期間の中、ここまでできるもんなんだなと感じました！」◆気づき・学び◆
本プロジェクトでの開発をとおして、今までは都庁で和気あいあいとコミュニケーションを取りながら仕事する機会が少なかったことに気がつきました。計画を立てる、ふりかえりをするなど仕事の進め方がシステム開発以外の普段の仕事に役立ちそうな感触があり貴重な経験でした。
◆これから挑戦の一歩を踏み出す人へメッセージ！◆
少しでもアジャイル型開発に興味があるならば、ぜひ経験して欲しいです。「アジャイル型開発」という言葉は庁内で浸透しつつありますが、実際は「何だろう？」と思う人が多いのではないでしょうか。些細な困りごとでもよいので、機会があれば、是非経験してみてほしいです！
港湾局 港湾整備部
技術管理課

福嶋課長代理開発プロジェクトの経験：今回が初めて
得意なこと：人と会話すること苦手なこと：資料整理

プロジェクトの満足度
面白さ
大変さ
自分が成長できたか

★★★★☆
★★★★★
★★★★★
★★★★★

20

事例② 概要「ヒヤリハット共有ツールの改修」（通称：Project-Hiyari）

•

東京
消防庁

ヒヤリハットを職員全員で共有し、安全に業務を遂行する！

Beforeヒヤリハット事案は一部の部(課)でしか収集していない◆このプロジェクトの目的

After
ヒヤリハットDBで一元管理
投稿用フォーム

・東京消防庁内の「全業務統一型ヒヤリハット」の取組を推進するための投稿用フォーム（Excel）とデータベース（Access）を開発し、収集したデータベースを庁内に共有することで、全職員が事案を参照できるようにする。

◆現状の課題・ヒヤリハット事案は一部の部(課)でしか収集していない・使いやすいものを提供しないと職員に使ってもらえない・プログラムの知識が乏しいため、自ら開発することが困難

ヒヤリハットDB

21

事例② 概要「ヒヤリハット共有ツールの改修」（通称：Project-Hiyari）

東京
消防庁

開発期間は2023年10月から2023年12月まで、約2か月半のプロジェクトとなりました。

10月

11月

12月

チームビルディング
インセプションデッキ作成
初期プロダクトバックロッグ作成
開発(スプリント)

１

２

3

4

5

6

7

※1週間単位の開発サイクルを7回繰り返しました。
スプリント4は祝日などの都合で2週間スプリントとなりました。

22

事例② 概要「ヒヤリハット共有ツールの改修」（通称：Project-Hiyari）

東京
消防庁「庁内のインフラ的な制約がある中、成果達成し求めていたものができました」
PO

東京消防庁
安全推進部
安全推進課

清水主任

◆気づき・学び◆
最初は手探り状態で進めたために何が必要なのか分かりませんでした。
10月の人事異動後すぐのタイミングで新メンバーとして一緒にスタートしたので時期的には良かったです。事業者とお互いにゼロから作ったことがProject-Hiyariの成功へとつながりました。シ
ステム開発に本格的に携わることがなかったので、すごく自分の勉強になりました。
また、このアジャイル型開発をきっかけに庁内の様々な部署と相談したことで知り合いの方も増え、東京消防庁内のコミュニケーションが取りやすい環境になりました。
◆これから挑戦の一歩を踏み出す人へメッセージ！◆
折角新しいことに挑戦する機会なので、是非楽しんでください！
POには、決断をリアルタイムで求められるので決断力が大事です。
自分に与えられた裁量を事前に上司に確認するなど、あらかじめ準備や相談をする事が必要です。
開発プロジェクトの経験：システム開発はないが、東京国際消防防災展で事業者とイベントをゼロから立ち上げた
得意なこと：誰とでも仲良くすること。新規アイディアを検討し、実現していくこと
苦手なこと：型にはめられることが苦手。言われたことをやる（創造性がないこと）

プロジェクトの満足度 ★★★★★
★★★★★
面白さ
★★★★☆
大変さ
自分が成長できたか ★★★★☆

23

事例③ 概要「農業指導業務の効率化」（通称：AGRI-EX）

産業労働局

農家に質の高い指導を継続的に行う！
Before
手書きでの指導記録を、使いづらいAccessの入力フォームから入力Ａ

Ａ
Ａ

Ａ◆このプロジェクトの目的

After
Kintoneを用い各センターを超えた事例の共有

・農家への指導記録の手書きをやめ、タブレットを用い現地で記録を行う。
・使いづらかったAccess※による入力フォームを使いやすくする。
・指導記録を職員の中で共有し、今後の指導に役立てる。

◆現状の課題・手書きでの指導記録を、農業改良普及センターに戻ってから
Accessに入力するため、手間がかかる。
・Accessのファイルが各センター毎で完結しているため、各センターを超えた事例の共有が困難。
・Accessのデータベースは職員ではフォーマットの修正が困難。

Ａ※現指導記録はMicrosoft Accessで作成

24

AGRI-EX：開発スケジュール
産業労働局

開発期間は2023年10月から2023年12月まで、約2か月半のプロジェクトとなりました。

10月

11月

12月

チームビルディング
インセプションデッキ作成
初期プロダクトバックロッグ作成
開発(スプリント)

１

２

3

4

5

6

7

※1週間単位の開発サイクルを7回繰り返しました。
スプリント4は祝日などの都合で2週間スプリントとなりました。

25

事例③ 概要「農業指導業務の効率化」（通称：AGRI-EX）

産業労働局「アジャイル型開発では、事業者にだけ開発をしてもらうのではなく、自分でも開発することができました！」◆気づき・学び◆
請負契約のように、最初に仕様を固めてしまうと開発過程での変更は難しいことから、要件を作りながら開発するため軌道修正しやすいのが、アジャイルのメリットだと分かりました。
開発中は、ステークホルダーから様々な意見が色々あり、意見を集約するのが難しいと感じましたが、自分の感覚を信じて思い切った判断をしてきました。また、自分自身も手を動かして開発作業を行う場面もありました。そうした経験を活かし、開発後の追加改修を見据えることで、思っていた以上に使いやすい成果物ができたと思います。そのほか、仕事の進め方などが大変勉
強になりましたし、楽しく取り組めたので、最後は名残惜しかったです。

産業労働局
農業振興事務所
振興課

松浦◆これから挑戦の一歩を踏み出す人へメッセージ！◆
やりたいことを具体的にイメージしつつも、時間が限られているため優先順位をつけて進めました。
必要に応じて決断することになりますが、コミュニケーションを取りながら進めるとよいと思います。
大小問わず課題があれば・・・（デジタルサービス局に）相談してみて、実際にアジャイル型開発による課題解決を体験して頂ければと思います。
開発プロジェクトの経験：ウォーターフォール型で既存ソフトの追加機能開発委託に携わった
得意なこと：コツコツ作業すること
苦手なこと：物事を説明すること、自らの意見を述べること

プロジェクトの満足度 ★★★★★
★★★★★
面白さ
★★★★☆
大変さ
自分が成長できたか ★★★★☆

26

27

アジャイル型開発の流れ
アジャイル型開発を行う際には、以下の大きな流れに沿ってプロジェクトを進行します。

1．チームビルディング
PO

2．計画フェーズ

3．スプリント（開発サイクル）

全体統括(各局支援)

どの段階でなにをするのか、

わかりにくい言葉等はいっしょに確認していこう！

デジ局がフォローします！
28

１．チームビルディング ①スクラムチームの特徴
デジ局のアジャイル型開発では、スクラムをベースにして、チームを組んで開発を行います。
スクラムチームにはどのような特徴があり、どんなメンバーでワンチームになるのか、見てみましょう。

スクラムの基本単位は、スクラムチームという⼩さなチームです。
このスクラムチーム内には、サブチームや階層は存在しません。
スクラムマスター1人、プロダクトオーナー1人、そして複数人の開発者で構成されます。敏捷性を維持しつつ、重要な作業を完了するための能力が備わっており、通常は10人以下のチームです。

もっと詳しく知りたいときは、「スクラムガイド※」に詳細が載っています！
※Ken Schwaber & Jeff Sutherland 著

スクラムチームは、プロダクトに関して必要となり得るすべての活動に責任を持ちます。例えば、ステークホルダーとのコラボレーショ
ン、検証、保守、運用などです。

POA

Dev

29

１．チームビルディング ②各プレイヤーの役割
プロダクトオーナー（PO）

あなたが担当する役割です！

・プロダクトバックログ※の管理者であり、ユーザー目線でバックログの優先順位付け等を行う。
・プロダクトの価値を最大化することに責任を持つ。

・ユーザー目線でバックログの優先順位付けが出来るメンバーが務めるのが望ましい。
※ プロダクトバックログとは、プロダクトゴールを達成するための要件リストのこと

プロジェクトでは、主にこんな業務をしているよ！
・プロダクトバックログの管理（優先順位付け&並び替え） /アイテムが完成しているか確認
・エンドユーザー、ステークホルダーの意見吸い上げや調整
・おおよそのリソース計画を策定 / 予算の管理（デジ局のアジャイル型開発では、全体統括がこの業務を担当）

PO30

１．チームビルディング ②各プレイヤーの役割
プロダクトオーナーアドバイザー（POA）
・デジ局のアジャイル型開発で追加した役割（一般的なスクラムには存在しない）

・開発経験が浅い又はないPOをサポートする役割
・スクラムに不慣れなPOがプロジェクトをスムーズに先導できるように
助言・相談を行う。

プロジェクトでは、主にこんな業務をしております！
・POのサポート・要件整理の支援やPOが主導で進めるスクラムイベント（会議）の推進（代行）・POとしての立ち振る舞い方・考え方の伝授

POA

31

１．チームビルディング ②各プレイヤーの役割
デベロッパー/開発チーム（Dev）
・デザインや開発を行うチーム
・インクリメント※の作成と品質に責任を持つ。
・個人ではなく常に開発チーム全体として作業を進める。
※ インクリメントとは、各スプリントで作成した成果物のこと

プロジェクトでは、主にこんな業務をしているよ！
・デザインの作成、実装
・設計・実装に伴うドキュメント類の作成・成果物に対するメンバー間での相互レビュー

Dev

32

１．チームビルディング ②各プレイヤーの役割
スクラムマスター（SM）
・POやDevを支えるコーチ・推進役
・Devが作業に集中して取り組めるようにサポート

・スクラムの外にいる人からの妨害や割り込みを防止する役
・マネージャーや管理者ではないので、
タスクアサインや進捗管理は行わない。

プロジェクトでは、主にこんな業務をしています！
・レトロスペクティブ・プランニングの実施
・Devのサポート・スクラム外にいる人からの妨害・割り込みの防止・調整、妨害リストの対応・解決

SM

33

１．チームビルディング ②各プレイヤーの役割
全体統括(各局支援)

デジ局が担当します！

・デジ局のアジャイル型開発で追加した役割（一般的なスクラムには存在しない）

・全プロジェクトの統括、進行管理及びプロジェクト運営の推進を行う。
・予算や全体スケジュールに対する意思決定は、POではなく全体統括が行う（但しプロダクトに関する意思決定は各局POが担う）。

プロジェクトでは、主にこんな業務をしております。
・全プロジェクトの最適化のもと、各プロジェクトのリソース計画策定 / 予算管理・受託事業者の調整（全体的な事柄）
・各局POとの調整・相談等

全体統括(各局支援)

34

１．チームビルディング ③デジ局Ver.のメンバー構成
デジ局では、皆さんの開発がより円滑に進むよう、下の図のようなメンバー構成で開発に取り組みます。

プロダクトオーナー（PO）◆各局のみなさん◆（あなたを含む）

助言・相談

スクラムマスター（SM）◆受託事業者◆

スクラムチーム（相互に協調・連携）

プロダクトオーナー
アドバイザー（POA）◆受託事業者◆

助言・相談・進行管理

コーチング

デベロッパー/開発チーム（Dev）◆受託事業者◆

全体統括◆デジタルサービス局(各局支援)◆

助言・相談・進行管理35

１．チームビルディング ④ワークショップの開催
デジ局のアジャイル型開発では、次のようなワークショップを行いました。

ワークショップの主な内容
3人程度のチームを構成して、1分程度で自己紹介を練習し、みんなで褒めたり気づいた点をアドバイスするなどフィードバックをして、再度各々自己紹介を考えます。上記を2～3回繰り返し、最後は全員の前で自己紹介を行います。お互いの紹介について話し合うことで、メンバーの興味や人柄を知ることができます。
アジャイル型開発はスプリントと呼ばれる繰り返しの作業です。ものを作り、それを確認してまた次のアイデアにする。自己紹介を繰り返しブラッシュアップすることでアジャイル型開発を疑似体験します。

PO

短い期間で成果を出すには、早い段階でお互いの関係を構築することが重要です。

POA

チームメンバーと楽しく会話することで、開発に取り組みやすくなりました。

36

２．計画フェーズ
開発に入る前に、重要な計画や整理を行います。
デジ局のアジャイル型開発では、次の3つを適宜作成し、開発に向けてスクラムチーム全体の認識を合わせていきました。

◆インセプションデッキ◆
これから取り組むプロジェクトの概要や目的、そしてゴールに対する共通認識を持つためのドキュメント。
事前に課題を洗い出したり、プロジェクトにおける優先順
位や重要度を明確にします。

◆ユーザーストーリーマップ◆
実際にプロダクトを使うユーザーが得る価値を「時間軸」×「優先順位軸」でマッピングしたもの。
プロダクトの価値やユーザーの利用シーンを整理することで、開発に進んだ際に優先すべき事柄を明確にできます。

◆プロダクトバックログ◆
チームが取り組むべき作業の情報源であり、プロダクトの開発や改善に必要となるタスクを、優先度順に並べた一覧表。
作業の優先順位や価値を確認し、チームとしてゴールを目指す助けとなります。

37

３．スプリント スプリントとスクラムイベント（開発サイクルと会議体）について
ここからは、実際にスプリントと呼ばれる期間ごとに、開発を進めていきます。
まずは「スプリント」の意味と、デジ局のアジャイル型開発で実施した「イベント」をご紹介します。

「スプリント（開発サイクル）」とはイメージしやすいように、専門用語を簡単な表現にしてみました。

プロダクトバックログの作成後に、デザインや開発を行っていく期間のこと。
一般的には1週間から2週間と言われています。

「イベント（会議体）」とは開発を円滑に進めるために、 以下のイベントをスプリント内で実施しました。スクラム開発における「スクラムイベ
ント」をベースとしています。
●

PO第2章で紹介した事例は、●

素早く実装してレビューの回数を●増やしていくために、1週間で実施して●いるみたいだね！

●

スプリントプランニング（計画）デイリースクラム（朝会）スプリントレビュー（レビュー）
スプリントレトロスペクティブ（ふりかえり）
バックログリファインメント(見直し・再整理)

全体統括(各局支援)
38

３．スプリント ①スプリントプランニング（計画）
バックログの中から、次のスプリントで実施する内容を決めるイベントです。
PO、Dev、SMを中心に実施します。

イベント内の主な作業●●

バックログの優先順位やDevが実施可能な工数※と照らし合わせ、次のスプリントのプランニングを行う。
必要に応じてチケットの再見積※工数とは、プロジェクトやタスクの作業量のこと

Devはプランニングの内容をスプリントで全て終わらせる責任を持ち、SMは開発チームがその責任を果たせる環境を作ることに責任を持っているんだ！

Dev

POはユーザー目線でバックログの優先順位付けを行います。

PO39

３．スプリント ②デイリースクラム（朝会）スプリント内の作業の進捗や問題を共有するための朝会です。 Devを中心に実施します。

イベント内の主な作業●

スプリント内の作業の進捗や問題の共有

毎日同じ時間に実施し、なるべく長時間話し込まずに行うよ。
個別の仕様確認などが必要な場合には関係者だけで別途ミーティングを設定しよう！

チームとしてプランニング内容を確実に完了させるために必要な共有や調整を行います。
SMに対してではなく、 メンバー間で進捗を共有することが重要です。

Dev

問題が起きていたり、何か懸念がある場合にも共有を行いましょう。

SM40

３．スプリント ③スプリントレビュー（レビュー）
Devがステークホルダーに対しスプリントの成果物のデモを行うイベントです。ステークホルダーの参加が難しい
場合、ステークホルダーへの窓口となるPOに対してデモを行います。

イベント内の主な作業●●●

スプリント成果物のデモ&レビュー
バックログアイテムが完了しているかどうかの判断
スプリントレビュー内で、完了の定義を満たさなかったものは別途修正チケットを切る。

POは成果物をもとに、該当のバックログアイテムが完了の定義を満たしているか判断するよ！
デモを行うのは原則「完了条件を満たしたタスク」のみだけれど、スプリント内で完了しなかったタスクがあった場合、途中の状態で共有することもあるようだね！

PO41

３．スプリント ④スプリントレトロスペクティブ（ふりかえり）
スプリントのふりかえりを行うイベントです。DevとSMを中心に実施します。
コミュニケーションを高め、開発をよりよいものとすることを目的としています。

イベント内の主な作業●●●●

スプリント内のできごとや学びや感情のふりかえり
次のスプリントをより良く過ごすためのアイデア出し
メトリクス※の確認妨害リストの作成※メトリクスとは…ストーリーポイント(作業量)やリードタイム(要望が実現するまでの時間)などのチームの状態を計測するための指標

デジ局のアジャイル型開発ではスプリント内のKPTやタイムラインを使ってふりか
えりをしました。

全体統括(各局支援)

42

３．スプリント ⑤バックログリファインメント（見直し・再整理）
バックログの起票内容の整理や優先順位付けを行うイベントです。POを中心に実施します。

イベント内の主な作業●

次のスプリントに向けたプロダクトバックログの整理や共有

例）
新しく起票されたチケット※や動きがあったチケットの読み合わせ
必要に応じてチケットに説明の追記や優先度を設定不要になったチケットの整理※プロダクトバックログはチケットとして管理をしている

バックログへの起票は、開発関係者なら誰でもいつでもできますが、内容の精査と優先順位付けは、POの責任で行います。

全体統括(各局支援)43

44

今後の流れまずは、お困りごと、DX化したいことをお聞かせください。
本事業で実現できそうかを確認させていただきます。
デジ局のアジャイル型開発について聞いてみたい！
というだけでも歓迎です！まずは気軽にお声がけください。
詳細や問合せ先は通知を確認ください。

全体統括(各局支援)

45

皆様へのお願い事項（1）①事業者との契約形態について②開発するプロダクトについて「アジャイル型開発」では、柔軟な対応を求める

開発するプロダクトは「プロトタイプ」としての開発・提ことから、事業者とは請負契約ではなく、準委

供となります。

任（単価）契約を結びます。

開発終了後の開発したプロダクトの利用は各局のごそのため、事業者に最終成果物の納品義務は判断にお任せしますが、継続して利用される場合のなく、契約で決めた時間を超えて働いてもらうこ

製品のライセンス費用や運用経費、運用事業者はともできません。

自局で準備してください。
また、本番環境等の別環境に反映する場合の作業

全体統括(各局支援)

事業者に丸投げしたり、一方的に無理な等も自局でお願いします。

依頼をするのではなく、ワンチームとして※開発が終了し、デジ局から引き渡された後に不具

適切なコミュニケーションをとりながら、合が発覚した場合、各局にてご対応をお願いします。

プロジェクトゴールを一緒に目指しましょう。
46

皆様へのお願い事項（2）①開発への主体的な関与及び②一定期間、業務負荷が皆様にかかる点

迅速な意思決定をお願いします。

について了承ください。

開発期間は限られています。迅速に意思POとして各種開発業務に主体的に関与していた決定をお願いします。

だくことから、計画や意思決定、開発チームとのミー

ティング等、業務負荷がかかります。
ご理解のうえ、本事業に参加ください。
未経験で不安という方も、デジ局とPOA

POAがしっかりサポートするので、まずはお問い合わせからでも、挑戦してみてはいかがでしょうか。

お待ちしております！

全体統括(各局支援)47

48

デジ局のアジャイル型開発の用語集（1）
アジャイル型開発
インクリメント

開発中の仕様変更などを視野に入れながら、短期間で小さな開発サイクルを繰り返す手法。対話を重視し、顧客を含めた関係者全員が協力して目標達成を目指す。従来のウォーターフォール型開発と比較される。
各スプリントで作成した成果物。

インセプションデッキ

関係者間でプロジェクトの全体像に対する認識を合わせるためのツール。「達成したいこと」「開発期間」「やらないこと」などを決める。

ウォーターフォール型開発

要件定義から設計や開発へと段階的に工程を進める開発手法。滝の水が上から下へ流れるように、原則として前工程に戻らない。

MVP
エレベーターピッチ
エンドユーザー
デベロッパー/開発チーム
（Dev）
機能要件

Minimum Viable Productの略語。価値を提供する必要最小限の機能を持つ製品。
プロジェクトの特徴や自分の意見などを簡潔に短時間で伝える手法。

モノやサービスの最終利用者のこと。社内向けシステムなら社内利用者。一般ユーザー向けサービ
スなら一般ユーザーを指す。
スクラムにおける役割の1つ。エンジニアやデザイナーなど開発作業を実際に進める人。
システム内に実装すべき機能。登録機能・検索機能など。

49

デジ局のアジャイル型開発の用語集（2）
工数

プロジェクトやタスクの作業量。

スクラム

アジャイル開発で用いられる、チームで効率的に開発を進めるための手法。

スクラムマスター（SM）

スクラムイベントスコープ
ステークホルダー
スプリント
スプリント計画
スプリントバックログ

スクラムにおける役割の1つ。開発全体を支援する人。スクラムイベントでの司会や開発における妨害などを解決する。

スクラムを組んだチームがスプリント内で実施する各ミーティング。
プロジェクトで取り組むべき範囲のこと。
システム開発においては関連する全ての人や企業のこと。
開発を反復（イテレーション）する単位。一般的には1, 2週間とされる。
各スプリント内で行うタスクを協議・決定するミーティング。
プロダクトバックログの内、各スプリント内で取り組むタスクのリスト。

50

デジ局のアジャイル型開発の用語集（3）スプリントレビュー
チケット

各スプリントの最後に行う成果物（インクリメント）のレビュー。
取り組む1つ1つのタスク。

チームビルディング

目標を達成するためのチームを作る取り組み。

デイリースクラム

毎日決まった時間に行う15分程度のミーティング。基本的には開発者間の認識合わせの場。昨日取り組んだこと・今日取り組むこと・相談事項などを共有する。
※朝会と呼ばれることもある。夕方実施（夕会）の場合もある

トレードオフスライダー

プロジェクトで優先する事項の順位付けをするために使用する指標。

非機能要件

機能要件以外の部分（「1秒以内に検索結果が表示される」など）。

プロダクトオーナー（PO）

スクラムにおける役割の1つ。製品開発の方向性を決める責任者。やることやらないことの最終決定権を有する。製品開発の依頼者などが担当する。

プロダクトオーナー
アドバイザー（POA）

デジ局のアジャイル型開発のために割り当てたスクラムにおける役割の1つ。経験がない又は浅いPOへの助言・相談役。

プロダクトバックログ

製品で実現したいこと・必要な機能などを記述したToDoリスト。
POによる優先順位付けが行われる。

51

デジ局のアジャイル型開発の用語集（4）フロント実装ここではユーザーが操作する画面を指す。

ペルソナ

ターゲットに類似するがより詳細に設定を決めたユーザー像。性別・年齢・所属など様々な属性を
含める。

ベロシティ

チームが作業を進める速度。

メトリクス

ストーリーポイント(作業量)やリードタイム(要望が実現するまでの時間)などのチームの状態を計測するための指標。

ユーザーストーリー
ユーザビリティ

エンドユーザーができる機能を簡潔に表現したもの。「○○が××をしたい」などの形式で表す。
使い勝手・使いやすさのこと。

リソース

目的を達成するために必要な資源や要素。このプレイブックでは主に「人材」のこと。

リリース

製品やサービスを公開、販売すること。

レトロスペクティブ

各スプリントの最後に行うふりかえり。関係者が良い点や悪い点を出し、次回以降のスプリントをより良くするための改善案を出す。
52

参考：本書作成に当たり、以下を参考としました。
名称

作成者/著者

アジャイル開発とスクラム -顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント-

平鍋健児・野中郁次郎 共著

アジャイルサムライ-達人開発者への道-

Jonathan Rasmusson 著
西村直人・角谷信太郎 監訳
近藤修平・角掛拓未 訳

SCRUM BOOT CAMP THE BOOK

西村直人・永瀬美穂・吉羽龍太郎 共著

アジャイルソフトウェア開発宣言（https://agilemanifesto.org/iso/ja/manifesto.html）
アジャイル宣言の背後にある原則（https://agilemanifesto.org/iso/ja/principles.html）

Kent Beck et al.

スクラムガイド（https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf）

Ken Schwaber & Jeff Sutherland 共著

アジャイル型開発実践ガイドブック

内閣官房情報通信技術（IT）総合戦略室

デジタルサービスに係る行動指針（https://www.digitalservice.metro.tokyo.lg.jp/digitalguideline/）

東京都デジタルサービス局

アジャイル領域へのスキル変革の指針 アジャイルソフトウェア開発宣言の読みとき方（https://www.ipa.go.jp/files/000065601.pdf）

独立行政法人 情報処理推進機構

アジャイル型開発適用のヒント IPA/SECにおける非ウォーターフォール型開発に関する調査検討結果から（https://warp.da.ndl.go.jp/info:ndljp/pid/12446699/www.ipa.go.jp/files/000005367.pdf）

独立行政法人 情報処理推進機構

53