キャリア比較

開発難易度について

ここでは、各キャリア毎の携帯電話アプリを作る場合の開発難易度に関して比較説明します。

はじめに

開発の難易度は人によってさまざまで、同じ事でも難しいと感じる人もいれば、簡単と感じる人もいます。
携帯電話アプリは、基本的に同じ携帯電話である以上、キャリアが違っても基本的にできることはほぼ変わりません。
ですので、ここでは、感じ方による違いをできるだけ排して、同じ事をするのにどれだけのステップ数を踏む必要があるかなどの、
作業の煩雑さや、かかる時間、かかる金銭などを開発難易度とし、それらをキャリア別に比較します。

全キャリア共通の開発環境

各キャリアのアプリ開発のプラットフォームは採用されている技術によりそれぞれ違いますが、各キャリア共にアプリ開発は基本的に、全てWindows2000以降のWindowsパソコンの上で行います。
携帯電話上で動くソフトを作ることが目的ですので、基本的には各キャリアの開発環境共に、必要となるツール群は似た構成になります。
携帯電話アプリの開発で必要なツール郡は基本的には以下のものになります。

1. コンパイラ
2. アーカイバ
3. エミュレータ

※ソースコードを書く為のエディタなどのツールは省いています。

この他にも、キャリアごとで固有のツールなどが必要になって行きます。

全キャリア共通の開発の流れ

携帯電話アプリの開発は、全キャリアで基本的な流れは同じです。
基本的には以下の流れで行います。

1. ソースコード編集
2. ＰＣ上でコンパイル・アーカイブ
3. ＰＣ上でエミュレータによる動作確認（問題があれば１へ戻る）
4. 実機上での動作確認（問題があれば１へ戻る）
5. 完成

実質的には、ほとんどの作業はパソコン上で行いますが、エミュレータ自体が実機の動作を完全に再現してくれないので、配布する目的で作るならば実機での動作確認は必須となります。
実機での動作確認は、ターゲットとする端末のみをやるのが普通で、全機種で行うことはほとんどありません（ターゲットとなる端末が多い場合は動作確認を行う機種数も増えるので、実質的に全機種になる場合もあります）。

各キャリアの開発環境に関して

Docomo開発環境に関して

ＳＤＫに関して 右の画像はdoja SDKのイメージ画像です。 Docomoの開発環境はJ2SE SDKを入れますが、実際にはJ2SE SDKを直接いじる事はありません。 基本的には、doja SDKが内部的にJ2SE SDKを使用し、コンパイル/アーカイブ/エミュレータ実行は 全てdoja SDK上で行えます。 doja SDKはSDKというよりもiアプリ作成専用のソフトと考えた方が近いでしょう。 doja SDKにはバージョンがあり、2008年４月現在は1.0〜5.0までリリースされています。 バージョンごとで対応する機種のシリーズが変わります。 例えば504/505シリーズ対応は3.0や、Fomaは3.5以上からなど、ターゲットとなる機種毎に 対応バージョンがあり、バージョンごとでアプリに対する制限もかわります。

必要な知識・資料に関して Docomoのiアプリを開発するのに必要な知識は、基本的にはjavaの知識が必要になります。 これは、市販の書籍などで独自に勉強してもらう必要があります。 技術的な資料に関しては、javaのAPIの資料が必要になりますが、これはJ2SE SDKに付属しているドキュメントにありますので、それで 賄う事ができます。 iアプリではJ2SEのAPIを全て使用する事は出来ませんが、どのＡＰＩが使用できるかの情報はdoja SDKの技術資料にあります。 Docomo独自の拡張ＡＰＩに関しては、doja SDKのＡＰＩマニュアルがありますので、そちらで賄う事が可能です。 Docomoの開発環境では、言語の基本的な知識がわかっていれば、インストールしたSDKおよびSDKを配布しているサイトに一緒に おいてあるドキュメントで必要な知識を全て賄う事が可能です。 また、一般書籍として、開発ガイド本のような解説書が存在しますので、そちらを利用するという手もあります。 アプリ開発・配布に関して Docomoでは、携帯電話内の個人情報にかかわる部分の機能を使用しない限りは、iアプリの配布は自由に認めています。 この個人情報にかかわる部分というのは、アプリでは「トラステッド」として規定されており、この「トラステッド」機能を使用するアプリ （メーラーなど）は「トラステッドiアプリ」とよばれ、この「トラステッドiアプリ」の配布に関しては、Docomoの公式サイト以外からの配布を 認めていません。 Docomoのiアプリの仕様は基本的には全て公開されており、またアプリ開発も自由にでき、かつ配布も自由にできる為、多くの人がアプリ を開発・配布しています。 ですので、このサイトのように、解説サイトが多く存在し、インターネット上でも多くの情報を検索できます。

SoftBank開発環境に関して

SDKに関して SoftBankの開発環境は非常に複雑です。 SoftBankの開発環境ではJ2SE SDKをインストールする必要がありますが、実際のところはJ2SE SDKのツール（コンパイラ・アーカイバ）が 必要なだけで、それ以外のものは事実上必要ありません。 実際に使用するAPI郡はJ2ME Wirless ToolKitの方（もしくはターゲット毎のＳＤＫ）にあるものを使用します。 J2ME Wirless ToolKitは基本的にJ2SE SDKインストール下の環境で動作し、エミュレータなども付属しますが、このエミュレータは基本的には 海外向けの端末（？）を想定して作られているので、S!アプリのエミュレータとしては用を成しません。 J2ME Wirless ToolKitはS!アプリにおいては、基本ＡＰＩを提供するだけの物と考えてください。 S!アプリは基本的にJ2ME Wirless ToolKit（MIDP）のルールにのっとって動作するアプリです。 ですので、本来ならばJ2ME Wirless ToolKit上でコンパイル・アーカイブをする必要があります。 J2ME Wirless ToolKitにはdoja同様にウィンドウ上でコンパイル・アーカイブする機能もあるのですが、J2ME Wirless ToolKitには、SoftBankの 提供するS!アプリ専用のAPIを外部より追加する機能がありません。 よしんば、追加する機能があったとしても、S!アプリ独自の設定項目を編集する機能もありません。 ですので、S!アプリのコンパイル・アーカイブはアプリの作成者がJ2SE SDKのツールを使用し、自分でコンソール（Dos窓）上で行う必要があります。
S!アプリではJ2SE SDKのコンパイラ・アーカイバを使用するため、SoftBankが配布するＳＤＫには コンパイル・アーカイブをする機能がありません。 基本的には、エミュレータとS!アプリ用の拡張APIのパッケージのみが配布されます。 右の画像はS!アプリ用のエミュレータのイメージ画像です。 ご覧の通り、2種類あります。 実際には、バージョン毎にもっと細かくありますが、大きく分けると2種類存在します。 上のJSCLエミュレータと言うのは、メガアプリ前エミュレータでMEXAエミュレータと言うのは３Ｇ端末以降 のメガアプリのエミュレータです。 MEXAエミュレータはある程度はJSCLエミュレータと下位交換が取れていますが、完全に下位交換がある 訳ではありません。 この理由に関しては、下記の「S!アプリの下位交換性に関して」で説明します。 何はともあれ、S!アプリでは、エミュレータはエミュレータのみで配布されており、ＳＤＫとは一切の連携は ありません。 ＳＤＫ自体もそれぞれが個別で連携はなく、アプリ制作者が独自で連携をするしかありません。 S!アプリの開発環境は、基本的には制作者が全て管理することになります。 エミュレータ自体は、全て同じパソコン上に入れることが可能ですが、J2SE SDKやJ2ME Wirless ToolKit のバージョンによっては動かなかったりもしますので、それらの管理も込みで、すべて制作者が管理する 必要があります。	JSCLエミュレータ MEXAエミュレータ
S!アプリの下位交換性に関して S!アプリは基本的には３Ｇ端末以前と以後では交換性はかなり薄いです。 まったく無い訳ではありませんが、３Ｇ以前のアプリを３Ｇ端末で動作させる場合には、まったく同じイメージでは動作できません。 これは、SoftBank携帯の端末特有のものです。 SoftBank携帯はJ2ME Wirless ToolKit（MIDP）を使用している関係上、アプリの動作構造自体が国際規格に適合するように作られています。 J2ME Wirless ToolKit(MIDP)自体は携帯電話用ではなく、ＰＤＡなどのモバイル端末を動かす為に作られたものですので、SoftBank携帯の端末は 携帯電話というよりもＰＤＡなどのモバイル端末に構造が似ています。 J2ME Wirless ToolKitは現在はMIDP1.0とMIDP2.0のバージョンがあり、最低限のＡＰＩはMIDPに用意されているので、これのみでアプリを作ることも 可能です。 当然ですが、そのアプリはSoftBankの端末で動かすことも可能です。 ３Ｇ以前のSoftBankの端末（ボーダフォン時代）ではMIDP1.0に拡張ＡＰＩ（JSCL）を追加し、拡張ＡＰＩで描画機能の強化やカメラなどの制御、電話機 特有の機能の制御などを担わせていました。 ところが、３Ｇ端末への切り替えの際に、このMIDPが2.0へとバージョンアップされました。 MIDP2.0では1.0よりもいろいろな機能が強化され、JSCLと同等の機能を提供するようになりました。 その際に、JSCLはMEXAと名前を変え、更に拡張されました。 その後、MEXAはMEXA Unit1とMEXA Unit2に分かれ、Unit2はMIDP2.0とかぶる機能が多く入りました。 このUnit2のサポートは各メーカーの端末ごとに委ねられ、そして切り捨てられていきました。 これにより、かつてJSCLで対応していたAPIが３ＧＣでは対応しなくなっていった為、下位交換性が薄れていきました。 必要な知識・資料に関して S!アプリは上記でもずっと述べてきたように、かなり複雑です。 S!アプリの作成の際に必要とされる知識は、基本的には ・java言語の基礎知識 ・MIDP対応アプリ作成の為の知識 の2つが必要です。 java言語の基礎知識に関しては、多くの書籍が出版されていますので、そちらで賄うことが可能です。 MIDPに関しては書籍も少なく、SDKに同梱されているドキュメントも英語であり、かつ、具体的なターゲット機種がＰＤＡだったりするので、読めたと しても、非常に解りにくいものになっています。 MIDPに関しては、率直なところとしては、実験を繰り返して身につけていくしかないと思います。 技術的な資料に関しては、拡張APIに関してはマニュアルが存在しますが、MIDPをきちんと理解していることを前提としている為、かなり解り難く なっています。 MIDPに関しては、基礎知識同様で、全て英語なので、がんばって読むしかありません。 書籍等は、多少あるみたいですが、書店等では見かけたことがないので、ほぼ無いと思ってもらってかまわないと思います。 基本的には、全ての資料は公開されていますが、難解な上に色々と分かれているので、非常に解り難くなっています。 アプリ開発・配布に関して SoftBankではS!アプリの自由な配布は認めていません。 基本的には「コンテンツアグリゲータ」と呼ばれる、アプリ配布用の決められたサーバー（プロダイバー？）があり、そこを通さないと配布できない 仕組みになっています。 商用の配布をする場合は、自ら公式ＣＰ（コンテンツアグリゲータ）になるか、コンテンツアグリゲータのサーバーを管理する会社と契約し、商用配布 を委託するかのどちらかになります。 個人の場合は、フリー/シェアどちらのアプリであってもコンテンツアグリゲータに委託することになります。 個人の場合にこのコンテンツアグリゲータと契約するには、基本的には無料でできるようです。 開発自体は、基本的には全てが公開されているので、自由に行うことが可能です。 ただし、Docomoのように個人情報にかかわる部分などに使用制限等がない為、配布する為にはコンテンツアグリゲータに自らの身分を証明する 必要があるようです。

AU by KDDI開発環境に関して

ＡＵ携帯端末向けBREWアプリの開発における制限に関して AU携帯端末向けアプリは基本的に2種類存在します。 ひとつはjavaによるアプリで、これはEZアプリ@javaなどと呼ばれます。 もうひとつはここで紹介しているEZアプリ@BREWです。 両者の違いは、技術的な部分では多くありますが、根本的な違いとしては、EZアプリ@javaは自由な配布を認め、仕様も公開されているのに対し、 EZアプリ@BREWは商用配布以外を認めていない点です。 ですので、EZアプリ@BREWのアプリを開発する場合は、基本的にはKDDIとの契約が必要になります。 以下ではKDDIと契約している企業のことを「CP」と称し、CPであることを前提に説明していきます。 SDKの準備に関して KDDIの開発環境（以下BREW開発環境）は、インストールだけならば比較的簡単です。 BREW開発環境では、SDKをインストールする前に開発ソフトとして、MicroSoft Visual C++ Vre6.0以降が必要になります。 C/C++を知っている人ならば、MicroSoft Visual C++自体はよくご存知だとは思いますが、Windowsソフトを作成する為の開発ソフトの代名詞の ような存在です。 このソフト自体はパッケージソフトであるので、パソコンショップなどで売られているものです。 MicroSoft Visual C++をインストールしたならば、クアルコムのホームページからBREW ＳＤＫをオンラインインストールすれば、ＳＤＫのインストール は完了です。 BREW SDKをインストールする際に、個人情報を登録する必要があるので、そこは注意が必要ですが、BREW SDK自体は基本的には無料で インストールすることができます。 BREW SDKはBREWのバージョン(2.0/2.1/3.1)毎に分かれており、基本的には1つの環境（1台のパソコン）に1つしか入れられません。 これは環境変数を書き換える為ですので、環境変数に関して十分な知識がある方であれば、1つの環境に複数インストールすることも可能です。 現在では、BREW2.0は古すぎてほぼ使用しないに等しい状態ですので、基本的には2.1か3.1のどちらかをインストールします。 BREW2.1はＳＤＫをインストールすると、ツール郡も一緒にインストールされますが、BREW3.1はSDKとツール郡が分かれているので、ツール郡は 別途でインストールする必要があります。 BREW3.1のツール郡も無料でインストールすることが可能です。 その後、KDDIよりCPに配布されている、SDKをこのBREW SDKにインストールします。 これで、パソコン上でエミュレータでアプリを動作させるまでの環境が整います。 この後、実機用にコンパイルする為のARM BREWコンパイラをインストールします。 こちらはARMより購入可能なオンライン販売のパッケージソフトで、有料（＄1500）です。 エミュレータまでの動作であれば、このARM BREWコンパイラは必要ありません。 BREW SDKには以下のような物が入っています。 BREWドキュメント郡 BREWユーティリティ BREW Compressed Image作成ツール BREW MIFエディタ BREWエミュレータ BREWデバイスコンフィギュレータ BREWリソースエディタ このうち、AU携帯向けアプリの作成で主に使用するのは、「BREW MIFエディタ」「BREWエミュレータ」「BREWリソースエディタ」の3つです。 このほかに、MicroSoft Visual C++に、BREWアプリ作成用のアドオンがインストールされます。 BREWアプリ開発の基礎 BREWアプリでは、基本的にはソースコードは一緒ですが、エミュレータ用のイメージと実機用のイメージは別々にコンパイルします。 BREWアプリは基本的にC/C++である為、プログラムイメージ（EXE）は機械語になっています。 ですので、Windowsパソコンと携帯電話機ではCPU自体が違う為、別々にコンパイルする必要があります。 基本的なアプリイメージのファイル構造自体は他のキャリアと似ていますが、内部的なデータ構造に関しては、むしろWindowに近い構造になっています。 BREWアプリのエミュレータ用のイメージはWindowsのDLLとして作成され、BREWエミュレータにより呼び出される仕組みになっています。 この部分が、他のキャリアと大きく違います。 BREWアプリでは他のキャリアのアプリのように、プログラムとデータを一つにアーカイブすることはありません。 その代わり、BREWリソースエディタを使用し、データのみをアーカイブし、プログラムとは別ファイルとしてまとめます。 また、BREW携帯端末にアプリを認識させる為にmifと言うファイルを用意する必要があり、これをBREW MIFエディタで作成します。 BREWアプリの最低限のファイル構成は以下のようになります。 ・アプリを認識させる為のmifファイル ・プログラム自体のファイル(エミュレータ用DLLもしくは実機用mod) ・リソースファイル（必要ない場合もある） それぞれで作成されたプログラム/データをエミュレータの決められた位置にコピーすると、エミュレータ上でアプリが認識され、実行できるように なります。 このように、エミュレータはエミュレータとしてしか動作しないということに関しては、BREWアプリの開発は、手順はだいぶ違いますが、Docomoよりも SoftBankに近い形になります。
ＳＤＫに関して BREWアプリの開発では、基本的にMicroSoft Visual C++が中心で作業されます。 MicroSoft Visual C++上でエミュレータ用のコンパイル・ARM BREWコンパイラ用のmakeファイルの作成 が行われ、ARM BREWコンパイラによるコンパイル時にもMicroSoft Visual C++付属のNMAKEを使用して コンパイルが行われます。 右の画像はBREW SDKのエミュレータ/MIFエディタ/リソースエディタのそれぞれのイメージ画像です。 見てお分かりの通り、それぞれが独立したWindowsアプリになっています。 BREWアプリの作成ではMicroSoft Visual C++でプログラムイメージを作成し、MIFエディタと リソースエディタでデータを作成し、プログラムイメージとデータをエミュレータに読み込ませるという手順に なります。 手順自体はSoftBankのS!アプリと似ていますが、SoftBankの方はコンソール(Dos窓)上で作業するのに 対し、BREWアプリではそれがGUI上での作業になります。 BREW SDKでは各ツールは独立したアプリである為、当然ですがDocomoのdojaのように、アプリ間での 連携はないので、それぞれのツールで出来上がったデータは作成者自身が管理する必要があります。 BREW SDKのエミュレータは、DocomoやSoftBankのものと違い、デバイス構成情報と言うものが 用意されており、これをエミュレータに読み込ませることによって、エミュレータが実機により近い動きを するように作られています。 このデバイス構成情報と言うのは、KDDIがCP向けにのみ配布しているものです。 このデバイス構成情報のターゲットとなる機種の物をエミュレータに読み込ませ、その上でBREWアプリを 実行させ、動作確認を行います。 実機用のイメージを作成する場合は、上記のほかにARM BREWコンパイラによる実機用のコンパイルの 作業が必要になります。 これは、上記でも述べているように、MicroSoft Visual C++上でmakeファイルを作成してくれるので、その makeファイルを使用して、コンソール(Dos窓)上でコンパイルを行います。 ここでエラーが起こらなければ、拡張子が「mod」という実機用の実行体イメージが出来上がりますので、 エミュレータに読み込ませた構成の「DLL」のファイルとこの「mod」のファイルを置き換えて、実機に 読ませる事になります。	エミュレータ MIFエディタ リソースエディタ
BREWアプリの実機テストに関して BREWアプリの開発において、実機でのテストは、他のキャリアとは根本的にやり方が異なります。 Docomoにしろ、SoftBankにしろ、アップロードするサーバーに制限が有るか無いかの違いを除けば、市販の端末を使用し、サイト上からダウンロードして 実機にイメージを送り込むことに違いは有りません。 BREWアプリでは、市販の端末は使用できません。 BREWアプリのテストに使用できる端末は、KDDIがCP向けにテスト用端末として設定変更した端末のみです。 このテスト用端末に専用ケーブルを接続し、専用ソフトを使用してテストアプリを送り込みます。 この際に、アプリを実機に認識させる為に、KDDIからCP向けに配布された特殊なファイルを一緒に入れる必要があります。 ですので、仮にテスト用の端末と専用ケーブル、専用ソフトを手に入れたとしても、CP以外で実機テストを行うことはできないことになります。 他キャリアのように通信を使用して、市販の端末にダウンロードをさせることも可能ですが、AU端末ではAUのネット網を使用しないとアプリがダウンロード できない仕組みになっており、これを行えるのはCPに限られている為、結局のところは開発段階ではこの方法は使用できないのと同じことになります。
必要な知識・資料に関して BREWアプリを作成する上で必要になる知識は、以下のような物があります。 ・C/C++の基礎知識 ・MicroSoft Visual C++の基本的操作に関する知識 ・NMAKEなどのmakeファイルの知識 基本的には、C/C++を使用するので、それに関する知識が必要と言うことになります。 C/C++の知識に関しては、市販の書籍が大変多く出回っているので、それで賄うことが十二分に可能ですが、C/C++は一般的にjavaよりも難しい言語 と言われています。 ですので、javaよりは知識的には難しくなります。 MicroSoft Visual C++の基本的操作に関しては、これも市販の書籍が数多く出回っていますので、そちらで賄うことも可能だとは思いますが、BREWアプリ の作成で使用される部分は、書籍等では書かれないような部分が多いです。 これに関しては、さわってみて、経験をつんでいく以外に、有効な方法は無いかもしれません。 NMAKEなどのmakeファイルに関する知識は、基本的には書籍等はあまりありません。 makeファイルはLinuxなどの世界では普通に使われている物ですので、インターネットなどで調べた方が、解りやすいかもしれません。 ただし、makeファイルは基本的にC/C++の基本的知識がないと判らないことだらけになりますので、気をつけてください。 技術的な資料に関しては、３キャリアの中ではAU端末が一番苦労します。 AU端末のBREW関連の資料は、基本的には2系統に分かれます。 ひとつはクアルコムが提供するBREWに関する資料です。 このクアルコムが提供する資料は、AU端末を前提としていないので、AU端末での開発目的で読むと、非常に解りにくいものになっています。 さらに、APIは基本的にKDDIが提供する拡張APIを使用することになるので、技術的な資料としては、クアルコムの提供する資料は、ほとんど用を 成しません。 基本的には、クアルコムの資料はBREW SDKの仕組みと使用方法を調べる為のものになります。 もうひとつはKDDIがCP向けに提供するAU端末用のBREW技術資料になります。 こちらの資料は、基本的な作成方法から細かく説明されていますが、基本的にBREWが理解できている上での説明になるので、解りにくいものに なっています。 さらに、量が非常の多く、さらに目的毎に資料が分けられており、必要な情報を探すのに非常に苦労します。 基本的には、一通り目を通さないと、分からないことが多いので、読むだけでも大変な労力を要します。 ただし、一通り読んでしまえば、この2系統の資料でほとんどの用は足りてしまうので、他の書籍等に頼ることはほとんど無いでしょう。 基本的に情報公開がされていない物ですので、書籍等もほとんど無く、この2系統の資料がほぼ全ての技術資料といっても過言ではありません。 当然ですが、公開されていない物ですので、インターネットなどで調べても、ほとんど情報は出てきません。 アプリの開発・配布に関して KDDIではEZアプリ@BREWの配布は基本的にはCPにしか認めていません。 開発自体もCP向けに配布されているSDKや資料・データなどを必要としているので、一般からは開発することはできません。 BREWアプリの開発・配布を行いたい場合は、KDDIとのCP契約が必要になります。

開発難易度比較

ここまで、開発環境に関して、キャリアごとで解説してきました。
以下では、これまでの解説を元に、3キャリアでの開発難易度に関して比較をしたいと思います。

開発難易度比較表

	Docomo	SoftBank	AU by KDDI
開発環境の導入	比較的簡単	比較的簡単	CPでないと出来ない
開発言語	一般的に簡単	一般的に簡単	一般的に難しい
知識獲得の労力	比較的簡単	やや大変	かなり大変
開発環境にかかる金額	ほぼ無料	ほぼ無料	ツール類は有料
機種依存	それほど多くない	多い	それほど多くない
実機テスト	楽	面倒	かなり面倒
インターネットでの情報	多い	比較的多い	かなり少ない

上記の表は、3キャリアの開発時の難易度を示しています。
ご覧の通り、Docomoは比較的簡単に開発ができるキャリアであることがわかると思います。
なんといっても、実機テストが楽なのが大きいです。
実機テストが楽だと、かなり実機テストを頻繁にできるので、開発自体の速度が速くなります。
また、機種依存も少ない（Foma以前はかなり多かったですが）ので、エミュレータでの動作が素直に実機で動いてくれるのも、開発を助ける
大きな要因です。

SoftBankは、導入から開発開始までは、Docomoと同等程度の労力で出来ますが、開発中盤以降からDocomoよりもはるかに労力が大きく
なって行きます。
実機自体に機種依存も多く、エミュレータ上では動作しても実機では起動すら出来ない場合も多く、更には資料等も少なく、原因を探すのに
大きな手間がかかってきます。
実機テストもコンテンツアグリゲータ経由でないとダウンロードが出来ず、その当たりでもひと手間がかかってきます。
プログラミングよりも資料との格闘の方で労力が取られるキャリアです。
ですが、AU by KDDIよりは開発自体は楽です。

AU by KDDIは最も開発の難しいキャリアです。
導入時点からハードルが高く、読む資料の量も多く開発し始めるまでに時間がかかります。
また、色々とお金もかかるので、懐には厳しいキャリアでもあります。
ほとんどの面で、他の2キャリアよりも難しい面が多いです。
が、唯一といっても過言ではありませんが、1つだけ、他の2キャリアよりも勝っている点があります。
それは、エミュレータ上できちんと動作すれば実機でもきちんと動作するという点です。
これは機種依存がまったく無いというわけではありません。
機種依存情報はＣＰ向けに公開されており、その機種依存を避けてきちんとプログラミングされていれば、実機上で不具合を起こす場合の
ほとんどがプログラムのバグであって、機種依存で不具合を起こすことはほとんど無いということです。
ただし、ここにも罠があり、BREWはC/C++での開発となるため、javaのようにメモリ関連がしっかりと管理されているわけではないので、
その辺りでかなり多くのバグが発生します。
特にメモリリークのバグはBREWの特性上、機種によっては現象が起こったり起こらなかったりするので、発見・解決に大きな労力が必要に
なってきます。

各キャリア共に、有利な点・不利な点があり、それをどれだけ重要視するかによって、開発難易度は人それぞれで変わってきますが、
3キャリア共に開発を経験したfurufuruの見解としては、

・Docomoが一番楽
・SoftBankははじめは良いが後が大変
・AU by KDDIは全て大変

と言う結論に達しました。

これから始める方も、既に始めていて対応キャリアを増やす方も、目安としてくれればうれしいです。