ID:70410さん

キャリアビジョン


技術でリードしながら領域を越えて学び続け、人に誇れるサービスを生み出すエンジニアになる

エンジニアとして最終的に目指すのは、自分が関わったと胸を張れるサービスを世に送り出すことです。日々の業務で技術を磨いていく過程は楽しいものですが、その積み重ねの先に「これは自分が作った」と人に語れるアウトプットがあってこそ、エンジニアとしての価値が完成すると考えています。 これまでは社内展開用のサービスやto Bのシステム開発が中心であったため、より多くの人に触れてもらうことや役にたつサービス開発に携わりたいと考えています。

プロジェクト経験

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

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

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

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

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

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

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

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

2024年/2年以上

kintone 開発支援

kintoneを用いた自治体・企業向けWebアプリ開発プロジェクトの立ち上げおよび顧客対応。15名規模のPJで自社メンバー統括(リーダー)を担当。kintone研修資料の作成と社内展開、倉庫管理業務のシステム化、オンラインストレージサービス連携プラグイン開発(Node.js)を実施。ローコード領域の立ち上げから顧客対応までを担い、新規領域の事業立ち上げ経験を獲得。

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

マネージメント能力

自治体・企業向けWebアプリケーション開発プロジェクトにおける、自社メンバー(立ち上げ時4名から現在12名)のマネジメントを担当。プロジェクト全体は協力会社含め約60名規模で、その中で自社メンバーの統括役として、開発作業の推進、スキル・タスクのアサイン管理、若手メンバーの育成、顧客折衝までを一貫して担っている。
プロジェクトの拡大に伴い、自社メンバーが4名から12名へと増えていく中で、2つの状態を作り出すことが責務でした。 1つ目は、新しく加わるメンバーがスムーズにオンボーディングし、戦力として機能する状態を継続的に維持すること。チーム規模の拡大は短期間で発生するため、育成の時間を確保しながら開発スピードを落とさない仕組み作りが求められました。 2つ目は、顧客から寄せられる要望と、メンバーごとのスキル・稼働負荷のギャップを埋め、品質と納期の両方を成立させる状態を作ること。年次やスキル差にバラつきのある混成チームでも、アウトプットの質を安定させ、顧客の信頼を維持する責任を担いました。
## 考え方 チーム拡大期において、リーダー1人がすべてを抱え込む体制では限界があると早い段階で判断しました。自分が顧客折衝とプロジェクト全体の意思決定に集中するためには、内部のマネジメントを分担する仕組みと、メンバー一人ひとりが自走できる土台を並行して整える必要があると考えました。また、混成チームである以上、個々のスキルや稼働状況を「見える化」しなければ、適切なアサインも公平な負荷配分もできないと考えました。 ## 直面した問題・障害 実際に進める中では、3つの障害が顕著になりました。 - 1つ目は、メンバー拡大時の技術キャッチアップと年次スキル差による生産性のバラつきです。新しく加わるメンバーが既存の技術スタックに慣れるまで時間がかかり、初期はチーム全体のアウトプットが落ち込む傾向がありました。 - 2つ目は、顧客からの要件調整や仕様変更への対応です。プロジェクトが拡大するほど顧客側の要望も増え、若手メンバーには対応が難しい変更も発生しました。 - 3つ目は、協力会社メンバーを含むチームでのコミュニケーションと品質管理です。所属が違うメンバー同士で前提知識や文化が異なるため、認識ズレや成果物の品質ばらつきが起こりやすい状況でした。 ## 工夫したこと これらに対して、4つの工夫を実施しました。 - 1つ目に、サブリーダーを育てて一部マネジメントを委譲しました。自分がすべての判断を行うのではなく、信頼できるメンバーに徐々に範囲を任せ、自分は顧客折衝や全体方針に集中できる体制を作りました。これによりチーム拡大時の意思決定のボトルネックを解消できました。 - 2つ目に、ペアプロ・コードレビュー・1on1を仕組み化してスキル伝承の場を継続的に設けました。一過性のオンボーディングで終わらせず、日常業務の中でスキルが伝わる流れを作ることで、新メンバーの立ち上がりを加速させました。 - 3つ目に、スキルセットとタスクレベルを可視化し、メンバーごとの強みと負荷を見える状態にした上でアサインを適正化しました。これによって、能力に対して過大なタスクで詰まることや、逆に成長機会を逃すことを防ぐことができました。 - 4つ目に、顧客との調整により、若手でも着手可能な作業から段階的に進められるよう要件・スケジュールを組み替えました。顧客側にもスキル成長期にあることを共有し、長期的な信頼関係を維持しながら、メンバーが成長できる作業の流れを作りました。 これらを継続することで、チーム規模が拡大する中でも品質と納期を維持し、顧客から継続的に新規案件を受注できる関係を保つことができています。

アピール項目


アウトプット

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

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

# 今後身に付けたい技術 ## 1. LLM・生成AIの実務応用 ChatGPT や Claude をはじめとする大規模言語モデルを用いたアプリケーション開発とともに、エージェント設計、ドメイン特化のファインチューニングを身に付けたい技術です。 ユーザー体験、データの扱い方、業務フローの組み方まで含めて、生成AIを前提にしたアーキテクチャを設計できるエンジニアになりたいと考えています。プロンプト設計、ハルシネーション対策、コスト最適化、評価設計といった実務上の難所を一通り経験し、技術選定の判断軸を持てる状態を目指します。 ## 2. Infrastructure as Code(Terraform、CDK) クラウドインフラを**コードで定義し、再現可能な形で管理する技術**を本格的に身に付けたいです。 これからのシステム開発では、開発・ステージング・本番といった複数環境を素早く立ち上げ、変更を安全に反映できる仕組みが前提になると考えています。Terraform や AWS CDK のような IaC ツールを使いこなすことで、構築の再現性、変更履歴の管理、レビューを通した品質担保が実現でき、チーム開発の質が一段上がります。テックリードとしてアーキテクチャを語る上でも、IaC を素養として持っているかどうかは大きな分水嶺になると考えており、強化していきたい技術の一つです。 ## 3. AI駆動開発(Cursor、Claude Code、Copilot等) AIコーディングアシスタント(Cursor、Claude Code、GitHub Copilot 等)を活用した**新しい開発スタイル**を、個人としてもチームとしても使いこなせるようになりたい領域です。 AI駆動開発は、単に「コードを書く速度を上げる」道具ではなく、**設計・実装・レビュー・テストといった開発プロセス全体を再設計する**ものだと捉えています。プロンプトの設計力、AI に任せる範囲と人が判断する範囲の見極め、AI が生成したコードの品質保証、チームへの導入と定着——こうした観点を体系的に身に付けたいです。 テックリードとして、**AI駆動開発の知見をチームに展開し、組織全体の生産性を引き上げる**ことができるエンジニアになりたいと考えています。これからのソフトウェア開発の主流になる領域なので、早い段階で実務レベルでの判断軸を持っておきたいです。 ## 4. プロダクトの企画から実装までの一貫関与 技術スキルとは別に、**サービスやプロダクトを「上流の企画段階」から関わって、実装まで一貫して見届ける動き方**を身に付けたいと考えています。 これまではすでにある要件を実現する立場が中心でしたが、本当に良いサービスを生み出すためには、**「何を作るか」を考える段階から関わる**ことが重要だと感じています。市場や顧客の課題を捉え、技術的な実現可能性と擦り合わせながら仕様を固め、設計・実装・リリース・改善まで持っていく一連のプロセスを経験したいです。 技術選定や実装の判断は、企画意図を理解しているかどうかで質が大きく変わります。**企画と実装の両方の視点を持つテックリード**として、ビジネス側と開発側の橋渡しができる存在になることが、自分の目指す姿です。

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

## 意思決定のスピードが速い環境 階層的な承認プロセスが多すぎず、技術的な妥当性で意思決定がなされる環境を望みます。フラットな組織か、階層型であっても**判断が現場に近い位置で完結する**カルチャーであれば、自分の力を発揮しやすいと感じています。検証して良し悪しを判断し、必要なら方針を素早く修正していく動き方が、自分のスタイルに合っています。 ## 技術好きなメンバーが集まっている環境 何より重視したいのが、**技術に対する純粋な好奇心を持つメンバーが多いこと**です。新しい技術に対して「面白そう」と思える人、議論を通じて技術判断の解像度を高め合える人、お互いの強みをリスペクトしながら高め合える人——そうしたメンバーが集まる環境では、自分の成長スピードもアウトプットの質も大きく変わると実感しています。

生成AIの活用状況

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

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 責任感
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
医療・介護 / アダルト
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す / 勉強会でLTをよくする / 趣味は仕事
その他のやりたいこと・やりたくないこと

相互に刺激しあえる環境で働きたい
技術が好きな人が多い環境で働きたい

やりたい事

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

基本プロフィール

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

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

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

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