ID:74493さん

3年後の目標や野望


技術力のあるエンジニアとして認知される

技術力のある人に技術は集まると考えている為。 最新技術のIO ベース知識のインプット(コンピュータサイエンスなど)

プロジェクト経験

2022年/半年以内

ライブ配信アプリ

■ライブ配信アプリ ユーザー数 2万 <<案件概要>> (状況) ユーザー数の増加や機能拡張に対応できるよう、アプリ全体のスケーラビリティを高める必要がありました。しかし、当初の実装は命令型UI(XMLベース)と一部複雑化した構造が残っており、コードの可読性・再利用性・保守性に課題がありました。そのため、宣言的UIへの移行、機能単位でのリファクタリング、データストリーム設計の見直しを通じて、将来的なスケールや継続的開発に耐えうる構造へ改善を図りました。 (課題) コードの構造をスケーラブルかつメンテナブルに再設計し、今後のユーザー増・機能追加に伴う開発コストや障害リスクを最小化すること。&#x2028;(行動)&#x2028;・命令型UIから Jetpack Composeによる宣言的UIへ段階的に移行 ・UIと状態管理の結合度を下げるため、ViewModel / UseCase / Repository の責務を明確化し、アーキテクチャを再設計 ・各機能単位での 分離可能なモジュール設計 にリファクタリング(Clean Architectureをベースに構築) ・イベント処理・非同期データフローに関して、RxJava → Kotlin StateFlow への全面的な置き換えを実施し、フローのシンプル化と学習コストの低減を実現 (成果) レガシーコードの置き換えを行い、今後の実装において、拡張性を持たすことができました <<担当業務>> ・要件定義 ・基本設計・基本設計書作成 ・詳細設計・詳細設計書作成 ・実装 <<習得スキル>> ・Jetpack Composeによる宣言的UIの設計・実装スキル ・ViewModel / UseCase / Repository を用いた責務分離と状態管理のアーキテクチャ理解 ・Kotlin Coroutines / StateFlow による非同期データフローの構築スキル ・RxJavaからStateFlowへの置き換えに伴うデータストリーム設計の再構築経験 ・Clean Architecture に基づいた機能単位のモジュール分割およびリファクタリング実践 ・Androidアプリにおける拡張性・保守性を意識した設計・改善の知見 <<コメント>> ・Jetpack Composeによる画面設計・実装を1から行う中で、宣言的UIの理解が深まり、UI状態とデータフローの関係性に対する知識がより一層高まった ・アーキテクチャや設計方針の見直しを推進する中で、技術的な背景や意図を理解することで、実装への自信に繋がった

2022年/2年以上

商業系施設アプリ

■商業系施設アプリ <<案件概要>> ユーザー数 4万 (状況) 本アプリは、商業施設における情報発信やクーポン施策の集約管理を通じて、来館者の利便性を高め、施設全体の売上および回遊性を向上させることを目的としています。さらに、従業員・関係者への福利厚生的な価値提供も兼ね備えることで、関係者を含めた経済圏の形成を志向しています。 その波及効果は、施設内の一部ユーザーにとどまらず、利用者・テナント・運営者といった複数のステークホルダーに利益をもたらす「和」のような広がりを持ち、地域経済全体を活性化するプラットフォームとしてのポテンシャルが期待されています。 (課題)&#x2028;プロダクト課題 アプリ上における主要サービス(クーポン、イベント、施設情報など)の導線がユーザーに十分認知されておらず、本来誘導したい施策に結びつかないという課題が顕在化していました。 特に、クーポンやイベントといった“利用促進型コンテンツ”が機能として存在していても、ユーザーに届いていない/発見されていない状態が続いており、施策の実行効果が限定的なものにとどまっていました。 また、新規ユーザーにおいては、アプリ初回起動時のファーストビューで価値が伝わりきらずに離脱するケースが多く見られ、オンボーディングや初期導線の設計そのものに見直しが必要な状況でした。&#x2028;技術的課題&#x2028;上記のプロダクト課題の背景には、画面単位で個別に実装された情報表示ロジックにより、UIコンポーネントの再利用性が著しく低いという、アーキテクチャ上の非効率性が存在していました。 特に、各機能ごとの責務分離が不十分であり、UIとロジックが密結合となっていたため、新しい施策ごとにUIを都度ゼロから実装せざるを得ない構造となっていました。 さらに、画面状態(ステータス)の設計が統一されておらず、画面遷移やデータ取得の分岐処理が場当たり的に実装されていたため、コードの可読性・保守性が低下し、チーム全体としても仕様変更に柔軟に対応できない課題が顕在化していました。 (行動)&#x2028;上記課題に対し、画面設計・情報構造・状態管理の3軸からアーキテクチャを抜本的に見直す取り組みを主導しました。 まず、画面の構造を機能単位でモジュール化し、UIコンポーネント・ビジネスロジック・状態管理をそれぞれ責務ごとに分離。これにより、再利用性の高いUI設計と、施策単位での迅速な画面構築が可能な土台を整備しました。 また、画面ごとの状態(表示・取得中・エラー・空など)を統一的な定義で扱えるステータス管理の仕組みを構築し、各画面の状態遷移の整理・簡素化を実現。さらに、施策ごとの表示制御を動的に管理できるように設計することで、マーケティング施策のタイミングや対象条件に応じた柔軟な出し分けを可能としました。 チーム全体にもその設計思想を展開し、設計書やUIコンポーネントライブラリの整備、チーム運用面でも拡張性と再現性のある開発体制を築きました。 (成果) これらの取り組みにより、ユーザーの行動導線が最適化され、クーポン利用率は従来比で25%向上。初回起動時の情報設計改善により、ファーストビューでの離脱率も30%改善し、新規ユーザーの定着率向上に貢献しました。 技術的にも、アーキテクチャの整理と状態管理の一元化により、仕様変更や新機能追加時のバグを抑制できた結果、Firebase Crashlyticsのエラー検知率100%を年間通して維持するなど、プロダクトの安定性と品質担保にも大きく寄与しました。 <<担当業務>> ・要件定義 ・基本設計、基本設計書作成 ・詳細設計 ・モック画面作成 ・実装/レビュー&#x2028;・単体テスト ・運用保守 <<習得スキル>> ■ アプリケーション開発(iOS / Android共通 ) UI/UX設計(情報導線最適化、初回導線改善、再利用UIコンポーネント設計) アーキテクチャ設計(MVVM、Clean Architecture、状態管理の統一と分離) Firebase活用(Crashlytics、Performance Monitoring、Remote Config) チーム開発(Git / GitHubベースのレビュー運用、設計ドキュメント整備、技術ナレッジ共有) ■ Android 開発 実装経験:Kotlin(Jetpack Compose、StateFlow、Navigation Component) 開発基盤構築:DI、モジュール分離設計 品質監視:Logcat分析、ANR解析、Firebase Performance活用 ■ iOS 開発 実装経験:Swift(SwiftUI、Combine、ObservableObject、@State / @Published) アーキテクチャ:MVVMに加え、Fluxアーキテクチャの要素を取り入れた状態管理と一方向データフロー設計 状態制御:Store、Action、Reducerを明確に分離し、画面遷移・UI更新の一貫性を担保 <<コメント>> 本プロジェクトを通じて、UI/UXの根本設計からアーキテクチャの最適化、品質改善、チーム開発体制の整備まで、アプリ開発の全工程に横断的に携わりながら、iOS・Androidの双方で実装および技術ディレクションを担当してきました。 単なるコード実装にとどまらず、ユーザー行動に基づいた課題発見・施策設計・データ検証のサイクルを意識しながら、プロダクトの価値最大化に貢献できるモバイルエンジニアとしての実績とスキルを体系的に習得しています。

2024年/1年以内

ビジネスマッチングアプリ

■ビジネスマッチングアプリ <<案件概要>> ユーザー数 5万 (状況) 本プロジェクトは、ビジネスマッチングアプリにおけるユーザビリティの向上と新規ユーザー獲得、さらに外部サービスとの連携拡張を見据えたアーキテクチャ刷新を目的にスタートしました。 既存のコードベースは機能追加の度に複雑化し、画面遷移・状態管理の煩雑さが目立っていたほか、クラッシュ頻度の高さによってユーザー体験を著しく損なっている状態でした。 (課題)
技術的には、使用しているライブラリのバージョンが古く、互換性や非推奨コードによるクラッシュが頻発していたほか、責務の分離が不十分で、特定機能が他モジュールに強く依存している構造が、メンテナンス性と安定運用の障害となっていました。 プロダクト全体としても、新規ユーザーに対する体験設計や、拡張性あるコード構成が求められていました。 (行動)
全体の安定性と保守性を確保するため、まず使用ライブラリのアップデートと依存関係の精査を実施。Flutter SDKおよび主要プラグインのバージョンを統一し、非推奨APIの置き換えとクラッシュ原因の修正を徹底しました。 並行して、機能ごとの責務分離と状態管理を行い、各画面・処理単位で再利用可能なWidget/Provider構成を構築。加えて、外部サービス連携部分もモジュール化し、API連携・バージョン管理が容易な仕組みへと刷新しました。 (成果) これらの取り組みにより、アプリのクラッシュ率は改善。外部連携の拡張性が向上し、複数の新規API統合もスムーズに対応できる体制を実現しました。 <<担当業務>> ・要件定義 ・基本設計、基本設計書作成 ・詳細設計 ・モック画面作成 ・実装/レビュー
・単体テスト ・運用保守 <<習得スキル>> Dart(Flutter)主要ウィジェットによるUI構築、カスタムWidgetの再利用設計 状態管理:Riverpod、StateNotifier、Providerを用いた責務分離・一元管理設計 <<コメント>> 本プロジェクトでは、Flutterのクロスプラットフォーム特性を活かしながら、アーキテクチャ再設計・ライブラリアップデート・外部連携対応・UI/UX最適化を横断的に推進しました。 技術的負債の解消にとどまらず、今後の成長フェーズに向けた拡張性・安定性の高い基盤構築をリードした経験は、モバイルアプリの持続的成長を支える実践力として活きています。

マネージメント能力

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

アピール項目


アウトプット

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

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

未入力です

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

未入力です

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
未入力です
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
年収が第一
やりたくない分野
未入力です
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代中盤
好きなテキストエディタ
androidstudio(IDE)
希望勤務地
東京都
希望年収
未入力
ご意見箱

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

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

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