今回は、VR関係の事業を営まれている非上場企業様からの問い合わせとなります。カスタムAppを顧客企業に提供する時のテスト設計についてのご相談。実は、ケースとしては前回と似ているのですが「テスト」にフォーカスがあたった話になります。

(研修資料より。自社製品のカスタマイズバージョンをカスタムAppとして他社提供するパターン)

以下が目次です。順番に見ていきましょう。

• 質問 : カスタムAppにおいて顧客の受け入れテストはどう実施するのでしょうか？
• 回答 : TestFlight内部テストを使います
• 解説1 : カスタムAppの受け入れテストに「王道」はない
• 解説2 : ADPのAdHocを受け入れテストに使うのは悪手
• 解説3 : 本番用と異なる検証用の別アプリに存在意義はあるのか

質問 : カスタムAppにおいて顧客の受け入れテストはどう実施するのでしょうか？

Q. 当社はVR関連の自社ソリューション(アプリ)を開発・販売している企業です。個人向けにAppStore公開アプリの提供をする一方で、顧客企業に非公開のカスタマイズ版を開発し、当該顧客ADEP契約のInHouseで署名して提供してきました。

現在、顧客からADP(カスタムApp)への移行を依頼されており、あわせてテストの手順策定を求められていますが、カスタムAppでどのように顧客側の受け入れテスト(UAT : User Acceptance Test)を進めていくのかが分かりません。

ADEPの時はInHouse配布をすれば良かったので余り悩むことがなく、検証用アプリと本番用アプリを分けてビルド・配布して受け入れテストと実配布を行っていました。カスタムAppではどのように顧客の受け入れテストを設計すれば良いのでしょうか？

回答 : TestFlight内部テストを使います

A. 仰る通りADPではADEPのようにはいかないため、顧客の受け入れテスト(UAT)の要件に合ったテスト設計を適宜行う必要があります。具体的に回答するには、エンドユーザ企業様のテスト要件ヒアリングが必要です。が、今回それはできないとのことですので、残念ながら抽象的な回答となります。

カスタムAppでは、原則 TestFlight の内部テストを使います。ですので TestFlight をよく調査し、顧客要件にあったテストを設計して下さい。基本的には以上です。

調査用に設計のコツをキーワードでお知らせすると、内部グループをうまく使い分けること、ビルドのコンプライアンス設定方針を考えること、の2点でしょうか。

一点、テストの考え方について補足いたします。

検証用アプリと本番用アプリを分けるのは余り良い方法ではありません。時折見られる手法ですが、そもそも実行バイナリとして別物を使って動作確認するのは、本当に「検証」と言えるのでしょうか？

TestFlight は AppStore アプリのために用意されており、「同一バイナリ」をテスト用と本番用とに配信し分けて、真の「検証」と実稼働を共存できる仕組みになっています。カスタムApp は AppStore アプリですから、テストも TestFlight の考え方や仕様に合わせるのが最善です。

我流を通そうとすると必ずどこかで進めにくさや違和感・無駄が発生することになります。特別な事情がない限り原則アプリは1つとし、検証と本番の切り替えは実装側で吸収することをお勧めします。

解説1 : カスタムAppの受け入れテストに「王道」はない

テストをどう行うか？は、カスタムAppを開発・テスト・配布まで自社完結できないケースで必ずぶち当たる壁です。

ADEP(InHouse)では好きに配布すれば良かったので課題にならなかったのですが、ADP(カスタムApp)では Apple の用意するテストツールである TestFlight を使って、自社なりの、アプリなりの、「テスト設計」が必要になります。

(学習教材としてTestFlightの公式ドキュメントがある。これをよく読み実際に試すことが推奨される)

App Store Review ガイドラインのような指針は特に与えられていませんから、TestFlight を十分に理解した上で、個々事情を考慮したテストの段取りを作り上げないといけません。これを誤ると開発がうまく進まなかったり、開発体制をスケールさせにくくなったりします。

また TestFlight は App Store Connect と無縁ではいられません。App Store Connect の仕様変更に影響を受ける場合もありますので、「テスト手順を策定する」といったミッションは、意外に難しかったりします。

(WWDC2021の動画から。カスタムApp では App Store , App Store Connect, TestFlight の全てを理解する必要がある)

ソフトウェア開発全般に言える事ですが良いソフトウェアの影には必ず良いテスト設計が存在します。カスタムApp化には、エンドユーザ側にも開発会社側にも TestFlight の理解が必要不可欠です。

弊社では、カスタムApp移行を御支援する際に「この方法なら概ね大丈夫」というパターンをベースにして、企業ごとの要件で調整してご提案することが多いです。

解説2 : ADPのAdHocを受け入れテストに使うのは悪手

テストにAdHoc配布を使えば良いのでは？という意見も一部にはありますが、弊社では推奨していません。大手企業では特に、アプリの数やiOS端末の利用部門が増えてくると「詰んで」しまうからですね。どういうことか。

AdHoc配布では、配信先の端末数が100台までという上限があります。

特に大手企業あるあるですが、部門別に色んなアプリを作り、外部委託先が何社もあって、しかも多段の商流を組んでいて関係者が多い…なんて状況では、すぐ上限を振り切ります。開発会社が開発側のテスト用に勝手に大量登録してしまった…なんてケースもありますね。

そして、あるタイミングで突然「テスト用端末を追加できない」と報告があがり「詰む」ことになります。「どの端末を消すか調整しよう」と動いたところで残念ながら手遅れで、詰んだ状態はすぐには解消しません。削除した端末数分をすぐ追加登録できるわけではないからです。ADP契約の更新日まで待たなければなりません。

(リセット日とはADPの契約更新日。削除した端末個数分を新たな追加枠として使うにはリセット日を待つ必要がある)

将来、アプリの数も関係者も増えない、と断定できるなら TestFlight を使わず AdHoc をテスト用途に使うのもありかも知れません。

いつ上限を超えるかコントロールできず、開発側の勝手な登録を禁止することもできない AdHoc は、外部委託が基本の大手企業においては特にテスト用途には不向きです。むしろ、稼働台数が数十台程度という制約付きで InHouse 配布と同じ運用ができる配布手段と捉えたほうが良いでしょう。詳しく以下をご覧下さい。

• AdHoc配布はテスト用途以外に使用できるのか
• AdHocアプリを社外ユーザに配布できるのか

弊社では、開発を外部委託している企業様のADPでは、AdHoc配布をテスト用途に使わないことを推奨しています。

解説3 : 本番用と異なる検証用の別アプリに存在意義はあるのか

今回のご相談では「検証用」アプリと「本番用」アプリとが別アプリだということでした。実は時々ありますが、弊社では余り推奨していません。

AppStore アプリにおいては、検証と本番をアプリ実体で分けるものではありません。Apple が用意する仕組みを読み解けば、Appleは検証と本番はアプリではなく配信ルートで分けるべき、と考えていることが分かります。

(WWDC2021の動画から。開発したアプリ(ipa)はテストならTestFlight、本番はAppStoreへ。行き先が異なるだけ)

同じアプリの用途違いでアプリの実体を複数作るべきではないのです。

• 検証用アプリと本番用アプリが別々に存在する
• 検証用配信ルートとしてTestFlightが、本番用配信ルートとしてAppStore+ABM+MDMが存在する

これをうまく使い分けられるでしょうか。検証用のアプリを本番用途の App Store → ABM → MDM と流す意味は何でしょう？ただでさえ複雑なカスタムApp配信に、自ら複雑さを加えることはないと考えます。

少し話は変わりますが、その昔、一般消費者向けの有償アプリの世界でも似たようなことがありました。「機能制限つきのFree版アプリ」と「フル機能の有償版アプリ」と、2つの別物アプリを開発会社は作り分けていたのです。弊社もやっていました。懐かしいですね。

(初期のAppStoreで弊社アプリを一覧した画面。フル機能の有償アプリ(右)と無償のLITE版(左)を別アプリで提供していた)

このような手法でアプリ数が無駄に増えることをAppleは良しとせず、1つのアプリで両役割を持たせられるよう In App Purchase (アプリ内課金) の仕組みを用意しました。それが2009年のこと。その後 AppStore からは、1つのアプリでFree版/有償版の2種類存在するケースは無くなっていきます。

実は業務用でも一緒です。特別な理由がない限りアプリは原則1つとし、実装で工夫をして同じアプリを用途ごとに使い分けられるようにするのをお勧めします。MDMからの本番用配信でのみアプリの特別な設定値を有効にする Managed App Configuration も活用できるでしょう。以下もご覧下さい。

• iOSDC JAPAN 2021で Managed App Configuration について講演します
• iOSDC2021で Managed App Configuration について講演しました -YouTubeで動画公開されました-

以上、カスタムAppにおけるユーザ受け入れテスト(UAT)についての質問＆回答と解説でした。

カスタムAppへの移行ではハマりどころが幾つかありますが、テストはその中でも比較的大きめのハマりどころです。App Store Connect、App Store、TestFlight に加え、ABM や MDM も理解していないと、業務用アプリのライフサイクル全体を設計できないからですね。関係者が多く、事前に手順書等を規定しなければならない大手企業の場合は結構大変です。

繰り返しになりますが、TestFlight をよく調査研究することが推奨されます。今後、カスタムAppの観点からのTestFlightについても解説していこうと思います。

そんな無償解決したお問い合わせストックの中から、シェアするのが有用と思われるものを紹介するケーススタディ企画を始めることにしました。具体的な課題や背景・ストーリーがあるほうがより分かり易い場合もあるからです。

記念すべき(?)第一回目は、古いInHouseアプリをカスタムApp化したいというご相談です。実際にはメールやビデオ会議で数回に分けてやりとりしていますが、本稿では、質問→回答、とシンプルな構成で書いてます。また、その後に解説も記しています。

• 質問 : 7,8年前のアプリをカスタムApp化したいのですが？
• 回答 : 作り直したほうが早いです。開発体制も再考の余地ありです
• 解説1 : 自社アプリのカスタマイズ版を他社提供する方法
• 解説2 : App Store アプリの開発経験を持った外注先を選ぶ

それでは質問からいってみましょう。

質問 : 7,8年前のアプリをカスタムApp化したいのですが？

Q. 当社はシステム開発事業を行っている上場企業です。7,8年前に、社内のある事業で作ったB2B向けの業務アプリを顧客のADEP(InHouse)を使って提供していたことがあります。アプリは諸般事情で提供をやめたのですが、ここに来て当該のアプリを復活させることになりました。

貴サイトを見て、業務用アプリはカスタムApp化が必要なことを知って取り組み始めたところです。開発には外部の開発会社を使っていますが、Xcodeでうまくビルドできないと言われてて進捗は良くありません。deprecated というエラーや警告が多発したり、SDK が見つからないと言われたりして、ipa ファイルが生成できないとのことです。どう進めていけば良いでしょうか？

回答 : 作り直したほうが早いです。開発体制も再考の余地ありです

A. deprecated や SDK が見つからない等の警告やエラーは、廃止されたAPIを使っていたり古いSDKを参照するソースコードで発生します。代替の実装を行う必要がありますが、軽微で済むものからインパクトの大きなものまで様々です。

App Store への申請が伴うアプリ開発では、deprecated となるAPI情報をチェックし、SDK も新しくして、継続的かつ計画的にiOS エコシステムの進化に追随していく必要があります。

(deprecated の例。上図はUIKit)

App Store と無関係でいられたADEP(InHouse)の場合は Xcode や iOS SDK を自社都合や顧客都合で固定できていたため、deprecated を意識することは余り無かったかも知れません。良い意味でも悪い意味でもやりたい放題だったというわけです。

7,8年もの間に蓄積したiOSアプリとしての「遅れ」を、ツギハギや小手先の調整で取り戻すのは困難な作業になると思われますし、実装の見直しが広範囲に及ぶ可能性も高いと推測します。残念ながら、御社は「カスタムApp を考える以前の状態」と言えるでしょう。

(Swiftの登場は2014年ですっかり定着。Android版の同時開発でもない限り昨今はSwiftがスタンダード)

当該アプリのソースコードは Objective-C のようですが、最新のXcodeを使ってSwift言語で今風に作り直す方針を推奨します。昨今ではそのほうが外注先開発会社の選択肢も増えます。また今後のビジネス持続性も考えて、App Store 向けアプリの経験がある開発会社を選ぶほうが良いでしょう。

既存ソースについて補足すると、全部捨てることが常に正解だとは限りません。基本的に捨てる方針としながら、一部流用できるビジネスロジックがある場合は Objective-C のまま当該部分を抜き出して再利用するのが賢明でしょう。とはいえ Swift と Objective-C を混在させるデメリットもありますので、そのあたりも含めて相談できる開発会社を探されると良いと思います。

解説1 : 自社アプリのカスタマイズ版を他社提供する方法

ここからは相談内容に関連する解説となります。さて、今回のご相談のように、

• 自社で開発したソースコードをビルドして
• 他社のADEP(InHouse)契約配下の証明書・秘密鍵・Provisioning Profileで署名する

というやり方は、自社開発の業務用iOSアプリを他社販売する時に行われてきました。しかし、ADEPが使えない(使えなくなっていくと思われる)今、今後はこの方式は使えない(使えない前提でビジネスを組み直さなければならない)と考えるべきです。

カスタムAppでは、

• 販売先企業毎にそれぞれアプリを作る
• 自社 ADP にカスタムAppとして個別に申請
• App Store Connect 上の配信設定で販売先企業の組織IDと組織名を指定
• 販売先企業にはABM+MDMの導入必須であることを説明

を行う必要があります。

(研修資料より。提供先企業がMDM+ABMを持っている前提でカスタマイズ版を他社向けABMに放り込む)

このことから分かるのは、業務用自社開発iOSアプリを他社提供するメーカ企業がADEP(InHouse)からの移行を目指す場合、メーカ企業自身にもABMとMDMの理解が必要になるということです。これらの理解なく、事業を営むのは今後難しくなっていくでしょう。該当する企業におかれは、以下を参照のうえ準備することをお勧めします。

• MDMとは何か 〜今さら聞けないMDMの基礎〜
• ABM(Apple Business Manager)とは何か

解説2 : App Store アプリの開発経験を持った外注先を選ぶ

本サイトで度々強調していることですがカスタムApp は App Store アプリです。そして App Store アプリには、ADEPの InHouse アプリと全く異なる、複雑で沢山のノウハウが求められます。

(App Store Connect は豊富な機能を備える。カスタムAppで必要なのは一部だけだが、それでも知るべきことは膨大)

ADEP では触れる事のなかった App Store Connect の基礎理解は必須であり、アプリ審査に関係するワークフローや審査結果に対するオペレーションも押さえる必要があります。テストの仕方もそもそも変わります(TestFlightを使用)し、前述の deprecated の対応も常に必要です。

ADEPとは比較にならない知識と経験が必要になるわけです。ipa ファイルを作って、審査もなく、本番・テストの区別なく自由にバラまけたInHouse配布のADEP時代とは全く違う世界だと認識しなければなりません。ADEPからEが取れた程度…と安易に考えてはいけません。

(アプリの詳細画面。たった1つのアプリでも、多くのタブと多数のメニュー、そして膨大な入力項目がある)

また、カスタムApp化で大きな課題になるのがiOS の API の進化に追随しなければならないという点です。

iOSは進化とともに古いAPIが使えなくなります。App Store アプリでは、この廃止予定のAPIを使っているとそもそも申請を受け付けてくれませんので、代替の実装に置き換えることをしばしば行います。

(iOS Release Noteから。上図は iOS16で UIKitの一部関数が廃止されることを示している)

開発者視点でiOS最新情報を確認できる iOS Release Note のページをチェックし、対応し続けられる開発体制かどうかは非常に重要です。App Store アプリの開発経験のない企業の場合、そもそもそういったことに慣れていない可能性があります。

「現場の iOS 端末で動けば良い」

この発想ではダメで、今後はアプリ審査に耐えうるクオリティの実装が必要です。では審査に耐えうるクオリティとは一体？…そうしたことに知見を持って対応できる、業務アプリの持続可能性を高める体制作りが必要になるのです。

そのために、App Store アプリの経験のある企業に発注する、または内製するなら経験者を雇うのは良い選択でしょう。それが適わないなら、最低限、その知見や経験を持った企業や個人に技術支援を依頼することをお勧めします。

今回はケーススタディ企画の第一弾ということで古いInHouseアプリをカスタムAppに移行したいというご相談への回答および関連解説をお届けました。他にも学びのある無償相談は沢山ありますので、また紹介したいと思います。