年度末の予算成立に向けて仕様書を固め、入札を経て、要件に合わせたシステムをウォーターフォール方式で開発していく──そんな進め方が一般的だった自治体のシステム開発のあり方が、近年変わりつつあります。
中でも大きな反響を呼んだのが、2022年から2023年にかけての東京都の取り組みです。社会情勢の急速な変化に対応し、限られたリソースで現場のニーズにマッチしたシステムを迅速に実現するため、アジャイル方式を採用して4つのプロジェクトを遂行。さらに、そこで得られた知見をクローズドにせず、「アジャイル型開発プレイブック」として広く公開するまでが、都にとって初となる挑戦の全容でした。
ただ、いくらアジャイルやスクラムといった手法や考え方を採っても、内製体制が整っていない組織の場合、発注する側だけでは完結しません。
一連の東京都のプロジェクトの委託を受け、前例のない取り組みを一体となって並走したスパイスファクトリーの小島寛人さんと泰昌平さんに、受託側の思いやプロジェクトを加速させるポイントを伺いました。
▼東京都デジタルサービス局へのインタビューはこちら agilejourney.uzabase.com
- 「前例踏襲」の先入観に反し、協力的に進んだ東京都のアジャイル開発
- スクラムの基本を忠実に守り、「2週間ごとの成功体験」を積み上げる
- 前例のない取り組みに再現性を持たせる「プレイブック」の価値
- 「東京都がやってるなら、自分たちも……」勇気を持てるモデルケースを作れた
- 【関連記事】受発注の壁を越え、現場を動かす
「前例踏襲」の先入観に反し、協力的に進んだ東京都のアジャイル開発
── アジャイル方式によるシステム開発を受注するのは民間企業同士の場合でも慎重になりがちだと思います。ましてや、東京都という大規模な自治体のプロジェクトを受託するのには決断が必要だったのではないでしょうか。
小島寛人さん（以下、小島）：確かに、前例のないスタイルに慎重な事業者も多かったようですが、私たちはむしろそこに可能性を感じていました。「これはやるべきプロジェクトだ」と、迷わず手を挙げたんです。
実はこれはスパイスファクトリーの強みでもあるのですが、顧客ニーズとしても、あまり要件が固まっていない段階から入っていくケースがほとんどなんです。
泰昌平さん（以下、泰）：私たち受託側が介在する意味は、単に決まった通りにシステムを作ることではありません。何も決まっていない状態から入ったり、お客さまの「変えたいけれどこれまで変えられなかった」部分に一緒に踏み込んで変えていく。
私たちのミッションは「革新の触媒 “The Spice Of Innovation”」ですが、東京都のプロジェクトではまさにその役割を果たせると考えていました。
小島：ただ一般には「お役所」は決まったとおりに仕事をすることを重視し、何のためかよく分からない作業が発生するもの──という先入観がありますよね。自分も受注直後は「前例踏襲を優先する方たちとうまくやっていけるだろうか」と心配だったのも事実です。
実際には全然そんなことはなく、むしろ民間企業よりも協力的で、利用者のことを考える方々と共にプロジェクトを進めることができました。
ビジネスの現場ではどうしても事業存続や成長のために収益が目的化してしまいますが、東京都の職員は大切な税金を預かり、都民ファーストで「より良くしていく」ところにフォーカスを当てて仕事を進めていく。まさにアジャイルやスクラムの文化や原則を体現するような人たちでした。
ですから、『プロジェクトX』のようなドラマチックなぶつかり合いはありません。「ここは譲ろう」「ここは粘ってやり遂げよう」といった事柄を、目的に対して真っ直ぐに協力し合いながら進めていきましたね。
泰：私は4つのプロジェクトのうち動物愛護センターのデータベース化に関わりました。確かに、東京都の皆さんはアジャイルという進め方自体は初めてでしたが、現場の課題をしっかり感じ、自ら変えていこうという意欲を強く持っていたことが印象的でした。
「変えたいけれどこれまで変えられなかったこと」にフォーカスし、アジャイルで変えていくプロセスに一緒に伴走できました。受発注の関係ではなく「ワンチーム」で実現できたことは、私としてもいい思い出です。
── アジャイル開発の経験がない皆さんにワンチームとして一緒に取り組むためには、最初の関係値づくりが非常に重要になりますよね？
小島：もちろんいくつか工夫はしました。最初にみんなでアイスブレイクを兼ねたカジュアルな自己紹介を行い、さらにゲーム形式のワークショップを通して「アジャイルとは何か、スクラムとは何か」を、体験しながら学んでいただく機会を設けました。
職員の皆さんにプロダクトオーナー（PO）になってもらい、あるテーマに沿ってスクラムをワンスプリントだけ疑似体験してもらったんです。ユーザーストーリーを付箋に書いて、「これだと大き過ぎるから、もう少し細かく切ってみましょうか」といった体験をしてもらい、アジャイルやスクラムの考え方を理解していただきました。
泰：ちょっとしたゲームっぽさを取り入れることで、面白さを感じてもらいました。チームの距離感が縮まり、その後も心理的安全性を確保した状態でスクラムイベントを進められるようになったと思っています。
── このワークショップは、スパイスファクトリーから提案したのですか？
小島：そうです。仕様書に書かれていたのは「4件の開発をこの時期までにやること」だけで、この期間の枠内ならば進め方はかなり自由でした。そこで最初に自分たちで内容を工夫してワークショップを実施したのですが、これが非常に効果的でしたね。
泰：私たち自身も業務の中で、有効だと考えた場合にはワークショップを活用していますし、ハンズオンを行ったりしています。
逆に私は、実際に動物愛護センターの現場に行って業務の様子を拝見して、「ああ、こんなふうに紙のカルテで管理しているんだ」といった現状をリアルに目の当たりにしたことで、あるべき姿を定義しやすくなりました。
── 実際に開発が始まってからも、大きなトラブルが生じることはなかったのでしょうか。
小島：互いにリスペクトの気持ちを持ち、利用者の価値に向かって一緒に頑張るという当たり前のことを積み重ねた結果、総じてスムーズに進みました。
当初は、POの方が東京都という組織の中で即断できる立場として活動できるか不安もありましたが、現場に近いプロジェクトでは価値を突き詰めて即決し、どんどん前に進むことができました。「上司に言われたのでひっくり返します」といったことも、ほとんどありませんでしたね。
ただ、全職員が利用するような規模の大きなプロジェクト「EVA」（職員専用ポータルサイトの改修）では、やはり関係者が多岐にわたる分、調整に苦労する場面もありました。開発体制もスパイスファクトリー側で8名、都側POが2名と最大規模だったこともあり、ステークホルダーが多いプロジェクトならではの難しさに直面したのも事実です。
一方で、エンジニア1〜2名を含む計3〜4名の最小構成で進めたプロジェクト「T-MAP」（通学区域デジタルマップ化プロジェクト）などでは、驚くほど意思決定がスムーズでした。 こうした経験を通しても、アジャイルの良さを引き出すには、まずは影響範囲を絞った小回りの利く規模から着手することが重要なのだと再認識しました。
スクラムの基本を忠実に守り、「2週間ごとの成功体験」を積み上げる
── もう一つの工夫と言えるのが、POA（プロダクトオーナーアドバイザー）という独自の役割を設けたことですね。
泰：POはスクラムにおいて、チームの方向性や優先度を決め、成功の鍵を握ります。しかし、関係者から情報を吸い上げきれない、意思決定できないといった事態が発生すると、うまくいかない要因になります。そういった事態を防ぐため、スパイスファクトリーからPOAを1名配置し、伴走支援を行いました。
小島：POAのアイデア自体は、システム開発に不慣れな職員を支援するため、東京都側から生まれたものです。
ただ、ここで私たちが工夫したのは、POAにプロジェクトマネージャー（PM）ではなく、ユーザー体験を設計するデザイナーをアサインしたことです。PMが担当するとどうしても「システムとしてどうあるべきか」が重視されがちですが、「利用者にとってどうあるべきか」を重視したのです。
特に東京都のPOの方々はシステム開発の経験がなかったため、PMやエンジニアの専門用語ではなく、UXデザイナーが「ユーザーの価値」という共通言語で対話することが最も重要だと考えました。
実際、現場でもPOとPOAが「どうすればより良い体験になるか」を一緒に話し合い、それをユーザーストーリーへと落とし込んでいきました。結果として、単なる機能の実装に留まらない、本質的なユーザー価値に寄り添った開発が実現できたと感じています。
── ほかに、スクラムを進める上でどんな工夫がありましたか？
泰：限られた期間で東京都の皆さんに成功体験を積んでいただくため、ユーザーストーリーを意図的に細かい粒度で切ることを意識しました。一つの大きなストーリーにずっと取り組み続けるよりも、細かくタスクを消化してベロシティが高まっていく様子を実感してもらう方が良いと考えたからです。それに、ストーリーが大きいと、途中で優先度や要望が変わった際にトレードオフがしづらくなるという理由もありました。
ノーコードの「AppSheet」も活用し、とにかく成果物へのリードタイムを短くして成功体験につなげることにもこだわりました。
小島：エンジニアが、スプリントに収まるよう適切にユーザーストーリーを切り出し、素早くデリバリーし続けたこと。それが、東京都の方に「2週間ごとに確実な成果物が出てくる」という、ウォーターフォールにはないスクラムの醍醐味を実感していただく結果につながったのだと思います。
── いろいろと独自の工夫を凝らして進めていったんですね。
小島：ただ、スクラムガイドの記述に従って、イベントをきちんとやっていくことがやはり大原則です。
スクラムでは毎日デイリースクラムを実施しますが、今回は、必ずしも出席する必要のないPOの方がポジティブに毎日出席してくださいました。これによって、私たちがどんなことをしていて、どんなことに悩んでいるのかを東京都側も分かってくれて、さらに協力的になっていった部分があったと思います。
泰：スクラムは、これまでに世の中で最も多くの現場で実践され、磨き上げられてきた方式です。だからこそ、そのフレームワークをわざわざ崩すべきではないと思っています。
例えば、何か失敗したからといって再発防止のために「チェックのルールを追加しよう」と、管理のための独自ルールをどんどん追加すれば柔軟性が失われ、がんじがらめになってしまいます。基本に忠実であることが非常に大切です。
その方が成功体験を積みやすく、汎用的で横展開もしやすいですし、他のプロジェクトにも学びを適用しやすくなります。
もちろん、今回の私たちの取り組みにおけるPOAのように、スクラムをより良くするための周辺要素（フレームワークにインプットされるリソースなど）については、現場に合わせて工夫して足していくのは大いにありだと思います。ただ、根幹となるスクラムのルールにはあまり手を加えず、組織を縛るような仕組みを増やすべきではないと考えています。
前例のない取り組みに再現性を持たせる「プレイブック」の価値
小島：もう一つ、私たちがこのプロジェクトで本当に価値があると考えているのが、「東京都アジャイル型開発に係るプレイブック」（以下、プレイブック）を制作して残したことです。
4つの実証実験プロジェクトを完結させるのはもちろんですが、ワークショップや成功体験の積み重ねを通じ、私たちがまさに「革新の触媒」となって、組織変革の面でも少しはお手伝いできたと思っています。
単に「4つのプロジェクトをスクラムでやりました、やって良かったね」で終わっていたら、おそらく、巨大組織の中に本当の意味で有益なものを残せないまま終わったと思うんです。
けれどプレイブックというアウトプットを出すことで、東京都という組織の中に再現性を持たせることができ、循環を組み立てることができる。公共入札には、毎年事業者が変わっていくという宿命がありますが、プレイブックを残すことで、次の事業者にもやり方が引き継がれていきますし、ステークホルダーである都民に対し、「こういう方法で変革を進めている」証跡にもなります。
それに、行政の皆さんの素晴らしいところは、成功したノウハウを自分たちの中だけに閉じ込めず、ほかの自治体ともどんどん共有して社会全体をより良くしていこうとする姿勢があることです。
泰：実はその姿勢は、私たちIT業界の技術コミュニティや勉強会のように、「得られた知見はオープンに共有して、みんなで一緒に成長していこう」という文化と同じなんですよね。
世界中のエンジニアが失敗や成功の知見をオープンにして技術を進歩させてきたように、行政の皆さんもノウハウを共有して横展開しようとしている。そこのマインドが完全に共鳴したからこそ、私たちもプレイブックという形で、全力でナレッジを残したいと思えたのです。
単発の成功で終わらせず、誰でも再現できる「型」として次につないだこと自体が、今回の挑戦の大きな成果の一つだと思っています。
── あらためてプレイブックを見ると親しみやすく、面白い内容になっています。
小島：「プレイブック」と聞いて最初に東京都の方が想像したのは、おそらく、文字をベースにした長大なドキュメントだったと思いますが、ロールプレイングゲーム調で親しみやすい内容にまとめました。これも私たちらしいアウトプットだったと思っています。
プレイブックを作成する際には各POの皆さんにインタビューを行いましたが、皆さん異口同音に「システムを作るのって楽しい！」とおっしゃってくださり、それを聞いて本当にやって良かったと思いました。
── 行政機関特有の契約や入札といったあり方と、アジャイルの良さを両立させるためにも一工夫必要だったのではないでしょうか？
小島：通常、自治体の仕事は請負契約を結ぶことになりますが、今回は準委任契約を結びました。東京都にとっても初めての準委任契約だったと思います。慎重な判断が求められる組織文化の中で、よく実現したなと。
自治体のプロジェクトは年度単位で区切られ、翌年3月に請求を行うのが通例ですが、この案件では月次で精算を行いました。そして、何をもって証跡とするのかについても前例がないので、私たちが使っている作業時間の計測ツールを用いて報告書を作成するフォーマットを作り、都庁内で処理を進めてもらえるよう調整を図っていただいたりしました。
また、ベロシティを把握できる資料を作成し、担当の方々が上長に報告しやすくする、といった取り組みも行いました。4つのプロジェクトとは別に定例会を設けて、自治体ならではのさまざまな壁をどう乗り越えるかについて、担当者の方と一緒に話し合っていきましたね。
泰：そうした契約や管理面だけでなく、技術や開発環境の面でも行政ならではの壁がありました。自治体では利用できるアプリケーションに厳しいセキュリティ制約が生じることもあります。最終的には関係各所と調整してクリアできましたが、どういったツールをどのようなライセンスで導入できるのかといった、技術やツール選定のやりくりも大変でしたね。
「東京都がやってるなら、自分たちも……」勇気を持てるモデルケースを作れた
── 東京都のプロジェクトを振り返って、ほかの自治体や、これからアジャイル開発を導入しようとしている組織が成功するためのポイントは何だとお考えですか。
小島：私は「東京都がやってるんだったら、自分たちもできるんじゃないか」と、ほかの自治体や企業も勇気を持てるようなモデルケースを作れたことに大きな意味があると思いますし、誇りに思っています。
もちろんアジャイルで、かつ準委任契約で進めるというのは受託側からすると不安もあるかもしれませんが、ポジティブに取り組むことが非常に大事だと思います。それから、繰り返しになりますが、スクラムの基本に忠実に進めることですね。
泰： 私はやっぱり「小さく成功を積み重ねること」に尽きるかなと思います。動物愛護センターのシステムでは、ストーリーを細かく切り、またAppSheetを用いて素早くデリバリーすることで前進している実感を成功体験として感じてもらうことができました。
行政のシステムに限った話ではありませんが、アジャイルを導入しようとして失敗するパターンは、いきなり、何か大きくて難しいことに取り組むことです。その前段階として、メンバーが失敗も含めて小さい体験を重ね、学びや自信を得ていくことで、スクラムのマインドは養われていくと思っています。
取材・構成：高橋 睦美
編集・制作：はてな編集部
- 小島寛人
- スパイスファクトリー株式会社 執行役員 ／ インフォポート株式会社 代表取締役。ローカライゼーションベンダーでのディレクターを経て、2006年よりWeb制作会社にて多様なプロジェクトに従事。2022年よりスパイスファクトリーに参画し、東京都町田市や東京都デジタルサービス局との協業を通じ、自治体・行政領域へのアジャイル開発の実装に取り組んできた。2026年には物流DX推進を目的としたインフォポートの完全子会社化を主導し、同社代表取締役に就任。現在はDXエージェンシーと自社プロダクト保有の両輪で物流DXを推進している。
- 泰昌平
- スパイスファクトリー株式会社 共同創業者 / CTO室 Principal Engineer。SIerやWebベンチャーを経て、2016年にスパイスファクトリーを共同創業。現在はAIサービス「Spice AI Enablement」の責任者も兼任し、技術とアジャイルの両輪でDXを推進している。東京都デジタルサービス局との都庁アジャイルプロジェクトではスクラムマスターとして現場をリードした。
