ITパスポート 2009年 秋期 問29

現行システムを全面開発し直すときの利用部門との関わり方【ITパスポート 解説】

正解の理由

• 要件定義：システムに必要な機能や条件をはっきりさせる作業。英語では「requirements definition」。
• レビュー：作成した文書や設計を見直し、誤りや不備を指摘・改善する活動。

解法ステップ

1. 状況把握：現行システムの利用状況と、業務がどう変化したかを整理する。利用部門（現場担当者）の声を聞く。
2. 要件抽出：業務に必要な機能やルールを利用部門と対話して書き出す。ここでの出力が「システム要件」。
3. レビュー（共同確認）：開発者と利用部門が一緒に要件を確認し、誤解や抜けを洗い出す。意見が分かれれば調整する。
4. 合意形成：レビューで修正した要件に対して、利用部門が承認（合意）する。承認があれば次の設計・開発に進む。
5. トレーサビリティ確保：要件から設計・テストまで対応が追えるようにして、要件どおりに作られているかを検証できるようにする。

選択肢別の誤答解説

• ア: 客観的に対象業務を分析するために、システム利用部門とかかわることは避ける。
  誤り。利用部門と関わらないと、業務の実情や変化を正確に把握できません。結果として、業務に合わないシステムになり、運用開始後に手直しや追加開発が必要になります。
• ウ: システム利用部門の意見は参考であり、システム要件は開発者が決定する。
  誤り。開発者だけで決めると、業務視点が欠けます。利用部門の承認がない要件は受け入れられず、現場が使えないシステムになる危険があります。開発と業務は共同で決めるべきです。
• エ: システム利用部門の作成した現行システムの操作マニュアルを基に、要求される機能を決定する。
  誤り。操作マニュアルは「今ある使い方」を示す資料ですが、業務が変化していれば古いマニュアルの方法そのままでは不適切です。マニュアルは参考にできますが、利用部門と対話して現在・将来の業務要件を確認する必要があります。

よくある誤解

1. 「利用部門の意見を全部そのまま採用すればよい」
   誤解です。利用部門の意見は重要ですが、技術的制約やコスト、優先順位を踏まえて調整する必要があります。共同レビューで妥当性を検討します。
2. 「レビューは形式的に行うだけで十分」
   レビューを形だけで済ませると、重要な抜け漏れを見逃します。具体例や業務フローを使って実際の操作を想定しながらレビューすることが重要です。

補足コラム

• ワークショップ形式で実際の業務フロー（紙やホワイトボード）を使いながら議論する。
• プロトタイプ（簡単に作った試作品）を利用して、利用部門に触ってもらう。言葉だけの確認より誤解が減ります。
• 合意した要件には「受け入れ基準（受入テストの条件）」を付けて、完成時に利用部門が検証できるようにする。受け入れ基準は「いつ・誰が・何をもって合格とするか」を明確にします。

• プロトタイプ：本番の前に作る試作品。使い勝手を早く確認するために用いる。

FAQ