ITごはん

ITを活用したい人、ITで何か作りたい人、そんなITでごはんを食べる人のためのブログ

【システム開発】発注者のためのテスト種類

はじめに

システム開発では、 プログラミング(コーディング)を行い、 それが想定している動作(=仕様、仕様書)と同じか、 確認するために、テストを行います。

システム開発会社は、各種テストについてよく知っていますが、 ユーザーサイドでは見慣れない人も多いので、 困惑してしまうことがありますので、 今回はそのテストの種類について説明します。

なお、ウォーターフォール型開発をベースにした場合の呼称や、 違い(切り分け)を説明していきます。

単体テスト

UT(Unit Test)と呼ばれることも多いです。 主にプログラム1つについて、動作検証するものを言います。 また、プログラム1つではなく、 モジュールというプログラムの小さなかたまり(機能)に 対するテストを指すことも多いです。

一般にシステム開発会社が担当します。

結合テスト

IT(Integration Test)と呼ばれることもあります。 単体テストの後で実施され、主にプログラムやモジュールを、 複数を接続して行うテストを言います。

一般にシステム開発会社が担当します。

システムテスト・総合テスト

ST(System Test)と略することもあります。 結合テストで検証されたプログラム・モジュール群を すべて接続し、本番環境に限りなく近い状態にした上で、 システム全体が要件を満たしているかの確認を行います。

一般にシステム開発会社が担当し、 開発側の最終確認の位置づけで行われます。

ユーザー受入テスト・運用テスト

UAT(User Acceptance Test)と略されることもあります。 システム開発会社がシステムテストを終えたシステムを、 発注サイド(ユーザー)で、システム全体が要件を満たしているかの確認を行います。

ユーザーが、業務を当該のシステムで、 運用できるかのテストを行います。

また、実際に検証を目的に、そのシステムを実際の業務に 使用してみることもあります。

これを終えると本番移行・本番リリースとなります。

さいごに

アジャイル開発や、小規模なスマホアプリ開発などでは、 単にテストと呼ぶことも多いです。 (ただし、ユーザー受入テストは、開発サイドのテストと区別することが多いです)

また、これらのテストはシステム開発会社において、 その会社のシステム開発標準(と呼ぶ方法論)や、 方言みたいな部分によって、微妙に名称が異なる場合があるので、

馴染みないなと感じたら、素直に 「どういう位置づけのテストですか」 と、システム開発会社に聞いたほうがよいでしょう。

後からになると、聞きにくくなったりしますよね。

基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために

基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために

【書評】「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

はじめに

我が国が技術立国であることには、言を俟たないですが、 ことITについてはどうでしょうか。

製造業では新興国に押されているとはいえ、 部品・素材やインフラ系など変わらず重要な地位を占めていると言えるでしょう。

しかし、ITについては、国際比較の中では、 産業規模こそ大きいものの、 米国や中国のように、世界的影響力をもつビッグプレイヤーが出てきていないと言えます。

また、米国を見てみると、 Googleのエンジニアは1,400万円の年収を得られ、 ITエンジニアは高年収ランキングの10位以内に入っています。

一方、我が国のITエンジニアは決して恵まれた環境ではなく、 新卒の学生から、憧れる職業ではなくなっていると聞きます。

このような我が国の特殊な状況は 多重請負や、人月問題、etcが根底にあると言われています。

本書の倉貫氏は、こういっった日本のIT業界全体の課題に 果敢に挑んでいる内容が本書に収められています。

「納品がおこしてきた問題」

本書ではIT業界で一般に行われる一括請負契約をベースとした、 納品がある契約を納品のある開発とし、 「納品がおこしてきた問題」として、以下を挙げています。

1 ソフトウェアの「完成リスク」を開発会社が引き受けてくれる
2 リスク引受(バッファ)による高価格化
3 創意工夫を阻む保守的な開発
4 開発会社の価値は保険
5 駄目なエンジニアほど儲かる
6 最大負荷をベースとしたハードウェア購入による高費用化
7 開発と運用が別なことによる、保守性を無視した設計・開発

これらは、業界に知見のある人であれば、 頷くことが出来ると思います。

そして、これらの解決の手段として、 倉貫氏とその会社のソニックガーデン社において、 提案・実行されているのが「納品のない開発」ということになります。

「納品のない開発」では、以下の様な特徴を持ちます。

1 月額定額(納品がない)で「できる範囲」で精一杯の「開発と運用」を行う
2 時間単位の作業の提供ではなく、顧客の成果と満足度をベースにした契約
3 同じ担当者が提案や開発・運用まで責任をもつ顧問ビジネス化
4 毎週のミーティングと非常駐

イメージとしては、自社に開発・運用を面倒みる システム担当者がいるようなものでしょうか。 また、開発手法としては、一般にアジャイル開発として 認識されているものに近いと思いますが、 あくまで中長期的なパートナーシップをベースとしているところに、 大きな特徴があるでしょう。

例えば、「3 同じ担当者が提案や開発・運用まで責任をもつ顧問ビジネス化」 一つをとっても、経験的に共感できるところがあります。

いわゆるシステムは開発の期間より、 実際に使用する運用の期間の方が圧倒的に長いです。 これは、開発期間の20倍を超えることも珍しくありません。

しかし、多くの場合、開発時の効率ばかりを考え、 運用期間におけるメンテナンスを考慮した設計・コーディングが 行われることが少ないです。

これは、開発会社が、運用を行う想定がない場合などは、 顕著にこの問題が起こる可能性があります。 (この場合の開発会社は、運用を考慮するインセンティブがありません)

中長期な視点のあるプログラムというのと、 開発の急場しのぎのプログラムというのは、 外側から見ると同じように見えますが、全く異なります。 それは、いざメンテナンスする際などに、 バグが多い、変更の自由が効かない、または修正コストが大きい といった形で返って来ます。

顧客にとっての「納品のない開発」

また、「納品のない開発」の顧客にとってのメリットは、 以下のように記載されています。

1 要件を1度に決めなくて良い、いくらでも仕様変更ができる
2 気軽に相談ができる
3 開発費用の低コスト化(請負にくらべ比較的安いそうです)

一般のシステム開発では、要件定義や外部設計等のフェイズを通して、 仕様を決めていくことが行われますが、 これは進捗するに従って、要件が変更ができなくなることを意味します。

ビジネス環境の変化が激しい現代において、このようなスタイルがマッチしないケースが 出てきていますが、「納品のない開発」では、 いくらでも仕様変更できる、というメリットは大きいでしょう。

「納品のない開発」は広がるか

こう見ていくと、「納品のない開発」は大変魅力的に写ります。 それではなぜ、一般に広がらないのでしょうか。

筆者も「納品のない開発」の限定性(大規模プロジェクトには向かない)を指摘していますが、 1つには、発注側の意識改革が進まないことがあげられるでしょう。

実際問題として、発注者側から見ると、 これまでのシステム開発モデルと比較して、 リスクを開発会社に転嫁できない分、不利のような印象を受けるでしょう。

このことは、顧客側は、ITに関して、一括丸投げモデルから、 一緒に考えるモデルへの変更が迫られることになります。 この意識変革を受け入れることができるか、というのが大きいように思います。

そして、この「納品のない開発」への期待としては、 現状のITエンジニアの環境改善にいくらか貢献するではないかと思います。

さきほど、米国のITエンジニアは高収入であると、 話をしましたが、彼らは日本のエンジニアと比べると、 明らかに業務の範囲が広いです。

彼らはIT技術に精通していることはもちろん、 ビジネスにも精通している人が多いです。

それは、米国のエンジニアの72%がユーザー企業(内製)で、 一緒にビジネスを遂行している結果だと思います。

日本のITエンジニアは、技術を磨いていますが、 ビジネス感覚に乏しいことは幾度となく指摘されています。 その結果として、顧客の「もっと提案して欲しい」という 要望はいたるところで聞けます。

「納品のない開発」の中で、中長期に顧客とともに ビジネスを成功に導くという経験は、非常に重要なように思います。

最後に、「納品のない開発」の主要顧客はスタートアップが多いそうですが、 そういったスタートアップから、成功事例が増えることで、 「納品のない開発」がより広く認知され、 冒頭で挙げたような業界の不幸な状況に風穴を開けてくれることを期待しています。

【システム開発】発注者のための契約書の5つのチェックポイント

はじめに

前回は、契約の種類(契約形態)について説明しましたが、 今回は、契約書を作成する際に、 失敗しないための5つのポイントを紹介します。

後で、 「ああ書いとけば、良かった」 と後悔しないように、 問題になりやすい5つのチェックポイントを 確認していきましょう。

※ ポイントが分り易いように、法律用語は極力省いています。 実務においては、弁護士、法務担当者等と検討の上、作成してください。

①業務範囲

まずは、業務範囲です。

システム開発では、企画、設計、コーディング、テスト、検収といった、 一連の工程(プロセス)をもって、進行することが多いです。

契約書では、この工程の中の、 どの部分についての業務委託となっているのか、 しっかり確認してください。

また、工程によっては、一方ではなく、 両方の協力作業が含まれる場合もありますので、 そちらも記載してください。

著作権

著作権システム開発で問題になりやすいポイントになります。

法律的な原則論として、システムを作成すると、その著作権は、 システム開発会社になります。

しかし、それでは発注者は、 後々、そのシステムに機能追加をしたい、 新しい展開をしたい場合など、 そのシステム開発会社に承諾を得なければいけないような 状態になってしまします。

そうならないためには、システム開発完了とともに、 著作権の譲渡を含む契約にする必要があります。

検収条件

検収とは、システムが開発されて、納入された上での、 発注者側で、正しくシステムが動作するかという確認になります。 ユーザー受け入れテストをもって、検収を行うというケースが多いです。

ここで、問題となるのは、何を持って、OKとするかです。

スマートフォンアプリなどユーザー受け入れテストが終わった後に、 アプリのリリース申請があります。 (iOSは申請から、実際にリリースされるまでに1〜2週間ぐらいかかります) そのため、受け入れテストで、OKとするか、 リリースまで見届けて、OKとするか、 また、申請後にリジェクトがあった場合の対応について、 など事前に決めておくことが望ましいです。

一般に納品から、1週間〜1ヶ月ほどの期間をもって、検収作業をおこないます。 この期間についても、最初の納入日から起算するのか、 納品後の不具合があった場合は、最終納品日から起算するのか、 こういった部分も事前に確認をしておきましょう。

瑕疵担保責任

瑕疵担保責任とは、 システムに問題(欠陥)があった場合に、 システム開発会社が無償で 修正しなければならない責任を言います。

これについて、契約書では検収後xxヶ月まで、 という形で期間を明示します。 もし、この記載がない場合は、1年となります。 (民法上の規定)

ただし、システム開発では6か月ぐらいというのが、 多いようです。

発注者有利という観点でしたら、長ければ長いほど有利ということに、 なります。

⑤損害賠償

システム開発では損害賠償について記載します。

一般的なのは、契約額を上限として、 システム開発会社が損害賠償責任を負うケースです。

発注者有利という観点でしたら、 損害賠償額を無制限とするケースがあります。 ただし、これは発注側がかなり有利な立場に限られると思います。 また、実際問題として、無制限の損害賠償額を支払えるかという、 問題はあります。

さいごに

以上、発注者の目線で、 契約書作成のポイントを記載してまいりました。

ただ、誤解して頂きたくないのは、 とにかく有利な契約にすれば良い、という訳ではないことです

有利な契約で交渉するということは、 当然、受注者側ではその不利な条件を、 飲み込むという不利益を被るために、 金額やその他条件によって、 その穴埋めをしてくるはずです

これは、適正な価格で、システム開発プロジェクトを成功させたいという、 発注者の意図とは反し、本末転倒となってしまいます。

契約上の有利な条件というのと、システム開発費・保守費は トレードオフな関係にあることを理解してください。

そのため、譲れない部分は、譲れない部分として、交渉し、 不必要な部分については、無理に主張すべきではないでしょう。

例えば、弁護士などに依頼して、とにかく有利な条件になるような 契約書のドラフトをもってきて、 結果的に価格が倍近くに跳ね上がったみたいなケースもあります。

あくまで、自社のビジネス環境を考慮の上で、契約書については、 作成すべきでしょう。

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

システム開発の契約形態

はじめに

初めてシステム開発を発注する際に、 最初の難関は契約書ではないでしょうか。

システム開発は、一般に業務委託契約という名前の契約書が 交わされます。

そして、この業務委託契約には大きく2種類あります。 それは、請負契約と委任契約です。

請負契約と委任契約

この2つの契約のもっとも大きな違いは、以下になります。

請負契約
・システムの完成に責任を負う


委任契約

・システムの完成に責任を負わない

どちらもシステム完成に向けて、作業するというところでは違いがありません。 ただし、法律的には、 請負契約が完成について責任を負うことになるのに対し、 委任契約では作業はするものの、システムの完成に責任は負いません。 万が一、完成しなかったとしても、責任を追求することはできません。

どちらがお得か

では、 乱暴に言ってしまえば、発注者にとっては、請負契約が、 受注者にとっては委任契約がお得だと言えます。

請負契約であれば、システム開発会社は何が何でも、完成させなければ 1円も受け取れません。(もちろん、契約内容によります)

ただし、「何が何でも完成させる」という命題がありますから、 例えば、ユーザーのちょっとした機能追加などの要望についても、 受け入れることが難しくなったりします。

これでは、より良いシステムを求めるユーザーにとって、 本末転倒な状況といえるでしょう。

さて、委任契約はどうでしょう。 委任契約ではシステム開発会社は、精一杯作業することが、 第一の目的ですから、機能追加などにも柔軟に対応できます。

ただし、その場合は作業量が増える=支払額が増える、となります。 また、本当に一生懸命やっているか、といった管理も必要になるかもしれません。

実際には、要件定義や基本設計といった、 スケジュールが見えにくい工程(プロセス)では、委任契約。

詳細設計やプログラミング、テストといった、 あるていどスケジュールを立てて進められるような工程では、 請負契約というのが、多いように思います。

最近の状況

最近ではアジャイル開発という、開発手法が各地で行われております。 これは、これまでのウォーターフォールという、 事前にしっかりと計画をたてて、企画→要件定義→設計→プログラミング→テストという、 手順を踏むのではなく、

企画→要件定義→設計→プログラミング→テストを、1〜3か月という短いスパンで、 繰り返すような開発の手法です。 この方法により、発注者とシステム開発会社の認識相違を少なくし、 柔軟に企画や、機能追加を行うことが可能となります。

このようなアジャイル開発では、多くの場合、委任契約のほうがマッチします。

システム開発の法律論

基本的には、契約・法律はトラブルが起こったときに、問題になります。

もちろん、「契約違反だー」と怒号が飛ぶような状況は、 発注者も、システム開発会社も避けなければなりません。

発注者も、システム開発会社もシステム開発という共通のゴールがあるわけですから、 それに向けて協力関係を築くのが第一です。

ただし、認識の相違や止むに止まれぬ事情によって、 契約の話になることもしばしばです。 もし、その際に、双方が建設的に問題を処理できるようにという観点で、 契約書を作成することが大切です。

ユーザを成功に導くシステム開発契約―クラウドを見据えて

ユーザを成功に導くシステム開発契約―クラウドを見据えて

システム開発費はなぜ高いか

はじめに

システム開発を行ったことがある経営者・担当者であれば、 システム開発費は高いという印象を持つる方が多いのではないでしょうか。

それではなぜ、IT投資に踏み切ったのかと言われれば、 「高くて仕方ないけど、必要だから投資した」というのが本音だと思います。

また、システム導入にあたって、複数の会社に相見積もりしたけど、 「全然、金額が違う。どうやって、見積もりしてるの?」 なんてことも聞いたりします。

このようなことから、システム開発費は不透明で、高いというイメージを持たれているようです。 今回はそんなシステム開発費を説明してみようと思います。

なお、本稿で説明するのは、外部のシステム開発会社(ソフトハウスSIer)の、 システム開発を業務委託した場合の、システム開発費になります。

システム開発費の構成

システム開発費は、以下のような費用で構成されています。

- エンジニアの人件費
- 営業マンの人件費や販売・促進に係る費用
- サーバーなどのインフラ購入費
- 開発場所の家賃や開発用PCの費用
- 利益
- バッファ

一番下のバッファ以外については、おおむね理解頂けると思います。

システム開発では、原材料と成るものがなく、 そのほとんどはエンジニアの技術によって、システムは構築されます。 そのため、主な費用はエンジニアや営業マン、デザイナーなどの人件費などになります。

では、最後の「バッファ」とは、何でしょうか。 これは英語ではBufferとなりますが、緩衝材といった意味になります。

何の緩衝材かというと、 システム開発の最中に出てきた問題(リスクの顕在化)への 対応で掛かる費用となります。(主に人件費)

システムは、作り終えるまでは、完成物のイメージがつきにくいという、 厄介な性質があります。 そのため、開発の途中で、当初は予定していなかった、 発注者からの要望や、技術上の課題などで作業量が増えたりすることがあります。

これを見込んでおいて、最初に予備的な費用をとっておくものがバッファとなります。 ただ、このバッファの取り方というのは、 企業によって、また案件の難易度や、得意分野などによって、変わってくるので、 どれくらいということができません。 ですが、提示額のおおよそ10%〜30%ぐらいはバッファを見込んでいると考えられます。 ちなみにバッファを使わなかったら、そのまま利益となります。

「人月」という習慣

では、構成はわかりましたが、どうやって見積額をだしているのでしょうか?

システム開発会社が、見積を行う際に使う単位に「人月」というものがあります。 1人月とは、これは標準的な技術のエンジニアが、 一ヶ月かかってやる作業量ということを意味しています。

開発するシステムに必要な作業量を、例えば20人月などと表現します。 20人月のシステムを、2人で10か月やれば、20人月ですから、 このような計算でスケジュールなども考えていきます。

そして、このエンジニアの1人月あたりで100万などの「単価」があり、 それを掛け合わせることで 「20人月×100万 = 2,000万円」 といった計算になります。

単価は会社によって、みんな100万という固定の場合もありますし、 エンジニアのランクによって、幅をもたせるところも多数あります。 (上級エンジニア・コンサルほど高い)

また、このような「人月」という作業量を基準にしたビジネスですから、 このようなビジネスのかたちを「人月ビジネス」と読んだりします。

システム開発費の相場

1人月のシステム開発費の相場(単価)は、どれくらいでしょうか。 具体的には以下の様な感じです。

- 大手SIer・ITコンサル 100〜150万以上
- 中堅SIer 80〜100万
- 中小企業、フリーランサー 60〜80万

上記を見ると、同じシステム開発会社といっても、だいぶ幅がありますね。

そして、この大手SIerと中小企業の金額の差は何でしょうか?

もちろん、技術力が一つには揚げられます。 大手企業ですと、優秀な技術者が集まりますし、社内研修等も充実しており、 技術をより一層磨ける環境にあります。 また、大企業ですと多くの営業マンもいますから、彼らの営業費用ももちろん含まれてきます。

そして、システム開発は技術力だけでなく、業界・業務知識や コミュニケーション力など多数のスキルが求められます。 大企業ですと、そういったスキルを保持したエンジニアがいる可能性が高いです。

そして、なによりはリスクに対する許容量です。 例えば、小さい会社で担当してくれたエンジニアが、 どうもイマイチ、技術力や提案力で力を発揮してくれないケースがあったとします。

これが、いくらクレームをだしても小さい企業ですと、対応が難しいことがあります。

その一方ですと、大企業ではエンジニアの大きなプールがあります。 もし、担当者がイマイチでも、抱えている問題を解決してくれる技術者が そのプールにはいる可能性があります。

また、何らかの問題が顕在化した時、その対応に必要な財務力も有しています。 これが小さい会社ですと、対応したくとも、その財務的基盤から難しい場合もあります。

ただし、これはあくまで一般論です。

実際には、大企業に任せれば安心というわけでもなく、 小さい会社であると、失敗するというわけではないです。

小さいけど非常に優秀なエンジニアの集団の会社も多数ありますし、 小さい会社ほど柔軟に要望に答えてくれたり、対応スピードも早いことも多いです。

また、大企業に発注した場合も、実際はその発注先の企業のエンジニアが、 実際の開発には携わらずに、管理だけというようなケースは多数ありますのでご注意下さい。 (業務の再委託をしている)

やはり、高いと思ったら

上記の説明で、少しは不透明で、高い、システム開発費について、 納得いただけたかと思います。

もし、それでも高いとおもったら、見積もりをもってきた営業マン・エンジニアに、 その内訳や見積の考え方を聞いてみましょう。

役割分担や優先順位によって、 不要な部分を削ったり、選定する技術を変更したりすることで、 金額を抑えられたりすることは十分に考えらます。

不信感を持ちながら、システム開発をスタートするより、 スッキリした状態で開発プロジェクトを立ち上げられるように、 気軽に相談してみてはいかがでしょうか。

f:id:HIDEKIT:20150330170414j:plain

今はどこも桜が満開ですね。近所のお寺です。

【リリース・プロモーション】発注者のためのアプリ開発のポイント⑥

はじめに

前回までにテストも完了しました。 それでは、そのアプリは日の目を見るように リリース作業を行います。

リリース作業も事前準備等は、発注者側で行えるものもありますが、 申請自体は多分に技術的な内容を含んでいるため、 開発者と協力しながら行うことをおすすめします。

(もし、技術的な部分を抑えていない素人がやるには、 かなり難しいことだけは覚悟しておいてください。)

そして、今や数百万個のアプリが、 アプリストアにリリースされています。

その中から、自分が作ったアプリを ダウンロードしてもらわなければなりません。 そのために行うのが、プロモーションです。

それでは具体的に中身を見て行きましょう。 なお、リリースの手順や内容について、改訂がはいることが しばしばありますので、現状の申請方法を事前に確認しておいてください。

リリース準備

アプリをリリース作業をする前に、 アプリの紹介文など、申請に必要な文書やスクリーンショットを 用意しましょう。

おおまかには以下の様なものになります。

- アプリのタイトル
- 紹介文
- スクリーンショット
- アプリストアの検索用のタグ
- 申請者の住所 etc..

以下のサイトが詳しいので参考にして下さい

iOS, 申請】iOSアプリの申請プロセスについてPart2 〜iTunes Connectでのアプリ申請前夜まで〜 http://qiita.com/knife0125/items/5b2fa28d651c5f4de52e

Google Play申請手順(2014年冬) http://qiita.com/itosho/items/8daf17286dcb307931e4

また、このときに、アプリあ多くの人の目にとまるように、 タイトル名の付け方などにもポイントがありますので、 下記サイトなどを参考にして下さい。

・ASO(アプリストア最適化)におけるキーワード設定のコツ!かなり重要です。 http://column.app-scope.jp/post/93058287125/aso

リリース

準備ができますと、リリースになります。

リリースが無事終わると、 iOSアプリはApp Storeに、 Androidアプリは、Google Playからダウンロードが可能になります。

※ なお、AndroidはGooglePlay以外にもアプリストアがありますが、 必要に応じて、他のアプリストアでのリリースを検討して下さい。

まず、Androidアプリは、リリース申請をおこなうと、 その3時間後ぐらいにはストアからダウンロードできるようになります。

一方、iOSアプリは、リリース申請の後に、 Apple社の審査があります。 この審査を終えるとストアに並ぶことになりますので、 おおよそ1〜2週間ほどかかります。

この審査でもし、リジェクトされてしまうと、 アプリのプログラムの変更等の対応が必要になり、それから再度、 一からの申請となりますので、注意してください。 ある程度リリース日には余裕をもたせることが望ましいですね。

また、Apple社の審査は厳しいことで有名ですから、 リジェクト理由には人通り目を通して下さい。

Apple社 アプリケーション審査 https://developer.apple.com/jp/app-store/review/

・「なぜアプリがリジェクトされたのか」をAppleが直々に解説!審査落ちする理由を公開 http://gori.me/apps/iphone-app-news/59988

なお、Androidは審査がないと言いましたが、 Googleがリリース後に事後的に審査を行っています。 そのため、そこで問題があると公開停止になります。 こちらもリジェクト理由については確認しておいてください。

Google Play デベロッパー プログラム ポリシー https://play.google.com/about/developer-content-policy.html

なお、リリース手順については以下が詳しいので、参考にしてください。

・【iOS, 申請】iOSアプリの申請プロセスについてPart1 〜Certification, Provisioningなどの必要ファイル準備編〜 http://qiita.com/knife0125/items/97de5c661e484e2c2019

iOS, 申請】iOSアプリの申請プロセスについてPart3 〜リリース用アーカイブファイル作成編〜 http://qiita.com/knife0125/items/05ef8bd6a5dc5fd9cd44

・よく分かる!Android アプリのリリース手順のまとめ | アドカレ2013 : SP #20 http://dev.classmethod.jp/smartphone/android/android-app-how-to-release/

プロモーション

そして、リリースされた後、またはリリースされる予定日あたりで、 プロモーションを行います。

以下のようなサイト、メディアにアプリの紹介依頼をお願いします。

- AppBankやアンドロイダーなどの、アプリのレビューサイト
- 一般ニュースサイト
- テレビ、雑誌、新聞
- プレスリリースサイト
- 広告(書籍、Web広告、アプリ広告)
- 店頭プロモーション(携帯電話ショップ、書店など)

紹介依頼を行う際は、メディア側にそのアプリの魅力をコンパクトに表現した プレスリリースを送って下さい。

プロモーションには、無料でできるものと、有料でできるものがあります。 そのアプリのマネタイズの方法によって、その切り分けを検討して下さい。

そして、最後に注意して欲しいのは、プロモーションは一定期間に集中して行って下さい。

レビューサイトやメディアで取り上げられると、 一時的にダウンロード数が飛躍的に増加します。 そして、そのタイミングで、アプリストアのランキングに入ることができれば、 更なるダウンロード数の拡大が期待できるからです。

さいごに

今や、アプリは物珍しいものではなく、 日常にある当たり前のものとなりました。

そのため、アプリをリリースするだけで、沢山ダウンロードされるような状況では ありませんから、プロモーションは必ず行って下さい。 せめて、無料でできることは必ず行って下さい。

※ 今回は手順の細かい説明について、多数のサイトのリンクを貼らせて頂きました。

 各サイト・著者様、ありがとうございます。

ヒットするiPhoneアプリの作り方・売り方・育て方

ヒットするiPhoneアプリの作り方・売り方・育て方

【テスト】発注者のためのアプリ開発のポイント⑤

はじめに

今回は「テスト」となります。

プログラムを作成した後は、必ずそれが意図したとおりの動きになっているか、 テストを行います。

開発者側で、基本的なテストを済ませた後に、 発注者側でもテストを行います。 この検収を目的とした、テストを UAT(User Acceptance Test ユーザ受け入れテスト・検収テスト ) と呼ぶことも多いです。

基本的には、開発者に依頼した要求どおりに、 アプリが動くかどうかを確認することになります。

テストの流れは、以下の様な流れになります。

1 テスト計画
2 テスト設計
3 修正等の対応

それでは、次に上記のプロセスを見ていきましょう。

テスト計画とテスト設計

まずは、テストを実施する前にテストの計画を立てましょう。 これはだれが、いつまでに、どういった、どの範囲でテストする、 といったことを決めて行きましょう。

そして、テスト設計になります。 テスト設計では、テストケースという実際に試してみる操作を整理します。

例えば、新規ユーザーがログイン→記事をお気に入りに追加する→お気に入りボックスに追加されていること のような形で、一連の操作手順(シナリオ)の用意も必要です。

規模が大きいアプリの場合は、全てのシナリオを実施することが、 出来ないこともあります。 そういった場合は、優先順位をつけて、確認するテストケース、シナリオを決めていきましょう。

テストケース作成のポイントを挙げると以下のようになります。

- 仕様書や依頼した画面イメージなどを用意して、1つ1つの項目を突き合わせる(テストの抜け漏れを防ぐ)
- 開発者側がテスト仕様書(テスト報告書)を作成した際は、テスト仕様書にテストが網羅されているか確認する
 (もし、テストに漏れがあれば、開発者にテストをおこなってもらう)
- まずは最も多いであろうスタンダードな、操作の流れを再現してみる
- そして、あまりないであろう操作の流れを再現してみる(例外系)

このようなテストケースをまとめてテストケースを作成することが一般的です。

テストの実施

次は、テスト計画やテスト設計(テストケース)にしたがって、 実機でテストとなる操作を行います。 そして、そのテストの結果が、想定した通りの結果(正常)か、 想定と異なるか(異常)かを記録していきます。

テスト後の対応

テストで問題が確認された場合は、 その対応策を考えなければいけません。 例えば、急に強制終了するとか、 登録したデータが壊れてしまうなど、 そういった場合は、致命的なバグとなりますので、 リリース前に修正を行い、再度テストをおこないます。

また、レイアウトがほんの少しズレているとか、 非常に稀なケースで画面が崩れてしまう、とか そのような場合は、一旦、対応を先送りにすることもあります。 (次回に改修する際に修正するなど)

いずれにせよ、顧客満足度や 品質、納期(リリース予定日)、費用の観点から、 対応する範囲を決定することが大切です。

また、iOSの場合、致命的なエラーが残っているケースは、 リリース申請の結果がリジェクト(申請拒否)となり、 修正が求められることもあります。

テストと修正を、問題がなくなるレベルまで繰り返して、 ようやくリリース作業に移ることができます。

今回はここまでです。 次回、リリースとプロモーションについて説明します。

Androidアプリテスト技法

Androidアプリテスト技法