英語でアプリの仕様を確認するときは、利用者、入力、保存先、失敗時の動作、完了条件を具体的な質問にすると話を進めやすくなります。「Do you understand?」に「Yes」と答えるだけでは、同じ動きを想像できているかは分かりません。
この記事では、「学習時間を保存できるようにしてほしい」という依頼を題材に、実装前の英語の質問と、回答をまとめるメモを練習します。会話・仕様はすべて編集部が用意した学習用の例です。実際の顧客案件や授業記録ではありません。
この記事でわかること
- 入力・保存・失敗時の動きを確認する英語の質問。
- 作業範囲と完了条件をそろえる聞き方。
- 決定事項と未決事項を分ける英語のメモ。
質問の基本形
Should the app ...?
アプリは〜する仕様ですか。
What should happen when ...?
〜したとき、どう動く必要がありますか。
To confirm, ... Is that correct?
確認ですが、〜という理解で合っていますか。
英語で仕様を確認する前に、目的と使う人をそろえる

最初の依頼を、次の1文とします。
Please add a feature that lets users save their study time.
「利用者が学習時間を保存できる機能を追加してください」という意味です。この段階では、保存する項目、入力できる値、再読み込み後の状態、別端末との共有などが決まっていません。
たとえば、「保存」が画面上の一覧に追加することなのか、ブラウザを閉じても使えるようにすることなのかで実装が変わります。さらにスマートフォンとPCで共有するなら、1つのブラウザだけに保存する仕組みでは満たせません。先に期待する使い方をそろえましょう。
英語の質問を考える前に、次のような日本語のメモを作ると整理できます。
| 依頼から分かること | まだ分からないこと |
|---|---|
| 学習時間を記録する機能が必要 | 誰が、どの端末で使うか |
| 利用者が保存操作をする | 何を入力し、何を必須にするか |
| あとで記録を使う想定がある | 再読み込み・削除・端末変更でどうなるか |
確認1:誰が、どんな場面で使うか
最初に、機能を使う人と目的を聞きます。技術の選択から始めるより、必要な動作を決めやすくなります。
| 英語の質問 | 確認できること |
|---|---|
| Who will use this feature? | この機能を使うのは誰か |
| Will each learner use the app on their own device? | 学習者が自分の端末で使うか |
| What do users need to do with the saved records? | 保存後に記録をどう使いたいか |
| Do users need to share their records with anyone? | 他の人への共有が必要か |
最後の質問への答えが「講師に提出したい」なら、一覧を見るだけで足りるか、出力する機能が必要かを続けて確認できます。ただし、「共有したい」という回答だけで公開ページを作ると決めてはいけません。誰が何を見られる必要があるかを具体化します。
入力・保存・失敗時の動きを具体的に質問する

確認2:入力項目と、有効な値を決める
「学習時間」の単位は分なのか時間なのか、0を許すのか、小数は使うのか。同じ画面でも、入力ルールによって動作とテストが変わります。
Which fields are required?
Should the duration be entered in minutes?
Should the app accept only whole numbers?
What are the minimum and maximum values?
順に、「必須項目は何か」「時間は分単位か」「整数だけを受け付けるか」「最小値と最大値はいくつか」です。whole numbersで小数を含めないことを尋ねても、0を認めるかは別に確認が必要です。
境界が曖昧なら、値を出して質問します。
Should the app reject 0 and values above 1440?
For example, should 30 be accepted and 30.5 be rejected?
「0と1440を超える値は受け付けないか。たとえば30は受け付け、30.5は拒否するか」という確認です。ここでの1〜1440分は教材上の候補であり、あらゆるアプリに適した上限という意味ではありません。利用目的に合わせて決めます。
確認3:保存先と、残る範囲を確認する
保存先を知らない利用者に、最初から「localStorageとデータベースのどちらですか」と聞いても判断が難しいことがあります。利用者が期待する動作として質問しましょう。
| 確認したい動作 | 質問例 |
|---|---|
| 再読み込み後も残るか | Should saved records remain after the page is reloaded? |
| 別の端末でも見たいか | Should users be able to see the same records on another device? |
| ログインが必要か | Do users need to sign in to access their records? |
| 消える条件を案内するか | Should we explain what happens if the user clears the browser data? |
1つのブラウザのlocalStorageへ保存する教材なら、別端末への同期まで実現したことにはなりません。MDNのlocalStorageの説明では、保存がオリジンに結び付くことや、ブラウザセッションをまたいで保持できることが説明されています。実装方法と、利用者に約束する範囲を対応させましょう。
ブラウザ内の保存を体験する練習には、JavaScriptの学習記録アプリ教材を使えます。要件確認の場では、その仕組みで依頼を満たせるかを先に確かめてください。
確認4:間違った入力や保存失敗をどう扱うか
正しい値を保存できるだけでは、入力欄が空だった場合の動きは決まりません。「何を止めるか」と「利用者へ何を伝えるか」を分けて確認します。
What should happen when the duration is empty?
Should the app show a message and keep the entered topic?
If saving fails, should the app keep the input so that the user can try again?
意味は、「時間が空欄ならどうするか」「案内を表示し、入力した学習内容は残すか」「保存に失敗した場合、再試行できるよう入力を残すか」です。
ここまで決めると、単にエラー表示を出せばよいのか、入力値も保持すべきなのかが分かります。確認できていない保存失敗への対応を、完成メモに「対応済み」と書かないようにしてください。
今回の作業範囲と、完了を判断する条件を決める

追加機能の話が出たら、今回の作業に含めるかを確認します。実装する側が黙って省くことも、相手が頼んでいない機能を増やすことも避けられます。
Do we need editing and deletion in this version?
Is CSV export part of this task?
Could we handle device synchronization in a separate task?
「今回は編集・削除も必要か」「CSV出力はこの作業に含まれるか」「端末間同期を別の作業で扱えるか」という質問です。最後の文は別作業にする提案であり、同意を得たことを意味しません。
短い課題では、In scope(今回含める範囲)とOut of scope for this version(この版では含めない範囲)を並べると整理しやすくなります。除外は永久に作らないという意味ではなく、今回の境界として書きます。
確認6:「完成」と判断する具体例を決める
「使いやすくする」だけでは、何を確かめれば完成なのかが曖昧です。操作と期待する結果を1組ずつ書き、相手に確認します。
Can we use the following checks to confirm that this task is complete?
1. Enter a topic and 30 minutes, then save. One record appears.
2. Reload the page. The saved record remains.
3. Leave the duration empty, then save. A message appears and no record is added.
これは「次の確認項目で完了を判断してよいか」という質問です。確認項目を提案した段階なので、テストに合格した報告ではありません。実装後には、実際の結果を別途記録します。
チェック表に落とし込む方法は、入力ミス・保存を確かめるテストの作り方も参考になります。0、小数、上限などが必要かは、合意した入力ルールから選びます。
決まったことと未決事項を英語のメモにまとめる

質問への回答が複数のメッセージに分かれたら、実装前に短くまとめ直します。以下は教材で回答を得たと仮定したメモの例です。
To confirm my understanding:
Goal:
Each learner can record study time in their current browser.
Agreed behavior:
- A topic and a duration are required.
- The duration must be a whole number from 1 to 1440 minutes.
- Records remain after a page reload.
- Invalid input must not create a record.
Not included in this version:
- Sign-in
- Synchronization across devices
- CSV export
Still to confirm:
- The exact message for invalid input
- What to show if saving fails
Is this understanding correct?
最後に「この理解で合っているか」と尋ねています。Agreed behaviorには回答を得た項目だけを入れ、まだ返事がない内容はStill to confirmに残します。合意メモを書くことで、未確認の項目まで確定するわけではありません。
作ったあとの説明書は、英語READMEのテンプレートへ整理できます。その際は、実装予定の機能と、現在動く機能を混ぜないようにしてください。
練習:「使いやすくして」に3つ質問する
次の依頼を受けたとき、すぐに色やボタンを変更する前に、何を確認するか考えてみましょう。
Could you make the app easier to use?
質問の例:
Which step is difficult for users?
利用者にとって難しいのは、どの操作ですか。Could you describe what users are trying to do?
利用者が何をしようとしているか教えていただけますか。What should users be able to do after this change?
変更後に、利用者が何をできる状態にしたいですか。
答えが「保存後に記録が増えたことに気づかない」なら、保存結果をどう知らせるかが検討対象になります。答えを聞く前に「色を変えること」が正解だと決めないのがポイントです。
よくある質問
英語が苦手なので、質問を短くしてもよいですか?
短くて構いません。1つの文で1つのことを聞き、必要なら30や0のような具体値を添えましょう。長い質問を一度に話すより、回答を確認しながら進められます。
ShouldとCanはどう使い分けますか?
この場面では、Should the app ...?を「そう動くべき仕様か」の確認に使えます。Can the app ...?は、現在できることや実現可能性を聞いているようにも読めます。必要に応じてDo we need ... in this version?と、今回必要かを明示してください。
質問しすぎると作業が遅くなりませんか?
すべてを一度に決める必要はありません。保存範囲や入力ルールなど、答えによって作るものが変わる点を優先します。文言など後から調整できる項目は、誰がいつ決めるかをメモしておく方法もあります。
まとめ:仕様を、利用者の操作と結果で確認しよう
仕様確認の英語は、専門用語を多く使うことより、「誰が何をしたら、どうなるか」をそろえるために使います。最初はShould the app ...?で聞き、最後にTo confirm, ...で理解を返すところから練習してみてください。
英語で質問しながら、ITを学ぶ方法を相談したい方へ
KredoではITと英語を学ぶ留学プログラムを案内しています。自分の現在の英語力や、作ってみたいものをもとに、学習方法を相談できます。
英語でIT・AIを学べるKredo
英語×IT・AIのスキルを身につけてグローバルに活躍しませんか?
当メディアを運営しているKredoは、英語×ITをオンラインで学ぶ「Kredoオンラインキャンプ」と、フィリピンのセブ島で英語とIT・AIを学ぶ「KredoIT留学」「KredoAI留学」を提供しています。これまでの卒業生は3,000名以上。卒業生の多くが、国内外のIT企業への転職、フリーランスなどへのキャリアチェンジを実現しています。これからの時代に必要な英語×IT・AIのスキルを身につけてグローバルに活躍しませんか?











