アプリのアップデートが行き詰る多機能化の罠に気を付けよう

ソフトウエアはバージョンアップを重ねて多機能化していきます。
使い勝手を改善する「変更」もありますが、大抵は機能が「追加」されていく一方です。
当初は評判の良かったソフトも、どんどん肥大化して使いづらくなることが往々にしてあり、デジカメ用の画像ビューアもそうでした。
顧客体験をモニターしながら改良していくDevOpsの時代になっても、そうした失敗から学んでおくことは有益ではないでしょうか。

バージョンアップの始まり

パソコンの標準機能がまだ満足に画像を扱えなかったデジカメの黎明期、デジカメの画像に対応したパソコン用Viewerソフト（Windows/Mac）を開発して製品にバンドルしていました。
初期のViewerは ”ExifViewer”といい、その名の通り、デジカメが記録するExif形式※の画像ファイルを一覧し、画像と撮影情報（カメラ名、撮影日時、シャッター速度や絞り値等々がわかります）を確認できるシンプルなものでした。
※Exifは富士フイルムが提唱しJEITA（電子情報技術産業協会、当時はJEIDA）で規格化された画像フォーマットです。
今でいえばエクスプローラー（macのファインダ）がファイルアイコンを表示するようなもので、起動してすぐ一覧が表示できました。

さて、いったん画像Viewerが使われ始め、それが当たり前になると、今度は画像加工がしたい要望が出てきます。市販の画像編集ソフトはありますが買うと数万円以上するので、そこまで本格的でなくても簡単な調整機能が望まれます。デジカメの方も機能競争によって動画や音声などを記録するようになり、Viewerは様々なファイルタイプを再生する必要が出てきます。加えて、フィルムからデジタルに変わることで撮った後の楽しみ方を提案する競争も始まっていました。

かくしてViewerは “FinePixViewer” となり、次々と機能を拡張してゆくサイクルが始まりました。
ソフト単品でのビジネス機会はありませんが、デジカメの商品化予算で賄われるので開発者には恵まれた条件だったと言えるかもしれません。
デジカメ新製品にはViewerの最新版がCD-ROMで同梱され、旧バージョンのユーザーへはWebサイトでアップデーターを提供しました。

FUJIFILM “Picture The Future” 利用ガイドより (2001年)

周期的な行き詰まり

ところが、高機能化はデメリットももたらします。様々なファイルに対応したために、フォルダ内のファイルを調べる処理が増えて、当時のPCの性能ではサムネール一覧（画像を小さく並べたもの）が表示されるまでに時間がかかるようになりました。また、機能が増えるにつれてプログラムサイズが大きくなり、起動にも時間がかかるようになります。その結果、初期のViewerのような軽快さがなくなり、起動するたびにストレスを感じる人が増えました。また、増えた機能はメニューやアイコンとなってViewerウインドウの周りを取り囲み、初めて使う人には難解なソフトに見えるようになりました。

少しでも多くの顧客要望に応えようと頑張って機能アップすればするほど、むしろ使いづらくなって評判を落とし、やがて改造で対応できる限度を越えます。そこでコンセプトを変えて新アプリを開発して切り替えるのですが、また同じ道を辿ってしまうのです。

上記のViewer変遷を見ると、行き詰まりとリメイクを繰り返したのが分かります。
アップデートを続けることでハマっていた罠がありました。

差分思考の罠

使用歴の長いユーザーとメーカーは変化を共有してきているので差分で理解しています。細かい違いは敏感ですが全体像には鈍感になります。一方、市場が成熟することで、新しいユーザーがたくさん入ってきます。初めて使う人たちにとっては、それまでの経緯など関係ありません。既存ユーザーと新規ユーザーでは、見える景色が異なるため、新規ユーザーの方が多数派になってくると、わかりにくさへの批判の声が突然大きくなって壁に突き当たります。
「簡単操作化」の大改修をすると新規ユーザーからの評判は良くなる半面、ほぼ確実に既存ユーザーには不評というジレンマが追い打ちをかけます。かくして、より良くしようと改良し続けるあまり、複雑さを増し、クソアプリと言われるまで突き進んでしまいます。

アプリの外部環境の変化にも理由があります。初期はPCやスマホにある程度詳しい人がアプリを使いますが、デジカメにせよ他の機器にせよ、普及期にはPCやスマホ自体に不慣れなユーザーも増えてくるため、初期には説明不要だった手順や用語に対する配慮も必要になってくることもあります。

我田引水の罠

自社都合でやりたいことがあるとき、既存のソフト資産を活かして別の目的も相乗りする（例えばViewerを利用してユーザーにフォトブックを販促したい）誘惑が発生します。一見投資効率が良さげに見えるため、つい追加機能を入れてしまうのです。
その結果、アプリの役割・優先順位が混乱し、ユーザーにとっては理解しづらいものになります。気付かれないこともあります。狙い通りユーザーに刺さることはまずありません。
無理筋だった実例を２つ挙げましょう。

（１）パソコンのプリインストール・ビューアーでプリント注文

東芝社と提携してマルチメディア・ノートPCにViewerソフトの特別版をプリインストールしたことがあります（PCを買った時点でソフトが入っている）。人気のパソコンシリーズでしたので、富士フイルムとしてはシェア低下していたFinePixブランドの宣伝とフィルムに代わってデジカメプリント需要の掘り起こしへの期待がありました。Viewerにはラボ機由来の画像補正技術でボタンひとつで画像を綺麗にする機能があり、Viewerから富士フイルムのネットプリント注文へ画像を送ると初回10枚無料になる特典を付けていました。
自社製品での経験上、ネットプリント注文は一度うまくいくやり方を覚えたユーザーは同じやり方を繰り返す傾向がわかっていたので、一度誘導できればリピートの期待がありました。

提携は2年ほど継続したでしょうか。結果としては残念なものでした。Viewer経由の注文のほとんどが10枚のお試しで終わっており、利用者数もPC販売推定数に比べてかなり少なかったのです。
ユーザーにとってViewerはViewerです。最初からネットプリント注文するつもりの人はWebの注文サイトを探して行きます。つまり、Viewerに本来の目的以外のおまけがついていても注目されないし、おまけの効果でViewerが活用されるわけでもない。シナジーとは互いの価値を高める何かがあって 1.2 x 1.2 = 1.44 みたいに掛け合わせになることで、単に相乗りしただけでは 1 x 1 = 1 でしかありませんでした。
実は、デジカメ用の本家Viewerでも様々なプリント注文への橋渡し機能をトライしていましたが、大きな効果を上げたものはなく、プリント注文はスマホやWeb経由で伸びて行きました。

（２）様々なスマホカメラアプリからのフォトブック注文　

スマホのカメラアプが活況だった頃。富士フイルムのラボへのプリント注文SDKをスマホアプリ開発者へ提供し、多様なアプリからフォトブック注文をロングテールで集めようというプロジェクト（P4：Print Product Partner Program）がありました。注文ごとにアプリ開発者へリベニューシェアをします。

多くのアプリベンダーさんたちを呼び込む先例を作るため、共同でプロジェクトを立ち上げたベンダーにお手本カメラアプリを複数作ってもらいました。スマホ内にデザインの良いテーマ毎の写真アルバムを作るカメラアプリです。赤ちゃん撮りに特化したテンプレートの子供アルバムアプリ、旅行に特化した構成の旅行カメラアプリ等を仕込みました。

AppStoreで公開してSNSでターゲティング広告を入れてブーストします。ダウンロードしてアルバムを完成させるユーザーが増えてくる頃合いまで待って、アプリに「フォトブック注文できるようになりました」アップデートを配信します。スマホ画面で既にアルバムライクになっているので、実物のフォトブックも注文しちゃうでしょ～、と思いきや、そうはなりませんでした。
同じ時期に、社内の別プロジェクトで「簡単フォトブック」というスマホアプリを出します。タイトル通り簡単な手順でスマホ内に溜めている画像を選んでフォトブック注文が出せます。手軽さ重視なので凝った編集はなく、赤ちゃん専用のテンプレがあるわけでもないのにこっちがヒット。次々とダウンロードされてフォトブック注文が来るようになったのです。

フォトブックを作る目的で使っていたわけではないアプリにフォトブック注文機能がついても（テーマやテンプレが凝っていても）気持ちは動かない一方で、フォトブックを作りたい人はフォトブック作成アプリをダウンロードして注文する。当たり前といえば当たり前なのですが、売り手の都合で目的を追加してもユーザーには刺さらないことをまざまざと教えられた案件でした。

ユーザーは目的があってそれに適うアプリを選び、期待する役割から外れた機能には関心をもたない。作り手の都合で別目的を相乗りさせても、ユーザーにはほとんど届かないのです。
１つ１つのアプリが目的にしっかりフォーカスすることが大事だと言えるでしょう。

クソアプリ化の兆候

こうした経験から、まずい状況になっていくときの兆候を挙げることができます。

起動や画面切替えが遅くなる
普段使う機能にひと手間ふえる
何のアプリかを一言で言えなくなる
説明しづらいオプション項目が増えていく

これらを満たすと、ほぼ確実にクソアプリ化し、ユーザーが代替手段に逃げてしまう。
私が身近に使うアプリの中で最もこの条件に合致するのが MS-Office とりわけ Outlook なのですが、このオプション設定は、もはや自分にどう関係するのか分からないし、うっかりいじると何が起きるのか怖くて触れなくなっています。（このような画面があと10倍以上ある）

プロセスの問題

開発と運用の意思決定が一体となってDevOpsが出来る組織では、こうした兆候に気付ければ軌道修正はしやすいはずです。
DevOpsが難しいメーカーなどの組織でアプリ開発する場合、企画案には導入とバージョンアップ計画の記載はあっても終了方針が明記されないケースが多いのではないでしょうか。モノ売りでは企画台数・販売計画が決まればサポートパーツの調達からEOL（保守終了）までプロセスが確立していて自ずと決まるのに対し、アプリは変動原価で考えないためEOLが自明でないことを見逃しがちだからです。企画段階で撤退プランを織り込んでおきましょう。
デジカメ用のアプリでは、対象のカメラがなくなってもアプリは継続が求められる場合やアプリが先に不要になる場合などアプリによってパターンはまちまちでした。導入後はどういう判断基準とプロセスでディスコンしていくのか、アプリごとにライフサイクルを決めなければなりません。DevOps出来ないからこそ「決定済みの計画」にしておかないと状況が変る都度の意思決定が大変だろうと思います。

但し、今後はDevOpsできない組織は業界問わず淘汰されていくでしょうから、このプロセスはもう過去の課題かもしれません。

回避策まとめ

ユーザーはアプリを起動してから目的を選ぶのではなく、目的でアプリを選ぶ。目的がブレてアプリが肥大化すると結局どの目的にも使ってもらえないことや、相乗効果のない組み合わせに価値はないことを見てきました。また、高機能化を進めすぎると、揺り戻しで簡単操作への大改造が必要になり、やがて新アプリへと切り替えざるを得なくなるサイクルがありました。

ロスや行き詰まりを避けるために３点挙げたいと思います。

目的でアプリを分け、目的からブレずに進化させる
ユーザーの成長・ユーザー層の変化に対応する
ライフサイクルの終了まで描いて進める

とはいえ商品開発の現場には様々な事情・制約があります。私自身、リソースが足りず増員も期待できないなかで管理するアプリを減らすために悪手と知りつつ２つのアプリを１つにまとめてしまったり、非機能要件で劣化に気付いていながら日程優先で直せなかったり、現実は苦渋の選択の連続だったことを弁解しておきます。

以上

「フォーカス! 利益を出しつづける会社にする究極の方法」アル・ライズ（2007）（Amazon）

目的を正しく探り当てることの難しさも含めて、目的にフォーカスする重要性を痛感できる。

「ジョブ理論イノベーションを予測可能にする消費のメカニズム」クリステンセン（2017）（Amazon）

顧客が片づけたいジョブに応えなければ、おまけを増やしても価値は上がらない。