Yui

自己推薦一覧

自己推薦はありません

2021年4月回 指名 (未返答 : 0/24件)


1位指名
MICIN
リモート可(週3日以上)
正社員
スター
承諾
AppBrew
リモート可(週4日以上)
正社員
プチリッチ
承諾
オープンエイト
リモート可(週4日以上)
正社員
プチリッチ
承諾
サイバーエージェント
(メディア統括本部)
正社員
スター
承諾
HRBrain
リモート可(週4日以上)
正社員
プチリッチ +変動残業代 
承諾
BASE
正社員
プチリッチ +変動残業代 
承諾
スマートキャンプ
リモート可(週4日以上)
正社員
プチリッチ
承諾
プレイド
提示金額100%保証
正社員
スター
承諾
マネーフォワード
リモート可(週3日以上)
正社員
プチリッチ
承諾
Sansan
正社員
プチリッチ
承諾
freee
正社員
プチリッチ
承諾
SEQSENSE
正社員
スター
承諾
MIXI
リモート可(週4日以上)
正社員
プチリッチ
承諾
ルーデル
正社員
プチリッチ
承諾
1位指名
WAmazing
リモート可(週4日以上)
正社員
スター
承諾
ラクスル
リモート可(週4日以上)
正社員
ノーマル
承諾
OLTA
正社員
プチリッチ
辞退
Gunosy
リモート可(週4日以上)
正社員
プチリッチ
辞退
Speee
正社員
ノーマル
辞退
ROXX
リモート可(週4日以上)
正社員
プチリッチ
辞退
VideoTouch
リモート可(週4日以上)
正社員
プチリッチ
業務委託
プチリッチ級/月(税抜)
辞退
1位指名
Showcase Gig
リモート可(週4日以上)
正社員
プチリッチ
辞退
Opn
リモート可(週4日以上)
正社員
プチリッチ
辞退
レスラク
リモート可(週3日以上)
正社員
プチリッチ
辞退

3年後の目標や野望


webの技術で世の中を良くするサービスを作りたい。

例えば、旅行のオンラインプラットフォームを作りたいと思っています。旅行会社はサービスを売っていますが利益はサービスからは生まれません。その結果、接客に時間をかければ利益が減るという本末転倒な仕組みとなっています。私は旅行会社で働いていた期間中に、その矛盾に大変悩まされました。そこで個人的に旅行者の相談に有料でのっていたりしたのですが、そのためのプラットフォームがないことに気が付きました。 そこで私は旅行のプラン作成や相談自体を売るサービスを作り、サービスに対価が支払われる仕組みを作りたいと考えました。そうすることで、消費者もより気兼ねなく質問ができ、安心して旅行を楽しめますし、従業員も対価=サービスなので、サービスの提供に不満がなくなります。 旅行業界だけでなく、世の中にはサービス業と称した利益のない業界が多くあると思っています。 サービス業界は総じて離職率が高い傾向にありますが、きちんと還元されていないことが原因だと考えています。 そこで、今オンライン化が進んでいる世の中だからこそ、webサービスを通してサービス業の矛盾をなくしたいと思っています。

年収評価シート

2018年/1年以内

訪日外国人向けマッチングアプリ開発

## サービスの概要 - 訪日外国人向けのマッチングサービス - 日本人に日本旅行のプランを組んでもらえる - 日本人は有料でプランを作成することができ、それを訪日外国人が買うことができる ## 機能 - チャット機能 - 決済機能 - ホテル予約機能(agoraのAPI利用) - プラン作成機能 ## 言語&フレームワークなど - Ruby on Rails - Ajax通信 - HTML, CSS ## 役割 新規事業立ち上げとして、CEOの方と二人で開発をしました。 人数が少なかったので、デザイン、要件定義、開発まで全て行いました。 リリース後は広報も担当し、ユーザーの要望を確認しながら機能改善を行いました。 ## チャット機能の構成に関して チャット機能は各ユーザーが、プラン作成者に対してDMをして疑問点などを解消するために実装しました。 RoRのMVCを利用して作成しました。 ## 決済機能に関して 決済機能はstripeのAPIを選定しました。 stripeを選んだ理由は、ユーザーがstripeのアカウントがなくても支払ができるという点で、ユーザーに煩らしい思いをさせることなく、決済に進んでもらえると考えたからです。 また、[ドキュメント](https://stripe.com/docs/api)も充実しており読みやすく、決済機能の実装は初めてでしたが問題なく実装できました。 ## 開発環境のDocker化 当初は開発環境をローカルで動かしていましたが、今後新しいメンバーが入るときのために、開発環境をDockerで立て直しました。 サーバーはherokuで立ており、developブランチにマージされたものは開発環境に、masterブランチにマージされたものは本番環境に自動デプロイが走るようにCIを組んで環境を整えました。 ## ホテル予約機能に関して アフィリエイトでも収益をあげるために、ホテル予約システムを導入しました。 agoraのAPIを利用した理由としては、比較的アフィリエイト収入がよく(当時で2%でした)adoraのサイトに飛ばす必要なく予約まで行うことができたからです。 booking.comのアフィリエイト用APIも検討しましたが、システム上どうしても予約時にはbooking.comのサイトに飛ばさないといけないため、UI面を考えると厳しく、agoraを使うことにしました。 ## agoraのAPIを利用して自動で記事を作成する 上記のアフィリエイト収入のため、PV率アップをして、大量の記事を作成する必要がありました。ただ、新しいライターを雇う余裕もないプロジェクトだったため、agoraのAPIを利用して、自動でタイトルと画像、本文にスタイルを当てて作成するようにしました。 ホテル情報の紹介のようなページでしたが、約2000件ほど作成できたので、PV率は月1,000pvほどだったところから3,000pvに上がりました。 ## 企画からローンチまでのスケジュール 企画から1ヶ月で要件定義と設計を行い、その後の3ヶ月で開発、その後は4ヶ月ほど運営、保守、改善を行いました。

2020年/3ヶ月以内

滞留分析アプリ開発

## サービスの概要 - 店舗の監視カメラから利用客の密集具合を検出し、表示する - カメラは既設の監視カメラを使うため、低コストで導入できる ## 機能 - 映像分析 - AIによる密集具合の検出 - 検出後は可視化し、色わけしてダッシュボードに表示 (私が関わったのは最後のダッシュボードに表示部分だけです。) ## 言語&フレームワークなど - Laravel - Azure - React - Next.js ## 役割 既存のサービスのフロントエンド部分のレイアウトとAPIをアップデートするために参画しました。依頼が来た時点で主な機能はできていましたが、依頼元にフロントエンドをまともに書くことのできる人材がおらず、フロントエンド部分でより細かいUIを実装することができないため、参画することなりました。フロントエンドの人数は私一人でした。 ## クラス型コンポーネント+propsの構成から関数型コンポーネント+hooksへの書き換え 参画した時点でコードを確認すると、ロジック部分と表示部分が一つのファイルにまとめて書かれており、Reactの良さというのを全く活かせていませんでした。 また、クラス型コンポーネントの構成だと、共通のロジックをコンポーネント間で再利用するのは難しく、毎回同じような処理を書く必要があります。さらに、componentDidMountやcomponentWillUnmountなどの細かく分けられた状態を完璧に理解するのは難しく、その後経験の浅い人がアサインされた場合にメンテナンスがしにくくなります。 その点、hooksを利用してロジック部分はできる限り共通化して外部に書き出し、ビュー部分ではインポートして使うようにすることで、あとから入った人でも見やすくメンテナンスがしやすくなります。 また、hooksの中のuseMemoやuseEffectなどで依存関係をもたせることで、より最小の差分のみを変化させることができ、レンダリングコストを少なくすることができます。もちろんこれはクラス型コンポーネントでも可能ですが、hooksを利用したほうがより直感的でわかりやすいです。 そのため、少し手間ではあったのですが、私がプロジェクトから抜けたときのことを考え、クラス型コンポーネント+propsで一つのファイルにベタ書きされていたものを、関数型コンポーネント+hooksへの書き換え、さらにファイル構成を、コンポーネント単位で切り分けて、ロジック部分はカスタムフックを管理するhooksフォルダを作り、ファイル名を見ただけで構成が理解できるようにリファクタリングを行いました。 結果的にこのリファクタリングは大正解で、どうしても私一人の作業量では足りない部分が出てきた際に止むを得ず社内のReactを少しだけ触ったことがある程度の人が参画することになったのですが、コンポーネントでの分離が完全にできていたので、作業の切り分けがしやすかったです。 また、ロジック部分は私がほとんど作ったカスタムフックを利用するだけで良かったので、そこまで経験値によって差がでることもなく、ある程度整頓されたコードを納品することができました。 ## Next.jsの導入 新しく使うAPIがセキュリティ面担保のため、SSRでしかアクセス許可されていませんでした。そのため、Next.jsを使う必要があり、上記のリファクタリング後のコードはNext.jsに置き換えました。APIにアクセスしないといけないのはページを表示した際にデータを取得するためだけだったので、getInitialProps内でAPIに接続しました。 ## 開発環境と本番環境の切り分け 本番環境ではAzureを使って運用されていましたが、残念ながら社内(私が所属していたSES企業)ではAWSで開発環境を作成する方針が決まっていました。 そこで、EC2上に開発環境を立ち上げて社内用の開発環境としました。また、先方に共有する際に、環境構築も必要になる可能性を考慮して、簡単に環境を共有できるようにDocker化も行いました。

2021年/2年以上

mycrewアプリ開発

## 概要 - バーチャルオフィスでコミュニケーションをとれるサービス ## プレスリリース - https://prtimes.jp/main/html/rd/p/000000001.000076293.html ## 機能 - チャット機能 - オフィス移動機能 - 通話機能 - ステータスのリアルタイム更新 ## 言語&フレームワーク - バックエンド..Golang - RPC..gRPC - フロントエンド..React+TypeScript - 通話機能はAmazon Chimeを利用 ## 役割 フロントエンド担当として、他のフロントエンドメンバー2名と一緒に開発を進めました。主にチャットサービス部分の実装とステータスのリアルタイム更新部分実装を担当しました。機能ごとに開発者を分けてアサインし、実装後は他の開発者が相互レビューを行う形で実装を進めていました。 ## gRPCの選定に関して 今回、gRPCを利用したのは通信速度が非常に高速だったのと、protoを使うことでフロントエンド側、バックエンド側両方に型を自動生成することができ、フロントエンド・バックエンド間の連携のずれを防ぐことができるからです。どうしてもバックエンド側のバージョンが上がった際にフロントエンド側の型の修正などを忘れてしまったりしますが、protoファイルをsubmoduleに入れてコードを自動生成するだけで、修正を忘れている部分があれば自動でエラーを吐くようになるので、コンパイル前に気がつくことができ、非常に便利でした。通信速度も非常に高速だったので、今回のようなチャット機能やステータスのリアルタイム更新などでは重宝しました。 protoに関しても、殆どはバックエンドの方が書くようになっていたのですが、proto自体難しくはないので、必要な返却値などがあれば、フロントエンド側からprotoディレクトリに対してプルリクエストを送って要求することもできました。 ## チャット機能に関して ユーザーはフロアボードを開いて、チャットをすることができます。リアルタイムで得たチャットに関してはstream処理で探知し、表示をするようにしました。 以下の手順で実装しています。 ①フロアボードを閉じている間に新しいメッセージを探知した場合 通知の赤丸のみをフロアボードアイコンに付与する。メッセージに関してはフロアボードを開くタイミングでgRPCが叩かれるため、メッセージの更新はReact側では行う必要がない。 ②フロアボードを開いている最中に新しいメッセージを探知した場合 フロアボードを開くタイミングでメッセージをgetするため、新しいメッセージが飛んできた場合はReact側で状態を変える必要がある。メッセージ探知の度にuseEffectが動くようにして、その中でuseStateを使って状態を更新して表示しました。 ③メッセージIDが同じ場合は更新しない ②の方法だと、まれに同時時刻に大量のメッセージを探知した際、二重、三重でメッセージが更新されてしまいます。そのため、メッセージと一緒に飛んでくるIDでメッセージリストを検索し、メッセージリスト内にすでに同じIDがあれば何もせずにreturnだけするという処理を加えました。 ## react-queryの導入 今回、構成上フロアボードを開く度にgRPCを叩く必要が出てくるので毎回新しいデータからスタートすると一瞬ですが画面にちらつきが生じます。 そこで react-queryを導入してキャッシュ利用可能にすることで、初めてデータを取得する場合のみデータが表示されるまでにローディングアニメーションを出し、それ以外の場合ではキャッシュのデータを表示することで無駄な画面のちらつきをなくしました。

2021年/2年以内

訪日外国人向けECサイト

## 概要 - 訪日外国人向けECサイト ## 機能 - 商品をキーワードで検索 - 商品購入 - お気に入り機能 - マイページ ## 言語&フレームワーク - バックエンド..Ruby on Rails - フロントエンド..Next.js+TypeScript - インフラ...heroku(APIのホスティング), fastly + amplify(フロントエンドのホスティング) ## 役割 開発リーダーとして要件定義から開発・レビューまで基本的に全タスクを見ていました。 具体的には、バックエンドのAPIのリクエスト・レスポンスの仕様に関してOpenAPIのyamlファイルを作成してバックエンド・フロントエンド双方の合意が取れた状態で開発をすすめるようにしたり、フロントエンドに関しては、開発だけでなくタスク分割をして開発者にアサインしたりレビューを行いました。 開発メンバーとは週に一度1on1をして、技術的な相談にのりながらスプリント内でタスクが完了するようにマネジメントもしていました。 ## Gatsbyを使った静的サイトの構成からNext.jsオンリーの構成にリプレイス このプロジェクトの中で最も注力したのは全体の構成のリプレイスです。 元々、Next.js 9系の頃からプロジェクトがあったということもあり、その当時はNext.jsにSSGの機能がなかったのでSSGのためにGatsbyを使って全ページを生成して、s3で静的ページとしてホスティングをしていました。この実装自体はページ速度の向上に非常に役にたったのですが、その分商品情報のページも予め生成してしまうため、売り切れなどの情報がリアルタイムで反映されないという問題が発生してしまいました。また、多言語化に関しても4言語行っておりましたが、各言語ごとにホスティングしており、ホスティング先が4つあるという状況でした。当然ビルドも4言語分走るので、ビルドするだけでも30分程度時間がかかり、開発体験としては決して良いものではありませんでした。 そこで、Next.jsの機能自体にSSGが備わったということと、多言語化に関しても一つのホスティング先で複数振り分けできるようになったということ、商品情報に関してはできるだけリアルタイムの情報を出したい、全体的にリファクタリングをする必要があるという思いから、以下の構成に変更することを決めました。 - 商品情報部分はISRで短めにrevalidateを設定することで、ページの表示速度はSSGオンリーの場合と大差なくしつつもデータは自動でキャッシュを更新するようにする - 多言語化に関してはNext.jsのi18n-routingを利用することで一つのホスティング先で複数言語が確認できるようにする - APIを接続している部分では積極的にSWRを利用してデータの表示速度を早くする - グローバルな状態管理に関してはSWRのキャッシュを利用するカスタムフックを作って利用し、他に依存先を作らないようにする - 商品画像に関してLambdaEdgeとCloudFrontを利用してs3にアップロードされたらLambdaEdgeを通じて画像の圧縮を行いCloudFrontにキャッシュとして残すようにする。画像を取得する際はs3を直接見るのではなく、CloudFrontから取得をすることで、画像の取得速度をあげる。 また、関数の命名ルールやディレクトリ構成・ファイル名などでもルールが特になく、各自が様々なルールで書いていたという状態だったので、チームメンバーとMTGをしつつルールを決めて、ルールに則るようにhusky、eslint、stylelintを活用して自動でチェックが入るようにしました。 このリプレイスに関しては、リポジトリ自体を変更するという大掛かりなものになりましたが、結果としてビルド時間は1/10になり、商品情報に関してもほとんどリアルタイムのものが確認できるようになったのでユーザー体験・開発体験ともに良くなる結果となりました。 ## SSRではなくISRを採用した理由 当然、データのリアルタイム性に重きを置くのであればSSR(あるいはCSR)を採用するべきでした。 ただ、今回のケースだとリアルタイム性も重要ですが、それ以上にページの描画速度も必要でした。というのも、ECサイトというのは、様々な商品ページを見られることが多いので、どれだけ各商品ページが早く描画できるのかということはUX改善において欠かせないポイントだからです。 作っていたサイトがオークションサイトのように強整合性が求められるものであればまた別なのですが、今回の場合は管理者も一日に数回商品情報を更新するかどうかという程度で、また、ユーザーが商品をカートに追加する時点でもその商品を購入できるかどうかのAPIを叩いてリアルタイムで再度確認ができるということもあり、結果整合性で十分だということになったので、ISRを利用することにしました。 ## SWRの利用 特に力を入れたのはSWRの利用です。 予めデータを取得できる場合は前述の通りISRでビルド時にデータを取得しておけば良いのですが、アクセスキーを使ってデータを取得するような場合は、CSRでデータを取得せざるを得ません。ただし、毎回APIを叩いて取得しているとユーザーメニューボタンを押すときなどで毎回ローディング状態になりUXとしてはよくありません。 そこで、変動があまりないもののよく叩かれるAPIに関してはCSRで叩く場合に関してはSWRを積極的に使うようにして、キャッシュを利用してデータの描画速度を早めました。 もちろん、CSRをするのであればリアルタイム性というのは譲れないポイントになるので、変動があった場合には明示的にMutateを行い、データのリアルタイム性の担保も忘れないようにします。 グローバルな状態管理に関してもSWRを利用しています。 その理由は、他に依存関係を作りたくないということが一番大きな理由です。もちろん状態管理のためのライブラリは多数優れたものがあるのですが、特定のライブラリに依存してしまうと将来的にそのライブラリが廃止や最新のNext.jsのバージョンに追従しないとなった場合に変更が大変です。そこで今回は状態管理のために新しいライブラリをインポートすることはせず、キャッシュ戦略として利用していたSWRを少し工夫して状態管理ライブラリとしても利用することにしました。 依存関係を作らないだけならreduxでも良かったのですが、Providerが複数個存在すると見にくくなるので、ここではSWRを利用しています。 ## CloudFront & LambdaEdge で画像をリサイズする 画像の最適化も大きな課題でした。サイズ問題だけならnext/imageで十分なのですが、s3は物理的にクライアントから呼ぶ際に距離が遠いのでどうしても取得自体に時間がかかってしまいます。そこで、CloudFront & LambdaEdgeを利用して画像をリサイズしつつキャッシュを保存することにしました。 具体的にはhttps://aws.amazon.com/blogs/networking-and-content-delivery/resizing-images-with-amazon-cloudfront-lambdaedge-aws-cdn-blog/ で紹介されていることをそのまま行っただけですが、CloudFrontのキャッシュを利用することで、かなり早く画像を取得することができました。

マネージメント能力

スプリント開発において、タスクの進捗状況のマネジメントと、エンジニアの評価やモチベーションに関して管理していました。また、アプリの品質管理に関しても私の仕事でした。
## 開発タスクに関するマネジメント 開発タスクに関しては、毎週のスプリントで各開発者に対して適切な量の課題を与え、かつその課題がスプリント内に終わるようにサポートする必要がありました。 スプリント会議でタスクを各自に与えたあとは1on1でそれぞれの開発者に対し、わからない部分の質問対応をして、プルリクエストが出てからはレビューで品質を担保していました。 ## エンジニアのモチベーションに関するマネジメント エンジニアの評価に関しては、各自の目標となる指標をそれぞれ決めて共有し、その期で目標を達成できるように定期的に雑談会などを開き各自が今興味を持っていること、今後やりたいことを把握し、適切な課題を各自に与えることで、モチベーションを損なわずに働くことができるように管理しました。
#課題点 開発タスクに関して、当初は淡々と課題を与えるだけだったのですが、途中でバックエンドとフロントエンドの意思疎通が正しくできていないことに気が付きました。 具体的には、例えばAPIの仕様変更があった場合にバックエンド開発者がそのAPIを変更したあと、フロントエンドへ変更を通知していなかったり、またバックエンドとしてもそのAPIがどのように使われているのかわかっていないようでした。 また、エンジニアのモチベーション的にもただ与えられたタスクをこなすだけで向上心が感じられなかったので、何かしらの手段でモチベーションを上げて働きやすい環境を整えることが重要だと思いました。 #取り組み バックエンド・フロントエンドの垣根を超えて全員がタスクの進捗状況を把握できたほうが良いという考えから、スプリント会議内である程度の具体的な実装例を皆で話し合って決めることにしました。 また、バックエンドに関してはOpenAPIを導入し、APIの仕様変更がある場合はまずそのAPIを実際に使うフロントエンド側がyamlファイルを作成して具体的なAPIのリクエスト・レスポンスを決めてからバックエンド・フロントエンド双方の合意が取れた状態で開発をすすめるようにルールを決めました。 また、私自身は元々フロントエンドのみしかわからない状態だったのですが、最低限上の立場なのであればバックエンドに関しても内容を把握できたほうが良いという考えから、開発者に協力してもらい徐々にバックエンドのコードに関しても見れるようになりました。 その過程でフロントエンドのレビューは元々私が見てましたが、バックエンドのレビューに関しても見るようになりました。 ただし、それだと私に責務が集中しすぎてしまうので、皆がある程度同等以上の知識を身につける必要があると考えました。そこで週に一度1on1を実施して、わからないことの質問対応を行いました。 エンジニアのモチベーション管理に関しては、まず各自が今後どのようになりたいのかを把握する必要がありました。 そこで期ごとの目標管理の際に将来的にどのようになりたいのかの長期目標から逆算して短期目標を決めて、その短期目標のために今足りていないことを考えました。例えば、将来的にテックリードになりたいのであれば、UI改善のみのタスクをするよりは、もう少し技術的に挑戦できるようなタスクを与える必要がある、などです。このように、各自ができるだけ楽しく開発できるようにタスクの振り分けを考えました。 #工夫点 APIの仕様の共有のために導入したOpenAPIに関してはamplifyで中身をホスティングするようにして、PRを上げたら自動でURLが発行されるようにしました。 そうすることで、皆にURLを共有するだけで簡単にAPIの仕様をレビューしてもらうことができるようになりました。 皆の知識の向上に関しては、勉強会も開いて具体例を用いながら皆がある程度理解できるようにしました。その中で、聞くだけではなく積極的に学んでほしいという思いから、簡単なサンプルプロジェクトを立ち上げてイシューを立ち上げてそれぞれにタスクを分割して相互レビューしてという時間を週に1時間ほど取ることにしました。 エンジニアに与えるタスクに関しては、中にはどうしても皆がやる気にならないタスク(例えばドキュメント整理など)はあったりするので、そういうものに関してはできるだけ私が率先して行うか、プラスアルファで興味が持てるような要素を付け足してタスクを渡したりしました。 もちろん難易度を上げたら良いというわけではないので、今の開発メンバーにとって有益になるように、将来的に会社でも使われるような設計にということを考えながらタスクを与えていました。

アピール項目


アウトプット

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

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

- データベース設計の知識 - AWSなどのクラウドの深い部分の知識(LambdaやEC2を使っての環境を建てることはできますが、パフォーマンス性などを考えるとまだまだインフラの知識が不十分だと感じるので)

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

未入力です

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 3年以内には海外で働きたい / 勉強会でLTをよくする / 趣味は仕事 / 起業/創業期のベンチャーにいた / 多職種のバックグラウンドがある / OSSのコミッターである
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きな Text Editor
VS Code
希望勤務地
東京都
希望年収
未入力
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
Yui
今年で30代前半
VS Code
参加ステータス
不参加
参加回数
4回
累計平均提示年収
663 万円
SIGN UPSIGN IN


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