ID:64502さん

3年後の目標や野望


スマホアプリ開発においてアーキテクチャを任される人間となりたい

アプリケーションの基礎となる土台となるアーキテクチャをしっかりと設計することにより、 技術的負債を少なくし、ビジネスを加速させることができると考えています。 現在MVVMやFluxを案件内・個人開発でも実践しようと勉強しつつ、試行錯誤をしています。 将来的にはテックリード的な立ち位置を社内で確立し、案件としてではなく、社全体の取り組みとして実践していけたらと考えています。

プロジェクト経験

2022年/1年以内

合コンマッチングアプリ

# 案件概要 合コンの開催日・人数を決めてマッチングをしてもらうサービス メジャーなマッチングアプリよりカジュアルなマッチングアプリを目指してサービスを展開していました。 # チーム構成人数(Flutter側) 4人 # 開発環境 - Flutter - Dart - openAPI # 業務担当内容 ## プロジェクトマネジメント - WebViewからFlutterネイティブへのリプレイス - リプレイス案の作成からスケジュール作成、事業部側への提案とプロジェクトを推進する合意形成 - チームメンバへのクリーンアーキテクチャ(feature first)の浸透 ## 実装 - 既存のWebViewの機能のリバースエンジニアリング - 初期設計・アーキテクチャ・仕様・パッケージ選定を担当 ## 開発環境の整備 - openAPIをチーム内、事業部内(サービス運営側)への浸透 ## 機能実装 - 検索(会員一覧)画面 - 新規会員一覧画面 - おすすめメンバー画面 - 検索条件画面 # 課題 1. 多国籍でチーム内の人間が自分以外エンジニア経験年数が浅い 2. チーム内のルールが何も決まっていない 3. Flutter自体の有識者が社内に不在 4. アプリメインのサービスのはずなのにアクティブユーザ数が100人未満 # 課題の解決 1. とにかく質問をしやすい環境・空気作りに専念した。 2. レビュールールやコード規約をとにかく徹底、週一のスプリントではチーム内に決定事項の議論通達を行った。 3. 自身がチームの手本となるように積極的なキャッチアップを行った。週一のスプリントではFlutterのWidgetの説明や実装例を共有 4. ユーザの使用率が一番高い検索(会員一覧)画面をFlutterネイティブにする事によりアクティブユーザ数の向上を図った # 成果 1. 自分の実装時間が削られはしたが、チームメンバの効率は飛躍的に向上、1日一回は必ずPRを提出する文化が出来上がった。 2. analysの強化も図りlintエラーをinfo含め0件まで減らすことができた。それに伴いレビューのリードタイムも減少 3. チームメンバの意識向上のために行っていたが、改善することは叶わなかった。ただ自身のスキルが飛躍的に向上 4. 日々のアクティブユーザ数が最終的には平均3000人まで向上した

2020年/2年以上

バックアップアプリ開発プロジェクト

# 案件概要 - 自社開発でスマホアプリ(Android/iOS)及びWEBの機能追加案件を担当していました。 # チーム構成人数 - 2〜4人で構成 # 開発環境 - PHP(自社フレームワーク) - ReactNative(js, ts) - 一部AndroidJavaとSwiftで独自実装 - GCP - Firebase # 業務担当内容 ## PM業務 - 新規機能追加の際に営業との要件調整、リリース時期の調整、機能提案。 ## 機能実装 - 主にスマートフォンアプリエンジニアとしてスマホ⇄APIの機能実装業務をメインに機能の実装を担当。 - チームメンバが限られていたため、WEBのバックエンド・フロントエンド機能実装も担当 ### 実装内容 - バックアップ機能 - 復元機能 - インフラ(GCP)コスト削減のための設定 - firebaseを使用した機能(analytics/crashlytics/cloud-messaging/in-app-messaging) - sentryでのエラー情報収集機能 - アプリ内課金機能 - WEBでの課金プラン変更機能(キャリア決済) - 管理画面機能 - アプリのギャラリーフォト化 # 課題 1. アプリのFWにReact Nativeを使用していたが、Reactの規則に則っていない作りだったため、改修の負担による手間が大きかった  2. 営業・顧客とのやり取りできる社員が少なく、PMが他のPMと掛け持ちしていたためその社員への負担が大きかった 3. PMが他のPJと掛け持ちだったため円滑な意思決定をすることが出来なかった 4. マーケティング政策を行えるプラットフォームが不足していた # 課題の解決 1. 社内のフロントエンド有識者と共にFluxアーキテクチャの導入を進めた 2. 業務領域を限定せずに、アプリ・WEB・APIの上流〜下流工程の業務全般・アプリの申請作業を自分で行いました。 3. PMが不在なことが多く営業とのやり取りを自分が行い、決定事項のみを伝える様組織を作り替えました。 4. マーケティング企画案等は営業に一任し、普及作をアプリでin-app-messagingおよびプッシュ通知機能を導入をおこなった。 # 成果 1. 各画面毎に管理されていた状態がアプリケーション全体で管理出来るようになり開発体験が向上した。 また、ビジネスロジックと画面を切り分けたことにより開発による不具合が減少した。 2. PMが管理していた部分をこちらで請け負うことによりPMの負担を減らすことが可能となった。 3. 上記同様PMの腐乱を減らすことに成功した。 4. キャンペーン施策を会員に対して通知出来ることが可能になり会員の不満点・解約理由などを素早く察知することが可能となった。

2021年/3ヶ月以内

ニュースサイト閲覧アプリ開発プロジェクト

# 案件概要 - 受託開発でスマホアプリ(Android/iOS)の保守・運用案件を担当しております。 # 開発環境 - ReactNative(ts, js) # 業務担当内容 ## PL業務 - 不具合修正に伴うアーキテクチャの導入(flux) ## 機能実装 - 主にスマートフォンアプリエンジニアとしてWebView機能を利用したアプリ開発を担当。 ### 実装内容 - WebView機能の共通化 - Fluxの導入 # 課題 1. アプリのFWにReact Nativeを使用していたが、Reactの規則に則っていない作りだったため、改修による手間が大きかった  2. 外部に委託した案件だったため、アプリの仕様を深く理解しているメンバーが不在だった 3. ソースコードが整理されておらずインデント・改行に規則性がなかった # 課題の解決 1. アプリの状態管理がアプリ全体でされていない状態だったため、Fluxを導入することによりアプリの状態管理を可能にした 2. ソースコードを読み解きアプリの仕様を理解した 3. フォーマッタ及びリンターを導入しソースコードの一貫性を担保した # 成果 1. 第三者でも開発がしやすい環境づくりを敷くことが可能となった。 2. アプリの仕様について説明出来る人員として立場を確立することができた。 3. プロジェクト共通で誰が書いても一貫性が持てるソースコードが書けるようになった。 # 実践したこと・結果 - Fluxの導入により開発体験の向上をはかることが出来た。

2020年/半年以内

オークションサイト開発プロジェクト

# 案件概要 - 受託開発でスマホアプリ(Android/iOS)の保守・運用案件を担当しております。 # 開発環境 - Nest.js - Next.js - Docker # 業務担当内容 ## SE業務 - 設計・実装・ローカルテスト・PR提出までの工程 ## 機能実装 - 主にフロントエンドエンジニアとしてAPIのCRUD機能をメインに担当。 ### 実装内容 - NestJSとAuth0-Hasuraを使用したユーザ情報機能作成 - オークション情報の作成・編集・削除機能 - 管理者ユーザ情報の作成・編集・削除機能 - その他新規機能

2024年/半年以内

婚活アプリFlutterリプレイス

# 案件概要 日本最大級の婚活お見合いアプリのSwift(UIKit), AndroidJavaからFlutterへのリプレイス # チーム構成人数(Flutter側) 4人 # 開発環境 - Flutter - Dart - openAPI # 業務担当内容 ## プロジェクトマネジメント - リプレイス案の作成からスケジュール作成、事業部側への提案とプロジェクトを推進する合意形成 - チームメンバへのレイヤードアーキテクチャの浸透 ## 実装 - 既存のWebViewの機能のリバースエンジニアリング - 初期設計・アーキテクチャ・仕様・パッケージ選定を担当 ## 開発環境の整備 - APIdogを導入し、既存APIの仕様をチーム内に共有、最終的にはopenAPIに変換する事により事業部側へも展開予定 ## 機能実装 - 検索(会員一覧)画面 # 課題 1. 前回のプロジェクトメンバーが全員退職しメンバーが一新したため再度教育から開始 2. リプレイス元のサービスを理解している人員がチーム内に不在 3. リプレイスの期限が非常に短い # 課題の解決 1. 前回のプロジェクト同様とにかく質問をしやすい空気作りに徹した。また、自身への指摘も積極的にしてもらう事により当事者意識を持たせた。 2. 自身がフロントに立ちチームメンバとサービス運営側との橋渡しを担当。コミュニケーションを密にした。またチームメンバには自身が記述した部分のdocコメントを正確かつ簡潔に書いてもらうようにした。(コードを設計書としてみれるレベルにした) 3. 自分は最低一年半と考えているがサービス側は一年じゃないと意味がないと考えている。そのため最初はとにかく動くもの(デザインコーディング)を作る事を優先させた。 # 成果 1. 新入社員や経験年数が浅い人間でもアーキテクチャ設計を理解できるようにドキュメントを残し共有 2. なぜ書いたか、何をしているか等コードを読めばDartを読める人間だったらわかるようになった 3. まだ結果は不明

マネージメント能力

アピール項目


アウトプット

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

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

未入力です

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

未入力です

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
問題解決力 / 責任感 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
SI / 金融 / 人材 / 仮想通貨
その他の特徴
レガシーな環境を改善できる
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代中盤
好きな Text Editor
VSCode, Android Studio
希望勤務地
埼玉県 / 千葉県 / 東京都 / 神奈川県 / その他地域 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
650万円
転職ドラフトスカウトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトスカウトに参加すると、企業から年収付きの指名を受け取ることができます。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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