2021.08.16 Mon

「行政システムではレガシーからの脱却が進む」グラファーエンジニアが明かす現状 #Devsumi2021

行政領域での開発と聞くと、レガシーな印象を受けるのではないでしょうか?2021年7月30日に、ソフトウェア開発者のための日本最大級のカンファレンス「Developers Summit(デベロッパーズサミット)」が開催されました。グラファーでは「行政領域では今何が起きているのか?スタートアップのエンジニアから見たGovtech SaaSとは」と題して、メンバーの吾郷協と澤孝晃が登壇。行政領域の最新状況を語りました。今回は、行政領域で進むレガシーシステムからの脱却について、澤が担当したパートを公開します。

【今回取り上げる人:澤孝晃】滋賀県出身。2018年、京都大学にて通信最適化を研究。2020年、ヤフー株式会社に新卒入社。社内開発プラットフォームのためのコンソールを運用・開発する。2021年5月、グラファーにProduct Developer として入社。Graffer スマート申請の開発に従事する。

「行政システムではレガシーからの脱却が進む」グラファーエンジニアが明かす現状 #Devsumi2021

これまで行政領域システム開発は、オンプレミスで高額な保守費用がかかる場合が多かった

これまで行政システムの多くは、専用システムをベンダーに発注する方法で進められてきました。例えば、住民票の管理や発行などをするようなシステムです。

こうした専用システムは、自治体のニーズに応じて柔軟なカスタマイズができるメリットがあります。

しかしデメリットとしては、保守運用にかかるコストが高額だという点が挙げられます。保守運用にかかる費用を一つの自治体だけでまかなうためです。オンプレミスでシステムを所有する場合やSEが自治体に常駐する場合には、コストはさらに増加します。


行政領域のスタートアップであるグラファーでは、多くの新技術を採用

このように従来の行政システムは、レガシーであるがゆえの課題がありました。しかし、日本国内でもいくつかの行政スタートアップが立ち上がり、状況は変わりつつあります。その一例として行政領域のスタートアップであるグラファーの技術環境をご紹介します。

1. インフラ基盤 ——Amazon EKS、Terraformを活用した基盤

インフラ基盤に関して、従来型の行政システムでは、各自治体が専用のシステムを発注してオンプレミスで構築していました。

一方、グラファーではAmazon EKS(Elastic Kubernetes Service)上に分散システムを構築して弾力的に実行しています。Kubernetesとは分散システムを実行するためのフレームワークです。

Kubernetesを使用するメリットの一つは、自己修復です。自己修復のおかげで、自治体から「システムが壊れたので修理をお願いします」といった依頼を受けることはありません。処理が失敗したコンテナは自動的に再起動されるためです。

構成管理にはTerraformというツールを用いています。TerraformはIaC(Infrastructure as Code)ツールの一つです。IaCツールを使用することで、インフラの構成は、コードで宣言した通りの状態となります。手作業で手順書通りに実行する必要はなく、GitHubにあるTerraformのコードをapplyするだけで、簡単にインフラが構築できます。

2. リリース作業 ——GitHub ActionsやArgo CDを用いた非属人的なリリース

リリース作業に関して、従来型のレガシーシステムの多くは、リリース手順書に沿って行う必要がありました。手順書に明文化されていない細かい作業も存在しており、経験がある人しかリリースができない場合もありました。

一方、グラファーではリリース作業が簡単になるような仕組みを取り入れています。

一つ目の仕組みは、GitHub Actionsを用いたCI環境です。リリースに必要なコードのビルド、テスト、配信、デプロイ、e2eテストは全て自動化されており、実行順を意識する必要はありません。

二つ目の仕組みは、Argo CDというツールを用いたGitOpsの環境です。Argo CDは、Kubernetes向けに用いられる宣言型の継続的デリバリーツールです。GitHubにあるソースコードの状態通りにアプリケーションがデプロイされるため、Gihubのコードを読めばデプロイの状態が確認できます。

三つ目の仕組みは、Slackを用いたChatOpsの環境です。Slack上の特定のチャンネルでメッセージを送ることでプルリクエストが作成されるようにしています。タグとイメージ入れ替えのプルリクエストを作成後、承認が得られればマージするだけでデプロイが完了します。

4. 不具合の検知 ——DatadogやSentryを用いた監視

不具合の検知に関して、これまで自治体で使うシステムに異常があった場合には、常駐している運用SEに相談するか、直接ベンダーに問い合わせる必要がありました。

一方、グラファーでは異常を能動的に検知して解決にあたる仕組みを用意しています。

その仕組みの一つ目が、Datadogという監視ツールを用いたメトリクスの監視です。CPUやメモリなどのリソース監視をはじめ、マイクロサービスそれぞれのヘルスチェックによるサービス監視、ブラウザテストによる外形監視を行っています。

二つ目は、Sentryというエラートラッキングツールを用いた、アプリケーションの監視です。バックエンドに加えてフロントエンドのエラーも取得することで、実際にサービスを利用するユーザーのスマホ環境で発生したエラーに関しても検知して対応しています。

三つ目は、ポストモーテムの実施です。ポストモーテムとは、SRE(Site Reliability Engineering)の役割から生まれた、障害から学びを得てサービスを改善する取り組みです。行政領域のサービスは多くの市民に影響を与えるためこのような考え方が欠かせません。障害の詳細な報告に加えて、根本原因を突き止めることで再発を防止しています。

5. 技術スタック ——モダンな技術スタックを取り入れた開発

技術スタックに関して、これまで自治体のシステムではCOBOLなどの言語がよく用いられてきました。しかし古い技術スタックはメンテナンスコストが高くなりがちです。

一方、グラファーでは新しい技術を多く用いています。

一つ目は、React + TypeScriptを使ったフロントエンド開発です。コンポーネントの肥大化を防ぐためにAtomic Designの考え方に基づいて分割したり、classではなくReact Hookを使用することでシンプルに記述したりしています。

二つ目は、Gin + Goを使ったバックエンドの開発です。DDD(ドメイン駆動設計)思想を取り入れ、DIP(Dependency Inversion Principal)が適用されたレイヤードアーキテクチャを用いることで、技術的な関心事とドメインの関心事が分離されるようにしています。

あわせて、メタプログラミングの徹底を重視しています。10万種類の行政手続きをデジタル化するにはエンジニア以外のメンバーの力も借りる必要があります。そこでコンテンツやデータを入稿するだけで製品が拡張されるようにすることで、行政DXを進めやすい環境を構築しています。

従来型の行政システムとは異なる、効率を重視した開発体制

行政スタートアップであるグラファーでは、Lean、DevOpsの文化、フルサイクル開発者の考え方を重視した開発体制を組んでいます。その一部をご紹介します。

1. リリース速度 ——Lean、DevOpsの文化を重視

従来型のレガシー開発で機能を追加・変更する際には、リリースまでに数カ月から半年ほどかかるのが一般的です。そのため、開発した機能を実際に利用して、フィードバックを得て改善するといった検証サイクルを回すには、ある程度の時間を必要とします。

一方、グラファーでは、Lean、DevOpsの文化を大切にしています。毎月80回以上の頻度で製品のバージョンアップを実施。いち早く利用者に価値が届くようにすることで、より長い期間、利用者に価値を届けることを目指しています。「リリースの頻度が高いチームは低いチームに比べて、不具合からの復旧時間が1/170であり、変更の失敗率も1/5である」ことが実証されている(※)ことからも、リリース頻度が高いことにはメリットがあると言えます。

(※)出典:『LeanとDevOpsの科学

2. 開発体制 ——全ての領域を網羅したDeveloperと、特定分野のSpecialistが共存する「フルサイクル開発者」の考えを採用

従来型のレガシー開発の場合、エンジニアが開発担当と保守・運用担当に別れていることが多くありました。運用専門のSEがクライアント先に常駐してトラブル対応にあたるケースも見られます。

一方グラファーでは、フルサイクル開発者の考え方を取り入れています。フルサイクル開発者とは、Netflixが提唱する概念で、一人の開発者が開発から運用までの全ての工程を担うという考え方です。

Developerが設計、開発、テスト、デプロイ、運用、サポートを担う。対してSpecialistは、特定の分野の専門性を高め、各専門領域における再利用可能なツールを提供します。このような体制によって、開発と運用で役割が分断されることがなくなります。

出典:『Full Cycle Developers at Netflix — Operate What You Build

3. 将来を見据えた要件定義 ——BizDevと連携することで、顧客に価値ある機能を提供し続ける

グラファーでは、自治体にSaaS型のサービスを提供しています。そのため、一つの製品に対して多くの自治体からの機能要望が届きます。ここで特定の自治体に製品を導入してもらうことだけを考えて機能を追加していくと、製品内部に負の遺産ができてしまいます。

このような要件定義に対する課題の解決に寄与するのが、BizDev(ビズデブ=事業開発メンバー)の存在です。エンジニアはBizDevのメンバーと一緒に製品開発に取り組みます。BizDevは「製品の資産価値」にコミットする役割を担うメンバーです。短期的にメリットがある機能ではなく、長い目で見て顧客に価値のある機能を追加するために顧客と調整することで、製品の資産価値を高めることをミッションとしています。エンジニアとBizDevが同じ方向を向いて仕事をすることで、エンジニアはよりよい製品を作るために、開発に注力することができます。

4. セキュリティ ——最新セキュリティ基準であるISMAPへの対応

最後に、セキュリティのための管理プロセスです。行政向けのサービスというと、形骸化した管理プロセスが多いというイメージを持つ方もいらっしゃるのではないでしょうか。

グラファーで採用しているのが、ISMAP(イスマップ)というセキュリティ評価制度です(※)。ISMAPとは、2020年度に開始された、政府におけるクラウドサービスの評価制度で、既にGoogle、AWS、Microsoft、Oracleなどの世界トップレベルのSaaS企業が取得しています。ISMAPは、管理プロセスを企業自身が定めて運用していくものです。そのため、より能動的な対応が求められます。グラファーにおいても製品の強みとなるように、強いては行政のDXが問題なく円滑に進むように対応を進めています。(※)取得準備中

編集後記
グラファーが取り組む領域であるGovtech(ガブテック)。Govtechとは、行政が民間企業のテクノロジーを活用して、電子申請やデジタル化などを進める取り組みです。日本でも近年Govtechが急速に進み、システム・開発面においても、レガシーからの脱却が進んでいます。これからどんどん変化が進んでいく領域です。ぜひご興味があればお話しましょう。

(※文中の敬称略。撮影時のみマスクを外しています。役職等は取材時点の情報です。開発環境等は2021年7月時点の情報となるため、今後変更となる場合もあります。)


グラファーはあなたの参加を待っています。現在募集中の職種はこちらをご確認ください。