iOSとAndroidの二重保守を解消した6か月。HR Techアプリ刷新で私たちが選んだこと

Netsujo株式会社は、HR TechのSaaS事業者が提供する業務アプリを、React NativeとTypeScriptを使って全面刷新しました。要件定義からリリースまで約6か月。iOSとAndroidの二重保守を単一コードベースへ集約し、UIを改善し、公開後の安定化まで担当しました。保守体制は引き継ぎ済みで、アプリは現在も運用が続いています。

今回の成果は、新しい技術でアプリを作ったことにとどまりません。利用者が実際に使う機能を調べ、移行すべきデータを読み解き、リリース後も改修を続けられる構造へ変えました。既存システムを刷新する際に、私たちがどこから判断し、どう実装と現場の利用をつないだのかを振り返ります。

私たちはこの経験を、顧客の業務課題を把握し、仕様・実装・本番利用・運用をつなぐFDE（Forward Deployed Engineer）型の実務として紹介します。

私たちが引き受けたのは、技術負債と事業スピードの問題だった

着手前のアプリには、長年にわたって追加された機能とコードが蓄積していました。iOSとAndroidは別々に開発・保守されており、一つの機能変更にも両方の環境で作業が必要でした。既存コードへの影響調査が新機能追加のたびに発生し、リリースまでの時間が長くなっていました。

利用者側でも、UIの使いにくさが課題になっていました。技術上の問題が、日々の操作性と機能改善の速度に影響していたのです。

さらに、旧アプリのデータ構造は十分に文書化されていませんでした。過去のデータをどう引き継ぐか、新旧アプリをどのように切り替えるか、公開後は誰が保守するか。全面刷新を選んでも、これらの仕事を解かなければ本番で使い続けられる状態にはなりません。

私たちはPM兼エンジニア1名、開発エンジニア2名の体制で、要件定義、アーキテクチャ、実装、リリース、公開後の安定化を担当し、保守体制を引き継ぎました。顧客側には大きな刷新を進めるための開発余力が限られており、私たちが技術と進行管理の両方を担う形になりました。

最初に全画面・全機能を棚卸しした理由

リプレイス案件で、旧アプリの機能を無条件に新アプリへコピーすると、以前の複雑さまで残ります。私たちは要件定義の段階で、既存アプリの全画面と全機能を棚卸ししました。

そのうえで、各機能を「利用頻度」と「業務への影響」の2軸で整理しました。頻繁に使う操作と、使用回数が少なくても業務上欠かせない操作を区別するためです。あわせて、使われていない機能を明確にし、リプレイス対象の範囲を絞りました。

この順序には実務上の意味があります。開発側の都合だけで機能を削れば、現場の業務が止まる危険があります。一方、過去の機能をすべて残すと、刷新した後も同じ保守負担を抱えます。利用実態と業務インパクトを見てから要件を決めれば、誰のどの仕事を維持するために作るのかが具体的になります。

実際の棚卸しで廃止した画面数や機能数は、今回の公開実績には数値を載せていません。私たちが公開している成果は、2軸で優先順位を決め、対象範囲を整理してから実装したことです。

段階改修よりも、全面刷新を選んだ

私たちは、既存コードを順次直す方法と、新しい基盤へ全面的に移す方法を比較しました。今回の問題の中心には、iOSとAndroidで別々に保守する構造と、深く蓄積した技術的負債がありました。部分改修を続ける方法では、その構造が残りやすい状態でした。

そこで私たちは、フルリプレイスの方が総コストを抑えられると判断し、React Nativeを採用しました。iOSとAndroidの実装を一つのコードベースへまとめ、TypeScriptを用いた共通開発体制へ移行しました。Web技術の開発経験を持つ人材も活用できる構成です。

もちろん、どのアプリでも全面刷新が適切とは限りません。旧アプリが安定しており、改修範囲が限定される案件なら、段階改修の方が移行リスクを抑えられる可能性があります。この案件で全面刷新を選んだ根拠は、二重保守の解消と、その先の継続的な変更のしやすさでした。

この点は、AI・SaaS製品の顧客環境への導入にも当てはまります。既存システムへの接続方法を選ぶときは、最初の開発費だけでなく、以後の機能追加、保守担当、障害対応まで含めて構成を比較する必要があります。

私たちは旧データを調べ直し、移行スクリプトを整えた

フルリプレイスで新しいUIを完成させても、旧アプリで蓄積されたデータを扱えなければ利用者は移行できません。今回の難所の一つは、十分なドキュメントが残っていないレガシーデータ構造でした。

私たちは旧スキーマを逆算し、移行スクリプトを整備しました。過去のデータが持つ意味と、新しいアプリが必要とする構造をつなぐための作業です。旧データの関係や業務上の意味を新しいアプリへ引き継ぐには、データ構造の調査と移行結果の確認が必要です。私たちはその基礎となる旧スキーマの逆算と移行スクリプトの整備を進めました。

続いてアプリのストア申請とリリース対応を行い、公開後の安定化まで支援しました。当社の担当範囲は完了し、保守体制を引き継いでいます。アプリは現在も運用が続いています。

私たちは旧スキーマの調査、移行スクリプトの整備、アプリの公開、安定化対応、保守体制の引き継ぎまで担当しました。 この経験を踏まえ、後半では類似案件に活用できる受入方法を提案します。

私たちが実現した成果と、その後の変化

この案件では、次の成果を実現しました。

刷新したUIは現場スタッフから好評を得て、リリースサイクルが短縮し、新機能追加の速度も上がりました。 私たちはこの変化と、両OSの二重保守の解消を当社の成果として公表しています。

一方、削減工数やリリース頻度の倍率、利用継続率や売上への効果について、定量比較の資料は公表していません。私たちは、実際に完了した刷新と定性的に確認した変化を成果として伝え、数値がない領域を推測で補うことはしません。

FDE型の導入支援に、この経験をどう生かすか

アプリ刷新に限らず、顧客の業務で動くソフトウェアを作る場合、実装から運用までを一つの流れで考える必要があります。私たちが今回の経験から提案するのは、受入条件を画面・データ・運用の三つに分ける方法です。

画面・操作では、利用頻度が高い操作と、失敗すると業務への影響が大きい操作が完了するかを見ます。データでは、必要なレコードと関係が移行後も正しく扱えるかを確認します。運用では、切替え後の問い合わせ、不具合修正、機能追加を誰が担当するかを決めます。

この3領域は、今回のHR Tech案件で扱った工程に基づく整理です。実際の受入テストの詳細条件は案件ごとに異なります。顧客が使う環境、権限、個人情報、停止できる時間などに合わせて設計する必要があります。

私たちの実案件では、要件定義から実装を進め、データ移行を扱い、アプリをリリースし、保守体制を引き継いで当社の担当範囲を完了しました。アプリ自体は現在も運用が続いています。FDE型の仕事でも、導入先で実際に使う人の仕事を理解し、技術の変更を継続可能な運用につなぐことに価値があります。

技術負債とアプリ刷新を相談する方へ

「アプリが複雑になりすぎた」「iOSとAndroidで保守が二重化している」「刷新したいがデータ移行と運用が心配」という相談には、現状の機能・データ・運用体制の整理から対応します。全面刷新か部分改修かも、現状と目標に応じて比較します。

私たちは、仕様書だけを受け取る実装作業に加え、業務の確認、技術判断、リリース、保守体制の引き継ぎまでを組み合わせた支援を行っています。実装と運用の担当範囲は案件ごとに合意します。

当社のHR Techアプリ支援実績 ／ AI導入・技術支援を相談する

---

当社の一次情報： 業務アプリのフルリプレイス（支援実績）。約6か月の要件定義・開発・公開、3名体制、React Nativeへの刷新、移行・保守体制の引き継ぎ、UIへの評価とリリースサイクルの変化は当社の公開案件記録に基づきます。FDE型支援に関する受入フレームは私たちの提案です。