佐藤 竜也

# プロジェクト概要 ## 目的・背景 某大手塾が提供するeラーニングシステムの設計・実装を担当した。 このシステムは公立中学・高校をターゲットに、web学習、成績集計、AIによる個別最適化学習、課題配信など、生徒・教師の学習フローの最適化を目的としている。 特に、cmi5という米国国防省内の標準化機関が2016年に発表した規格に準拠しており、AI学習もサポートしている。 ## 規模感、チーム構成、担当した役割 本プロジェクトは複数の会社が参画し、弊社はbackendの実装を担当した。 また、backendと各サービス間の結合部分の詳細設計も弊社側で取り組んだ。 全体の統括や大枠の設計は別の会社が行っていた。 以下が本アプリケーションを構成するサービスである。 backendは主に、frontendのリクエストを起点に、LRSやAIと連携しながらデータの生成やレスポンス生成等を行っている。 * frontend * backend <- 弊社担当 * LRS(データストア) * AI ## 使用技術 言語: Ruby、 JavaScript フレームワーク: Ruby on Rails DB: MySQL インフラ: Docker、 AWS その他: OpenAPI Spec # 開発・実装内容 ## 1. frontend向けAPIの作成 ### 概要 本backendサービスは、別サーバーでホスティングされているfrontendサービスのリクエストに対するレスポンスを、WebAPIを通して行う必要があった。 ### 課題・問題点 開発している会社が異なることによるコミュニケーションコストや、仕様のすり合わせ等のオーバーヘッドが考えられた。 ### 打ち手・使用した技術 OpenAPI Specを使用した標準的な仕様書の導入を行い、多部隊感でのコミュニケーションや結合に関するコストの低減を行った。 ### 成果 OpenAPI Specを使用した事で、仕様書がコードベースになり、gitによる管理ができるようになった。 これにより、改修や結合等に関わるコミュニケーションコストを削減できた。 ## 2. AIサーバーとのデータ連携 ### 概要 backendとAIはそれぞれ個別にDBを持っており、同じデータを保持する必要があるという仕様であった。 また、backendからAI側へのデータ書き込みはWebAPIを使用して行う設計であった。 このデータ書き込みを行うAPIはAI側で用意されているものであり、各テーブルごとに個別のAPIが割り当てられていた。 これらのAPIは都度改修や、今後もAPIの追加等が考えられた。 ### 課題・問題点 上記仕様を守るために、backendとAIでデータ齟齬を発生させないようにする必要があった。 つまり、backend側にデータが作成されるのであれば、AI側にも同じデータを生成する必要があり、逆に、どちらかのデータ作成が失敗した場合には両方でデータ作成を行わない仕組みが必要であった。 また、メンテナンス性や、拡張性を考慮した設計を行う必要もあった。 ### 打ち手・使用した技術 上記のようなデータの整合性を保証するために一般的に使用される技術としてはトランザクションがあり、Railsはトランザクションを標準的にサポートしている。 しかし、Railsが標準的にサポートしているトランザクションは、Railsアプリケーション内で完結するデータ書き込みである。 そこで、modelコールバックを使用したトランザクションを設計することで対応した。 Rails側にデータ作成・更新を行い、コミットするまでの間にAI側へのデータ書き込みのリクエストを行い、AI側が何らかの理由により書き込みに失敗した際にはRails側でも明示的にエラーを挙げ、コミットをキャンセルすることでトランザクションを実現した。 また、メンテナンス性、拡張性を高めるために、AI側のAPIと疎通するためのクラスはGoFのデザインパターンにおける、Template Methodパターンを使用した設計を採用した。 さらに、backendでは1つのレコードであるが、AI側では複数のレコードに分割するような書き込みを行う際にはRubyのマルチスレッド機能を使用した実装にすることで、書き込み速度の向上も行った。 ### 成果 当初の設計では、backend・AI間におけるデータ齟齬由来のバグの発生まで考慮されていなかった。 私のこの設計・実装により、2つのサービス間で齟齬のないデータ保持が可能になり、安定的なアプリケーション運用を実現できた。 ## 3. 成績集計に関する定期実行バッチ処理 ### 概要 本アプリケーションでは成績を集計して表示・分析するための機能が存在する。 この機能では、集計対象のパラメータとして、生徒、教科、学習パターン、期間等が選択可能であった。 また、集計は各生徒の1問ごとに生成される解答データをもとに行う必要があった。 ### 課題・問題点 当初の設計ではエンドユーザーの成績集計リクエストのたびに、対象の集計を行いレスポンスする設計であった。 しかしエンドユーザーが任意の集計パラメータでリクエストした場合に、対象データ数が膨大なことにより、レスポンスが遅くなることが考えられた。 そこで、レスポンス速度を向上させること、また、コンピューターリソースの圧迫を抑えることを実現する工夫が必要であった。 ### 打ち手・使用した技術 上記問題を改善するために以下の技術を使用した。 * cronを使用した定期実行処理(夜間)の実装 * sidekiqを使用した非同期処理の実装 これらの技術を使用し、夜間の定期実行非同期バッチ処理により、各生徒の日毎の成績の集計を行い、成績集計リクエスト時の計算量を減らすためのデータを作成するように実装した。 また、成績集計リクエストはクラス単位で行われることが多いため、別途クラス単位での集計データも生成するようにした。 ### 成果 当初の設計に対し、私が上記で実装した内容により、成績集計の計算速度を向上させられた。 本アプリケーションでは、レスポンス速度の向上はプライオリティの高い非機能要件であったようで、統括会社様から、この工夫を評価いただけた。 # 本プロジェクトを通して学んだこと * 別サーバーで稼働するサービスとのWebAPIを使用したやり取り。OpenAPI specによる仕様書の共有。データ齟齬を発生させないためのトランザクション等。 * cronを使用した定期実行処理 * sidekiqを使用した非同期 * ドメイン駆動設計を採用した、modelからビジネスロジックを分離させる実装。 * WebAPIに於いて、ActiveModel::Serializerを用いたJSONレスポンスの生成。 * デザインパターンを踏襲した再利用性・拡張性の高いクラス設

# プロジェクト概要 ## 目的・背景 本プロジェクトは投資家向けファンダメンタル分析のサポートツールの既存機能のアップデートを行うというもの。 アプリケーション自体は別会社により作成されていたものを引き継ぎ、追加機能開発を行った。 ## 規模感、チーム構成、担当した役割 このプロジェクトは必要な追加機能開発をスポットで行ったため、数名のbackend実装者で小規模に開発を行った。 私が担当した業務は、TDnetが公開する適時開示情報を定期ポーリングし、XBRLファイルを取得し、複数ファイルから必要な指標値を取得・集計するという処理を実装することであった。 ※ XBRLファイル: 企業の業績データを作成・流通・利用できるように標準化されたXMLベースのファイル ## 使用技術 言語: Ruby、 JavaScript フレームワーク: Ruby on Rails DB: PostgreSQL インフラ: Docker、AWS その他: XBRL # 開発・実装内容 ## 1. 外部サービスに対する定期ポーリング ### 概要 本アプリケーションでは、企業の業績データを公開しているTDnetに対して定期的にポーリングをかけ、前回のポーリング時から差分があればXBRLファイルをダウンロードする処理を実装する必要があった。 ### 打ち手・使用した技術 これを実現するために以下の技術要素を使用した。 * cronを使用した定期実行 * faraday gemを使用したコードベースのHTTP通信 * sidekiqを使用した非同期処理 これらを組み合わせ、非同期でポーリングを行い、更新分のファイルをダウンロードするような実装を行った。 ### 成果 上記gemを複数組み合わせた構成により、コードベースの安定的なポーリングを実現できた。 ## 2. XBRLファイルからの指標値の抽出 ### 概要 上述のポーリングで取得したXBRLファイルは、様々な指標値が含まれている。 しかし、アプリケーションで実際に使用したい指標値は、その中の一部である。 よって、ファイル内の特定の指標値を抽出してアプリケーションのDBに永続化する必要があった。 ### 課題・問題点 XBRLファイルは「日本会計基準」、「米国会計基準」、「国際会計基準」の3種の会計基準が存在し、それぞれによって、ファイルの数や種類、内部構造が異なる。 また、これら会計基準は企業によって選択の自由があり、途中で変更されることもある。 それ故、3種の会計基準に対し、動的なロジック割り当てや、柔軟性の高いクラス設計にすることが求められる。 ### 打ち手・使用した技術 XBRLファイルから特定の指標値を抽出するために、nokogiri gemを用いたスクレイピングを導入した。 また、3種の会計基準に動的に対応するために、GoFのデザインパターンにおける、Strategyパターンを採用した。 ### 成果 約4000社のXBRLファイルを自動で解析し、必要な情報を抽出するフローを実装できた。 また、Strategyパターンを採用したクラス設計の導入により、今後の拡張性も高めた状態にできた。 # 本プロジェクトを通して学んだこと * cronを用いた定期実行処理 * sidekiq gemを用いた非同期処理 * faraday gemを用いたコードベースのHTTP通信 * nokogiri gemを用いたスクレイピング * Strategyパターンを用いた柔軟性の高いクラス設計