だまし絵を描かないための－－要件定義のセオリー

赤俊哉

システム開発プロジェクトにおいては、「無意識のうちに騙（だま）し絵を描いてしまわないように注意する必要がある」と筆者は考えています。要件を定義する際、自分が「騙し絵を描いている」ことに気づかないまま後工程に進んでいくと、騙すつもりはなくても、システムにからくりを仕込んでしまうことになりかねません。また逆に、騙し絵が描かれていることに気づかないまま 後工程に進んでいくと、「からくりに気づいた時には既に遅い」という事態に陥ります。
筆者は、騙し絵が原因となって難航した開発プロジェクトを数多く見てきました。それほどにビジネス・業務・システムの無数の色合いを「要件として明確化する」ことは困難な作業なのです。
本書では読者の皆様と、そんな困難な作業に、できる限り少ない労力で立ち向かうための術を、共有したいと考えています。奥深い要件定義について、一緒に学んでいきましょう。 （本書「まえがき」より）

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 全般
• 出版社: リックテレコム
• タイトル: だまし絵を描かないための－－要件定義のセオリー
• タイトルID: 20026962
• 電子版発売日: 2020年08月20日
• コンテンツ形式: EPUB
• サイズ(目安): 8MB

[ブクログ · ★★★☆☆]

冗長な表現、同じようなことをあちこちで語り直す、という感じは否めないのと、肝心の図式が抽象的すぎて、正直あまりわからない。。と、初心者は思うと思う。が、ある程度やってきてて、我流の棚卸し的に振り返る目的で読むと、言ってることのイメージわくのと、結構自分がやってきてる方法とまんま近いとこもあったので、すーっと流し読みでも満足度あった。

[ブクログ · ★★★★☆]

業務システムの要件定義を行うにあたって初心者ベースで非常にわかりやすい。


○ 1 要件定義とは
要求分析と要件定義の作業
1．じっくりと時間をかけて要求を明確化し、ToBeビジネスモデルを検討する。
2． 明確化された要求を基に、ToBe（あるべき）プロセスモデル(業務プロセス手順の図解)とToBe概念データモデル(管理すべきデータと、データの構造を図解したもの)を作成
3. Aslsモデルを検証。（ここまでが要求分析）
4. Aslsモデルを参考にして、人、モノ、金等のプロジェクトとして意識せざるをえない制約を考慮しつつToBeの実現可能性を検討
5.実現可能性が低いと判断されたら、ToBeを修正
6. Aslsから新ToBeモデルへ至るプランを策定

要求(欲しいもの)と要件(要るもの)を明確に区別する

上流工程は、システムのプロと業務のプロとが相互翻訳を行いシステム構想を作り上げる工程

要件定義はトップダウンで骨組み、ボトムアップで肉付けがセオリー

○ 2 要検定後の前段
・ウォーターフォール型で手戻りは認めないために、90点の要件定義を100点にするためにリソースを注ぎ込むより、変更発生時に遡って反映できるようにトレーサビリティを高めておくことで手戻りコストを抑制することは得策。
・アジャイル開発においては、新しい価値を生み出すプロセスであり要件は固まらないという限定があるものの、その上での最低限の要件の明確化は必要
・アジャイル工程の考え方は①要件定義、設計、実装をいきなり繰り返すもの、②要件定義を前半できちんと行ってから繰り返すもの、があるが本書は②をとる
・要件定義と基本設計は一般に別工程として分けられるが、同時に行った方が効率性は抜群に高まる


○ 3 ビジネス要求の整理
* 目的の明確化
* 目的
* 対象
* 効果　定性、定量、投資回収期間
* 新システムイメージ
* システム以外の組織、役割イメージ
* システム化計画
* 新業務イメージの図示
* Tobeモデルの作成
* プロセスモデルとデータモデルを詳細に図示

要求を三種に分類
1. 「ビジネス要求」＝トップダウンの要求
2. 「業務要求」＝業務レベルの要求
3. 「システム要求」＝システムレベルの要求

4-1 要求明確化の手順
* step 1 ビジネス要求、業務要求を把握する
* システム化企画、ToBe モデルから、「ビジネス要求」を抽出
* 「ビジネス要来」から「薬務要求」へのブレイクダウン(各部署や現場の要求を取り込み)
* ToBe モデル、プロセスモデル、データモデルに反映
* Step 2要求の発生源を明確にする
* 現場からの要求度合いが強い「業務要求」の発生部門と担当者を明確化
* 経営課題の解決につながるものを優先事項としてチェック(業務要求から遡りビジネス要求との整合性をチェックし、ビジネス要求たりうるものを優先とする)
* Step 3要求の背景にある課題・問題点を明確にする
* 要求の背景を認識し、課題や問題点を明確にする。「ビジネス要求」と「業務要求」について、要求が発生した原因や理由を明らかにする
* Step 4 システム要求への落とし込み
* 「ビジネス要求」と「業務要求」のうち、優先順位を参考にして「システム要求」への落とし込み
* 経営視点、現場視点、システム視点と多方面からの検討
* システム要求を基に必要なUI、機能／非機能への対応を検討
* Step 5要求のランク付け
* 重要度合いを5段階にランク付け
- 経営およびビジネスに与える影響の大きさ
- 緊急度
- 課題解決に要する規模など
* 総合的なランクを決定
* 改めて、優先順位の高い要求のUI、機能／非機能について多面的に検討
* Step 6要求の階層化を整理する
* 要求の分類、ブレイクダウンの整合、トレーザビリティ可能か、ToBeモデルが各要求を反映しているか確認
* ビジネス要求は不変、業務要求レベル、システム要求レベルの修正の場合、ビジネス要求との整合性をとりつつ、速やかにシステム要求を明確化

4-2 システム全体図
・制約を踏まえて要件を確定させる。
・要件化された開発対象を、外部接続形態と共に認識するためのもの

4-3 業務フローの明確化
・ブレイクダウンされた業務要件を表すフロー図を作成
・やかりやすさを軽視しない
・人が行う処理、システムが行う処理を明確に区別、レーンを仕切るのも良い

4-4 業務プロセスの定義
・以下の5W2Hを定義すること
* When いつ→実施タイミング（事前／開始条件含む）
* Where どこで→場所、組織
* Who 誰が→担当者、ユーザー
* What 何を→対象データ
* Why 何のために→目的、狙い
* 当該プロセスが完了した時点で達成される目的と事後条件（プロセス完了時に達成できていること）、を含む
* How どのようにして→実施要領（制約条件含む）
* ユースケース記述まで書くのが望ましいが、シナリオ（手順）までは最低でも把握可能なレベルで記述）
* How many どれくらい→ データ量、時間
・開始条件、制約条件、前提条件の3つを持つとも捉えられる

4-5 UI・機能要件の明確化
* UIの基本形
* 検索
* 参照表示
* 選択
* 入力
* 実行
* 結果表示
* 画面遷移
* UIにおけるデータ操作: CRUD
* 生成　Create
* 参照　Read
* 更新　Update
* 削除　Delete
・UIは機能を実現するために存在するため、併行して定義すべき、ただしバッチ処理は例外
・機能の主な役割はデータ操作
・プロトタイプはUIを決める上で有益だが、業務フロー、業務プロセス、5W2Hがある程度明確になってから。機能が肥大化する懸念あり

4-6 データ要件の明確化
・ER図でエンティティ(SFのオブジェクト)とリレーションの関係を定義
・IE記法が基本
・リレーションの定義文は、〜する〜されるの動詞句を基本とする

4-7CRUDマトリクス分析
・エンティティ、プロセス、ごとに操作するCRUDを整理すること。

○ 5 非機能要件
・社会的責任を最優先
・FURPS+のうちFを除いたもの
* Functionality：機能性。画面や帳票など、利用者が扱うUIと処理要求を含む
* Usability 操作性。使いやすさ。画面の使い勝手や見栄え等を含みます。
* Reliability 信頼性。システムの停止要件（停止許容時間）、障害対策（ネットワークやハードウェアの二重化など）
* Performance 性能。オンライン処理の応答時間やバッチ処理時間など
* Supportability：保守の容易性。ハードの拡張性や互換性、プログラムの保守性
* + 設置場所、言語の規定、セキュリティ要件など
・業務プロセスの定義から明確化する

○ 6 アーキテクチャ
システムアーキテクチャの枠組み
* ホスト中心ー昔ながらのメインレームを使用するシステム
* 2層クライアント／サーバー型ーオープン系のサーバーとクライアントPCで処理を分担するシステム
* 3層クライアント／サーバー型ー データベースサーバー、アプリケーションサーバー、クライアントで処理を分担
* Webシステム（PCプラウザ・モバイル）ークライアントとしてPCまたはモバイルのWebブラウザを使用するシステム
* Webシステム（リッチクライアント）ークライアントとして「リッチクライアント」と呼ばれる特殊なプラウザを使用するシステム。スマートフォン専用アプリケーションもこの分類
* その他のシステムーIoTデバイスを使用するシステムや、サーバーレスのP2P（ピアソービア）、エッジコンピューティングなど
・疎結合がキーワードになる程分散が主流
・非機能要件をもとに最適な組み合わせを決める

アプリケーションアーキテクチャの位置付け
・明確にすべき項目
* 処理形態（オンライン・バッチ等）
* アプリケーション方針（オンライン・バッチ連動方法、どこまでサーバー側で処理するか)
* サーバー側プログラミング言語・フレームワークの使用
* DB操作方法
* 通信プロトコル
* クライアント側プログラミング言語
* ユーザーアクションの検知方法
* データ保持方法・チェック方法
* 画面遷移方法
* 排他制方式（楽観ロック、悲観ロック）
* 取消方法
* ログ

○ 7 妥当性確認
成果物の確認
① 要求・要件トレース図
② システム全体図
③ 概念／論理データモデル（ER図・用語集・データ項目書)
④ ビジネスルール集（要件定義レベル）
⑤ ToBe業務フロー及びプロセス定義（プロセスモデル）
③ UI定義（プロトタイプ）／画面遷移図
⑦ 非機能要件定義晝
⑧ アーキテクチャ要件定義書
・未決事項の把握と対応策