第4回:自治体システム運用における「伴走支援」とは何か 〜運用SEは自治体業務の外部記憶装置である〜
前回までの記事では、標準化・ガバクラをめぐるコスト構造、そして自治体基幹系におけるSaaSの難しさと市場構造について、現場目線で整理してきました。
そんな中、読者の方から次のようなコメントを頂きました。
次回投稿される際には、ぜひ「システム運用における自治体への伴走支援」とはどのようなものか、お教えいただきたいと思います。デジ庁など標準化・ガバクラ推進の面々は、そんなもの自動化できると軽視しているように感じています。
私は伴走支援についてなど偉そうなことをとやかく言える立場でもないし経験も乏しいのですが、深く考えるせっかくの機会をいただいたと思い、筆を走らせてみようと思います。
ということで今回はこのコメントを起点に、私たち運用ベンダ(運用SE)が日々やっている「伴走支援」とは何か、そして今後どのような関わり方ができるのかを書いてみます。
※今回も「ポジショントークじゃねぇか!!」と思われそうな部分がありますが、私たちの等身大の話になってるのでそこのところ、ご了承くださいませ。。
結論から言うと、自治体システムにおける伴走支援は単なる操作説明や問い合わせ対応ではありません。
もっと根っこに近いところで、自治体の業務そのものを成立させるための役割を担っていると感じています。
0.伴走支援の定義
本記事では、伴走支援とは「我々運用SEが行なっている日常的な支援内容」とします。
DX文脈の伴走支援とは少しニュアンスが異なっていると思いますのでそこはあらかじめご了承ください。
また私は、単に運用SEの必要性を説きたいのではなく、そう成らざるを得ない構造的な問題点や、今の原課と運用SEの関係は果たして健全な姿なのかという点も含めて提起ができればと思っています。
それではご笑覧ください。
1. 自治体の最大の課題は「人が定着しないこと」
私の感覚として、自治体の課題を一言で言うならこれです。
とにかく人が定着しない。
ここで言う「定着しない」は、能力や意欲の話ではなく、構造の話です。
• 定期的な人事異動
• 政策・制度改正による業務変更
• その場しのぎの運用が積み上がる
• 現場は常に逼迫している(=教育に時間が割けない)
この結果、何が起きるか。
業務ノウハウが組織に蓄積されない。
特に中小規模の団体は当てはまるのではないでしょうか。
担当者が変わるたびに、一定の割合で業務理解がリセットされます。
これは私が運用SEとして長年感じていることで、そもそもの制度理解の話などが異動の時期には頻繁に問い合わせとして電話が来ます。
自治体も(特に窓口業務は)臨職さんをあてがっているケースも多く、そんな事情もあり、システムの操作だけでは無く、制度としてどう扱ったら良いのか、これはなぜ賦課されているのか、などの制度全般に関する問い合わせを受けるのが我々運用SEの日常です。
そして制度改正が追い打ちをかけます。昨年の正解が今年の正解ではなくケースが、特に近年では多いのではないでしょうか。
良い悪いの話では無く、規模が小さくなってもカバーすべき業務範囲は変わりませんので、課の定員が少ない町村レベルほど制度そのものをよく分かっていらっしゃらない担当者さんもいることは事実です。
組織として定着しないといけないノウハウが貯められず、結果としてSEに聞いたり属人化が進んだりする光景を見てきました。
その結果、最短距離で目の前を回す運用が増え、属人化し、次の異動でまた途切れるのです。
こうして自治体の業務は、構造的に「学びが継続しにくい」体質になります。
2. 運用SEは自治体業務の「外部記憶装置」になっている
では運用SEはどうでしょうか。
運用SEは、長年にわたり複数自治体の運用を担当する中で、
• 制度知見
• 業務知見
• システム仕様
• 実際に事故が起きた時の対処
といった知識を積み上げていきます。
一方で自治体側は、異動により知識が断続的になりやすい。
この構造が続くと、ある現象が起きます。
自治体業務の知識の一部が、自治体の外側に蓄積されていくのです。
言い方を変えると、運用SEはいつの間にか、自治体業務の「外部記憶装置」 のような役割を果たしているのです。
自治体側が「その処理ってどうでしたっけ?」と悩む時、運用SEは「去年も一昨年も同じケースがあった」「A市ではこう回している」と経験を持っていて、それを元に回答できます。
これは単に“詳しい”という話ではなく、自治体業務が構造的にそうならざるを得ない、という話です。
3. 「伴走支援」はヘルプデスクではない
では、伴走支援とは具体的に何をしているのか。
多くの人が想像する「運用支援」は、こういうイメージだと思います。
• 操作方法の説明
• マニュアル案内
• エラーが出た時の復旧支援
• 問い合わせ対応
もちろんこれも大事です。ですが、自治体システムの運用では、これだけでは足りません。
なぜなら自治体から来る問い合わせの多くは、実は「操作」ではないからです。
たとえば、私は介護保険システムのSEなので介護保険でいうとこんな問い合わせをしょっちゅう受けます。
・適用除外施設から他市の住所地特例施設へ転居する場合の保険者って適用除外施設があった自治体じゃないの?
・賦課権消滅時効の起算日って具体的にいつになるの?
・年度途中で資格取得した被保険者の給付額減額期間がシステム値と想定とで異なるんだけど。
これは操作の域を超えており
• 制度上どう扱うべきか
• 業務上どう回すのが適切か
• システム上どう入力・処理されるのか
というように、制度・業務・システムが同時に絡んでいます。
SaaSの世界観だと、基本的には「仕様に沿って使ってください」で終わります。
マニュアルも「入力方法」までは書けますが、「自治体業務としてどう回すべきか」までは書けません。
自治体運用の現場では、この“空白”が頻繁に発生します。
ここを埋めるのが、伴走支援です。
4. 現在の運用SEが主に担っていること
トラブルや例外が多いのでこのような支援が必要になっている。ひいては使いづらい(分かりづらい)システム(やサポート品質)のせいだ!!
という声も聞こえてきそうですが、果たして本当にそうでしょうか。
「例外が多いから伴走支援が必要」確かにその一面もあるとは思います。
でも本質は「自治体側の知識が継続しにくい構造」であると感じてます。
(そこも含めてBPOとして発注者も受注者も認識しているのであれば話は別ですが、ほとんどの場合は従前の運用契約の中で受注者側への要求が(恣意的かはさておき)増えざるを得ない構造になっていると考えるのが自然な流れです)
だから、例外を減らしても、システムを標準化しても、クラウドにしても、「運用の負荷」そのものは簡単には消えません。
なぜなら運用の負荷の多くは、システムの問題ではなく、
• 人の入れ替わり
• 制度改正
• 組織の余力不足
• 業務の断片化
といった、組織運営の問題から発生しているからです。
つまり、伴走支援は「例外処理係」ではなく、組織の継続性を補う役割にすでになっているなのだと思っています。
現状、運用SEが担っている伴走支援は、ざっくり言うと次のようなものです。
• 制度改正時の影響整理(どの帳票・処理が変わるかなど)
• 業務手順の確認(自治体内での流れ踏まえ、誰が何をするかなど)
• 入力・処理の判断支援(このケースはどの扱いかなど)
• 事故予防のための観点提供(過去に起きたトラブルの再発防止など)
• データ整合性の点検(帳票の数字が合わない、なぜか対象者が出ない、など)
これらは単なる「システムの運用」ではなく、システムを使って業務を成立させるための支援です。
ここが、一般的な運用(監視・復旧・問い合わせ)とは性質が異なる部分だと思います。
5. これからの伴走支援:運用SEは“真のDX”の橋渡し役になれる
ここから先は、私の考え(仮説)です。
これから自治体は、人口減少と職員減少によってより限られた人数でより多くの業務を回す必要が出てきます。
その時に必要になるのは、単に“便利なシステム”ではありません。
• 業務が回る組織設計
• 教育が回る仕組み
• ノウハウが消えない運用
• 政策変更に耐える体制
こういった、もっと土台の部分が重要になると考えます。
そして、ここに運用SEが関われる余地があると私は思っています。
なぜなら運用SEは、単一自治体の事情だけでなく、複数自治体の現場を見た上で、
• どこが詰まりやすいか
• どうすれば事故が減るか
• どうすれば教育コストが下がるか
• どうすれば属人化が減るか
という観点を持てるからです。
つまり運用SEは、目の前の問い合わせ対応だけでなく、
「自治体の限られた人数で多くの業務を効率的に遂行する組織づくりや教育」
「さらに職員が減る将来を見据えた能動的な組織改革」
においても、橋渡し役になれる可能性がある。
私はそう感じています。
この問題は、システムの標準化だけでは解決しません。
監視の自動化だけでも解決しません。
むしろ標準化が進むほど、表面上の評価のみで自治体側の余力が削られ、「運用を回す力」そのものが今後ますます重要になる可能性すらあると思います。
6. 「伴走支援は自動化できる」と軽視される危うさ
ですが現状はこの部分が軽視されていると感じています。
国の資料を見ていても標準化文脈では「標準化・ガバクラによって浮いた職員工数を住民サービスに充てられる」という説明が目立っている印象です。
伴走支援が軽視されるのは、そこにはある前提があるように感じます。
「システムが標準化されれば、運用も標準化できる」
「運用は自動化できる」
確かに、監視や定型作業の一部は自動化できます。
それは否定しません。
ただ、自治体システム運用の本質は、そこだけではありません。
自治体運用の難しさは、
制度・業務・組織の変化の中で “業務を成立させ続ける” ことにあります。
そしてここは、現時点では簡単に自動化できる領域ではない。
むしろ、人が減る時代にこそ、知識の継続性をどう担保するかが問われる。
その現実を無視したまま「自動化できる」と言ってしまうと、
結果として現場だけが疲弊していく。
私はその未来を繰り返したくありません。
ガバクラで起きたことを、SaaSでも同じ形で再現してはいけないと思っています。
7. おわりに:運用ベンダの役割は、これから変わる
ここまで書いてきたように、私の考えでは、伴走支援とは
自治体業務が継続して回るように、知識と運用を支えること
です。
そして運用SEは、実態としてすでに
自治体業務の外部記憶装置 のような役割を担っています。
この役割を、ただの「問い合わせ窓口」や「保守運用」として扱ってしまうのは、あまりにももったいない。
自治体の職員が減り、しかし業務が増え、制度が変わり続ける時代に、必要なのは派手なDXのスローガンではなく、
・地味だけど確実に業務が回る仕組み
・知識が消えない体制
・教育が破綻しない運用
そういった足腰だと思います。
運用ベンダは、そこに貢献できる。
そして貢献すべきだと思っています。
例えば
・運用SEの短期派遣制度(業務運用の要件定義を伴走型で実施する)
・運用ベンダの業務説明会を広域で実施する
などであれば割とすぐにできると思いますし、
・広域自治体間でのレンタル職員制度
などは今後の広域自治体に求められてくるのかも知れません。
2040年問題を解決するのは標準化だけでもガバクラだけでもDXだけでも限界があります。
もっと本質的な構造的問題を把握し、手を打っていく。そこに我々運用SEがお役に立てるのであれば今こそ、日本のために知恵を絞りたい。私はそう考えています。
追記(読者の方へ)
もしよければ、コメントで教えてください。
「伴走支援」と聞いた時に、皆さんがイメージするのはどの支援でしょうか。
現場の視点を集めていくこと自体が、たぶんこのテーマの一部だと思っています。
いいなと思ったら応援しよう!
最後までお読みいただきありがとうございます!
よろしければ応援お願いします!