システム開発の打ち合わせで、「要件定義」「非機能要件」「ステージング」「受入テスト」と専門用語が次々に出てきて、話についていけない。気づけば「では、その方向で進めます」と会議が終わっていた——技術に詳しくない事業部門の担当者によくある悩みです。
「打ち合わせで専門用語ばかり出てきて、何を決めているのか分からない…」
先に結論をお伝えします。用語をすべて覚える必要はありません。大切なのは、その用語が出てきたときに「いま自分は何を決める(確認する)場面なのか」が分かることです。専門用語の多くは、発注者が判断すべきことの「目印」になっています。
この記事では、打ち合わせでよく出てくる専門用語を、プロジェクトの工程(企画・要件定義/設計/開発・テスト/リリース・運用)ごとに「ひとことで言うと」と「発注者が決める・確認すること」の表で整理しました。あわせて、分からないときの聞き方や議事録の頼み方も紹介します。
打ち合わせで専門用語が分からなくなる理由
専門用語が多くなるのは、開発会社が意地悪をしているからではありません。開発チームの中では、用語を使うほうが短く正確に伝わるため、つい社外の打ち合わせでも同じ言葉を使ってしまうのです。
一方で発注者にとっては、用語が分からないまま進むと困ることがあります。打ち合わせは「説明の場」であると同時に「発注者が判断する場」でもあるからです。何を判断したのか分からないまま同意すると、後から「そういう意味だったのか」という食い違いや、想定外の追加費用につながりかねません。
そこで次の章からは、用語を工程ごとに並べ、それぞれの場面で発注者がやることをセットで示します。表は打ち合わせの前に、その工程の部分だけ見返す使い方がおすすめです。
企画・要件定義フェーズの用語と発注者が決めること
プロジェクトの最初の段階です。ここで出てくる用語は「何を・いくらで・いつまでに・どんな契約で作るか」に関わるものが中心で、発注者の判断が最も多い工程です。
| 用語 | ひとことで言うと | 発注者が決める・確認すること |
|---|---|---|
| RFP(提案依頼書) | 開発会社に提案をお願いするための依頼書 | 目的・予算の幅・期限・必須条件を書き、複数社に同じ条件で渡す |
| 要件定義 | 作るものの中身を文章で決める工程 | 業務の流れ・必須の機能・例外ケースを伝え、できた要件定義書を確認・承認する |
| 機能要件 | システムが「何をできるか」 | 必須の機能と「あれば嬉しい」機能を仕分ける |
| 非機能要件 | 速さ・止まらなさ・安全性など「どのくらいの品質で動くか」 | 利用人数、止まったら困る時間帯、扱う情報の重要度を伝える |
| 工数/人月 | 作業量の単位(人月=1人が1か月働く量) | 見積もりの工数が、どの作業にどれだけかかる前提かを聞く |
| 請負/準委任 | 請負=完成に対して払う契約、準委任=作業そのものに対して払う契約 | どちらの契約か、何をもって「完了」とするかを確認する |
| ウォーターフォール/アジャイル | 最初に全部決めて順に作る進め方/小さく作って直しながら進める進め方 | どちらで進めるか、発注者側がどのくらい打ち合わせに参加するかを確認する |
| WBS | 作業を細かく分けて一覧にした表 | 発注者側の作業(資料の提供・確認・承認)が入っているかを見る |
| マイルストーン | 途中の大きな節目(例:設計完了、テスト開始) | 節目ごとに発注者の確認・承認が必要な日を社内の予定に入れる |
要件定義は、発注者が主体となって関わるべき工程だと公的機関も指摘しています。
📰 出典:IPA(情報処理推進機構)「ユーザのための要件定義ガイド 第2版」
IPAはこのガイドの紹介で、要件を定義する責任はシステムを使う立場のユーザ(発注者側)にあると言われていることに触れています。「要件定義」という言葉が出てきたら、自社の業務を一番知っている人が参加すべき場面だと考えてください。要望の伝え方は作りたいシステムを開発会社にどう伝える?初めての発注で準備したい5つのことでも詳しく解説しています。
契約形態の違いについては、IPAが公開しているモデル契約の考え方が参考になります。
📰 出典:IPA「情報システム・モデル取引・契約書(アジャイル開発版)」
IPAは、アジャイル開発版のモデル契約について、あらかじめ特定した成果物の完成に対価を払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を払う準委任契約を前提にしていると説明しています。進め方(アジャイルかどうか)と契約形態はセットで話題になりやすいので、一緒に確認しておくと安心です。個別の契約内容の判断は、弁護士などの専門家に相談しましょう。
設計フェーズの用語と発注者が決めること
要件定義で決めた「何を作るか」を、「どう作るか」に落とし込む段階です。画面の見た目や使い勝手を発注者が確認できる、大切なタイミングでもあります。
| 用語 | ひとことで言うと | 発注者が決める・確認すること |
|---|---|---|
| 基本設計(外部設計) | 画面・帳票・操作の流れなど、使う人から見える部分の設計 | 画面や帳票が業務に合っているかを確認し、承認する |
| 詳細設計(内部設計) | プログラムの中身の設計。主に開発会社が担当 | 基本的には任せてよい。変更が要件に影響する場合だけ説明を求める |
| ワイヤーフレーム | 画面の配置を線で描いた設計図 | 項目の過不足・並び順・ボタンの位置を現場目線で確認する |
| プロトタイプ | 実際に触れる試作品 | 現場の担当者に触ってもらい、使いにくい点を早めに伝える |
| API | システム同士がデータをやり取りする窓口 | 連携したい既存システムや外部サービスを伝え、相手側の費用や制限を確認する |
| DB(データベース) | データを整理して保存する入れ物 | どんなデータを、どのくらいの期間保存するか、移行するデータがあるかを伝える |
| クラウド | インターネット経由で借りるサーバーなどの設備 | どのサービスを使うか、月々の利用料を誰が契約して支払うかを決める |
設計フェーズで見落としがちなのが「承認」の重みです。基本設計を承認した後に画面を変えたくなると、多くの場合は仕様変更の扱いになります。ワイヤーフレームやプロトタイプの段階で、実際に使う人に見てもらうのが一番の予防策です。変更の考え方はシステム開発の途中で仕様変更したい!どこまで変えていい?判断の物差しと進め方も参考にしてください。
開発・テストフェーズの用語と発注者が決めること
開発会社が実際にプログラムを作り、確かめる段階です。この工程の用語は開発会社の中の作業を指すものが多いですが、最後の「受入テスト」は発注者が主役です。
| 用語 | ひとことで言うと | 発注者が決める・確認すること |
|---|---|---|
| スプリント | アジャイルで使う、1〜数週間の短い開発の区切り | 区切りごとの成果確認の場に参加し、次に優先する機能を決める |
| PR(プルリクエスト)/レビュー | 書いたプログラムを別の人が確認する仕組み | 基本は開発会社内の品質管理。レビュー体制があるかを聞いておく |
| 単体テスト | 部品ごとの動作確認 | 開発会社の作業。テスト結果の報告をもらえるか確認する |
| 結合テスト | 部品をつなげたときの動作確認 | 既存システムとの連携部分をいつ・どう確認するかを聞く |
| 受入テスト(UAT) | 発注者が実際の業務の流れで使ってみて、合格かを判断するテスト | テストする人・日程・合格の基準を決め、社内の時間を確保する |
| 本番環境/ステージング環境 | 実際に使う環境/本番そっくりの確認用の環境 | 受入テストをどの環境で行うか、テスト用のデータを誰が用意するかを決める |
受入テスト(UAT)は、発注者が「これで納品を受ける」と判断する場面です。「開発会社がテストしたから大丈夫」と任せきりにせず、日常業務の流れや例外ケースで実際に操作してみましょう。受入テストの期間には、現場の担当者の時間を確保しておく必要があります。
「受入テストの日程は、できれば設計の段階で決めておきたいんです。現場の方の予定が押さえられないと、リリースがずれてしまうことがあるので」
リリース・運用フェーズの用語と発注者が決めること
完成したシステムを使い始め、使い続ける段階です。ここの用語は「トラブルが起きたとき、誰が・いつまでに・いくらで対応するか」に関わります。
| 用語 | ひとことで言うと | 発注者が決める・確認すること |
|---|---|---|
| リリース | システムを使える状態にして公開・利用開始すること | 利用開始日、社内への周知、旧システムからの切り替え方法を決める |
| デプロイ | 作ったプログラムを本番環境に反映する作業 | 反映作業をする時間帯(業務への影響が少ない時間か)を確認する |
| 保守/運用 | 保守=不具合修正や更新などの手入れ、運用=日々動かし続ける作業 | どこまでが月額費用に含まれるか、範囲外の作業はどう見積もるかを確認する |
| SLA | サービスの品質について、提供側と利用側で取り決めた水準 | 問い合わせへの回答時間や復旧の目安など、何を約束してもらうかを決める |
| 瑕疵/契約不適合 | 納品物が契約の内容に合っていないこと | 不具合を無償で直してもらえる範囲と期間を契約で確認する |
「瑕疵(かし)」は古い言い方で、現在は「契約不適合」という言葉が使われます。
📰 出典:IPA「改正民法に対応した『情報システム・モデル取引・契約書』」
IPAは、2020年4月施行の改正民法で瑕疵担保責任が契約不適合責任に変わり、権利を行使する期間の考え方も変わったことを解説しています。実際の無償対応の範囲や期間は契約書の書き方によって異なるため、契約前に確認し、判断に迷う場合は専門家に相談しましょう。保守費用の中身はシステムの保守費用は何に払っている?月額保守費の内訳と見直す前に確認したいことでも整理しています。
用語が分からないときの聞き方(そのまま使えるフレーズ)
分からない用語が出てきたら、その場で聞いてかまいません。ポイントは「意味」だけでなく「自分が何をすればいいか」まで聞くことです。
- 「すみません、◯◯というのは、ひとことで言うと何のことですか?」
- 「その件で、こちらが決めることや用意することはありますか?」
- 「それを決めないと、何に影響しますか?(費用・期間・使い勝手など)」
- 「いま決めていることを、私の言葉で言い直すと◯◯という理解で合っていますか?」
- 「この場で決めなくてもいい話であれば、社内で確認してから回答してもいいですか?」
特に最後のフレーズは大切です。その場で判断できないことは、無理に即答せず持ち帰りましょう。
議事録には「決まったこと」と「ToDo」を書いてもらう
専門用語の多い打ち合わせほど、議事録が役に立ちます。開発会社に議事録をお願いするときは、次の3つを分けて書いてもらうよう頼んでみてください。
- 決まったこと:何を・誰が承認したか(例:「画面Aのレイアウトを承認」)
- ToDo:誰が・何を・いつまでにやるか(発注者側の宿題も含める)
- 保留・未決事項:まだ決まっていないことと、いつ決めるか
議事録を受け取ったら、社内の関係者にも共有し、認識違いがあれば早めに伝えます。用語の意味を1行で添えてもらえると、社内の説明にもそのまま使えて便利です。
発注者がやることチェックリスト
- ☐ 打ち合わせ前に、今どの工程にいるか(要件定義・設計・テスト・運用など)を確認した
- ☐ 表を見て、その工程で自社が決めること・確認することを洗い出した
- ☐ 分からない用語は、その場で「ひとことで言うと?」と聞き返した
- ☐ 「こちらが決めること・用意することはあるか」を毎回確認した
- ☐ その場で判断できないことは持ち帰り、回答期限を決めた
- ☐ 議事録を「決まったこと・ToDo・保留事項」に分けて出してもらうよう依頼した
- ☐ 受入テストの担当者と日程を、早めに社内で押さえた
- ☐ 契約形態(請負/準委任)と、契約不適合への対応期間を契約書で確認した
開発会社への質問例
- 「このプロジェクトの工程ごとに、こちら(発注者側)が承認や確認をするタイミングを一覧にしてもらえますか?」
- 「今日の打ち合わせで決めたいことを、最初に教えてもらえますか?」
- 「今後の打ち合わせで出てきそうな専門用語を、1行ずつの用語集にしてもらうことはできますか?」
- 「議事録は、決まったこと・ToDo・保留事項に分けて共有してもらえますか?」
- 「受入テストでは、何をもって合格とするか、基準を一緒に決めてもらえますか?」
まとめ:専門用語は「発注者が決める場面」の目印
打ち合わせの専門用語は、すべてを覚える必要はありません。用語が出てきたら、次の3つを意識しましょう。
- いまはどの工程の話か(企画・要件定義/設計/開発・テスト/リリース・運用)
- その場面で発注者が決めること・確認することは何か
- 分からなければ「ひとことで言うと?」「こちらがやることは?」と聞く
特に、要件定義・基本設計の承認・受入テスト・契約の確認は、発注者にしかできない判断です。用語の意味が分からないまま同意せず、議事録で「決まったこと」を確かめながら進めれば、専門知識がなくても開発会社と対等に話を進められます。
あわせて読みたい関連記事









