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

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

2023年3月

目次

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

2章 デジ局のアジャイル型開発における取組事例 …p17

3章 アジャイル型開発の流れを知る…p34

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

…p51

付録集

…p55
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

ところで、実はすでに東京都庁内の4つのチームが、 「アジャイル型開発」を実践しました。

デジタル
サービス局
EVA

福祉保健局
ANIMAL

環境局
Yu-ki

教育庁
T-MAP

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

17

事例① 概要「シン・トセイ職員専用ポータルサイトの改修」（通称：EVA）

デジタル
サービス局

「情報を探しやすくする。」
たったそれだけのことが大変で、だからこそやる価値があったーーー。
Before:ユーザビリティに課題があった

After:ユーザビリティをより意識して改修

東京都職員向けの2つの掲示板サイト①デジタル提案箱＋②SHIN-QAを
より多くの職員に使ってもらえるようするためのプロジェクト◆課題
・ユーザビリティ改善が必要
・ユーザーに情報を分かり易く伝わるような仕組み作りが必要（情報設計が必要）
・認知が広がっていない。
・継続的な利用が獲得できていない。
18

事例① スケジュール「シン・トセイ職員専用ポータルサイトの改修」（通称：EVA）

デジタル
サービス局

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

11月

12月

1月

2月

3月

ワークショップ
キックオフ
計画・整理
開発
受け入れテスト

１

2

3

4

5

※フィードバック対応※1週間単位の開発サイクルを4回繰り返しました。
スプリント5は2週間単位です。

ユーザーテスト
計画・整理
開発
受け入れテスト

6※スプリント6は2週間単位です。

公開19

事例① プロダクトオーナーへのインタビュー1「シン・トセイ職員専用ポータルサイトの改修」（通称：EVA）

デジタル
サービス局

「1回やるとやらないとでは、アジャイル型開発の見方がかなり変わります。
私もその一人でした。」◆気づき・学び◆
本プロジェクトで何を実現するかを整理してから参加しました。しかし、実際に事業者の方から色々と教えていただきながら開発を進めることができたので、自身の成長にもつなげることができたと思います。打ち合わせもフラットな雰囲気で進められていたこともよかった点でした。開発のス
ピード感が早いため、都側の意思決定のスピードをどう合わせていくかが課題だと感じました。

デジタルサービス局 戦略部
デジタル改革課 デジタル改革担当

藤井課長代理◆これから挑戦の一歩を踏み出す人へメッセージ！◆
投稿フォームやデザイン等のUI関係の開発には向いていると感じました。また、チームワークを大切にし、柔軟にやり方を改善しながら進められるマインドがある方にあっている開発手法と思います。1回やるとやらないとではアジャイル型開発の見方がかなり変わります。私もその一人でした。
まずは1回チャレンジしてほしい！
開発プロジェクトの経験：今回が初めて
得意なこと：切り替え
苦手なこと：わかりやすく物事を説明する

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

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

20

事例① プロダクトオーナーへのインタビュー2「シン・トセイ職員専用ポータルサイトの改修」（通称：EVA）

デジタル
サービス局

「アジャイル型開発はチームワークを大切にするため、人とのコミュニケーションをベースに、楽しく開発に参加できました。」◆気づき・学び◆
事前にアジャイル型開発に関して学んでいたつもりでしたが、実際の学びになったのは開発を進めていく中でした。成果物の進捗を日々デイリースクラムなどで気軽に質問しながら確認し、その場で判断する機会も多いため、成長の場にもなりました。スプリントを分けることで、想定外の障害などにすぐに対応できたのも良かったです。しかし、フロント実装の最終段階の調整で最終的な詰めを行うため、その前のスプリントで研ぎ澄ませてきた価値を担保できなくなるリスクもあると感じました。
◆これから挑戦の一歩を踏み出す人へメッセージ！◆
事業者をパートナーと認識し、チームワークを大切にする方や自身も技術的な知見を高める
意思がある方に向いていると思います。 アジャイル型開発はチームワークを大切にするため、人とのコミュニケーションをベースに、楽しく開発に参加できました。ぜひ1度チャレンジしてほしい！
開発プロジェクトの経験：今回が初めて
得意なこと：知らないことを遠慮なく聞く
苦手なこと：こまかい話に関連すること

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

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

デジタルサービス局 戦略部
デジタル改革課 デジタル改革担当

流田主任

21

事例② 概要「問い合わせ等受理簿のデータベース化」（通称：ANIMAL）

福祉保健局

飼い主への対応にもっと時間をかけるという本来あるべき姿を、実現するための可能性ーーー
Before:紙やWordで対応

After:
システム化

動物愛護相談センター多摩支所監視担当職員の業務効率化により、飼い主への飼い方指導・助言といった本来業務に時間を割いて丁寧に取り組めるようにするためのプロジェクト◆課題
・問い合わせ等受理（処理）簿はMicrosoft
Wordで作成
・記録が追記されるごとに紙に印刷して所内回覧
・共有ドライブ内をファイル検索して問い合わせ
履歴を検索
22

事例② スケジュール「問い合わせ等受理簿のデータベース化」（通称：ANIMAL）

福祉保健局

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

11月

12月

1月

2月

3月

キックオフ
現場視察
計画・整理
開発
受け入れテスト

１

2

3

4

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

23

事例② プロダクトオーナーへのインタビュー1「問い合わせ等受理簿のデータベース化」（通称：ANIMAL）

福祉保健局「ひとまず相談するだけと思っていたら、「ひとまず相談するだけと思っていたら、最終的には一つのシステム構築のPOとして開発を完了することができました。」
最終的には一つのシステム構築のPOとして開発を完了することができました。」◆気づき・学び◆
ICTリーダー2年目として何かできることはないかと模索する中だったので、とても興味がありました。しかし、ITパスポート講座では「アジャイル」というキーワードを学んだのみでしたので、実際に開発を進める中で多くの学びを得ることができました。実際にシステムができあがってきた時に「これは利用できるぞ！」という気持ちになってきたので、将来的に利用し続けるシステムとなるようにマニュアル作成、人材・予算確保が必要だと感じています。
◆これから挑戦の一歩を踏み出す人へメッセージ！◆
コミュニケーションを重視するものだと気づきました。システムとは、人のために人が愛情をもって作るものだと実感しました。「最初は相談からOKです！」と聞いたので、ひとまず相談するだけと思っていたら、最終的に一つのシステム構築のPOとして開発を完了できました。システム開発の経験はなかった私でも、進行できる開発手法です。まずは相談してみることをお勧めします！
福祉保健局 健康安全部
動物愛護相談センター多摩支所
監視第一区担当

山崎さん

開発プロジェクトの経験：今回が初めて
得意なこと：こつこつ決まった作業を繰り返すこと
苦手なこと：クリエイティブなこと

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

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

24

事例② プロダクトオーナーへのインタビュー2「問い合わせ等受理簿のデータベース化」（通称：ANIMAL）

福祉保健局「開発経験がない方にとっても、
コミュニケーションを主軸に進めやすいアジャイル型開発はオススメです！」◆気づき・学び◆
もともと興味がある分野でしたが、動物を相手にしている点などでシステム開発とはまったく前提が違うため、その点を配慮してエンジニアさんに伝えるのはとても難しかったです。その点では、システムの要件を詰める中で粒度の細かい内容を伝えたい気持ちはありつつ、開発に影響なさそうな点は優先度を下げて考えるなど、柔軟な進め方も必要だと感じました。
◆これから挑戦の一歩を踏み出す人へメッセージ！◆
バックグラウンドの異なる方々とのコミュニケーションも必要になるため、柔軟な考え方や躊躇しないでやり方を見直しできる勇気も必要そうです。開発経験がない方にとっても、コミュニケーションを主軸に進めやすいアジャイル型開発はオススメです！開発の経験などがないと「やってみるか！」と一歩踏み出すのに勇気がいると思いますが、実際は開発を進めてみて、おもし
ろかったし、楽しかったので、まずは気軽に一歩踏み出していただければと思います！
開発プロジェクトの経験：今回が初めて
得意なこと：料理と食べること。創作も好き。
苦手なこと：人とのコミュニケーションに
苦手意識ありプロジェクトの満足度
面白さ
大変さ
自分が成長できたか

★★★★★
★★★★★
★★★★★
★★★★★

福祉保健局 健康安全部
動物愛護相談センター多摩支所
監視第二区担当佐野さん

25

事例③ 概要「VOC連続測定データベースの統一化及び可視化」（通称：Yu-ki）

環境局

システム開発に縁のなかったPOが挑んだ、
東京都の空気をより綺麗にするための”多角的分析“ーーー
Before:
自作マクロで分析
After:BIツールを導入

光化学スモッグ注意報の発令数を削減する(※VOCの排出量を低減する)・光化学オキシダ
ント濃度を低減するためのプロジェクト※VOCとは、揮発性有機化合物のこと◆課題
・都内に設置しているVOC連続測定機のメーカーが異なりデータベースが統一できていない。
・自作マクロでは一度に長期間のデータを分析できない。
・自作マクロのため異動などで担当者が変更にな
るとメンテナンス等が困難である。

26

事例③ スケジュール「VOC連続測定データベースの統一化及び可視化」（通称：Yu-ki）

環境局

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

1月

2月

3月

ワークショップ / キックオフ

計画・整理
開発

１

２

３

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

27

事例③ プロダクトオーナーへのインタビュー①「VOC連続測定データベースの統一化及び可視化」（通称：Yu-ki）

環境局「開発が始まる前に思い描いていたプロダクトを、上回るシステムができました。」◆気づき・学び◆「IT知識が乏しいため、システム開発のPOとして仕事できるか」「専門的な仕事（化学関連）を開発
チームに伝えられるか」など、当初とても不安でした。しかし、毎日の短時間の会議で意見交換する中で、不安は解消されていきました。開発チームは自分の考えや思いを形にしてくれ、日々改良されていく
プロダクトをリアルタイムで見ることができたからです。「こんなこと聞いていいのかしら」と思うこともフランクに会議で聞いたり、それでも恥ずかしい場合は質問箱に投稿しました。開発チームから毎回返答があるので、だんだん理解できるようになりました。システム開発というととてもハードルが高かったのですが、少しそのハードルが下がった気がしています。この経験はシステム開発だけでなく、現在の別の仕事のやり方や進め方の見直しにも活かせていけると感じています。
環境局 環境改善部
化学物質対策課
有害化学物質調査担当

野澤課長代理開発プロジェクトの経験：今回が初めて
得意なこと：決まった作業を繰り返す/日々のモニタリングで異変を発見できる
苦手なこと：パソコン操作/オンライン会議（今回の開発で少し慣れた）

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

28

事例③ プロダクトオーナーへのインタビュー②「VOC連続測定データベースの統一化及び可視化」（通称：Yu-ki）

環境局「それぞれの良さを活かしながら、助け合いで開発できるし、安心できます。」

環境局 環境改善部
化学物質対策課
有害化学物質調査担当◆これから挑戦の一歩を踏み出す人へメッセージ！◆
IT知識に自信がない方にこそ向いていると思います。私はパソコンおんちでオンライン会議ほぼ初でした。
そんな私がPO……と不安もありました。
開発が始まる前に思い描いたプロダクトを上回るシステムができました。奇跡に近いと感じます。周りの方の助けもありつつチームで開発を進めているので、安心もできます。昨年度に自分で同じような管理ツールをエクセルで試しに作りましたが、うまくいかなかったです。その経験をもとに考えた時、ウォーターフォ
ール型ではツールの選定や仕様書を自分で作成する必要があると思うので、自分では難しいと感じています。
アジャイル型開発ではデジ局や開発チームがサポートしてくれるので、自分も含めそれぞれの良さを活かしながら、助け合いで開発できるし、安心できます。
IT知識がない私でも開発ができたので、大丈夫ですよ！

野澤課長代理29

事例④ 概要「通学区域デジタルマップ化プロジェクト」（通称：T-MAP）

教育庁

通学地域をデジタルマップ化、
アジャイル型開発で新たな政策検討への一歩を踏み出すーーー
Before:紙の地図などで把握

特別支援学校通学区域デジタルマップ化
プロジェクトAfter:システム化◆課題
・現状は、各校の所在地や通学区域について、紙の地図を用いて把握している。
・各校の所在地や通学区域、学校情報を
デジタルマップで一元的に表示し、今後の政策検討に活かしたい。
30

事例④ スケジュール「通学区域デジタルマップ化プロジェクト」（通称：T-MAP）

教育庁

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

1月

2月

3月

キックオフ
計画・整理

開発

１

２

３

４

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

31

事例④ プロダクトオーナーへのインタビュー①「通学区域デジタルマップ化プロジェクト」（通称：T-MAP）

教育庁「常に仕事を前向きに進めている感覚がありました。」◆気づき・学び◆・ 実現したい内容について、具体的なイメージを持つことが重要だと思います。
・ また、各スプリントで成果を上げる必要があるため、限られた時間の中で優先する事項を整理してチームで共有するなど、POが責任をもって関与する姿勢が求められます。
・ アジャイル型開発の手法は、システム開発に限らず、日々の仕事の進め方等にも活かすことができると感じました。

教育庁 都立学校教育部
特別支援教育課
特別支援教育企画担当

佐藤主任

開発プロジェクトの経験：2回目（ウォーターフォール型開発に携わった経験があります）
得意なこと：掃除と整理
苦手なこと：人見知り

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

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

32

事例④ プロダクトオーナーへのインタビュー②「通学区域デジタルマップ化プロジェクト」（通称：T-MAP）

教育庁「この開発期間がとても楽しかったので、もう1年やりたいくらいです！」◆これから挑戦の一歩を踏み出す人へメッセージ！◆
・ 今回初めて、アジャイル型開発に取り組んで感じた点は、とても楽しく、充実した時間を過ごしたということです。
・ 同じゴールを目指し、課題解決に向けて知恵を出し合うチームで活動するため、常に前向き感がありました。
・ システム開発と聞くと、難しい印象があると思いますが、「課題を解決したい！」という思いがあれば、まずは軽い気持ちで取り組んでみて良いと思います。
・ 有意義な時間を過ごせたため、また機会があれば長期かつ大規模なアジャイル型開発に挑戦してみたいと思います！

教育庁 都立学校教育部
特別支援教育課
特別支援教育企画担当

佐藤主任

開発プロジェクトの経験：2回目（ウォーターフォール型開発に携わった経験があります）
得意なこと：掃除と整理
苦手なこと：人見知り

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

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

33

34

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

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

2．計画フェーズ

全体統括

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

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

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

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

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

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

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

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

POA

Dev

36

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

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

・プロダクトバックログ（※）の管理者であり、ユーザー目線でバックログの優先順位付け等を行う。

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

プロジェクトでは、主にこんな業務をしているよ！
・プロダクトバックログの管理（優先順位付け&並び替え） /アイテムが完成しているか確認
・エンドユーザー、ステークホルダーの意見吸い上げや調整

・おおよそのリソース計画を策定 / 予算の管理（デジ局のアジャイル型開発では、全体統括がこの業務を担当）

PO37

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

・スクラムに不慣れなPOがプロジェクトをスムーズに先導できるように
助言・相談を行う。

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

POA

38

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

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

Dev

39

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

・マネージャーや管理者ではないので、
タスクアサインや進捗管理は行わない。

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

SM

40

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

デジ局が担当します！

・デジ局のアジャイル型開発で追加した役割（一般的なスクラムには存在しない）
・全プロジェクトの統括、進行管理及びプロジェクト運営の推進を行う。

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

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

・各局POとの調整・相談等

全体統括

41

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

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

助言・相談

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

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

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

助言・相談・進行管理

コーチング

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

全体統括◆デジタルサービス局◆

助言・相談・進行管理

42

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

ワークショップの主な内容
1．自己紹介：自己紹介シートを用いて、得意なことや苦手なこと等を打ち明けることで、お互いの距離を縮めました。
2．ミニゲームの実施：アイスブレイクの一環として、ミニゲームを実施しました。初めてチームとしての第一歩を踏み出しました。
3．アジャイル型開発模擬体験：PO体験のワークショップを開催しました。
身近な業務の改善をテーマに、計画フェーズと1スプリント分の流れを体験しました。
ミニゲームでは、「バースデーラインゲーム」などを実施したよ！

短い期間で成果を出すには、早い段階でお互いの関係を構築することが重要だから、ここでチームとして打ち解けられて良かった！

Dev

ワークショップでPOの役割を体験できて、その後の開発に活かせたよ！

PO43

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

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

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

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

44

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

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

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

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

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

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

●

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

全体統括
45

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

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

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

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

Dev

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

PO46

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

イベント内の主な作業●

スプリント内の作業の進捗や問題の共有
毎日同じ時間に実施し、なるべく長時間話し込まずに行うよ。

個別の仕様確認などが必要な場合には関係者だけで別途ミーティングを設定しよう！

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

Dev

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

SM47

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

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

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

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

PO48

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

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

スプリント内のKPT（※）の洗い出し
チケットの見積と実稼働の比較整理
ベロシティの計算妨害リストの作成※KPTとは、継続したいこと（Keep）、改善したいこと（Problem）、
次スプリントで取り組む改善活動（Try）のこと

デジ局のアジャイル型開発ではスプリント内のKPTの洗い出しのみ行いました！

全体統括

49

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

イベント内の主な作業●

チケット（※）の整理や共有

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

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

全体統括

50

51

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

全体統括

52

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

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

供となります。

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

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

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

自局で準備してください。
また、本番環境等の別環境に反映する場合の作業全体統括事業者に丸投げしたり、一方的に無理な等も自局でお願いします。

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

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

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

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

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

について了承ください。

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

だくことから、計画や意思決定、開発チームとのミー
ティング等、業務負荷がかかります。
ご理解のうえ、本事業に参加ください。

未経験で不安という方も、デジ局とPOA

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

お待ちしております！

全体統括
54

55

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

インクリメント

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

各スプリントで作成した成果物。

インセプションデッキ

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

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

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

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

Minimum Viable Productの略語。価値を提供する必要最小限の機能を持つ製品。
プロジェクトの特徴や自分の意見などを簡潔に短時間で伝える手法。
モノやサービスの最終利用者のこと。社内向けシステムなら社内利用者。一般ユーザー向けサービ
スなら一般ユーザーを指す。

スクラムにおける役割の1つ。エンジニアやデザイナーなど開発作業を実際に進める人。
システム内に実装すべき機能。登録機能・検索機能など。

56

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

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

スクラム

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

スクラムマスター（SM）
スクラムイベントスコープ
ステークホルダー
スプリント

スプリント計画
スプリントバックログ

スクラムにおける役割の1つ。開発全体を支援する人。スクラムイベントでの司会や開発における妨害などを解決する。
スクラムを組んだチームがスプリント内で実施する各ミーティング。

プロジェクトで取り組むべき範囲のこと。
システム開発においては関連する全ての人や企業のこと。
開発を反復（イテレーション）する単位。一般的には1, 2週間とされる。

各スプリント内で行うタスクを協議・決定するミーティング。
プロダクトバックログの内、各スプリント内で取り組むタスクのリスト。

57

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

チケット

各スプリントの最後に行う成果物（インクリメント）のレビュー。

取り組む1つ1つのタスク。

チームビルディング

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

デイリースクラム

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

トレードオフスライダー

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

非機能要件

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

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

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

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

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

プロダクトバックログ

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

58

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

ペルソナ

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

ベロシティ

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

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

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

リソース

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

リリース

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

レトロスペクティブ

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

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

作成者/著者

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

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

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

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 ）独立行政法人 情報処理推進機構

60