ID:59651さん

2026年8月回 指名


まだ何もありません

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

  • エブリーがID:59651さんのレジュメを見ています。
    2026.09.02
  • TOKIUMがID:59651さんのレジュメを見ています。
    2026.09.01
  • RechoがID:59651さんのレジュメを見ています。
    2026.09.01
  • YOUTRUSTがID:59651さんのレジュメを見ています。
    2026.09.01
  • ハコベルがID:59651さんのレジュメを見ています。
    2026.08.31
  • FaciloがID:59651さんのレジュメを見ています。
    2026.08.31
  • アイザックがID:59651さんのレジュメを見ています。
    2026.08.30
  • TOKIUMがID:59651さんのレジュメを見ています。
    2026.08.30
  • UbieがID:59651さんのレジュメを見ています。
    2026.08.29
  • TOKIUMがID:59651さんのレジュメを見ています。
    2026.08.28

キャリアビジョン


エンジニアとユーザーの架け渡しをしたい

元々カスタマーサポート出身です。カスタマーサポートは「対応する仕事」ではなく、問題が起きる前に設計し、起きたときに組織が正しく動ける状態を作る仕事だと考えています。最近のキャリアではオペレーション設計や自分で手を動かすこともできるCREという職種に軸足を移動し、従事しております。 例えば、新製品リリース時にはQAの立場からエスカレーション経路を事前設計し、実際のインシデント発生時にシミュレーション通りに対応できた経験。不具合多発時に定性定量の不具合レポートを素早くまとめ、上司・PMを巻き込んで展開停止・ロールバックの判断を引き出した経験。こうした「事前設計×組織を動かす」という動き方は、現職のマネジメントでも一貫しています。 退職者多発によりCRE↔DevOps/SREの役割分担が空白化した局面では、RASIC表の叩き台を自ら起草し、現場の混乱を組織として解決すべき議題に格上げして合意を取りました。メジャーインシデント対応では、司令塔としてオンコールシフトに入りながら、招集通知の自動化・オーバーライド運用設計・ポストモーテム主導まで担い、事後対応ではなく事前設計でインシデントの影響を最小化する体制を構築しました。 技術選定・導入判断も担える点も強みのひとつです。現職ではClaude Codeの契約交渉から社内展開・ガバナンス設計まで一貫して主管し、IVRy(AI電話自動応答SaaS)では要件定義からセキュリティチェック申請・PoC設計までをリードしました。前職ではアウトソースベンダーの選定・契約交渉・締結・導入後のKPI管理まで一通りの調達プロセスを経験しており、「何を外部に出し、何を内製するか」の判断軸を持っています。 今後は、この「事前設計×組織合意形成×技術選定」の動き方をAIエージェントと組み合わせることで、より大きなスケールで実現したいと考えています。人が判断しなくていいオペレーションを設計し、組織の意思決定を加速させることをキャリアの中心に置いていきます。

プロジェクト経験

2025年/1年以内

EC事業のCustomer Reliability Engineer(CRE)マネージャー

## 部署 IT部 リライアビリティチーム(CRE)/ミッションコントロールセンター(全社横断組織)兼任 2026/3〜 CREマネージャー/ミッションコントロールセンターマネージャー 2025/10-2026/2 CREリードエンジニア ネット専用スーパー「Green Beans」を運営する新設会社で、社内外のユーザーのシステム利用を支えるCRE組織を担当。主にJIRAを使ったフロー整備や生成AI導入、大型障害のインシデントコマンダーやポストモーテム文化の醸成に努める。 ## 1. 問い合わせを発生させない導線の設計 ### 1-1. アカウント・権限付与の役割分離 SaaSと社内システムを横断する権限付与依頼がCREへ集中し、可否判断まで抱え込む状態にあった。権限体系と付与基準を調査し「CREは付与者ではなくトリアージ担当」と再定義、各管理者へ振り分けるフローを確立。JIRAの自動化を中心に、フロー整備や正しいフローの啓蒙活動、それに必要なデータの分析を行い、大量の異なるジャンルからの導線を正しい担当者へデリバリーできる状態を継続した。 ### 1-2. トイル削減プロジェクト 対応の速さではなく発生量そのものを削減対象と定義したプロジェクトを企画・稟議。課題棚卸から効果測定までの週次サイクルを設計し、チケット化されない隠れトイルも対象に含めた。一番効果のあった削減策として、依頼元へのツールレクチャーで月100件の依頼が発生しない体制を形成し、再アサイン(5分×月100件)等の自動化で月約65時間を削減。前月比約2倍(164件)まで増加した定型作業は依頼元自身が対応できる形へ移管し、移管後の起票はゼロとなった。 ## 2. インシデントマネジメント ID管理から、受発注システム、倉庫内出荷に関するロボット、システム、ネットワーク障害・セキュリティインシデントなどあらゆる分野の障害で重大なインシデント発生時の一次オンコーラーとして24時間365日のシフトを3名で組み、週2件前後・月10件規模に対応。 15分以内に対応チームを結成する体制を整備し、対外報告・関係者を巻き込んだポストモーテムのリードと恒久対策の実施までを担当。暗黙知だったインシデントレベルは初学者でも判断できる基準へ文書化し、テンプレートに沿えば漏れなく判断できる形へ再構築した。 ## 3. 生成AI活用推進 生成AIツールの導入担当から、AIエージェントを自ら内製して運用に載せ、IT部全体のライセンス・コスト・普及・統制までを担う範囲へ拡大した。 ### 3-1. 運用手順のAIエージェント化 社内ITヘルプデスクの定型運用を、AIエージェントが実行可能な手順として体系化。判断基準の共有マスタへの一元化・冪等設計・自動化ツールへの移管条件の事前定義を設計原則として固定した。自身で31件を作成して週次・月次の手作業を自動化する一方、命名規則とフォルダ構成の正本を整備して他メンバーが同じ型で作れる状態にし、5ヶ月で208件・作成者21名へ拡大。特定個人に依存しない体制とした。 ### 3-2. 定期巡回によるチケットトリアージ Slack常駐型のAIエージェントを構築し、月1,000件規模のタグ付け、週20件規模のアカウント申請の連携調整漏れ、期限付きタスクの期限切れを日次で巡回。人手では維持できない頻度の点検をエージェントの責務として設計した。 ### 3-3. 判断を要する領域のAIエージェントへの委譲 機械的に決まる領域は既存ルールで完結していた一方、IT部への新規リクエストは導入スコープや管理主体の判断を要するためルール化できず、経験知に依存していた。 過去90日・110件を全件分析し、判断パターンを3段階の判定フローとして辞書化。チケットの状態遷移を起点にエージェントを起動して担当を確定する経路を構築し、ルールで裁ける領域は既存の自動化に残して判断を要する領域のみを委譲することで、IT部への新規リクエストは人が介在せず担当が確定する状態とした。例外は辞書に蓄積し優先参照させ、運用するほど精度が上がる構成としている。 ### 3-4. IaC(Terraform)によるID管理と定義の保守 IT部の正社員・業務委託 約100アカウントのEntra IDをTerraformで管理。月10件規模の入退場に伴うユーザー追加は、フローをMiroとNotionで構造化して手順化し、CRE・SREとシニアマネージャーの計6名で分担できる状態に整備、Devinで半自動化した。一方、定義漏れやEntra ID側の手動追加との乖離によるエラーは切り分けに半日を要するため、担当できる要員が2名となった状況下で、自身が一次トリアージから原因特定・再定義までを担い、レビューを経て適用(apply)まで実施している。 ### 3-5. 生成AIの導入・普及とライセンスガバナンス Claude CodeのIT部導入を主管し、利用者想定の取りまとめから契約交渉まで担当。SSO確立、費用決裁と月次支払いの自動化、リスク評価とガイドライン整備など、利用者が自力では越えられない障壁を先に片付け、IT部41名中33名(80.5%)へ付与。利用実績を月次で可視化するスキルを自作し、利用者数・利用強度・キャッシュ効率・コストを追える状態を整備。利用が倍増した月もキャッシュ効率により定額プラン内に収まり、追加課金ゼロを維持。他部署からの個別ツール導入要望は、対象スコープと代替手段を提示して全社共通ツールへ誘導し、適用範囲を広げない運用とした。 ### 3-6. AI利用ガイドラインの改訂 グループ会社とガバナンスを揃えるAI利用ガイドライン改訂プロジェクトに、情報セキュリティ委員会のAIガバナンス分科会メンバーとして参画。MCP接続の実態調査とAIツールの洗い出し・プロコン整理を担当し、作成した台帳を母体データとして改訂リリースに至った。 ## 4. ピープルマネジメント 直属3名(+業務委託2名)の一次評価者。1on1は隔週で実施し、進捗管理ではなく配慮すべき状況の把握と本人のロールモデルの言語化を目的に運用。採用では書類選考と一次面接を担当し3ヶ月で約6名を面接。 判断のばらつきを抑えるため観点と配点体系を統一し、選考業務自体も生成AIでスキル化し、書類選考から採用管理システムへの記録までを1件30〜60分から約10分へ短縮。 ## 5. 【環境/ツール】 コミュニケーションツール:Slack、Teams 情報管理ツール: 編集閲覧 Microsoft 365、Notion、Miro、Jira Software、Jira Service Management 管理領域:Entra ID、Terraform、Azure、GitHub 生成AI:Devin、Copilot、Gemini、NotebookLM、Cline、Claude Code

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

2023年/1年以内

物流倉庫向け自動搬送ロボットと連携用業務アプリケーションの保守体制構築および、CSマネジメント

# 職務要約 ## 部署 2023/11〜2024/11 CS部 カスタマーサポートチーム/業務企画チーム兼任 マネージャー 物流向け自動搬送ロボット(RaaS)のカスタマーサポートおよび業務企画を担当。問い合わせ月100件規模の体制が、事業拡大により件数の倍増を見込む状況にあり、個別の対応改善ではなくサポート体制そのものの再設計に取り組んだ。問い合わせデータの構造化と傾向分析を起点に、委託先・開発・営業を横断して対応方針を決定する役割を担う。 ## 1. 問い合わせデータの構造化と対応方針の決定 不具合チケットが症状ベースでのみ記録されており、どの製品のどの領域に負荷が集中しているかを集計できない状態であったため、まずCRM(HubSpot)のプロパティ設計を改修し、症状と原因を分類軸として集計できる構造へ作り替えた。そのうえでハードウェア/ソフトウェア別・システム別に傾向分析を実施し、負荷の集中箇所を特定。ハードウェア修理の多い領域は外部委託の検討に接続し、ベンダー選定まで実施のうえハードウェア部門へ引き継ぎ。ソフトウェアかつ新規案件に集中している事象は、顧客ごとの個別改修に起因する可能性が高いと判断し、改修を担当した開発チームへエスカレーションした。 ## 2. インシデント対応方針の決定 検出したクリティカルな障害について、ユーザーへ告知するか・改修で解消するか・運用で回避するかの3つを選択肢として整理し、インシデント会議をファシリテートして方針を決定。カスタマーサポート・開発・営業にまたがる判断を1つの会議体で決着させ、対応の指針として展開した。 ### 2-1. 同種不具合の水平展開 顧客ごとの個別改修が多く、かつオンプレミス環境で稼働していたため、ある顧客で検出した不具合が他顧客に潜在したままとなる構造にあった。検出済みの事象について、適用の要否・実施タイミング・ユーザーへの告知の有無を営業を含む関係者と調整して展開方針を策定し、問い合わせが発生する前に解消する運用を設計(リリース作業は開発が担当)。 ## 3. サポート体制の再構築(コールセンターの外部委託) 1次受付から4次受付までのサポート網を、各層の稼働時間帯・雇用形態(正社員/派遣社員/業務委託/アウトソース)・担務の粒度まで分解して可視化。1次受付は24時間365日体制であるものの技術的な切り分けができず、実質的な回答を持つ2次受付は平日9〜17時のみという構造上のギャップを特定した。 当時は問い合わせ月100件を社員1名と常駐の業務委託2名で対応しており、月200件へスケールする際は常駐要員を増員する構図で、要員が入れ替わるたびに教育コストが発生するうえ、24時間365日対応にも耐えられない状態にあった。 技術的なバックボーンを持つ専門コールセンターを発掘から選定契約まで主導。 1次・2次受付を統合し、増員が教育コストに直結しない構造へ転換する方針を設計。 部長レイヤーの合意を形成したうえでCOOへ提案し、承認を獲得した。 ### 3-1. 委託形態の判断フレームの設計 選定に先立ち、インハウス(正社員/請負)とアウトソース(専任/シェアード)の4区分で委託形態を定義し、それぞれの利点と制約を整理。あわせてコア業務とノンコア業務の切り分け基準を設定し、標準化が可能な業務を委託対象とする判断軸を明文化した。稼働時間を拡大するほどコストが増大する構造も判断材料として置いた。 ### 3-2.ベンダー選定と段階的な移行 4社へのヒアリングを経て3社から見積もりを取得し、技術対応の親和性から1社を選定。移行にあたっては全体を一度に移管せず、2024年7月より1次受付のみを先行して置き換え、その運用期間をトライアルと技術教育に充てる設計とした。 ### 3-3.教育の内製化 FAQを整備したうえで研修を設計・実施。過去の問い合わせからハードウェア・ソフトウェアのユースケースを20件作成し、自身が顧客役となってランダムに出題するロールプレイを行い、対応後にフィードバックの場を設けてオペレーター10名全員に実施した。2次受付の統合時には、常駐していた既存の業務委託メンバーへ教育の役割ごと引き継ぎ、委託先内で教育が完結する状態とした。 ### 3-4. 旧体制の解約と統合 トライアル期間中に対応能力を評価して既存委託先との契約終了を判断し、交渉および関係先への説明を自ら担当。着手から約3ヶ月で2次受付の統合までを完了し、1次と2次を1社に集約したことでエスカレーションの段数が縮まり、24時間365日の技術対応を維持したまま件数の増加に耐えられる体制へ移行した。運用開始後は課題を洗い出しながら委譲範囲を段階的に拡大した。 ## 4. 受電オペレーションの平準化と属人化の解消(クラウドPBXの導入) 従来は貸与した社用携帯への直接架電で受電しており、シフト制であるにもかかわらず担当交代時の引き継ぎが成立せず、休暇中のメンバーへ直接電話が入る状態が発生していた。 メンバーの負荷の偏りを懸念する声も上がり分析。 hubspotのチケットを分析するとメンバー間で受電数に偏りがあり、最も多く受けていたのがリーダーである社員であることが判明した。 ただ詳しく分析していくと、①古参の顧客はリーダーが受けている。理由としては電話番号自体が知られている②新規ユーザーはリーダーは取れていない と負担の構造が単なる受電率では異なることがわかった。 シフトの引き継ぎ、メンバー負荷の偏り解消、この2つの課題を解消するために導入を提案し推進した。 ### 4-1.クラウドPBXの導入を推進 候補10社から資料請求により5社へ絞り、必要条件をマトリクスで比較したうえで2社をデモ環境で評価し、オペレーターと協働して性能を検証して選定した。 着信のラウンドロビン配分を設定した結果、受電比率は3:4:3へ是正され、リーダーは生まれた余力を業務委託メンバーからのエスカレーション対応に充てられる状態となった。 あわせて全員が同条件で受電する状態となったことで受電率を横並びで集計できるようになり、負荷配分を調整する根拠として提示した。 ### 4-2. チーム運営 立ち上げ途上のチームに対し、FAQのNotionへの移行、コールセンターKPIの再設定、新人受け入れ手順の整備、チーム会議のファシリテーションを担当。また、新プロダクトのタスクフォースにカスタマーサポートの代表として推薦され(2024年4月)、導入後サポートのオペレーション設計とユーザー向けマニュアルの再構成を担当した。 ## 5. 【環境/ツール】 コミュニケーションツール:Teams 情報管理ツール: 編集閲覧 Microsoft 365、Notion、kintone、HubSpot、Miro 閲覧中心 Jira Software、GitHub、MySQL、nginx

2022年/2年以内

電子おくすり手帳harmoリニューアル立ち上げ

# 職務要約 ## 部署 CS&OP部 2022/5〜2023/10 harmo株式会社(100%出向)に在籍し、2019年6月にソニー株式会社より承継した電子おくすり手帳「harmo」の全面リニューアルに伴う、カスタマーサポートおよびオペレーション(コールセンターとオンサイトはアウトソーシング)の構築業務を担当。 ## 1. カスタマーサポート業務 ソニーより継承した電子おくすり手帳システム(薬局にタブレットを設置し、ネットワークを通してクラウドのデータベースと連携するシステム)のサポート体制のオペレーション構築、ヘルプデスクの管理。 問い合わせは月200件程度 - ヘルプデスクのエスカレーション対応(月30件程度) - ヘルプデスクのFAQ作成 - 運用フローの検討 - 問い合わせ分析業務(月次) ## 2. 全国約1,000店舗を対象としたシステム入替プロジェクト(オペレーション設計・ベンダーコントロール) ソニー製の電子おくすり手帳を自社製品へ全面リニューアルに伴う全国規模のシステム入替を担当。 導入ベンダー1社と契約し、地域ごとに再委託先を切り替える体制を設計。 既存の導入対象700社からagreementを取得する際、同意取得フォームに現行の機器構成・導入希望時期・必要台数のヒアリングを組み込み、個別ヒアリングを発生させることなく導入スケジュール設計の基礎データとして活用。 ソフトウェア開発のリリース時期の遅延に伴い、導入計画を3度組み替え。 ### 2-1. 導入不成立の原因特定と手順の標準化 主要レセプトコンピュータを使用する薬局を訪問し、連携可否を実地で調査。 Windows 7/8環境では動作しない構成であることを特定して導入対象を再設定。 さらに特定1社以外のレセプトコンピュータでは調剤情報の連携が成立しないことを突き止め、調査結果を根拠に開発へ再調査を依頼し、実装の大幅なリファクタリングにつなげた。 検証済みのケースはパターン化し、フィールドエンジニア向けの手順書として配布。 ### 2-2.データを根拠とした導入停止の意思決定 2023年6〜8月に200店舗へ着手したが、導入成功率は約50%にとどまる。 事前に計画の見直しを進言したものの事業継続の存続可否と天秤の上、着手継続と判断されたため、実績値をもとに残り約500店舗へ同条件で展開した場合の失敗件数・再訪問件数・所要リソースおよびユーザーへの影響を定量化。 社内の交渉窓口である部長と連携しつつ、自身もCEOへ直接データを提示し、一度は導入継続として判断された状態を会社として導入を一時停止する意思決定に至った。 あわせて開発への改修依頼と導入スケジュールの再設計を実施。 ### 2-3. 導入ベンダーのマネジメント スケジュール変更が重なるなかで委託先の実働キャパシティが縮小した局面では、地域別の人員配置から主要レセプトコンピュータ3社への対応順を軸とした段取りへ計画を組み替え、導入を継続。 社内でエスカレーション対応チーム(4名)を組成し、対応手順と情報集約のオペレーションを構築。集中的なトライアンドエラーにより早期不具合の発見、後のコールセンター移管のナレッジを構築。 ### 2-4.ドキュメント・ツールの整備 入替手順書はNotionに集約し、フローはMiro、Notion上はMermaidで可視化。外部公開向けFAQサイトはZendesk・Helpfeelを比較検討のうえ、構築・委譲コストの低さからwikipyを採用。 ## 3. リリース品質の担保(QAプロジェクト) QA専任者が不在の状況でQAをプロジェクト化する方針となり、リリースが遅延し、オペレーションも後ろ倒しになることから、期間限定で兼任メンバーとして自ら参画(4名体制)。 前職の経験を活かし、QAリーダーとマインドマップでテストシナリオを設計し約1,000項目を洗い出したうえで、検証の実行は外注メンバーへ委譲。 自身は現行システムと新システムの差分という最もリスクの高い領域に注力する体制とした。 結果、現行システムに存在する工程が新システムで欠落している事象を多数検出し、リリースを遅らせてでも修正するという意思決定につながった。 ## 4. 【環境/ツール】 コミュニケーションツール:Slack、Teams 情報管理ツール: 編集閲覧 Microsoft 365、Notion、kintone、Salesforce、Box、Miro 閲覧中心 Jira Software

2021年/1年以内

家庭用ロボットのテクニカルサポート

# 職務概要 ## 部署 2021/6〜2022/4 テクニカルサポート(市場QA担当) 家族型ロボット「LOVOT」のテクニカルサポート(市場QA担当)として、ヘルプデスクで回答できなかった問い合わせに対する遠隔での障害切り分けと分析を担当。月約900件のチケットを、業務委託2名を含む3名体制で処理。 ## 市場不具合の傾向分析と予兆の検知 修理データとコールセンターデータを変換して解析工程のトレンドグラフを作成し、月次の不具合傾向を分析。 ハードウェアの設計変更やソフトウェアアップデートのタイミングで不具合が増加する傾向を事前に予測し、全体への波及を防ぐため各部署と連携。 VOC会議では顧客対応方針を議論し、温度感の高い顧客には訪問ヒアリングまで実施して障害解決へ接続。増加傾向の問い合わせへの対策や、未確定だったアフターサービスの運用方針もこの場で決着。 ## 属人化しないナレッジの整備 未知の不具合が多い次世代製品であったため、社内マニュアルを整備。Grafanaの参照方法や「仕様か不具合か」の判定基準まで明記し、自分以外が担当してもチケットを処理できる状態を作る(記事数1,500超)。 ## 遠隔での障害解析 Grafanaでロボットの挙動を遠隔モニタリングしてハードウェア故障を解析。連携スマートフォンアプリはログを取得して障害発生時の事象を推定し、ハードウェア起因はリペアセンターへ障害箇所を指示、ソフトウェア起因は仕様を確認して回答を作成。

2013年/2年以上

画像処理検査装置のテクニカルサポート

# 職務要約 ## 部署 2013/5〜2019/9 CS本部 カスタマーサポート部 業界トップシェアの画像処理検査装置メーカーにてカスタマーサポート業務を幅広く行っており、主に製品のハードウェアのテクニカルサポートに従事(PC本体、CMOSカメラ、レンズおよびLED照明)。 日々の業務の経験と知識から品質の評価や不具合集計、次世代製品の企画なども協力した経験がある。 特に修理部材の調達、価格調査や海外拠点のサポート体制の見直しや強化のプロジェクトの中心にも選ばれ、海外支社のCS本部立ち上げに貢献。 ## 品質評価と製造委託先への是正交渉 突発的な不具合は開発とタッグを組んで原因を調査。重大な不具合については海外(台湾)の製造工場へ自ら出向き、自作の分析レポートをもとに設計不良・ロット不良の原因を提示して対策を交渉し、採用に至る。 交渉の過程で他の取引先でも同傾向の障害が発生している事実を引き出し、代替部品の無償提供と無償保証期間の2年延長を取り付け、約400万円相当の修理費用を回避。市場流出も最小限に抑制。 ## 修理・分析/テクニカルサポート アプリケーション/OS/ハードウェアの層で不具合を切り分け、ソフトウェア起因は自社開発へフィードバック、ハードウェア起因は画像処理コントローラの修理・キッティングを実施。 部品単位の不具合はPCベンダーへ英文の調査報告書を作成してエスカレーションし、回答を得るまで交渉。 機種別の不具合を毎週統計して突出した案件を特定し、調査のリードタイムを2年間で60日から20日へ短縮。 ## 海外拠点サポート 中国・タイの拠点と月1回のオンライン会議を実施して問題点をヒアリングし、在住日本人スタッフへの最新情報提供をリード。海外事業所への出張と英文メール対応も担当。

マネージメント能力

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

アピール項目


アウトプット

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

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

agenticAIを活用し、定型作業はどんどん型化し、コア業務に時間をかけられるような組織を作りたいと思っております。

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

ユーザーの課題解決のために、色々な部署が協力して、渦中に飛び込みながらお互いを尊敬しあい問題を解決するチームであったり会社。

生成AIの活用状況

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

キャラクター

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

やりたい事

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

基本プロフィール

年齢
今年で30代後半
好きなテキストエディタ
VS code
希望勤務地
千葉県 / 東京都 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
750万円
ご意見箱

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

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

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