TY49937

# 概要 - 行政制度DBの管理システムのリプレイス - データ更新作業の効率化のための機能開発 # 担当 - 企画, 技術選定, 設計, 開発 - (当初CTO含めエンジニア3人ほどだったためこのシステムに関する全て個人で担当) # 課題 - 全自治体の行政制度の定期更新に人件費が多くかかっており、新機能による工数削減が求められていた。 - ダブルチェックはしていたがそれでも意図しない更新によりデータの不備が発生していた。 - フロントエンドにReact, Vueのようなフレームワーク等が使われておらず、UIを含む新機能では2000行程のコード量になることが多かった。 - ES5以前のJavascript, レガシーなライブラリ, 使われてない機能等々の要因で運用保守にも頻繁に工数がかかっていた。 - EC2を用いて常時起動でデプロイされていたため、利用頻度に対して料金が多くかかっていた。 # 取り組み 1. リプレイス - Typescript, React Hooks, MaterialUIの導入 - jsxやhooksによる記法で以前のDOM操作のコード量が約10分の1程度に削減 - MaterialUIでの実装により統一感のある要素やData Gridなどの複雑なUIをシンプルなコードで実装 - TypescriptやES2015以降の構文に統一し、型安全かつ可読性の高いコードを実現 - バックエンドAPIのサーバーレス化 - AWSのAPIGateway, Lambdaで行政制度DB(MongoDB)に接続するAPIを実装 - 管理システムと切り離し、別プロジェクトでも利用できるよう汎用的なAPIを構築(node.js, express) - テストコードの実行とデプロイを自動化( jest, mongo-jest, gitlabCI, AWS CDK) - フロントエンドのサーバーレス化 - AWS S3, CloudFrontを用いてをサーバーレスで実装 - SPAに対応するためCloudFrontの設定をカスタマイズしAWS CDKでインフラをコード化 - サーバーレス化するにあたり認証機能を持つマネージドサービスとしてFirebase Authenticationを利用 - (当時AWS CogniteではUIの変更や日本語対応が難しかったためFirebaseの認証を使用) 2. 追加機能の実装 (リプレイス前に実装した機能を含む) - 制度名などの重要な項目の変更は管理者権限に制限 - WebSocket通信によりリアルタイムで誰がどの制度を更新しているか表示 - (従来システムではSocket.ioで、新システムではAPIGatewayとDynamoDBを用いて実装) - 必須項目が空であるときなどにエラー出力するバリデーション機能 - 過去の制度情報と比較し非エンジニアでも見やすい更新時のdiffを表示 - 参照元自治体サイトをiframeにより同タブ内に表示 - 前回更新時の制度情報の参照元URLと現在のURLのHTML差分を元サイトのCSS等を適応することにより見やすく表示 - 複数のデータの一括更新 # 工夫した点 - React, Firebase, AWSのサーバーレスの構成などは社内でも初めての試みで他の手法も検討した上で良いと思ったものを導入した - WebSocketによる他ユーザーの編集中制度の表示がサーバレスに移行する上でのネックであったが、当時ExperimentalだったAPIGatewayのWebSocketの機能を先駆けて導入し、公式ドキュメントが不足するなか試行錯誤して実際に動くとこまで実装できた。 - 実際に一ヶ月ほど行政制度の更新作業に参加することで、利用者目線に立つことができ追加機能の提案に大きく役立った。 # 成果 - バリデーション機能によりシステムで最低限の品質が担保され重大なデータの不備はなくなった - 自治体サイトの差分表示機能により差分のみの確認で十分になり工数の削減が実現 - 過去データとのdiffを表示する機能により、元々制度データの更新内容を別途メモしていた工数が削減 - 業務未経験で入社したエンジニア2名に引き継ぎ、2週間ほどで運用保守、機能追加を問題なく対応できている - (従来のコード量の場合一ヶ月かけてもシステム全貌の把握は困難だった)

# 概要 - 各自治体でのコロナに関する支援制度を収集するクローラーの開発 # 担当 - 要件定義, 設計, 開発(全て個人で担当) # 課題 - 社内でコロナに関する支援制度を集めて事業化することとなったが、人力では全国の自治体の情報を網羅的に収集できなかった - また当時毎日のように自治体サイトには新しいコロナ関係の支援制度が増えており、定常的にサイトを調査する必要があった # 取り組み - まずは支援制度を探す工数をなくすためにクローラーで該当URLの一覧表を生成し制度収集チームに提供 - データの鮮度を担保するために定期的に新しく更新されたURLの一覧を生成し提供 - 全社員が好きな時に任意の自治体の情報収集が行えるようDiscord上にクローラーBotを作成 # 開発したシステム - Node.js, TypeScriptで自治体の公式ページからコロナに関する支援制度を探索するクローラー - コロナに関する支援情報のページかどうかURLやhtmlのデータに正規表現を用いて判定する機能 - S3に自治体サイト情報のデータを追加すれば自動でLambdaが起動するようAWS上でクローラーを実装 - 定期的にクローリングを実施しサイトページの更新日時部分を参照し最近の更新されたURL一覧を抽出 - 概要、カテゴリ、申請期間、申請方法等々できる範囲でhtmlデータから抽出しデータの作成補助 - 全社のDiscord上に自治体名を指定すると制度情報をクローリングしcsvファイルを返すbotの作成 # 工夫した点 - 複数の自治体のクローリングをローカルPCで実行するのが厳しくなってきたためlambdaで実装 - また無駄なアクセスを減らすため一度アクセスしたページのhtmlデータをS3上にキャッシングする処理を入れた - どのようなサイト構成でもクローリングできるよう正規表現を用いて汎用的なアルゴリズムを実装した - それでも全く収集できていない自治体サイトの調査と対策もおこなった(例covid→covitのサイト側のスペルミスなどに対応) # 成果 - 一月程度の短期間で全国の自治体公式サイトをもとにコロナ対策支援情報のDB作成に成功 - 収集したデータをもとに新型コロナ対策支援ナビの公開(https://wincovid19.jp/) - 上記のサイトをきっかけに東京都のコロナ支援情報ナビの案件を獲得(https://covid19.supportnavi.metro.tokyo.lg.jp/) - 本プロジェクトで開発したクローラーをカスタマイズし様々なデータを収集、納品し2000万円ほどの売り上げに貢献

# 概要 - Wordで管理しているのデータ集をMongoDBへ移行し自社のWebシステムで管理する - MongoDBへ移行したドキュメント群からPDFを一括で生成できるシステムの開発 # 担当 - 要件定義, 設計, 開発(全て個人で担当) # 課題 - 管理するWordデータが1000ファイルほどあり、更新やPDF生成を一ファイルづつ行っており、工数が多くかかっている。 - セル結合を含む複雑な表が含まれておりそのままテキスト情報にはできなかった # 取り組み - Wordで管理されていたデータはほとんどMongoDBへ移行していたが、表形式のデータを含むデータセットがDBでの管理ができずにいたため、まずはセル結合や幅寄せの情報を残しつつどうやってテキストとして保管するか検討した - どのライブラリもセル結合には対応できていなかったためMarkdownをベースに"^"と"<"の記号を使い記号の指す方向のセルと結合する記法を考案 - MongoDBの管理用Webシステムを立ち上げ、作業チームにWordデータの移行作業を依頼 - その間に考案した記法で書かれたMarkdownを含むドキュメントをPDFに変換するWebシステムを開発 # 開発したシステム - Wordファイル上のテキストデータを管理するためのMongoDBを構築 - 別プロジェクトで実装した制度DBの管理システムを流用しつつ本プロジェクト用に構築 - セル結合や文字の端寄せを含む表に対応できるMarkdownの拡張記法の考案 - 上記の拡張MarkdownをHTMLのtableタグに変換するプログラムの開発 - Word上でのデザインと同等になるようなHTMLとCSSのテンプレートファイルを作成 - MongoDBに移行したデータとテンプレートファイルからHTMLデータを生成 - HTMLデータをPDFファイルに変換しダウンロードするWebシステム (js-PDF, html2canvas, AWS S3, AWS CloudFront) # 工夫した点 - 基本インフラをAWS CDKで実装していたためこのプロジェクトへの流用が楽にできた - Markdownからhtmlへの変換部分はフルスクラッチでコードを実装した - js-PDFが日本語のhtmlからの直接の変換に対応しておらず、自分でA4に収まるようHTMLを生成しhtml2canvasでの画像化を経由することで対応した - ブラウザでPDFを生成できるようにしたのでシステムのサーバーレス化が実現し、また大量のPDFデータをサーバーとやり取りする必要も無くなった - ログイン機能やユーザー毎の権限付与も特に必要なかったため、CloudFront Functionという機能を用いてBasic認証をCDK内で簡単に実装できた # 成果 - 順延しかけていたPDF納品を間に合わせることができた - 今後のデータの管理工数が削減した - ブラウザでPDF生成する技術は別のプロダクトでも使われている (https://service.asukoe.co.jp/naviform/)