「クラウド化」という言葉は、公共システムの現場でも当たり前に使われるようになりました。それでも、実際の判断はそう単純ではありません。24時間365日止められないシステムと、止まっても回避策がある業務システムを、同じ基準で検討すると、途中で行き詰まります。消防庁がまとめた検討資料には、この行き詰まりを避けるための線引きが具体的に示されています¹。

1. クラウド化は全体の話にすると止まる

指令系・支援系と業務系は、そもそも別のシステム

消防で使われるシステムは、大きく二つに分かれます。119番を受けてから出動を判断するまでを担う「指令系」「支援系」と、日々の届出や台帳管理などを担う「業務系」です¹。呼び方は似ていても、支えている場面はまったく違います。

この違いを最初に押さえないまま「クラウド化を進めましょう」と一括りに検討を始めると、途中で引っかかる部分が出てきます。指令系の話をしているのか、業務系の話をしているのかが、議論の途中で入れ替わってしまうためです。

外から関わるエンジニアにとっても、この二分法は出発点になります。案件の説明を聞いたときに、対象がどちらの系統なのかを最初に確かめる習慣をつけておくと、後の設計判断が早くなります。

一括りに考えると、検討は途中で止まる

全体を一度に動かそうとする検討では、途中でどこかの部署が反対に回ります。理由を尋ねると、「止められないから」という一点に集約されます。止めてよいものと止められないものが、同じ議論の中に混ざっているためです。

消防庁の検討資料は、この混乱を避けるために、最初から系統を分けて議論を進めています¹。全体を一枚の絵として描くのではなく、まず二つの箱に仕分けてから、それぞれの箱ごとに判断を下す構成です。

この仕分けの発想は、消防に限った話ではありません。止めてはいけない部分と、止まっても回避できる部分を先に分けておくことが、クラウド化の検討をつまずかせない出発点になります。図1は、この二つの系統がそれぞれ何を担っているかを整理したものです。

消防に限らず、公共分野のシステム全般でも同じ構図が繰り返されます。利用者と直接向き合う窓口の機能と、内部の記録を管理する機能とでは、止まったときの影響がまったく違います。二分法を先に立てる姿勢は、他分野の案件でも応用が利きます。

図の作成：Remogu編集部。消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」をもとに、二つの系統が担う役割を整理したもので、統計データではありません

2. 線を引いた基準は「回避策があるか」

対象外になった系統と、移行できる系統

指令系・支援系については、明確な判断が示されています。大規模災害時を含む24時間365日の稼働が必要不可欠なため、クラウド活用の検討対象外です²。

理由も明記されています。停電や回線途絶による通信断等のリスクが少ない、オンプレミス環境で整備するのが適当だという考え方です³。クラウドが向かないという話ではありません。むしろ、止まったときの経路を絞った環境を選んだ判断です。

一方、業務系については逆の判断が示されました。利用できない場合に回避策(別手段にて暫定対応を行い、システム復旧後登録する等)が取れるため、クラウド環境に移行可能です⁴。

この一文は、線引きの基準そのものを言い当てています。業務系が指令系より軽い仕事だからクラウドに移せるのではありません。止まったときに別の手段で当面をしのげるという条件があるから移せる、という順序です。重要かどうかより、止まったときにどうなるかが先に問われています。

この基準は、資料に載っている二つの系統だけに当てはまるものではありません。案件の要件を洗い出す場面で「止まったら何が起きるか」を先に問う型として、そのまま持ち出せます。オンプレミスかクラウドかという選択そのものより、先にこの問いを立てられるかどうかが、検討の速さを左右します。

表1で見る、二つの判断の分かれ目

ここまでの内容を一枚の表に整理すると、判断の分かれ目がより明確になります。指令系・支援系と業務系は、どちらも消防にとって欠かせない仕組みですが、止まったときに取れる手段の有無によって、選ばれた環境が正反対になりました。表1では、系統ごとの判断とその理由を並べています。同じ「重要さ」を持つシステムでも、回避策の有無という一点が結論を分けていることを見比べてみてください。

系統	判断	理由
指令系・支援系	クラウド活用の検討対象外	停電や回線途絶による通信断等のリスクが少ない、オンプレミス環境で整備するのが適当
業務系	クラウド環境に移行可能	利用できない場合に回避策(別手段にて暫定対応を行い、システム復旧後登録する等)が取れる

自分が関わる案件がどちらの列に近いかを考えてみると、クラウド化の検討がどこで止まりやすいかが見えてきます。

要件を洗い出す段階でこの問いを意識しておくと、後の工程で「なぜこの部分だけオンプレミスなのか」を説明する場面でも、根拠を示しやすくなります。

3. 可用性で分けると設計が決まる

止められないシステムの設計は先に決まる

指令系・支援系に24時間365日の稼働が求められる背景には、大規模災害時にも通信が途切れてはならないという条件があります²。この条件が決まった時点で、選べる設計の幅はかなり狭くなります。

停電や回線途絶が起きても機能を止められない以上、外部の回線や電源への依存度を減らす方向に設計が寄っていきます³。オンプレミス環境が選ばれたのは、この依存を減らせる環境だったからです。

可用性の条件を先に決めてから設計に入るという順番は、公共分野に限りません。止められない機能があるなら、まずその機能の可用性の条件を言葉にしてから環境を選ぶ順番にすると、途中の迷いが減ります。

止まってよい前提のシステムは、別の設計で足ります

業務系のように、止まっても回避策で当面をしのげるシステムは、可用性の条件が緩やかになります⁴。この違いが、選べる設計の幅を大きく広げます。

回線が途切れても致命的にならない前提があるからこそ、クラウド環境という選択肢が現実的になります。可用性が高いシステムより設計の自由度が低いと考えるより、条件が異なるために選択肢の数が違う、という理解のほうが近いです。

図2は、可用性の条件によって設計の分かれ方が変わる様子を整理したものです。同じ「消防のシステム」という括りの中に、条件がまったく異なる二つの設計が並んでいることが見えてきます。

可用性の条件を最初に言葉にしておくと、設計の議論に入ってからの手戻りを防げます。「なぜこの環境を選んだのか」を後から説明する場面でも、条件に立ち返って答えられるようになります。

図の作成：Remogu編集部。消防庁の検討資料をもとに、可用性の条件と選ばれる環境の関係を整理したもので、統計データではありません

4. 標準化の動機は人の側にある

支える人数が減っていく前提

消防業務システムの標準化が進む理由は、機能面の課題だけではありません。今後、消防機関を支える人数と、システムを提供する事業者側で管理・運用に当たる人数の両方が、減っていくことが想定されています⁵。

この想定は、消防に限った話として読むより、公共分野のシステム全般に通じる前提として読むほうが実務に近いです。支える人数が減っていく前提のもとでは、これまでのやり方をそのまま続けることが難しくなります。

支える人数が減っていく想定は、システムの作り方そのものへの要求に変わります。人手をかけて個別に対応する前提を、そもそも見直す必要が出てくるためです。

表2で見る、標準化が向かう先

この想定が、どの立場に及ぶのかを整理すると分かりやすくなります。消防機関を支える人数と、システムを提供する事業者側で管理・運用に当たる人数の両方が、減っていくことが想定されています⁵。表2は、この二つの立場と、それぞれに求められる対応の方向を並べたものです。

立場	想定される変化	求められる対応
消防機関	支える人数が減っていく	短期間・少人数で対応できる仕組みへの標準化
システムを提供する事業者	管理・運用に当たる人数が減っていく	短期間・少人数で対応できる仕組みへの標準化

そのうえで示されているのが、短期間・少人数で対応可能となるよう業務やシステムを標準化するという方向です⁵。標準化は、システムを画一化して自由を失わせるための取り組みではありません。むしろ、支える人数が限られる状況でも、対応にかかる時間と人手を抑えられる形に組み替える取り組みです。

少人数で回せる仕組みへの組み替えは、外部の知見を一時的に借りる形で進む場面もあります。標準化の設計そのものに関わる案件も、内部の記録管理を担う個々の機能に関わる案件も、この想定を前提に組み立てられています。

5. 作り込みから「選ぶ」へ

個別にカスタマイズする1対1の関係

現在の消防業務システムは、各消防本部に対して個別にカスタマイズしたシステムを構築し提供する、1対1の関係で成り立っています⁷。本部ごとの事情に合わせて作り込む形です。

この作り込みには、相応の代価が伴います。カスタマイズ部分に大きなコストがかかります⁸。個別対応の丁寧さより、費用の重さのほうが目につきやすくなります。

外から関わるエンジニアが目にする「独自仕様」は、この1対1の関係から生まれていることがよくあります。仕様の背景を知らずに手を入れようとすると、なぜそう作られているのかが分からないまま作業することになります。

標準の中から選ぶという設計への転換

この状況に対して示されている方向は、標準業務・機能の中から選択することで、カスタマイズを減らしてコストを下げるというものです⁹。作り込む発想より、選ぶ発想への転換です。

選ぶ発想を後押しする仕組みも合わせて示されています。標準仕様を普及させるため、クラウド上に構築されたシステムを共同利用するSaaS型消防業務システムが推進されます⁶。1対1の関係から、1つの標準を複数の本部で共有する関係への移行です。

図3は、この関係の変化を整理したものです。外から入るエンジニアの役割も、この変化に沿って動きます。ゼロから作り込む仕事より、標準の中から選び、整っていない部分を見極める仕事の比重が増えていきます。

作り込む仕事が消えるわけではありません。標準の機能で満たせない部分をどう扱うかという判断は、これまで以上に重視されます。ゼロから作るか、標準に合わせるかを見極める視点が、これからの設計の中心になります。

図の作成：Remogu編集部。消防庁の検討資料をもとに、システム提供の関係の変化を整理したもので、統計データではありません

6. まとめ

ここまで見てきた線引きは、一つの問いに集約できます。指令系・支援系は、止まったときの回避策がないために検討対象外となりました²。業務系は、回避策が取れるため、クラウド環境へ移行できます⁴。

この問いは、消防に限らず、公共分野やインフラ分野のシステム全般に応用できます。重要かどうかではなく、止まったときにどうなるかを先に問う。この順番を持っているかどうかが、クラウド化の検討が途中で止まるかどうかの分かれ目になります。

標準化の背景にある、支える人数が減っていく想定も⁵、1対1の作り込みから標準を選ぶ設計への転換も、根っこは同じです。限られた人数と時間の中で、判断の基準をあらかじめ言葉にしておくことが、後の作業量を左右します。

公共分野やインフラ分野のシステムに関わる案件では、こうした線引きの説明を求められる場面がたびたびあります。なぜこの部分は動かせて、なぜあの部分は動かせないのか。その説明を、重要さではなく回避策の有無で組み立てられるかどうかが、外から関わるエンジニアの評価につながります。

これまでとこれからを、一つの表で見る

二つの系統の線引きと、標準化の方向を一つの表に重ねると、外から関わるエンジニアの仕事がどこに向かっているかが見えてきます。作り込む仕事から、標準の中から選び、整っていない部分を見極める仕事へ。表3は、この変化を三つの観点で整理したものです。

観点	これまで	これから
システムの提供の形	消防本部ごとに個別カスタマイズする1対1の関係	標準を複数の消防本部で共有するSaaS型
コストのかかり方	カスタマイズ部分に大きなコストがかかる	標準業務・機能の中から選ぶことでコストを抑える
エンジニアの関わり方	ゼロから作り込む仕事が中心	標準の中から選び、整っていない部分を見極める仕事が増える

この記事は、クラウド化を急ぐという話をしているわけではありません。むしろ、線引きの基準を先に言葉にしておくことの大切さの話です。公共系・インフラ系のシステム刷新に関わる案件は、こうした線引きの設計や、標準化への移行を担う場面が中心になります。Remoguで扱う案件は90%以上がフルリモート可能です¹⁰。場所を選ばずに、この種の設計判断に関わる働き方を選べます。

積み上げてきた経験が、止められない部分と回避策がある部分を仕分ける仕事にどう活きるか。それを確かめる一歩は、まず案件の条件を見比べてみることから始まります。

7. よくある質問

業務系がクラウド環境に移行できるのは、重要度が低いからですか

いいえ、重要度の話ではありません。線引きの基準は、止まったときに回避策(別手段による暫定対応)が取れるかどうかです⁴。業務系の仕事にも重要なものはありますが、止まっても回避できる設計になっている点が、指令系・支援系との違いです。

自分が関わる案件でも同じ問いを立てられます。担当するシステムが止まったとき、代わりに使える手段があるかどうかを最初に確認すると、クラウド移行が現実的かどうかの見立てが早くなります。

消防指令システムがオンプレミス環境を選んだ理由は何ですか

大規模災害時を含む24時間365日の稼働が必要不可欠という条件が先にあります²。そのうえで、停電や回線途絶による通信断等のリスクが少ない環境として、オンプレミスが選ばれています³。

クラウドが向かないという結論ではなく、可用性の条件によって選ばれる環境が変わるという話です。

標準化が進むと、外から関わるエンジニアの仕事はどう変わりますか

個別にカスタマイズした1対1のシステムを一から作り込む仕事から⁷、標準業務・機能の中から選び、整っていない部分を見極める仕事へと比重が移っていきます⁹。

図4は、この判断を自分の案件に当てはめて考えるときの問いの流れを整理したものです。止められるか止められないか、回避策があるかないかを順に確認すると、設計の方向が見えてきます。

図の作成：Remogu編集部。本記事の線引きの考え方を、案件に当てはめる際の問いの流れとして整理したものです

このような案件は、フルリモートで進められますか

Remoguで扱う案件は90%以上がフルリモート可能です¹⁰。公共系・インフラ系のシステム刷新に関わる案件も、この条件の中に含まれます。

場所にとらわれず、標準化や可用性設計に関わる経験を活かしたいと考えているなら、まず案件の条件を見比べてみることから始められます。

標準化に関わる案件では、どんな経験が活きますか

個別にカスタマイズされたシステムの仕様を読み解いた経験や、複数の利用者が共有する仕組みを設計した経験は、標準業務・機能の中から選ぶ⁹という判断の場面でそのまま活きます。

可用性の条件によって環境を選び分けた経験があるなら、なおさら相性がよい領域です。積み上げてきた経験を、公共系・インフラ系の案件でどう活かせるかは、まず案件の条件を見てみることで具体的になります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊2 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊3 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊4 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊5 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊6 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊7 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊8 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊9 消防庁「消防業務システムの標準化・クラウド活用に関する検討状況」消防指令システムの高度化等に向けた検討会 資料13-5（2024年10月）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）