roana0229

# 概要 （興味を持っていただき詳細は面談の中で話せればと思い、読み取りやすいように箇条書きで記載しています。） - 仕様を固めることを含め、新規開発開発〜現在（記載時点で3年目）運用保守のAndroid/iOS開発チームリード - 主にはiOSアプリ側の開発をしています。 - マルチデバイスのため、他デバイスとの開発連携 - ユーザ行動分析・データ設計 - PM・デザイナー・マーケターとの連携 # チーム規模 - エンジニア: 6~8人 - アプリ専任PM: 2人 - アプリ専任デザイナー: 2人 - その他デバイスでも同じような構成、デバイス間の情報連携は開発リード＋デザイナー＋PMが関わるため、20~30人規模 - これに加えて他事業部の人との連携もある # 利用技術 - アプリ開発: KMP + Swift + Kotlin - CI//CD: GitHub Actions + Bitrise - 分析: BigQuery # やってきたこと ## ■新規開発アプリ設計 - VIPERアーキテクチャを採用 - かなりの画面数があったため、開発初期段階で新規画面作成のSoruceryテンプレートを作成 - ViewはHostingViewControllerを利用してSwiftUIで開発 - 開発初期の頃はまだフルSwiftUIで作るには経験・世の中の知見が足りず、プロジェクトを成功させるために、フルSwiftUIは見送り - OS間で共通のビジネスロジックはKMPで開発 - KMPでUseCaseを作成し、iOSからはCombineで利用できるようにrickclephas/KMP-NativeCoroutinesrickclephas/KMP-NativeCoroutinesを利用 - Swift Concurrencyの導入 - 初期はCombineが主流だっため、ベースはCombineになっている - 機能として分離しやすかった動画のダウンロード機能でConcurrencyを導入、その後、新規画面開発で積極的に利用 - 最重要な動画プレイヤーを中心にユニットテストを導入 ## ■行動分析のためのデータ設計・保守 - Web含め、マルチデバイス対応なサービスのため、横断して分析しやすいような情報設計 - 基本はGA4公式の推奨イベントを利用 - 分析情報設計しつつ、実際にBigQueryでクエリを書いています。 - 何かの施策案が出るときに数値を元にしていないことも多く、優先度を裏付ける補足情報としても利用しています。 - 分析情報の期待値を満たしているか検証するために自動でUI操作しログをチェック - iOSだけでなく、Android/iOS両方で利用できるようにするために、Maestroを採用 ## ■チームメンバーの生産性維持・向上 - チームの意識合わせ - 関係者が多く、一次情報が自分含めリーダーへ共有される組織体制のため、その中から必要な情報をメンバーへ共有 - 施策単位でメンバーへリードを移譲することで、メンバーの成長含め、自分がボトルネックにならないように権限移譲 - レビューの属人化傾向にあったため、PR内容を共有＋同期的に集まってレビューする取り組み実施 - 自動化 - Four Keysを元に生産性を測るための情報を付与 - QAやリリースに必要なビルド、リリースノートを作成 # 課題に感じている/いたこと - 自分が抜けてもチームが回るようにするためのチーム育成 - できる限り権限移譲しているが、自チームだけでなく他事業部まで関わるため、関係する事柄が多い

# 概要 - 2年ほどアップデートされていなかったReactNativeプロジェクトの運用判断 - 運用継続のためのSwift移行、新規機能開発 - ライブ配信アプリの運用保守 # 利用技術 - アプリ開発: Swift + React Native - CI//CD: Bitrise - 分析: BigQuery # やってきたこと ## オンラインサロンアプリのReactNative -> Swift移行 - Appleからのリジェクトにより開発が止まっていたReact Nativeプロジェクトを運用再開 - ビジネス的にモバイルアプリが必要と判断されていて、どのように運用するかを検討 - ReactNativeができるエンジニアの採用が難しく、今後の運用を考えるとSwiftへ移行するのが良いと判断 - Swift移行の計画立て - フルリプレイスは長期間要するため、部分的な移行を計画を立て、エンジニア以外にも共有し、採用 - 部分的な移行のためReactNative自体のバージョンも最新に追従 ## ライブアプリの運用保守 - ライブ配信が安定していない状況だったため、どのような問題が起こっているかの状況把握 - 今までは問題が起こったベースでAWS MediaLiveに出力されていた動画データをみて調査していた - アプリ内でネットワークや送信された動画情報がどうなっていたか分からない状況だったため、まずはアプリで起こっていることを把握できるようにデータの送信し、そのデータをLookerで可視化 - 結果として、単純なネットワーク問題、特定の動作による不具合などが事実ベースで判断できるような状態を実現 - CI/CDが準備されておらず、手動での運用だったため、最低限の自動化 # 課題に感じている/いたこと - Swift移行するにあたって、QAやテストを行い品質の維持をする必要があるが、テストはなくQA項目も明確にはなかったため作成したが、それを実施すること自体に時間もかかってしまっている

# 概要 - 2014年頃から現在（2024年）も個人で運用しているアプリ [iOS](https://apps.apple.com/jp/app/%E3%82%B3%E3%83%9F%E3%83%9E%E3%83%83%E3%83%97/id775148131) / [Android](https://play.google.com/store/apps/details?id=com.app.cmap) - 自分が参加するイベントで使いやすいアプリがなく、紙を利用している人も多かったため、自分で開発 - 機能が小さいプロダクトで、ユーザが一定数いるからこそ１つのプロダクトに対して、色々な方向性で技術を試すことができている - ストアのレビューも基本的には各イベント前にすべて対応し、フィードバックの声を聞きつつアプリを維持していける程度に取り入れ、各ストアで高い評価を維持 - 実際に利用していた方がtogetterまとめを作られてくださっていました。今はUIも多少変わっていますがアプリ自体の雰囲気も伝わると思います。 https://togetter.com/li/1255852 # 利用技術 - Objective-C, Java -> ReactNative (with ExpoKit) -> KMP + Compose Multiplatform - Google Apps Script # やってきたこと ## クライアントアプリの変遷 - 個人で管理していくため、アプリのコンセプトである「自分の行きたいスペースをマップ上で把握できる」ために必要な機能を最低限実装した状態でリリース - リリース初期は後述するデータ管理を仕組み化せず、まず需要を確認するためかなり愚直に作成しました。 - そこから大きく機能を変えることなく、現在も細かな改善を継続しています。 - 社会人になってから継続してメンテナンスをしてくには収益化する必要があると考え、フリーミアム形式での課金を導入 - 同じくメンテナンスを継続するために、当時クロスプラットフォームとして有力なReactNativeへ移行、このタイミングで初めてTypeScriptを本格的に触りました。 - 他にもOTAなどの機能が魅力だったため、ReactNativeを採用しました。 - 仕事で主に使っていた技術はSwift/Kotlinであったこと、当時のReacNativeの進化スピードも早く変更量が多かったこともあり、キャッチアップが難しくなってしまっていたため、2023年末に普段から扱っている技術に近いKMP + Compose Multiplatform へフルリプレイス ## クライアントアプリで利用するデータ管理・生成 - アプリとして主な機能は、入力した識別子を元に会場マップ上の座標を特定する機能であり、画像生成と座標情報を一括管理するために、GoogleSpreadSheetsを利用 - Swiftで画像生成＋座標json生成するスクリプトを作っていて、アプリにはそれらのデータを埋め込み、ネットワークなしでの利用を可能にしています。（コミックマーケットの会場ではネットワーク回線が遅いことが多いため） - 他に必要な情報はFirebase RemoteConfigで管理をしています。

# 概要 - 既存でWebで提供しているサービスのiOSアプリを作るため、ワイヤーフレームを作成するタイミングからプロジェクトに参加 # チーム規模 - エンジニア2人 - デザイナー1人 - ディレクター1人 # 利用技術 - Swift # やってきたこと ## チームでの動き方に関して - 基本的にはWebの体験をベースにしつつ、整理してアプリに適したUIにし、ワイヤーフレームが完成したところで、デザインと並行して開発 - ワイヤーフレーム完成前はアプリの技術的なベースのところを詰めていました。 - ネイティブアプリは会社としてノウハウが少なく、デザイナーもiOSアプリは初だったため、HIGの共有や実際にどういう風にレイアウトを組むのかイメージを掴んでもらうための勉強会などを行い、アプリの特徴を掴めるように進行 - 開発中は「仕様を叶えることが難しいと思ったときの代替案」や「デザイナーが提案するデザインの叶えたいことをそのまま叶えられるか、本質を変えないまま工数を減らして作れる方法があるか」などを意識して進行 - 開発が進みアプリの主軸ができてきたところで、エンジニア以外も実機で触れる環境を作り、フィードバックを出しやすいようにしていました。 - 最終的に、初期リリースとしては十二分と思える状態で予定通りのリリース - 初期リリース後は、社内の分析基盤を利用してKPIをウォッチできるようにRedashのダッシュボードを作ったり、施策を詰めるためのSQLを使った数値分析を行いながら、施策の要件を詰めていくタイミングから参加 - GitHub Projectsでのタスク管理を管理しつつ、GitHub Releasesにリリースログを残し、開発以外の人も管理コストを減らす＋エンジニアも開発以外の管理に時間をかからないようにして、エンジニア1人での週1リリースサイクルを回していた ## 開発に関して - 前提として、APIやデザインも並行して進んでいき、両OSを見越した開発をしておく必要があり、以前に既存プロダクトの改善を回していた際に、差分が大きくなりがちでレビューコストが高くなっていたため、同じ問題を抱えないようにするため以下を意識し設計 - アプリの設計はMVVM + Clean Architecture構成 - View <-> ViewModel間はRxSwiftを使ったデータバインディング（Androidは公式で機構が用意されているため） - APIにはSwagger(現在はopenapi-generator)を利用し、yamlからAPIクライアントを自動生成（Androidでも同じ定義から生成できるようにするため） - 2ステップ以上離れた画面では、EventBusをラップして利用し、乱用されないために記述できる箇所を制限した仕組みにして画面間同期 - ViewModelのテストを書くことで画面の正しい状態を保持 - これによって、APIやデザインを順次適応していく際の差分がハッキリと別れ、低いレビューコストで進めていくことができました。 - 他にも、社内での配布やリリースサイクルを自動化するためにFastlaneを整備し、人力運用コストを下げる - 弊社のネイティブアプリでは初のCI導入で、CIに関しての細かい内容は[こちらのブログ](https://made.livesense.co.jp/entry/2019/05/31/070000)に記述しています。

# 概要 - 新卒で入った際に初めて参加したプロジェクト # チーム規模 - エンジニア4人（うち、未経験2人） - ディレクター1人 - デザイナー1人 # 利用技術 - Android (Java) # やってきたこと ## チームでの動き方に関して - 施策のベースはディレクターが考え、それに対してチーム全員で意見を出し合いながらブラッシュアップしていく形で進行 - 施策の要件がある程度固まったら、ミニマムで動くものを作って共有したり、デザインも並行で進む中でこちらから少ない工数で開発できるデザイン案を提案し、イメージのすり合わせこまめにを行う ## 開発に関して - 大学時代からAndroid/iOSの開発を行っていたため、基本的な技術はあり、既存プロジェクトを理解すること、改善することを主としていた - 既存プロジェクトのコードは、現状のプロダクトの開発状況には合っていない設計(MVC)になっていたり、初期の設計意図が伝わらないままコードが積み重なっている状況 - 複雑に複数の機能が依存してしまっていたため、品質を保ったまま開発スピードを維持していくことが難しい状態になっており、設計リプレイスをする方針で進行しました。 - アプリの行動フェーズをいくつかに分割すると、「求人を探す」「応募する」「応募後のやり取りをする」フェーズに別けられ、今後改善を回す中で効果やスピードを求めるであろう「応募する」フェーズの設計をリプレースすることに決め、改善後の設計を考えメンバーからフィードバックを受けた上でリプレースを進行 - 既存コードはModel層を担うクラスがDBモデル以外には明確に別れておらず、Viewから直接DBの変更や非同期通信処理を呼び出したコールバック処理たちが無造作に行われていました。 - 各層の役割を意識する、ユーザのアクションから行われる処理の流れを追いやすくするため、改善後はMVP+Clean Architecture構成で、DataBindingと非同期通信にはRxJavaを採用しました。（このときはまだAndroid公式がDataBindingをサポートしていませんでした。） - 当時RxJavaは非同期通信で利用されていたAsyncTaskの置き換えポジションとして使われていた印象が大きかったのですが、個人的には処理フローを宣言した上でそのフローに沿ってデータが流れる事自体に大きな恩恵があると思い採用をしました。 - リプレイスのための技術導入にあたって学習コストが必要になるが、リプレースの基準となるPRをメンバー全員がレビューし、認識をすり合わせた上で各メンバーもリプレース開発を進行 - 最終的には全体の設計を改善しつつ、施策も止めずに開発を進めました。 - また、Rails製のAPIもチームでメンテナンスしていて、必要に応じて機能の追加や修正をする程度の開発を行っていた。