だまし絵を描かないための要件定義のセオリー - WEB銭の読書やグラベルロードのメモなど

まとめ
この本を読んだ理由
仕事にかせるポイント
目次
感想

まとめ

「だまし絵を描かないため」というタイトルが秀逸で、かつ過激だなぁ。でも、失敗する要件定義を表すと、まさに「だまし絵」なんだよね。絵に描いた餅を定義してしまう。そうならないためにビジネス要求から、ビジネス要件に、業務要求から、業務要件に、システム要求から、システム要件に
しっかり内容を定義する方法を本書は教えてくれます。

この本を読んだ理由

久しぶりにしっかりと要件定義を行うプロジェクトに入ったため

仕事にかせるポイント

やはり、「要求の引き出し」から「要件定義」に持っていく話のまとめ方ですね。論理ジャンプしないで済む方法ですよね。

第1部　要件定義と情報システム
序章　なぜいま、「要件定義」なのか？
第1章　情報システムにおける要件定義
第2章　要件定義の基本方針
第2部　要件手気の実践
第3章　要件定義の前にやっておくべきこと
第4章　要件定義でやるべきコト
第5章　非機能要件の定義
第6章　アーキテクチャの整備
第7章　妥当性確認/合意形成

感想

この本は「ユーザー要求を正しく実装へつなぐシステム設計のセオリー」との姉妹書なんだという。もちろん、こっちが要件定義で、そっちが設計なので、お姉さんは、こっちだ（何を言っているんだ）。

きっと、妹の方の書籍も、しっかりとした手順と「なぜならば」という話が書かれているのだろうな。

素敵すぎるのだ。どっちつかず抽象論でみなければ、気合いと努力を求めるばかりでもない。きっと数え切れないほどの要件定義を行って来たからなのだろな、そう思えてしまう安心感があるのだ。

要求とは本当に欲しいもの。
要件とは本当にいるもの。

だから、要件を定義する要件定義で行う作業とは「やらないことを決める作業」といえる。

このプロセスを具体的に、わかりやすく教えてくれる。

流行りのUXという言葉も、要件定義に用いるとこんなことができると、教えてくれる。UXからユーザーシナリオの大枠を導き出し、業務プロセスの固まりである業務フローを作成します。業務フローから個々の業務プロセスにとって必要なUI・機能を洗い出すことが可能になるのだと。

で、要件定義のお話なのですが、要件定義の前には要求の洗い出しを行わなくてはならない。

では、要求の洗い出しと要件定義って、何が違って、つながっているのかという話だけれど、これをものすごくわかりやすく教えてくれる。

要求分析と要件定義の作業

1．じっくりと時間をかけて要求を明確化し、To Beビジネスモデルを検討する
2．明確化された要求を基に、To Be（あるべき）プロセスモデルとToBe概念データモデルを作成する
3．As Is(現に今ある）モデルを検証（…ここまでが要求分析で行うべき作業）
4．As Isモデルを参考にして、人、モノ、金などのプロジェクトとして意識をせざるをえない制約を考慮しつつToBeの実現可能性を検討する
5．もし、実現可能性が低いと判断されたら、ToBeを修正し、新しいToBeのプロセスモデルとデータモデルを作成する。
6．As Isから新To Beモデルにあたるプランを策定する。

これをもっとわかりやすくまとめると「ToBeモデル第1弾の作成」と「AsIsモデルの作成」までが要件定義の前に行って、要件定義では本当に目指すべき未来を定義する「新ToBeモデル」を作成するってことですな。

で、要件定義のなかれをまとめると、こうなる①要求→要件のトレース②システム全体図の作成③業務フローの明確化④業務プロセス要件の明確化⑤UI・機能要件の明確化⑥データ要件の明確化。そして、これらの妥当性を確認するCRUD マトリックス分析。

この本がすごいのは、①～⑥のステップをわかりやすく教えてくれることなのだ。

要求から要件を明確にする手順

Step1　要求階層の確認
Step2　要求から要件へ
Step3　要件の整理
Step4　システム要件の確定
Step5　要件範囲の明確化

システム全体図の作成手順

Step1　システムイメージの検討
Step2　システム全体のラフスケッチを描く
Step3　外部接続を描き加える
Step4　サブシステム（候補）同士のつながり
Step5　機能間の連携も記載する

そして、著者が言うように業務フローはシンプルであればあるほど好ましい。そんな業務フロー上に現れる業務プロセスは5W2Hで表現されるという。

When：実施タイミング（事前/開始条件を含む）
Where：場所、組織
Who：担当者、ユーザー
What：対象データ
Why：目的、狙い、当該プロセスが完了した時点で達成されている目的と、事後条件（プロセス完了時に達成できていること）を含む
How：実施要領（成約条件含む）
How many：（データ量、時間）

そして、作らなければならないToBeの業務フローはこのように作る。

Step1　全体を鳥瞰可能なレベルの業務フロー図を作成する（トップダウンモデリング）
Step2　全体図の各アイコンを1枚の業務フロー図に分解（トップダウンモデリング）
Step3　業務フロー図をさらに細分化する
Step4　業務プロセスに命名する
Step5　外部/内部インターフェイスの定義を行う
Step6　フローの詳細化（トップダウンとボトムアップ）
Step7　業務フローの定義
Step8　スイムレーンを分ける
Step9　外部データとの連携を詳細に記載する
Step10 最下層の業務プロセスを5W2Hを定義する
Step11 各業務プロセスを統合または分割する

そして、UI・機能の明確化の手順はこうなる。

Step1　ユーザーシナリオの抽出
Step2　ペーパープロトタイプの作成
Step3　画面遷移の明確化
Step4　プロトタイプの確認
Step5　機能の洗い出し
Step6　プロトタイプ、画面遷移に関する要件の確定

そして著者は非機能要件を整理する際にソフトウェアの品質属性を表すモデルであるFUPRS+と呼ばれる分類報を参考にしているそうな。それ、私も参考にしよう。

Functionality：機能性。画面や帳票など、利用者が扱うUIと処理要求を含みます。
Usability：操作性。使いやすさ。画面の使い勝手や見栄え等を含みます。
Reliability：信頼性。システムの停止要求（停止許容時間）、障害対策（ネットワークやハードウェアの二重化など）を含みます。
Performance：性能。オンライン処理の応答時間やバッチ処理時間等を含みます。
Supportability：保守の容易性。ハードの拡張性や互換性、プログラム保守のしやすさなどを含みます。
+（Other）：上記の分類に当てはまらないもの。主にプロジェクトの制約。ハードウェアの設置場所等の物理的制約、操作端末の制約、プログラミング言語の指定、セキュリティ要件など。

で、ユーザビリティ要件の明確化は、このようなStepとなる。