2023.9.18
業務用iOSアプリ開発のルールやガイドライン作りで大切な考え方
昨年末頃(2022年末頃)から、エンドユーザ企業様から社内ガイドライン作りを直接ご依頼頂いたり、エンドユーザ企業を支援されるSIerさんやコンサル企業様からアドバイスを求められたりする事が増えました。中にはエンドユーザ企業様とグループ内のSI子会社様の2社合同で御支援するようなケースもあります。
(研修資料から。ADPでは特に理解すべきことが多くなり全体像をつかみにくい。ルールを作るのも大変)
特に、証明書や秘密鍵をどう管理したら良いか分からない、カスタムApp開発をどう統率したら良いか分からない等々、よく分からないのだ…という声が多いです。上図でいうと、App Store Connect にたどり着くまでの手前部分ですね。(あともう一つ言えば TestFlight の部分も)
そこで本稿では、ガイドラインやルール作りでエンドユーザ企業側が特に意識すべきポイントについて紹介します。以下が目次となります。
今回は主に、エンドユーザ企業様向けの内容です。順に見ていきましょう。
なぜ業務用iOSアプリ開発の管理は難しいのか
よく分からない…という状況になりがちな理由はとても簡単です。セキュリティ的観点やコンプライアンス観点で管理・ルール化したいもの、つまり証明書や秘密鍵、Provisioning Profile といったものが「開発の世界」のものであることに起因しています。
(おなじみのADPの画面。開発会社だけが分かれば良い…わけではないのが難しい)
証明書等々は、エンドユーザ企業とAppleとのADP/ADEP契約に基づいて専用サイト Apple Developer で生成するものですが、エンドユーザ企業の担当者が普段CSRや証明書といったものに接することはまずありません。Apple 特有の用語も多数ありますし、しかも基本的に英語です。
(Apple Developer にはエンドユーザ側には馴染みのない言葉が沢山。しかも英語だらけ)
従って、開発部隊が社内にない限りは何が何やら理解できない場合が多く、エンドユーザ企業だけでルールやガイドラインを作るのは極めて困難です。
例えると分かり易いのですが、分からないものを管理するのはどう考えても無理筋ですよね。
製造業を営む企業が工場の製造ガイドラインを作れるのは、素材や材料や機材やライン、品質管理や周辺の法律、それらがなぜ必要でどう機能するかを分かっているからです。エンドユーザ社内にその知識があるから、分かるからこそ、ルール作り・管理・運用ができます。
(ガイドラインの策定も運用も分かるからこそできる。Generated by Midjourney)
では、業務用iOSアプリ開発の場合はどうか。社内で分からないなら「分かる」開発会社に一任すれば良いじゃないか、あるいは、既に取引ある開発会社のどこかにルールを提案して貰えば良い…という発想になります。
しかし悩ましいのは、開発会社側もこの証明書周りについて余り理解せずにアプリ開発ができてしまっている場合が多いということです。これが、業務用iOSアプリ開発のガイドライン作成や管理を難しくさせている原因です。
証明書周りの厳密な理解がなくても開発はできる
エンドユーザ企業の期待と裏腹に、秘密鍵・CSR・証明書・Provisioning Profile のそれぞれの役割や関係性を説明できる開発会社は多くない印象です。
例えば、秘密鍵と証明書がどこでどの瞬間に使用・参照されるのか、ADEP/ADPでどう違うか、Provisioning Profile と証明書の関係性、その種類と意味、秘密鍵は漏洩するとどんなリスクがあるのか、配布用 Provisioning Profile の更新が年1で絶対必要なADEPと違いADPではなぜ必須でないのか、InHouseの証明書失効でアプリが動かなくなるのにAppStore向けではそうならないのはなぜか…等々です。
ぶっちゃけ、これらの理解がなくてもiOSアプリは開発できてしまいます。開発環境のXcodeが自動で処理してくれるからですね。
(Automatically とあり自動化できていることが分かる。昔はこのような便利な仕組みは無かった)
iOSが日本に上陸した2008年当初は、これらを理解していなければ ipa ファイルの生成すらままなりませんでしたが、Xcodeの自動処理の進化により今は随分(開発者にとっては)良くなりました。しかしそのぶんブラックボックス化されている範囲が広くなってしまったのです。
(開発環境Xcodeの付属ツール Organizer でアプリの最終出力をするところ。最新版のXcode15でブラックボックス度合いが更に上がった)
しかし、エンドユーザが管理したい証明書やProvisioning Profileは、そのブラックボックスの中で使われるモノになります。それらを作るのはエンドユーザ企業自身のADEP/ADP契約であり、何をどう作りどう管理するかをルール化したいわけですよね。
我々は分からない、あなた方も余り分かってないというのか…、となりがちです。開発プロセスで自動化・隠蔽化されていっている手順の中で使われるモノをエンドユーザが作らなくてはいけないという非常に難しい関係性にあるのです。
(権限設定に関する公式ページ。複雑なうえに、項目の意味や影響範囲を(開発会社でも)理解するのが難しい)
開発会社側からすると「とりあえず納品(申請)するのに必要だから最高の権限を下さい。あとはおまかせあれ」となりがちです。理屈としては一理ありますよね。実装して納品(申請)するのが役割なのですから。
結果、「よく分からないし、強い権限があればとりあえず開発は回せるらしいし…」ということで、
- Admin か App Manager を付与
- Certificates、Identifiers & Profiles へのアクセスの権限チェックを一通りONにする
- すべてのアプリにアクセス権
と少々乱暴に進めてしまう事になりますし、実際そうされている場合が多いでしょう。それがエンドユーザ企業側で何を意味することになるのか…を考慮せずにですね。
(App Store Connect でのユーザ登録。管理せず、とにかく開発が進めば良いならこれでok)
エンドユーザ企業が中堅・中小企業様で、委託先はこの開発会社一社だけ、ここに全部任せているのだ、という関係性なら全く問題はありません。全てを一任し管理して貰えば良いのです。全権限を渡す…で一択です。
しかし、上場企業のように大きな組織で多数の業務用アプリがあり、複数部門が複数の外部委託先に発注して開発している、業務用だけでなく一般消費者向けアプリもある…といった規模感になると、問題が起こります。
例えば、
- 委託先の開発会社a社/b社/c社の関係者全員にAdminを付与しており、エンドユーザ企業視点では誰が何をしているかどんなリスクがあるのか分からない
- 各社でやり方が違って、発注元のエンドユーザ側A部門/B部門/C部門の各部門でテストや申請のやり方も違っていて社内統制が取れてない
- D部門が新たなアプリ開発をd社に発注しようとしたら、証明書が作れないとか、秘密鍵をくれとか、テスト端末が登録できないとか言われる。既存a社/b社/c社に聞いてもそれぞれ意見が違って一体どうすれば？
とかとかですね。
こうしたことが起こらないように、また心配事を最小化できるように、正しい理解に基づいた「業務用iOSアプリの開発ガイドライン」的なものが必要になるでしょう。大きな企業であればあるほどです。
エンドユーザ側で最低限の開発側理解が必要
やはり、前述した「分からないものは管理できない」という基本原則をふまえて、自社の方針を決定するしかありません。選択肢を列挙すると以下のようになるでしょう。
- (A) 開発委託先が今後も一社のみの場合 → 全部丸投げして任せる
- (B) 開発委託先が複数社ある場合
- (B)-1. 頑張って理解して管理する
- (B)-2. 管理を諦める
(A)の場合は悩む必要はありません。Admin 権限を渡して全てを任せるのがお勧めです。
もし(B)の状況でガイドラインを作りたいのなら、まずは (B)-1 で進めてみることをお勧めします。その際エンドユーザ側だけで理解するのは基本的に無理がありますので、
- 自身がADPの契約をしている
- 自身のアプリも開発・公開した実績もある
の条件を満たす取引実績ある開発会社や個人の方に相談すると良いでしょう。ポイントは「他社に発注する場合でも破綻しないルール作りを手伝って欲しい」とお願いすることです。加えて、Xcode で配布用証明書や配布用 Provisioning Profile がどのように使われるのかなども教えてくれる開発会社なら、エンドユーザ側として管理イメージを描き易いのでより良いと思います。
(WWDC2021の動画より。開発側で必要になるものは2008年当初より随分変化してきた。そのあたりの知識も必要)
相談できる開発会社や個人がいない場合、Apple公式情報を参考に自力で頑張ることになります。Apple Developer サイトと App Store Connect のページに一通り目を通すのが良いでしょう。以下がリンクとなります。
それでもやはり難しい場合、残念ながら諦めるしかありません。やはり分からないものは管理できないからですね。
今回はエンドユーザ企業様向けに、ガイドライン策定やルール作りで大切な考え方について書いてみました。
色々御支援させて頂く中で感じるのは、ADPもADEPも社内でアプリを内製する体制を前提にした仕組みになっているように見えることです。業務用ソフトウェアを外部委託することが多い日本企業には、ピッタリハマりにくいです。つまり丸投げしにくい。委託の仕方も色々ですから、全企業で使える共通管理モデルなるものも作りにくいですしね。
では、Apple Japan の法人部門がガイドラインを作ってくれるかというと、残念ながらそれは難しいと言わざるを得ません。厳しいようですが、そうしたことは iOS 端末数の販売増には繋がらないからです。せいぜい上記で紹介した公式ページ情報を提示される程度でしょう。
ということもありますので、本サイトでは引き続き開発視点を盛り込んだ、エンドユーザ企業様向けの管理ノウハウも投稿していきたいと思っています。
