haton14

自己推薦一覧

自己推薦はありません

3年後の目標や野望


茨城に家を建て家族で暮らす生計をたてるために、低レイヤーもある程度理解している技術者になり希少価値を上げる。

- 家族で広々とした地元に家を建て住みたいため。 - 技術的にはバックエンド・フロント・インフラと幅広く行っていたがために器用貧乏になっている。 - そのため、バックエンド・インフラに特化する方向で希少性を出したいと思う。 - 直接的なUI・UX改善よりは地道な改善の方が好きなためバックエンドをメインとしたい。 - バックエンドをメインであれば、フロントを行うのも問題ないです。 # 自己紹介 - エンジニアとしての実務経験は5〜6年目になり、バックエンドがメインになります。 - フロントもジュニアレベルですが業務・個人で触っております。 - インフラもある程度構築・運用経験がありクラウドネイティブ(Docker, CI/CD, AWS ECS Fargate, AWS Lambda, AWS SNS)な構成での経験があります。 - Goを触っている時間が長いですが、言語に強い拘りはなくその都度ベストな言語選定を心がけたいと思っています。

年収評価シート

2021年/2年以内

飲食店向け予約管理システムのプラットフォームの再構築【2021/10 ~ 現在】株式会社エビソル

### 職種・役割・担当工程・チーム規模 - 職種: バックエンドエンジニア / 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とともにメール通知するため。また、バッチが予期しない理由で失敗した場合にもメール通知する。

2022年/3ヶ月以内

Aurora PostgreSQLのメジャーバージョンアップ対応【2022/6〜2022/9】株式会社エビソル

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

2021年/3ヶ月以内

サーバサイド側からiPadOSアプリへのプッシュ通知機能開発【2021/8〜2021/11】

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

2020年/3ヶ月以内

来店者数予測AI機能の技術検証【2020/11〜2021/1】株式会社エビソル

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

2020年/2年以内

Java製REST APIの顧客管理機能をGoでリプレイス【2020/4〜2021/7】株式会社エビソル

### 職種・役割・担当工程・チーム規模 - 職種: バックエンドエンジニア - 役割: メンバー - 担当工程: 設計 / 開発環境整備 / 実装 / 構築 / テスト - チーム規模: 3人 - 技術選定の相談役としての上司・インフラ専任の方と行った。 ### プロジェクト概要 EC2上にApache Tomcatを入れ動いていたJava製REST APIをメンテナンスや開発効率向上するためのリプレイスプロジェクト。その第1段階目として顧客管理機能を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のパイプライン含めて構築。

2018年/2年以内

医薬製造管理システム【2018/9~2020/2】株式会社アドフォース

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

マネージメント能力

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
未入力です
Zenn アカウント
あり
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
あり

今後、身につけなければいけないと思っている技術は何ですか?

- エッジサーバにworkerを実装する知見 - Cloudflare Workersなど - BFFの代わりまたは一緒に使われていくかもしれないと思っているから - WebTransport - 双方向通信が必要なシステムで、通信速度が上がるに比例して使われていくようになるだろうから - Linuxのシステムコール制御の仕組み - 学問レベルでOS知識が足りていないため - WASI - コンテナ化とは別の抽象化技術としてクラウドネイティブな構成に取り込まれるだろうから

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

未入力です

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
学習能力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
プライベートとの両立
やりたくない分野
SI / 広告 / 仮想通貨
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す / stackoverflowで回答した
その他のやりたいこと・やりたくないこと

事業内容に拘りが強い方ではないですが、家族に話しても誇れるような内容が良いです。
広告系はあまり気が進まないです。

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で20代後半
好きな Text Editor
vscode
希望勤務地
東京都 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
未入力
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
SIGN UPSIGN IN


転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?