ID:40178さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


Reactを中心としたWebフロントエンド・モバイルアプリのリードエンジニアを経てプロダクトマネジメント

### 3年後 - Reactを中心としたWebフロントエンド・モバイルアプリのリードエンジニア - React周りの専門性(React、Redux、Next、React Nativeなど)を深く持ち、その上でプロダクトにコミットすることで「どう作るか」に関しての意思決定と実装・実行力を身につけていと考えている。 - 技術側からだけでなく事業側からの思考も持つことができるエンジニアになりたいと思っている。新機能の実装をただ行うのではなく、ユーザにとってより価値の高いアップデートであるかを常に考え、それを具体に落とし込んで実装できる存在になりたいと考えている。 - 最新技術や自分が知らないことへの情報に関してのインプットは常に行い、それを何らかの形で試しナレッジをシェアする活動を継続的に行っていきたいと考えている。 ### 5年後 - プロダクトマネジメント - 「何を作るか」に関して一流の意思決定と実装・実行力を身につけていと考えている。

年収評価シート

2020年/1年以内

[自社プロダクト]AI学習サービス

## 開発 自社プロダクトであるAI学習サービスの開発・設計(2020/4〜現在) ## 使用技術・ツール React, Redux, TypeScript, Redux Thunk, Cloud Functions, Firebase Authentication, Node, Express, GCR, GKE, Datadog, Brightove Video, Mailgun, Sentry, Wovn ## チーム規模・状況 全員がフロントエンド・バックエンドのタスクを担うことがあったが、基本的にチームは以下のような構成だった。 - チーム構成 プロダクトマネージャー:1人 サーバーサイドエンジニア:(時期によって)1-3人 フロントエンドエンジニア:(時期によって)1-2人(このうち1人が自分) デザイナー:2人 ## タスク詳細 ### Reactアプリケーションのフロントエンドのリファクタリング - どのような課題があったか: - フロントエンドにテストが無かったのでテストを導入しようとしたが、Componentが肥大化していたことでテストの導入がしずらかった。また、Componentのlocal stateの規模が大きすぎたり、Component内部でAPIを叩いていたことでComponentと副作用を伴うロジックが密結合になっていた。 - どのように行ったのか: - Component内で扱っていた一部のlocal stateを切り出してReduxで管理するようにした。 - Redux Thunkを導入することで、Component内部で扱っていたAPIをRedux Thunkに切り出した。 - 何が解決されたのか: - 各Componentで重複したロジック(非同期処理周り)をRedux Thunkに集約することができたことでComponent内部の冗長性が減った。また、データを参照する時もactionを発行するのみとなりシンプルになった。 - ComponentとAPIの密結合が解消されたことでComponentを分解することができ、それによってユニットテストを導入することができた。 - Componentが参照するstateがReduxのstateになったことで、Componentで参照するstateのデータで齟齬が起きにくくなった。 ### アプリケーションの新機能の設計および実装 プロダクトマネージャーとデザイナーから機能とデザインのインプットを受け、仕様に関しての設計を行い新機能の開発を行った。 #### ユーザにユニークIDと所属部門の情報を追加してそれらで管理できるような新機能: - 担当:フロントエンド - なぜ行ったのか:大規模クライアントでは、例えば1000人以上のメンバーを抱えていたため管理画面にて管理・検索をしにくい状態であったため。 - 何が解決されたのか:大量のメンバーが存在するチームにおいて管理画面でのメンバーの管理のしにくさが解消され、管理者がより快適にメンバー管理を行うことができるようになった。 - どのように行ったのか:ユニークIDや所属部門のstateを追加する実装を行った。所属に関してはReduxを利用することで、どこの画面からも所属一覧を参照できるようにした。所属の情報に関してlocal stateではなくReduxを採用したのは、多くの画面(コンポーネント)で参照する必要があったため各コンポーネントのlocal stateで管理するよりグローバルなstateとして管理した方が情報の齟齬が起きにくかったり、データフローも分かりやすいと考えたため。 #### 所属部門別で管理権限を設定できる新機能: - 担当:フロントエンド - なぜ行ったのか:大規模クライアントでは、マスター管理者の下に紐づくような、例えば所属部門単位での管理者権限がある方が便利だというフィードバックを受けていたため。 - 何が解決されたのか:所属部門ごとに管理者権限を付与することができ、より細かくメンバー管理を行えるようになった。 - どのように行ったのか:もともと存在していた管理者権限あり/なしの二つのステータス加えてその中間のステータスとして所属別の管理者権限を追加した。それらのstateを追加したり、管理者権限あり/所属別管理者/管理者権限無しのそれぞれのステータスで何ができて何ができないといった権限設計を行いながらそれらの実装を行った。またこの機能はオプション機能であるため、この機能を購入したクライアントのみこの機能を利用できるように特定のモードとして定義してUIやUXの出しわけを行った。 #### ユーザ情報の要素によって絞り込み検索できる新機能: - 担当:バックエンド - なぜ行ったのか:名前以外でのメンバー検索方法がなかったため特定のメンバーに到達およびそのメンバー情報を編集をするUXが良くなかったため。 - 何が解決されたのか:特定のメンバーを検索する時に、例えば管理者権限の有無や所属部門での検索が行えるようになり、より簡単にメンバーの情報編集が行えるようになった。 - どのように行ったのか:ユーザに設定されている情報(管理者権限の有無/受講ライセンス/所属部門/タグなど)によって、絞り込んで検索表示できるようにした。フロントエンドから渡されるクエリによって、それらの内容によってクエリを継ぎ足しながらmongoDBから取得するようにした。なるべくDBに負担をかけないこととコードの可読性をあげるために、クエリを継ぎ足しながらDBからデータを取得するロジックにした。

2020年/1年以内

[個人開発]音楽専用の質問箱

## アプリ概要 音楽専用の質問箱(個人開発 2020/7〜現在) ## 使用技術 React, TypeScript, Node.js, Cloud Functions, Firestore, Firebase Hosting, Firebase Authentication, TwitterAPI, SpotifyAPI, MaterialUI, Figma ## 技術選定について - 自分1人で設計、開発、リリースする前提であったためサーバサイドに関してはBaaSを利用しようと思いFirebaseを選択した。 - DBに関しては、Firestoreを選択した。Realtime Dataseを選択しなかったのはクエリの制限があったためである。Realtime Dataseは、絞り込みと並び替えを同時にできないといった制限があった。 - フロントエンドに関しては型安全な開発を行いたいと思っており、フレームワークはTypeScriptと親和性の高いReactを採用した。また、Hooksを用いることでロジック部分に関してより自由度が高いと考えた。 ## タスク詳細 - Firebase AuthenticationとTwitterAPIを使用したログイン機能実装 - React Componentの実装 - コンポーネントの不要なレンダリングを防ぐために、Hookを用いて適切にmemo化・callback化を行っている。 - Cloud Functionsを用いた各種APIの実装 - Cloud FunctionsとFirebase Hostingを用いたTwitter OGP表示ロジックの実装 - TwitterOGPを作成するためにmetaデータを動的に変更する必要があった。そこで、Hostingのrewritesで指定したURLをトリガーにしてFunctionsを呼び出しその中でmetaデータの更新を行いTwitterOGPに表示するようにした。 - metaデータの中の画像に関しては、Tweetする度に投稿内容によって異なった文字列をセットする仕様にしていた。最初はSVGで対応しようと考えていたがOpen Graph ProtcolはSVG対応していなかったので他の方法を考えた。Cloud FunctionsがImageMagickをデフォルトでサポートしていたので、ベースとなる画像をPNGで用意し、Functionsの中でImageMagickで文字列をセットして、Cloud Storageにアップロード→metaデータにセットするようにした。クライアント側でCanvasで書き換える方法もあったがクライアントの環境依存が原因でうまくOGPが生成されないことを避けたかったこともあり、Functionsで完結するロジックを採用した。 - SpotifyAPIを使用したSpotifyデータ取得ロジックの実装 - TwitterAPIを使用したTwitterのフォロー・フォロワー情報の取得 - Spotifyのプレイヤーの実装 - Firebase Hostingを使用してReactアプリケーションのHosting ## 現在実装中のリンク(2021年3月にα版リリース予定) https://pitchask-front.web.app/

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

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

マネージメント能力

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

アピール項目


アウトプット

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

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

- Next.js、React Native、swrなどReact周りの技術。 - React周りの知識の幅と深さをさらに深めて、Reactのことはこの人に聞けばざっくり分かるという人物になりたい。

エンジニアとして影響を受けた本を教えてください

- ハッカーと画家

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

- チーム開発が行われている(レビューの文化など) - チームメンバーのコミュニケーションがある

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 分析力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
SI / アダルト
その他の特徴
レガシーな環境を改善できる / 新しい技術はとりあえず試す / 趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

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

要望、不具合報告、使いづらい点や感想など、なんでもお気軽にご連絡ください。

ID:40178さん
今年で20代中盤
VS Code
参加ステータス
参加したい
参加回数
10回
累計平均提示年収
539 万円
SIGN UPSIGN IN


このサービスを友人に薦めたいですか?