ID:85154さん

キャリアビジョン


作るものを決める段階から関わり、実装から運用まで一貫して持てるエンジニアでいたい。

これまでの約20年は、要件が固まった後の実装を引き受ける立場が中心でした。受託・制作の現場が長く、ヘルスケア・不動産・金融・教育・ECなど幅広い領域を横断してきましたが、入るのは「何を作るか」が決まった後がほとんどでした。 その部分を自分で埋めるために、個人事業主として6プロダクト(Shopifyアプリ2本/モバイルアプリ4本)を、企画・技術選定・スキーマ設計・実装・ストア審査対応・課金実装・リリース後の運用まで単独で完遂してきました。そこで分かったのは、技術選定の精度は「何のために作るか」を持っている人間が決めたときに一番上がる、ということです。埋め込みアプリの認証でOAuthリダイレクトがiframeの制約に阻まれたときも、仕様の意図を自分で握っていたため、短命JWTを検証して必要時にトークンを取得する方式へ早い段階で切り替えられました。要件と実装を別の人が持っていたら、後戻りはもっと大きかったはずです。 同時に、一人で速く作れることよりも、チームで作り続けられることのほうがプロダクトの寿命には効くと考えています。設計判断は「採用しなかった選択肢とその理由」まで書き残し、チーム開発ではブランチ戦略・PRフロー・CSS命名規則を自ら策定してREADMEとして明文化してきました。実装そのものより「他の人が入ってきても同じ品質で書ける状態」を作ることに、意識的に時間を割いています。 2006年にFlash Developerとしてキャリアを始め、Flashの終焉とともにHTML/CSS/JavaScriptへ、さらにReact/TypeScript/Next.jsへと軸足を移してきました。プラットフォームが消える経験を一度しているので、いま使っている技術が続く前提は置いていません。直近はクラウド(2025年にAWS認定ソリューションアーキテクト – アソシエイトを取得)と、AIエージェントを開発フローに組み込むことに時間を使っています。 個人開発で企画から運用まで一人で回してきた経験を、チームの仕事に接続させたい。これが、このキャリアビジョンを掲げている理由です。

プロジェクト経験

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

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

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

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

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

マネージメント能力

アピール項目


アウトプット

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

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

## 1. IaC(Terraform / AWS CDK) いま一番の穴です。開発環境は Docker Compose で標準化し、構築・疎通確認・権限修正をスクリプト化して「手順書ではなく実行可能な形」で再現性を担保してきました。ところが**その考え方をクラウド側のリソースには適用できていません**。コンソールで作ったものは差分が追えず、環境が増えるほど手作業に戻ってしまいます。 ローカル環境でやってきた「設定を単一ソースに寄せて、そこから全部を生成する」進め方を、そのままインフラに持っていきたいと考えています。 ## 2. AWS の実装経験(資格と実務のギャップを埋める) 2025年に AWS認定ソリューションアーキテクト – アソシエイトを取得しましたが、**実務での AWS 利用は S3 を使った静的配信構成が中心**で、体系的に学んだ内容を実際に手で組んだ経験は多くありません。実務量としては GCP(Cloud Run / Cloud Build / Artifact Registry)のほうが上回っています。 直近で最も伸ばしたいのは、この「学んだが使っていない」状態を解消することです。具体的には、VPC・IAM の設計、コンテナ実行基盤(ECS / Fargate)、監視とコスト設計を、資格の知識ではなく運用した経験として持てるようにしたいと考えています。 ## 3. 生成AIを組み込んだ機能の設計 — 特に評価と制御 Claude Code の Skill / Hooks で仕様書の自動生成を組み、変更影響度を4段階で判定して「更新すべき時にだけ動く」制御を設計しました。個人開発では Anthropic API を本番機能に組み込んでいます。 一方で、**RAG やベクトル検索、出力品質の評価設計といった領域は未経験**です。AI を組み込んだ機能は「動いた」で終わらせると精度の劣化に気づけないため、次に取り組みたいのは**出力を継続的に評価し、劣化を検知できる仕組みを作ること**です。制御の設計はやってきたので、その延長として評価の設計を身につけたいと考えています。 ## 4. スケールを前提にしたデータ設計 個人開発では、集計処理をアプリ側で回さず DB 側(RPC)に寄せる判断をしてきました。ただし扱っているデータ量は小さく、**実データの規模で設計判断が試された経験はありません**。インデックス設計、クエリの実行計画の読み方、キャッシュ層の置き所を、負荷のかかる環境で判断できるようになりたいと考えています。 ---

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

## 1. 裁量があり、自分で見つけた課題に着手できる環境 これまでの改善は、いずれも依頼されて始めたものではありません。 - Docker Compose による開発環境の標準化と、複数案件への横展開 - Python + GitHub Actions による、プラットフォーム仕様変更の Slack 自動通知 - Claude Code の Skill / Hooks を使った仕様書の自動生成 いずれも案件業務の外側で、現場の非効率を自分で見つけて着手し、社内へ展開しました。**「気づいた人が手を挙げれば動かせる」余地がある環境**だと、案件をこなすだけでは出せない価値を足せます。逆に、決められた範囲の実装だけを回す体制だと、この部分が丸ごと余ります。 ## 2. 判断が文書に残り、非同期で追える環境 設計判断は「なぜその選択をしたか」を必ず残しています。**採用しなかった選択肢とその理由まで**書くようにしていて、単独開発のアプリでは `ARCHITECTURE.md` に、チーム開発ではブランチ戦略・PRフロー・CSS命名規則を README として明文化しました。 こうした情報が口頭で共有される環境だと、聞ける相手がいる時間帯にしか進めなくなります。**リポジトリの中に判断の履歴が置かれていて、後から入った人が自力で追いつける状態**だと、確認待ちの時間が消えて速度が出ます。自分がその状態を作る側に回ることもできます。 ## 3. まとまった時間で設計を詰められる環境 不具合の原因特定や設計の検討は、細切れの時間では進みません。確認画面付きフォームで日本語入力が切れる事象を調べたときは、**プラグインがステップ間データを Cookie で保持していて、日本語のURLエンコードで約4KBの上限に達している**ところまで特定し、文字数上限を仕様として確定させました。この種の調査は、途中で切られると最初からやり直しになります。 会議が一日に分散する体制より、**まとまった集中時間が確保できる体制**のほうが成果が出ます。

生成AIの活用状況

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

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
調整力 / 問題解決力 / 責任感
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
会社の安定性
やりたくない分野
未入力です
その他の特徴
新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で40代中盤
好きなテキストエディタ
VS Code
希望勤務地
東京都 / 大阪府 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
800万円
ご意見箱

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

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

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