本来は依頼企業から提供されるはずの「現行業務フローチャート」「要求定義」「要件定義」「新業務フローチャート」などの文書（ドキュメント）も、開発企業側で作成するものと覚悟してください、ということです。
という、哀しいけれど、現実的な前提を元にしたドキュメント作成の解説書である。

全体的に流れが論理的で気持ちがいい。
基幹システムの見直し時などに、とても参考になるだろう。
見開きで左に解説文書、左に図解という構成になっている。
解説文書はとても分り易いのだが、図解があまりよろしくないのが残念である。

本書では、以下のような構成になっている。

システム開発の問題点
現行業務フローチャートの作成
要求定義の作成
要件定義の作成
新業務フローチャートの作成
概要仕様書の作成
基本仕様書の作成

一般的なイメージでは、「概要仕様書」はRFPをもらった後の提案書、「基本仕様書」は基本設計書、というところか。

現行業務フローチャートの作成にあたり、収集した業務上の問題を「処理速度や処理量の問題」「処理の正確性の問題」「業務情報の共有の問題」「システム以外の問題」に分類する。
情報をどのような切り口で分類するかは、調査・分析において非常に重要である。
この本では、各フェーズにおける切り口が紹介されており、実務に役立ちそうだ。

以下のノウハウは、実際に役に立ちそうだ。

部門間の流れを知るために、申請書や指示書を収集し、申請・発行部門、承認部門、管理部門のマトリックスを使用する。

「変わる」ことへの抵抗を避けるために、ユーザインタビューではシステムの導入を前提とせず、問題点や改善点と共に作業内容や作業環境なども尋ねるようにする。

要望は、「システムを導入するための本質的な要望」「システムを導入するときの手法的な要望」「具体的な技術に関わる要望」の３つに分類する。
「システムを導入するための本質的な要望」は、経営陣から提示された要望の中にあり実現が前提となる。
「システムを導入するときの手法的な要望」は、現場の要望であり技術の方針を検討する際に重要になる。
「具体的な技術に関わる要望」は、使用する技術を特定している。

要望の中には、システム化以外の対策が必要なものが混在している。
システム化が有効な要望のキーワードは「迅速性」「正確性」「記録性」である。

要求定義と要件定義は以下のような関係にある。

「要求定義」
基本的な要求
　業務要求
　ユーザ要求
　技術的要求
運用・保守上の要求
　運用上の要求
　保守上の要求
業務フローチャート

「要件定義」
技術的要件
　機能要件
　1.システムを実現するために必要十分な「機能」
　2.機能要求、性能目標、品質属性
非機能要件
　1.システムを実現させるために必要十分な「条件」
　2.制約条件、物理的条件、セキュリティ目標、
　　システムの操作性、システムのライフサイクルと維持管理、
　　仮定と依存性
運用・保守上の要件
　運用上の要件
　保守上の要件
システム要件
　ハードウェア要件
　ネットワーク要件
　ソフトウェア要件

「要求対性マトリックス」を利用し、「要件ID」と「要求ID」をキーとして仕様書間の関係を明確にする。

業務改善の方法は二種類ある。
１つは業務を統合する方法であり、もう１つは業務を分割する方法である。

ネットワークの具体化では、建物の設計図を使った概要仕様書のネットワーク構成図をもとにする。
実際の建物で配線出来るか、現場をまわって確認する必要もある。

[amazonjs asin=”4774137855″ locale=”JP” title=”SEの認められるドキュメント”]