モバイル実装戦略の選択

過去5年間におけるモバイルテクノロジーの急激な発展は、大きな機会を提供しています。多くのモバイルプラットフォームが引き続き繁栄する可能性が高い一方で、モバイルユーザーはアプリケーションにおいて非常に高い品質のユーザーエクスペリエンスを求めています。この記事では、ユーザーエクスペリエンスとプラットフォームカバレッジのバランスを取りながら、アプリの将来への道筋を示すモバイルチャネル実装のための2つの戦略を紹介します。

2012年5月21日


Photo of Giles Alexander

Giles AlexanderはThoughtworksのリードコンサルタントです。R&D製品開発の経歴を持ち、現在はThoughtworksのクライアントがモバイルアプリケーションとそれを支えるアーキテクチャを開発・提供する支援を専門としています。


モバイルが重要な理由

モバイルは新しいウェブ:2000年、企業は商業と顧客関係の未来が急成長中のウェブにあることに気づき始めました。数年後には、ウェブコマースは従来のオフラインコマースを凌駕しました。現在のモバイルコマースはウェブコマースのごく一部ですが、数年後にはウェブコマースを凌駕するでしょう。

大小の企業はこれを認識しており、到来するモバイル利用の波に備え、それを活用するための製品を計画しています。これらの製品は革新的で魅力的です。実際、多くの企業が、モバイルテクノロジーが追いついてくるのを待っている製品を計画しています。

モバイルが爆発的に普及しているのには理由があります。人々はモバイルのエンゲージメントと即時性を好むからです。モバイルは人のライフスタイルにフィットし、人と一緒に移動しますが、テクノロジーの都合に合わせて人が合わせる必要はありません。そして、この変化には、新しいチャネルを通じて同じものを販売すること以上の、新しい機会があります。

しかし、モバイル市場は複数のプラットフォームに分散しています。優れた製品アイデアを持つだけでは不十分です。これらのアイデアを実行するための計画も必要です。計画では、多くの異なる要因を考慮する必要があります。しかし、まず、エクスペリエンスとプラットフォームカバレッジのどちらがより重要でしょうか?

エクスペリエンスの重要性

過去10年間、ウェブの台頭を通して、広告は販売における受け入れられた知恵でした。これは正確で効果的でした。ウェブは直接的な接続と仲介排除の巨大な沼地でした。そして、これは消費者にとって素晴らしいことですが—ある程度までは—ベンダーが消費者の前に自分の名前を出す方法を見つける必要がありました。その結果、よりターゲットを絞った、より侵入的な広告の競争が繰り広げられました。

モバイルは問いかけます

もし私の店があなたの好きな店で、常にあなたのポケットに入っているなら、なぜ私はあなたが昨晩何を食べたかを知る必要があるのでしょうか?

つまり、高品質なエクスペリエンスは顧客を引きつけ、維持します。結局のところ、買い物はレジャー活動です。一度維持されれば、これらの顧客に広告するための特定のトラッキングはそれほど必要ありません。しかし、最先端のユーザーエクスペリエンスを維持することは必要です。なぜなら、それがモバイルユーザーが追いかけているものだからです。

モバイルの爆発的普及の過去5年間は、ユーザーエクスペリエンスの忠実度の着実な向上物語でした。Appleは、より高品質なエクスペリエンスを提供することに基づいて、モバイル市場で強い地位を確立しました。結果として、プラットフォームを問わず、アプリ開発者はモバイルユーザーの高い期待を満たすか、それを超えることを目指しています。

特に注目すべきは、Windows Phone 7でモバイルの世界に後発参入したMicrosoftが、主にAppleのiOSエクスペリエンスを上回ることで市場ポジションを獲得しようとしていることです。彼らは確かにAppleを上回っているように見えますが、遅すぎるのでしょうか?

最初の戦略

エクスペリエンスが主要な目標である可能性がありますが、考慮すべき4つか5つの異なるモバイルプラットフォームがあります:iOS、Android、BlackBerry、Windows Phone 7、モバイルウェブです。これらのプラットフォームのうち2つ以上が重要である場合、それらすべてで高忠実度のエクスペリエンスを提供することは、非常に高価で時間のかかる作業になります。それは、重要なすべてのプラットフォームで素晴らしいエクスペリエンスを目指す価値がないという意味ではありません。すぐにそこに行こうとするのではなく、これを目標として考えましょう。

代わりに、モバイルへの最初のステップが何であるかを考えてみましょう。最初のステップでは、プラットフォームカバレッジとエクスペリエンスの忠実度の間で何らかのトレードオフが含まれます。アプリの性質、ビジネス、ユーザー、市場は、トレードオフがどのようなものであるべきかを決定します。これらの制約をすべて考慮すると、単一のプラットフォームをウルトラハイファイデリティエクスペリエンスでサポートすることと、すべてのプラットフォームを基本的なエクスペリエンスでサポートすることの間で、いくつかの選択肢があります。

便宜上、これら2つの極端なものをレーザー戦略と万全を期す戦略と呼びます。

プラットフォームカバレッジとエクスペリエンスの忠実度の間のトレードオフは、モバイル空間に移行する際の最初の戦略にすぎないことを覚えておくことが重要です。モバイルアプリと戦略は進化します。どのような位置からスタートしても、時間とともに、すべてのプラットフォームが高忠実度のユーザーエクスペリエンスでサポートされる「素晴らしいゾーン」へと進化させることができます。しかし、アプリを進化させるために使用できるテクニックは、最初の戦略として選択した戦略によって異なります。

これらの戦略のいずれかを選択する必要があり、この選択はアプリの最初の2年間ほどに影響を与えます。この決定について意図的に取り組み、戦略の長所と短所、そして各戦略の進化パスがどのようなものになるかを理解することが重要です。

レーザー戦略

レーザー戦略とは、少数の機能と1つのプラットフォームに焦点を当て、非常に洗練された没入型のユーザーエクスペリエンスを提供することです。エクスペリエンスがアプリや製品の鍵となる場合、この戦略に従います。多くの場合、アプリ自体が製品の中核となります。

たとえば、Hipmunkのように、航空券の購入に対する大幅に新しいアプローチを提供することが目標かもしれません。あるいは、Instagramのように、デザインの影響を強く受ける特定の顧客層にリーチしようとしているかもしれません。

いずれにしても、エクスペリエンスが最も重要です。1つのプラットフォームを選択し、そのプラットフォーム上に非常に高忠実度のエクスペリエンスアプリを構築します。

進化

明白な選択肢の1つは、水平方向に進化させることです:アプリを別のモバイルプラットフォームに移植します。別のプラットフォームを追加すると、既存の開発チームとともに新しい開発チームが開始されるため、構築とメンテナンスの両方のコストが増加します。移植作業の終了時には、新しいプラットフォームがサポートされますが、新しい機能は導入されません。つまり、基本的に同じアプリをもう一度入手するだけです。製品の範囲を拡大する機会を失うことに加えて、真の損失は、製品の機能セットを学習し、適応させる機会を失うことです。

別の方法としては、新しいプラットフォームを新しい製品や機能のアイデアを探求する機会として使用することです。これにより、忠実度の低いエクスペリエンスを持つ異なる機能セットが生成される可能性があります。新しい機能が成功すれば、これらを元のアプリに統合できます。

違いを受け入れると呼ばれる、レーザー戦略の具体的な進化があります。しかし、このアプローチの詳細に進む前に、レーザー戦略をもう一方の極端な戦略である万全を期す戦略と比較したいと思います。

万全を期す戦略

万全を期す戦略とは、多くの、場合によってはすべてのモバイルプラットフォームで、忠実度の低いアプリを構築することに焦点を当てることです。このアプリは、すべてのプラットフォームで一貫した機能セットとエクスペリエンスを提供します。この戦略は、すでに大規模なユーザーベースを持っており、アプリが既存製品にアクセスするための新しいチャネルとなる場合に最も適しています。

既存のユーザーベースがあるため、最も重要なのは、できるだけ多くのユーザーの前に新しいチャネルを提供することです。明らかに、プラットフォームカバレッジが最も重要です。しかし、これはモバイルであるため、エクスペリエンスも非常に重要です。劣化させたエクスペリエンスを提供するのではなく、最小限の機能セットを持つ簡素化されたエクスペリエンスを提供します。

進化

この戦略の進化は、レーザー戦略よりもはるかに簡単です。すべてのプラットフォームでアプリのエクスペリエンスの品質を向上させることによって、アプリを垂直方向に進化させます。ただし、2つの考慮事項があります。

まず、プラットフォームによっては、価値が大きく異なる場合があります。製品とユーザーにとって最も重要なプラットフォームを見つけ、そこで努力を集中させます。これらのプラットフォームでのエクスペリエンスを、他のプラットフォームよりも徐々に—または一気に—向上させます。

次に、万全を期す戦略は、何らかのクロスプラットフォームテクノロジーを前提としています。クロスプラットフォームフレームワークなどは、最低限の共通分母アプローチを提供することで機能します。これにより、アプリ開発の一貫性が確保されますが、提供できるエクスペリエンスの品質に上限が設定されます。クロスプラットフォームツールキットを選択する際には、この上限を考慮することが重要です。上限はあなたの用途にとって十分に高いですか?少なくとも最も価値のあるプラットフォームで、上限を突破する方法がありますか?これらの質問を考慮せずに、1年後にはアプリを最初から書き直す必要があることに気付くかもしれません。

「類似性の活用」として知られる進化戦略は、カバー・ユア・ベース戦略に着手する際に非常に効果的です。これについて詳しく説明する前に、レーザー戦略の進化アプローチである「違いの受容」に戻りたいと思います。

違いを受け入れる

レーザー戦略が最適な最初の策であると決定したら、そこからプラットフォームの範囲を拡大するためのアプローチの1つは、プラットフォーム間の違いを受け入れることです。各モバイルプラットフォームとチャネルには、異なるインタラクションパターンと使用傾向があります。モバイルは人々の生活に組み込まれているため、iPhoneとiPadの両方のユーザーに同じ製品をアプリとして提供する場合でも、iPadを使用する状況が異なるため、アプリはユーザーにとって事実上異なる製品になります。

すべてのプラットフォームが基本的に同じであると見せかけるのではなく、これらの違いを利用して、アプリの機能セットを試行錯誤し、拡張します。

Facebookによって最近買収されたInstagramを考えてみましょう。彼らはiPhoneアプリと、写真にビンテージフィルターを適用し、それを友達と共有するという2つの機能だけで、非常に効果的に成長しました。彼らはレーザー戦略の典型的な例であり、デスクトップウェブサイトさえ持っていませんでした。

iPhoneでの成長を通して、繰り返し問われていたのは、いつAndroidアプリをリリースするかということでした。暗黙の仮定は、Instagramがさらに大きな市場シェアを獲得するための最善の方法は、同等のAndroidアプリをリリースすることだったということです。しかし、Instagramの市場シェアは問題ではありませんでした。彼らは処理できるよりも速く急成長していました。彼らの問題は、構築した膨大なユーザーベースとソーシャルネットワークの価値をどのように活用すればよいか、実際に分からなかったことです。

たとえば、通常のInstagramユーザーは、iPhoneを使用してのみソーシャルネットワークとやり取りできます。iPhoneのインタラクションモデルは、写真の投稿または現在の状況の確認を迅速に行うことを中心に構築されています。ブラウジングや詳細な探索には適していません。Instagramユーザーが別のユーザーをフォローし始めると、そのユーザーの古い写真を快適に閲覧することはできません。その新しいユーザーからのリンクをフォローすることも不便です。どの写真が好きで、他に誰がフォローされていますか?

これらはすべて、現在はやりのないデスクトップウェブ、あるいはタブレットの方が適したタスクです。

Instagramは最終的にAndroidアプリ(iPhoneアプリの直接移植)を構築しましたが、別の方法もあったでしょう。

  1. 既存のInstagramユーザーがソーシャルネットワークを探索できるように、デスクトップウェブアプリケーションを構築します。これは主に読み取り専用のアプリになりますが、ユーザーがソーシャルネットワークを拡大できるようにします。最も魅力的な機能は、既に公開されている写真のさまざまなスライドショーでしょう。このデスクトップウェブアプリケーションは、iPhoneアプリにはない新しい機能を提供します。さらに、既存のユーザーベースが生まれたばかりのソーシャルネットワークを充実させ、少なくともInstagramの世界を閲覧できるようにすることで、他のモバイルユーザーにもわずかにリーチします。このステップによるInstagramに追加コストは最小限です。これはサポートする新しいプラットフォームですが、容易に広く入手可能なスキルを備えたプラットフォームです。既存のInstagram開発者が目に見える遅延なしにこのプラットフォームを引き受ける可能性が高いです。
  2. デスクトップウェブアプリケーションを調整して、一流のiPadエクスペリエンスにします。少量の作業で、新しい機能を備えた新しいプラットフォームで非常に高品質なアプリを持つことができます。
  3. このiPadウェブアプリを使用して、ハイブリッドアプローチでこのアプリをネイティブiPadアプリケーションに埋め込みます。既存のiPhone写真共有コードを組み込んで、ソーシャルネットワークの探索と元の写真共有機能を組み合わせたネイティブiPadアプリを提供します。この時点で、Instagramはプラットフォームの範囲と機能セットの両方を拡張しました。彼らは、方向性の誤りを迅速に修正し、彼らを有名にした高品質なエクスペリエンスを維持できる一連の小さなステップでこれを行いました。

上記のように、Instagramは実際にはこの戦略に従うのではなく、Androidアプリをリリースしました。しかし、FacebookによるInstagramの買収はこのアプローチのバリエーションと見なすことができます。次にどこに行くのかを見るのは興味深いでしょう。彼らは現在、世界最大のソーシャルネットワークの一部ですが、Facebookは彼らが独立して運営し続けることを約束しています。明白な次の動きは、Facebookの力を使って限られたソーシャルネットワーキング機能を拡張することでしょう。

この実例は、まさに例です。しかし、レーザー戦略で開始した場合、同じアプリを他のプラットフォームに移植する以外に存在する代替案の種類を非常にうまく示しています。この例では、ハイブリッドウェブアプローチが非常に強く特徴付けられています。ハイブリッドウェブアプローチは、レーザー戦略の多くの進化において重要な役割を果たすと予想されますが、このオプションを排除する必要があるステップを踏む場合は注意が必要です。

類似性を活用する

違いを受け入れることがレーザー戦略の最初の策から進化するための強力な方法であるのと同様に、プラットフォーム間の類似性を活用することは、カバー・ユア・ベース戦略から進化するための効果的な方法です。カバー・ユア・ベース戦略を選択した場合、プラットフォームの範囲が主な目標になります。つまり、新しい機能が導入されると、これらの新しい機能はサポートされているすべてのプラットフォームで利用可能になる必要があります。

しかし、これはモバイルであり、ユーザーエクスペリエンスは非常に重要です。最初の策では基本的なエクスペリエンスが可能かもしれませんが、時間の経過とともにこのエクスペリエンスは向上するはずです。レーザー戦略がほぼ水平方向に進化したのに対し、カバー・ユア・ベース戦略はほぼ垂直方向に進化します。唯一の違いは、どのプラットフォームが最も価値が高いかを決定したら、これらのプラットフォームでのユーザーエクスペリエンスを加速するために努力する必要があることです。

ハイブリッドウェブアプローチは、レーザー戦略の進化に役立つ可能性がありますが、カバー・ユア・ベース戦略の基礎になると予想されます。

この戦略について、ニューヨークを拠点とし、ウェブで放送しているグローバルなテレビとラジオのニュース番組であるDemocracyNow!の例を考えてみてください。DemocracyNow!の目標は、可能な限り多くの潜在的なリスナーと視聴者にリーチすることでした。これを達成するために、DemocracyNow!はリスナーと視聴者に合ったメカニズムを提供することが重要であると認識し、モバイルアプリの構築を開始しました。モバイルアプリを使用すると、朝の通勤中にDemocracyNow!番組を簡単に視聴できます。

DemocracyNow!はモバイルウェブアプリを構築することにしました。高品質なプラットフォームカバレッジを提供するだけでなく、遭遇する可能性のあるエクスペリエンスの限界に対処する能力も提供します。たとえば、DemocracyNow!のエピソードは非常に大きなビデオファイルになる可能性があるため、後で視聴できるようにダウンロードするにはどうすればよいでしょうか?HTML5はオフラインストレージを提供しますが、容量は非常に限られており、ウェブページはバックグラウンドダウンロードプロセスを実行する能力が限られています。

この場合、エクスペリエンスの要件は高品質なユーザーインターフェースではありません。

この状況はハイブリッドアプローチに非常に適しています。DemocracyNow!ウェブアプリを取得してネイティブアプリに埋め込みます。アプリのネイティブ部分は、バックグラウンドでビデオをダウンロードし、HTML5 UIで使用できるようにします。HTML5はiOSおよびAndroidデバイスで非常に高品質なエクスペリエンスを提供するだけでなく、BlackBerryやWindows Phone 7などの低品質のデバイスでも非常にスムーズに動作低下するため、これは特に強力なアプローチです。

このようなハイブリッドアプローチに切り替えることは、クロスプラットフォームアプローチに固有のエクスペリエンスの限界を突破するための効果的な方法です。真に洗練されたハイブリッドアプローチでは、ネイティブデバイス機能へのバックグラウンドアクセスを許可するだけでなく、クロスプラットフォームUIとネイティブUIを切り替えることも可能です。これの準備には、選択したハイブリッドアプローチを慎重に検討する必要があります。HTML5には多くの利点があります。

指針と理念

基本的に、モバイル戦略の選択を導く原則はごくわずかです。まず第一に、リーンスタートアップムーブメントから出てくるアイデアに従うことをお勧めします。このムーブメントは、最小限に必要な機能セットのみを定義および開発することに固執することを促しています。モバイルはここで独自の機会を提供します。ほとんどの大企業におけるメインラインのウェブ開発は、それ自体として生命と目標を持つ巨大な組織に成長しましたが、モバイルはしばしばはるかに小さな兄弟として開始されます。もちろん、時間の経過とともに成長します。しかし、簡単であり、人々が注意深く見ていない可能性がある間、スタートアップとしてモバイル開発を実行してみてください。

スタートアップのアイデアを使用する意図は、早期にリリースすることで、製品が実際になるべきものをより迅速に学ぶことができることです。学習は重要な原則です。モバイルは新しく、プラットフォームは急速に進化しており、人々のモバイルとの関係も進化しています。これは多くの機会があることを意味しますが、それらを活用するには学習し、迅速に動かなければなりません。

前述のように、よりオープンなテクノロジーを選択することには利点があります。一般的に、オープンテクノロジーは将来の動きを制限する可能性が低くなります。これは、オープンテクノロジーが複数のベンダーによってサポートできるためです。各ベンダーは、テクノロジーの進むべき方向について多少異なる見解を持っている可能性があります。同じテクノロジーを使用しながらベンダーを切り替えることは、はるかに苦痛が少ないです。より具体的には、ウェブとウェブテクノロジーを優先します。オープンであるだけでなく、これまでにない最高のベンダーサポートを受けています。

最後に、アプリのリリースという観点で考えることを避けましょう。つまり、いくつかの機能とプラットフォームのリリースをまとめてバンドルするのではなく、機能について考え、それらを個別にリリースすることを計画しましょう。マーケティング上の理由から機能をバッチ処理することを選択する場合がありますが、それはテクノロジーと実装とは完全に独立した選択肢のままにする必要があります。機能とリリースを分離することで、プラットフォームのサポートを個別に移動することもできます。

測定する次元

ユーザーエクスペリエンスとプラットフォームカバレッジは、モバイル実装戦略を決定するための2つの重要な次元であると考えていますが、考慮すべき変数は他にも多数あります。

あなた

  • 寿命/ライフサイクル:アプリ開発プロセスをどのくらいの頻度で行いますか?アプリの寿命はどのくらいですか?すぐに置き換えられますか?短命のアプリはレーザー戦略に適しています。アプリをメンテナンスしない場合は、迅速に開発されたシングルプラットフォームアプリが最適です。
  • 予算:アプリ開発を決めたということは、ある程度の予算があるということです。しかし、何回アップデートできますか?予算がリリースには足りるが、多くのアップデートには足りない場合、「レーザー戦略」によって、少数のリリースで主要プラットフォームに効果的に焦点を当てることができます。
  • 既存システムと社内スキル:アプリを統合する必要がある大規模な社内システムはありますか?開発可能な社内スキルは?Java開発者を再教育する十分な人材はいますか?大規模で複雑な既存システムがある場合、モバイルアプリはおそらく既存製品への新たなチャネルとなるでしょう。さらに、社内スキルの再教育には、効果が出るまでに数回のリリースが必要になります。「カバー・ユア・ベース戦略」が適している可能性が高いです。

あなたのユーザー

  • ターゲットユーザーは誰か? 何が彼らを動かすのか?彼らの属性は?モバイル技術との関係は?ターゲットユーザーが絞り込まれている場合は、「レーザー戦略」で効果的にターゲットを絞り込むことができます。一方、ユーザー層が広い場合は、「カバー・ユア・ベース戦略」でできるだけ多くのユーザーにリーチすることを目指すのが最善策です。
  • 競合他社は何をしているか? 一般的に、競合他社に反応するのは良いアイデアではありませんが、モバイルまたはユーザーエクスペリエンスが重要な差別化要因の一つである場合は、認識しておくことが重要です。
  • マーケティング効果:このアプリでマーケティング効果を生み出すのが目的ですか?アプリ自体が注目を集めるためですか、それともブランド認知度を高めるためですか?ブランド構築の取り組みには2つの方法があります。アプリがブランドに貢献し、ブランドを拡大することを目的とする場合、迅速に進める必要があります。しかし、アプリ自体がブランドになることを目的とする場合、品質と長期的な進化がはるかに重要になります。

アプリ

  • アプリの性質:アプリはブランディング活動の一部ですか?競争の一部ですか?ユーザーがたまに使用するものですか、それとも顧客の既存の製品とのコミュニケーションチャネルを大幅に置き換えることを目的とした、長期間にわたって使用される主力製品になることを目的としたものですか?
  • B2[ECB]:従業員、顧客、またはビジネス向けのアプリですか?それぞれに大きく異なるインタラクションモデルがあります。一般的な見解では、従業員ははるかに低い品質のエクスペリエンスを許容します。しかし、これは変化しています。モバイルによって消費者のエクスペリエンスへの期待が高まったように、従業員の期待も高まっています。BYOD(Bring Your Own Device)の普及により、従業員を囲い込まれた顧客とみなすだけでは不十分になっています。
  • ネイティブデバイス機能:アプリはネイティブデバイス機能にどの程度アクセスする必要がありますか?

どのように実現するか?

この記事では、「レーザー戦略」と「カバー・ユア・ベース戦略」について、そしてそれらの戦略が長期的に実行可能なモバイル戦略にどのように発展していくかについて説明しましたが、実際にはどのように実現するのでしょうか?

実装戦略を実行するには、組織構造と技術選定に関する決定が必要です。この記事では、前述のようにハイブリッドWebアプローチには多くの可能性があることを除き、技術選定についてはここでは触れません。

レーザー戦略の実現

「レーザー戦略」に近い戦略に従うことを決定した場合、開発組織はそれを反映する必要があります。ここで最も重要なのは、機能とエクスペリエンスの均一性を維持するという考え方を捨てることです。代わりに、各プラットフォームを異なる速度で進化させることを許可します。

万全を期す戦略の実現

モバイルアプリの提供のための開発組織の編成に関しては、主要な目標は、すべてのプラットフォームで機能セットとエクスペリエンスを拡大できることです。これを実現する最善の方法は、機能を互いに独立して開発および提供することです。すべてのモバイルプラットフォームとバックエンドシステム全体で新機能のエンドツーエンド開発を担当する「Y字型」の機能チームを編成します。「Y」の幹はバックエンドとアプリケーションロジックの変更を開発し、次に枝に分かれてさまざまなモバイルプラットフォームに機能を提供します。このような機能チームの編成により、チームは各プラットフォームで可能な限り最高のエクスペリエンスを提供するための柔軟性を確保できます。

結論

結局のところ、誰もがモバイルが将来の波であることを知っています。テクノロジー業界の3大企業は現在、モバイル市場を争っています。しかし、以前のWebとは異なり、モバイルはユーザーエクスペリエンスを重視しています。そして、それはオンラインコマースの形状を大幅に変更する可能性があるほど重要な意味を持っています。長期間これを無視できるビジネスはまれです。

しかし、モバイルは断片化されています。そして、高品質なユーザーエクスペリエンスを構築するコストを考えると、どのように対処するのでしょうか?少なくとも最初は、プラットフォームのカバー範囲とユーザーエクスペリエンスをトレードオフする必要があると予想してください。時間とともに、多くのプラットフォームで高品質なエクスペリエンスを提供できるようになります。しかし、効率的にこれを実現するには、モバイル実装戦略の選択方法を意図的に行う必要があります。

アプリや製品の進化を想像し、最も可能性の高い進化の道筋に備えましょう。そして、特にHTML5とモバイルWebテクノロジーが提供できるものに注目しましょう。

最後に、モバイルの新しい特性を活用しましょう。リーンスタートアップとしてモバイル開発グループを運営できますか?このグループに迅速なペースと学習の文化を構築できますか?そして、開発チームをこのエキサイティングな新しい世界に備えさせましょう。


謝辞

これらのアイデアの開発とこの記事のレビューにご協力いただいたJonny LeRoy氏とPete Hodgson氏に感謝いたします。また、これらのアイデアの開発にご協力いただいたDan Tao氏、Renaud Tircher氏、Srini Raguraman氏にも感謝いたします。そして最後に、名前の扱いが本当に上手だったDan氏、Pete氏、Jonny氏に感謝いたします。

重要な改訂

2012年5月21日:martinfowler.com向け最初のバージョン