バクラク申請・経費精算のモバイルアプリを開発している id:kikuchy です。9日ぶりですね！初見だという方はこちらの記事もどうぞ。
ID/共通管理チームの id:convto さんに教えてもらったCharachorder Oneという変形キーボードを自分用のクリスマスプレゼントに購入しました。 入力が難しすぎてまだ数字が入力できませんが、複数種の文字を入力する際に指を動かさなくて良い、というのは大変画期的だなという体感です。使いこなせると爆速で文字入力できるそうなので頑張ります。
この記事は LayerXテックアドカレ2023 の36日目の記事です。明日は @civitaspo さんが登場です！
今回はのびしろウィーク企画ということで、バクラク申請・経費精算のモバイルアプリの「のびしろ」を大公開します！
のびしろウィークとは
「LayerXってCTO経験者とかいっぱいいるし、問題なんて無いでしょう？」 「LayerXは興味あるけど、つよつよなエンジニアが集まっていて、自分にできることなんて何もないのでは？」
そう思っている方、いらっしゃいませんか？私もそうでした。
テックブログには、基本的にうまく行った事柄などが掲載されるもので、順風満帆に物事が進んでいるように見えるかもしれません。
しかし、多くの企業と同様、大きく変化する環境に適応していく中で様々な施策を打っており、その中には上手く行っている事があれば上手く行っていないこともあります。 現在もLayerX社内には解決されていない問題、整備されていない環境がいっぱいあります！
そこで、チーム内に転がる課題「のびしろ」を公開してみるのがこののびしろウィーク。 もし「のびしろ」を見て「一緒にこの課題を解決してみたい」と感じることがあれば、ぜひご連絡ください！
バクラク申請・経費精算のモバイルアプリチームとは
企業のお金の流れをDXするバクラクシリーズのなかでも、バクラク申請・経費精算は稟議や経費精算を取り扱うプロダクトです。 全従業員の方にお使いいただくプロダクトでもあり、外回りや出張中の方にもお使いいただく機会があります。 必ずしもPCの前におられる方のみがお使いになるわけではないため、便利に使っていただくためにモバイルアプリも提供しています。
バクラク申請・経費精算のモバイルアプリチーム（以下、アプリチーム）のエンジニアは3人で、現在はFlutterでアプリを再開発している最中です！ 書き直しの動機はこちらの記事が詳しいので、こちらを御覧ください。
今回はこのチームが抱えている伸びしろをご紹介します！
Webフロントへの追従や同期が大変
バクラク申請・経費精算では、メインのロジックはバックエンドが実装しているものの、フロントエンドにコアなロジックがないわけではありません。 即座にユーザーの方にレスポンスしたいことはフロントエンドにドメインロジックの実装がされるため、フロントエンドにも然るべき量のロジックが存在します。 とりわけ、以前に私が書いた記事で紹介したような複雑なバリデーションが重厚感を醸しだしていたりします。
すでにNuxt.jsで実装されたフロントエンドの実装はかなり膨大で、少なくとも当面のあいだ、アプリはこのWebフロントエンドに追従するための実装を続けることになります。
アプリが機能の追従を行っている間も、当然Webフロントの機能追加は続きます。 既存機能にも改修が入って、仕様がマイナーチェンジしたりすることも考えられます。 それらにも追従することを考えると、アプリがWebフロントの機能をすべて備えるのはまだまだ先のことになるでしょう。 （すでに、申請フォームの作成など管理者向けの機能をアプリで実装しないことは決まっています。アプリに求められる役割はPCブラウザから見るWebフロントとはまた異なりますからね）
また、追いついた後も常に仕様を同期していく必要があります。 Webフロントはデプロイすればすぐにお客様に使っていただける状況になりますが、アプリはストアに掲載した上でお客様にアップデートしていただかなければいけません。 常にデプロイのタイミングを考え続けなければいけなくなります。
複数プラットフォームの仕様同期はアプリに閉じた話ではありません。 今回はたまたま後からアプリというプラットフォームができたから起きた問題、ということですね。
バックエンド、Webフロント、アプリで共通に使用できるロジックを吐き出せる言語で共通部分を実装するとか、技術的に解決する方法もあるかもしれません。 チーム運営の仕組みやデプロイ手順の改善でどうにかなることなのかもしれません。 いえ、技術と組織面の両方から解決が必要となる問題かもしれません。 どう乗り越えていくのか、未だに解決されない問題として残っています。
ドメイン知識を得ながら開発速度を出す
アプリチームのメンバー3人のうち、 @chocoyamaさんと@yoheiさんはアプリチーム組成のタイミングでジョインされたため、チーム組成の段階では稟議や経費精算といった業務ドメインの深い理解や、バクラク申請・経費精算というプロダクトの仕様をご存知ではありませんでした。 オンボーディングのタイミングで説明はさせていただくものの、短時間でプロダクトの仕様まで全部説明するのも把握するのも無理があります。
当然、開発しながら仕様をキャッチアップしていただくことになりますが、そうなると全速力を出していただくのは難しい… 今作っているものが正解かどうか、確認を持てないままだと当然そうなりますよね。
そこで、スプリントのバックログリファインメントのタイミングで、これから開発に取り掛かる機能についてのドメイン知識や現行仕様の確認を行いながらタスクを積むようにしました。 これで一定の問題は解決しましたが、今度はバックログリファインメントにかかる時間がどんどん伸びて行ってしまうようになったのです。 リファインメントせずに実装後に「じつは違う」みたいな手戻りが発生すると、リファインメントにかかる時間以上の時間を浪費してしまうことになるので、リファインメントにかかる時間は必要な時間かもしれませんが。
とはいえ、もっと爆速開発できる方法があるはず…！ オンボーディングプロセスの改善や、仕様理解をフォローしながら開発速度を上げることを諦めたくはないですね！
端末管理の問題
現在、LayerX内でモバイルアプリの開発をしているのは、バクラク申請・経費精算のアプリチームのみです。 昨年にバクラク申請・経費精算アプリがリリースされるまでは試験端末すらありませんでした。
アプリが使えるようになってくると、社内でのリリース前最新版を使用したいニーズが高まってきました。 アプリでもバクラクの使用には認証を必要とするため、特にID/共通管理チームの方の開発環境・ステージング環境での動作試験に使用したいニーズがあるのです。 セールスやカスタマーサクセスの部門の方も、次にリリースされるアプリに触れておいて、営業の際に次のアプリの特徴を体感しておきたいニーズも生まれました。百聞は一見に如かず、質の高いセールス活動のために行動してくださる皆様に頭が下がります！
その際に問題になってくるのが、アプリが配布されるiOS端末の管理です。
iOSで社内配布を行う場合、基本的には配布対象の端末のUDIDが必要となります。 このUDIDは100件まで追加でき、そして1年に1回しか棚卸しができません。
TestFlightを使用して配布すればUDIDの収集は必要ありません。 が、内部テスターとしてユーザーを追加する場合はテスターにApple Developerアカウント、その上で招待とアプリテスターへの追加が必要ですし上限が100人、外部テスターを招待して使う場合は審査を通す必要があります。
もし社内のメンバーを内部テスターとして追加する場合。 いちいち必要な人にAppleアカウントの招待を送り、招待の承諾を待ってから、アプリのテスターに追加する、という手順を人数ごとに行う必要があります。 また、退職があった、開発チームを移動した、などで使用しなくなったユーザーの棚卸しが必要です。 それなりの手間隙がかかってしまいますが、今のところはこの方法で回しています。UDID集めてProvisioning Profile更新して再デプロイするより全然楽…！
外部テスターとして招待する場合。 Appleの審査を通す必要があるのですが、開発環境/ステージング環境はアクセス制限がかかっており、審査される環境からはアクセスできません。 リリース前の新機能は開発環境/ステージング環境でのみ使用可能で、アプリが使用しているバックエンドの環境はSchemeで切り替えているため、審査は本番環境に繋いで、配信後に接続先をステージング環境に切り替える…という芸当も現在はできません。
うまい管理の仕方を見つけたいと思っています。助太刀求む！
Figmaで作ったデザインを実装に落とし込むのが大変
アプリチームではFigmaによるプロトタイピングを本格導入したバクラクでは初めてのプロダクトになります。 アプリ実装は、プロトタイピングで使用したデザイン画を元に画面を作っています。 Figmaのデザイン画を元に実装を起こしていくのは、よくある開発スタイルではないかと思います。
アプリチームには他業務も兼務しているデザイナーさん1人についていただき、デザインから実装を起こしています。 バクラクのデザインシステムは、デザイン中に使われている色・数値・真偽値（プリミティブなもの）、それの組み合わせである空白やタイポグラフィ、簡単なアイコン、各画面で共通に使用されるUIコンポーネント含んでいます。
デザイン中の色や数値は、FigmaのVariablesという機能で管理しています。いわゆるDesign Tokenに相当する情報ですね。 これををJSONでエクスポートし、Style Dictionaryを通すことでDartのコードを生成することが可能です。
アプリチームではStyle Dictionaryの出力をよりFlutterに適した形で吐き出してくれる style-dictionary-figma-flutter を使用しています。
しかし、Figmaからアイコン定義や共通コンポーネントを取り出したり、Design TokenのJSON出力を自動で取り出してCIでコード生成するなどの最適化ができていません。 現状では目視で共通コンポーネントをコーディングし、開発都合で見つけた共通コンポーネントをデザイナーさんに適宜連絡する、といったプロセスが取られています。 Figmaで作った共通コンポーネントが自動的にDartのコードになってくれれば言う事無いんですが…AIの力でなんとかなったりしませんか…？
この後のフェーズで色の調整やスペースの調整などが入る予定もあり、なるべくシームレスな追従を実現したいものです…が、できていないのが現状です！
まとめ
スムーズな開発にむけて、まだまだ解決されていない問題が山積しています。 アプリの開発でも爆速を実現したい！
こうした話題にすこしでも興味がある方はぜひお話しましょう！
こちらからカジュアル面談に来ていただくのもOKですし、 jobs.layerx.co.jp
最近開催しているCasual Nightという、オフィスでドリンクや軽食などを食べながら気軽に話せるイベントもございます。 12/21の第3回はCola Nightということで、コーラを始めとしたソフトドリンクを楽しむ会になっています。 私が選んだクラフトコーラもたくさんそろえていただきました！ 一緒にコーラ飲みましょう！
