Koya Aoyama

営業リソースが足りない企業が仕事を掲載し、フリーランスや副業の営業マンがその仕事に応募し、両者のマッチングをはかるという求人Webサービスの開発 / 運用を行っていました。 主な機能は以下の通りです。 - 求職者用画面 - 仕事の検索, 詳細確認, ブックマーク, 応募 - マイページ - プロフィール管理, 給与明細出力, 応募した求人の管理 - 求人を掲載する企業用画面 - 求人情報の登録, 更新, 削除 - 応募者の管理 - 企業情報管理 - 社内用管理画面 - ユーザー(求職者, 企業, 管理ユーザー)管理 - お知らせやブログ記事の管理 - 各種CSVインポート / エクスポート(求職者への支払い情報, ユーザー情報, 社内経理課用の情報 など) 使用技術は以下の通りです: - フロントエンド: - TypeScript, Next.js(Pages Router), Emotion, Redux(Toolkit), RTK Query - バックエンド: - PHP, Laravel, Go, MySQL, Deployer, GitHub Actions, Docker, AWS 5名のチームにバックエンドエンジニアとして参加しました。 継続的な新規機能追加を中心に、入社から退社まで長く携わりました。 2019年の4月に未経験からバックエンドエンジニアにキャリアチェンジし、始めてアサインされたプロジェクトでした。継続的な新規機能追加と運用、改修などを行い、2023年2月末の退社まで長く携わりました。 同プロジェクトに長期にわたって携わったエンジニアは私のみであり、オーナーシップを持って開発を行いました。 チーム構成は以下の通りでした。 - PM - 1名 - 開発チーム - 5名 【主な取り組み、実績など】 ## 自動デプロイ導入 参加当初はデプロイ方法がDeployerというツールを使用した手動デプロイでした。開発マシンにリリース用ブランチをpullし、コマンドを実行することでデプロイされるというものです。 モノレポ構成だったためフロントエンドで変更があった際もバックエンドエンジニアが手動でコマンドを実行してリリース作業をしていました。なので軽微な修正の反映すら手間がかかるといった状況でした。 そこで運用改善の一環としてGitHub ActionsとDeployerを組み合わせた自動デプロイを提案・導入し、リリース速度やコミュニケーションコストを減らすことができました。 設定方法などをQiitaにまとめて社内で共有し、その後他プロジェクトでも同様の自動デプロイ方法を導入する文化を根付かせることに繋がりました。 (書いた記事はこちら: https://qiita.com/koyablue/items/a809f86ca934de52f206) ## Goによるバッチ処理の実装 既存の求人情報に対して追加の情報を大量に登録しなければならないことがありました。PHPで行うには無理があったので、別プロジェクト(別セクションに後述)で使用経験があったGoでデータ投入のためのバッチ処理を実装しました。 元データが整理されていなかったので、必要情報をCSVファイルにまとめるところまでをPMを通して他部署に協力してもらいました。その後CSVにまとまったデータをGoによってDBに流し込みました。 ## レガシーなフロントエンドのTypeScript / Next.jsへのリプレイス 一度チームを離れましたが、大規模な改修計画が発足した際にフロントエンド担当としてチームに再加入しました。バックエンドをAPI化し、フロントエンドをTypeScriptとNext.jsで実装するという内容でした。 この計画の少し前に社内の別プロジェクトで初のフロントエンド実務を行っており、その際の自走能力を評価されて引き続きフロントエンドエンジニアとして参加することになりました。 当時すでに約3年ほど同サービスに関わり続けており、適任だと判断されてのアサインでした。 長期間携わったことによるドメイン知識の蓄積やコードベースへの深い理解をもとに、バックエンドエンジニアと密にコミュニケーションを取りながら、後続の担当者に引き継ぐまで開発を行いました。

飲食店内で非接触で注文ができるアプリケーションの開発を行いました。 QRコード読み込みでユーザーのLINE内ブラウザでアプリケーションが起動し、POSレジと連動して着席、メニューの確認、注文、会計(支払いは別)まで全てが非接触で完結可能なアプリケーションです。 主な機能は以下の通りです。 - ユーザー用画面 - QRコード読み取り - 利用人数の登録 - メニューの確認、注文、注文履歴の確認 - 会計(注文を締め切る) - 店舗用管理画面 - メニューの管理 - テーブルの管理(いくつテーブルがあり何人着席可能かなど) - レジの開局 - POSレジの状態を同期する 使用技術は以下の通りです: - フロントエンド: - TypeScript, React, Emotion, Redux (Toolkit), LINE Front-end Framework (LIFF) - バックエンド: - PHP, Laravel, MySQL, GitHub Actions, Docker, AWS - 他 - OpenAPI, ブレインPOSレジのAPI 7名のチームにフロントエンドエンジニアとして参加し、仕様策定、技術調査、実装方針決めなどを含むゼロからの新規開発フェーズを担当しました。 このプロジェクトがフロントエンド開発の初実務となりました。 チーム構成は以下の通りです。 - PM - 1名 - 開発チーム - 5名 以前からフロントエンドに興味があり自学自習していることを上司や部署内の人に伝えており、自走能力が評価された上でアサインされました。そのような状態においてバリューを出すために、フロントエンドの実装業務と継続的な学習の他に、バックエンド出身ならではの価値をチームに提供できるようにしました。このような携わり方が評価され、このプロジェクト以降継続的にフロントエンドエンジニアとして他プロジェクトにアサインされるようになりました。 【主な取り組み、実績など】 ## Swaggerで必要APIのラフ案をドキュメント化して共有 バックエンドからフロントエンドに転身したので、バックエンドチームとスムーズにコミュニケーションを取ることでチーム全体に貢献できると考えました。その一環として、プロジェクト開始のキックオフミーティング後すぐに必要APIのラフ案をSwaggerでドキュメント化して共有し、たたき台にして実装方針を話し合いました。 単に「こういう形でデータがほしい」というフロントエンド側からの要求を投げっぱなしにするのではなく、バックエンド実装者の目線で細かい実装の詳細などを話し合うことができました。 ## バックエンド実装状況のキャッチアップ 開発中はバックエンドがどのような実装になっているのかをできるだけ確認するようにしました。バックエンドの実装内容を把握することで、技術的なお願い / 相談 / 提案 / 妥協点の模索 / アイデア出しなどの話し合いをより密に円滑に行うことができました。

小規模サービス用にAWSでインフラ構築をする業務を担当しました。同じ構成が社内で何度も使われていたのでTerraformでコード化し、他プロジェクトでも設定を使い回せる状態にしました。 大まかな構成は以下のとおりです。 - VPC, EC2, SES, SNS, DBはMySQLを使用しRDSではなくEC2内に立てる - SSLはLet’s Encrypt - CIはGitHub Actions