アプリ納品時に泣かないための受け入れテストの基礎知識：Androidアプリ開発テスト入門（終）（3/3 ページ）

[生路茂太，日本Androidの会テスト部]

解決策【3】受け入れテスト担当者の最後の拠り所「ビジネスモデル」

　冒頭でも述べましたが、受け入れテストという最上位のテストは、「どんな」テストをするか、ではなく「誰が」テストをするかです。また、その目的はエンドユーザーやマーケットに受け入れてもらうことです。

　ここまで、受け入れテストの根拠となる「要求がない」という問題に対して、「要求仕様を明確化して受け入れテストにつなげよう」という視点で書かせていただきましたが、それでも現実に要求が固まっていない・固まらない場合の方が多いと思います。その際、最後の拠り所となるのは究極のメタ要求である「ビジネスモデル」です。

SI業界で発達した超上流工程

　前述の通り、受け入れテストは要求仕様に対する下流作業であると同時に、要求仕様の妥当性確認作業でもあります。このため、SIerの分野ではベンダ側からもBABOKなどの「超上流工程」とよばれるビジネス制約についても考慮することで、要求や要求変更の妥当性確認をより高い精度で行う取り組みを行っています。

出典『経営者が参画する要求品質の確保』（IPA ソフトウェア・エンジニアリング・センター編、オーム社、2006年6月、P35）

　ただし、Androidアプリのような軽量開発における超上流とはBABOKのような複雑な概念ではなく、企画書やブレストから以下のような事項を想像したものだと思ってください。

　実際、要求が固まっていない状況ではビジネスモデルが完全に固まっていることも少ないと思います。だからこそ、これから決めていく要求仕様の根拠としてビジネスへの整合性を意識する必要があります。

1. 達成のための予算（例：1000万円）
2. 達成したい目標（例：100万DL獲得）
3. 達成のためのストーリー（例：有名ゲームの全世界全機種移植対応）

　どんなに何も決まっていないプロジェクトでも、特に1.の予算上限がぶれることはあまりありません。予算規模が分かっているだけでも、そのAndroidアプリに対する受け入れ基準の規模感の目安とすることができ、要求変更時に目標達成ためのストーリーとの矛盾の検知などを行えます。

　ちなみに言うまでもないですが、ビジネスモデルの骨子がない状態の要求には、実現する根拠がありませんので、後々に変更される可能性が極めて高いです。

受け入れテスト担当者のためのビジネスモデルフレームワーク

　これまで、受け入れテストのための理論的根拠となる知識体系というと、おそらく品質保証、ユーザビリティ、またはREBOKなどの要求工学がまず思い浮かぶものと思います。しかし、受け入れテストの双子の兄弟である要求仕様から見ると、「ビジネスモデル」も極めて近しい概念となります。

　受け入れテスト担当者およびエンジニアという立場から、メタ要求としてビジネスモデルを活用するための方法論として、書籍『ビジネスモデルジェネレーション』中に紹介される「ビジネスモデルキャンバス」および「エンパシーマップ」というフレームワークが有用です。

　「ビジネスモデルキャンパス」記法は、DFDやUMLのアクティビティ図に慣れたエンジニアにとってビジネスモデルを「物流と金流という2つのデータフローのアーキテクチャ」としてとらえるのに適しています。

ビジネスモデルキャンパス紹介 from miyazen

　もう一方の「エンパシーマップ」という記法は、エンドユーザーのペルソナ像や要求の背景を探るのに適しています。

Open Field Notes: 【d.schoolメソッド】エンパシーマップでユーザーへの理解を深める via kwout

　これらを基に、例えば「エレベータ・テスト」と呼ばれるフレームワークに沿って言語化をすることで、USDMの上位である超上流工程の「メタ要求」として定義でき、受発注間の認識統一や、受け入れテスト作成時のガイドラインの1つとして活用できます。

　「エレベータ・テスト」とは、エレベータに乗っているような短時間で、人に製品を説明できるかどうかという考え方で、以下のようなことを説明するものです（参考：ジェフリー・ムーア著『キャズム』）。

これは、

• 「（あること）」で問題を抱えている
• 「（どんな人）」向けの、
• 「（ある分野）」の製品であり、
• 「（ある機能を提供）」することができる。
• そして、「（同じ分野の競合製品）」とは違って、
• この製品には、「（すばらしい機能）」が備わっている。

Androidアプリの受け入れテスト技術発展のために

　このように、Androidアプリ開発の受け入れテスト担当者は、営業視点の経理的要求、企画視点のUI／UX要求、モバイル端末視点およびシステム視点の技術要求、法律や外部要因に対する品質要求などの中心に立つことになるので、最下流と最上流を行ったり来たりしながら臨機応変な対応を求められます。

　やるべきことは膨大で、ノウハウの蓄積もない中では途方もない仕事に見えるかもしれませんが、Androidアプリ自体が新しい技術分野であるため、これはやむを得なく、またそれが新規技術の醍醐味（だいごみ）でもあります。

　一つ言えるのは、この分野の進化をより加速させるためには、車輪の再発明を避け、クリエイティブ、ビジネス、Web、SI、組み込みなど異なる分野の有用な既存知識をいかに応用させていくかが重要になってきます。

　Androidという新しい世界においては、自分の出身業界の常識にとらわれず互いに歩み寄ることで、新しいソフトウェアテストの定石を生み出すことが求められているといえるでしょう。

テスト部へのお誘い

　Androidテスト部では、これまでの連載で挙がったテスト技術について、それぞれが研究結果を持ち寄って発表、議論しています。

　第2回テスト祭りの閉会あいさつでも述べましたが、Androidの世界はまだまだ解決を待っているソフトウェアテストに関する問題が山積みです。本連載を読んでくださった皆さんには十分に参加資格があります。テスト部一同、皆さんの参加を心待ちにしております。

Android Test and Evaluation Club（ATEC） via kwout

著者プロフィール

生路 茂太

Androidテスト部

組み込みソフトウェアベンダで、国内外の携帯電話／テレビ開発、サービスプラットフォーム開発、新規事業開発などに従事。現在は、広告業界でAndroid関連事業や著作権事業開発に従事。超上流〜上流プロセスを主に担当。

商売と技術の狭間で、受発注間のコミュニケーション改善を目指して、日々是七転び八倒中

「Androidアプリ開発テスト入門」バックナンバー

• アプリ納品時に泣かないための受け入れテストの基礎知識
• ここが超タイヘンだよAndroidアプリのシステムテスト
• JenkinsでCI（継続的インテグレーション）すればAndroidアプリ開発はもう怖くない
• Android Mockを利用してHTTP通信をテストするには
• スマホアプリに必須なデータ永続化のためのDBテスト
• Androidアプリを“超”魅力的にする3種類のUIテスト
• Android SDKでビジネスロジックのテストを自動化するには
• Androidアプリ開発でテストを始めるための基礎知識