koyablue

営業リソースが足りない企業が仕事を掲載し、フリーランスや副業の営業マンがその仕事に応募し、両者のマッチングをはかるという求人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

カナダのデザインエージェンシー(主に受託開発などを行う企業)で勤務し、複数の案件にフロントエンドエンジニアとして携わりました。 Linkedin経由の紹介で採用され、完全な英語環境で開発業務を行いました。 担当した主な案件は以下の通りです。 - バンクーバーにあるフィットネスクラブのWebサイト - フロントエンドはNext.js。バックエンドはContentfulというヘッドレスCMS - ユーザー登録、クラスの購入などの機能があるWebアプリケーション - トロントの分譲コンドミニアムのWebサイト(Next.js) - その他メール送信SaaS連携やreCAPTCHA導入など 技術スタックも開発スタイルも見知ったものだったので、言語面でのハンデはあれど難なくスムーズに業務に入ってゆくことができました。 また、身一つで渡航した異国の地で現地の企業から「この人になら任せられる」と白羽の矢を立ててもらえたことは、技術者として働く上での大きな自信に繋がりました。

URLやパスをハードコーディングしなくてすむ「Path-Kanri」というライブラリを個人開発しました。 - GitHub: https://github.com/koyablue/path-kanri - npm: https://www.npmjs.com/package/path-kanri リンク先やAPIのエンドポイントなどがハードコーディングされている場面を業務内で何度も目撃しており、それらの管理に手を焼いていました。ハードコーディングなので変更や修正に弱く、数が増えてくると管理も厄介になってきます。そのような問題を解決したいと思ったのが、このライブラリの開発に至ったきっかけです。 PHPのフレームワークであるLaravelのルーティング管理方法にインスパイアされ、URLやパスを一元管理してコード内のどこからでも関数で呼び出せるような仕組みを実装しました。 また、ライブラリの全身である関数の実装記事をZennに投稿した結果、多くの人に読んでいただき、数日間Zennのトレンドに載ることができました。 https://zenn.dev/koyabluetech/articles/b5c23cbd78cc64

7名のチームにバックエンドエンジニアとして参加し、工場で使用される作業用具の貸出状況管理機能のWeb APIを開発しました。 既に稼働している管理Webアプリケーションに新しく機能を追加するという形で、当該機能の開発担当は私含め2名でした。 主な機能は以下の通りです。 - 貸出可能な工具に対して以下のようなデータを持たせて管理する - どの工具が - どの下請け業者の社員に対して - いつからいつまでの期間 - どのような方法で貸し出されたのか(郵送や直接受け取りなど) - 貸出状況はどうなっているのか - 貸出が予約されただけ / 貸出中 / 返却中 / 返却済み / 期間を過ぎても返却されていない など - 備考のコメント - 工具一覧をガントチャートで表示する - ガントチャートから工具に紐づく情報の登録 / 更新が可能 既存のコードベースにはコーディングルールがなく、各々が好きに実装するという、統一性を著しく欠いたものでした。また、Laravelが使用されていたものの、開発担当者全員がLaravelに不慣れという状況でした。 その状況の中、私の実装内容を参考に今後プロジェクト全体の実装や設計を立て直すことができる状態にしてほしいという、チームリーダーから私への要望がありました。 開発を担当する機能は3ヶ月で実装しきって、後続のメンバーに引き継がなければなりませんでした。その中で上記の要望を実現するために、主に以下のような取り組みを行いました。 ## 型宣言とDTOによる入出力データ型の明確化 - 約3ヶ月で引き継ぐ - 実装方針の立て直し この2点を考慮した際に最優先で取り組むべきは、型宣言を充実させることであると判断しました。なので、クラス変数や関数の引数に対する型付けを行い、さらにDTOを定義してどのような構造のデータが流れるのかを明確化しました。 ## 簡略化したレイヤードアーキテクチャの導入 既存の実装では全てがControllerに記述されており、解読、修正や変更などが困難な状態でした。そこで新規追加する箇所では何かしらの設計手法を導入しようと考え、レイヤードアーキテクチャを採用しました。 限られた期間内での実装かつ既存の実装と大きく乖離しないことを考慮した結果、以下のように簡素化した状態で適用しました。 - ドメインモデル + インフラ層としてEloquent Model(LaravelのORM)を使用 - UseCase層は廃してServiceクラスを作成し、ビジネスロジックとインフラ層の呼び出しをService内で行う - 当初は1アクション1UseCaseというようにファイルを分けて実装しようとしたが現状too muchであると判断し、粒度の大きいServiceクラスのみ実装することにした - too muchであると判断した理由は以下の通り - 適切な責務で関数を分割すれば問題ない - 適切な粒度で複数Serviceクラスを作成すれば問題ない - ファイルを分割しすぎると既存の実装と大きく乖離してしまう - ControllerはServiceクラスの処理を呼び出して表示用データを返す。プレゼンテーション層としての振る舞いに徹する - 最終的に返すJSONの構造を統一するため、必ずデータ型整形用関数を通して表示用データを返すように実装 - 入力バリデーションと入力値のDTO化をLaravelのFormRequestクラスで行う - バリデーション後のデータがControllerに流れてくる時点でDTO化されていることによって型安全性を担保する