tkg216

自己推薦一覧

自己推薦はありません

3年後の目標や野望


ARR100億円規模のサービス生み出すチームのリードエンジニア、AWS Top Engineer

大目標: 世の中を良くするプロダクトを作る なるべく多くの人に良い影響を与えたいので100億/年規模に育てたい。自分がこれを作った、この課題を解決したと胸を張って言えることや子供に言えるようになりたい。 その中で自分の関わり方としては、プロダクト開発を推進できる立場でありたい。具体的には、クラウドアーキテクチャが得意なフルサイクルエンジニアとして幅広く貢献したい。

年収評価シート

2023年/1年以内

エンペイでのSREプロジェクト

## プロジェクト概要 進行中のプロジェクトで、2023/10よりSREチームが発足しセキュリティ分野に注力する計画中です。 エンジニアの中でSRE専任ロールは自分1人という状況で3プロダクトに対してのSREとしての様々な取り組みをしていく。 # アーキテクチャ改善 【課題】 - ECSの同一タスクにサービス本体とAdminが同居していることで耐障害性が低い - インフラ構成の変更を試す環境がない、試す方法が確立されていないので問題が放置されていた 【解決策・工夫点】 - ECSサービスの単位で分離 - 新規AWSアカウントを払い出し、検証用環境を構築し、自由に検証できるようにした 【成果】 - 狙い通り分離することによって耐障害性を高めることができた - 検証しやすい環境の構築を通してブラックボックス化されていたデプロイの仕組みを1から理解することができ、社内展開した - その検証環境が後にインフラ領域にチャレンジするメンバーが活用することができた # オブザーバビリティ向上・可用性向上 【課題】 - Datadogを入れたけど使っていない - デバッグの方法が非効率かつ且つ属人化している 【解決策・工夫点】 - 実際のデバッグ時の方法について開発者にヒアリングを実施し、実際のデバッグシーンを見せてもらうことで業務理解を深めることに努めた - RUM→APM→Logが紐づいていなかったので紐づけることでツールや機能の行き来する負荷を減らすようにして、エンジニアに対してデモを実施 - RUMのセッションリプレイやResourcesの表示などでデバッグのしやすい環境を構築 【成果】 - 使っていなかった機能のメリットを理解してもらえて効率改善を体感してもらえた - 監視・モニタリングツールの統一や選定する課題が先送りされていたが前進した # コスト最適化 【課題】 - これまで副業の業務委託の人に対するクラウドインフラ領域の依存度が高かったため、コスト最適化があまり進んでいなかった - スタートアップであること、円安であることからなるべくコスト削減をしたい - 他のSRE領域もあるためコスト最適化に長期間時間をかけられない 【解決策・工夫点】 - クイックウィンである範囲を一旦の活動のゴールとすることに設定 - コスト構造を把握するために、AWSではCostExplorer、Datadogでは契約内容の見直しから着手 - 書籍にあるような基本的な対策、他社事例などを積極的に採用 - 当初は会社の中で1番大きなプロダクトが対象だったが、他チームのエンジニアと連携しながら横展開も並行して進めた 【成果】 - Datadogで大きなコストロスをしている契約内容を検知して是正した - AWSでは、Googleカレンダーと連携したサーバーやDBのスケジュール停止の機構を導入することや、不要リソースの削除、RI/SPの導入、FARGATE SPOTの導入、ARM化などを実施 - 合計として$3500(約30%)ほどの節約効果を実現 - 既存のインフラ構成への理解が高まったこととプロダクトチームメンバーと協力して進めることでプロダクト開発者のインフラへの理解度が高まった - クイックウィンとしての施策は一旦、時期を区切ったが継続的に打てる施策を情報収集しながら日々試算や実践する習慣がついた # その他 - AWS全体 - 権限管理: 全員Administratorだった状況に対してチーム構成に沿った権限構成へ変更 - CloudTrailやGuardDuty、AWS ConfigなどのサービスをOrganizationsレベルで設定 - enpayプロダクトへのSRE活動 - サービス本体コンテナとAdminコンテナをECSサービス単位で分離することで可用性の向上 - AWSリソースのアラートを設定しメモリ不足などに事前に気づける最低限の整備 - CDKV1のEOL対応 - WAFのログ設定 - デプロイフローのドキュメント化とSWEへのレクチャー - ログのフォーマット改善 - SytemAlertsの整備 - モニタリングダッシュボードの整備 - SLO策定 - redashサーバーの共通化 - 各プロダクト・各環境ごとにredashサーバー(ECS+RDS)を構成していたものを、共通redash化してPrivateLink経由で各DBに接続する構成に変更することでコストの削減とURLの統一による利便性向上に貢献した

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

2023年/半年以内

enpayウォレット開発

## プロジェクト概要 - 目的: オートチャージ機能、支払い機能を備えたモバイルアプリの新規立ち上げ - 自分の役割: エンペイJoin直後にSREとして参画 - チーム構成: PdM1名、モバイルアプリエンジニア2名、バックエンドエンジニア2名、自分 【課題】 - 入社直後のプロジェクトで周りからの信頼を得る必要がある - 同時にインフラ領域に挑戦したい若手エンジニアの教育・フォローをする必要がある - 自分の慣れていないECSサービスでインフラ構築する 【解決策・工夫点】 - まずは、自分の経験や実績の多い領域から着手し、信頼を高めることコミュニケーションの円滑化に努めた - 入社前後に既存プロダクトのインフラ・CI/CDパイプラインの構成をキャッチアップする機会があり、その際に課題を洗い出し、その結果を踏まえGitHubFlowのCI/CDパイプラインを提案 - 若手教育の観点では中規模なマイルストーンを設定し、細かいコミュニケーションを取りつつ、進めた。一方でプロダクトとしてもスピード感を持ってローンチまで辿り着きたいところがあったため、バックエンド開発に必要なStaging環境構築などの開発全体で高い優先度のものに遅れが出ないよう優先度決めを行なった。逆にCI/CDパイプラインとして一旦デプロイができる状態にしてからB/Gデプロイメントへの移行などを腰を据えて行うことにした。 【成果】 - 開発の早い時期にCI/CDパイプラインを構築したことでリリース後の開発プロセスを意識しながら開発に取り組むことができた。そのことで、開発期間中にCI/CDパイプラインへのフィードバックを反映させながらプロジェクトを進めることができ、リリース後数ヶ月経過してもCI/CDパイプライン周りで問題が発生していない - マルチプロダクトで1人SREという会社の状況で、CDKなどのIaCをみえる人材が不足していたが、若手エンジニアの努力もあり、社内でAWSやCDKに知見を持ったエンジニア数が増え組織編成の際の柔軟度を高めることができた - 自分自身、サーバーレスのLambdaを使う経験が多かったが、コンテナオーケストレーションサービスのECSについて知識とスキルを得ることができた。

2021年/2年以内

NAONA

## NAONAとは コミュニケーション可視化のプラットフォームです。オンライン/オフラインのどちらのコミュニケーションにも対応していて、コミュニケーションデータの解析・蓄積やアプリケーションを作成するための要素を提供しています。NAONAプラットフォーム上で、1on1やグループディスカッションなどのアプリケーションを開発しています。 ## プラットフォーム拡張(管理画面とREST API開発) 【課題】 - (プロダクト) プラットフォームの管理画面でCRUD操作できないデータがあり運用負荷が高かった - (プロダクト) アプリケーションが使う機能として利用所許諾機能を追加開発する必要があった - (プロジェクト)入社直後の既存システムの理解度が低い状態で協業先の業務委託メンバーと開発を推進する 【解決策】 - スクラムに入る前のオンボーディング期間でプロトタイピングをしながら構成をキャッチアップし、これまでの工数見積もりよりも精度が高く、スピードのある開発サイクルを実現することができた。 - 実際には、オンボーディングとしてAPIを実行したりゆっくりと検証することをする期間として与えられていたが、プロトタイピングの提案を行い、スクラムに想定よりも早く入ることを提案した。 【成果】 - 予定工数の2/3程でリリースまで完了することができた。 - オペレーションの運用コストを1/3程に短縮 ## PoCアプリ: 面接練習アプリの開発 NAONAを面接練習に使えないか検証するためのWebアプリケーションを実装。Nuxt.js/TypeScript, Amplifyで構築。アプリケーションの機能としては、面接練習を開始すると、問題が表示され、マイクを使って回答すると回答内容についてのフィードバックが得られるもの。言い淀みや話速などの指標で回答が上手く行えているか練習生が振り返りに使うことができる。PoCアプリのフィードバックを得るため、転職時に親交を深めたエージェントの方にフィードバックをもらえるようにアポイントを取ることや営業に同行しながらヒアリング・機能検討を進めた。 ## PubSubAPIの構築 【課題】 - アプリケーションのユーザーが操作したことを他のユーザーの画面に反映させたい機能要望 - 必要な機能ではあるが実装コストが高い場合を危惧してなかなか優先度が上がらなかった 【解決策】 - AWSのAppSyncをキャッチアップしGraphQL Subscription機能を使えば実現できることを自力で調査 - AWS SAとの打ち合わせを設定し他の実現方法も含めてチームメンバーおよびAWS SAと議論の場を設けた - API GatewayのWebSocket方式をAWS SAからは勧められたが自分の検証結果を鑑みると開発工数などは低いためAppSyncを採用することを提案 - プロトタイプを作り社内で採用実績のなかったGraphQLとAppSyncの勉強会を実施 - 新技術の提案・導入だけで終わらないように、フロントエンドの実装例などもドキュメント化 【成果】 - 短期間でGraphQL Subscription機能を使えるAPIを構築することができた - 要望の上がった背景の機能以外の機能でも使われる汎用的なAPIとなった - フロントエンドで機能実装する際に低い工数で問題なく導入することができた →こちらをテーマにJAWS DAYS 2022 PREEVENTで登壇 ## ブラットフォーム(CI/CDパイプラインの刷新) 【課題】 - 外部ベンダーが構築したJenkins製CI/CDパイプラインを内製化・エンハンスできない - 社内外にJenkinsに対する知見を持ったエンジニアがいない - 既存のリリースフロー、パイプライン構成ではリリースに時間がかかる 【解決策】 - AWS CodePipelineをベースにしたGitHub Flowベースのパイプラインに刷新を提案 - 継続デリバリーやThe Twelve-Factor Appのベストプラクティスに則ったCI/CDを設計 - 移行用の検証環境を用意して移行のリハーサルまで実行することでパイプライン移行実施時に起こり得るトラブルを洗い出してから移行本番に臨むようにプロジェクトを推進 【成果】 - 目立ったトラブルが発生することなくCI/CDパイプラインの移行に成功 - リリースにかかる工数が大きく短縮 - リリース頻度が上がり、リリースへの安心感が向上 - 別モジュールのCI/CDパイプラインでも同じ構成を採用することに繋がり社内にノウハウが溜まった ### プラットフォーム(監視の仕組み刷新) CloudPackに依存していた監視の仕組みをCloudWatch MetricsやSNSなどのAWSサービスをベースとしたSlack/Backlog通知をする監視基盤に刷新 ## 内製Web会議開発 【課題】 - 既製品のWeb会議アプリで内蔵スピーカーを使うユーザーの音声をNAONAアプリケーションで音声を解析しようとすると他者音声と区別がつかないため、精度が著しく低下する課題があり、その影響でディスカッションの評価制度に影響を与えていた 【解決策】 - 粘り強くWebRTC関連のSDKの調査や技術調査を行い、同じブラウザ内であればWebRTCを使ったWeb会議の音声と内蔵スピーカーが拾う音声を分離して解析できることを突き止めた - ブラウザ版Web会議アプリを内製化する開発工数とライセンス費用がネックになっていたが、Amazon Chime SDKを使うことで簡単にデモアプリを作成し初期費用なく利用できることを調査で明らかにして社内で共有した - Amazon Chime SDKを有効に活用するためには社内で利用実績のなかったReactを使う必要があったがチャレンジすることを提案した - チームメンバーのマネジメントとReact/ChimeSDKのノウハウ伝授をしながら開発を進める 【成果】 - 音声解析精度が上がり、サービスを展開する上で重要な顧客との提携が大幅に前進した - ChimeSDK、React、API(APIGateway+Lambda+DynamoDB)、EventBridgeなどのスキルを高めることができた ## その他 ### Slackでのオープンコミュニティ促進 チームにジョインした当初、Slackは導入されていたがDMやプライベートチャンネルがメインで使用されていた。自分自身も新しく参画した立場で少しやりにくさを感じたのと、今後、より深い議論をオープンにしていくことが必要だと感じたため、パブリックチャンネルをメインにした運用へ変更を決定した。協力的な姿勢で取り組んでいただけ、リモートワークがしやすくなったという声などをいただけた。 ### 開発勉強会としてのセキュリティ勉強会を開催 セキュリティ対策を全くできていないわけではなかったが、開発、チームとしてここまで出来てるからOK、あとはここはやらなければいけない、のような具体的なものを自分、チームが持てていなかったのを課題に感じ、企画、提案、実施中。 ### EM役割 開発マネージャーが異動となり、明確なマネージャーが不在となり、自分が開発マネージャーとしてやるべき動きをやることが増えるようになった。例えば、メンバーとの1on1(明確なポジションではないので完全な定期開催というより個々人と話す機会を増やしながら進めた)や、開発全体でのKPTなどを開催し、タスクとして落とし込みなどを行なった。

2018年/2年以内

アプリ個人開発(iOS, webアプリ)

# 概要 プライベートで友人と2人でiOSアプリを2作開発・リリース、webアプリケーションを1つ開発しました。 # 背景 元々エンジニアでなかった友人と、アプリ開発経験のなかった自分の2人で、本業でなかなか新しいサービスを開発できない歯痒い想い共有し、個人活動で晴らしたいという想いで、意気投合し、モバイルアプリとwebアプリケーションを開発しようと取り組み始めました。 # 苦労した点 ### (1) アイデア出し、要件仕様検討 「世の中に役立つアプリを作る」という目標の元、どんなアプリを作るか検討を重ねました。思いついたアイデアが既に実現されていたり、アイデア出しに時間が取られてなかなか開発までいけないなど苦労しました。 その中で、 ・アイデアフレームをアプリで実現するFastIdeaというマンダラチャートとしりとり法が使えるアプリ(iOS) ・スポーツチームとスポーツをしたい人をマッチングするTipOffというアプリ(iOS) ・技術書に特化した技術書レビューサイト(web) の2つのアプリを開発しました。 ### (2) 未経験のアプリ開発をスピード感を持って実施すること  2人ともモバイルアプリについて素人でしたが、半年間で2作リリースしようと目標を立て、開発を行いました。iOSの基礎から学習し始め、休みの日に、お互いの家で開発作業をしたり、カフェで話し合いを繰り返したりしながら、技術習得、開発を進めていきました。  モバイルアプリやクラウドの知識習得や、CircleCIやGitHubなどのツールの導入も積極的に行いました。その結果、新しい技術に触れることや、全行程について考えることの楽しさと難しさを経験することができました。

2016年/2年以上

beatサービス開発(富士ゼロックス)

# リモートアクセスサービスの機能拡張 【プロジェクト概要】 リモートアクセスサービス機能の負荷分散を実現する機能拡張プロジェクトでプロジェクトリーダーとして担当。 【担当フェーズ】 技術調査、基本設計、詳細設計、実装、テスト 【担当業務】 ・メンバーの立ち上げ ・調査内容の取りまとめ、精査 ・業務内容のアサイン ・アーキテクトレビュー 【実績・取り組み】 ### メンバーの立ち上げ 自分以外のメンバーは新規の業務委託メンバーだったため、既存のサービスに対する理解がなく、メンバーの立ち上げから行う必要がありました。プロジェクトリーダーとして、作業内容を伝えるだけでなく、背景や目的を理解してもらうよう務めるように心がけたことで、メンバーからの提案なども行われ、QCDを達成することができた。 ### アーキテクチャ決定 リモートアクセスサービスの負荷分散を実現するためには、仲介サーバーとUTMサーバーが上手く連携し、割り振り方法の決定、IPアドレス付与方法の決定などの課題があり、これらは未調査のものであった。 それらの方式を決定するために、各課題に対して、複数アイデアを出し、実現性やコスト、メンテナンス性などの観点からQOCで比較し、最適なアーキテクチャーを検討し、グループ内のアーキテクトチームのレビューを重ねることでアーキテクチャを決定することができた。 ### 性能測定ツールの作成 大量のクライアントが同時にアクセスするケースをテストする手段が、端末を大量に動作させることは難しく、今までツールが存在していなかった。 負荷分散の実現を確認するためにも性能測定ツールは必須だと感じ、提案・開発いたしました。今までプロジェクトに導入実績のなかったterraform, Docker, GCP, Ansibleを組み合わせることで実現できることを自ら、考案し、導入提案、ツール開発を行いました。技術を選定した背景は、大量のインスタンスを同時や順次コントロールする必要があったため、クラウド上で大量のインスタンスをTerraformで作成し、Ansibleで操作することで解決できるのではないかと考え、導入した。TerraformやAnsibleは知らなかったツールでしたが、業務外活動(Hardening)で情報を得ることができたもので、その知識を業務にフィードバックすることができた。

2020年/1年以内

みまもりサービス開発(Novars Inc.)

# 法人向けみまもりサービス業務アプリの開発 【プロジェクト概要】 介護事業社等がwebアプリケーション上で、高齢者をみまもる新規サービスの開発 【担当フェーズ】 要件定義、画面設計、基本設計、詳細設計、実装、テスト 【実績・取り組み】 開発メンバーが社内に不足しているため、オフショアを活用した開発を推進しました。 中でも、業務でwebアプリケーションを1から作る経験は初めてだったが、XDを使った画面設計や要件定義などの上流工程から取り組みました。XDを使ったワイヤーフレーム を用いて、事業開発グループ側と折衝することや画面の詳細設計をする新しい経験など慣れない点もあり苦労しましたが、ユーザー視点やビジネス視点を持つことの大切さを学ぶことができたと思います。 全体の設計としては、運用コストを抑えることのできるサーバーレスアーキテクチャーを採用しました。基本的には、フロントエンドにVue.jsを採用しシングルページアプリケーションを構築し、APIと分離することでオフショアを使った開発をしやすいようにした。さらに、1つのシングルページアプリケーションで構成するのでなく、管理画面とアプリ画面(みまもり電池連携機能)とログイン画面を別のVue.jsで構成し、cloudfrontのbehaviorに登録する設計を採用することにした。このことによって、サービスイン時は、みまもり電池連携機能のみを持つアプリケーションだが、別のアプリケーションとの連携機能を持たせたくなった場合に、アプリ部分のVue.jsのプロジェクトを差し替え、追加することだけで実現ができるアーキテクチャーを採用した。 また、複数のVue.jsやAPIを手動で複数環境(dev, stg, prod)にデプロイするのは、手間でもあり、ミスが発生しやすいのでデプロイパイプラインの導入を検討した。レポジトリには、GitLabを使っていたので、複数のCodeCommitに対して、ミラーリングができず、複数環境にデプロイパイプラインの構築ができないという課題があった。設定値のレポジトリとアプリのレポジトリは分離し、アプリのレポジトリは、GitLabからGithubにミラーリングし、CodepipelineとCodecommitを用いることで、複数環境へのデプロイパイプラインの構築をした。

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

2022年/1年以内

SmileForceでのAWS関連のアドバイザリー/SRE

・AWSに関するアドバイザリー ・アーキテクチャ選定 ・CDKを使ったインフラ構築およびCI/CD Pipelineの構築をし、プロパーへのレクチャーを実施 ・Cognito、WAF、ControlTower等の導入

マネージメント能力

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

村田製作所でのNAONAサービスのWeb会議アプリの開発マネジメント、チームマネジメント
内製Web会議アプリのアーキテクチャに関して決定する責務、開発タスクについてタスクの定義/管理をする責務、開発メンバーが開発しやすくするようにする責務、開発チーム全体から課題を抽出する責務。
まずは、コミュニケーション面でSlackを導入していたがプライベートな運用をされていたのでパブリックに議論できるように働きかけを行った。他社での事例や自分の経験を交えてパブリックにする目的などを説明するように心がけた。 アーキテクチャ決定や開発を前進させるところについては、自分自身が責任感を持って推進することは基本としながら、困った際にはメンバーや周りの人に意見を聞きながら合意を得ることを心がけた。広い知見を取り入れられると共にメンバーの納得感の向上にも繋がったと思う。また、自分自身もメンバーの管理だけではなくプレイヤーとしたら開発を進める中での進め方としてボトルネックにならないタスクを持ちながら進めることを意識した。一方で技術調査を任せることで上手く進まないことがあったりしながらも、自分がまとまった時間を確保して調査できない難しさを抱える場面はいくつかあった。 組織を運営する上では元々開発マネージャーが在籍していた時期はチーム全体でのKPTなどは行えたいたが、個々の課題感を拾えていないところがあったため、隙間で雑談のようにヒアリングすることや1on1を明確に時間として設けるなどして各メンバーとの対話の時間を増やした。また、アジャイル開発+各スプリントでの振り返りは行えていたが、広い時間軸での課題の抽出ができていない、開発チームだけのKPTが行えていなかったので、開発チーム全体での広い観点でのKPTを開催し、課題に落とし込んだ。この辺りを進める上で自分自身は明確なマネージャーではないところがあったので、遠慮はしないながらも、出過ぎないように同じ視点で議論できるようにすることを心がけた。

アピール項目


アウトプット

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

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

・データ基盤やデータ活用周りの知見 ・セキュリティ関連をリーディングできる知見

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

* 会社・組織の方針が明確 * 開発チームと事業開発チームなどその他チームとのコミュニケーションが円滑 * 1人で集中できる空間がある

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
風通しの良さや意思決定ライン
やりたくない分野
SI / 広告 / ゲーム / アダルト / 仮想通貨
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと

AWS Community BuildersにServerless部門で選出された通りサーバーレスに関することやクラウドアーキテクチャ領域への関心が高いですが、信頼性やデータ基盤など周辺の技術にも関わり良いサービスを作りたいです。

プロダクトと組織がたまに成長していくフェーズに貢献していきたい。

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きな Text Editor
visual studio code
希望勤務地
東京都 / 神奈川県 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
780万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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