個人開発者の多くの方は、ご自分で保有している端末のみで検証していると思います。
一方、会社の業務としてアプリを開発している場合は、アプリを世に出す前に一定の基準をもって幅広く検証を行なっていると思います。
ただ、幅広く検証を行うにあたり、実は中身が同じもしくは似通った端末を重複して、開発や検証を行っているとすれば、コスト的にはもったいない話です。

Android端末の内部構造に関して知ろう

まず、Android端末がどのような構成で成り立っているかご存知でしょうか？
ソフトウェア的観点から見た場合、Googleが提供しているコードのみで成り立っているわけではなく、三者のコードが合わさって1つの端末が成り立っています。
三者のコードとは下記の３つになります。

• Googleのコード
• チップメーカーのコード
• メーカーのコード

Googleのコードについて

一般的にAndroidのコードはOHA(Open Handset Alliance)からリリースされているコードを示しています。基本的にはオープンソースであり誰でもOHAのホームページからコードを取得することができるコードです。（※Android3.0のみ非公開でした、Android4.0から再び取得できるようになっています。)
下記のOHAのページでコードを取得することができますので是非取得してみてください。
http://www.openhandsetalliance.com/

チップメーカーのコード

QualcommのSnapdragonやOMAP、NVIDIAのTegra、Texas Instrumentsなど各社のチップセットに合わせたコードです。
ベースはOHAのAndroidコードであり、チップに合わせた改変が行われています。MW/Linuxカーネル部分が中心ではであるが、Application層に変更を入れている場合もあります。

メーカーのコード

SONY、富士通、SHARPなどメーカーが端末をリリースするために、OHAからリリースされているコードと搭載するチップのコードを合わせて1つのコードとしています。そのコードに対して、端末に搭載されるデバイスへの対応、キャリア対応、自社アプリ対応などを行い、端末に搭載しています。

これら三者のコードが合わさり1つのコードができあがっているため、端末によって動作が異なるという問題が生じています。
メーカーが異なれば動作が異なる可能性はありますが、メーカーが同じでも、搭載チップが異なることによりコードが異なり、結果として動作が異なる可能性のほうがはるかに高いです。上記の事からリリースされている端末を、搭載OSと搭載チップでマトリックス化すると下記の図のようになります。(※メーカーはSONY・富士通・SAMSUNG・NECカシオ・SHARPの5社で分類しています)

図表：端末マトリックス図1

図表：端末マトリックス図2

図表：端末マトリックス図3

出典：http://k-tai.impress.co.jp/docs/ranking/gfk/20130215_587694.html
出典：http://bcnranking.jp/category/subcategory_0010_month.html

検証工数削減の考察

マトリックス図をみますと、同一OSと同一のチップセットから複数端末がリリースされていることがわかります。発売しているキャリア(docomo、au、softbank)が異なることで、搭載アプリケーションなどは異なってきますが、アプリケーションを開発する上で基本的な動作はほとんど変わりません。
マトリックス図にて複数端末が表示されている箇所は、その中からあるひとつの端末のみを動作確認することで、検証工数を大きく削減することができます。
例えば、XPERIA、ARROWS、GALAXY、AQUOS PHONEの主要端末の場合下記のように分類されます。

XPERIAでQualcomm Snapdragon MSM8960搭載のAndroid4.0の場合

• XPERIA GX(SO–04D)
• XPERIA SX(SO–05D)
• XPERIA AX(SO–01E)
• XPERIA VL(SOL21)

ARROWSでNVIDIA Tegra3搭載のAndroid4.0の場合

• ARROWS X(F–10D)
• ARROWS V(F–04E)
• ARROWS Z(ISW13F)

GALAXYでSamsung Exynos4210搭載のAndroid2.3の場合

• GALAXY S II(SC–02C)
• GALAXY S II WiMax(ISW11C)

AQUOS PHONEでQualcomm Snapdragon MSM8960搭載のAndroid4.0の場合

• AQUOS PHONE ZETA(SH–09D)
• AQUOS PHONE sv(SH–10D)
• AQUOS PHONE si(SH–01E)
• Vivienne Westwood(SH–01E)
• AQUOS PHONE SERIE(SHL21)
• PANTONE 6(200SH)
• DM014SH

加えて、カメラデバイスなど端末に搭載されているデバイスはチップが異なる場合は、その部分の動作が異なることが多く、デバイスを使用するアプリケーションの場合は、チップセットとOSが同じでも搭載するデバイスが異なるため、各機種ごとに動作確認を行ったほうが良いと言えます。

次にどの機種が売れているのか継続的に調査を行うことも重要で、動作保証する端末を人気機種に絞る手もコスト削減には有効です。
週次や月次でランキングが様々なホームページで発表されており、どの機種が売れているのかを確認することは比較的容易です。現在は様々機種が発売されていますが、人気機種とそうではない機種は一目瞭然です。売れ筋調査により、開発時に使う端末や検証時に使う端末は必然的に絞られてくることでしょう。

ちなみに、2012年10月から12月までの人気機種の上位は下記の通りになります。

1位:AQUOS PHONE si(SH-01E)
2位:GALAXY S III(SC-06D)
3位:Optimus G(L-01E)
4位:XPERIA acro HD(IS12S)
5位:GALAXY Note(SC-05D)
（※独自の算出方法で上位機種を割り出しています。）

1位から3位までは2012年夏/冬モデルであり、4位の2機種は2012年春モデルになります。
XPERIA AXやAQUOS PHONE ZETA(SH-02E)などは10月の時点で発売されていないためランキングに入っていませんが、2012年冬モデルの人気機種が上記3機種であるかと言われるとそうではありません。
XPERIA acro HD(IS12S)、GALAXY Note(SC-05D)は、後継機(XPERIA VLとGALAXY Note2)が発売されたため、値引きされて人気があがっている裏事情があります。
長期的にランキングをみることによって、どの機種が市場で人気であるのかを判断できるようになります。開発時や検証時に使う端末を人気機種から選ぶことで、多くのユーザに不具合の少ないアプリケーションが提供できるようになります。

さらに一歩考察を深めてみましょう。
先程のマトリックス図と1位のAQUOS PHONE si(SH-01E)をみることによって、AQUOS PHONE si(SH-01E)は下記の7機種とOSと搭載チップが同じであることがわかります。

• AQUOS PHONE ZETA(SH-09D)
• AQUOS PHONE sv(SH-10D)
• Vivienne Westwood(SH-01E)
• AQUOS PHONE SERIE(SHL21)
• PANTONE 6(200SH)
• DM014SH

たとえば、AQUOS PHONE ZETA(SH-09D)を保有しているが、人気機種のAQUOS PHONE si(SH-01E)は保有していない場合には、検証内容次第で、AQUOS PHONE ZETA(SH-09D)で代替可能なのです。

サポートOSに関する考察

アプリケーションをリリースするために、どのOSバージョンからサポートすべきなのでしょう？
もちろんアプリケーションの仕様としてサポートされているAPIから必然的にOSバージョンが決まる場合もありますが、仮に作成するアプリケーションがAndroid1.6(API Level 5)にてすべて実装可能である場合、サポートOSはAndroid1.6にすべきなのでしょうか？
個人的には「Android1.6からサポートする必要はない」と考えています。リリースするアプリの保証範囲に関してはよく検討されたほうが良いでしょう。
では、その保証範囲はどのように決めていけばよいでしょうか？1つの指標となるのが、現状のOS占有率です。

図表：OS占有率

出典：http://developer.android.com/intl/ja/about/dashboards/index.html

2013年1月時点でAndroid1.6からPlay storeのアクセス数は全体の0.3％しかありません。この0.3%のユーザの為に使いにくいUIでアプリを実装し、無駄な動作検証をするよりも、サポートする範囲を限定し、使いやすいUIで検証端末を絞りユーザビリティを向上させることを優先させたいと考えています。

また、OS占有率を見ていただくと、Androidの占有率は非常に変化が大きく1年後には大きく占有率が変わっていることが読み取れます。アプリケーションの開発期間は各社で異なりますが、長いスパンで開発をおこなう場合には１年後の占有率を予測し適切なサポートOSを選択するべきでしょう。

2012年1月から2013年1月の１年間で大きく変化をしている事がわかります。

Android2.1

2012年は8.5%の占有率で３番目に大きかったOSが2013年は2.4％まで下がっています。

Android2.2

2012年は30.4％の占有率であったAndroid2.2は下がり続け2013年には一桁の9％まで下がっています。Android2.1と同様の下がり方をした場合には来年の2014年にはわずか2.4％ととなってしまうと予測できます。

Android2.3

2012年は58.1%の占有率が2013年は47.4％と下がり幅は約10％と小さいように見えますが、Android2.3は2012年6月までは占有率があがっており、最大で64.6％となっていますが、その後7ヶ月で17％弱も占有率が下がっています。

Android4.0

2012年にはわずか0.3％の占有率が2013年には29.1％まで上昇しており、市場の3割を占める端末となっています。

Android4.1

2012年にはリリース前であり存在しなかったAndroid4.1は9％のシェアを獲得しており、Android2.2と同一の占有率です。今後、2013年の春モデルの多くがAndroid4.1を搭載することを考えると。2013年は１番伸びていくOSであると予測できます。

また、この占有率は全世界での占有率であり日本市場では少し異なってきます。日本市場では、Android端末が売れ始めたのが2012年の夏モデルからであり、この時のメジャーOSはAndroid2.3であったことが理由のひとつです。そのためAndroid2.1やAndroid2.2の占有率は、日本市場ではもっと少ない割合となっていることでしょう。
今後の傾向としても、Android4.xの占有率は伸び、Android2.xの占有率は下がる一方であることは間違いないでしょう。

総論

検証工数削減の観点において、開発用の端末と検証端末の選定基準として、下記に留意すると良いでしょう。

メーカー x OS x チップセットが同一端末を１台と考える

現在、メーカーも様々な端末をリリースしているが、実はベースは同一で派生機種を発売している場合が多々あります。派生機種より異なるベース機種の検証を優先しましょう。

人気機種からOSを絞って選定する

より多くのユーザが実際に使っている端末を優先して検証を行うことで、サポートカバー率を上げることができます。結果的に不具合発生率が少ないアプリケーションを開発することができ、ユーザメリットにも繋がるでしょう。