ID:73895さん

2024年5月回 指名


まだ何もありません

自己推薦一覧

自己推薦はありません

あなたを気にしている企業

  • GraciaがID:73895さんを検討中に入れました。
    2024.05.21
  • GraciaID:73895さんのアウトプットのURLを見ました!
    2024.05.21
  • GraciaがID:73895さんのレジュメを見ています。
    2024.05.21
  • LegalOn TechnologiesがID:73895さんのレジュメを見ています。
    2024.05.21
  • BEENOSがID:73895さんのレジュメを見ています。
    2024.05.21
  • ホワイトプラスがID:73895さんのレジュメを見ています。
    2024.05.21
  • 令和トラベルがID:73895さんのレジュメを見ています。
    2024.05.21
  • BuySell TechnologiesがID:73895さんのレジュメを見ています。
    2024.05.21
  • イタンジがID:73895さんのレジュメを見ています。
    2024.05.21
  • エス・エム・エスがID:73895さんのレジュメを見ています。
    2024.05.20

3年後の目標や野望


自分の技術で「かゆいところに手が届く」を実現したい

ちょっとした困りごとを技術で解決することに喜びを感じます。 また、小さな問題を解決するツールやサービスを素早く作ってしまえるような方々のことをとても尊敬しています。そうなりたいです。 決して目立つことではないかもしれませんが、その積み重ねが大きなサービスの開発にも活きると考えています。

年収評価シート

2019年/2年以上

営業フリーランス向けの求人サービス開発

営業リソースが足りない企業が仕事を掲載し、フリーランスや副業の営業マンがその仕事に応募し、両者のマッチングをはかるという求人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年ほど同サービスに関わり続けており、適任だと判断されてのアサインでした。 長期間携わったことによるドメイン知識の蓄積やコードベースへの深い理解をもとに、バックエンドエンジニアと密にコミュニケーションを取りながら、後続の担当者に引き継ぐまで開発を行いました。

2021年/2年以内

飲食店向けの非接触オーダーアプリ

飲食店内で非接触で注文ができるアプリケーションの開発を行いました。 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でドキュメント化して共有し、たたき台にして実装方針を話し合いました。 単に「こういう形でデータがほしい」というフロントエンド側からの要求を投げっぱなしにするのではなく、バックエンド実装者の目線で細かい実装の詳細などを話し合うことができました。 ## バックエンド実装状況のキャッチアップ 開発中はバックエンドがどのような実装になっているのかをできるだけ確認するようにしました。バックエンドの実装内容を把握することで、技術的なお願い / 相談 / 提案 / 妥協点の模索 / アイデア出しなどの話し合いをより密に円滑に行うことができました。

2020年/2年以内

自社の営業チーム用のマップWebアプリケーション

自社の営業社員が訪問可能な顧客の管理に使用する地図アプリケーションを開発しました。地図機能はフロントエンドに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で定期実行

2021年/1ヶ月以内

小規模Webサービス用のAWS構成をTerraformでコード化

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

2024年/半年以内

カナダのWeb開発企業での勤務

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

2022年/2年以上

URLやパスをハードコーディングしなくてすむようにするライブラリの開発 (個人開発)

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

2023年/半年以内

工場で使用される作業用具の貸出状況管理機能の開発 (カナダ・日系企業)

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化されていることによって型安全性を担保する

マネージメント能力

アピール項目


アウトプット

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

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

- AWSなどクラウドインフラ周辺の知識が弱いので身につけたいと考えています。過去に実務でAWSのサーバー構築やTerraformでのコード化などを行いましたが、調べつつの実装だったので、体系的に学んで使えるようになりたいと考えています。 - バックエンドの実装スキルを高めたいです。現在フロントエンドを中心に業務を行っていますが、バックエンド開発への興味を失ったわけではありません。領域にこだわらないアプリケーション開発エンジニアとして成長していきたいので、またバックエンド開発にも携わって技術を高めたいと考えています。 過去にPHP / LaravelとTypeScript / NestJSでの実装経験がありますが、できれば他の言語にもチャレンジしてみたいです。

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

- Don't be evilのモットーが浸透している環境 - 作る理由が明確でそれに対して納得できている状態 - 風通しがよく、フランクに何でも話ができる環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
学習能力 / 調整力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
SI / 金融 / 広告 / 仮想通貨
その他の特徴
新しい技術はとりあえず試す / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

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

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

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

  • {{error}}
SIGN UPSIGN IN


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