ID:6480さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


エンジニアリングスキルを軸にEM / PdMとしてデビューする

AI時代の到来によって、これからエンジニアの「コードが書ける力」のバリューが大きく下がると考えています。 生き残るためには「意思決定する力」を持つ必要があり、それが一番求められ、磨かれるポジションがEM / PdMだと考えており、そう言ったキャリアを構築していこうと考えています。

年収評価シート

2017年/2年以上

ヘルスケアアプリ開発 / 保守プロジェクト

## プロジェクトの概要 アーリー〜グロース期のベンチャーのBtoBtoCシステムのプロジェクト。 エンジニア4名程度のチームにメンバーとして関わった。 技術選定 / 実装 / 運用すべてのフェーズに携わり、フルスタックエンジニアとして活動した。 ## 私が主に担当したこと - react-native製モバイルアプリの保守 - 複数のモバイルアプリの共通認証基盤作成(nodejs / express) ☆ Amazon Chime sdk を用いたモバイルアプリ/ブラウザ間のカスタマーサポート用ビデオ通話機能 ☆ 面談予約機能(アプリ/管理画面連携) ☆ アプリ外の決済/在庫管理システム(決済SaaS仕様) ☆ レガシーrailsアプリの実行インフラの移行(AWS ElasticBeanstalk → AWS ECS + Docker) 注) ☆は技術選定から担当したものです ## ハイライト ### Amazon Chime sdk を用いたモバイルアプリ/ブラウザ間のカスタマーサポート用ビデオ通話機能 react-native製の既存アプリにビデオ通話機能を実装しました。 使用する通話SaaSの選定から担当し、プロトタイピングを経つつAmazon Chime sdkの採用を主導しました。 特に大変だった点としては、Amazon Chime sdkのreact-native対応はまだ不完全であり、公式が公開している実装サンプルにネイティブレイヤでバグがあったことです。AWSのサポートと相談しつつ自力で修正するなどの対応を行い、無事リリースまで漕ぎ着けることができました。 ### レガシーrailsアプリの保守/インフラの移行(AWS ElasticBeanstalk → AWS ECS + Docker) 社内にrails開発経験者がいない中、未経験の私が情報をキャッチアップしつつ保守/機能開発を行いました。 「守るべきものは何か?」と常にユーザ目線で物事を捉え、最低限のユーザ導線を確保できるよう、e2eテストをcircleCI + cypressで構築しました。 Rubyやライブラリのアップデートにかける工数がPJ都合で確保できなかったため、AWS Elastic Beanstalkによる継続的デプロイが、このままアクションを取らないと不可能になってしまうという出来事が発生したこともあります。デッドラインの2年前からDocker + ECSへのホスティング環境の移行を提案していたため、実際には継続的なデプロイを続けられる状態を保つことができました。

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

マネージメント能力

react nativeのアプリ開発するチームの業務フロー (評価などを含む厳密なピープルマネジメントは未経験です)
- 継続的にアプリがリリース可能な状態を維持する責務 - 機能要件の開発工数を確保するため、最低限の工数でバランスをとって上記を実施する責務
参画時に課題を認識し、それに対して解決策を考え実行しました。 ### 参画時に認識した課題 - 技術的なissueの優先度づけがされておらず、エンジニアが「必要だと思った順に対応していく」という暗黙のルールによって運用されていた - 結果、エンジニアがやりたいと思ったissueのみ対応されており、優先度の高いissueが放置されていた(期限のある課金ライブラリのアップデートなど) - コードレビューに関するルールが言語化されておらず、水掛け論的な議論で不必要にコードレビューの時間が不要に長くなっていた(100以上のポストがあるPRなどが散見された) - チームのコミュニケーションが極端に少なく、改善に関するディスカッションが起こりづらい状況だった ### 実行した解決策 - 「技術的なissueもPdMが握っている機能要件のissueと同等に開発計画に載せるべきだ」と考え、期限とインパクトを文章化しつつ優先度付けを実施した。その上で4半期ごとにPdMへの申し送りを実施し、開発計画に載せるようにした。 - 反動として「開発速度を保つために必要なリファクタリング」などが抑制され過ぎてしまったため、月1日「エンジニア目線でやるべきだと思ったコード整備をする時間」を設けてバランスを取った - コードレビューに関するルールをガイドラインとして文書化し、「rejectすべき基準に達していない議論事項についてはIMOとしてコメントする(リリースブロッカーにしない)」「変更が大きいPRの場合、同期的な質疑応答を含むレビュー会を実施する」などのルールを整備した。結果として、定性的な測定ではあるが、リリースまでの速度を早めることができたと評価された。 - 自主的にチームメンバーとの1on1を実施しコミュニケーションの強化を図った。 - 私の立ち位置が「グレードが周りのエンジニアより一段階高い実質的なリーダーだが、職位の上では他のメンバーと同じエンジニア」という難しいものだったため、メンバーからの反感を買わないようにコミュニケーションを工夫した。 - ディスカッションする際に「理論」と「感情」を分けつつ、その両方を大切にする仕事の進め方を心がけた。

アピール項目


アウトプット

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

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

未入力です

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

未入力です

キャラクター

直近で一番やりたいこと
マネジメント力を上げたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
風通しの良さや意思決定ライン
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 勉強会でLTをよくする
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

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

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

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

  • {{error}}
SIGN UPSIGN IN


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