dbSheetClient要件定義
先月、福岡に出張しました。
宿泊した博多は、食べ物が美味しくて、人情の厚い街です。
この街で、旅の疲れを癒すため、以前から興味があったタイ古式マッサージの施術を受けてみました。
アロマの香る部屋で、ゆったりとしたテンポで、関節＆筋肉がストレッチされます。
すると、末梢の血流が盛んになり、心身ともに、リフレッシュされました＾＾
さて、今回は、記念すべき１００回目の記事となります。
気がつけば、４年の月日が流れました＾＾；
要件定義とは
要件定義とは、システム開発において、ユーザーのニーズを明確にし、必要な機能や条件を具体的に定義するプロセスです。
一般的に、以下のようなステップで進めていきます。
① 要件収集：ユーザーへのヒアリングで、ニーズや期待を理解する。
② 要件分析：収集した要件を分析し、矛盾や重複を排除し、必要なものを整理する。
③ 要件仕様書作成：分析結果を文書化し、明確な仕様書としてまとめる。
④ 要件確認：ユーザーと仕様書を確認し、合意を得る。
要件定義は、プロジェクトの成功にとって非常に重要なフェーズであり、この段階での不備や誤解は、後の開発プロセスや最終成果物に大きな影響を与える可能性があります。
要件定義書の構造
要件定義書は、次のような構造を持っています。
① 表紙と目次
表紙には、プロジェクト名、作成日、作成者、バージョン番号を記載します。
目次には、各セクションのページ番号を記載し、全体の構造を明確にします。
② プロジェクトの概要
プロジェクトの背景と目的、プロジェクト対象範囲、プロジェクト進行における前提条件を記載します。
③ 部署・役割別の要件
部署・役割の一覧を作成し、それぞれのニーズや期待を具体的に記載します。
④ 機能要件
システムが持つべき機能一覧を作成し、各機能の詳細を記載し、どのように動作するかを説明します。
⑤ 非機能要件
システムの性能に関する要件（例：応答時間、処理速度）、セキュリティに関する要件（例：アクセス制御、データ保護）、システムの運用に関する要件（例：稼働時間、保守性）を記載します。
⑥ データ要件
システムで使用するデータベースの構造、データの流れを示します。
⑦ ユーザーインターフェース要件
主要な画面やインターフェースの設計、ナビゲーションやアクセシビリティなどの使いやすさに関する要件を記載します。
⑧ 制約条件
使用する技術やシステム環境に関する制約、法令や規制に関する要件を記載します。
⑨ リスクと対策
プロジェクトにおけるリスクを特定し、優先順位を付け、リスクへの対策を記載します。
⑩ 付録
用語集（専門用語や略語の定義）、参照文献（参考にした資料や文献の一覧）を記載します。
要件定義書は、プロジェクト全体の指針となる重要な文書です。
ユーザーと密接に連携し、正確かつ詳細に記載することが求められます。
dbSheetClient要件定義書
要件定義書は、ITベンダーとユーザー企業の情報システム部がシステム開発内容について合意する文書です。
内製化を推進する企業では、社内開発者が、社内ユーザーに向けて要件定義書を作成することになります。
社内ユーザーは、システム開発の専門家ではないので、要件定義書に目を通しても、システムの完成形をイメージしづらいと思います。
社内ユーザー向け要件定義書の作成作業は、かなりハードルが高いのではないでしょうか。
dbSheetClientは、要件を定義するプロセスで圧倒的なポテンシャルを持っています。
dbSheetClientは、メニュー、ボタン、Excelシートのサンプルを使って、短時間で、あたかもシステムが完成したように見せることができるからです。
専門家ウケする機能一覧よりも、実際に動く画面は、ユーザーの期待を大きく膨らませ、同時に大きなズレなく仕様の詰めが完了します。
こんな開発ツールは、他にないでしょう。
要件定義書のポイント
プロトタイプによるデモンストレーションは、ユーザーとの要件定義合意に有効な手段です。
しかし、最終的には、要件を文書化しないと、ユーザー組織内で広く合意形成することは、困難です。
文書化において、まず、大切なことは、「部署・役割別の要件」です。
システム利用者が抱えている課題とその解決への道筋を明確に言語化することです。
課題やニーズは、システム利用者の部署、役割ごとにまったく異なります。
例えば、営業部門と経理部門、担当者と課長では、課題やニーズが異なります。
課題やニーズを部署、役割に分けて言語化して、要件定義書に記載します。
次に、重要なのは、「機能要件」と「ユーザーインターフェース要件」です。
具体的には、データ入力手順、主要帳票の様式と出力手順です。
dbSheetClientでプロトタイプを作成すると、システムの操作手順書が時間をかけずに作成できます。
操作手順書は、プロトタイプの画面ハードコピーを活用します。
プロトタイプでは、データベースと連携させる必要はありません。
データベースと連携しないプロトタイプは、ユーザー要望を反映して修正する作業負荷が軽減されます。
また、作成したプロトタイプは、要件合意後も無駄にならず、システム開発の工数を削減することができます。
特に、すり合わせを行なったデータ入力画面や出力様式のExcelシートが使えるのは、非常に大きなメリットです。
データベースと連携しないプロトタイプ作成ノウハウは、別の機会に紹介したいと思います。
非機能要件
最近、オンプレミスではなくクラウドサービス利用でのdbSheetClient関連サーバー運用が増えています。
クラウドサービスでは、夜間稼働させるかどうかによって、契約料金が変わってきます。
２４時間稼働させるニーズの有無を確認して、コスト削減を検討します。
また、専任のシステム管理者を置けない場合は、いかに運用負荷を軽減できるか検討します。
具体的には、ユーザー保守（登録・抹消）を除き、dbSheetClient側でアクセス制御やデータ保護の保守作業ができる仕組みを検討します。
システム保守の最適化は、リリース後のシステム開発者の負担に影響を及ぼします。
利用ユーザーとシステム管理者の双方にメリットがある合意形成を目指しましょう。
皆さん本日もお疲れ様でした！
おやすみなさい（挙手）