• GIZMODO
  • FUZE
  • DIGIDAY
  • gene
  • gene
  • cafeglobe
  • MYLOHAS
  • Glitty
  • roomie
  • machi-ya
  • GIZMODO
  • DIGIDAY
  • gene
  • cafeglobe
  • MYLOHAS
  • Glitty
  • machi-ya
  • roomie

堀込泰三  - ,,,,  08:00 PM

「プロ版」での大失敗を乗り越えた、Windowsデスクトップ整理アプリ『Fences』開発秘話

「プロ版」での大失敗を乗り越えた、Windowsデスクトップ整理アプリ『Fences』開発秘話

150413fences1.jpg


Fences』は、デスクトップアイコンを個別のスペースに整理するだけの、単純なアプリ。その価値は、使ってみなければわかりません。

開発したのはJeff Bargmann(ジェフ・バーグマン)氏。ずっとアプリ開発をしてきたバーグマン氏が、初めてデスクトップ整理の必要性を感じたのは高校生のときでした。アイデアはしばらく温められたあと、数年後に、「Stardock」が配布するWindowsアプリケーションとして花開きます。おかげで、筆者のデスクトップも大きく様変わりしました

有名アプリの誕生にまつわる逸話を紹介する「Behind the App」シリーズ、今回は、Fencesを開発したバーグマン氏に、アプリの誕生秘話を聞きました。


── 『Fences』のアイデアが生まれたきっかけは? あなた自身が直面していた問題の解決策としてなのか、それとも別のきっかけがあったのですか。


バーグマン:Fencesには、とても楽しい思い出があります。発表したのは2006年ですが、原型はもっと前の2000年ごろから存在していたのです。当時高校生だった私は、学校で「ウェブエディタークラブ」を運営していました。そこで気が付いたんです。ラボ内のデスクトップが不統一だったため、チームの生産性が妨げられていると。そこで、デスクトップをラベル付グループで標準化するというアイデアを思いつきました。Windowsアプリのコーディングはお手のものだったので、すぐに取り掛かり、「Desktop Icon Organizer」が誕生しました。

これに磨きをかけて商用にしようと思ったのは、6年後のことです。当時、大学とアプリ開発で手が埋まっていた私は、高校時代に開発した初期のラフバージョンをずっと使っていました。でも、私のデスクトップを見たたくさんの人々が、それを使ってみたいというので、プロジェクトを完成させようと思ったのです。



── アイデアを思いついたあと、次にした行動は何ですか?


アイデアの技術的検証を行いました。実現可能性の検討に始まり、実現するための手段を検討し、その中からベストな手段を選ぶといった具合です。そして、コンセプトを実証したのです。このように詳細な技術的検証をすることで、何ができるのか、どれぐらいの困難を伴うのかなどの情報を知ることもできます。その過程で、「商品チーム」はオプションを決め、「エンジニアリングチーム」はそのオプションを実現するためのコストを知ることができます。このプロセスは、私が開発を手掛けた商品すべてに共通するものです。

商用化を決め、コーディングを終えたあと、最初にしたのは市場でのテストです。招待者限定のベータ版、ローンチページ、β版サインアップを開始すると同時に、長年関係のあった「Stardock」との交渉を始めました。そして、当時有名だった「WinCustomize」「BetaNews」などの掲示板にリンクを貼ったところ、数百人がサインアップしてくれました。

テスターの皆さんには、参加したくれた理由とご自身のワークフローに与えた影響を入力してもらいました。おかげで、お客様のモチベーションを知ることができ、さらに個人的なつながりもたくさんできました。あの頃はStardockのCEOと私で緊密に連携してしましたが、正式に販売契約を結ぶまでは、アプリを草の根レベルに抑えていました。

つまり、質問への答えとしては、学び、検証して、とにかく動き続けたということです。


── もっとも大変だった点は? それをどのようにして乗り越えましたか?


多くのアプリと同じで、流通が最大の課題でした。ユーザーの皆さんから、使ってみるまで必要性がわかりにくいというフィードバックをもらい続けていたのです。使い始めれば、中毒になるとも。

ただ、見た目にわかりやすいことから、ウイルスのように広まりやすいという、明らかなアドバンテージもありました。使っている人のデスクトップを見た人が「何それ?」と食いつきやすいのです。ただ、課金の壁やトライアル版の制約を設けてしまうと、そのアドバンテージを活かしきることができません。

そこで、極めてリスキーなアプローチをとることに決めました。Stardockのおかげで、情報を広める基盤はありました。でも、課金するのではなく、完全にフリーで提供することにしたのです。マネタイズは、あとから考えようと。

これが成功でもあり、失敗でもありました。流通の問題は解決しました。最初の2年は、かなりの手ごたえがありました。週に3万5000回ものダウンロードがあり、アクティブユーザーは100万人を越えました。でも、莫大な時間とコスト、さらに機会コストをかけているのに、誰もお金を出してくれないことが問題でした。そして、「プロ版」を提供してフリーミアムに移行したのは大失敗でした。それに、フリーであることで築いてきた信用があるので、やすやすと課金をするわけにいきません。

翌年は、プロ版について様々なアプローチを試しましたが、どれもうまくいきませんでした。そうしている間に、アプリは勢いを失います。1年間いろいろ試しましたが、ダメでした。私たちは、流通の課題を解決しながら、アプリを殺してしまったのでしょうか?

2012年の夏。有料のv2.0を作ることを決めました。フリーの1.0は残しつつ、2.0には重要な新機能を加えました。フォルダーポータル、デスクトップ「ページ」などのイノベーティブな新機能、新しいUIなど、大幅な改善を実施したのです。有意義なアップグレードを行えば、有料でも使ってもらえるのではないかというのが、私たちの願いでした。そして、それはうまく行ったのです! 1日に6000回のダウンロードを記録し、恐れていた流入トラフィックの消滅は起こりませんでした。お金を払いたくない人は1.0を使い続ければいいので、ネガティブな反応は限定的でした。おまけに、新バージョンを通知することができる巨大なユーザーベースが存在していたのです。

つまり、最終的には、流通のギャンブルは成功したと言っていいでしょう。でも、莫大なリスクがあったのも事実です。


150413fences2.jpg


── ローンチした時はどのような感じでしたか?


当時はアプリストアのようなものはなかったので、「ローンチ」は今のそれとは大きく異なるものでした。ローンチ前に、すでに何千人もの人がFencesを使っていたのです。

私たちは、ローンチを唯一の検証の舞台にせずに、開発しながらFencesを自然に進化させてきました。各ステップでさまざまなことを学び、順応しながら、徐々にオーディエンスを増やしていったのです。最初は10人、次に100人、200人、1000人に検証してもらい、少しずつ方向性に自信を付けてきました。そうやって徹底的な検証を終えたあと、単なるマーケティングイベントとして「ローンチ」があったのです。

一方で、ここ数年のiOS版ローンチに参加して思ったのは、最近では避けられない「trough of sorrow」(悲しみの谷)よりも、私のやり方の方が自然だということ。モバイルの世界では、ローンチそのものが、かつてはもっと簡単にできたはずの検証のステップになっています。残念なことに、昨今の市場の透明性のおかげで、ソフトなローンチをすると苦し紛れな印象を与えかねないため、避けるしかありません。つまり、大きくローンチして、検証して、必要に応じて方向転換をして進めていくしかない場合があるのです。Fencesではその必要がなかったのが幸いでした。


── ユーザーの要求や批判にはどのように対応していますか?


注意深く対応しています。この仕事を始めたばかりのころ、ユーザーリクエストを一貫性なく扱っていました。でも、それだと商品が肥大化してしまい、焦点がぼけてしまうことを知りました。

プロダクトマネジャーがやるべきは、ユーザーのフィードバックからテーマとパターンを抽出することです。Fencesでは、掲示板でデータを収集しました。「PhotoDrive」など、比較的最近のアプリでは、アプリ内にフィードバックのリンクを目立たせることで、ユーザーが声を上げやすいようにしています。批判は、反対側からの意見だと思っています。つまり、それはデータの1点であり、データの集合がトレンドを作ります。だから、批判は注意深く検討しますが、後回しにはしません。また、さらなる反対意見を募ることもあります。トレンドが見えたら、仲間とブレインストーミングを行い、対策プランを組み立てます。とてもわかりやすいプロセスでしょう。

エンジニアリングの観点では、批判にはもっと積極的に飛びつくべきです。私はトヨタ生産方式を信奉していて、それをソフトウェア開発に適用しています。品質を最大に保ちながら技術的負債を最小に抑えるために、問題が見つかった瞬間にすべてを中断し、改善策を考える。その場で解決できない場合、それを優先課題とするか後回しにするかを決断するという方法です。

Fencesは、成熟しているようでいて、背後では非常に複雑な処理が行われています。初期段階では、スクリーンシェアによって問題を診断することがしょっちゅうでした。それが、iOSで開発を行っている今では、完ぺきなデバッグログと「MixPanel」分析を使って、バーチャルに「そこにいる」という感じですね。エンジニアリングの観点では、批判に反応することが品質向上のカギと言えるでしょう。


── 同じような試みをしようとしている人に、どのようなアドバイスを送りますか?


  • 小さく始める。

  • 実験する。

  • もっと実験する!

  • クリエイトし続ける。課題を解決する。頭を使う。

  • 学ぶ。検証する。一歩離れ、心をクリアにして、1週間後か1か月後に厳密に見直す。これを複数回行う。

  • パートナーを見つける! 一人でやらない。

  • パートナー選びは慎重に。

  • 信頼できるアドバイザーの小グループを作る。

  • メンターとの関係を築く。メンターに耳を傾ける。お返しに貢献する。

  • 失敗を恐れない。挑戦する。まずは失敗する。学ぶ。動き続ける。

  • こんなクリエイティブなことに取り組めるチャンスを得られる人は多くない。できることに感謝し、楽しむ。


幸運を祈っています!


Andy Orin(原文/訳:堀込泰三)

MORE FROM LIFEHACKER

powered by
    
    
    
  

Kotaku

Recommended

© mediagene Inc.