「システム開発の要件定義で何を聞けばよいか分からない」

「顧客へのヒアリング項目を事前に整理しておきたい」

「必要な機能を聞いているつもりなのに、開発途中で追加要望が出てくる」

要件定義では、最初のヒアリングが非常に重要です。

ただし、ヒアリングで、

「どんな機能が必要ですか？」

と聞くだけでは十分ではありません。

なぜなら、利用者自身も「どの機能が必要なのか」を正確に言語化できているとは限らないからです。

例えば、

顧客：
顧客管理システムが欲しいです

開発者：
どんな機能が必要ですか？

顧客：
顧客登録、検索、CSV出力が欲しいです

というヒアリングだけで開発を始めると、後から、

案件も管理したい

営業担当別に表示したい

顧客ごとに対応履歴を残したい

管理者だけ削除できるようにしたい

既存Excelを移行したい

といった要望が追加される可能性があります。

重要なのは、

必要な機能を聞く

ことではなく、

現在どのような業務をしていて

何に困っていて

どのような状態に変えたいのか

を理解することです。

この記事では、Webシステム・業務システム開発の要件定義で確認したいヒアリング項目を、実際に使える質問例とともに整理します。

要件定義のヒアリングとは

要件定義のヒアリングとは、発注者・利用者・業務担当者などから、

開発背景

業務内容

課題

必要な機能

利用者

データ

セキュリティ

運用

予算

納期

などを聞き取り、システムとして実現すべき内容を整理する作業です。

要件定義では、

相手の要望をそのまま書き取る

だけでは不十分です。

例えば、

ダッシュボードが欲しい

と言われた場合も、

「なぜダッシュボードが必要なのですか？」

と確認します。

すると、

各営業担当から毎週Excelを集めて
売上を集計している

↓

管理者が数字を確認するまで
数日かかっている

↓

売上状況をリアルタイムで確認したい

という本当の課題が見えてくるかもしれません。

この場合、本当の要求は、

ダッシュボードを作る

ではなく、

管理者が最新の売上状況を
すぐ確認できる

ことです。

この違いを発見するのが要件ヒアリングの重要な役割です。

要件定義のヒアリング項目一覧

システム開発では、主に次の項目を確認します。

分類	主な確認内容
開発背景	なぜシステム化するのか
目的	何を改善したいか
現状業務	現在どう仕事をしているか
課題	何に困っているか
利用者	誰が利用するか
新業務	導入後どう変えたいか
機能	システムで何を実現するか
データ	何を管理するか
権限	誰が何を操作できるか
帳票	CSV・PDF等は必要か
外部連携	他システムと接続するか
非機能	性能・セキュリティ等
移行	既存データをどうするか
運用	導入後誰が管理するか
予算	開発予算はいくらか
納期	いつまでに必要か
優先順位	何が絶対必要か

順番に具体的な質問例を見ていきます。

1．システム開発の背景を確認する

最初に、

なぜ今回システム開発を検討しているのか

を確認します。

質問例

今回システム化を検討したきっかけは何ですか？

現在どのような問題が発生していますか？

これまでどのように対応していましたか？

なぜ今システム化する必要があるのでしょうか？

現在利用しているシステムに問題がありますか？

例えば、

Excel管理が限界になった

のであれば、

どの部分に限界を感じていますか？

まで確認します。

すると、

ファイルが増えすぎた

同時編集できない

誰が更新したか分からない

集計に時間がかかる

担当者しか操作方法を知らない

など、具体的な問題が見えてきます。

2．開発目的・ゴールを確認する

次に、

システムを導入して
何を実現したいのか

を確認します。

質問例

今回のシステム開発で最も改善したいことは何ですか？

システム導入後、どのような状態になれば成功ですか？

現在の作業時間をどの程度減らしたいですか？

絶対に解決したい課題は何ですか？

半年後、このシステムが成功したと判断する基準は何ですか？

例えば、

業務効率化したい

だけでは曖昧です。

可能であれば、

現在：
月40時間

↓

導入後：
月10時間以下

のように数字へ落とします。

3．現在の業務フローを確認する

要件定義で特に重要な項目です。

現在の業務、つまりAs-Isを理解します。

質問例

現在はどのような流れで業務をしていますか？

最初に誰が何をしますか？

その次に誰へ情報が渡りますか？

どこでExcelを使っていますか？

紙で管理しているものはありますか？

メールで送受信しているデータはありますか？

最終的に誰が確認・承認しますか？

例えば、

顧客から注文

↓

営業担当がExcelへ入力

↓

事務担当へメール

↓

事務担当が販売管理システムへ再入力

↓

倉庫へ連絡

という業務だったとします。

ここまで分かれば、

Excel入力
↓
メール
↓
再入力

に改善余地があることが見えてきます。

実際の資料を見せてもらう

ヒアリングだけでなく、

現在使っているExcel

紙の申請書

帳票

CSV

メール

マニュアル

既存システムの画面

も確認します。

実物を見ることで、利用者自身が意識していなかった業務が見つかることがあります。

4．現在の課題を確認する

業務フローを確認したら、

どこに問題があるのか

を聞きます。

質問例

現在最も時間がかかっている作業は何ですか？

ミスが発生しやすい業務はありますか？

二重入力している作業はありますか？

担当者しかできない業務はありますか？

確認のために電話・メールしている業務はありますか？

月末・繁忙期だけ大変になる業務はありますか？

例えば、

各営業担当が顧客情報をExcel管理

↓

月末に管理者が集計

↓

毎月5時間

なら、この作業はシステム化の対象候補になります。

「面倒な作業は何ですか？」も有効

現場担当者には、

毎日の業務で
面倒だと感じている作業は何ですか？

と聞くのも有効です。

専門用語を使わなくても、本質的な業務課題が見つかることがあります。

5．例外業務を確認する

要件定義で特に漏れやすい項目です。

通常業務だけではなく、

通常と違う場合

を確認します。

質問例

キャンセルの場合はどうしますか？

登録内容を間違えた場合はどうしますか？

返品の場合はどうしますか？

一部だけ変更するケースはありますか？

承認されなかった場合はどうしますか？

締切を過ぎた場合はどうしますか？

担当者が不在の場合はどうしますか？

例えば注文システムなら、

注文

↓

支払い

↓

発送

だけではありません。

実際には、

キャンセル

返品

一部返品

数量変更

支払い失敗

発送後キャンセル

などがあります。

こうした例外処理が開発途中で発覚すると、設計変更につながる場合があります。

6．利用者を確認する

次に、

誰がシステムを使うのか

を確認します。

質問例

誰が利用しますか？

何部署で利用しますか？

利用者は何人ですか？

社外の人も利用しますか？

取引先もログインしますか？

管理者は誰ですか？

将来的に利用者は増えますか？

例えば、

営業担当：
30名

営業管理者：
5名

システム管理者：
2名

とします。

利用者によって必要な画面・権限が変わります。

7．権限を確認する

利用者が複数種類いる場合、権限も確認します。

質問例

全員が同じデータを閲覧できますか？

他部署のデータを見ることはできますか？

削除できるのは誰ですか？

承認できるのは誰ですか？

管理者だけが変更できる項目はありますか？

拠点ごとにデータを分ける必要がありますか？

例えば、

操作	担当者	管理者
顧客閲覧	○	○
顧客登録	○	○
顧客削除	×	○
全担当者の案件閲覧	×	○
ユーザー管理	×	○

のように整理します。

8．新しい業務フローを確認する

現在の業務を把握したら、

システム導入後に
どう変えたいか

を確認します。

質問例

現在の作業のうち、なくしたいものは何ですか？

システム導入後も人が判断する業務は何ですか？

自動化したい作業は何ですか？

どこまでシステムに任せたいですか？

承認フローは今後も必要ですか？

例えば、

現在

Excel入力
↓
メール
↓
別システムへ再入力

を、

将来

Webシステムへ入力
↓
DB保存
↓
関係部署が同じ情報を見る

へ変更します。

9．必要な機能を確認する

ここで初めて具体的な機能へ入ります。

質問例

どのような情報を登録したいですか？

何を検索したいですか？

一覧画面には何を表示したいですか？

編集・削除は必要ですか？

通知機能は必要ですか？

CSV出力は必要ですか？

PDF出力は必要ですか？

ダッシュボードは必要ですか？

承認機能は必要ですか？

例えば顧客管理なら、

顧客登録

顧客検索

案件管理

対応履歴

担当者管理

CSV出力

などへ整理します。

「欲しい機能」だけを聞かない

相手が、

CSV出力が欲しい

と言った場合は、

なぜCSVが必要ですか？

と確認します。

すると、

毎月会計システムへ
データを取り込むため

と分かるかもしれません。

この場合、

CSV出力

より、

会計システムとの自動連携

の方が適切な解決策である可能性もあります。

10．検索条件を確認する

業務システムでは検索機能が重要です。

質問例

普段どの項目から情報を探していますか？

顧客名で検索しますか？

担当者で絞り込みますか？

期間指定は必要ですか？

複数条件で検索しますか？

検索結果をCSV出力しますか？

例えば、

顧客名

担当者

案件ステータス

契約日

都道府県

で検索できるようにします。

11．管理するデータを確認する

次に、

何を保存する必要があるか

を確認します。

質問例

現在Excelではどの項目を管理していますか？

必須項目は何ですか？

一意になる番号はありますか？

画像やPDFも保存しますか？

何年間データを保存しますか？

年間どの程度データが増えますか？

例えば顧客なら、

顧客ID

会社名

担当者

電話番号

メールアドレス

住所

営業担当

ステータス

などです。

12．帳票・CSVを確認する

業務システムでは後から追加されやすい項目です。

質問例

現在使用している帳票はありますか？

PDFで出力する必要がありますか？

Excel・CSVで出力しますか？

顧客へ送る帳票はありますか？

印刷が必要ですか？

既存帳票と同じレイアウトが必要ですか？

例えば、

見積書

請求書

納品書

在庫表

顧客一覧

売上CSV

などです。

既存帳票がある場合は実物を確認します。

13．外部システム連携を確認する

質問例

現在利用している他のシステムはありますか？

会計システムとの連携は必要ですか？

Google Workspaceを利用していますか？

Slack・Teamsとの連携は必要ですか？

決済サービスを利用しますか？

外部APIはありますか？

CSVでデータをやり取りしていますか？

例えば、

Webシステム
↓
会計システム

Webシステム
↓
Slack

Webシステム
↓
Gmail

などです。

外部連携は開発工数へ大きく影響するため、早い段階で確認します。

14．メール・通知を確認する

質問例

どのタイミングで通知したいですか？

誰へ通知しますか？

メールですか？

Slackですか？

システム内通知ですか？

通知しない方がよいケースはありますか？

例えば、

在庫10個以下

↓

倉庫管理者へメール

などです。

15．性能・利用規模を確認する

ここから非機能要件です。

質問例

利用者は何人ですか？

最大で何人が同時利用しますか？

データは何件ありますか？

1年後にはどの程度増えますか？

大量CSVを扱いますか？

何秒程度なら待てますか？

例えば、

ユーザー：
50名

最大同時接続：
20名

商品：
50,000件

CSV：
最大100,000件

などです。

16．利用時間・可用性を確認する

質問例

何時から何時まで利用しますか？

土日も利用しますか？

24時間利用する必要がありますか？

システムが止まると業務は止まりますか？

メンテナンス可能な時間帯はありますか？

例えば社内管理システムなら、

平日
8:00〜20:00

で十分かもしれません。

一方、ECサイトなら24時間利用が前提になります。

必要以上の可用性を求めると費用も増えるため、業務上必要なレベルを確認します。

17．セキュリティを確認する

質問例

個人情報を扱いますか？

機密情報を扱いますか？

社外からアクセスしますか？

IP制限は必要ですか？

多要素認証は必要ですか？

操作履歴を残す必要がありますか？

データを閲覧できる人に制限はありますか？

例えば、

顧客個人情報

従業員情報

契約情報

決済関連情報

を扱う場合は、早い段階で伝えます。

18．バックアップ・ログを確認する

質問例

データを誤って削除した場合、
どこまで戻せる必要がありますか？

バックアップは何日分必要ですか？

操作履歴は必要ですか？

誰が変更したか確認する必要がありますか？

例えば、

在庫数：
誰がいつ変更したか記録

が必要なら、監査ログ機能が必要です。

19．対応端末を確認する

質問例

PCで利用しますか？

スマートフォンでも利用しますか？

タブレットは必要ですか？

Windows・Macの両方ですか？

特定ブラウザの指定はありますか？

現場でバーコードリーダーを使いますか？

例えば、

倉庫：
タブレット

本社：
PC

なら両方を考慮したUIが必要です。

20．既存データの移行を確認する

データ移行は要件定義で忘れやすい項目です。

質問例

現在のデータはどこにありますか？

Excelですか？

既存システムですか？

何件ありますか？

何年分移行しますか？

不要なデータはありますか？

データの重複はありますか？

例えば、

顧客：
20,000件

過去案件：
100,000件

Excel：
30ファイル

なら、移行だけでも大きな作業になります。

21．運用方法を確認する

システム完成後の運用も要件です。

質問例

ユーザー追加は誰が行いますか？

マスタ変更は誰が行いますか？

問い合わせ窓口は誰ですか？

障害時は誰へ連絡しますか？

退職者のアカウントは誰が削除しますか？

データ修正は誰が行いますか？

例えば、

ユーザー登録
→ 自社管理者

障害対応
→ 開発会社

商品マスタ
→ 業務担当

とします。

22．予算を確認する

予算を聞きにくいと感じることもありますが、要件整理では重要です。

質問例

今回の開発予算はどの程度を想定していますか？

予算上限はありますか？

初期費用と月額費用を分けて考えていますか？

保守・運用費も想定していますか？

予算が、

50万円

なのか、

500万円

なのかで提案内容は大きく変わります。

限られた予算なら、

初回リリース

↓

追加開発

と段階的に開発する方法もあります。

23．希望納期を確認する

質問例

いつまでに利用開始したいですか？

その日付に理由はありますか？

絶対に動かせない期限ですか？

段階的なリリースは可能ですか？

例えば、

10月1日

という希望でも、

新店舗オープン日

なら固定期限です。

一方、

できれば10月

なら調整できるかもしれません。

期限の背景まで確認します。

24．優先順位を確認する

すべての要望を実装できるとは限りません。

質問例

絶対に必要な機能は何ですか？

なくても業務できる機能はありますか？

将来追加でも問題ないものはありますか？

この中で一つしか作れないならどれですか？

例えば、

Must
・顧客管理
・案件管理

Should
・CSV

Could
・ダッシュボード

Later
・AI分析

と整理します。

25．今回やらないことを確認する

非常に重要です。

質問例

今回の開発対象外にするものはありますか？

既存システムで継続する業務はありますか？

将来対応に回す機能はありますか？

例えば、

今回

○ 顧客管理
○ 案件管理
○ 対応履歴

対象外

× 請求
× 会計
× AI分析

と明記します。

「含まれると思っていた」という認識違いを防げます。

【コピペ用】要件定義ヒアリングシート

実際の打ち合わせでは、次のチェックリストを利用できます。

【開発背景】

□ なぜシステム開発を検討していますか？

□ 現在どのような問題がありますか？

□ なぜ今システム化する必要がありますか？


【目的】

□ 最も改善したいことは何ですか？

□ システム導入後、どうなれば成功ですか？

□ 数値目標はありますか？


【現状業務】

□ 現在の業務フローを教えてください

□ 誰が担当していますか？

□ Excel・紙・既存システムを使っていますか？

□ 二重入力はありますか？

□ 現在使用している資料を見せてもらえますか？


【課題】

□ 最も時間がかかる作業は何ですか？

□ ミスが多い作業は何ですか？

□ 属人化している業務はありますか？

□ 繰り返し作業はありますか？


【例外】

□ キャンセル時はどうしますか？

□ 修正時はどうしますか？

□ 承認されない場合はどうしますか？

□ 通常と異なる処理はありますか？


【利用者】

□ 誰が利用しますか？

□ 何人利用しますか？

□ 社外ユーザーも利用しますか？


【権限】

□ 管理者と一般ユーザーの違いは？

□ 部署ごとに閲覧制限がありますか？

□ 削除できるのは誰ですか？


【機能】

□ どの情報を登録しますか？

□ 何を検索しますか？

□ CSV・PDFは必要ですか？

□ 通知は必要ですか？

□ 承認機能は必要ですか？


【データ】

□ 管理するデータは何ですか？

□ 現在何件ありますか？

□ 年間どの程度増えますか？


【外部連携】

□ 他のシステムと連携しますか？

□ API・CSV連携がありますか？

□ Google Workspace・Slack等を利用していますか？


【非機能】

□ 利用人数は？

□ 利用時間は？

□ 個人情報を扱いますか？

□ バックアップは必要ですか？

□ 操作ログは必要ですか？

□ PC・スマホどちらで利用しますか？


【移行】

□ 既存データはありますか？

□ 何件ありますか？

□ 何年分移行しますか？


【運用】

□ 誰がユーザーを管理しますか？

□ 問い合わせ窓口は誰ですか？

□ 障害時は誰へ連絡しますか？


【予算・納期】

□ 予算はいくらですか？

□ 希望リリース日は？

□ その日付に理由はありますか？


【優先順位】

□ 絶対に必要な機能は？

□ 将来追加でもよい機能は？

□ 今回対象外にするものは？

要件定義ヒアリングの進め方

質問項目を用意しても、上から読み上げるだけでは良いヒアリングにはなりません。

おすすめは次の順番です。

1．背景

↓

2．目的

↓

3．現在の業務

↓

4．課題

↓

5．新しい業務

↓

6．必要機能

↓

7．データ・権限

↓

8．非機能・移行・運用

↓

9．予算・納期

↓

10．優先順位

特に重要なのは、

現在の業務
↓
課題
↓
新しい業務
↓
機能

という順番です。

最初から「どんなシステムが欲しいですか？」と聞かない

例えば、

予約管理システムが欲しい

と言われても、そのまま機能設計へ進まない方がよいでしょう。

まず、

現在予約はどう管理していますか？

と聞きます。

すると、

Googleフォーム

↓

Excel

↓

担当者が残席計算

↓

満席になったらフォーム停止

という業務かもしれません。

この業務を理解すれば、

予約受付

定員管理

残席表示

満席時受付停止

予約一覧

が必要だと自然に分かります。

つまり、

システムの答えを顧客に聞くのではなく、業務を聞いて必要なシステムを一緒に考える

ことが重要です。

要件定義ヒアリングで使える深掘り質問

ヒアリングでは、次の質問が特に有効です。

「なぜですか？」

例えば、

CSVが欲しいです

に対して、

なぜCSVが必要ですか？

と聞きます。

「現在はどうしていますか？」

例えば、

承認機能が欲しい

に対して、

現在はどのように承認していますか？

と聞きます。

「それができないと何が困りますか？」

優先順位が見えます。

「誰が使いますか？」

権限・画面・操作方法が見えてきます。

「どのくらいの頻度ですか？」

例えば、

年1回

しか使わない機能と、

1日500回

使う機能では重要度が違います。

「通常と違うケースはありますか？」

例外処理を見つけられます。

ヒアリング内容はその場で認識合わせする

要件ヒアリングでは、

聞く
↓
メモする
↓
後で整理

だけでは、認識違いが残る可能性があります。

例えば、

つまり現在は、

営業担当がExcelへ入力し、
事務担当が販売システムへ再入力している、

という理解で合っていますか？

とその場で確認します。

この、

要約
↓
相手に確認

を繰り返すと認識違いを減らせます。

要件定義ヒアリングでよくある失敗

失敗1｜欲しい機能だけ聞く

最もよくある失敗です。

どんな機能が欲しいですか？

だけではなく、

現在の業務

課題

目的

から確認します。

失敗2｜管理職だけに聞く

実際に操作する現場担当者にもヒアリングします。

管理者が認識している業務と、現場の実態が違う場合があります。

失敗3｜通常ケースだけ聞く

キャンセル・修正・返品・エラーなどの例外を確認します。

失敗4｜現物を見ない

Excel、紙、帳票、既存システムを可能な範囲で確認します。

「Excelで管理しています」という一言でも、実際に見ると20シート・複雑なマクロ・色分けなど、多くの業務ルールが隠れていることがあります。

失敗5｜専門用語を使いすぎる

顧客へ、

非機能要件はどうしますか？

RTOは？

RBACは？

と聞いても伝わらない場合があります。

例えば、

システムが止まった場合、
何時間以内に復旧する必要がありますか？

など、業務の言葉へ変換します。

失敗6｜その場で解決策を決めすぎる

ヒアリング中に、

それなら○○機能を作りましょう

とすぐ決めると、後から別の解決策が見つかる場合があります。

一度、

課題

要求

制約

を持ち帰って整理することも重要です。

失敗7｜予算を確認しない

要望をすべて整理した後に、

予算は30万円です

と分かると、要件を大幅に見直す必要があります。

予算・希望時期は比較的早い段階で確認しておきます。

初回ヒアリングで全部決める必要はない

要件定義というと、

1回の打ち合わせで
全部聞かなければならない

と思うかもしれません。

実際には、

初回
↓
背景・目的・業務

2回目
↓
機能・画面

3回目
↓
データ・権限

4回目
↓
非機能・移行・運用

5回目
↓
全体確認

のように複数回に分けることもあります。

むしろ、業務システムでは一度聞いた内容を整理し、

業務フロー

機能一覧

ワイヤーフレーム

などにして見せることで、新しい要件が見つかることがあります。

ヒアリング後に作成したい成果物

ヒアリング結果は、そのままメモで終わらせず整理します。

例えば、

開発目的

業務フロー

課題一覧

要求一覧

機能一覧

画面一覧

権限一覧

データ一覧

非機能要件

対象外

未決事項

などです。

これらを最終的に要件定義書へまとめます。

特に、

未決事項

は明確にしておきます。

例えば、

ID	未決事項	担当	期限
Q01	CSV形式	業務担当	8/10
Q02	データ移行範囲	管理者	8/15
Q03	メール通知方法	開発会社	8/20

という形です。

要件定義ヒアリングに関するよくある質問

要件定義のヒアリングは誰にするべきですか？

システムによって異なりますが、

業務責任者

実際の利用者

管理者

経営・決裁者

情報システム担当

などが候補です。

特に実際にシステムを操作する人への確認が重要です。

初回ヒアリングでは何を聞けばよいですか？

まず、

開発背景

目的

現在の業務

課題

利用者

予算

希望時期

を中心に聞きます。

詳細な画面・データ項目まで初回で確定させる必要はありません。

顧客が必要な機能を説明できない場合はどうしますか？

現在の業務を聞きます。

現在どのような手順ですか？

何が面倒ですか？

どこでミスが発生しますか？

誰から誰へ情報を渡しますか？

と確認すると、必要なシステム機能が見えてきます。

ヒアリングシートは事前に送るべきですか？

事前に送る方法も有効です。

ただし、すべてを顧客自身に記入してもらうのではなく、

事前回答
+
打ち合わせで深掘り

とする方が具体的な情報を得やすくなります。

ヒアリング時間はどのくらい必要ですか？

対象業務によります。

小規模システムでも初回は60〜90分程度確保し、その後必要に応じて追加ヒアリングを行う方法があります。

一度の長時間会議で全部決めるより、テーマを分けた方が整理しやすい場合があります。

hiro-dev-labの要件定義・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなくヒアリング・要件整理から対応しています。

例えば、

現状業務のヒアリング
Excel・既存システムの確認
業務フロー整理
課題の洗い出し
システム化範囲の整理
機能要件の整理
画面・ワイヤーフレーム整理
データ項目整理
権限設計
非機能要件整理
外部システム連携の検討
Java・Python・TypeScriptを利用したWebシステム開発

などを検討できます。

例えば、

現在

Excelへ入力
↓
メールで共有
↓
別担当者が転記
↓
月末に集計

という業務であれば、

ヒアリング

↓

現在の業務フロー整理

↓

課題の洗い出し

↓

新しい業務フロー検討

↓

必要機能を定義

↓

設計・開発

という順番で進めます。

要件定義ヒアリングで重要なのは「機能を聞くこと」ではなく「業務を理解すること」

要件定義のヒアリングで、

どんな機能が欲しいですか？

と聞くこと自体は間違いではありません。

しかし、それだけでは本当に必要なシステムは見えてきません。

重要なのは、

なぜシステム化したいのか

現在どう仕事をしているのか

どこに問題があるのか

誰が困っているのか

どういう状態に変えたいのか

を理解することです。

そのうえで、

業務

↓

課題

↓

要求

↓

機能

へ落とし込みます。

要件定義のヒアリングでは、次の順番を基本にすると整理しやすくなります。

1．開発背景を聞く

2．目的・ゴールを確認する

3．現状業務を聞く

4．課題を洗い出す

5．例外業務を確認する

6．利用者・権限を確認する

7．新しい業務フローを整理する

8．必要機能を定義する

9．データ・帳票・外部連携を確認する

10．非機能要件を確認する

11．移行・運用を確認する

12．予算・納期を確認する

13．優先順位・対象外を決める

「システム化したいが、必要な機能が整理できていない」

「既存ExcelをWebシステムへ移行したい」

「顧客への要件ヒアリングから支援してほしい」

「業務整理から設計・開発までまとめて相談したい」

といった段階からでも、要件整理を進めることができます。

要件定義・業務システム開発について相談する