第3回：SaaS化は本当に自治体を救うのか〜市場構造のリアルとガバクラの失敗を繰り返さないために〜

※ππの話はでません！

前回からかなり間が空いてしまいました。
忙しさに忙殺（←）されておりなかなか重い腰が上がりませんでしたが、頑張ってみます。

前回までは、ランニングコスト高騰とSaaS化が難しい理由について書いてみました。（未読の方はぜひこちらも読んでみてください！）

そもそもガバクラは自治体を救うはずだったのですが、蓋を開けてみるとコスト高騰の主犯になっている現状。そしてその解決への銀の弾として、最近目にするようになった「公共SaaS」。

私はこの銀の弾には正直かなり懐疑的です。
結論、選択肢として提供されるのであればよいですが公共SaaS自体が目的化してしまうと本末転倒というか、ガバクラの二の舞三の舞になりかねないと感じてます。

引用している特集だけでなくガバクラもそうでしたが、立案者側の主観的なメリットのみが述べられているだけで、市場に対する解像度の低さが目立ちます。結局のところガバクラは失敗とっていい結果になりつつあるので、国側のいうことばかりを鵜呑みにしてはいけない、という気持ちになっている方も多いのではないでしょうか。
メリットを示すならそのエビデンスが欲しいのですが正直根拠に乏しい情報ばかりだと感じています。

もちろん自治体や今後の日本にとって良い方向に向かう施策なら全面的に支持するのですが、どうも私はそのように思えません。
そこでガバクラの課題・反省点を整理した上で、フラットに見てみたいと思います。

私は地方で運用の最前線で戦う地場の運用SE。現場ど真ん中の私の目から見たリアルな現状とSaaS論に対する課題感を独断と偏見で整理していきます。
※異論は認めます、そういう点はぜひご指摘いただければ・・・。

【お断りとお願い】
立場上ポジショントークに見える部分もあると思いますが、今回の記事は最大限フラットに書く努力をしています。批判一辺倒な内容には決してしませんので、ぜひ多くの方に届いたらいいなと思います。

ガバメントクラウドの反省点

正直にいうと、私はガバメントクラウドは失敗したと思っています。まだ稼働前の自治体も多い中ですが、コスト増の主犯格になっているのは間違いありません。

技術的な課題や地方自治体との相性については松屋JKがとても詳しくまとめられているのでそちらも併せてご覧いただければ。
松屋JKのNoteはこちら

私は現場にデリバリを行う地場運用ベンダの身なので、その観点から少し話をしていきます。どのあたりが失敗したのかというと、目指すべき姿はよかったのですがとそれに向かう実現方法とマネジメントが良くなかったと感じています。
具体的には「企画立案側の既存市場に対する理解が浅いまま理想論ばかりで進めてしまったこと」「立ち止まりピポッドするタイミングはいくつかあったが、ことごとく無視して強権的に進めてしまったこと」あたりでしょうか。これらにより現在の悲惨な現状になってしまっていると感じます。

識者たちは数年前からガバクラの課題を指摘していました。例えば、クラウド最適化・ランニングコスト・支払いスキーム・経済安全保障/ソブリン・事業者へのインセンティブ設計・現行法との矛盾点などです。
当時のデジタル庁はクラウドそのものをコスト削減の銀の弾と位置付けて、乗合バスを例にクラウドがいかに優れているのかを力説されていました。

描いた餅の通りに事業計画を進めていけることなんてそうそう無く、現場からのフィードを受けて適切な場面でピポッドを行うのが経営だと思うのですが、ことガバクラに関してはここのガバナンスが全く機能していなかったように思えます。
この点だけで長々とした記事が書けそうですが、政治とのバランスや組織体制に起因する問題でもあると認識しており、外野が騒いだところでどうしようもない部分でもあるので、今回のスコープからは外します。

今回は主に「企画立案側の既存市場に対する理解が浅いまま理想論ばかりで進めてしまったこと」この点について掘り下げてみます。

市場構造のリアル

ガバクラの失敗はクラウド選定の問題ではありません。SaaSが進まないのは地場ベンダのせいでもありません。
問題は、市場構造と自治体業務の前提条件が無視されていることだと感じています。

自治体基幹系システムのデリバリ

この界隈の方なら常識かもしれませんが、自治体の基幹系システムはどうやって導入されているのでしょうか。
私はたまに原課さんから「このシステムはMeteorさんがつくってるんですか？」と聞かれることがあります。
そんなわけはなく、大規模都市を除くだいたいの自治体には、開発元が作ったパッケージシステムを導入ベンダがおもりしているんですが、この観点がとても重要だと最近改めて感じています。

自動車に例えるなら、車を開発して製造するのはトヨタ、私の仕事はディーラーです。

顧客の要望に合わせてディーラーオプションという名のカスタマイズをしたり、点検したりリコール対応（制度改正）したりしています。
これは効率的にデリバリ〜運用保守するために必要な仕組みだと思っていて、フランチャイズなんかもその一種かと思っています。
要は、製造側からすれば直販ではスケールに限界がくるし効率も悪い、運用側からすれば製造コストがない分限られたリソースの中で販売や保守・サポートに注力できるということです。

もちろん直販で運用保守までしているベンダさんもいらっしゃいますし、弊社も（20業務ではないですが）とある業務システムは全国的に直販展開しているパッケージも抱えてたりしますが、一定のスケールと効率化を目指すならそういう話もあるよねーということです。

システム導入の盲点：誰がどこにシステムを構築するのか

車の場合は製造を集約することで高効率で製造ができ、デリバリはディーラーに任せて終わり。なんとなくそのイメージで認識が合うと思いますが、システムの場合はそういうわけにはいきません。

システムの場合は、ソフトウェアという非物理的な電子データ群をサーバという物理基盤にインストールして初めて利用可能となります。
ソフトウェアは開発元が製造しますが、各自治体で利用可能にする（＝サーバへインストール・セットアップ、初期設定、移行など）のはデリバリ側の仕事です。

このデリバリ側の役回りがどうも軽視されているというか、正しく認識されていないんじゃないかなーと感じる場面が多々あります。(・ω・｀)
（これまでの国の動向を見ていると、場面によっては存在すら認知されていないように感じることすらありました）

この記事では、このようにデリバリやその後の運用保守を行う立場の者を運用ベンダと記載します。
また特に地方ではラストワンマイルとして自治体の窓口になるベンダがいたりします。彼らを地場ベンダと記載します。運用ベンダと地場ベンダはほぼイコールです。

そのため既存の市場構造のままでは、どれだけSaaSに振り切ったとしても集約効率は全国に津々浦々といらっしゃる地場ベンダの数で頭打ちになってしまいます。

これがかねがね申し上げている「パイが小さい」問題です🥧
最近でもSaaS化することでシステム数が減り連携調整などが容易になるといいう論調を見かけましたが全くそのようなことはありませんと断言できます。ぜひエビダンス🦐を示していただきたいところです。

「既存の市場構造のままでは」と書いたのは、真にSaaSのメリットを打ち出すには私含めた地場ベンダがシステム構築から撤退することを意味し、そのマクロ的な意味合いとミクロ的な影響の議論検証が現時点では不十分であると感じているため、このまま進めて良いのかという課題提起のためです。

では地場ベンダの仕事である「システム構築〜導入・デリバリ（イニシャル期）」と「運用保守（ランニング期）」で切り離して考えることができればこの議論は進みそうです。

しかしながら現時点ではそれは難しく、ガバクラを利用しても同様の構造になるものと考えています。決してこの市場構造は従来のオンプレや自治体クラウドの調達の名残りで成立しているという訳ではなく、もっと根深い課題があるように感じます。

地場ベンダの役割〜なぜガバクラになってもデリバリと運用を切り離すことは難しいのか〜

私は標準化以前より他社移行など何回も経験していますが、私の経験からそれぞれのフェーズで行っていることをざっと書いてみます。

イニシャル期
・システム構築
・システム移行
・システム操作研修
・課題管理とその対応
・業務要件整理〜要件定義
・運用設計、伴走支援

ランニング期
・システムに関する問い合わせ対応
・平時処理対応、月次や年次処理対応
・制度改正対応（改正点の説明、運用の変更点などの要件定義、システム改修）
・業務観点での助言
・自治体固有運用の伴走支援

単にシステム的なことを行っている技術者という訳ではなく、長年の運用経験に基づく業務知識含めたサービスを提供していることが分かっていただけますでしょうか。
イニシャル期からシステム構築や移行作業と並行して、業務の要件定義やシステムでどのように運用をしていくのかといったサポートを行なっています。

前回の記事で「業務SEは動かぬ原課」と書きましたが、まさにその観点で移行初期から業務にどっぷり入り浸りながら職員さんと伴走していきます。
システムを開発するにも構築するにもパラメタ設定するにも運用保守するにも、深い業務知識が必要になる。それが自治体基幹系システムの現場にいる方達の認識なのではないでしょうか。

そのような非常にニッチな分野のスペシャリストたちが運用ベンダや地場ベンダには多数在籍しておりシステムと運用が密接に関わっているため、彼らの存在を無視して一朝一夕に議論を進めることは、結果として自治体の業務継続に大きな損失をもたらすものと考えます。
よって、現状の市場構造を深く理解することがこの議論にはとても重要と感じています。

私の感覚では、長年そのように寄り添いながら運用支援を行ってきた運用SEは、もはやSEではなく業務コンサルやコンシェルジュといっても過言ではないと感じています。
システム運用だけではなく、業務のアウトソーシング含めたBPRという位置付けとして地場ベンダは関わっているという側面をどうか国側にもご理解いただきたいところです。

ドメイン知識がなにより重要な業界だが・・・

この記事を書き始めた2025年7月時点ではこのような理由で「運用SEのSE以外の役割」のウェイトが、自治体にとっても極めて重要である状況です。長年の業界に関わってきた実績と信頼があるからこそ、自治体もシステム以外のところでも頼っていただいているのだと思います。
なおこれはいずれAIチームなどが発達してくれば代替可能になるかも知れない分野と思っています。そうなった時には、もしかしたら地場ベンダの役割は大体可能なものになっているかも知れません。

しかしそれでSaaS化が進む訳でもコスト削減される訳でもないと考えています。
真に障壁となっているのは我々の存在のせいではなく、自治体側に課題があると感じているのです。

本質的な問題は自治体側にある

知り合いの自治体職員さん達から聞いたリアルな現状から考察すると、ベンダに頼らざるを得ないのは、結論「自治体側の課題」が原因となっているように感じます。

• 複雑怪奇なスパゲッティ制度

• 人事異動で定着しない業務ノウハウ

• 減らぬ仕事、増える（国の）仕事

• 自治体は国支所ではない

• 必要以上に変化を嫌う空気・文化

複雑な制度設計によるものです。自治体は国の下請けではありません。選挙にしろお米券にしろ給付金にしろ、まずは徹底したデリバリの仕組み化が必要なのではないでしょうか。人口減と生産年齢減の状態で持続可能な住民サービスを提供していくための座組みづくりがこれからの政治には求められているのだと思います。土台がガタガタの状態であらゆる事業をアドオンしてもうまくいくものもいかないですよね。
ガバクラや標準化が高いのは事業者がボッているから？そんなわけありません。自治体に非効率を強いている行政サービスの仕組み自体に原因があるのではないかと、この事業を通して強く感じるようになりました。

まとめ

標準化・ガバクラの文脈で「コスト増は事業者が原因」という報道に触れる機会も増えてきました。もしくは構造的な課題に触れつつも解像度が低く、本質的な課題解決につながらない主張も見受けられます。
私は学者でも政治家でも専門家でもないですが、この市場で生計を立てるいち現場の人間として、どうもそのような話の微妙なズレや解像度の低さが気になっています。

結局のところ正しい課題を認識しないまま次の政策・制度が作られて同じような轍を踏む未来しか見えず、正直この業界に疲れてしまったところもあるのも事実です。それでも界隈の仲間たちの発信を見て、私も何か発信していくことでどこかの誰かの一助になればとの思いで書いています。

ガバクラの問題については単にSaaSを使えば解決するような話ではなく、市場構造を正しく理解することもだし、そもそもなぜ現在の市場が形成されているのか、自治体側が抱える課題は何なのか、それはどうして起こるのか、など、あらゆる分野・レイヤの課題を丁寧に汲み取っていく必要があるのではと感じます。

後半失速気味になってしまいましたが、市場構造と取り巻く課題について少しでも伝われば幸いでございます。

私は今まさに標準化稼働の火中に晒されており、割と死にそうになってます。（笑）
メンタルも身体もほんとギリギリの状態ですが、同業の皆様や自治体の皆様の存在のおかげでなんとか前向きに生きれています。
引き続きどうぞよろしくです。

おっぱい。