400万人が利用する会社訪問アプリ
ソーシャルPLUS / フロントエンドエンジニア
ID連携・ソーシャルログインを基軸としたSaaS開発に従事
バンクーバーのデザインエージェンシーでフルタイムのフロントエンドエンジニアとして勤務。 使用技術: Next.js, Linux, PM2
カナダのデザインエージェンシー(主に受託開発などを行う企業)で勤務し、複数の案件にフロントエンドエンジニアとして携わりました。 Linkedin経由の紹介で採用され、完全な英語環境で開発業務を行いました。 担当した主な案件は以下の通りです。 - バンクーバーにあるフィットネスクラブのWebサイト - フロントエンドはNext.js。バックエンドはContentfulというヘッドレスCMS - ユーザー登録、クラスの購入などの機能があるWebアプリケーション - トロントの分譲コンドミニアムのWebサイト(Next.js) - その他メール送信SaaS連携やreCAPTCHA導入など 技術スタックも開発スタイルも見知ったものだったので、言語面でのハンデはあれど難なくスムーズに業務に入ってゆくことができました。 また、身一つで渡航した異国の地で現地の企業から「この人になら任せられる」と白羽の矢を立ててもらえたことは、技術者として働く上での大きな自信に繋がりました。
STS Innovation カナダ バンクーバー支社にてバックエンドエンジニアとして勤務。 製造施設で使用されるツール管理システムのWeb APIを開発しました。 使用技術: PHP, Laravel, PostgreSQL
6名のチームにバックエンドエンジニアとして参加し、工場で使用される作業用具の貸出状況管理機能のWeb APIを開発しました。 すでに稼働している管理Webアプリケーションがあり、そこに新規機能を追加する形で実装しました。 使用技術は以下の通りです: - バックエンド - PHP, Laravel, PostgreSQL, Docker コーディングルールがなく統一性を著しく欠いた混沌としたコードベースであり、開発を担当する機能についても3ヶ月で実装しきって後続のメンバーに引き継がなければなりませんでした。 そこで、自分が新規開発する機能だけでも修正と拡張が可能な状態にし、かつ他の部分の実装方法と著しく乖離しない状態で実装し引き継げるようにしました。 そのために、主に以下の方法を採用しました: - 処理ごとにDTOクラスを定義し、インプットとアウトプットのデータの型をコードから判別できる状態にした - ビジネスロジックはServiceクラスを作成して分離した - 入力バリデーションと入力値のDTOへの変換をLaravelのFormRequestクラスで行い、責務を分離した - 最終的にAPIから返すJSONの型を統一した
自社Webサービスのバックエンド / フロントエンド開発に従事。
営業リソースが足りない企業が仕事を掲載し、フリーランスや副業の営業マンがその仕事に応募し、両者のマッチングをはかるという求人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でドキュメント化して共有し、たたき台にして実装方針を話し合いました。 単に「こういう形でデータがほしい」というフロントエンド側からの要求を投げっぱなしにするのではなく、バックエンド実装者の目線で細かい実装の詳細などを話し合うことができました。 ## バックエンド実装状況のキャッチアップ 開発中はバックエンドがどのような実装になっているのかをできるだけ確認するようにしました。バックエンドの実装内容を把握することで、技術的なお願い / 相談 / 提案 / 妥協点の模索 / アイデア出しなどの話し合いをより密に円滑に行うことができました。
自社の営業社員が訪問可能な顧客の管理に使用する地図アプリケーションを開発しました。地図機能はフロントエンドにGoogle Maps APIを組み込んで実装されました。座標情報を持つ訪問先のデータをマップUI上にピンで表示し、クリックで詳細情報の確認やメモの保存などができる仕様です。 主な機能は以下の通りです。 - ユーザー用画面 - 訪問先をピンとしてマップUI上表示 - 訪問先についてのメモの登録、更新 - 管理画面 - 顧客情報の管理 - CSVインポート - ユーザー情報管理 使用技術は以下の通りです: - フロントエンド: - TypeScript, React, Emotion, Redux (Toolkit), Google Maps API - バックエンド: - PHP, Laravel, Go, MySQL, GitHub Actions, Docker, AWS 3名のチームにバックエンドエンジニア(インフラ構築含む)として参加し、すでにあるプロトタイプを元に新規開発を行いました。実装する機能自体はシンプルなものであり、どちらかといえばインフラ構築とバッチ処理実装が主な業務でした。 【主な取り組み、実績など】 ## Goによる大量データ投入のバッチ処理 初期データとしてCSVファイルから抽出した数万件のデータをDBに流し込む必要がありました。最初はPHPで実装しましたが、10時間以上経っても処理が終了しないような状態であり、別の方法を探すべきと判断しました。並行処理が可能なGoが適切だと考え、急遽Goを学習し、バッチ処理を実装しました。結果、10時間でも終わらなかった処理が40分に短縮され、大幅に業務を効率化することができました。 また、その後他プロジェクトでの同様のシチュエーションにおいても、この時の方法を転用することでスムーズなデータ投入を行うことができました。 ## AWSのインフラ構築 インフラ担当がチームにいなかったため、AWSでインフラ構築を行いました。 大まかな構成は以下の通りです。 - EC2 - RDS - S3 - Let's EncryptでSSL化し、証明書の更新はcronで定期実行
小規模サービス用にAWSでインフラ構築をする業務を担当しました。同じ構成が社内で何度も使われていたのでTerraformでコード化し、他プロジェクトでも設定を使い回せる状態にしました。 大まかな構成は以下のとおりです。 - VPC, EC2, SES, SNS, DBはMySQLを使用しRDSではなくEC2内に立てる - SSLはLet’s Encrypt - CIはGitHub Actions
業務: toC営業, 業務委託社員のマネジメント 商材: 光回線, 映像サービス, タブレット, スマートフォンなど
青山 晃也さん
のプロフィールをすべて閲覧
Wantedlyユーザー もしくは つながりユーザーのみ閲覧できる項目があります
過去の投稿を確認する
共通の知り合いを確認する
青山 晃也さんのプロフィールをすべて見る
株式会社Wiz / バックエンド/フロントエンドエンジニア
小規模サービス用にAWSでインフラ構築をする業務を担当しました。同じ構成が社内で何度も使われていたのでTerraformでコード化し、他プロジェクトでも設定を使い回せる状態にしました。 大まかな構成は以下のとおりです。 - VPC, EC2, SES, SNS, DBはMySQLを使用しRDSではなくEC2内に立てる - SSLはLet’s Encrypt - CIはGitHub Actions
