400万人が利用する会社訪問アプリ

佐藤竜也

株式会社永産システム開発 / backendエンジニア

登録してプロフィールを閲覧

佐藤竜也

株式会社永産システム開発 / backendエンジニア

登録してプロフィールを閲覧

Webエンジニアとしてのスキルセットを磨く

閲覧頂きありがとうございます。佐藤竜也と申します。簡単ではありますが、自己紹介をさせていただきます。

この先やってみたいこと

未来

自己紹介の欄に記入した通り、私の目標は、あらゆる課題に柔軟な対応策を提示できる、引き出しの多いbackendエンジニアになることです。そのため、backendエンジニアとしてのスキルを更に磨きたいと望んでいます。

株式会社永産システム開発3年間

backendエンジニア現在

2021年11月 - 現在

Webアプリケーションの開発に従事。Ruby on Railsを用いながら、現在までに4つのプロジェクトに参画した。

大手転職支援サービス企業採用支援サービスの開発
# プロジェクト概要 ## 目的・背景某大手転職支援サービス企業の依頼により、既存のアプリケーションに対して機能の追加開発を行うというもの。既存アプリケーションは別会社により作成されたものであり、それを引き継いで追加機能開発を行った。 (現在私が作業中のプロジェクトです。) 既存機能として、このアプリケーションが提供する機能は主に以下である。 * 企業が採用候補者に対して適性検査を受験させる機能 * その受験結果を分析する機能 ## 規模感、チーム構成、担当した役割本プロジェクトはスケジュールに対して機能数が膨大なため、2社の開発チームが共同して実装を行った。分担は機能ごととしており、担当する機能に対してはfrontend、backendともに実装を行った。また、クライアント会社様で大枠の仕様は決めてくださったが、設計に落としこむ作業からは弊社側で対応した。私が担当した業務は主に以下である。 * 面接サポートツールの実装 * 社内アンケート機能の実装(現在作業中のため、適宜追記します。) * 弊社実装チームのPM ## 使用技術言語: Ruby、 JavaScript フレームワーク: Ruby on Rails、React.js DB: PostgreSQL インフラ: AWS # 開発・実装内容 ## 1. 複雑な条件分岐のクラス実装 ### 概要本アプリケーションでは、面接官が面接時に資料として活用する面接シート機能が存在する。この面接シートは、候補者の適性検査の結果をもとに、その候補者の適正を深ぼるような質問が自動で割り当てられる仕組みである。 ### 課題・問題点この質問の割り当ては、対象となる性格特性に応じ、複雑な条件分岐を実装することが必要である。また、定期的なメンテナンスにより、質問を割り当てるロジックの追加や改修に対応できる必要がある。 ### 打ち手・使用した技術上記課題を解決するためには、拡張性・メンテナンス性を高められるようなクラス設計が必要である。そこで、本機能のクラス設計は、GoFのデザインパターンにおけるStrategyパターンを採用した。 ### 成果当初、本機能の拡張性に関しては特に言及されていなかったが、クライアント様へのヒアリングをもとに定期的なメンテナンスによる追加・改修が想定されることがわかった。そこで、上記のように、Strategyパターンを使用したクラス設計を採用することにより、今後の想定される拡張に対し柔軟な構造に仕上げることができた。クライアント様からは、アプリケーションの長期運用まで想定した設計を提案・実装したことについて、好評をいただけた。 ## 2. 面接シート作成の非同期化 ### 概要上述の面接シート作成は、複数の受験者の面接シートを複数件一括でも作成できるという要件があった。 ### 課題・問題点面接シートに対して質問を割り当てる処理はそれなりの計算量があるため、一括作成時にレスポンスが遅く、ユーザビリティが低下することが考えられた。よって、面接シートの作成処理を非同期化することを提案させていただいた。また、非同期化に伴い、面接シート作成画面において、現在非同期で作成中の処理があるか否かをフィードバックする処理の実装も合わせて提案させていただいた。 ### 打ち手・使用した技術非同期処理でデータを作成するところまではsidekiq gemが標準的にサポートしているが、現在作成中の非同期処理が存在するか否かをユーザーごとにチェックして、フィードバックを返すことは標準的な実装ではない。そこで、sidekiq gemが内部で使用しているmoduleをいくつか流用し、特定のユーザーが面接シートに関する非同期処理のjobを持っているかチェックし、Ajaxでフィードバックする仕組みを自作した。この際、sidekiqが持つjobの状態や、どこまでのテストが書かれているか等、gemの深い読み込みを行い、アプリケーション側で自動テストする際に網羅的で漏れのない検証を行えるようにも工夫した。 ### 成果当初、面接シートの一括作成時におけるユーザビリティの低下は考慮されていなかった。しかし、ユーザビリティを向上させるために非同期化に対応、更に適切なフィードバックを返すことを提案し、実現できた。クライアント様からは、仕様には書かれていない部分にまで配慮した設計を提示できたことに好評をいただけた。 # 本プロジェクトを通して学んだこと * Railsのデザインパターンである、Serviceクラスを用いた、modelからのビジネスロジックの分離。 * sidekiq gemや非同期処理の深い理解 * RailsにおけるAjax通信 * capistrano gemを用いたデプロイ運用 * PMをやりながら実装を並行して進める際のリソース配分等
2023年4月
大手塾 eラーニングシステムの開発
# プロジェクト概要 ## 目的・背景某大手塾が提供する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レスポンスの生成。 * デザインパターンを踏襲した再利用性・拡張性の高いクラス設
2022年6月 - 2023年3月
投資家向けファンダメンタル分析サポートツールの開発
# プロジェクト概要 ## 目的・背景本プロジェクトは投資家向けファンダメンタル分析のサポートツールの既存機能のアップデートを行うというもの。アプリケーション自体は別会社により作成されていたものを引き継ぎ、追加機能開発を行った。 ## 規模感、チーム構成、担当した役割このプロジェクトは必要な追加機能開発をスポットで行ったため、数名の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パターンを用いた柔軟性の高いクラス設計
2021年12月 - 2022年6月
webサイト分析ツールの開発
# プロジェクト概要 ## 目的・背景このプロジェクトはwebサイトの分析を行うためのアプリケーションを受託開発するというものである。実装する機能は、「ヒートマップ」、「離脱防止」、「チャットボット」、「ポップアップ配信」、「ABテスト」、「プッシュ通知」等である。このアプリケーションは弊社でスクラッチで開発したが、私が参画したのは後半である。 ## 規模感、チーム構成、担当した役割弊社のbackendエンジニアチームで、frontend, backend, インフラ等、サービス展開に必要な作業を包括的に対応した。私が担当した業務は、上記の「ヒートマップ」機能の実装である。 ## 使用技術言語: Ruby、 JavaScript フレームワーク: Ruby on Rails DB: MySQL インフラ: AWS # 開発・実装内容 ## 1. ヒートマップ機能の実装 ### 概要エンドユーザーが訪問したWebサイトにおいて、どのような動作を行ったかを可視化するための、ヒートマップの実装を行った。ヒートマップの種類としては以下の2つがある。 * クリックヒートマップ: ページのどの部分がどの程度クリックされたかを可視化する * アテンションヒートマップ: ページのどのスクロール領域をどの程度見ていたかを可視化する ### 打ち手・使用した技術ヒートマップの表示を行うために、javaScriptのcanvas APIを使用した。また、クリック・アテンションヒートマップの描画には、クリック座標や、閲覧秒数等の情報取得が必要である。これらの情報はjavaScriptのaddEventListenerを使用して、必要な情報を取得し、ページ遷移時にDBに保存することで実現した。 ### 成果ヒートマップ機能を実現できた。 ## 2. ヒートマップデータの運用 ### 概要と課題上述のヒートマップデータはその性質上、かなり膨大な量になることが予想された。それにより発生するDBの運用コストを低減する必要があった。また、取得速度の向上も考える必要があった。 ### 打ち手・使用した技術ヒートマップデータはその構造上、RDBで管理する必要はなかった。よって、NoSQLタイプのDBが使用可能であったため、コストやデータIOに優れたAWSのDynamoDBを採用した。 ### 成果 DynamoDBを使用することで、DBの運用コストを低減させ、また、データIOのパフォーマンス向上も実現できた。 # 本プロジェクトを通して学んだこと * javascriptを用いた画面情報の取得 * DynamoDBの実践をもとにした使用方法
2021年11月 - 2022年1月