「アプリ開発」は一般にapp developmentまたはapplication developmentと表せます。
ただし英語仕様書では単語の直訳より、requirement、design、build、deploy、release、operateの工程差をチームで定義することが重要です。
同じ言葉を同じ意味で使える用語集を先に作り、要件文には対象、条件、動作、結果を入れてください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 日本語 | 英語候補 | 区別する点 |
|---|---|---|
| アプリ開発 | app development | モバイル、Web、業務アプリの範囲 |
| 要件 | requirement | 満たすべき条件 |
| 仕様 | specification | 動作や制約の定義 |
| 設計 | design | 要件を実現する構造 |
| ビルド | build | ソースから成果物を作る工程 |
| 配備 | deployment | 対象環境へ配置する工程 |
| 公開 | release | 利用者へ提供する判断と行為 |
| 運用 | operation | 公開後に維持する活動 |
工程用語を成果物と動作で区別する
build、deploy、releaseは同じ意味ではありません。
ビルドが成功しても検証環境へ配備していない場合があり、配備済みでも利用者へ公開していない場合があります。
| 用語 | 動作 | 完了の証拠 |
|---|---|---|
| requirement | 必要な成果と制約を定義 | 受け入れ条件 |
| design | 実現方法と構造を決定 | 図、データ、API、判断記録 |
| implementation | 設計をコードへ変換 | レビュー済み差分 |
| build | 配布可能な成果物を生成 | 版付きパッケージ |
| deployment | 環境へ配置 | 配置記録と動作確認 |
| release | 対象利用者へ提供 | 公開記録 |
| operation | 監視、問い合わせ、更新 | 運用記録 |
要求情報の考え方はISO/IEC/IEEE 29148の規格案内で確認できます。
規格の用語を無条件で増やすのではなく、自社の成果物と承認条件へ対応させてください。
英語のappは口語的な短縮形で、契約や規格ではapplicationを使う場合があります。
どちらを選んでも、mobile application、web application、backend serviceの範囲を文書冒頭で定義します。
仕様文を五つの要素で書く
曖昧な「ユーザーが簡単に登録できる」を、そのままThe user can easily registerと訳しても検証できません。
誰が、どの条件で、何をしたとき、システムがどう動き、何をもって成功とするかへ分けます。
- Actorとして操作主体と権限を示す
- Preconditionsとして開始前の状態を示す
- TriggerまたはActionとして入力や操作を示す
- System behaviorとして処理と例外を示す
- Acceptance criteriaとして観測可能な結果を示す
例として、A signed-in user can cancel an unshipped order and receives a confirmation messageのように、主体、条件、操作、結果を一文へ含められます。
ただし実際の仕様では、キャンセル可能時間、返金、外部通知、失敗時の状態も別の受け入れ条件へします。
必須度を示す語は、文書内で定義して使ってください。
RFC 2119とRFC 8174は、MUST、SHOULD、MAYなどを規範語として解釈する条件を示しています。
四主体と三状態の曖昧さを数える計算例
次の数字は、「ユーザーが編集できる」という一文の不足を示す仮定です。
未ログイン、一般利用者、管理者、停止中利用者の4主体と、下書き、申請中、承認済みの3状態があるとします。
主体と状態の基本組み合わせは4×3で12通りです。
一文のuserとeditableだけでは、12通りのどれを許可するか判断できません。
| 軸 | 候補数 | 例 |
|---|---|---|
| Actor | 4 | anonymous、member、admin、suspended |
| State | 3 | draft、pending、approved |
| 組み合わせ | 4×3 | 12 |
権限表で許可、拒否、読み取り専用を決め、仕様文とテストの両方から参照します。
英語が流暢でも、主体と状態が省略されれば要件の曖昧さは残ります。
用語集へ定義と使用例と禁止例を残す
用語集は日英の対訳だけでなく、意味、範囲、使用例、似た語との違い、担当者を持たせます。
customer、client、user、memberが同じ利用者を指すなら一つへ統一し、異なるなら定義を分けます。
エラー文では開発用の専門語をそのまま利用者へ見せません。
timeout、authentication failure、validation errorという内部分類と、利用者が次に行う操作を示す表示文を分けます。
翻訳資産を管理する場合は、XcodeのLocalization資料のように、文字列へ文脈を添えて抽出と取り込みを行う仕組みを使います。
仕様書の用語集とUI用語集を無関係に作らず、利用者向け表現との対応を残してください。
英語仕様を差分でレビューする
長い英語文書を完成後に一括レビューすると、用語変更と機能変更が混ざります。
一つの要件変更ごとに、定義、仕様、画面文言、テストの差分をまとめます。
GitHubのPull Requestレビュー資料は、コメント、承認、変更要求を差分へ結び付ける方法を説明しています。
文法だけでなく、主体、条件、例外、用語定義、受け入れ条件の一致を確認します。
機械翻訳を使う場合も、変更された規範語と否定表現を重点確認します。
must notとneed not、canとmayのように、実装と権限へ影響する違いを対訳表へ残してください。
アプリ開発の英語表現でよくある質問
アプリ開発は英語で何と言いますか？
一般にはapp developmentまたはapplication developmentです。
対象を明確にするならmobile app development、iOS app development、Android app development、web application developmentのように範囲を加えます。
MUSTとSHOULDは同じ強さですか？
同じではありません。
必須条件と推奨条件を同じ優先度で実装できると解釈しないことが重要です。
規範語として使う場合の意味はRFC 2119とRFC 8174で確認し、文書内でも定義してください。
日本語仕様書を自動翻訳すれば十分ですか？
下訳には使えますが、曖昧な原文、固有用語、否定、規範語、権限、受け入れ条件は人が確認します。
原文を先に対象、条件、動作、結果へ分解すると、翻訳後の確認もしやすくなります。
定義済みの英語で仕様とテストをつなぐ
英語仕様書の品質は難しい単語ではなく、同じ用語が同じ対象と条件を表すかで決まります。
工程語、主体、状態、規範語を用語集へ固定し、要件とテストの差分を一緒にレビューします。
- app developmentとapplication developmentで明示する対象範囲
- requirement、design、build、deployment、release、operationの成果物差
- 仕様文に必要なActor、Preconditions、Action、System behavior、Acceptance criteria
- 用語集へ残す定義、範囲、使用例、禁止例、担当者
英語文書を含む見積もりへ進む前に、アプリ開発費用の種類、機能別内訳で翻訳、レビュー、実機確認を別の工数として計上してください。
