menu
menu
menu
menu
ModuleApps

オムニチャネル戦略やO2O事例を読み解く専門メディアモバイルマーケティング研究所

アパレル大手に学ぶこれからのブランド別アプリ開発戦略

 Post by MML編集部

アベイル,しまむらアプリ_トップ画面

今回の記事では、前回しまむらグループのアベイルアプリの紹介記事でも触れた「共通システムを活用したブランド別アプリの効果的な開発手法」について、同様の手法を採用している青山商事やAOKIなどの事例も含め、その背景やメリットについて解説したいと思います。

既に複数のアプリを公開している企業様や、これから複数のブランドでアプリ公開を検討している企業のご担当者様は、是非ご参考いただければと存じます。

■目次
1.ブランド別に複数のアプリを開発する企業が増加
2.ブランド別アプリ開発の課題と対処
3.共通システムを活用したブランド別アプリ開発事例
(1)しまむら
(2)青山商事
(3)AOKI
4.共通のシステム上で開発を行う事の3つのメリット
5.まとめ:これからのブランド別アプリ開発戦略

1.ブランド別に複数のアプリを展開する企業が増加

スマートフォンの普及に伴い、企業の公式アプリ開発は増加の一途を辿っています。

アプリ開発にあたり、単一ブランドを運営する企業の場合はブランド名でアプリ開発を行う形が一般的ですが、複数のブランドを展開する企業の場合には、以下の2つの選択肢から開発方針を選択する必要があります。

  1. 複数のブランドをまとめた企業・グループ名で、1つのアプリを開発する(モンテローザ等)
  2. ブランドごとに複数のアプリを開発する(しまむら等)

モンテローザ・しまむら アプリ

モンテローザ/しまむら

以前はアプリ開発の費用などを考慮し、(1)の企業/グループ単位でのアプリ開発も見られましたが、以下のような課題があり、マーケティング上ベストな状態と言いにくい面がありました。

  • ターゲット層の違う複数のブランドを一つにまとめてしまうと、ブランドイメージが曖昧になってしまう。
  • ブランド名に比べ認知度の低い企業名では、アプリストア等で検索されにくく、ダウンロード数が伸びにくい。

そのため近年では、今回取り上げるしまむら・青山商事・AOKIなどのように、ブランド別に複数のアプリを開発する(2)のケースが増えているようです。

2.ブランド別アプリ開発の課題と対処

しかしながら、複数のアプリを開発する際に課題となるのが、アプリ開発や改修にあたっての手間・コストです。

スマートフォンアプリはOSや端末に合わせ開発/テストの工数がかかりやすく、一般のウェブサイトより制作費用が嵩む面があります。開発するアプリの数が増えればその分アプリの開発費や運用コストが増えてしまう事から、それらを懸念し、ブランド別のアプリ開発を避けるケースも多かったのではないでしょうか。

これらの課題を解決するのが、共通のシステムを使い、複数のアプリを効率良く開発・改修する形です。

?3.共通システムを活用したブランド別アプリ開発事例

「共通システムでのアプリ開発」とは、一つの企業が、ブランドや用途に合わせたアプリを、共通化されたシステム上で複数開発している状態を指します。システムの共通化を図る事により、個別開発を行う場合に比べアプリ開発にかかる工数やコストを抑える事が可能になる事から、多くの企業で導入が増えているようです。

スマートフォンアプリは通常、スマートフォンにダウンロードするフロントエンドのアプリと、そこに情報を提供するバックエンドのサーバー・システムとで成り立ちますが、各画面のデザインやUIを比較する事により、アプリおよびシステムが共通化されているか否かをおおよそ推測する事ができます。実際の事例を見てみましょう。

1.しまむら

前回の記事でも触れた「しまむら」では、ブランドごとに以下の4つのアプリを公開しています。

  1. しまむら(2013年11月公開)
  2. シャンブル(2013年11月公開)
  3. バースデイ(2013年11月公開)
  4. アベイル(2014年6月公開)

4つのアプリを並べてみると、トップ画面や下層メニューで似通ったデザインが活用されており、共通のシステムを使ってアプリ開発を行っている事が推測できます。

アベイル,しまむらアプリ_店舗検索画面

先日リリースされたアベイルアプリでは、トップ画面にドロワーメニュー方式を採用しよりデザイン性を高めた画面を実現するなど、機能を向上させている事が分かります。

アベイル,しまむらアプリ_メニュー形式

2.青山商事

続いて、紳士服最大手の青山商事の事例です。同社ではブランドごとに以下の4つのアプリを公開しています。

  1. スーツカンパニー(2012年9月)
  2. CALAJA(2013年10月)
  3. 洋服の青山(2014年3月)
  4. ネクストブルー(2014年3月)

4アプリの各画面を並べると、以下のようになります。

青山商事 アプリ(THE SUIT COMPANY,CALAJA,洋服の青山,NEXT BLUE)

上記のうち(1)と(2)はトップ画面だけでなく下層ページまでデザインやUI等が異なっており、別々のシステム上で動いている可能性が高いものと推測されます。ブランド別に事業部が分かれる同社では、マーケティング戦略の一環であるアプリ開発も各事業部に進めたであろう事が想定され、開発会社等も統一されていなかった可能性が高いでしょう。

ところが(3)と(4)の2アプリはトップ画面以外の下層メニューでデザインが似通っており、共通化されたシステムで開発をされた事が推測されます。以前の記事でも触れた通り、「洋服の青山」アプリは同社50周年の記念事業として綿密な準備を経て公開されたものであり、当初から別のブランドにも展開することを考慮し、拡張性の高いシステムを開発していたであろう事が推測されます。

現在はアプリの改修等が必要になった際、(1)と(2)と(3)・(4)の3種のアプリを修正する必要があると思われますが、今後は全体最適を考慮し、(1)(2)の先行2アプリについても、システムの共通化を実施していくのではないかと推測されます。

3.AOKI

続いて、同じく紳士服大手のアオキの事例です。同社では以下の2つのアプリを公開しています。

  1. AOKI
  2. ORIHICA

2アプリの各画面を並べると以下のようになり、トップから下層にかけ似通ったデザインが採用されている事が分かります。

AOKI(AOKI,ORIHICA)

4.共通のシステム上で開発を行う事の3つのメリット

次に、共通のシステム上でアプリを開発する事のメリットについて考えてみましょう。

1.アプリ開発費用・期間の短縮

共通のシステム上にデザインの違う複数のアプリを開発する事により、ゼロから個別にアプリを設計・開発する場合に比べて、アプリ開発の費用・期間を大幅に短縮する事が可能になります。

2.バックエンドシステムの共通化によるサーバーのコストダウン・冗長化

バックエンドのシステム/サーバーを一つにまとめる事により、別個に用意する場合に比べコストを大幅に下げられるだけでなく、サーバーの冗長化や増強などがしやすくなり、一部アプリへの急激なアクセス増にも対応がしやすくなります。

3.公開後のアプリの改修コストや改修期間の短縮

アプリ公開後も、OSのアップデートに合わせたアプリの改修や新機能の追加などアプリの改修が必要になった際、共通のシステムを改修する事で、複数のアプリを低コストで改修する事が可能になります。

5.まとめ:これからのブランド別アプリ開発戦略

これまで見てきた内容を以下にまとめます。

  1. 複数のブランドを展開する企業に於いては、ブランド別に複数のアプリを開発するケースが一般化している。
  2. ただし複数アプリの開発を別個に行うと、開発工数や費用がかさんでしまう。
  3. (2)の課題を解消する為には、複数のアプリを共通のシステムで開発する事が望ましい。
  4. (3)の開発手法はしまむら・青山商事・AOKIなど多くの企業で実際に導入されている。
  5. 共通システムでの開発によるメリットは、費用面に加え、システムの共通化や改修のし易さなど他にも多い。

最後に、(3)の「共通システムでの複数アプリ開発」の実現方法について、整理をしてみましょう。

これまで見てきたしまむら・青山商事・AOKIなどのケースでは、各社が自社独自の共通システムを開発していたものと推測されます。自社開発を行う場合、自社が思い描く必要要件を100%実現できる反面、スタートの段階で共通化を念頭に拡張性の高いシステムを要件定義し開発する手間と時間を許容できるかや、自社開発で必然となるサーバー等の多額の初期費用を許容できるかといった点は、個別開発程ではないにせよ、考慮が必要と言えるでしょう。

もう一つの方法が、弊社が提供する「ModuleApps」のような外部のアプリ開発プラットフォームを活用し、自社開発と同等のメリットを得る事です。

ModuleAppsは共通のバックエンドサーバー/システムと共通のコアモジュールをアプリ開発のベースとする事で、各社の要望に合わせた複数のアプリを低コスト・短納期で開発・改修できるよう設計されており、単一ブランドでの開発実績だけでなく、実際に一部の企業では、ブランド別に3~6つ程度のアプリを開発されています。

ModuleApps開発実績

ModuleApps開発実績(ModuleAppsサイトより)

既存のプラットフォーム機能に含まれない特殊な要件は実装できない場合がある点は考慮が必要ですが、十分な機能を備えたアプリを、要件定義にかかる初期の手間・工数やサーバー等ハードウェアの初期費用を大幅に抑えつつ開発できる点は、大きなメリットと言えるでしょう。

どちらを選ぶべきかは、

  • 最終的に開発したいアプリ(ブランド)の数
  • 自社で実現したい要件
  • アプリ開発の予算や納期

など各社の事情により変わってくるでしょう。まずは両方の選択肢を俎上に挙げ、自社で実現したい要件は何か、その実現手段としてどちらが適しているのかを比較検討する事が望ましいと言えるのではないでしょうか。

アプリ開発を検討中の企業様には、是非当記事を参考にしていただければ幸いです。