東京アプリを“ゼロ”から内製開発する時にチームで考えたこと
はじめに
こんにちは、GovTech東京で東京都公式アプリ(東京アプリ)のモバイルアプリ開発を担当している山内です。
今回は私達が開発している東京アプリのバックエンド技術とその選定背景について、アーキテクチャ設計の考え方や内製開発の意義について座談会を行いました。チーム立ち上げからの半年を振り返り、行政サービス開発の最前線で奮闘する生の声をお届けします。
東京アプリとは
東京アプリは都民一人ひとりがスマホ一つで行政とつながり、より便利になったという実感を都民に届けることを目指しています。
2025年2月にリリースされ、開発委託先と連携して順次機能を拡充しながら発展を続けています。東京アプリチームでは、現行アプリの開発・運用と並行して内製開発への移行も行っており、モダンな技術スタックの採用やアクセシビリティへの考慮などを追加して、自分たちで作るという取り組みを進めています。
座談会の参加メンバー
今回は以下の3名にお話をしてもらいました。

写真左から 山内、平井、三上、松尾
平井さん: サービスマネージャー(デジタル事業本部長)
通信事業者でネットワークエンジニアとしてのキャリアをスタート。事業者間のネットワーク相互接続やブロードバンド事業技術企画業務に従事。並行して2013年より日本最大級、約7500名のエンジニアコミュニティである日本ネットワーク・オペレーターズ・グループ(JANOG)の運営に参画し、2017年から2020年まで会長を務める。2019年12月に東京都のデジタルシフト推進担当課長としてTOKYO Data Highway戦略やスマート東京の実現に向けた各種DX事業を推進した後、2024年4月にGovTech東京に参画。現在は、東京アプリのサービスマネージャーとして従事。
三上さん: バックエンドエンジニア
バックエンドエンジニアとして入職。現在はプロダクトマネージャーを支援し、仕様策定に従事している。新卒でアクセス解析などのSaaSを提供する企業に入社し、約12年間在籍。CTOを経て、昨年GovTech東京へ初の転職。行政分野で社会課題の解決に挑むべく、公共サービスの価値向上に取り組んでいる。
松尾さん: インフラ/アーキテクト
アーキテクトとして技術選定や要件定義、全体のアーキテクチャ検討を担当。新卒でSIerに入社して人工衛星の組み込みソフトウェアやスーパーコンピュータ「京」の開発に携わった後に、パーソルキャリア、DeNA、AWSのソフトウェアエンジニアやソリューションアーキテクトを経験。偶然目にしたGovTech東京の宮坂理事長の記事が印象に残り、ソフトウェアによる社会貢献や行政分野に興味を持ちGovTech東京の門を叩いた。
内製開発における技術選定や設計思想、チーム開発体制の現状をサービスマネージャーである平井さんからの質問を交えながらお話してもらいました。行政システムの開発現場から見えてきた課題と解決策、そして行政ならではの要件と向き合う中で培われた知見を共有します。
なぜ東京アプリを内製開発するのか
現場で変わった開発のイメージ
── 行政システム開発と聞くと、どのようなイメージを持つだろうか。多くの人にとっては「ベンダーへの外部委託が前提」「制約の多い開発環境」といった印象であるかもしれない。松尾さんも、当初はそのような先入観を抱いていた一人である。
(松尾)正直、最初は委託前提というイメージでした。報道でも「ベンダーがシステム開発を担当」という話が多く、内製の現場は想像できていなかったです。
── しかし実際に入ってみると、その認識は大きく変わる。
(三上)そもそも前例がない状態だったので、レガシーなものに引きずられることなくモダンな技術を使える環境があるんです。もちろん、組織内の選定プロセスはありつつも、内製だと新しく入る人がモチベーションを持って働けるような技術選定ができる。それが醍醐味だと思います。
内製が生む開発速度とアーキテクチャの自由度
── また、内製化のメリットは「改善の継続性」という側面もある。
(松尾)一度作って終わりではなく、都民の声を聞きながら改良し続けられる体制が重要です。一般的な行政の開発で行われている外部委託の場合、契約開始時に決められた範囲内での実装や年度単位を基本とした契約など改善サイクルが限定されがちですが、内製なら柔軟かつ継続的な改善が可能になります。
(三上)最終的には都民のためになる選択をするという点で、内製化は合理的な選択肢だと思います。
── 内製化は単なる開発方法の選択ではなく、行政サービスのあり方そのものに関わる重要な判断だと考える。

内製開発の意義を語る三上さん
サービスを支える技術選定と開発プロセス
── 東京アプリの内製開発ではエンジニア自身がプロダクトに最適な技術を柔軟に選択できる環境がある。
(松尾)外部の依存や制限が少ない環境で、良いプロダクトを開発するために直結する技術を選べることが内製の大きなメリットです。具体的には、言語選定においてTypeScriptを基盤とし、シンプルかつモダンなHonoウェブフレームワークを採用しています。
また、クラウドサービスで全体アーキテクチャを設計し、モバイル通信プロトコルは低レイテンシと型整合に強い gRPC を、Webは広い接続性とツール群であるRESTと使い分けるなど、ユースケース最適化を図っています。

技術選定の難しさについて語る松尾さん
大規模アクセスを前提とした設計思想
── 東京アプリは都民約1,400万人という大規模なユーザーに対応しなければならない。
(松尾)アクセスがモバイルアプリからデータベースに到達する一連の流れの中で、処理が遅かったり、帯域が狭いところがあると、そこがボトルネックになって処理しきれない状況が生まれます。そういう部分を作らないようにするのが最優先です。
(三上)特に書き込みの処理はボトルネックになりやすいです。1,400万人という規模を考えると、読み込みだけじゃなくて書き込みもいっぱいあるだろうなと想像しました。そこでRDBMSではなく、書き込みの方でもしっかりスケールするNoSQL系やNewSQL系のデータベースを選びました。
── こうした技術選定は、技術的挑戦と公共サービスへの貢献という二つの価値を両立させる環境を整えるために合理的に判断している。
信頼性や安全性に直結する技術的判断
── 設計で特徴的なのは、開発チームがサービスのローンチ前から将来の拡張性を視野に入れて設計を行っている点である。サービス開発では「まず小さく始めて、需要に応じてスケールする」アプローチが一般的であるが、東京アプリでは異なる考え方が求められる。
(平井)行政は効率だけで割り切らない。必要な投資なら最初から規模を見据えて設計する。今は顕在化していないボトルネックでも、今後予見できるものならば、今から責任を持って前に進める必要があります。
── サービスの信頼性や安全性に直結する要素を初期段階から適切に設計するための難しさでもあり、エンジニアが挑戦できる部分でもある。
行政ならではの要件、「すべての都民」のための設計
ペルソナが無数という現実
(松尾)行政サービスのペルソナは無数にあります。民間サービスであれば特定の層だけを対象にするという選択肢がありますが、私たちはすべての人を対象にしてサービスを開発します。
(平井)民間サービスではコスト面からアクセシビリティ対応が後回しになることもありますが、行政サービスでは最優先事項の一つです。
── この「すべてをカバーする」という責任は、都民の多様性を考えれば非常に重要だ。デジタルデバイドへの配慮、アクセシビリティ対応など、民間サービスであれば将来的な課題として先送りできる要素も、行政サービスとしては初期段階から考慮する必要がある。

行政サービスでアクセシビリティは最優先事項と語る平井さん
組織特性を踏まえた「内製の難しさと面白さ」
専門知と現場力の融合
── システムの設計で特筆すべきなのは、この規模感への対応が単なる技術的挑戦ではなく、行政サービスとしての責任に根ざしている点だ。こうした独自の環境で効果的に開発を進めるため、チームは専門知と現場力の両方を重視している。
(松尾)明石信之氏、及川卓也氏、白石陽介氏など、エグゼクティブアドバイザーの方々との定例ディスカッションは非常に貴重です。どんな質問を投げても的確に答えてくれる専門性があり、プロフェッショナルだなと感じます。
── こうした専門家の知見を取り入れながらも、実装は現場主導で柔軟に進めている。
(三上)行政用語や行政サービスの抽象的な言葉を実際のコードや設計に落とし込む時、様々な工夫が必要です。アクセシビリティ対応一つとっても、単純なデザインの問題ではなく、バックエンドからフロントエンドまで一貫した配慮が求められます。
内製の強みを生かす組織文化
── チーム内では「役割に縛られない」文化も大切にしている。
(松尾)自分の役割だけに固執せず、落ちているボールを自分で拾いに行くようなマインドを持った人が集まっているのが強みです。
(三上)バックエンドエンジニア、フロントエンドエンジニア、デザイナーといった役割の垣根を超えて、プロダクト全体の価値を高めるために協働する文化が根付いています。これは内製チームだからこそ実現できる強みでもあります。
── このようにGovTech東京の東京アプリ開発チームは、行政ならではの強みと責務を両立させながら、独自の内製モデルを構築している。必要な投資を適切に行いながら、将来的に行政DXの一つのモデルケースを目指している。

組織文化について話す松尾さん
おわりに
社会実装に向けたユーザー体験
── 開発チームが描く将来像は技術だけでなく、全体的なユーザー体験にも及ぶ。
(松尾)全ての外国人旅行者が自動化ゲートで入国できるシンガポールのように、申請しているのかどうか自分でわからないくらいの透明感が理想です。
── これは単なる技術的な利便性向上だけではとどまりません。行政手続きが従来のように「申請する」という意識的行為を要するのではなく、必要な情報が適切なタイミングで提供され、ユーザーの負担を最小限に抑える体験を目指している。
持続可能な開発の実現に向けて
── こうした展望を実現するには、持続可能な開発体制の確立が不可欠だ。開発プロセスの自動化やAIの積極活用もその一環である。
(松尾)ゼロから大規模システムを作る機会はなかなかない。
(平井)GovTech東京だからこそ作れる東京アプリを目指したい。
── そして何より、この言葉には公共サービスの未来を切り拓く責任が表れている。
編集後記
今回の議論で内製開発の良さは速さだけではなく「継続して改善していけること」だと再確認し、都民にとって正しい選択を責任持って積み上げていくチームでありたいと実感した。
プロダクトの品質は組織文化から生まれると思うので、役割の壁を越えて助け合うこのチームなら、行政DXのモデルケースをプロダクトで見せられると思っている。
抽象的な行政サービスの要件を言葉にして設計で実装まで落とす。その積み重ねで、都民の体験を変えていきます。
東京都が設立した外郭団体「GovTech東京」のテックブログです。GovTech(ガブテック)は、Government×Technologyの融合させた言葉。このブログでは、行政DXへの技術的挑戦、現場で得た知見、そして組織のカルチャーを発信していきます。govtechtokyo.or.jp
Discussion