roana0229

2014年頃から現在（2024年）も個人で運用しているアプリです。Android/iOSともにリリースしています。 https://apps.apple.com/jp/app/%E3%82%B3%E3%83%9F%E3%83%9E%E3%83%83%E3%83%97/id775148131 https://play.google.com/store/apps/details?id=com.app.cmap ## クライアントアプリの変遷 自分が参加するイベントで使いやすいアプリがなく、紙を利用している人も多かったため、自分で開発しました。コミックマーケットだけでなく、会場の中で複数の参加グループがあるイベントなど同じ形式のイベントでも対応できるようなものです。 個人で管理していくため、アプリのコンセプトである「自分の行きたいスペースをマップ上で把握できる」ために必要な機能を最低限実装した状態でリリースを行い、そこから大きく機能を変えることなく、現在も細かな改善を続けています。 初期は、Objective-C(Swiftが出てきて移行),Javaと両OSネイティブ開発で開発していました。この時にSwiftのバージョンアップ移行なども対応していました。 運用していく中で、両OSネイティブで開発をしていくのが厳しくなり、ReactNative(ExpoKit)にリプレースしました。 両OSでViewは少し違うも同じ機能を持たせていたため、機能的には大きく変えず、今後継続的に課金で収益を建てられるように仕様を整え、運用しています。 ReactNativeを選択したのは、純粋にクロスプラットフォームに興味があり、OTA配信での臨機応変な対応がしやすいからでしたが 実際には導入してみると、ReactNativeにはOS間での動作が違う難しさ、OTA配信は決してリリースが簡易になるわけではないということを実感しました。それでも、今まで触ったことのなかったTypeScriptの知識を付けつつ、イベント日に合わせた修正も各ストアに依存しにくくOTA配信により対応しやすくなり、良い状態になりました。 そこから2年ほどReactNativeで運用していると、普段触らない技術のキャッチアップやReactNative自体のアップデートについていくことが難しくなり、2023年末に普段から扱っている技術に近いKMP + Compose Multiplatform へフルリプレイスしました。 機能が小さいプロダクトで、ユーザが一定数いるからこそ１つのプロダクトに対して、色々な方向性で技術を試すことができています。 ## クライアントアプリで利用するデータ アプリ内でマップを提供する際に、GoogleSpreadSheetsを元データにしていて、APIとしてその情報が利用しやすいため、バックエンドはGoogleAppsScriptを利用してAPIを提供しています。 GoogleSpreadSheetsを使っている用途としては、アプリ内で利用する画像がエクセルのような格子状になっている座標情報が必要で、GoogleSpreadSheetsを元にJSONデータを生成しています。 そのJSONを元にクライアントアプリとは別でSwiftを使い画像を生成しています。 必要なデータは RemoteConfig + GoogleAppsScript をサーバとして、クライアントで情報を利用できるようにしています。 ## 備考 またストアのレビューも基本的には各イベント前にすべて対応し、フィードバックの声を聞きつつアプリを維持していける程度に取り入れ、各ストアで高い評価を維持し続けています。 実際に利用していた方がtogetterまとめを作られていたりしました。今はUIも変わっていますがアプリ自体の雰囲気も伝わるかと思います。 https://togetter.com/li/1255852

## チームでの動き方に関して 既存でWebで提供しているサービスのiOSアプリを作るため、ワイヤーフレームを作成するタイミングからプロジェクトに参加しました。 関わる領域はプロダクトのフェーズによって変えていて、新規開発だったため「どういうアプリにするか」を決めるところから参加しています。エンジニア・デザイナー・ディレクター含め4人ほど。 基本的にはWebの体験をベースにしつつ、整理してアプリに適したUIにし、ワイヤーフレームが完成したところで、デザインと並行して開発を進めました。 ネイティブアプリは会社としてノウハウが少なく、デザイナーもiOSアプリは初だったため、HIGの共有や実際にどういう風にレイアウトを組むのかイメージを掴んでもらうための勉強会などを行い、アプリの特徴を掴めるように進めました。 この間にアプリの設計の大枠を練り、必ず作るであろう画面をサンプルとして作り、社内の他のアプリエンジニアのレビューを経て、設計を固めました。 開発中は「仕様を叶えることが難しいと思ったときの代替案」や「デザイナーが提案するデザインの叶えたいことをそのまま叶えられるか、本質を変えないまま工数を減らして作れる方法があるか」などを意識していました。 開発が進みアプリの主軸ができてきたところで、エンジニア以外も実機で触れる環境を作り、フィードバックをできるようにしました。 最終的に、初期リリースとしては十二分と思える状態で予定通りのリリースをし、引き続き開発を行っています。 このフェーズになると開発を重視しながら、施策は要件を詰めるタイミングから参加するようにしています。 また改善していくために、社内の分析基盤を利用してKPIをウォッチできるようにRedashのダッシュボードを作ったり、施策を詰めるためのSQLを使った数値分析を行っています。 ## 開発に関して 前提として、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 GitHub Projectsでのタスク管理を管理しつつ、GitHub Releasesにリリースログを残し、開発以外のことに時間をかからないようにして、エンジニア1人での週1リリースサイクルを回していました。

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