haton14

### 職種・役割・担当工程・チーム規模 - 職種: バックエンドエンジニア / CI・CDエンジニア / (フロントエンドエンジニア) - 役割: メンバー/ (テックリード) - 担当工程: 設計 / 開発環境整備 / 実装 / 構築 / テスト - チーム規模: 4〜7人・2チーム ### プロジェクト概要 会社のメインの事業である飲食店向け予約管理システムは、当初外部に委託して作られたことや稼働してから 10 年以上が経過したことなどが原因で、技術スタックもバラバラかつメンテナンス性が低く機能追加が困難となっていた。 そのためシステムのプラットフォームを再構築し、コンテナ化をベースにすることでアプリ・インフラの運用工数の削減とともに、開発生産性の向上を目的として行っている。 ### 担当業務 サーバサイドの技術選定とコア実装を行い、チームを横断して展開するテックリードのようなことを行いました。大きく分けて管理者向けとユーザ向け機能があり、管理者向け機能を担当。 ### 実績 - 画面設計・REST API設計【2021/10〜2022/01】 - 画面設計を行い、画面項目から必要なDBリソース・REST APIを洗い出し。 - OpenAPI(Swagger)でREST API設計。 - 開発環境整備・技術選定・コア実装・アーキテクチャ選定【2022/01〜2022/02】 - Windowsを使用している方もいるため、Docker Composeによるコンテナベースの開発環境構築。 - サーバサイドのフレームワーク・ライブラリ・アーキテクチャ選定。 - サーバサイドのコア実装を行いチームに横展開し、Rest API実装を進める。 - CI/CDをGitHub Actionsで整備。 - 自動テストの設定(UT)。 - OpenAPIの自動フォーマット。 - GoのMockファイル生成。 - コンテナをビルドしAWS Fargateにデプロイするパイプライン作成。 - < 使用技術等 > - gomock / golangci-lint / pq / PostgreSQL / Docker Compose / Docker / OpenAPI / ECR / Fargate / Cognito / GitHub Actions / Vue3 / Nuxt3 / TypeScript / Node.js - Go - 社内の標準言語となっているおりノウハウがある程度あるため。 - sqlx - 複雑なSQLを書くことが多いためORマッパーは検討していなかった。database/sqlの薄いラッパーであり、構造体にバインドする機能が便利なため使用。 - echo - 既存のGo製REST APIではDSLからOpenAPIとhandlerを生成してくれるGoaを採用していたが、ドキュメント不足により内部実装をみることが多いことや精通している方が少ないため薄いフレームワークであるechoを採用。 - レイヤードアーキテクチャ - 既存システムではhandler(controller)に処理を全て書いておりメンテナンス性や実装の統一感に問題があった。そのため、レイヤー毎に実装ルールを定義しロジックも分割することで既存の問題に対処した。また、これまでは結合テストのみだったが、レイヤーを分けたことで単体テストと結合テストをそれぞれ分けて実装できるようになった。 - DDD - 項目毎にロジックをもっていたとしても既存システムはフロントやサーバ、SQL内部など統一感なく実装されおり、ロジックの影響範囲調査が非常に困難であった。厳密なDDDではないが、すべてのシステムから共通で使うライブラリとして項目毎にValue Objectのようなものを作成することで、全ての実装者はそのライブラリだけ見ればロジックがわかるようになった。 - 管理者向けシステムの機能実装【2022/02〜2022/10】 - サーバとフロントの実装・テスト。 - 外注の方への技術指導・レビュー。 - 予約検索結果エクスポートバッチの技術選定・設計・実装【(2022/10〜2023/01】 - REST APIへのリクエストをトリガーとしてAWS Batch起動する構成。 - 巨大なデータのためバッチのメモリを枯渇させないようにストリーム形式でCSV, Excel帳票, PDF帳票をS3へアップロード。 - Goのioパッケージについて理解が深まった。 - ついでにファイルアップロードのコア実装としてチーム内に横展開。 - 新しく入ったメンバーのメンターをしながらタスクを分解し割り振り。 - < 使用技術等 > - Go, gocsv, ECR, Fargate, ECR, GitHub Actions, Docker - pgx - pqが機能追加はとまりメンテナンスのみしか行われていないためpgxのノウハウを得るため。 - scany - 社内で採用実績のあるsqlxと似た使い方できるかつ、pgxのドライバ以外の機能に対応しているため。また、sqlxのメンテナンスが積極的に行われていないのも理由。 - AWS Batch - バッチの処理が15分以上かかる場合もあるためLambdaではタイムアウトしまうため。 - S3 - CSV, Excel帳票, PDF帳票を配置し、ダウンロード用の期間の短い署名付きURLを発行するため。 - SES - 帳票が作成できたことをダウンロード用URLとともにメール通知するため。また、バッチが予期しない理由で失敗した場合にもメール通知する。

### 職種・役割・担当工程・チーム規模 - 職種: インフラエンジニア - 役割: メンバー - 担当工程: 構築 / 保守 - チーム規模: 2人 - インフラ専任の方と行った。 ### プロジェクト概要 サポートの切れてしまうAWS Aurora PostgreSQL 10を12へメジャーバージョンアップする。 「飲食店向け予約管理システムのプラットフォームの再構築」と並行して行った。 ### 担当業務 - メジャーバージョンアップによる設定値の差分を全て洗い出し、既存システムへの影響範囲調査、妥当な設定値を決めていく。 - 深夜にシステム全体を止めてのバージョンアップ作業実施。 ### 実績 - 私自身が初の作業実施となるシステム停止と再開・メジャーバージョンアップを問題なく遂行し、目立ったDB性能劣化も発生しなかった。 - 2段階のメジャーバージョンアップを実施するために必要な作業をドキュメント化し透明性があるようにした。 - PostgreSQL 12から廃止になったoidsのチェック方法がドキュメントに十分記載されておらず、PostgreSQLのソースを読み調査した。

### 職種・役割・担当工程・チーム規模 - 職種: バックエンドエンジニア - 役割: メンバー - 担当工程: 設計 / 実装 / テスト - チーム規模: 2人 - ディレクターの方と行った。 ### プロジェクト概要 当日に入った予約を、店舗で使用しているiPadOSアプリへプッシュ通知する機能を開発。 ### 担当業務 - ディレクターのざっくりとした要件を仕様に落とし込み資料作成し、実現したい機能の認識合わせを行った。 - プッシュ通知に必要なAWSリソースの作成、サーバサイドの実装。 - 一つのiPadに複数ユーザがログインする可能性があるため、端末識別子をキー・ユーザをバリューとしてDBに持ち、ログインユーザが変更されるタイミングでユーザを書き換えプッシュ通知対象であるか判定を行った。 ### 実績 - 複数の古いシステムに対して機能追加するためテストコードをまともにかくことができない状態であったが、コードをベースにマトリクス形式で網羅テストを作成しデグレを起こすことなく機能追加を行った。 - リリース時から現在に至るまで一度も問題を起こしていない。 - 年末までに機能がリリースされたことにより、某焼き鳥チェーン店に予約システムが導入される決め手となった。 - < 使用技術等 > - SQS - サーバサイドからのPush通知だと基本SNSを直接呼び出して問題ないが、10年以上前の古いJavaシステムがあり、SNSのライブラリ追加による影響が見えないため既に連携実績のあるSQSを間に挟む方針にした。 - Lambda - SQSをトリガーとしてSNSにプッシュ通知をリクエストするため。 - SNS - iPadOSにプッシュ通知をするため。

### 職種・役割・担当工程・チーム規模 - 職種: バックエンドエンジニア - 役割: メンバー - 担当工程: 要件定義 / データ選定 - チーム規模: 7人 - 役員・ビジネスサイド・外部の会社の方と行った。 ### プロジェクト概要 予約データ10億件ほどを保持しているため、来店者予測機能を開発できないか技術検証することが目的。外部のAI開発開発と共同で検証。 ### 担当業務 - A学習データに使えそうなデータの選定。 - ゴミデータのフィルタリング。 ### 実績 - 既存システムにレガシーな部分が多くデータをクリーンな状態にすることが難しいことがわかった。最終的に65%程度の精度までが限界と判明し打ち止めになった。

### 職種・役割・担当工程・チーム規模 - 職種: バックエンドエンジニア - 役割: メンバー - 担当工程: 設計 / 開発環境整備 / 実装 / 構築 / テスト - チーム規模: 3人 - 技術選定の相談役としての上司・インフラ専任の方と行った。 ### プロジェクト概要 EC2上にApache Tomcatを入れ動いていたJava製REST APIをメンテナンスや開発効率向上するためのリプレイスプロジェクト。その第１段階目として顧客管理機能をGoでリプレイスする。 ### 担当業務 - Java製REST APIの顧客管理機能のリプレイスに関わる全ての工程をほぼひとりでおこなった。 ### 実績 - 反省点だが既存実装があるからとドキュメントを充実させずに実装を進行したため出戻りもあった。 - 複雑な既存システムをリプレイスする時こそ既存仕様をまとめ意味でもドキュメントが大切であった。 - Fargate, GitHub Actionsなど最近のプロジェクトでも採用している技術の知見を得る場になった。 - 言語をGoにし、インフラ環境をAWS ECS Fargateへとクラウドネイティブに置き換えた。 - < 使用技術等 > - sqlx, pq, golangci-lint - Go - 1週間ほどで実装・テストを行えるようにキャッチアップ。 - Goa v3 - Goa v1が既存システムに採用されていたため。 - ドキュメントが充実していない中フレームワークの実装を見てプラグインカスタマイズを行った。 - リリースされたばかりでバグも多くコミュニティのSlackでメンテナと直接やり取りし、バグ報告などを行っていた。 - gomock - Mockを用いた単体テストを書くための知見を得た。 - GitHub Actions - CI/CDを構築した。当時はCircleCIが主流であり世の中にもあまりノウハウがなかったが、GitHubを使用するならこちらの方が伸びるだろうという期待と社内ノウハウをためるため。 - Code Build, Code Pipeline, Code Deploy, ECR, Fargate, Docker, Docker Compose - Docker Composeで開発環境を構築。 - 社内でFargate構築の知見がない中、CDのパイプライン含めて構築。

### 職種・役割・担当工程・チーム規模 - 職種: デスクトップアプリ開発エンジニア - 役割: メンバー - 担当工程: テスト / 実装 / 保守 / 顧客問い合わせ回答 - チーム規模: 10～30人 - 派遣業務(SES) ### プロジェクト概要 各医薬製造会社へパッケージソフトである医薬製造管理システムをカスタマイズ開発や、標準機能となる機能を開発する。 ### 担当業務 - カスタマイズ機能開発のテスト工程 - 標準機能の実装・保守・顧客問い合わせ回答 - 新しく参画したメンバーへの技術指導 - ラベル印字の電文デバッグ ### 実績 - 当時入社した40代の方と新卒である私の2人で参画し、派遣先の信頼を得て会社から増員できるきっかけになる。 - 派遣先の方と同じくらいドメインを理解しており、標準機能の実装や改修時に相談を受けるほどになった。 - 開発環境構築・検証環境構築・社内ライブラリの依存関係などドキュメント化し属人化しないように努めた。 - これらについてドキュメントがメンテナンスされておらず、派遣先の方でも構築できないほど記述が足りていなかった。 - 慣れないWindows Server上でのISS構築など自力で完遂した。 - < 使用技術等 > - VB / .NET Framowark / Oracle / ISS