Business social network with 4M professionals

Akiyoshi Takazawa

株式会社SocialDog / Webエンジニア日本

23Connections 23Followers

Akiyoshi Takazawa

株式会社SocialDog / Webエンジニア

より良いプロダクト開発を。

Webアプリケーションエンジニアです。😸

Ambition

In the future

【5年後以降目指していること】ユーザー目線でプロダクトに関わり、共に成長することリードエンジニアとしてプロダクト開発をリード

株式会社SocialDog10 months

WebエンジニアPresent

Jan 2025 - Present

SocialDogの開発
プロダクト内容 https://social-dog.net/ja/
Jan 2025

アルサーガパートナーズ株式会社5 years

エンジニア(フロント/バックエンド)

Aug 2020 - Jan 2025

駐車場契約・解約申請システム
1. 概要マンション管理業務の1つとして、契約・解約などの駐車場関連の申請業務負荷が非常に高い。 DXによる業務の効率化・省力化を行うことで付加価値の高い業務に人的資源を集中させ、顧客視点に立ったサービス提供を促進するために本システムを開発することになった。主な機能・駐車場の契約・解約申請・外部認証システムとのログイン連携・車庫証明書の発行処理・外部請求システムとの定期連携 1-1. チーム構成 PM：1名バックエンド：7名フロントエンド：3名 QA：2名 1-2. 担当した役割開発リーダーとしてアサイン。要件定義・設計・実装・テスト・レビューを対応しつつ、タスク割り振りやドキュメント整理を行った。 1-3. 技術スタックフロントエンド：React, Typescript, Inertia.js バックエンド：PHP/Laravel, データベース：MySQL, Redis インフラ：AWS(ECS・Fargate・ECR・SQS・SNS・S3・ElastiCash・etc...) その他：Backlog, Github, Notion, Slack, GithubActions, 2. 開発中の課題・発揮したバリュー 2-1-1. 概要勤めている会社におけるアーキテクチャとしては、 Repositoryパターンがメインで導入されている。ただ、複数のプロジェクトに携わる中でいくつか課題を感じたため、本プロジェクトでは導入することに至った。 2-1-2. 課題 Repositoryパターンを下記のようにどのプロジェクトでも導入している。 Laravelを使っているため、参考としてはlaravelベース。あくまで例。 ``` interface AdminRepository { public function find(int $id); } class EloquentAdminRepository implements AdminRepository { public function find(int $id) { return Admin::find($id) } } ``` 利点としてはデータベースアクセスする際に使用するデータベースエンジンが変わったりした際でも変更しやすかったりするため、保守性が高いが、そもそもデータベースを変更する際には、ほとんどない。そのため、あまりつかうメリットが感じられなくなった。また、複数人で開発をしていると同じような役割を持つメソッドが増える傾向があり、保守性が悪くなると感じた。 2-1-3. 解決策 Repositoryパターンを使わず、Laravelであれば便利なORMのEloquentがあるため、 Eloquentをメインで使用する。 Builderパターンを用い、メソッドを拡張することで使用しやすくするようにした。また、特に恩恵を受けたのがユースケースに基づくActionクラスを作成することで、業務ドメインと同様の実装を行うことができた。そのため、改修する際に影響範囲がわかりやすくなり、開発スピードが高まった。参考にした記事 https://domain-driven-design-laravel.com/ 2-2. バウンスメール発生時のメール通知 2-2-1. 機能概要マンションに住んでいる方が申請を行った際にメール送信を申請者に対し行う。その際に、何かしらが影響でバウンスが発生した際に、管理者の方へバウンス発生した旨をメール送信する。 2-2-2. 課題今回のプロジェクトではAWS SES を用い、メール機能を実装している。メールバウンス発生したかはSESから取得することで判断できるが、管理者へメール通知する内容にはデータベースから情報を取得し、メール内容に記載する必要があったためどのようにSESとアプリを連携させ、バウンス処理を対応するかの知見が足りなかった。 2-2-3. 課題に対して自身が発揮したバリュー及び成果調査を行い、実現できる設計・検証を行った。結果として、 SESで発生したバウンスはSNSを通じてSQSへメッセージを送ることにした。サービス側から定期バッチにてSQSへポーリング処理を行い、メッセージがあれば管理者へメール送信するように開発を行った。なお、どの申請者のどのメールがバウンスかを判断するために、メールヘッダーに暗号化したIDを入れることで解決を図った。
Mar 2023
電気ガス補助金申請システム
1. 概要世界情勢を背景としたエネルギー価格の高騰による電気・都市ガス料金の上昇によって、家庭や企業等の負担増加が見込まれた。国が定める値引き単価により電気料金・都市ガス料金の値引きを行った電気・都市ガスの小売事業者等に対して、補助金を申請するためのWebサービス。負担緩和策として、各小売事業者等を通じて、電気・都市ガスの使用量に応じた料金の値引きを行い、急激な料金の上昇によって影響を受ける家庭・企業等を支援するためのシステム。主な機能・申請機能(ファイルアップロード・フォーム) ・CSVインポート 1-1. チーム構成 PM：1名バックエンド：6名フロントエンド：2名 QA：1名 1-2. 担当した役割開発リーダーとしてアサイン。タスク割り当てやレビューをメインで担当しつつ、実装も行った。 1-3. 技術スタックフロントエンド：Vue.js, Typescript バックエンド：PHP/Laravel データベース：MySQL, Redis インフラ：AWS(ECS・Fargate・ECR・S3・ElastiCash・etc...) その他：Backlog, github, Notion, Slack, CircleCI 2. 開発中の課題・発揮したバリュー 2-1. 課題同依頼主の別申請Webサービスの補助金申請において、銀行口座情報を毎週CSVでそれぞれのサービスごとに読み込み処理を行っていた。サービス数としては5つ。これは補助金振り込み先口座を指定する際の候補口座情報として使用する。また、銀行口座支店が閉店または新規開店するために随時更新する必要があった。読み込み処理するために、人員確保やメンテナンス時間を各サービスごとに取り入れることによって、人員コストや開発コストが高くなっていた。 2-2. 課題に対して自身が発揮したバリュー及び成果すべてのシステムで同じDB・APIを使用することで、更新処理にかかる人員コストを削減することを提案し、各システムへ導入まで対応することができた。銀行口座を取得するAPI かつ、UIからCSVインポートできるWebサーバを構築し、マイクロサービスのように活用するように行った。これにより5つのサービスごとに毎週月曜に更新作業を行わずに、 1つのサービスを更新するだけで対応することが可能となり人員コストを下げることができた。
Aug 2022 - Feb 2023
経営戦略ミーティング支援プラットフォーム開発
概要法人企業向けミーティング支援ツールの開発主な機能 20階層構造を作成できるTODO機能カレンダー機能(Google Calendar 連携機能付) 会議通知・タスク通知機能担当バックエンドエンジニアのメンバーとしてプロジェクトにアサイン。リーダーフロント兼任使用技術フロントエンド：Vue3, Typescript バックエンド：PHP/Laravel8, インフラ：MySQL5.7, Redis, AWS ECS・S3, Docker, Redis 開発中の課題・工夫した点 ◯20階層構造を作成できるTODO機能詳細企業課題を細分化し、より具体的なTODOを出していく機能の開発を行なった。各TODO には、進捗率が記載することができる。進捗率は、上の階層に対しても反映され、一番上の階層では配下のTODOを合計した割合を計算する。課題ドラッグ&ドロップにて階層移動ができるためアクセスが集中してしまうとDB処理が追いつかず、複数人が操作してしまうと、反映処理が遅くなっていた。工夫した点 DBをREAD /WRITE に分けることで、負荷分散を行いDBの負荷を下げる。 Queueを活用することで、非同期で処理するものと同期的に反映するものを分け、処理を行なった。 ◯カレンダー機能(Google Calendar 連携機能付) 詳細アプリ側で作成したカレンダー機能とGoogle Calendar との相互連携機能の開発を行なった。 Google 側で操作してもアプリ側へ反映。アプリ側で操作してもGoogleへ反映される。所属する企業全員をGoogle Calendar のようにサイドバーに表示を行い、チェックマークを行うことで、カレンダー表示を行う。加えて、1つのイベントに対してアジェンダという議事録が保存できる機能の開発を行なった。また、商用利用する場合、 Google に対してOAuth申請を動画撮影を行い許可を得る必要があり、その申請対応を行なった。課題アプリ側で作成したイベント情報をGoogle Calendar 側へ反映するにあたり、例えば、毎週水曜に行う定例といったようなデータを作成/更新/削除を行う場合の、 Google Calendar 側の仕様を細かく網羅する必要があった。作成したGoogle Calendar のユニークなIDに対して、アプリ側のアジェンダとの紐付けを行うが、ユニークなIDが繰り返しのイベントの更新処理などを行う場合IDが変更されてしまうことがあり、紐付けが外れてしまうことがわかった。そのため、Google Calendar 側の仕様を網羅し、いつどの処理を行うとIDが変更されてしまうのかを調査する必要があった。工夫した点調査に関しては、カレンダーで操作できるパターンケースを全てスプレッドシートにまとめ、 1つ1つ検証を行なった。その検証結果を元に、Google Calendar とアプリ側の連携の設計・実装や、アジェンダとの紐付けなどの設計を行なった。
Jun 2021 - Jul 2022
ネイティブポーカーアプリ開発
概要オンライン対戦ができるポーカーゲームアプリの開発担当バックエンドエンジニアのメンバーとしてプロジェクトに短期アサイン ios(appStore) ・android(google play) のサーバ処理課金機能を担当使用技術インフラ: AWS ECS, Docker サーバ：PHP/Laravel8, MySQL8.0, 開発中の課題・工夫した点アプリ課金機能の設計・実装詳細スマホゲームでよく見られる、ダイヤモンド(アプリ内通貨)を購入してもらい、さまざまなアイテムと交換できる機能。ダイヤモンドを購入するためのappStore ・google play における課金レシート処理の設計・実装を行なった。課題 appStore とgoogle playにおける課金処理方法が違うため、それぞれの違いを調査し、設計する必要があった。工夫した点調査するにあたり下記項目を主に考慮した。 appStore とgoogle play の課金されるフローの違い transaction をどこに適用することで、ユーザー損失を防げるかまた、アプリ内通貨を購入するプランにおいて、例えば、500個 + 20個みたいなケースで20個分がサービスとなるケースが出てくる。その場合のユーザーが保持するアプリ内通貨として、有償分(課金) と無償分(課金せず取得したもの)を分けることをクライアントに提案を行なった。上記の処理を明確に分けることで、例えば、サービス終了し、余った通貨をユーザーに返済する必要が出てくる場合があるが、有償分から通貨を使うよう優先順位をつけることで、そのリスクを減らすよう提案と設計・実装を行なった。
Nov 2021 - Feb 2022

株式会社Lbose1 year

業務委託(Side)

Nov 2022 - Dec 2023

Webエンジニア

AI分析カメラを活用したデータをBIツールで分析するまでを自動化プロジェクト
1. 概要某都心にて通行人種別(男性・女性・年齢)を分析をするためのカメラがあり、分析データはGoogle スプレッドシートへ出力される。 Google スプレッドシートの情報(1シート2000行・6~10シート/日)をデータウェアハウスであるBigQueryに流し込む。 Looker Studioを使用し、BigQueryに取り込んだデータを元にグラフを生成する。上記の自動化が必要となった。今までは、手作業で分析や読み込み処理を行っていた。 1-1. チーム構成 PM：1名エンジニア：1名 1-2. 担当した役割エンジニアとしてアサイン。(業務委託) 設計から実装・テストまでを行った。 1-3. 技術スタックプラットフォーム：Google Cloud Platform, Google Apps Script(Javascript) DWH: BigQuery BIツール： Looker Studio 2. 開発中の課題・発揮したバリュー 2-1. 課題普段ではWebサービスをメインで設計することが多かったため、 BigQueryやGoogle Apps Script(以下GAS), Looker Studioを今まで使用したことがないため知見がなかった。 2-2. 課題に対して自身が発揮したバリュー及び成果設計段階で、それぞれのサービス連携方法の調査を行った。とにかく検証し、サービスに慣れることを最優先とした。最終的に下記方法で対応することができた。 GASで該当Google Driveにあるシートを読み込みテーブル設計を行ったBigQueryに流し込む Looker Studio でグラフ生成
Nov 2022 - Dec 2022

Cloud Position5 months

エンジニア(フロント/バックエンド)(Side)

Mar 2022 - Jul 2022

フロント / サーバ Webアプリケーションエンジニアとして開発へ参画

婚活診断 Webサービス
概要女性をメインターゲットとした婚活分析・相談アプリ担当フルスタックエンジニアとしてプロジェクトにアサイン使用技術サーバ：PHP/Laravel8, MySQL8.0, フロント: Vue.js /Nuxt.js2, Typescript 開発中の課題・工夫した点 ◯登録ユーザーに対してサービス活用を促すリマインドメール詳細結婚確率などの診断を行いユーザー登録後に、診断結果の作成日時をもとに 1日後 7日後 30日後 90日後 180日後 180日以降90日ごと経過日時ごとにリマインドメールをユーザーへ送ることで、ユーザーに対してアプローチ(囲い込み)を行う機能。 Laravel のタスクスケジューラーを使用し、バッチ処理を仕込むことで機能の実装をおこなった。工夫した点要件として、経過日時によって取得するユーザーデータが変わる。そのため、経過する日時を変更するだけで、取得するデータが変わるサービスクラスを作ることをおこなった。経過日時ごとの取得する処理を書くのではなく、 1つのクラスで使いまわせるように調整をおこなった。 ◯結婚診断結果履歴表示詳細ユーザーが今まで実施した診断結果を1つのページに履歴として表示する。課題ユーザーによっては、件数が多い方もいらっしゃるため、 1つのページで表示するとかなり時間がかかっていた。工夫した点件数が多くなった場合でもユーザーにとって処理が重くならないようにクライアントに、ページネーションでの表示を提案を行った。ページネーション自体の件数も1つページあたり、10件にすることで、表示速度が重くならずに表示することができた。
Mar 2022 - Jul 2022