ID:43130さん

3年後の目標や野望


アメリカに拠点を移し、スキルを活かす

アメリカの大学院でPhDを取得する。そのための準備期間とコネクション作りのため、2024年4月から日本で社会人学生として大学院に進学予定。現在考えているテーマとしては、中米考古学における土器分類を3次元データ解析をDeep Learningで行なう研究。

年収評価シート

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

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

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

2021年/3ヶ月以内

Technical Deep Dive - IoT

### 概要 コロナ禍におけるサテライトオフィスのデジタルツイン化 - ドローンで撮影したサテライトオフィスの画像を用いたフォトグラメトリ。 - ラズパイを使った人感カメラによるオフィス内の撮影画像と、`M5Stack` とセンサを用いた温度・湿度・気圧のSlack連携。 ### 成果 - 新領域の技術獲得 - IoTデバイス(OSやセンサーなど)の選定から `Rust` や `Blockly` を使った組み込みの実装といった普段の業務で使用しない領域の技術に触れることができた。 - 同様にドローンの操作やフォトグラメトリ技術についての知見を獲得した - 知見の社内共有 - M5Flowを用いて非エンジニアでもM5Stackを使った簡単なIoTの実装ができるハンズオンを実施。同時にIoTを取り巻くトレンドや技術の背景などを社内に共有した。 ### チーム規模・役割 リードエンジニア - フロントエンド2名、バックエンド3名、インフラ2名 - フロントエンド・バックエンドの一部・インフラの設計と実装

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

2020年/3ヶ月以内

ビデオ通話機能開発プロジェクト

### 概要 『楽待アプリ』と『楽待加盟店アプリ』を使って、不動産投資家と不動産会社がビデオ通話できるようにした。 ### プロジェクトの目的 - 不動産投資家の支援 - 不動産会社の活動支援 ### 成果 - 2020年6月度社長賞を受賞 - [プレスリリース](https://www.rakumachi.jp/news/column/261843) ### チーム規模・役割 エンジニアメンバー(技術選定・アーキテクチャ設計・FE/BE実装・一部データパイプライン実装) 開発マネージャ2名、エンジニア5名、デザイナー1名 ### 時系列 #### 2020年4月 技術検証 - 調査の視点 - ビデオ通話とはどういう技術で成り立ってきたのか。 - 現在主流な技術は何か。今後どのような技術が主流になりえるか。 - リソースを考慮した場合、どの技術を選択することが最適解になるか。 - サンプルアプリ作成 - 20通りほどある実現手段のうち、`Agora.io` の `React Native` 用SDKを用いてサンプルアプリを実装した。 最終的に提案したサンプルアプリで実装することを社長と合意。採用に至った観点は以下の3つ 1. アプリに組み込んでデモ通話を作ることができた。 1. 通話品質に対して料金が非常に安かった。 1. 拡張性に優れていて、不動産売買のオンライン契約に必要な要件を満たしていた。 #### 2020年5月 - フロントエンドの実装(スマホアプリ) 要求仕様の各種機能と、エラーハンドリングなどの非機能要件を実装。具体的には以下。 - カメラon/off - マイクon/off - 通信状態の制御とエラーハンドリング - 通話記録のログデータ取得 - バックエンドの実装 ビデオ通話を要求するリクエストを受け取り認証/認可を行なうサービスを作成、主にAgora Cloudによって提供されるAPIの制御を実装した。 - ML Opsの実装 通話記録をビッグデータとして活用できるようにデータパイプラインを `Google Cloud BigQuery` を活用して作成した。また、通話の解析結果をMetabaseというBIツールを通じてマーケティング部が活用できるようにした。

2019年/3ヶ月以内

大家さんデビュープログラム

### 概要 マーケティング部が企画した「楽待 大家さんデビュープログラム」のシステム部分を実装した。UIデザイナー1名と協力し、マーケティング部の要望に応えるシステムを実現した。 ### プロジェクトの目的 - 不動産投資家の支援 ### 成果 - 申込数1000件以上、不備のある申し込み0件 - アプリのDAU17%上昇 ### 時系列 #### 12月 1. 要件定義 2. システム設計 3. テスト設計 - 要件定義 期限は1/16リリース。解決すべき課題が大きく2つ存在した。 1. 「キャンペーン」の運用を恒常化 - 状況 これまではキャンペーンを行なうたびにハードコーディングしていたため、キャンペーン終了に伴って、ソースの削除を行ってリリースしなければならなかった。 - 小課題1 アプリのリリースは、「審査に時間がかかること」、「リグレッションテストで工数がかかること」、「ユーザーにとって負担になること」の3点を考慮して回数を極力減らしたい。 - 小課題2 次回以降のキャンペーンで設計を使いまわせず、知見、データが溜まらない。 - 小課題3 ソースの削除忘れなどでバグ、デザイン崩れのリスクを抱えることになる。 2. ディープリンクの実現 - 状況 マーケティング部の要望で、キャンペーンのLPへの導線としてディープリンクを実現したいと承った。 - 小課題1 直近で別のチームがディープリンクを実現していたが、特定の機能のために実装されおり、汎用化されていなかった。 - 小課題2 Firebase Analyticsで計測するパラメータの一貫性がなく、集計する際に不都合だった。 - システム設計 - 「キャンペーン」の運用を恒常化 主として使用した技術が `Firebase Remote Config`。既存システムに導入されていなかったため、技術調査から1人で行なった。`Remote Config`はJSON形式のデータストアで、これをアプリに組み込むことでソースリリースなしにクライアントに対して変更を伝えられるという特徴を持つ。キャンペーンに関する変数を設計し、`Remote Config` で管理することによって、ソースリリースなしでキャンペーンのon / offを実現することを目指した。 - ディープリンクの実現 主として使用した技術が `Firebase Dynamic Links`。11月に別チームが別の機能のために導入していたが、その機能に特化しており汎用化されていなかったため、「DynamicLinks関連のソースコードのリファクタリング」と「パラメータの再設計」の2つを行う方針にした。キャンペーンとしては自社サービス外の広告、WEBアプリのバナーに展開できるようURLを用意。 #### 1月 4. 実装 5. テスト 6. リリース - 開発環境 ホスト上に作業ディレクトリを作成し、Githubからソースをクローンして管理している。Xcode / Android Studioでシミュレータ / エミュレータ / 実機を立ち上げ各OS毎の挙動をデバッグしながら実装する。ソースを変更はホスト上のターミナルにバンドラ(Node.jsサーバ)を立ち上げて更新。 - バックエンド実装 - Remote Config `react-native-firebase` に `Remote Config` を使用できる仕組みがあったため、それを使用。すでに導入されている `redux-saga` と親和性を保ち、かつ今後Remote Configが別の機能でも活用できるようにフェッチする部分とデータハンドリングする部分を切り分けて実装した。その成果の副産物としてA/Bテストを実現できた。 - Dynamic Links `Dynamic Links` はURLを踏んだクライアントが、`Firebase` に登録されたデバイス情報に基づいてアプリに遷移させる仕組み。今回はハンドラの汎用化設計+リファクタリングを行った(小課題1)。また、計測に関して(小課題2)はパラメータ設計に基づいて正規表現を当てるメソッドを作成し、そこを通過するようにした。 - フロントエンド実装 ランディングページの `HTML` / `CSS` 部分はデザイナーの方にタスクを振って担当していただいた。 自分は、申し込みフォームの作成とそのバリデーションを実装した。申し込みフォームは「フォームメーラー」という外部サービスを用いて仕組みを実現した。フォームのバリデーションは `HTML5` 標準のものと、`JavaScript` を組み合わせて作成。一番難しかったのは添付されたファイルサイズのバリデーション。フォームメーラーで求められるファイルの規格をバリデーションに組み込んで、滞りなく応募できるようにした。 - リリース 途中からデザイン要件が変わり、期日通りのリリースが間に合わなくなる可能性が浮上。キャンペーンとして運用が成立するために必須のタスクを洗い出し、優先度が高い順に取り組むことで期日通りのリリースを実現。 - 評価 キャンペーン実施中のため、社長賞は終了後に判断するとのこと。特に評価評価されたポイントは、システム設計の出来のよさと、要件の変更にもかかわらず期日通りのリリースができたことの2点。

2019年/半年以内

加盟店値上げプロジェクト

### 概要 あるサービスに関する加盟店値上げプロジェクトを営業部の部長と2人で発足させ、ビジネス要件の企画をするところからシステムの実装、テスト、リリース、保守までを行った。 ### 成果 実施後1ヶ月でサービスの月次売り上げが前年同月比で+500万円を達成した。この成果によって11月度社長賞を受賞した。 ### 時系列 #### 10月 - 企画と要件定義 過去の売上推移や加盟店の契約状況を分析し、加盟店に対する値上げの内容を企画。それを社長に提案し承認を得た。また、独占禁止法、二重価格、事前告知の必要性など、法務的な観点から事前に想定されうる懸念点についても考慮した。 - 分析 要件を確定させる以前の仮説設定と分析は基本的に1人で行なった。 1. 他社の値上げ事例の調査 2. 当社の過去の売上・契約データ分析 - 他社事例の調査 類似したビジネスモデルを持つ企業の事例を海外の法人まで含めて20事例ほど調査。同様のプロジェクトの成否を有価証券報告書などを時系列順に追って比較、成功するプロジェクトの進め方とは何かについてまとめた。 - 過去のデータ分析 過去の売上推移データと加盟店の契約状況の分析、および市況調査アンケートの企画・実施・結果分析を行なった。実装としては`metabase` を使って `SQL` を実行しデータを取得。それらを用いてプロジェクトを行なった結果の売上推移をシミュレーションした。この際、`Python` を用いてごく簡単な機械学習でモデル作成を行った。 #### 11月 確定した要件に基づいて、システム側の実装を1人で行なった。 実務の流れは以下。 1. 業務フローの設計 2. システム設計 3. テスト設計 4. 実装 5. テスト 6. リリース 1. 業務フローの設計 営業部の部長と協力しながら、業務フローを設計、可視化。 ツールとしては、`draw.io`、`plantuml`を用いてアクティビティ図を作成した。 2. システム設計 システム全体は `Symfony1.4` / `Doctrine` のMVCを主体とした構成になっていた。ただ、課金に関するシステム設計は10年以上前にドメイン駆動設計(以下DDD)で行われており、全容を理解している人がいなかった。そのため、独力で『エリック・エヴァンスのドメイン駆動設計』を参考にしつつ仕様を理解した。複雑な課金体系と、テストマーケティングの新しい概念を組み合わせる難易度が高い設計だった。ツールとしてはplantumlを用いてクラス図の作成を行った。また他に、UIデザインをAdobeXDを用いて行った。 3. 実装 - 開発環境 `Virtual Box`で、実行環境(`Ubuntu12.04`)とreverse proxy(`Ubuntu14.04`)を用いた。開発環境の構築は既存社員が持つVMのデータをダンプして、それをもらってインポートするという秘伝のタレ的な構築方法。個人のreverse proxyに社内IPが割り当てられるため、プロキシサーバの `nginx` や証明書関連の設定は自分で行なった。 - ソースコード管理 `GitHub` を用いて行った。ソースの変更は`nfs`マウントを用いて、mac(ホスト)上の`VSCode`から行なった。 - バックエンド実装 「加盟店値上げ」に対応するシステムであるため、ドメイン本体には極力手を入れず、UtilityにDDD部分とMVC部分の緩衝材になるメソッドを実装した。ロジックの根幹になるメソッドを1つに集約し、全てのメソッドがその判定を通るようにしたことで、仕様変更に対する保守性を担保できる実装になった。 - フロントエンド実装 新しい契約と既存の契約で内容が異なるため、営業事務・加盟店の方々が操作を間違えないよう、各アカウント毎に表示する内容を変えた。 - 評価 開発部の部長から「適切な設計ができた」という評価をいただき、社長賞を受賞した。 #### 12月 - 障害 負荷テスト実行漏れによって数店舗の加盟店がプラン開始できない障害が発生した。自身で調査を行なった結果、バッチ処理実行時の `Doctrine` のメモリリークが主たる原因だということが判明した。調査の手段としては `rundeck` のログ解析、`Doctrine` の中身をステップ実行で確認するなどを採用した。 - 2020年問題 プランの実働開始が2020/01/01からだったので、2019/12/31の夜中から2020/01/01の明け方まで本社サーバにVPNで接続し、バッチ処理の監視を行った。

マネージメント能力

最大20名程度の混成エンジニアリングチーム
大規模で複雑なドメインを持つアプリケーションを迅速に開発できるようにする
### 課題 様々なステークホルダーで構成された混成のエンジニアチームで、大規模で複雑なアプリケーションを開発する必要があった ### 工夫したこと - 実装方針や採用した設計思想の部分からチームで共有し、目指すプロダクトの方向性を一致させた。具体的には、デザイナと協力して `figma` や `miro` を使ってユーザージャーニーマップを用意し、ユーザのペインとニーズを明らかにし、それをチーム間の共通認識とした。 - モブプロ・ペアプロを積極的に採用し、個人間の理解・細かいスキル面の差を極力減らす用に心がけた。 - IaCやCI/CDを用いてDevOps基盤を作り、作業の属人性を排除することで新たなメンバーが開発チームに入ってきた際になるべく早く軌道に乗せられるようにした。 - Notionを使ってプロダクトの設計に関する意思決定を記録し、なぜその技術・実装が採用されているのか背景と経緯がわかるようにした。

立ち上げから完全に1人で組成したエンジニアチームのリード
1人1人が自走できるエンジニアチーム
### 課題 作りたいコンセプトはあるが、それ以外何もない状態からチームを組成しアプリ開発を軌道に乗せる必要があった ### 工夫したこと - チームを構成するエンジニアの質で勝負の8割は決まると思っており、個人のスキルレベル・相性の補完の良さなどを考慮して50名以上の候補者の中から5名を1か月で採用した。 - その後、彼らが作業しやすい基盤作りを行なうとともに得意領域の業務を切り出して自走してもらうことで予定の1.5倍ほどの進捗を出すことができた。 - 一度仕組みができあがるとロードマップ上の依存関係の管理だけがマネジメントコストになり、自分自身もマネージャ兼プログラマとして動くことができるようになった。

データサイエンティストを含む生成AIアプリケーション開発チーム
大企業の仕組みの中でイノベーティブなサービスを開発できるようにする
### 課題 エンジニアの都合で最先端の技術を追い求めるだけでなく、セキュリティやケイパビリティなどのトレードオフを理解した実践的なサービスをつくる必要があった ### 工夫したこと - 自身がデータサイエンスの領域にはみ出すだけでなく、データサイエンティストにもエンジニアリングの領域に踏み込んでもらうことで、互いのやりたいこととやるべきことが合致する部分を見つけられるようにした。 - リリースに必要な申請や手順などが決まっており、逆算して計画的に動く必要があったため、顧客も巻き込んでプロジェクトを動かした。

アピール項目


アウトプット

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

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

3D Point Cloud Analysis, Generative AI, Photogrammetry, Contrastive Learning, Rust

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

- フルスタックが求められる環境 - 達成するまで諦めず、細部まで工夫する風土がある環境 - 議論だけでなく、対話ができる環境 - 心理的安全性のもとに技術、思考などを共有できる環境 - 多様なバックグラウンドの人材が活躍する環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
分析力 / 問題解決力 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す / 3年以内には海外で働きたい / 勉強会でLTをよくする / 多職種のバックグラウンドがある / stackoverflowで回答した
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

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

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

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

  • {{error}}
SIGN UPSIGN IN


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