業務の課題をシステムのデザインで解決

現場で起きていたこと

災害発生時に利用するコミュニケーションツールの刷新の事例です。これまでのシステムはスクラッチで開発され、更新の際にも「同じものを作る」ことが常態化し、新たな価値や、業務そのものの見直しには目が届きにくくなっていました。

閉域網を前提に作成されたツールだったため、特定の拠点でしか利用できず、ツールは災害時にしか使わないものになっていました。いざ災害が起きても、平時の PC からデータを USB で移すなど、情報の断絶が生じていました。

SOA（Service-Oriented Architecture）の提案

私たちが提案したのは、SOA（サービス指向アーキテクチャ）の考え方です。難易度は高いですが、業務と SaaS への理解があればハマります。同じ画面を一から作り直すのではなく、業務に必要なサービスをつなぎ、組み合わせで動かします。

SOAを採用するメリット

スクラッチで抱え続けると陳腐化しやすく、部分改修もしづらい。防災分野では、そのデメリットがそのまま「世の中の技術進歩の恩恵を受けられず、置いてけぼりになる」ことにつながります。SOAであれば、サービス自体が進歩していく余地があり、いざとなれば別のサービスに乗り換えることもできます。

SOAを採用するメリットは他にもありました。これまでは信頼性を確保するため、防災系のシステム単体で重厚な設計を行っていました。SaaS の製品を導入することで、対応が防災系のシステムだけでなく、普段のシステムからも可能になったので、単体で可用性を担保する必要がなくなりました。具体的にいうと、普段のシステムでは Teams が採用され、防災系では Slack を採用するというように、異なる基盤で提供されているサービスを組み合わせてデザインすることで、両方が同時に故障する確率を下げ、システムとしての可用性を賢く担保することができるようになりました。

また、インフラに依存しない汎用端末でサービスにアクセスできるため、普段使いの PC と重複で配備していた防災用の PC が不要になり、使い慣れた自分の PC で災害対応を続けられるようになりました。