ID:66681さん

キャリアビジョン


バックエンドを軸に、インフラ・フロントエンドまで横断的に担えるエンジニアとして、プロダクト全体の品質に責任を持てる存在になりたい。

これまでRuby on Railsを中心としたバックエンド開発で経験を積んできました。 その中で「APIの設計だけでなく、インフラの構成やフロントエンドの挙動まで 理解していれば、もっと最適な設計ができる」と感じる場面が増えてきました。 具体的には、以下の領域を横断的に扱えるエンジニアを目指しています。 - **バックエンド**: APIサーバー設計・DB設計・パフォーマンス改善 - **インフラ**: AWS/GCPなどのクラウド構成・CI/CD・コンテナ管理 - **フロントエンド**: TypeScript/Reactを用いたUI実装・状態管理 それぞれを深く専門化するよりも、プロダクトの全体像を把握した上で 最適な技術選定や意思決定に貢献できる、いわゆる「広く深い」エンジニアを 目指しています。チームの規模にかかわらず、必要な場面で領域を超えて 動ける人材として価値を発揮したいと考えています。

プロジェクト経験

2026年/3ヶ月以内

インド人エンジニアとの協業による EOR プラットフォーム開発

| 項目 | 内容 | |------|------| | 期間 | 2026年6月 〜 現在 | | カテゴリ | Webサービス / SaaS / 業務システム | | 担当工程 | 設計・実装・テスト・インフラ運用 | | 役割 | バックエンド・フロントエンド・インフラ・テックリード | | チーム編成 | PM 1名 / 開発者 3名(自身 + インド人エンジニア 2名)/ ビジネスチーム 2名 | | 使用技術 | PHP (Laravel) / React / Inertia.js / TypeScript / Go / MySQL / AWS / Docker / Caddy | **概要** 日本企業が現地法人なしで海外人材を採用できる EOR(Employer of Record)プラットフォームの開発に、創業期のチームとして参画しています。インド人エンジニアと日本側ビジネスチームの橋渡し役を担いながら、バックエンド・フロントエンド・インフラを横断的に実装しています。 **取り組みのポイント** - **日印クロスカルチャーチームの連携** 日本語・英語が混在するコミュニケーション環境で、日本側の業務要件をインド人エンジニアに正確に伝達し、双方の認識を揃えながら開発を推進しました。技術的なリードとして、要件の翻訳・優先順位の調整・意思決定を担いました。 - **複数レガシーデータソースの統合アーキテクチャ設計** Google Drive・Dropbox・メールなど分散したデータを統合するミドルウェア層を、Canonical Data Model(CDM)を用いて設計・実装しました。 - **AI エージェントとの連携** Dify ベースの AI エージェント(日本チーム主導)と EOR プラットフォーム(インド側エンジニア主導)の統合を調整役として牽引し、CDM と Google Drive を介したデータ整合性を確保しました。また Laravel AI SDK を活用し、レジュメ解析・AI 検索などの機能を実装しました。 - **インフラ整備と本番環境への移行計画** Contabo VPS 上で Caddy / Sentry / Resend を用いたアプリケーション基盤を構築・運用し、AWS への本番移行戦略の策定にも携わっています。

2021年/半年以内

声紋による話者識別機能のプロジェクトリード

| 項目 | 内容 | |------|------| | 期間 | 2025年(フリーランス参画期間内) | | カテゴリ | Webサービス / 音声認識システム | | 担当工程 | 要件定義・設計・実装・テスト・リリース | | 役割 | バックエンド・フロントエンド・プロジェクトリード | | チーム編成 | PM 1名 / 開発者 5名 / QA 1名 | | 使用技術 | Ruby on Rails / Go / React / TypeScript / GitLab / GitLab CI/CD / AWS / Azure | **概要** 会議参加者を声紋で自動識別するユーザー識別機能を、要件定義からリリースまでプロジェクトリーダーとして主導しました。音声処理という専門性の高い領域を含むため、技術調査から設計・実装・品質管理まで一貫して牽引しました。 **取り組みのポイント** - **技術的難易度の高い領域の要件定義** 声紋識別という技術的に複雑な領域において、実現可能な精度・処理フロー・エラー対処方針を整理し、チームが迷わず実装できる仕様に落とし込みました。 - **プロジェクトリーダーとしての進捗管理** 要件定義・設計・実装・テストの各フェーズでマイルストーンを設定し、遅延リスクを早期に検知して優先順位を調整しながら期日通りのリリースを実現しました。 - **レガシー仕様の整理と開発基盤の強化** 既存システムの未整理な仕様を整理・ドキュメント化し、本機能の開発を通じてチーム全体の知識共有と開発効率の向上にも貢献しました。

2024年/半年以内

会議要約生成機能の最適化およびオプション要約方法の変更

| 項目 | 内容 | |------|------| | 期間 | 2025年(フリーランス参画期間内) | | カテゴリ | Webサービス / 音声認識システム | | 担当工程 | 要件定義・設計・実装・テスト | | 役割 | バックエンド・フロントエンド | | チーム編成 | PM 1名 / 開発者 5名 / QA 1名 | | 使用技術 | Ruby on Rails / React / TypeScript / GitLab / AWS | **概要** 会議の音声から自動生成される要約機能に対して、ユーザーが要約方法をカスタマイズできる機能の追加開発を担当しました。テストフェーズでの不具合が1件のみという高品質な納品を実現しました。 **取り組みのポイント** - **要件の曖昧さを早期に解消** 「要約方法を変更できる」という要件に対して、具体的なオプションの種類・UI挙動・バックエンドへの反映方法を設計段階で詳細に詰めることで、実装中の手戻りを防ぎました。 - **バックエンドとフロントエンドの一貫した実装** オプション設定の保存ロジック(Rails)とUI側の選択インターフェース(React)を自身で一貫して実装することで、連携部分のバグを最小化しました。 - **テスト設計による品質担保** 要約オプションの組み合わせパターンを網羅したテストケースを設計し、テストフェーズでの不具合を1件に抑えた高品質な納品を達成しました。

2025年/3ヶ月以内

RSpec テストカバレッジ向上

| 項目 | 内容 | |------|------| | 期間 | 2025年(フリーランス参画期間内) | | カテゴリ | Webサービス / 音声認識システム | | 担当工程 | 実装・単体テスト・保守運用 | | 役割 | バックエンド | | チーム編成 | PM 1名 / 開発者 5名 / QA 1名 | | 使用技術 | Ruby on Rails / RSpec / GitLab / GitLab CI/CD / AWS | **概要** 音声認識システムのテストカバレッジが約20%と低く、品質が不安定な状態でした。既存コードの仕様を整理しながら RSpec による単体テストを体系的に実装し、カバレッジを約70%まで引き上げました。 **取り組みのポイント** - **仕様が不明確なレガシーコードへの対応** ドキュメントが整備されていないコードベースに対して、動作を読み解きながら仕様を整理しつつテストを設計しました。テストを書くこと自体がドキュメントとしても機能するよう意識しました。 - **テスト設計の体系化** 場当たり的なテスト追加ではなく、境界値・異常系・正常系を網羅する設計方針を定め、チームで再現性のある品質向上の仕組みを構築しました。 - **品質改善の定量的な成果** カバレッジ 20% → 70% の達成により、リリース後の不具合発生件数を大幅に削減し、システムの安定稼働に貢献しました。

2023年/1年以内

大手広告代理店の社内管理システムの追加開発

| 項目 | 内容 | |------|------| | 期間 | 2023年4月 〜 2023年11月(約8ヶ月) | | カテゴリ | Webサービス | | 担当工程 | 実装・単体テスト・結合テスト・保守運用 | | 役割 | バックエンド・フロントエンド | | チーム編成 | PdM 1名 / 開発者 4名 / デザイナー 1名 / PJ全体 20名 | | 使用技術 | Ruby on Rails / Vue.js / JavaScript / MySQL / DynamoDB / AWS / Docker / GitHub | **概要** 社内の業務効率化を目的として、SNS投稿機能と活動記録管理機能を追加開発しました。メンバーとして実装フェーズ以降を担当し、後輩の技術的サポートやコードレビューも行いました。 **取り組みのポイント** - **公式ドキュメントを活用した自律的な情報収集** 技術記事がほとんど存在しない領域のため、公式ドキュメントを積極的に参照し、irb での動作確認を繰り返しながら実装を進めました。DynamoDB 連携では AWS 公式サイトや Dynamoid gem のソースコードまで遡って正確な理解に努めました。 - **コードレビューへの真摯な対応** 経験豊富な先輩からのレビューで指摘を受けた際、答えられない部分は自分で深く調べ直した上で再レビューを依頼しました。複雑な処理には説明コメントを加え、意図が伝わるコードに整理しました。 - **RSpec による単体テストでコード品質を担保** 複雑な処理が多かったため、単体テストを詳細に設計することでブラックボックステストを回避し、コードの信頼性を確保しました。

2024年/1年以内

不動産仲介業社向け販売管理システムの開発

| 項目 | 内容 | |------|------| | 期間 | 2024年4月 〜 2024年10月(予定) | | カテゴリ | Webサービス / 業務システム / 受託開発 | | 担当工程 | 要件定義・設計・実装・テスト・保守運用 | | 役割 | バックエンド・フロントエンド・エンジニアリングマネージャ | | チーム編成 | PdM 1名 / PM 1名 / 開発者 2名 / PJ全体 4名 | | 使用技術 | Ruby on Rails / JavaScript / MySQL / AWS / Docker | **概要** 不動産仲介会社への販売管理システム導入により、業務効率化を実現するプロジェクト。4名の少人数チームの一員として、顧客との要件定義から導入まで全工程に携わりました。 **取り組みのポイント** - **業務フロー図を起点とした要件整理** 現在手動で行っている業務をシステムにどう落とし込むかを業務フロー図ベースで整理しました。ビデオ通話では伝わりにくい細かい要件は顧客先へ直接訪問して対話することで、満足度の高い仕様に仕上げました。 - **開発効率を重視した環境構築** webpack から vite への移行など、開発スピードを上げる環境構築を積極的に提案・実施しました。ドキュメントは細かく作り込むより、開発がスムーズに進むことを優先した最低限の資料作りを徹底しました。

2023年/1年以内

大手銀行向け行員利用システムの追加開発

| 項目 | 内容 | |------|------| | 期間 | 2023年12月 〜 2024年(複数フェーズ) | | カテゴリ | Webサービス | | 担当工程 | 要件定義・設計・実装・テスト・保守運用 | | 役割 | バックエンド・フロントエンド・インフラ・PM | | チーム編成 | PdM 1名 / PM 1名 / 開発者 3名 / PJ全体 15名 | | 使用技術 | Ruby on Rails / JavaScript / jQuery / PostgreSQL / AWS / Docker | **概要** 大手銀行の行員向けシステムを利用企業ごとにカスタマイズ追加開発し、新たな販路を開拓するプロジェクト。PMおよびメンバーとして要件定義フェーズから参画し、顧客ヒアリング・設計・実装・テスト・納品まで一貫して担当しました。 **取り組みのポイント** - **抽象的な要望を実現可能な仕様に落とし込む** 顧客から提示される抽象的なシステムイメージを、既存機能を参考にしながら技術的裏付けのある提案として具体化しました。リポジトリが分岐したシステムでも、共通システムの構成を維持しながら要件通りの実装を実現しました。 - **工数見積もりと優先順位づけによる進捗管理** 機能単位で工数を見積もってメンバーをアサインし、回収インパクトの大きい機能から着手する優先順位づけを実施。GitHub Issues の消化率で進捗を可視化しました。 - **運用を想定した高品質なテスト設計** 複雑な操作フローを含むため、顧客ヒアリングで得た知見をもとに最適なテストケースを設計。単体テストカバレッジ 95% 以上を達成し、納品品質を確保しました。

マネージメント能力

前職(Cuon)で参画した「大手銀行向け行員利用システムの追加開発」において、PMとして開発チーム全体のマネジメントを担いました。
3ヶ月という限られた期間内に、要件定義から総合テストまでを完遂し、品質を担保した上でお客様に納品する責務がありました。銀行システムという性質上、仕様の曖昧さや手戻りを最小化することが特に重要でした。
# プロジェクト概要 開発内容: 大手銀行向け行員利用システムの追加開発 期間: 3ヶ月 工程: 要件定義から総合テスト チームメンバー: 4名(PM1名、開発者3名) 技術: Ruby on Rails, AWS, Docker ツール: GitHub Issues、要件定義シート # 取り組みと工夫 ## 1. 要件の認識齟齬を防ぐ仕組みづくり 銀行側の担当者はシステム開発に不慣れなため、要件のすり合わせ時に技術的な説明をそのまま伝えると誤解が生じるリスクがありました。ミーティングでは技術用語を極力使わず、業務フローに置き換えた言葉で説明するよう徹底しました。また要件定義シートを都度更新・共有し、認識の相違を早期に検出できる体制を整えました。 ## 2. 進捗の可視化とリスク管理 GitHub Issuesでタスクを細分化して管理し、週次の進捗報告ミーティングでチーム全体の状況と課題を共有しました。開発者が抱える技術的なブロッカーを早めに察知できるよう、日次スタンドアップで各自の作業状況を確認し、遅延の兆候があれば即座にスコープ調整の判断を行いました。 ## 3. チームメンバーの自律的な動きを引き出す 開発者がタスクの意図を理解した上で実装できるよう、GitHub IssuesやSlackでのコメントを通じて背景・目的を丁寧に伝えるよう意識しました。1on1で各メンバーの詰まりポイントを拾い上げ、実装方針の合意形成をこまめに行ったことで、手戻りを最小化しながら期日通りに納品することができました。 # 習得したスキル - 技術的な内容を非エンジニアにわかりやすく翻訳するコミュニケーション能力 - 進捗・リスクを俯瞰し、タイミングよく意思決定するプロジェクト管理能力 - メンバーの自律性を引き出すための1on1・非同期コミュニケーションの設計

このマネージメント能力は公開されていません

アピール項目


アウトプット

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

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

# 1年後 スキルアップにフルコミットして、自走力のあるエンジニアとしてチームを引っ張る存在になりたいです。 スキルアップのためには、業務で扱う技術を中心に個人でアプリ開発を行います。 未経験からエンジニアに転職する際にも、個人でアプリを開発した経験があるため、次のアプリ開発ではフロントエンドやインフラの技術を使いながら進めていきたいと思っています。 # 3年後 プロジェクトのリーダーとして、お客様への価値を最大化したいと考えております。 プロジェクトとして担当するタスクを行うだけではなく、個人開発で得られた技術も活用して、積極的に開発環境のアップデートやメンバーとのコミュニケーションを大事にしていきます。 また、プロジェクトマネージャーの動きもよく確認しつつ、3年後には自分がそのポジションにいるんだというビジョンを描きながら進めていきたいと思っています。

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

# 1. 会社のビジョンに共感できるか ビジョンに共感できる場合、自分自身もより一層やりがいを持って取り組むことができると考えています。 また、そのような環境には、私と同じような考え方の人が集まると考えていますので、 同じビジョンを持った仲間と働きたいと考えているためです。 # 2. 新たなチャレンジを受け入れる環境があるか 私は過去の仕事の中で多くのアイデアを提案し、組織全体を大きく成長させる取り組みを進めてきました。 年齢や立場に関係なく、チャレンジする人をアイデアを歓迎する環境であると、私自身やりがいを感じ、 より一層のパフォーマンスを発揮できるためです。

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード補完系の生成AIを活用
GitHub Copilot等のコーディング支援ツール
業務でコード生成、コーディングエージェント系の生成AIを利用
コードレビュー、テストコード生成、デバッグに生成AIを活用
サービス・プロダクトへの応用
既存のサービスやプロダクトに生成AI(API利用など)を組み込み、LangChainやLlamaIndexなどのフレームワークを使った開発経験
生成AIをコアとした開発
生成AIを主要技術としたサービス・プロダクト・機能の企画や、RAGなどの高度な手法を用いた開発経験
モデルの構築・研究開発
LLMのファインチューニングや、独自モデルの構築経験

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
学習能力 / 企画立案力 / 巻き込み力
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
風通しの良さや意思決定ライン
やりたくない分野
SI
その他の特徴
新しい技術はとりあえず試す / 趣味は仕事 / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと

エンジニアとしての技術力を習得し、その技術力を持って貢献していける環境があることを希望します。

やりたい事

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

基本プロフィール

年齢
今年で30代中盤
好きなテキストエディタ
Visual Studio Code
希望勤務地
リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
1199万円
ご意見箱

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

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

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