スポンサーリンク

お客様との Access 要件定義時に聞くべき 10 のこと

スポンサーリンク
Access
スポンサーリンク

こんにちは、なかぜんです。Access や VBA に慣れ親しんだ皆さんなら、システムの要件定義は「ただ聞くだけ」ではなく、「どう聞くか」が大事なのをご存じですよね。特にお客様との打ち合わせでは「お互いの認識ギャップ」を埋めることが成功の鍵です。

この記事では、上級者の視点から「要件定義時に必ず聞いておきたい 10 の質問」を、納得感のある質問の意図とともにご紹介します。これを使えば、すぐに「やってみよう!」と思えるはずです。

スポンサーリンク

1.業務の目的・背景

まずは「なぜこの Access アプリを作りたいのか?」を明確にしましょう。

'' 質問例
「このアプリで最優先に解決したい業務上の課題は何ですか?」

この質問により、お客様の本質的なニーズ(例:集計の省力化、データの共有強化、ミス防止など)が把握できます。

2.ユーザーの想定範囲とスキル

誰が使うのか、どの程度のPCスキルを持っているかを確認します。

'' 質問例
「利用者は Access に詳しいですか?PC の基礎操作で困る方はいらっしゃいますか?」

スキルに応じて、操作画面の複雑さや補足説明の必要性を調整できます。

3.データ構造と入力フロー

どのようなデータをどんな流れで入力/登録していくのか?を明確にします。

'' 質問例
「どんな情報をいつ・誰が入力し、どこに保存しますか?」

テーブル設計やフォーム構成の土台となります。

4.データの更新頻度と運用体制

データはリアルタイムに更新するのか、定期的なバッチ更新かなどを確認。

'' 質問例
「データはいつ(リアルタイム?日次?)更新されますか?誰が更新しますか?」

これによりイベント処理や自動化の要件が見えてきます。

5.既存システムとの連携

他のシステムからデータを取ってきたり、出力したりする必要があるか確認。

'' 質問例
「Excel/CSV/データベースなど、他システムと連携はありますか?」

データ import/export や ODBC・DAO の選定にも影響します。

6.セキュリティ要件とアクセス制御

データの機密性や利用者ごとの操作制限などを把握します。

'' 質問例
「特定のユーザーにだけ見せたくないデータはありますか?ユーザーごとに機能制限は必要ですか?」

User-level セキュリティやフォーム制御が必要か判断できるようになります。

7.印刷や帳票出力の仕様

帳票やグラフの必要性と仕様を具体的に聞いておきましょう。

'' 質問例
「印刷したい帳票やグラフはどのようなレイアウト/ファイル形式ですか?」

プリンタ対応や PDF 出力を VBA で組み込む判断材料になります。

8.将来的な拡張想定

今は小規模でも、将来的に拡張する可能性もありますよね?

'' 質問例
「将来的に取り込みたいデータ量の増加や、新機能の追加予定はありますか?」

スケーラビリティやリファクタリングを念頭に置いた設計が可能になります。

9.エラーハンドリングと運用サポート

障害時やデータ異常時の対応フローを確認しましょう。

'' 質問例
「予期せぬエラーやデータ異常が起きたとき、通知や復旧方法はどのようにしますか?」

トランザクション制御やログ出力、エラーメッセージ設計に活きます。

10.導入・維持の体制と期限

いつまでに誰が導入し、その後のメンテはどうするか明確にします。

'' 質問例
「希望納期はいつですか?導入後の運用/改修はどなたが担当されますか?」

納期管理や保守契約の範囲が明確になり、プロジェクトの成功率が高まります。

実際のコード例と画面イメージ

上記の要件定義を踏まえて、「ユーザーごとにフォームの表示内容を変える」例をご紹介します。

【コード例:フォームの Load イベントで権限に応じた表示制御】

Private Sub Form_Load()
    Dim userName As String
    userName = CurrentUser()
    ' 仮に「Manager」「Staff」で分けるとします
    If userName = "Manager" Then
        Me.営業部データ列.Visible = True
        Me.社員コード入力.Enabled = True
    ElseIf userName = "Staff" Then
        Me.営業部データ列.Visible = False
        Me.社員コード入力.Enabled = False
    End If
End Sub

このコードは、「Manager(管理者)」には営業部データの列を見せつつ入力も許可し、「Staff(一般)」には非表示かつ入力不可にしています。フォーム設計におけるユーザーごと表示制御の具体例として使えます。

画面イメージ(説明)

  • フォーム上部に「ログインユーザー名」を表示
  • 営業部データを表示する一覧/それ以外はグレーアウトまたは非表示に
  • 入力欄の有効/無効が明確に分けられている

注意点やよくあるミス

  • 「想定していたユーザー」と違う役職や権限の人が実際に使うことがあるので、ユーザー層はしっかり確認する。
  • 将来の拡張を考えずに設計すると、あとで改修が大変になることも。
  • 印刷レイアウトは詳細仕様を聞かないと、「思ってたのと違う」となりやすい。
  • エラー時に VBA が止まるだけで通知もフォローもない構成にしないように。
  • 要件定義時に「今は職員5名だから」と聞くと、その先増えたときに処理性能に問題が出る可能性あり。

応用ポイント

上記を基に以下のような工夫も可能です:

  • ユーザーの役割ごとに設定ファイル(テーブル)に権限レベルを持たせて、DAO/ADOで動的制御する。
  • エラー時にはメール自動通知やログ保存・ダッシュボードに表示させて、運用を安心・効率的に。
  • 将来的には Access → SQL Server や Web フロントに移行する前提で、テーブル構成を汎用的に設計しておく。
  • 帳票作成に Crystal Reports や PDF SDK を組み合わせて柔軟性を高める。

まとめ

今回ご紹介した「要件定義で聞くべき 10 の質問」は、

  • 業務の背景と目的
  • ユーザー像とスキル
  • データ構造/更新フロー
  • 連携や印刷ニーズも含めた具体的な運用要件
  • 保守、エラー対応、将来展開まで見据えた設計の視点

これらが揃うことで、Access アプリの開発は「思っていた通り」実務にフィットし、「自分でもできそう」と感じられるものになります。

次のステップとしては、実際の要件をひとつひとつフォーム化し、プロトタイプを作ってお客様と確認していくフェーズですね。ぜひ一緒に進めていきましょう!

なかぜんでした。