アプリ開発の市場で勝つにはどうすれば良いのか調べてみた
皆さん「これは毎日使うぞ」というアプリはありますか？僕は Twitter、Kindle、YouTubeです。本当に毎日使っていますが、もはや完全に習慣となっており、生活の一部にまで溶け込むUXに感心するばかりです。ちなみに、YouTubeのiOSアプリのバージョンは14.51.5です。継続的な改善の歴史を感じますね。
さて、僕もそんなアプリの業界で働く一人なのですが、競争がとても激しく、ユーザーの品質への期待値も高まり、なかなかのハードモードです。なんとか上手く立ち回りたいなと思って、色々調べているので備忘録がてらブログにまとめたいと思います。
ソフトウェア開発を取り巻く市場の変化と戦い方
今回は上記の3つの本 / 記事を読んでみました。現在のソフトウェア開発を取り巻く状況の変化と、それらを踏まえてどのように戦うべきかに鋭く触れており、大変勉強になりました。以下、自分が読みながら取っていたメモです。詳しく知りたい人はぜひ元のリンク先を訪れてみてください。
ソフトウェアの市場の変化
- Software Is Eating The World。あらゆる産業にソフトウェアが浸食し、業界構造を再編している。ハードウェアがソフトウェアと一体となり、常にネットワークに繋がる状態（コネクティッド）が一般化することで、サービス提供者と消費者の間の関係性が変わってきている。
ソフトウェアのビジネスモデルの変化
- Before
- ひと昔前は「売り切り」の時代だった。例えば、Microsoft Office や Adobe Photoshop が電気量販店で売られ、消費者は決して安くない価格で購入をする。その為、消費者は元を取るまでは使わないと損という感覚を持っていた。
- 提供者は、商品が買われたその時点で消費者との関係性が終了するため、売買が発生するまでにフォーカスを置いていた。
- 開発スタイルは、「売り切り」の時代だからこそ、ウォーターフォール型の開発が適していた。ひとたび売買が終了すれば、ユーザーに新しいバージョンに切り替えてもらうハードルは高い。なので、リリースまでが勝負で、最大限の設計・実装・テストを尽くしリリース日を迎える。
- After
- Software as a Service という言葉が生まれ、完成形のソフトウェアがクラウドで提供されるようになった。「売り切り」から「サブスクリプション」の時代になり、消費者に対する売買発生時の初期コストが急激に安くなった。つまり、元を取るまでは使い続けるという考え方はなくなり、ちょっと試して合わなければすぐに止めればいいやという発想が一般化してきた（フリーミアムモデルも合わせて一般化）。
- 提供者は、プロダクトが買われた以降もユーザーと関係が続いていく為、ユーザーに長く使ってもらうことにフォーカスを置き始めた。
- 開発スタイルは、「サブスクリプション」にはアジャイル開発が適している。変化の早い現代で消費者の心を掴み続けるために、リリースしてからが勝負で、プロダクトを継続的に改善し、アップデートをし続けている。また、ユーザーに使われない機能を開発しても意味がないため（*売り切りの時代では入り口で売上が発生するので使用の有無は関係なかった）、なるべく早くリリースしてユーザーに試してもらい、ニーズがあると判断してから開発を加速させるやり方が主流となった。
SaaS時代 （=乗り換えコストが低く、各社が継続して改善を続ける競争の激しい時代）の戦い方
- プロダクトではなく顧客体験をデザインする
- ユーザーがプロダクトを使っている時間だけではなく、その前後の時間や一連の流れまでを考慮して、プロダクトを作らなければいけない。多くの競合が存在するなかで、またSNSや口コミサイトへの投稿が当たり前の時代で、ユーザーの感情を軽視したプロダクトは受け入れられなくなっている
- どうやって顧客体験をデザインするか
- ユーザーの隠れたニーズを見抜く、満足度を高めるUX設計、メンテナンス性・拡張性の高い仕様設計、パフォーマンスの高いアプリの実装、最適化されたマーケティング・ブランディング・コミュニティ運営、堅実な収益モデルなど、様々な要素を高いレベルで実現する必要がある。
- これらはビジネス・テクノロジー・デザインが協力して取り組むことで初めて達成できる。
- どうやってビジネス・テクノロジー・デザインが協力し合うか
- ビジネスだけではなく、テクノロジー、デザインが経営レイヤーに入る
- 戦略や意思決定にはビジネス、テクノロジー、デザインの3者が立ち会う
- ビジネス、テクノロジー、デザインの領域に存在する組織間の壁を取り払い、3者が有機的に繋がるチームを作る
- 定性的な共通理解の形成を図る
- 羅針盤として機能するミッションを設定する。「Who が What をして、 Result になる」のように具体性を持たせる。
- サービスの正のロールモデル、負のロールモデルを言語化しておく。
- 成長モデルをシンプルにする。
- 相手の言葉、相手の譲れないことを理解する。
- 定量的な共通理解の形成を図る
- 数値目標、KPI設計。
- ログ分析、アンケート収集、統計的分析。
- 一方に偏らない仕組みを整備する
- 目先の目標（来月の売上など）を追う開発チームと、長期的な取り組みをする開発チームを分けておく。
自分のメモを最後に眺めて見て
やっぱり仕事のハードルが高くなっているなあ。マーケティング・セールスだけが強くても悪い口コミが出回ればサービスは滅びるし、プロダクトだけが強くてもユーザーには届かない。たとえマーケティングとプロダクトが強くてもユーザーが持つ可処分時間は限られているので顧客体験の完成度が低くければ継続して使ってもらえない。高いレベルの顧客体験の提供にチームが一丸となって取り組めるかが勝負の別れ道なんだと思います。
