ID:82793さん

キャリアビジョン


ゲームとデータの力で,世界中の人々に感動を提供できる人材になりたい.

## 目標の背景 ### ゲームという体験の本質 私がゲームに夢中になってきた理由を突き詰めると,ゲームというコンテンツが持つ構造的な特異性に行き着きます. ゲームは,プレイヤーの多様な入力に対して,多様な出力を返します.同じゲームをプレイしても,あるプレイヤーは初めてボスを倒したときの達成感に震え,あるプレイヤーはストーリーの結末に涙を流し,あるプレイヤーは仲間と協力して難局を乗り越えた瞬間に喜びを爆発させます.その出力は怒りであることもあり,驚きであることもあり,悲しみであることさえあります. つまりゲームとは,人の感情を能動的に引き出すことができる,世界でも稀有なメディアです.映画や音楽が感動を「受け取る」体験だとすれば,ゲームは感動を「生み出す」体験です.プレイヤー自身の選択と行動が,そのまま感情の出力につながります. この構造が,世界中の人々を感動で包み込み,ひいては人々の間に共感と平和を築く一つの力になると,私は本気で信じています. ### データ・AI利活用のきっかけ 大学・大学院での研究を通じて,データには「見えないものを見えるようにする力」があることを実感しました. オクルージョン(手指が自身の手の甲によってカメラから隠れてしまう現象)下の手指座標を推定する問題に対し,深層学習モデルを設計することで5mm以内の精度で指先座標を推定できた経験から,データと数学が人間の認知の限界を超えられることを学びました.その経験が,データはゲームの世界においても,誰も気づいていない価値を掘り起こせると考えるようになりました. ## 将来挑戦したいこと ### 1. ゲームを「まだ届いていない人」に届ける ゲームに触れたことがある人はもちろん,これまでゲームとは無縁だった人,国籍や年齢や文化的背景を問わず,世界中のあらゆる人にゲームの感動が届く仕組みを作りたいと考えています. そのためにデータが果たせる役割は大きいです.どのユーザ層がどのコンテンツに触れたとき,どんな感情的反応を示すか.どのタイミングでどんなコミュニケーションを届ければ,まだゲームを知らない人がゲームの入口に立てるか.プレイヤー行動データやレビューデータは,その問いへのインサイトを持っていると考えます. 現在,趣味で取り組んでいる「Steamレビュー国別文化分析」もその延長線上にあります.多様な国籍のユーザが同じゲームの何に感動し,何に不満を感じるかを定量化することは,ゲーム体験による感動を世界中に届けるための地図を描く行為だと捉えています. ### 2. IPの力を最大化し,新しいファン層を開拓する 日本ゲームのIPは,これまでも世界中に感動を届けてきました.しかし,データの観点から見ると,まだリーチできていない層は確実に存在します. ビッグデータを扱うエンジニアとして,どの年齢層が,どの地域で,どのIPのどの体験に最も共鳴するか.データ分析によってその解像度を上げ,IPの普及戦略をより精緻に設計できる人材を目指します. ### 3. プレイヤーが気づいていない「面白さの構造」を可視化する プレイヤー自身は言語化できていなくても,行動データには面白さの痕跡が残っています.どこで何度も試行し,どこで諦め,どこで時間を忘れて没頭したか.その構造を解析することで,開発者にもプレイヤーにも見えていなかったゲームの価値を引き出せると考えます. これはゲームを「より多くの人が楽しめるもの」へと進化させる行為であり,感動の総量を世界規模で増やすことに直結します. ## まとめ ゲームは,人の多様な入力に対して多様な感情を返すコンテンツです.その構造ゆえに,ゲームは世界中の人々を感動で包み込み,共感と平和を生み出す力を持っています. 私はデータという手段を通じて,その力が届く範囲を広げたいと思っています.国籍も年齢も文化的背景も問わず,一人でも多くの人がゲームの感動に包まれる世界を,データの力で実現することが,私の人生をかけた仕事だと考えています.

プロジェクト経験

2024年/半年以内

クレジットカード延滞抑止のための課題特定と施策立案

### チーム情報 | 所属 | 人数 | 自身の役割 | |---|---|---| | サービスイノベーション部(自部署) | 3名 | **データ分析リード・施策立案** | | 債権管理部 | 3名 | ドメイン知識提供・施策レビュー | | **合計** | **6名** | | --- **【概要】** クレジットカード債権の未回収リスク削減を目的として,Snowflake上に蓄積された顧客データ・カード利用履歴を多角的に分析し,延滞発生の主要因を特定しました.さらにその課題の解決策として,リアルタイムで延滞可能性を予測する機械学習モデルをAWS SageMaker上で構築し,早期アラートによる具体的な抑止策を提案しました. **【自身が担当した実装内容】** - Snowflakeからの大規模顧客データ(利用履歴・属性・行動ログ)のSQLによる抽出・前処理 - 延滞発生との相関が高い特徴量の探索的データ分析(EDA) - 時系列での利用変化率や直近N日間の行動変化など,延滞の前兆となる動的な特徴量の設計・追加 - 機械学習モデル(LightGBM)の設計・学習・精度評価 - AWS SageMaker上でのモデル学習・推論パイプラインの構築 - SHAPを用いたモデル出力の説明可能化と,担当者が各ユーザーのリスク要因を直感的に把握できるダッシュボードの設計 - 分析結果・施策提案の意思決定者へのプレゼンテーション **【課題・問題点】** 2つの技術的課題が存在しました. 1つ目は延滞要因の複合性です.延滞者の傾向は単一要因では説明できず,「利用パターン×属性×時系列変化」の複合的な組み合わせで発生しており,単純な統計集計では本質に到達できませんでした. 2つ目はクラス不均衡問題です.延滞者のサンプル数が非延滞者に比べて大幅に少なく,単純に学習させると非延滞者に偏った予測しかできない状態でした.また,高精度であるだけでなく「なぜそのユーザーが高リスクか」を担当者が理解できる説明可能性も要件として求められました. **【打ち手・使用した技術】** 延滞要因の複合性に対しては,ドメイン知識を持つ債権管理部と密に連携し,「金融的に意味のある特徴量」を協働で設計しました.単変量分析にとどまらず,時系列での動的な特徴量を自身で考案して追加しました. クラス不均衡問題に対しては,オーバーサンプリング(SMOTE)と損失関数の重み調整を組み合わせて対応しました.説明可能性の要件に対してはSHAPを実装し,モデルの出力根拠を人間が解釈できる形で可視化しました.再現性・拡張性を担保するため,前処理からモデル推論までをパイプライン化してSageMakerに実装しました. **【成果】** 構築モデルの技術的新規性と予測精度の高さが評価され,特許出願に至りました.提案した早期アラート施策が承認され,より大規模なプロジェクトとして本格稼働が決定しました.後続フェーズは債権分析の専門部署へ移管されました.

2024年/2年以内

営業データ分析業務を自動化するAIエージェントの開発

### チーム情報 | 所属 | 人数 | 自身の役割 | |---|---|---| | サービスイノベーション部(自部署) | 18名 | **プロダクトオーナー(開発責任者)** | | 支社社員 | 12名 | ユーザー・要件提供 | | **合計** | **30名** | | --- ### 開発・実装内容A:課題特定・要件定義・開発体制の構築 **【概要】** 支社における営業データ分析業務の属人化・非効率化という課題に対し,専門知識不要で対話形式により分析から施策立案まで一貫して実行できるAIエージェントをゼロから企画・開発しました. **【自身が担当した実装内容】** - 支社ユーザーへの業務ヒアリングと課題の構造化(自身が主担当) - ビジネス要件から技術仕様への変換・要件定義書の策定 - 開発チームの体制構築(役割分担・スプリント設計) - AWS上の開発環境構築(APIGateway / Lambda / VPC / S3 / Bedrock) **【課題・問題点】** 支社側の課題は「分析が大変」という粒度でしか共有されておらず,何をシステム化すべきかが不明確でした.また,30名規模の開発体制で,ビジネス側・エンジニア側・支社側の三者間の認識を揃えることが困難でした. **【打ち手・使用した技術】** 業務フローを支社ユーザーと一緒にトレースし,「どのステップで属人化・非効率が発生しているか」を粒度細かく特定してから要件定義に入りました.認識齟齬を防ぐためにユーザーストーリーマッピングを活用し,開発優先度を三者で合意しました. **【成果】** 開発体制・要件定義・技術選定を単独でまとめ上げ,プロジェクトを立ち上げました. --- ### 開発・実装内容B:RAGアーキテクチャを活用したAIエージェント本体の実装 **【概要】** AWS Bedrockを基盤とし,営業データに対して自然言語で問い合わせ・分析・施策提案まで実行できるAIエージェントを実装しました. **【自身が担当した実装内容】** - RAGアーキテクチャの設計と実装(自身が主担当) - LLM(Claude 3.5 / GPT-4o)の性能・コスト・レイテンシの比較評価と技術選定 - Snowflakeと連携したデータ取得・前処理パイプラインの設計 - AWSサーバーレスアーキテクチャ(Lambda / APIGateway)による本番環境の構築 **【課題・問題点】** 営業担当者の質問は「先月と比べて売上が悪い店舗はどこか」のような自由記述形式であり,SQLに変換する際の意図解釈の精度が不安定でした.また,複数のLLMを比較した際に,精度・コスト・速度のトレードオフが各モデルで異なり,用途に応じた使い分けの設計が必要でした. **【打ち手・使用した技術】** - プロンプトエンジニアリングにより,曖昧な自然言語入力をSQLに変換する際の精度を改善.Few-shot例を業務ドメインに特化した形で設計し,誤変換率を大幅に削減 - Claude 3.5とGPT-4oをタスク種別(複雑な推論 vs 高速な単純応答)で使い分けるハイブリッド設計を採用 - RAGの知識ベースは営業KPIの定義・過去施策の事例・地域別特性を含む社内ドキュメントで構成し,回答の根拠を担保 **【成果】** 2025年6月にβ版をリリース.業務効率化による事業貢献額405万円を達成しました.正式版は2026年内リリース予定で,年間1,050万円相当の工数削減を見込んでいます.

2025年/1年以内

トップ営業のトークスキルを再現するAIコンサルティングアプリの開発

### チーム情報 | 所属 | 人数 | 自身の役割 | |---|---|---| | サービスイノベーション部(自部署) | 9名 | **データ分析・基盤開発** | | 九州支社 | 8名 | ドメイン知識提供・効果検証 | | 関西支社 | 1名 | ドメイン知識提供・効果検証 | | 戦略部署 | 3名 | 要件レビュー | | **合計** | **21名** | | --- ### 開発・実装内容A:トップ営業の応対データ分析と学習データの整備 **【概要】** 九州支社管轄店舗の営業担当者スキル標準化を目的として,トップ営業担当者の応対履歴と顧客データを分析し,AIエージェントの学習データを整備しました. **【自身が担当した実装内容】** - Snowflakeからの応対履歴・顧客データの抽出・クレンジング(自身が主担当) - トップ営業の成約パターンを抽出するための特徴量設計 - AIエージェントへの学習データ整備(構造化・ラベリング設計) **【課題・問題点】** 応対履歴データは自由記述形式のテキストが中心で,構造化されていない状態でした.また,「トップ営業のどの行動が成約に効いているか」を定量的に特定することが困難でした. **【打ち手・使用した技術】** - テキストデータをLLMで半自動的に構造化し,「顧客の反論パターン」「トークの切り返し種別」「提案内容」をカテゴリとして抽出 - 成約率との相関分析により,成約に寄与するトークパターンを特定してAI学習データの優先度付けに活用 **【成果】** 現地での効果検証が完了し,**本年度第3四半期に九州支社全店舗への正式導入が決定**しました. 導入効果の試算として,2025年2月25日〜3月31日(35日間)の検証期間中に約35,207件の業務処理を計測しました.1件あたり10分の工数削減を見込んだ場合,以下の通りです. ``` 35,207件 × 10分 / 60 ≒ 5,868時間(今年度貢献分) ``` 来年度(1年間)の展開後は,同様のペースで試算すると以下の見込みです. ``` 35,207件 × (365日 / 35日) × 10分 / 60 ≒ 61,290時間/年 ``` 九州支社全店舗への展開後は,**年間約61,000時間相当の工数削減**が見込まれます.

2025年/1年以内

R&D部門の技術アセットを活用した社内イベントの価値向上支援

### チーム情報 | 所属 | 人数 | 自身の役割 | |---|---|---| | サービスイノベーション部(自部署) | 3名 | **データ活用推進・技術連携** | | データ基盤部 | 3名 | データ基盤提供・連携 | | R&D戦略 技術広報部 | 4名 | アセットカタログの運営 | | **合計** | **10名** | | --- ### 開発・実装内容:R&D技術アセットのハブとしての整備と社内イベントへの展開 **【概要】** 全社的なデータ利活用の質的向上を目的とするプロジェクト「Data Marche」に参画しました.R&D部門で日々創出される技術検証の成果やデータ分析アセットを,社内イベントを主催する各事業部へ提供するハブとしての役割を担いました. **【自身が担当した実装内容】** - R&D部門内の技術検証成果・データ分析アセットの調査と集約(自身が主担当) - 各事業部との連携・ニーズヒアリングおよび提供アセットのマッチング - 社内イベントのコンテンツ企画支援(技術的な観点からのコンテンツ設計) - 技術アセットの共有と活用方法に関するコンサルティング **【課題・問題点】** R&D部門で創出される技術的成果は高品質であるものの,各事業部への横展開が進んでおらず,部署間のナレッジ格差が拡大していました.また,技術的な内容を非エンジニアの事業部担当者にとって理解しやすい形で届ける手段がなく,社内イベントのコンテンツとして活用されにくい状態でした. **【打ち手・使用した技術】** 各事業部のニーズと技術アセットのギャップを埋めるため,事業部担当者へのヒアリングを通じて「どんな課題を抱えているか」を把握した上で,対応する技術アセットを選定・提案しました.また,技術的な内容を非エンジニアでも理解・活用できる形に再編集し,イベントコンテンツとして組み込むことで,部署を問わず活用しやすい形に整備しました. **【成果】** 各イベントのコンテンツ価値を技術的な側面から高め,部署間のナレッジ格差の是正に貢献しました.全社のAI・データ活用レベルの底上げと,新たな技術活用の促進につながる仕組みを構築しました.

2025年/1年以内

MLOpsの民主化による支社の営業データ分析業務の高度化

### チーム情報 | 所属 | 人数 | 自身の役割 | |---|---|---| | サービスイノベーション部(自部署) | 4名 | **プロジェクトマネージャー兼エンジニア** | | 支社分析チーム | 3名 | 要件提供・効果検証 | | **合計** | **7名** | | --- ### 開発・実装内容A:MLOps機能の要件定義とスコープ分離の設計 **【概要】** 既存AIエージェントが対応できない高度な分析(機械学習モデルの構築・運用)を,専門知識不要で対話形式から実行できるMLOps機能として開発しました. **【自身が担当した実装内容】** - 支社の業務課題ヒアリングと分析要件の定義(自身が主担当) - AIエージェント本体からMLOps機能の開発・技術検証を切り出すアーキテクチャ上の意思決定 - プロジェクト全体の計画策定・タスク管理・進捗管理 **【課題・問題点】** 既存AIエージェントにMLOps機能を直接組み込もうとすると,システムが複雑化し品質担保が困難でした.また支社側の課題は「分析が大変」という粒度でしか共有されておらず,要件定義の起点を作ることが難しい状況でした. **【打ち手・使用した技術】** MLOps機能を独立したプロジェクトとして切り出すアーキテクチャ判断を行い,責任範囲を明確に分離しました.業務ヒアリングでは支社の実際の分析フローをトレースし,「どのステップで専門部署への依頼が発生しているか」を特定してから要件に落とし込みました. --- ### 開発・実装内容B:対話形式でMLOpsを実行できる機能の実装 **【概要】** ユーザーが自然言語で指示するだけで,機械学習モデルの学習・評価・推論をAWS SageMaker上で実行できるインターフェースを設計・実装しました. **【自身が担当した実装内容】** - 機械学習モデルの設計・評価(自身が主担当) - AWS SageMaker AIを用いた学習・推論パイプラインの構築 - 効果検証の指標設計と検証の推進 **【課題・問題点】** PM・エンジニアを兼務する体制で,特に検証フェーズに工数が集中しました. **【打ち手・使用した技術】** モデルの評価基準と効果検証の指標を要件定義の段階でチームと合意しておくことで手戻りを最小化しました.技術検証タスクは委譲できる粒度まで分解し,自身はPMとしての判断と高難度の設計に集中する役割分担を徹底しました. **【成果】** 有効性の検証を推進中.他支社への展開の中核機能として位置づけられています.

2025年/1年以内

広告審査アプリの開発と活用推進

### チーム情報 | 所属 | 人数 | 自身の役割 | |---|---|---| | サービスイノベーション部(自部署) | 3名 | **アプリ開発(技術担当)** | | 東北支社 | 4名 | 業務要件提供・効果検証 | | 四国支社 | 2名 | 同上 | | 法務部 | 2名 | 審査マニュアル提供・レビュー | | **合計** | **11名** | | --- ### 開発・実装内容A:RAGシステムを用いた広告審査アプリの開発 **【概要】** 広告掲載前のリーガルチェックにおける審査の属人化・抜け漏れを解消するため,複数の審査マニュアルを知識ベースとするRAGシステムを構築しました. **【自身が担当した実装内容】** - 業務ヒアリングによる課題特定と要件定義(自身が主担当) - RAGシステムのアーキテクチャ設計と実装 - ノーコードツール「Dify」を活用したプロトタイプ開発 - LLM(Gemini / GPT)の精度検証(回答精度・ハルシネーション率の評価) - 保守設計 **【課題・問題点】** 審査マニュアルは複数部門にわたって存在し,相互に矛盾する記述や,解釈に専門知識を要する条文が含まれていました.LLMに直接参照させると,矛盾した情報に基づく誤った審査結果を出力するケースがありました. **【打ち手・使用した技術】** - RAGの知識ベースを構築する際に,法務部と協働でマニュアルの優先順位と矛盾箇所の解決ルールを整理し,チャンク設計に反映 - LLMをGeminiとGPTで比較検証し,法的文書の読解精度・コスト・応答速度のトレードオフを評価した上で技術選定を実施 - Difyを活用することで,プロトタイプ開発のサイクルを短縮し,法務部への早期フィードバックを実現 **【成果】** プロトタイプの開発を完了し,法務部での試用検証を開始しました.現在は,主管部門が自律的にナレッジを更新・運用できる「業務の自律化」を次の目標として,権限移譲を前提とした仕様再設計を技術担当として推進中です.

2025年/1年以内

AI活用推進を目的とした社外・社内イベントの企画・運営

### チーム情報 | 所属 | 人数 | 自身の役割 | |---|---|---| | SI部(自部署) | 7名 | **イベント企画・運営リード** | | 法務部 | 3名 | コンテンツレビュー | | R&D戦略部 | 6名 | 技術コンテンツ提供 | | クロステック開発部 | 6名 | 同上 | | ブランドコミュニケーション部 | 2名 | 外部発信 | | **合計** | **24名** | | --- ### 開発・実装内容A:グループ全社向け生成AIイベント「+AI」の企画・運営 **【概要】** ドコモグループ全社の生成AIツール利用率向上と社員のスキル底上げを目的として,グループ全社向け生成AIイベントを継続的に企画・運営しました. **【自身が担当した実装内容】** - 社外担当者(Google等)との折衝・コンテンツ調整(自身が主担当) - [社外イベント(Google Cloud共催:AI PRISM)の企画・運営・外部発信](https://cloud.google.com/blog/ja/products/ai-machine-learning/google-cloud-and-ntt-docomo-group-co-host-ai-prism) - 社内イベントの企画・開催・運営 - 全社員対象の画像生成コンペティションの設計・運営 **【課題・問題点】** 多部門横断の体制で,各部署の温度感・目的・技術リテラシーに大きなばらつきがありました.「生成AIをすでに使いこなしている層」と「何から始めればいいかわからない層」が混在する中で,全社員が参加しやすいコンテンツ設計が必要でした. **【打ち手・使用した技術】** 参加者のスキルレベルを問わず入口を広げるため,「実際に手を動かして体験できる」コンテンツ(画像生成コンペティション)を軸に設計しました.審査基準を「業務への活用イメージが伝わるか」に設定することで,技術的な敷居を下げながら業務活用のイメージ醸成を同時に実現しました. **【成果】** 各イベントの参加者実績は以下の通りです. | イベント | 参加者数 | |---|---| | イベント① | 1,219名 | | イベント② | 142名 | | イベント③ | 130名 | | イベント④ | 1,113名 | 管理職対象イベントでは,以下の成果を達成しました. - **参加者:** 管理職350名を含む全体810名がリアルタイム参加 - **総合満足度:** 4.58 / 5.00 - 第一部(本音プレゼン):4.60 - 第二部(幹部×AIトーク):4.68 - 第三部(質問コーナー):4.31 - **NPS:** 49.5 - **「自身が取るべき行動のヒントが(少し以上)あった」と回答した管理職:100%** 満足度・NPSともに高水準を達成し,管理職全員が具体的な行動変容のきっかけを得たと回答しました.AI活用推進イベントとして,単なる情報発信にとどまらず,**意識・行動変容まで踏み込んだ成果**を定量的に示せた取り組みとなりました.

マネージメント能力

プロジェクト全体のスコープ・スケジュール・品質をマネジメントしていました. 具体的には,SI部4名・支社分析チーム5名からなるチームを率い,以下を一手に担っていました. - 支社の業務課題ヒアリングと分析要件の定義 - プロジェクト全体の計画策定とタスク・進捗管理 - 機械学習モデルの設計・評価・効果検証 - AIエージェント本体とMLOps機能とを切り分ける技術的意思決定
**専門知識がなくても,支社が自律的にMLOpsを実行できる状態** を作ることが責務でした. 背景として,既存のAIエージェントでは対話形式での簡単な分析しか実行できず,機械学習モデルの構築・運用といった高度な分析は依然として専門部署への依頼が必要でした.これが,各支社が自律的に業務を高度化する際の構造的な障壁になっていました. この状態を解消し,専門知識がないユーザーでも対話形式でMLOpsを実行できるプロダクトを,PM兼エンジニアとして有効性の検証まで推進する責任を負っていました.
高度な分析が専門部署に集中している構造を変えるには,技術者がいなくても機械学習パイプラインを動かせるインターフェースが必要だと判断し,対話形式でMLOpsを実行できる機能の開発を起点に設計しました. **障壁①:スコープの分離が困難だった** 既存のAIエージェントにMLOps機能を直接組み込もうとすると,システムが複雑化し,品質担保が難しくなることが判明しました.そこでAIエージェント本体からMLOps機能の開発・技術検証を切り出し,営業データ分析AIエージェントの分析機能開発を独立したプロジェクトとして進める意思決定を行いました.責任範囲を明確に切り分けることで,それぞれの品質を担保しながら並行開発できる体制を構築しました. **障壁②:支社メンバーのニーズが曖昧だった** 支社側の課題は「なんとなく分析が大変」という粒度でしか共有されておらず,何をMLOps化すべきかの要件定義が困難でした.支社の訪問や業務ヒアリングを複数回実施し,実際の分析フローを一緒にトレースすることで,「どのステップで専門部署への依頼が発生しているか」を特定しました.この解像度を上げてから要件定義に入ることで,作るべき機能の優先順位が明確になりました. **障壁③:PM・エンジニアの兼務による工数の逼迫** PMとして計画・調整を行いながら,機械学習モデルの設計・評価も自分で担う二刀流の体制は,特に検証フェーズで工数が集中しました.対応として,モデルの評価基準と効果検証の指標をあらかじめ要件定義の段階で合意しておくことで,手戻りの発生を最小化しました.また技術検証のタスクをチームメンバーに委譲できる粒度まで分解し,自分はPMとしての判断と高難度の設計に集中する役割分担を徹底しました.

アピール項目


アウトプット

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

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

### 1. ゲーム業界のドメイン知識 データ分析・機械学習の技術力は業務とコンペを通じて継続的に高めてきましたが,ゲーム事業に特化したドメイン知識はまだ発展途上だと自覚しています. ゲーム業界におけるKPIの設計思想,マネタイズモデルの構造,ユーザーライフサイクルの特性,IPの育て方といった事業理解を深めることで,技術力をゲームビジネスの文脈で正しく活かせる人材になりたいと考えています. --- ### 2. AIオーケストレーション能力 今後,多種多様なAIエージェント・LLM・特化型モデルが急速に登場し続ける時代が続くと考えています.その中で重要になるのは,個々のAIを深く使いこなすことだけでなく,それぞれの長所を組み合わせてチームや組織全体の力を底上げできる設計力です. 特定のツールに依存するのではなく,新しいAIを素早くキャッチアップし,既存のパイプラインに適切に組み込んで業務の効率化・高度化を継続できる環境を自ら整えられる人材を目指しています.

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

## あなたが一番パフォーマンスを発揮できるのはどんな環境ですか? 「ゲームが持つ感動体験を世界中に届けたい」という想いを,チーム全員が共有している環境です. 私がパフォーマンスを最大化できる理由は,ミッションへの共鳴が思考の質に直結するからです. 同じ目標を持つ仲間がいると,議論の前提を共有できるため,業務本来の目的を深く掘り下げられます.技術的な意思決定も,根本の目的意識を軸に判断可能となり,アウトプットの質が変わります. 技術力を「感動を届ける手段」として捉えている人が周囲にいると,自分のスキルの磨き方の方向性が自然と揃います.「より多くの人に感動を,届けるためには何が必要か」を一緒に考えられる環境は,私にとって最も成長が加速する場所です.

生成AIの活用状況

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

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
分析力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
SI / 金融 / 人材 / ファッション / アダルト
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと

最も貢献したいのは,多様なソフトウェアを束ねるプラットフォームそのものの設計と,そこに集まるユーザの理解です.

プラットフォームには,すでにゲームを愛しているユーザだけでなく,まだゲームと出会っていない潜在的なユーザも含まれます.プラットフォーム全体のデータを扱うことで,「どのユーザが,どのコンテンツと出会ったとき,どのような体験をしたか」を横断的に分析できます.単一タイトルの分析では見えない,ユーザとゲームの出会い方のパターンや,離脱・継続の構造が見えてきます.

その知見を活かして,より多くの人がゲームの感動と出会える導線を設計することが,私がデータの力で実現したいことの核心です.これからゲームに触れる可能性があるすべての人を視野に入れた貢献ができる場所として,プラットフォーム領域に最も強い関心を持っています.

やりたい事

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

基本プロフィール

年齢
今年で20代後半
好きなテキストエディタ
Visual Studio Code
希望勤務地
埼玉県 / 千葉県 / 東京都 / 神奈川県 / 愛知県 / 京都府 / 大阪府 / 兵庫県 / 福岡県 / その他地域 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
700万円
ご意見箱

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

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

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