ID:33203さん

2026年9月回 指名


まだ何もありません

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

  • COUNTERWORKSがID:33203さんのレジュメを見ています。
    2026.09.29
  • COUNTERWORKSがID:33203さんのレジュメを見ています。
    2026.09.28
  • RevCommがID:33203さんのレジュメを見ています。
    2026.09.27
  • GoalsがID:33203さんのレジュメを見ています。
    2026.09.25
  • ほぼ日がID:33203さんのレジュメを見ています。
    2026.09.25
  • アトミックソフトウェアがID:33203さんのレジュメを見ています。
    2026.09.25
  • GoalsがID:33203さんのレジュメを見ています。
    2026.09.25
  • アトミックソフトウェアがID:33203さんのレジュメを見ています。
    2026.09.25
  • SYSLEAがID:33203さんのレジュメを見ています。
    2026.09.24
  • クラシルがID:33203さんのレジュメを見ています。
    2026.09.24

キャリアビジョン


世の中を便利にするサービスを作りたい!!!

- エンジニアができる社会貢献 - エンジニア冥利ってそういう事だと思っている

プロジェクト経験

2026年/半年以内

AIコードレビュー導入によるPRリードタイム63%短縮

# 概要・背景 開発組織において、Pull Request作成後のコードレビューがボトルネックとなり、PR作成からマージまでのリードタイムが長期化していました。 開発速度を向上させつつ、レビュー品質を維持・向上させることを目的として、AIコードレビューサービス「CodeRabbit」の導入と、それを効果的に活用するためのリポジトリ基盤整備を主導しました。 # 担当・取り組み 単純にAIレビューサービスを導入するだけでは十分な効果が出ないと考え、既存のコードレビューの流れやボトルネックを整理した上で、CodeRabbitを開発フローへ組み込みました。 また、AIレビューを開発者が実際に活用しやすい状態にするため、リポジトリ側の設定や運用方法についても整備し、導入後も継続的に改善を行いました。 導入効果を感覚値だけで判断しないよう、PR作成からマージまでのリードタイムを指標として継続的に計測し、施策前後の変化を確認しました。 # 成果 取り組み開始から3か月後には、PR作成からマージまでのリードタイムを中央値ベースで63%短縮しました。 AIツールそのものを導入するだけではなく、既存の開発プロセス・リポジトリ基盤・運用をセットで改善し、定量的な開発生産性向上につなげることができました。 この取り組みを通じて得た知見をもとに、現在は個別ツールの活用にとどまらず、開発部門全体で生成AIを活用するための基盤整備・利用促進にも取り組んでいます。

2024年/2年以内

既存Webサービスのモダン技術スタックへの刷新プロジェクト

長期間運用されてきたレガシーな社内システムを、モダンな技術スタックへ段階的に置き換えるプロジェクトです。私はこの刷新を進めるためのフロントエンドエンジニアとして入社し、約10か月、フロントエンド2〜3名の体制でフロントエンドリードを担当しました。 既存システムについては、入社時の背景として、技術スタックの老朽化によるセキュリティ上の懸念、長年の改修によって蓄積したデッドコードや複雑性による開発速度の低下、扱えるエンジニアが限られることなどが課題として共有されていました。実際に現在も残っているレガシー部分を扱う中で、機能追加や変更の難しさは実感しています。 新システムではNuxt、TypeScriptを中心としたフロントエンドに加え、フロントエンドとバックエンドの間にBFFを設ける構成を採用しました。BFF導入の背景には、過去にフロントエンドの開発リソースが不足した際、支援できるエンジニアが少なく、フロントエンドがプロジェクト全体のボトルネックになった経験が会社としてあったことがあります。 そこで、フロントエンド固有の実装領域を必要以上に広げず、バックエンドを専門とするエンジニアでも担当しやすいBFF層を設けることで、特定職種の人員不足によって開発全体が止まりにくい構成を目指しました。単にフロントエンドとバックエンドを技術的に分離するのではなく、社内のエンジニア構成や過去のプロジェクト上の課題まで考慮してアーキテクチャを設計しています。 技術スタックとしてはNuxt、GraphQL、Hono、Node.js、Reka UI、Tailwind CSSなどを利用しています。私はフロントエンド側の設計・実装に加え、コードレビューや技術的な相談への対応を行い、ユニットテストについても、どこまで・どのような粒度でテストするかという方針を策定しました。 また、新しい技術を採用すること自体を目的にせず、今後継続して機能追加していくことを前提に、実装のしやすさや保守性、チーム内で扱える技術であることを重視しました。 現在も一部のレガシー領域は残っており段階的な移行を続けていますが、新システムへ置き換えた領域ではページレンダリング速度が大幅に向上し、新規機能の追加もしやすくなっています。 このプロジェクトでは、既存システムを単に新しい技術へ置き換えるのではなく、過去に発生した開発上・組織上のボトルネックまで踏まえて新しい開発基盤を設計することを意識しました。技術選定、アーキテクチャ設計、実装、テスト方針、レビューまで一貫して関わり、今後も継続的に開発できる基盤作りを進めています。

2023年/2年以内

1000超のソースを対象としたVue 2→Vue 3大規模移行・開発基盤刷新

## プロジェクトの目的 EOLを迎えたVue.js 2で構築されたWebアプリケーションをVue.js 3へ移行し、 今後も継続的に機能開発・保守できるフロントエンド基盤へ刷新することを目的としたプロジェクト。 ## プロジェクトの規模感 - プロジェクト期間:約10か月 - チーム:約10名(時期により変動) - フロントエンド:2〜3名程度 - 移行対象:1,000以上のソースファイル ## 担当した役割 - Vue.js 2からVue.js 3への移行に関する技術調査・移行方針策定 - Vue.js 3への移行実装 - メンバーへの技術展開・技術フォロー - コードレビュー - 移行手順・実装パターンのドキュメント化 - webpackからViteへのビルド基盤移行 - ESLintの導入・ルール設計 ### チーム内での立ち位置 プロジェクト開始前からVue.js 3を自主的にキャッチアップしていたため、 チーム内のVue.js 3有識者として技術面をリードしました。 自身で実装するだけでなく、移行方法の調査・方針策定、コードレビュー、 メンバーへの技術フォロー、ナレッジのドキュメント化などを担当し、 チーム全体がVue.js 3への移行を進められる状態を作る役割を担いました。 また、アプリケーションコードの移行だけではなく、 ViteやESLintの導入など、今後の開発を支えるフロントエンド基盤の刷新も主導しました。 ## チームが抱えていた課題 ### Vue.js 3の知識不足 プロジェクト開始時点ではVue.js 3の実務経験・知識を持つメンバーがほとんどおらず、 個々のメンバーが都度調査しながら移行すると、品質や実装方法にばらつきが出る懸念がありました。 ### 開発時のビルド速度 既存環境ではwebpackによるトランスパイルに時間がかかり、 日常的な開発効率を低下させていました。 ### 既存コードの潜在的な品質問題 Vue.js 3への移行を進める中で、不具合につながる可能性のある既存コードが 多数存在していることが判明しました。 ## 課題に対して自身が発揮したバリュー及び成果 ### Vue.js 3移行方法の標準化 Vue.js 3への移行方法や注意点、実装パターンを調査し、 移行作業の手引きとなるドキュメントを作成しました。 メンバーが毎回有識者に確認しなくても一定の方針で作業を進められる状態を作り、 大規模な移行をチームで進めるためのナレッジを整備しました。 また、コードレビューを通じて実装品質を担保するとともに、 個別に得られた知見をチームへフィードバックしました。 ### webpackからViteへの移行 webpackによるトランスパイル時間が開発効率のボトルネックとなっていたため、 Viteへの移行を提案・主導しました。 既存環境との互換性や移行に必要な技術調査から実際の移行まで担当し、 トランスパイル時間を従来の約1/6まで短縮しました。 ### ESLintによる品質基盤の整備 既存コードに潜在的な不具合につながる実装が多数存在していたため、 Vue.js 3への移行を機にESLintを導入しました。 プロジェクトの特性を考慮しながらルール選定を主導し、 問題のあるコードを静的解析で検出・修正できる仕組みを構築しました。 ## 成果 約10か月で、1,000以上のソースファイルを対象としたVue.js 3への大規模移行を完遂しました。 単なるフレームワークのバージョンアップに留まらず、 移行方法の標準化、メンバーへの技術展開、コードレビュー、 ビルド基盤・静的解析環境の刷新まで担当することで、 移行後もチームが継続的に開発しやすいフロントエンド基盤を構築しました。

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

マネージメント能力

CodeRabbit導入を中心とした、PRレビューからマージまでの開発プロセス改善をリードしました。レビュー品質と開発速度の両立を目的に、導入方針・設定調整・チーム展開・効果測定まで担当しました。
PR作成後、最初のレビューが行われるまでの待ち時間が長く、それに伴って指摘修正やマージも後ろ倒しになることが課題でした。そこで、PR作成直後に自動レビューが開始されるCodeRabbitを導入し、レビューの初動を早めながらコード品質も向上させる状態を目指しました。品質向上だけを追ってマージまでの時間が長くなっては意味がないため、レビュー品質とリードタイムの両方を見ながら継続的に運用を改善することを責務としました。
まずPR作成からマージまでのプロセスを確認し、大きなボトルネックの一つが「PRを作成してから最初にレビューされるまでの待ち時間」だと考えました。最初のレビューが遅れると、指摘への修正開始も遅れ、その後の再レビューやマージもすべて後ろ倒しになります。そのため、個々の開発者の実装速度だけではなく、レビューの初動を早めることが開発全体のリードタイム短縮につながると考えました。 そこで、PR作成とほぼ同時に自動レビューを開始できるCodeRabbitを導入しました。人間のレビュアーを待つ前に最初のフィードバックを返すことで、レビュー待ち時間を短縮し、開発者が早い段階から修正に着手できる状態を作ることを狙いました。 一方で、単にレビューを高速化するだけではなく、コード品質にも改善余地があると考えていました。そのため、CodeRabbitの設定はあえて厳しめの状態からスタートしました。指摘を厳しくすることでコード品質の向上が期待できる一方、指摘が増えすぎて修正コストが高くなり、マージまでの時間が伸びてしまえば本末転倒です。そのため「品質を高めながら、リードタイムは悪化させない」ことを前提とし、実際のレビュー内容や運用状況を見ながら設定を調整していく方針としました。 また、ツールを導入するだけではチーム内に定着しないと考え、利用方法や運用方針をまとめた簡単なドキュメントを作成しました。さらに、CodeRabbitの公式ドキュメントをソースとしたNotebookLMも用意し、各メンバーが疑問を持った際に、自分で必要な情報へアクセスできる環境を整えました。これにより、導入担当者に質問が集中するのではなく、チームメンバーがそれぞれ自走してCodeRabbitを活用できる状態を目指しました。 効果についても感覚ではなく、PR作成からマージまでのリードタイムを継続して計測しました。その結果、取り組み開始から3か月で、PR作成からマージまでの中央値を約63%短縮することができました。 この取り組みでは、単にCodeRabbitというツールを導入するのではなく、まず開発プロセス上のボトルネックを特定し、仮説を立てて施策を実行し、品質と速度の両方を見ながら運用を調整しました。さらに、ドキュメントやNotebookLMを整備することで、特定の担当者に依存せずチームが自走できる状態まで仕組み化し、最後に数値で効果を検証するところまで一貫して取り組みました。

アピール項目


アウトプット

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

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

最近フロントエンド界隈にRustの波が押し寄せているのでRustを書けるようになる。その上でViteのプラグイン作成なんかに手を出していきたい。

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

周りの人間が穏やかであること。

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード補完系の生成AIを活用
GitHub Copilot等のコーディング支援ツール
業務でコード生成、コーディングエージェント系の生成AIを利用
コードレビュー、テストコード生成、デバッグに生成AIを活用

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
責任感
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
プライベートとの両立
やりたくない分野
SI / 金融 / 医療・介護
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で40代前半
好きなテキストエディタ
Visual Studio Code
希望勤務地
東京都 / 神奈川県
希望年収
900万円
ご意見箱

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

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

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