東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた

「初！都庁職員、アジャイル型開発に参加する」
東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。

これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？

東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。

コロナ禍で浮き彫りになった、「迅速」の重要性

──まず、東京都はソフトウェアシステム開発において「発注側」の立場です。特定のソフトウェア開発手法を採用するという取り組みが、開発側ではなく発注側にあるという点がユニークです。東京都としてアジャイル型開発を推進するモチベーションはどこからきたのでしょうか？

石川秀之さん（以下、石川）：きっかけの1つは、やはり新型コロナウイルス感染症だったと思います。新型コロナウイルス感染症の流行によって、自治体として、給付金対応など、通常時にはなかった業務が急遽発生することになりました。

しかし東京都には、こうした突如発生する案件に対して、限られたリソースの中でソフトウェア開発をしてもらうための体制がなかったのです。業務で何かしらのソフトウェアシステムが必要となっても、その時点から外部の事業者と契約手続をして開発してもらう、という従来的なフローでは、現場で発生するニーズに迅速に対応できません。

新型コロナウイルスの感染が拡大していた頃は、現場の職員が必要に応じて最低限のシステムを内製するしかなく、各所でかなりの苦労があったと聞いています。

石川秀之さん：東京都デジタルサービス局 戦略部DX推進担当課長

──もし東京都から業務に必要なシステムの開発を外部に発注するとなった場合、通常であればどのようなプロセスとスケジュールで進むのでしょうか。

石川：大まかには、まずは予算化し、議会の承認を得て、翌年度から開発に着手することになります。1月頃に知事の予算査定があり、3月に議会で予算承認、4月に契約をして発注といったスケジュール感です。

──いざ発注をするとなったら、おそらく入札の段階で、かなり詳細な要件仕様を作成するのですよね。

石川：その通りです。その要求仕様に基づいて発注が決まったら、最終的にプロダクトを検収して受け入れるまで、各工程でドキュメントによるチェックをしながら手順通りに段階を踏んで設計開発を進めてもらいます。いわゆるウォーターフォール型の開発ですね。東京都に限らず、自治体におけるソフトウェアサービスの開発は、おおむねこのような形で進むことが多いはずです。

都民の皆様からお預かりした税金を使う以上、発注の適正性や成果物の効果をしっかりと検証しなければなりませんから、こうした開発プロセスになるのは、理にかなっている部分があります。しかし一方で、急遽発生する業務をデジタル化するために必要な、迅速性や俊敏性にはどうしても欠けてしまうという課題がありました。

──東京都がアジャイル型開発を採り入れる動機は、「迅速」「俊敏」への課題感が顕在化した結果と言えそうですね。

石川：はい。とくに新型コロナウイルス感染症への対応という社会の大きな変化を経て、また、自治体運営における従来的な価値観が必ずしも現状の社会とは適合しないケースが増えていく中で、堅牢性と迅速性のバランスを考慮したソフトウェアシステム開発が必要になります。ですから、都としてアジャイル型開発にチャレンジしようと考えたのです。

──「迅速」が求められる状況に対応するという目的があり、そこからアジャイルに目を向けられたというのが興味深いです。

石川：実は「アジャイル」という言葉自体は、東京都の構造改革推進プロジェクトであるシン・トセイにも登場しています。具体的には、改革実践の5つのキーワードを都庁内に定着させようという方針がありました。そして、定着を目指すキーワードの1つが「アジャイル」です。

シン・トセイでは改革のキーワードとして「スピード」「オープン」「デザイン思考」「アジャイル」「見える化」の5つを掲げている。
画像は「＃シン・トセイ 都政の構造改革ポータルサイト」より引用

石川：シン・トセイでは、「アジャイル」は「環境やニーズの変化に大胆かつ弾力的に対応し、確認と改善のプロセスを絶えず繰り返します」と明文化しています。デジタルサービスやシステム開発に限定した言葉としてではなく、もっと概念的な意味での「アジャイル」には馴染みがありました。

また、シン・トセイの5つの理念の中には「アジャイル」のほかに「スピード」というキーワードもあります。これは「社会や人々の価値観の急速な変化にも的確に対応するため、デジタルを駆使し、スピード感をもって課題解決につなげます」と明文化しています。

これらのキーワードをデジタルサービスやDXの文脈に置いた際、アジャイル型開発という選択肢が得られます。そして、アジャイル型開発を都庁内にしっかり定着させていくことが、私たちデジタルサービス局の重要な役割と捉えたのです。

「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発に向くプロジェクトを掘り起こす

──「都庁でアジャイル開発を推進しよう」と考えた場合も、具体的なシステム開発で実践するとなると、やはり予算化して議会に承認を取るというフローは必要になるのですよね。

下家昌美さん（以下、下家）：はい。最終的なゴールは、デジタルシステムを必要とする部局が自律的に事業者と契約し、アジャイル型開発をできるようにすることだと考えています。

ただ、いきなり「アジャイル型開発をやってみましょう」と言っても、現場には必要な知見が全くありません。そこで昨年度（令和4年度：2022年4月〜2023年3月）、まず職員にアジャイル型開発を体験してもらうための試行的なプロジェクトを開始しました。

下家昌美さん：東京都デジタルサービス局 戦略部デジタル推進課 各局支援担当 課長代理

──試行的なプロジェクトということは、開発対象を定めずに民間の事業者に入札してもらったのでしょうか？

下家：いえ、開発対象と開発ツールを仕様書で例示したうえで、入札に参加していただきました。エンジニアを確保して入札に参加するというコストを事業者に負ってもらうからには、業務内容をある程度、仕様書に記載する必要があります。こうした入札における情報の必要性は、ソフトウェア開発の事業者からヒアリングをする中で把握していきました。

かといって、具体的な仕様がすでに定まっている大きな事業でいきなりアジャイル型開発を実践するのは困難です。そこで庁内に声をかけて、業務改善を目的とした比較的小規模なシステム開発などのニーズがないかを探すことにしたのです。

──どうやってそうしたシステム開発のニーズを探したのでしょうか。

下家：「皆さん業務で困っていませんか、そのためのデジタルシステムをアジャイル型開発で作ってみませんか」という内容のメールを各局宛に配信することで、募集をしました。

職員の皆さんからすると、「アジャイル型開発をしてみませんか」というメッセージだけではよくわからない面もあるので、アジャイル型開発による業務改善のイメージを伝える内容も含めています。「今は紙で行っている業務内容をシステムに入力すれば、情報を蓄積でき、データベース化できます」とか、「蓄積した情報を電子上で決裁できます」または、「ウェブページの改修も行えます」などがわかるように記載しています。

令和4年度（2022年）実際に配信されたメールの内容（連絡先部分のボカシ処理はAgile Journey編集部による）がこちら。アジャイル型開発に不慣れな職員に向け、概略や開発の大まかな流れも記載されている。

──案件募集にあたって、何か条件は課していたのでしょうか？

下家：条件は特になかったのですが、機密性が求められる業務や、ミッションクリティカルで都民の皆様の生命、財産にかかわるようなシステムは、試行的な取り組みには馴染まないので、あくまでも業務改善などを想定して募集しました。

結果、複数の局が「自分たちのやりたいこと」を書いて応募してくれました。それをもとに我々から詳細をヒアリングし、最終的に4件のプロジェクトを開発しました。

アジャイル型開発を実施したのは、この4件のプロジェクトだ。環境局、福祉保健局（現 保健医療局）などが参加した。
スライドは「東京都アジャイル型開発に係るプレイブック開発事例集 P2」より引用

アジャイル型開発実践に向け「準委任契約」を採用

──開発対象のシステムがはっきりしたら、次は事業者の選定、契約という段階です。どのようにシステム開発を担う事業者を選定していったのでしょうか。

下家：都のシステム開発において、過去に契約実績がある事業者の中には「どのような開発を行うか予め明確に定まっていない」という試行的な事業への入札に戸惑いもあったようでした。都の入札に参加したことのない事業者も含めてヒアリングをするなかで、「何も決まっていないところから開発を始めるのが得意」という事業者がいることもわかりました。

──入札によって事業者を選定するのですね。

下家：そうです。入札にもいくつか方式があるのですが、今回は価格だけで決める入札ではなく、仕様書に基づき技術やノウハウなど事業者からの提案内容も含めて評価する「総合評価方式」を採用しました。

──アジャイル型開発を実践する、という前提があるなかで、契約形態には通常とは違う点もあったのでしょうか。

石川：従来的な開発では、仕事をお任せして成果物を納品していただく「請負」という形で契約を交わしていました。しかし、今回の開発はアジャイル型開発であり、事業者は一緒にプロジェクトに参画し、デジタルシステムを構築していく、つまり、稼働に対して対価をお支払いするという考え方になるので、「準委任」という形での契約をお願いしました。

「準委任」契約は、都の契約として、例えば庁舎のフロア清掃といった仕事をお願いする場合は一般的ですが、デジタルシステム開発に関する契約では、今回の事業が初めてだったと認識しています。

下家：事前にアジャイル型開発の準委任契約について定めた約款を作成するなど、契約業務を所管する財務局と調整しました。

当時、独立行政法人情報処理推進機構（以下、IPA）から「情報システム・モデル取引・契約書（アジャイル開発版）」が公開されていて、その中で「アジャイル型開発は、請負契約での実践が難しいので、準委任契約がより適当である」と指摘されています。こうした情報も参考にして、準委任契約の約款などを整備していきました。

──IPAの資料は、民間企業向けと想定されていると思いますが、そうした情報も積極的に参考にされていたのですね。

下家：はい、モデルケースがなかったので、国や他自治体のアジャイル導入資料などとともにかなり参考にしました。

石川：従来のような請負契約では我々がプロダクトオーナーとして直接プロジェクトに参加しにくいことも難点になります。請負契約の性質上、直接の指揮命令はできないので基本的には仕様書に書いたとおりのことを遂行してもらい、納品してもらうしかありません。よって必然的に、自治体がアジャイル型開発をやるには、おそらく準委任という契約方法しか選択肢がないように私は思います。

デジタルサービス局が統括しつつ、各局でスクラムを実践

──いよいよ開発の様子について伺いたいと思います。とはいえ、すでに詳細かつ親しみやすい2編の記録が「東京都アジャイル型開発に係るプレイブック / 開発事例集」（以下、プレイブック）として公開されていますね。

下家：デジタルサービス局としても初めてのアジャイル型開発なので、先ほど話題に出たIPAの資料などを通じて勉強を重ねましたし、様々な議論を通じて多くの経験を積むことができました。インプットを重ねながら各プロジェクトを進めていったのですが、その記録がこのプレイブックです。

──プレイブックによると、1つのプロジェクトにつき4～6スプリントで、かなりきっちりとスクラム開発を実践されています。プロジェクトによってはプロダクトオーナー（以下、PO）を2人置いていたり、更にどのプロジェクトにも、プロダクトオーナーアドバイザー（以下、POA）というPOの補佐役を置いているのが印象的です。

“東京都初のスクラム”はこの5種の役割を設定し実施された。
スライドは「東京都アジャイル型開発に係るプレイブック開発事例集 P8」より引用

石川：POは、職級は問わず、それぞれの現場で業務をいちばん知っている職員に担当してもらいました。 上司やステークホルダーと調整して要件を判断できるなら、どなたでもPOを担えますが、調整にあまりに時間がかかってしまうと、肝心な「迅速」というアジャイルの良さが半減してしまいます。幸いにも各局のアジャイル事業への理解もあって、必要に応じPOを2人体制にするなど、業務を分担できるように工夫して行うことができました。

下家：POAという役割を置いたのは、アジャイル型開発かどうか以前に、そもそもシステム開発に馴染みのない職員が多いからです。実用書や研修などで勉強したとしても、いきなり「バックログを作ってください」と言われては戸惑ってしまいます。ですから、開発をよく知る事業者がPOAを担い、POをサポートしました。

──スクラムでは、それらPOのサポートはスクラムマスターが担うことが想定されていると思いますが、あえて別の役割を設けたわけですね。

下家：はい。システム開発に慣れていない職員に寄り添って、彼らがやりたいことを一緒に考えるには、スクラムマスターとはまた別にシステム開発の知見がある人のサポートが必要と考えたのです。POAは「アジャイル型開発を熟知していて、かつ職員側」という立ち位置の役割と捉えています。

──もう1つ、プレイブックを拝見して特徴的に見えるのは、「全体統括」という役割の存在です。

下家：全体統括は、デジタルサービス局が各プロジェクトを管理するために置いた役割です。本来であれば、予算や期間もPOが責任を持つところですが、今回のプロジェクトはどれも「デジタルサービス局の事業」として実施しているので、そうした権限は我々にしかありません。

そこでデジタルサービス局の職員、具体的には私自身ともう一人が各プロジェクトのスクラムチームに参加するために全体統括という役割を置きました。プロジェクトの管理だけでなく、開発に参加する職員のサポートも全体統括の役割です。例えば、都のネットワーク環境や、業務でなんらかのSaaS製品を使う際に必要な申請、あるいは使用ができないツールの詳細など、各局の職員が把握しにくい要件に関しては、デジタルサービス局が随時、迅速に知見として共有し、開発がスムーズに進むようサポートします。

──ということは、下家さんは4つのプロジェクト全てでスクラムに必要なミーティングに参加されていたわけですね。さすがに開発者によるデイリースクラムにも参加するのは難しそうですが。

下家：4件のプロジェクトが重なる時期があったので、時間的にどうしようもなく諦めたことはありましたが、令和4年度はデイリースクラムを含むほぼ全てのミーティングに参加しました。

アジャイル型開発の知見を広めることが事業目的の一つですから、デジタルサービス局は細大漏らさずプロジェクトを観察しなければなりません。先に挙がったプレイブックを作るためにも、できる限り各プロジェクトに参加する必要がありました。

チーム内のギャップ、自治体と事業者間のギャップや制約を乗り越える

──事業者としても、デジタルサービス局の方がチームに入っていることに対して、きっと安心感のようなものがあったでしょうね。

下家：決定権を持つ人が組織内にたくさんいることや、いわゆる縦割りのような風土、ツールの選定にも制約があることなど自治体にはどうしても民間と違う部分があるので、全体統括という役割が事業者の感じるギャップを埋めるのに役立ったと思います。とくに、昨年度の受注者であるスパイスファクトリーは、自治体との仕事が初めてだったので、プロジェクトを進める上で安心材料と捉えていたように感じました。

ギャップという観点では、都庁の職場ならではの仕事の進め方や文化に起因するものもあります。たとえば、紙の取り扱いです。DX的な発想では全て電子化するような業務でも、現場のやり方を考えると、その時点では紙のフローを残したほうがいいステップがある、といった場合もあります。こうした文化的なギャップの調整も全体統括としてのデジタルサービス局の役割でした。

──事業者側が感じるものだけでなく、各局の職員の方が感じるギャップもありそうですね。

下家：都庁のソフトウェア開発に関する契約はこれまで基本的に請負契約なので、職員の主な仕事というのは「仕様書どおりに業務が遂行されているかを確認すること」でした。いわば進捗管理が職員の仕事だったわけです。

しかしアジャイル型開発では、職員もチームの一員として、課題解決のために一緒に考えることが要求されます。この点が、従来型の開発を知る職員にとってはギャップだったかもしれません。

石川：職員の従来的なマインドセットをリセットするために、プロジェクト初期にワークショップを実施したりもしましたね。

下家：とくにPOについては、「指示をするのではなくチームの一員として同じ立場で一緒に開発することになる」という話を応募の前提としていて、プロジェクト選定のためのヒアリングでも説明をしてきました。

──そうした説明を受けて、「それなら応募をやめる」というプロジェクトもあったのでしょうか。

下家：今年度はありました。ただし直接の理由は、開発に参加することで発生する稼働を確保できない、本来の業務がある中で1〜2か月のプロダクト開発に一定の時間を捻出するのが困難、というものでした。

──採用されたプロジェクトでPOとなった職員の方の稼働の調整について、デジタルサービス局で何か対処するようなこともあったのでしょうか。

下家：それは全くありませんでした。POになる職員が個人で応募するわけではなく、上司の同意を含めた、組織としてのプロジェクト参加意思をもらっているので、開発参加職員の稼働量や時間の調整は、応募された局内で行われたと聞いています。

また、開発に関連した業務報告も、タイミングを見て適宜実施されていたと聞いています。開発経過を上司に見せてフィードバックを得て、それを次のスプリントに反映させるといったサイクルは、どのプロジェクトでも実施されていました。プロジェクトの後半に差し掛かれば、開発中のシステムを実際に触ってもらうといったことも可能になります。

──なるほど。スプリントごとに必ず成果物があるので、報告という観点ではアジャイル型開発のほうがやりやすいかもしれませんね。

2年目の今年度、プロジェクトはより拡大した。アジャイル型開発を都庁全体に浸透させるために

──最後に、これからのことを聞かせてください。令和4年度の4つの試行的プロジェクトを経て、今後はどういう形でアジャイル型開発に取り組まれるのでしょうか。

石川：令和4年度の事業を通じて、「アジャイル型開発でやれるプロジェクトがある」ということは実証できました。2年目となる今年度は、これを仕組みとして定着させるべく、プロジェクトの数を10件に増やして昨年度と同じようにプロジェクトを募集しました。

──今年度の応募件数が増えたのかどうかが気になります。

下家：実は、応募件数という点では昨年度からあまり増えませんでした。ここは課題だと考えています。「アジャイルをやりたい」という人をもっと都庁内に増やしていかないといけません。

──プロジェクトの内容については、昨年度と同じく小規模な業務改善プロジェクトが中心なのでしょうか？

下家：昨年度は4スプリントほどに収まる小さなプロジェクトが中心でしたが、今年は8スプリント、つまり開発期間が2ヶ月程度に収まるプロジェクトに拡大して募集をかけました。

実際に動かしているプロジェクトの中には2ヶ月では収まらないものもあって、優先順位を付けて断念すべき部分を切り出しつつ、各職員が自ら開発を引き継ぐか、別の事業者に改めて発注するかなど、引き続き機能追加・改善していくことも検討しています。

また、プロトタイプをアジャイル型開発で作成し、その後、規模の大きい本体開発の要件定義作成につなげる事業もあります。昨年度よりも多様な取り組みが各局から出てきているので、これはとてもいい傾向だと感じています。

──単年度で収まらない開発をアジャイル型で進めるとなった場合、同じ事業者に発注できるのでしょうか。

石川：同じ事業者に発注することは可能ですが、調達の制度上、改めて入札が必要になります。

──では、別の事業者になっても引き継げるよう、アジャイル型開発であっても仕様をドキュメント化して残すといった対応が必要になりそうですね。

下家：実際、昨年度も手順書が必要という案件はあったので、バックログに起こして必要なドキュメントを作成したことはありました。今年度のプロジェクトにも継続開発を視野に入れたものがあるので、必要であれば機能追加の手順や設計ドキュメントなどを残すという選択肢はある、といった話を開発過程でPOに伝えています。

石川：維持管理しながら継続して使っていくシステムを、「準委任」のアジャイル型開発で作った場合、それを次年度以降に異なる事業者に適切に引き継げるか、という課題は、今後発生し得るものだと考えています。

東京都で開発するシステムは多種多様ですから、中には「請負」のほうが適するものもあるでしょう。アジャイル型か従来型か、適切に選択できることが大事だと考えています。

──事業者が年度で変わることには、スクラムチームの維持が困難という面もありそうです。

下家：事業者だけではありません。自治体では異動が避けられないという実情があるので、職員についてもプロジェクトを担当した人間が、翌年度以降も同じチームにいるとは限りません。こうした人員編成の流動性は課題かもしれません。

──まだまだ課題は多いと思いますが、それでも皆さんがアジャイルに取り組み、都庁に浸透させようとしているのですね。

石川：日々変化するニーズを汲み取りながら、常に改善を繰り返していくことが、都政や都庁の業務でも重要です。こうした考えをシステム開発の文脈で体現する手法として、アジャイル型開発という選択肢がありますが、アジャイルなマインドセットを都庁全体の1つの文化として根付かせることが、都民の皆様が都政に期待するものを迅速に具現化することに繋がるはずだと考えています。

下家：最大の目標は、個々のプロジェクトを成功させるだけでなく、この開発手法を都庁にもっと浸透させることです。ですから、今年度は情報発信の拡充も進めていて、昨年度のようなプレイブックはもちろん、アジャイルに関する漫画を職員に向けて周知するといった情報発信活動も行っています。

──都庁全体でアジャイル型開発手法が当たり前の選択肢になれば、次年度への引き継ぎといった課題も解消しやすくなりそうです。アジャイル型開発のマインドセットが、ソフトウェア開発に留まらず、都政のさまざまな側面に波及していくかもしれませんね。今日はとても意義のある取り組みについてお聞かせいただき、ありがとうございました。

合わせて読みたい関連記事

ステークホルダーの多いプロジェクトでもスクラムが効果を発揮するまでヤフーが取り組んできたこと─スクラムマスターとアジャイルコーチの役割とは

アジャイルをスケールさせる手法に正解はない 自社のモデルを探す事例と課題 平鍋健児さんに聞く

組織に対するカオスエンジニアリングの実践 - 変化に対応する組織をつくるための課題を探る「カオスWeek」という取り組み

取材・構成：鹿野 桂一郎（@golden_lucky / ラムダノート）
編集・制作：はてな編集部