ID:81531さん

キャリアビジョン


チームで設計を議論しながら、事業課題を解くプロダクト開発をリードするテックリードになりたい

現職ではビジネスサイドと要件を詰めながら、受講生管理基盤や外部企業との決済連携などを、要件定義から設計・実装・保守運用まで一貫して担ってきた。副業では10年以上稼働するレガシーRailsアプリのモダン化を主担当とし、ジョブ基盤の再設計・API契約の基盤構築・モデルとビジネスロジック層の責務分離を、提案書や規約docで合意を取ってから進めてきた。6月以降は新機能の開発もAPIからフロントまで担当している。 これらを通じて、業務構造を理解して保守性の高い設計に落とし込むこと、設計判断を言語化して合意を取りながら進めることに手応えを感じてきた。現職では、その判断をAI開発フローの評価基準や週次の技術共有・相談会という形でチームに渡し、後輩が自分で判断できるようになっていく変化も見てきた。 ただし業務委託という関わり方では、なぜこのリプレイスを行うのか、なぜこの技術選定なのか、ユーザーがどう使っているのかといった上流の文脈にアクセスしづらく、設計判断の前提を自分で確かめきれない。本業として事業の内側に入り、設計を同じ目線でレビューし合えるチームで技術判断を磨きたい。 まずはバックエンドエンジニアとして即戦力で貢献し、3〜5年の中期では、既存プロダクトの機能拡張・改善を設計からリードし、設計判断を文書化・共有してチームの判断の質を揃えるテックリードの役割を担いたい。言語やフレームワークにはとらわれず、事業に合った技術を選んで設計していきたい。

プロジェクト経験

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

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

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

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

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

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

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

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

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

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

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

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

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

マネージメント能力

社内エンジニアチーム(5名)の設計品質と技術力の底上げ。AI開発フロー「EDAF」の導入・運用と、週次の技術共有・相談会の立ち上げ・運営を担当。
各エンジニアがClaude Codeを自由に使い始めたことで崩れかけていたチームの設計方針(サービス層を極力避ける等)を、個人の注意ではなく仕組みで守れる状態にすること。あわせて、エンジニアの退社が続くなかで、ビジネスサイドが安心して相談できる、自走できるエンジニアを増やすこと。
## 課題 - AIの使い方が各自に委ねられ、チームの設計方針が守られなくなり始めていた - 自身よりエンジニア歴の浅いメンバーが増える一方で、ビジネスサイドが相談できるメンバーは減っていた - いずれもバックログにない課題で、誰かが起案しなければ手がつかない状態だった ## 工夫したこと - AIの出力を人がその都度チェックするのではなく、チームの設計方針を評価基準として組み込み、基準を満たすまで次のフェーズへ進めない仕組み(EDAF)にした。誰が使っても品質が揃うようにするため - 育成は業務時間を使うため、「投資としての育成」とビジネスサイドに説明して合意を得てから、エンジニア全員が集まる週次の技術共有・相談会(毎週3時間)を始めた - 相談会では答えを渡すのではなく、設計判断の理由・デバッグの進め方・コードレビューの観点を伝え、後輩が次から自分で判断できるようにした ## 結果 - EDAFを社内メインアプリに導入し、技術情報配信ツール「catchup-feed」とあわせて社内エンジニア5名が日常利用 - 相談会を始めてから、後輩から「ビジネスサイドとのミーティングで持ち帰らずその場で提案できるようになった」等のフィードバックを得た

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

アピール項目


アウトプット

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

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

Ruby / Ruby on Rails - Rails 8系の機能(Solid Queue・Solid Cache等)を活かした構成・設計の実践 - 大規模アプリケーションでの設計・運用経験を積みたい 設計・アーキテクチャ - DDD やモデル責務分割の体系的な学習 - API 設計(OpenAPI・契約駆動開発)の実践知見をさらに深めたい - Clean Architecture などのアーキテクチャを、規模や用途に応じて使い分ける判断(個人開発で実践中) テックリードとしての設計判断 - ADR などによる設計判断の文書化と、チームでの合意形成の進め方 - コードレビューや設計レビューを通じて、判断の理由をチームに伝える方法 - 開発者体験(DevEx)の改善によってチームのパフォーマンスを高める取り組み Go言語 - 個人開発で使用中、チーム開発での実践経験を積みたい インフラ・運用 - DB 設計・運用、特に大規模・レガシー Rails アプリのパフォーマンスチューニング - コンテナ・IaC(ECS / Terraform 等)の実践経験 - ネットワーク・OS / Linux の土台理解 AI活用 - LLM を活用した開発効率化(EDAFで取り組み中) - AIエージェントの設計・実装

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

設計を同じ目線でレビューし合い、事業の文脈を踏まえて技術判断を議論できるチームで、最もパフォーマンスを発揮できます。 副業では、大きな変更の前に改善提案書や規約docを作り、方針の合意を得てから実装する進め方を続けてきました。判断の理由を文書に残し、レビューで指摘を受けて磨いていくサイクルが回る環境ほど、設計の質もスピードも上がると実感しています。一方で、業務委託として関わる中では、なぜその機能が必要なのか、ユーザーがどう使っているのかといった文脈に触れにくく、判断の前提を確かめきれない難しさも感じてきました。 そのため、ビジネスサイドやユーザーの情報にエンジニアもアクセスでき、設計判断を文書で残す文化のあるチームを希望します。逆に、一人で機能の設計判断をすべて抱え、レビューし合う相手がいない体制では、力を発揮しにくいと感じています。新しい技術やツールの導入にも前向きで、チームに合うものは自分から提案して定着まで進めます。

生成AIの活用状況

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

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 巻き込み力
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
SI / 人材 / 広告 / ファッション / ゲーム / 仮想通貨
その他の特徴
レガシーな環境を改善できる / 新しい技術はとりあえず試す / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと

バックエンドを主軸に、ビジネスサイドと協議しながら技術で事業課題を解くプロダクト開発に取り組みたいと考えています。要件定義から設計・実装まで一貫して関われる環境と、コードレビューや設計議論を通じて互いに技術力を高め合えるチームを希望します。

副業で10年以上稼働するRailsアプリのモダン化と新機能開発に取り組んでいますが、業務委託という関わり方では事業文脈やユーザーの利用状況にアクセスしづらいため、本業として腰を据えて、内側から技術判断を積み上げていける環境に身を置きたいと考えています。シニアエンジニアとして即戦力で力を発揮し、中期的にはテックリードとして、設計判断をチームに伝える役割を担いたいと考えています。

Go言語の習熟やAI活用(Claude Code等)にも継続して取り組んでおり、新しい技術への挑戦機会を歓迎します。

やりたい事

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

基本プロフィール

年齢
今年で40代前半
好きなテキストエディタ
VSCode
希望勤務地
埼玉県 / 千葉県 / 東京都
希望年収
700万円
ご意見箱

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

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

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