東京都におけるアジャイル開発

行政情報システム研究所（狩野英司）

編著者:

東京都では、デジタルサービス局の主導の下、準委任契約に基づくアジャイル開発を部門横断的に行う事業に2021年度から取り組んでいます。2022年度には複数のプロジェクトで業務・サービスの改善を達成するとともに、組織内でのアジャイル開発のマインドセットの醸成、参加者の高い満足度の実現が得られるなどの成果を挙げています。本記事では、この取組のうち特に事業推進のプロセスに着目し、どのような流れで、どのような活動が実施されたかを説明しています。

■関連フレームワーク

アジャイル開発プロセス [→行政機関向け本格アジャイル開発タスクリスト]

　東京都の事業では、表１に示すように、行政機関が準委任契約に基づくアジャイル開発を実践する場合に必要とされる14項目のプロセスのうち12項目をカバーしていることが明らかになっています*1。これに対し、従来、行政機関で行われてきたアジャイル開発でカバーされているプロセスは、東京都アジャイル型開発事業の約半数の項目にとどまっています。

表 1　準委任契約に基づくアジャイル開発で実践が求められるプロセスと東京都での実践

こうした実績を踏まえ、行政情報システム研究所では、東京都の協力を得て同事業について事例研究を行い、蓄積されたナレッジを形式知化するとともに、他の行政機関等でも活用できるよう一般化したプロセスとして整理しています。これらの成果は、「行政におけるアジャイル開発の実践に向けた調査研究」報告書（行政情報システム研究所，2024）として公開されています。<https://www.iais.or.jp/reports/labreport/20240410/agile2023/>

　本記事は、同報告書のうち、東京都が実際に実践したアジャイル開発プロセスに係る部分を抜粋したものです。事例研究の結果を一般化したプロセスモデルについては、アジャイル開発タスクリスト（準委任契約／組織横断的推進）を参照ください。また、プロジェクトを実際にどのように進めたのかについては、東京都アジャイル型開発に係るプレイブック🔗（東京都，2024更新）で詳しく紹介されています。

1. 組織横断的な支援・調整体制の確立

個別のプロジェクトに対し、デジタルサービス局に置かれた「全体統括」が組織横断的な支援・調整の役割を担った。全体統括は、各プロジェクトの遂行支援やプロジェクト全体としてのリソース計画、予算管理、スケジュールの調整等を行った。また、各プロジェクトに対し、キックオフの準備、管理ツールの選定・登録、セキュリティ担当部著への申請、各種アカウントの発行、受託者との連絡調整、会議体の段取り（URLの発行、議事メモ作成等）、プロダクト引き渡しまでの段取りなどに関して、様々なサポートを行った。

　全体統括と受託者は、以下のような打合せを実施した。

(1) スクラムチームでのデイリースクラム（朝会）以外に全体統括担当と受託者との全体朝会（毎日）を開催し、個別スクラムチームでは解決できない課題を把握・対処する場とした。また、受託者は、全体のリソース計画、予算、稼働時間の調整などにおいて、全体統括の支援を行った。

(2) PO分科会（隔週）：個々のスクラム開発のベロシティ（開発チームが作業を進める「速度」または「作業量」）を定期的に把握した。

2. プロダクトオーナー(PO)のアサイン

事業を開始するにあたり、まずプロダクトオーナー（PO）の役割を定義した。その上で、各局への応募案件のヒアリングに際し、POの役割を理解してもらうよう説明を行った。さらに、案件の選定にあたっては、POとしての適性やプロジェクトへの向き合い方もヒアリングした。

　全体統括は、プロジェクト開始にあたり、セキュリティを始めとする全庁ルールに基づく外部サービス（ノーコード・ローコード開発ツールやSaaSなど）利用の申請手続きやPC等の端末環境の手配を各局POと調整して行った。ツールの選定やプロダクトバックログの優先順位の決定にあたり、開発事業者との調整にあたった。

3. 予算の見積り

アジャイル事業に知見のある事業者との意見交換も参考にしながら、４件ほどのプロジェクトのリソースを一括して調達する前提で概算費用を見積もった。その上で、事業開始後もプロジェクトによって、スプリントの回数を追加するといったリソースの調整を行った。全体統括が、プロジェクト全体のリソースの消化状況やスケジュールの進捗状況をマネジメントした。

4. 開発方針の策定

アジャイル型開発の認知度を上げるため、東京都の庁内各部局で参加を募る必要があった。全体統括は各部局に対し、案件発掘のために事務連絡の発出や各局の有望な案件への働きかけ、チラシの配布といった、“営業活動”を積極的に行った*2。募集対象としたのは、2～3カ月である程度の成果が見込める小規模なシステムやWebサービスなど。その際には以下を明示した。

(1) 準委任契約を前提とするため、成果物の完遂や納品を求めることはできない。限られた期間や工数内で開発を進めるために、各部局は主体的に開発に関与してもらう必要がある。

(2) 本事業にかかる費用は、デジタルサービス局の負担で実施する。

案件の選定は次のような観点で行った［案件内容のアジャイルへの適合性／POの役割の理解／POのアジャイル開発の理解］、なお、POが事業担当の東京都職員であり、大規模な開発にいきなり着手することは難しいので、ノーコード・ローコード開発ツールを使った小規模な開発を中心に案件を募集した。同じ理由で基幹システムは検討対象外とした。

5.パートナー企業の探索・確保

東京都の入札に参加したことのない事業者も含め、アジャイル開発を受託できる事業者を積極的に探索した。具体的にはアジャイル開発を行っている事業者のウェブサイト等を通じて検索し、事業の説明を行うことで興味を持ってもらった。事業を実施するうえで、ボトルネックになり得る問題点などをヒアリングした。これまで官公庁の案件を受託したことがなく、東京都の入札参加資格がない事業者の場合には、参加資格が必要なことを教示した。

6. ユーザーストーリーの作成

準委任契約を前提とするため、調達仕様書にはシステムの要件は規定せず、プロジェクトにアサインできる専門人材の工数を規定した（プロジェクトの数と期間、各役割の工数）*3。ただし、対象案件の性質が「WebサイトやWebサービス等のプロトタイプ等」であることを示し、受託者がどのような人材を確保すればよいかは明示した。（気づき：何を作るのかを示さないと受託者が応札へのリスクから参入を躊躇してしまう。）

7. 調達仕様書の作成

調達仕様書において、事業者がアサインするプロダクトオーナー（PO）支援、スクラムマスター、開発チームの要員が備えるべき業務経験や資格などの必須要件を設定した。

8. 準委任契約の契約書の作成

単価契約によって支払額が決まる準委任契約の約款を、アジャイル開発方式を用いたプロダクト開発用に整備し、受託者との契約を締結した。

9. 関係者のアサイン

各プロジェクトのキックオフ時にチームビルディングのためのワークショップを実施した*4。ワークショップでは、スケジュール、自己紹介、ミニゲーム、アジャイル型開発模擬体験を実施した。なお、スクラムチーム編成前にも事前打合せを行い、コミュニケーションを図った。

10. アジャイル開発の推進

計画フェーズでは、開発に入る前にインセプションデッキ、ユーザーストーリーマップ、プロダクトバックログを作成し、スクラムチーム全体の認識を合わせた。　プロダクトバックの管理はスクラムボードを用いて行った。スプリントは、プロジェクトによって、スクラムの期間をチームで1週間または2週間の間で設定した。

　イベント（会議体）として、スプリントプランニング（計画）、デイリースクラム（朝会）、スプリントレビュー（レビュー）、スプリントレトロスペクティブ（振り返り）、バックログリファインメント（見直し・再整理）を設定した。

　テスト工程として、機能（単体）テスト、表示テスト、誤字脱字、追加機能の管理画面操作説明書、結合テストを受入テストとして実施した。

11. 支払のため稼働管理

月毎・プロジェクト毎に開発チーム全員の稼働時間を分単位で管理・報告することを求め、月毎に単価契約に基づく清算を行った。

12.プロダクトの確認

個々のプロダクトは調達仕様書で規定していない。各プロジェクト内で作成するドキュメントの一覧を示すとともに、受託者に品質確保のためのテストの方法や納品物について提案を求めた。その上で、各プロジェクト内で、ソフトウェアの品質を確保するための各種テストを行うとともに、プロダクトの受入基準を定め、リリースの条件とした。

13. ナレッジの収集・蓄積・共有

PO／開発チーム／全体統括それぞれの視点で振り返りを行った。受託者は振り返りレポートを作成し、今後に向けて継続すべき良い点と今後の改善点を整理した事業を通じて得られた知見や経験をもとに、アジャイル開発実践のためのノウハウや課題、これから挑戦の一歩を踏み出す人へのメッセージなどを記載した東京都としてのプレイブックを作成した。また、次年度以降もプレイブックをナレッジの蓄積に利用していくこととした。（気づき：プロジェクトをうまく推進させるためには、デジ局によるお膳立てが必要であった。）

14. 継続的な改善

ノーコード・ローコード開発ツールで構築したプロダクトの一部は、現場の東京都職員によってある程度、自律的な改善を行っていけるようにした。（気づき：プロダクトの中には開発終了後も十分に試行・準備をしてから、実装という案件もあった。）

*1 狩野英司，行政における準委任契約に基づくアジャイル開発プロセスに関する一考察，経営情報学会2023年全国研究発表大会

*2 東京都「アジャイル型開発案件募集チラシ」（参考２）

*3 「東京都アジャイル型開発に係るプレイブック」p.44, p.59

*4 「東京都アジャイル型開発に係るプレイブック」 p.43

参考1：用語集

用語	解説
CoE	Center of Excellenceの略。優れた人材やノウハウを集約し、組織横断的な取り組みを継続的に行うための中核となる部署やチーム。
DevOps	Development（開発）とOperations（運用）を組み合わせた造語で、開発担当者と運用担当者が連携して、継続的にシステムの価値向上を図る取組み。
GUI	Graphical User Interfaceの略。コンピューターの操作をマウスなどを用いて視覚的に行えるようにするインターフェース。
IPA	独立行政法人情報処理推進機構
MVP	Minimum Viable Productの略。実用的で最小限の範囲で動くプロダクト。
PO	プロダクトオーナー（Product Owner）の略。開発する機能の仕様策定に関する議論を主導し、開発機能の優先順位や実現方法等に対する意思決定を主体的に行う役割を指す。開発する情報システムの価値を最大化することに責任を負う。（内閣官房）[1]
RFI	Request For Informationの略。情報提供依頼。
SaaS	Software as a Serviceの略。利用者に、特定の業務系のアプリ、コミュニケーション等の機能、運用管理系の機能、開発系の機能、セキュリティ系の機能等がサービスとして提供されるもの。（デジタル庁1[2]）
UI	ユーザーインターフェースの略。画面や音声入出力、キーボードなど、システムにおいてユーザーに対する情報提供や操作手段に関係する要素のこと。（重点計画[3]）
UX	ユーザーエクスペリエンスの略。あるサービス（システム）を使う課程で起きるユーザーの知覚及び反応。（ニーズが適切に満たされることで）達成感を感じたり、システムを快適に利用できる。（重点計画）
アジャイル開発	アジャイル開発対象となる機能の設計・開発をイテレーション（反復）と呼ばれる短い期間に分けて進め、イテレーションが終了するごとに機能の動作を確認できることを特徴とした情報システム構築作業の進め方である。[4]（デジタル庁2）
インセプションデッキ	これから取り組むプロジェクトの概要や目的、そしてゴールに対する共通認識を持つためのドキュメント。（東京都）[5]
ウォーターフォール型開発	工程を時系列に進め、原則として前工程の完了後に次工程を開始する情報システム構築作業の進め方（デジタル庁2）
請負契約	「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる」契約（民法第632条）
エンドユーザー	提供されるモノやサービスを最終的に利用する人や組織。
基幹システム	企業・団体における主要業務をシステム化した情報システムの総称。地方自治体であれば住民情報システム、税システム、福祉システムなどが該当する。（総務省[6]）
サブスクリプション契約	商品やサービスやサービスを購入せず、その利用権に対して課金する契約方式。
準委任契約	特定の業務を遂行することを定めた契約のうち、法律行為以外の業務に係る契約。仕事の結果や成果物に対する完成の義務は負わない。
随意契約	競争入札によることなく、特定の者を選定して締結する契約。
スクラムチーム	スクラムマスター１人、プロダクトオーナー１人、複数人の開発者で構成されるチームであり、スクラムの基本単位。（スクラムガイド）[7]
スプリント	開発に必要な行為やイベントが一通り揃った、スクラムにおける開発期間を指す。スクラムでは、スプリントを単位として反復して開発する。（内閣官房）一般的には１週間から２週間とされる。
善管注意義務	善良な管理者の注意義務の略。業務を委任された人の職業や専門家としての能力、社会的地位などから考えて通常期待される注意義務。（デジタル大辞泉）
デイリースクラム	開発チームの状況について共通理解を持ち、スプリントのゴールが達成できそうか確認するために毎日１５分程度の短時間で行うミーティングを指す。（内閣官房）　朝会、デイリースタンドアップと呼ばれることもある（立ったまま行うため）。
プロダクトバックログ	システム開発に必要となる要求のリスト。リストの並び順で取り組むべき順序を表現する。（内閣官房）
ローコード開発・ノーコード開発	少ないコード又はコードを使わずにソフトウェアを開発する手法。GUIによる視覚的な操作によって、コードの知識が乏しくてもソフトウェア開発を行うことが可能。
非機能要件	機能要件以外の情報システム要件のこと。具体的には性能や信頼性、拡張性、運用性、セキュリティ等がある。
ベロシティ	開発チームが作業を進める「速度」または「作業量」。
ユーザーストーリー	エンドユーザーができる機能を簡潔に表現したもの。「○○が××をしたい」などの形式で表す。
要件定義	情報システムに関する調達（情報システムの設計・開発、機能改修、運用若しくは保守等業務の委託に関する調達又は情報システムを構成する機器若しくはソフトウェア製品等の調達）を行うに当たって、必要な要件を明確に定める行為又はその定めた内容のこと。（デジタル庁2）