一人目のモバイルエンジニアとしてやってきたこと
この記事は hacomono advent calendar 2023 の21日目の記事です
画像はAIが考えた『一人目のモバイルエンジニア』です。
はじめに
hacomono でモバイルエンジニアをやっている木下です。teru と呼ばれています。hacomonoは、フィットネスクラブ・インドアゴルフ・24hジム・スイミングスクールなどの店舗運営に必要な機能を網羅した会員管理・予約・決済システムを開発・提供している会社です。
昨年(2022年)の9月に 一人目のモバイルエンジニアとして入社しPOS部というセクションに所属しています。入社してから一年以上が経過したこのタイミングで、自分がやってきたことを振り返りながら知見などを広く共有できればと思い執筆しました。
自己紹介
はるか昔、新卒で入社した SIer では制御系ソフトウェア（SEMI Standard に準拠した半導体液晶製造装置向けソフトウェア）の開発をメインで行いました。その後、企業向けシステムの受託開発事業でフリーランスとして特立し後に法人化をしました。案件としては施設予約管理システム、生産管理システム、販売管理システムなどが多かったと思います。ガラケーアプリの開発も行いました。
2008年頃から iPhone アプリとAndroid アプリの開発を始めモバイルエンジニアとしての道を歩み始めます。初期の頃は自分で企画したアプリを開発し App Store の上位にランクインしたアプリもいくつかありました。2015年からスタートアップ数社にジョインし次の領域でモバイルエンジニアとしてのキャリアを重ねてきました。
IoT
EC
VoIP
会計
入社の経緯
hacomono への入社を決めた要因は、私自身ダイエットをきっかけにジム通いを10年以上続けておりウェルネス・フィットネスというドメインに興味があったこと、直近のキャリアから toB SaaS というビジネスモデルへの関心が高まっていたこと、モバイルエンジニアとして自分のキャリアを活かしつつ大きくチャレンジできる環境であると感じたこと、hacomono のミッション・ビジョンに強く共感できたことの4点です。それぞれ深掘りすると長くなるので止めておきますが、hacomono の ミッション・ビジョン・バリュー については こちらのサイト をご覧いただければと思います。
入社直後の状況
hacomono から声をかけていただいたのが シリーズBラウンドの調達 直後で、私が入社した時点で組織的もそれなりの規模感になっていました。
モバイルエンジニアは不在でしたが、店頭でチェックインなどを行える iPadアプリ （以下「店頭アプリ」） は既に提供されていました。こちらのアプリは Webエンジニアのメンバーが開発したもので、メイン機能は WebView で実装されているいわゆる「ガワネイティブアプリ」と呼ばれるものでした。
配属となったのはPOSレジを開発するチームで既に開発は始まっていました。こちらも iPadアプリ （以下「POSレジアプリ」）として提供することが決まっており「ガワネイティブアプリ」を想定したアーキテクチャとなっていました。既に他のメンバーがブログを執筆していますが Capacitor を採用していました。Webアプリの開発は進行しており iPadアプリの基礎部分は既存の Webエンジニアにより実装されている状況でした。
一人目のモバイルエンジニアとしてやってきたこと
技術選定の確認
入社時点で既に決まっていたことを一通り確認し、プロダクトや販売戦略として適切な選択がされているかを見に行きました。
中でも難しい選択だったのが Capacitor の利用です。Capacitor の前身である Cordova の利用経験があり新OSへの対応が遅れたりメジャーな Plugin のメンテが止まったりするなどあったため、安定性が求められる toB プロダクトとして適切な選択かどうか、また hacomono や私としても実績の無い現状で安易に選択をしてよいか、の懸念がありました。最終的には開発スケジュールが決まっており手戻りしている余裕がないことと、Capacitor のメンテが鈍った時点で乗り換えの検討を始めることを条件として Capacitor を選択することとしました。
また、POSレジアプリと連携する周辺機器の選定も確認しました。こちらは某メーカーさんのレシートプリンター、バーコードスキャナーを利用することが決まっていました。他社のPOSレジでは多くの周辺機器がサポートされいる中、一シリーズの周辺機器のみで大丈夫か？みたいな不安はありましたが、一度に多くのことをするのは無理だとすぐに納得したのと、選定されていた機種はレシートプリンターを除く、バーコードスキャナやキャッシュドロワー、カスタマーディスプレイなど他の周辺機器はレシートプリンターをハブとして接続することができ、アプリとしてもプリンターのみを通信相手として管理すればよく実装的な負担も軽減できそうと考え最初にサポートする周辺機器としては適切な選定がされていると判断しました。ハードウェアの場合は安定供給可能かどうかも重要なポイントになるかと思います。
サポートOSの決定
ネイティブアプリ開発のスタートラインとして重要な「サポートOS」の決定がされていませんでした。どのiPadOSバージョンをサポートするかです。
私自身の経験や他社アプリの状況などを踏まえて「最新OSバージョン + 一つ前のバージョンをサポートする」を基準としてサポートOSを決定することとしました。リリース予定が 2023年初旬でしたので iPadOS15 以降をサポートOS として決定しました。
ちなみに既存の店頭アプリについては サポートサイトをご覧いただければ分かりますが、「推奨OS：iPadOS最新バージョン」とモバイルエンジニアからすると「えっ！？マジか…」と感じる設定となっているため、変更に向けて動いている最中です。
デリバリー方法の決定
開発したPOSレジアプリをどのように顧客（店舗様）へ配布するかも決まっていませんでした。既存の店頭アプリがどのように配布されているかを確認したところ「非表示アプリ」として配布されていることを知りました。こちらは比較的新しい配布方法で私も hacomono に入るまでは知りませんでした。
App Store で検索や直リンクを叩いても表示されず、デベロッパーが許可したユーザー（組織）やインストールコードを配布されたユーザーのみがインストール可能となる配布方法です。
PdMやチームとして配布方法を決定するために、iOSアプリの配布方法と Pros&Cons をまとめたドキュメントを作成し広く情報を共有しました。最終的には既存の店頭アプリと同様に「非表示アプリ」として配布することとなりました。一般の配布方法に比べると審査が緩いのでは？という都市伝説への期待値を含む意思決定でした。
ただし非表示アプリの場合一点大きな課題がありました。アプリをアップデートしていただくための導線が用意できない点です。一般的なアプリで強制アップデートなどを実現する場合「アプリをアップデートしてください」のメッセージと共に App Store 内の当該アプリのページへ遷移するためのボタンを表示させますが、非表示アプリの場合 App Store に表示されないためこのUIが採用できません。このため hacomono では導入時に自動アップデートを有効にすることを推奨しており、サポートサイトでは手動でアップデートする手順を案内するようにしました。
周辺機器連携の実装
前述のとおりCapacitor を採用しているため、周辺機器連携は Capacitor の Plugin として実装しました。プロダクトのロードマップでは周辺機器の対応を、(1) レシートプリンター → (2) バーコードスキャナー → (3) キャッシュドロワー → (4) カスタマーディスプレイ、と段階的に進める予定となっていましたが初期のバージョンから全ての周辺機器に対応した Plugin を実装し、アプリ(Web)とのインターフェースのデータ構造も JSON 形式として、アプリ側の実装負担もできるだけ軽減するようにしました。具体的なコードはお見せできませんが、なかなか汎用性の高い Plugin が実装できたと思います。
用語の統一
モバイルエンジニアならではというアクションではありませんが POSレジアプリの開発を進めるなかで、主に周辺機器を指す言葉にブレが生じていることに気づきました。ハードウェアメーカー各社さんや他社POSレジなど、それぞれで微妙に異なっていることに気づきました。このままでは hacomono 社内でも表記揺れが発生する懸念があったため早期に統一させるようチームに働きかけました。
具体的には キャッシュドロワーを指す言葉だけでも次の候補が挙がりましたが、hacomono では キャッシュドロワー を採用しました。
ドロア
ドロワ
キャッシュドロアー
キャッシュドロア
キャッシュドロワー
Linter の導入
Webエンジニアの既存メンバーが実装してきたこともあり、コードの記述が統一されておらずインデントもずれている箇所があったり、強制アンラップが多用されておりクラッシュの原因となっている箇所もありました。コードに統一感を持たせ可読性を高めることと、バグの可能性が高いコードを排除することを目的として SwiftLint を導入しました。
CI/CD の導入
店頭アプリ及び開発中のPOSレジアプリでCI/CD が導入されておらず、ローカルでビルドして配布する運用がされており、ビルド環境が個人に依存していたため CI/CD を導入しました。個人的にも実績が多く情報量の多い Bitrise を採用しました。また Pull Request に対し SwiftLint を走らせるために Danger も導入しました。
Firebase の導入と安定性向上
既存の店頭アプリの利用状況やクラッシュ発生状況なが一切把握できておらず、アプリがどくれくらい利用されているのか？ 安定してご利用いただいているのか？ 全くわからない状況でした。これらのデータはプロダクトやタスクの意思決定・優先順位決めをする上で非常に重要となります。
店頭アプリとPOSレジアプリのそれぞれにおいて Firebase Analytics を導入してアプリの利用状況を把握できるようにし、Firebase Clashlytics を導入してクラッシュの発生状況を把握できるようにしました。店頭アプリについては継続的にクラッシュ対応を行い、最新バージョンではほぼクラッシュが発生しない状況まで改善することができました。
toC アプリの開発
2023年1月に POSレジアプリのリリースを終えた時点で、モバイルアプリとしてのタスクが一旦収束し比較的余裕ができたことと、hacomono としても将来的は toB(店舗様向け)アプリ だけでなく toC(施設の会員様向け)アプリを提供してく必要があると感じていたため、当時日常的に 1on1 を実施していただいていたCTOと相談しながら toCアプリを開発・提供していく方向性を定め、 PoC という扱いではあるものの開発する体制を整えました。
こちらのアプリは PoC 検証中でして一部の店舗様とその会員様にご利用いただいている状況です。限られた開発リソースでかつ iOS と Android の両プラットフォームに向けてアプリを提供する想定だったため Flutter で開発しました。アプリの主要機能は WebView で「ガワネイティブ」に近い状態ですが、Dart で実装した UI もいくつか含まれています。
二人目のモバイルエンジニア採用に向けて
プロダクトやビジネスが成長するにつれてモバイルエンジニアが一人では不安かつ不足しているという課題感が社内で高まってきました。私としてもhacomonoに入社した当時から「モバイルチーム」をつくっていきたいという思いがあり今から約半年前、正式に二人目のモバイルエンジニアを採用することが決定しました。
まずはJD(Job Description)を修正するところから始めました。私が採用された時点で既にJDは存在していたのですがWebエンジニアの人たちが中心となって作成した内容のため、ターゲットが明確に定まっていなかったりモバイルエンジニアから見ると違和感のある内容があったりと改善が必要な内容でした。またハードウェア連携の実装からFlutterでのアプリ開発など、将来的には幅広い開発にご対応いただく「可能性」があったため期待値が適切に伝わるような内容としました。
また hacomono として表立ったモバイルアプリをリリースしておらず、社外から見てどんなアプリを開発しているのか分かりずらい状況でしたので、カジュアル面談や面接では hacomono におけるモバイルエンジニアの立ち位置や関係するプロダクトの機能や状況、ご入社直後に想定しているポジションなどを丁寧にお伝えするよう心がけました。
現在モバイルエンジニアのJDはクローズしています。
Webアプリ開発
POSレジの開発スピードを上げて一日でも早くユーザーへ価値あるプロダクトを提供するために、一時期Webアプリの開発にも参加していました。POSレジではバックエンドに Ruby on Rails、フロントエンドには Nuxt3 を採用しており、これらの実装を行いました。特にモダンなフロント実装の経験が少なかった私としては非常に収穫のある経験でした。親切丁寧にコードレビューしてくれたメンバーに感謝感謝です！
失敗談
十分な成果が出せなかったチャレンジもありました。hacomono では毎年 RUN for というイベントを通じて社会課題の解決つながる活動を行っています。
この RUN for ではイベント期間中に各社員がランニングした実績（距離や消費カロリー）を Google Forms から登録する運用をしていたのですが、スマホからより簡単に登録できると体験が改善され参加意欲も高まると考え、Flutter や Firebase, Cloud Firestore などを活用してモバイルアプリを片手間で開発してみました。アプリ内では個人の集計や社内でのランキングも表示できるようにしました。
アプリは開発したのですが…デリバリーや社内のセキュリティポリシーの課題をイベント期間中に解決することができずお蔵入りとなってしまいました…
このような失敗が許容される（？）のも hacomono の良さかなと思います。
振り返り
過去所属していたスタートアップでも数名くらいのタイミングで一人目のモバイルエンジニアとしてジョインするようなケースはあったので同様の感覚で入社しましたが、組織やプロダクトがある程度成長・成熟した状態で一人目としてジョインするのはややハードモードだなと感じることもありました。
コミュニケーションや情報共有を丁寧に行っていけば、モバイル開発のカルチャーや特性への理解も得られ組織やプロダクトとしても成長できるようになることを体験し、コツコツ丁寧に続けることの重要性を理解することができました。
ちなみに 非表示アプリは一般の配布方法に比べると審査が緩いのでは？という都市伝説 は今のところ否定されています。
来年はモバイルチームやモバイルプロダクトを成長させるため、更に新しいことにチャレンジしていきたいと思います！
株式会社hacomonoでは一緒に働く仲間を募集しています！
採用情報や採用ウィッシュリストも是非ご覧ください！
この記事が気に入ったらサポートをしてみませんか？