WebFamil システム開発手法であるウォーターフォールでは要件定義を行います。要件定義の役割とシステム開発における重要性を説明します。
要件定義とは
要件定義とはシステム開発における工程の一つで、一番最初の工程となります。
要件定義
外部設計
内部設計
製造テスト
結合テスト
システムテスト
ユーザテスト
導入
システムがどのような目的でどのような機能を満たすのかをユーザと認識を合わせる工程となります。この工程ではユーザのシステム開発目的をしっかり理解し具体的に構築するシステム機能を提案する必要があります。
構築する機能数によって見積りが変わりますので、ここの工程ではユーザとしっかり意思統一を図り、どれほどの機能が必要とするのかズレがないように打ち合わせを何度も行います。
要件定義工程で必要な資料
客先によって異なりますが、今まで経験した客先で利用していた資料の一覧になります。各資料ごとに意味があるものとなりますので手を抜かずにしっかり資料作成することが重要です。
要件定義書
システムを構築する背景から目的、対応方針や対応内容を記載します。
背景や目的は簡単に書きがちですが、なぜ今回システム構築をする必要があるのか、システム構築することでどのような目的を達成する必要があるのか、とても重要な情報となりますのでここはしっかりヒアリングをした上で記載する必要があります。
対応方針や対応内容は記載軸があいまいになりがちですが、以下に例文を記載します。
対応方針：〇〇システムとデータ連動する
対応内容：当システムの△△データを日次で〇〇システムにHULFTを利用してファイル連動する。
業務フロー
お客様の業務単位で業務関係者のそれぞれの処理をフローで表現します。フローに示すことで各関係者がどの時間軸でどんな作業をするのか明確にすることを目的としています。
例：日報管理システム構築時の業務フロー
テスト要件書
システム構築におけるテストをどのようなテストをどのような時期におこなうのか明確にします。
単体テストよりも結合テストやシステムテストでのテスト方針がメインとなります。
テストをするために関連システムやユーザへ依頼事項があればここで頭出しを行います。
後続工程ではテスト内容をより詳細に記載するテスト計画書を作成します。
移行要件書
システムリリース時の移行方針について記載します。
一括移行や段階移行など移行方法はさまざまとなりますので、ここで明確にしておきます。
移行をするために関連システムやユーザへ依頼事項があればここで頭出しを行います。
後続工程では移行内容をより詳細に記載する移行計画書を作成します。
機能一覧
システム構築で具体的に作成する画面・帳票を整理します。また各機能の概要を記載します。
見積もりを出すときは機能数から算出することも多く、ここでしっかり機能を整理することでシステムの規模を把握することができます。
画面や帳票を作成するためにはバッチ機能も必要となりますので、バッチの機能一覧も忘れずに作成しましょう。
入出力定義書
各画面ごとの役割、画面イメージを作成します。帳票であれば帳票イメージを作成します。
外部設計で整理することもできますが、要件定義で入出力項目を整理しておくことで外部設計では入力項目以外の入力チェックや処理内容についてしっかり検討することができます。
要件定義をするために必要なスキル
要件定義ではお客様の業務をしっかりドキュメント化する必要があります。
お客様業務を理解しておく必要があるのはもちろん、システム化における機能の想像力も大切です。
お客様は要件を全て説明しきれない、またはシステムを前提に話すことは難しいということもあり、言われたことをそのままシステム化するとシステムテスト当たりで仕様変更が起きたりします。
要件定義での仕様漏れはお客様が言ってないから漏れるのか、お客様からすると当たり前すぎてシステム側で漏れるのか判断はとても難しいこともあります。
システム側としては言われたことをシステム化するのではなく、頭の中で処理フローを考えたときに必要な処理をイメージしてお客様へ提案することができると要件定義は充実してきます。
またシステム処理だけではなく、帳票出力後の業務やデータを他システムへ連携したあとの業務をしっかりヒアリングすることでより保守性の高いシステムを構築することができます。
スキルを身に付けるためには、、、
お客様と業務の話をするため業務知識は必須です。もしここの知識が足りない場合は業務のことをよく勉強しましょう。
業務知識の高さ＝要件定義の品質、ではありません。
ドキュメント作成力も必要です。冗長的な文章にならないようわかりやすく必要な情報のみを記載します。またフロー図などを作成する場合は一目でわかりやすくなるような資料作りをすることが必要です。
ドキュメントは従来作成された資料をよく見ましょう。よく見て資料の目的となる情報を読み取り、資料の構成を把握します。そうすることで自分にもドキュメントの雛型イメージが頭の中にインプットされますので同じような情報をドキュメント化する場合には雛型イメージを利用します。そのまま作成するのではなくその時の状況に則すように自分にアレンジを加えることでさらに良い雛型イメージになります。
最後に思考と裏付けです。なぜこのような機能が必要なのか、ユーザにいわれたからそのまま作成するのではなく機能意味を考えその裏付けをユーザに確認することです。そうすることでそれぞれの機能の意味が理解でき、全体をみたときに充足しているのか考えやすくなります。
これは普段の仕事からできることで指示されたことをやるだけではなく自分でも思考して作業に取り組むことです。思考だけではな思い込みによる予期せぬ仕様になることが多いので有識者に確認する、または他の資料と複合的に確認することで辻褄合わせをすると思考と裏付けのクセがつくようになり、要件定義でも活かせます。
まずは現場働こう！
要件定義はお客様ありきの作業であることから机上で勉強することはとても難しいです。
まずは現場に出ましょう。現場で作業をコツコツ積み上げていくことで詳細設計→基本設定→要件定義とだんだんステップアップしていくことが可能です。要件定義はやりたくてもいきなり参画することは難しいのでまずは下流工程の作業から一つずつ理解し実績を残して周りのメンバーに認めれるようになるのが要件定義への近道かと思います。