今回も『「ユーザのための要件定義ガイド：4.2.2要求の具体化」と概念データモデルの取り扱いA024』の続きです。
P135は以下のように始まっています。
（2）ビジネスプロセスの観点から業務を可視化し､新しい業務として具体化する
【解決したい問題】
■要求を反映した業務プロセスにならない
・ビジネスプロセスが変わらない
・業務プロセスを標準化できない
・変革ポイントが分からない
・要求が反映されているか分からない
業務を表現するモデルとして業務フローなどのプロセスフロー系のモデルがよく使われる。業務部門やシステム部門にとっても理解しやすいモデルであるが作成量が多くなる傾向にある。現状業務を中心に業務フローを作成したが、作成が終わったときには現状とそう変わりのないフローになっていたというプロジェクトも少なくない。要求を実現するためのビジネスプロセスの見直しの検討に時間が確保できていないプロジェクトもある。眸今は手作業の機械化だけではないので、ビジネスプロセスの見直し、To-Be業務の検討に注意を払って業務フローを作成していくことが重要である。
勘どころ①問題・課題、要求と照らし合わせてプロセスモデルを描く
企業におけるビジネスの実態を･番意識しやすいのは、業務フローなどのプロセス系ドキュメントである。しかし、フロー系成果物は精度を上げて具体的に記載すればするほど量が多くなり、作成には時間もかがるため、対象をすべて記載するところまでで精一杯になり、内容に対する談論か疎かになる傾向にある。そうならないように、作成者が経営的視点でビジネスプロセスを改革、改善するという意識を持って、業務フロー図などのプロセス系成果物の作成に臨むことか重要である。
フロー系のドキュメントの検討において使用される３階層のフロー図（ビジネスプロセス関連図、業務フロー、システム化業務フロー）（図4.26）のうち、ビジネスプロセス関連図では、より経営レベルに近いビジネスプロセスの改革（要求）が表現でき、業務フロー、システム化業務フローでは、より現場レベルに近い細かいビジネスプロセスの改善 （要求）が表現できる。プロセス改革の検討においては、ビジネスプロセス関連図レベルの検討から始めるのが良い。
システム部門（またはそこから委託されたベンダ企業）がフロー図を作成すると、現行システムをベースに新たな要件への対応を追加するというアプローチで検討を行った結果、ビジネスプロセスの変革が期待したほどでなかったという結果を招くことになりがちである。それを防止するためにも、フロー系成果物は､利用部門が主体となって検討を行うことが望ましい。
ガイドのこの部分では、フロー系ドキュメントの作成を「要件定義」の段階で描き起こすのがよいと推薦していますが、筆者の前回ブログ『ビジネスプロセスマネジメントにおける「プロセスマップ」と「要件定義」A027』で、ビジネスプロセスマネジメントを行い、ビジネスプロセスをマッピングする方法をお伝えしました。ビジネスプロセスのマッピングは一朝一夕にできるわけではなく、然るべき時間と体力をかけて行う必要があります。その時間と体力の節約と効率的な実行のために株式会社BPデザイナーズ社のコンサルティングを受けることをお勧めもしました。
ガイドの文中に「業務フローなどのプロセス系ドキュメントである。しかし、フロー系成果物は精度を上げて具体的に記載すればするほど量が多くなり、作成には時間もかがるため、対象をすべて記載するところまでで精一杯になり、内容に対する談論か疎かになる傾向にある。」という件がありますが、これは本末転倒で、要件定義のためにビジネスプロセスマッピングを行うのではなく、ビジネスプロセスアナリシス（マッピング）を行い、現状（As-Is）プロセスの問題を洗い出し、何をChange（＝差分）するのかを検討し、あるべき姿（To-Be）のプロセスを定義した上で要件定義を行うのが筋であり、ガイドの指摘は首肯できません。
ガイドでは次のようにも言っています。
「業務フローなどのプロセス系ドキュメントである。しかし、フロー系成果物は精度を上げて具体的に記載すればするほど量が多くなり、作成には時間もかがるため、対象をすべて記載するところまでで精一杯になり、内容に対する談論か疎かになる傾向にある。それを防止するためにも、フロー系成果物は､利用部門が主体となって検討を行うことが望ましい。」
本ガイドは「ユーザのための要件定義ガイド」であり、利用部門が主体となって検討を行うことが大前提だと筆者は考えているのですが、読者の皆さんはどうお考えになるでしょうか？
ガイドでは、更に以下のように続きます。
勘どころ②要求との紐付けをする
要件定義において業務フロー図を作成するプロジェクトは多数あるが、業務フロー図上に問題点・課題や要求を記載しているプロジェクトはそう多くはない。
業務フロー図上に問題点・課題や要求のマッピングを行い、現状の課題の共通認識や新しい業務の検討に業務フロー図を用いる。それとともに、前出している要求との照合を行うことが重要である。
改革・改善を意識させるための簡単かつ有効な方法は、フロー図に要求・課題の欄を設け、それらとマッピングさせながらフローの検討を進めることである（図4.27）。
●AS-lSフローを作成する
●経営レベルの課題をAS-lSフローにマツピングする
●現場レベルの問題点をAs-lsフローにマツビングする
●新たな問題点・課題がないか検討し、分析を補完する
●As-lsフロー図に基づいて問題点・課題の共通認識、合意形成を行う
●経営レベルの目的・施策をTo-Beフローにマッピングする
●現場レベルの目的・手段をTo-Beフローにマッピングする
●マッピングした内容をもとにTo-Beフロー図を作成する
●To-Beフロー図をもとに施策、手段の共通認識、合意形成を行う
上記のガイドの指摘は妥当な指摘と考えますが、あくまでビジネスプロセスの検討は、システム検討に先立つものであると言うことです。
更にガイドは以下のように続きます。（細かい説明は割愛）
勘どころ③業務プロセスのバリエーションを整理する
ここでは､業務プロセスや業務パターンを整理し、業務プロセスの観点から業務の複雑さを低減するための勘どころを述べる。業務プロセスを見直すときに常に意識しておくと良い。
●業務プロセスの廃止を検討せよ（図4.28のａ）
●業務プロセスの集約を検討せよ（図4.28のb）
●業務プロセスの連結を検討せよ（図4.28のＣ）
● 業務プロセスの並行化を検討せよ（図4.28のd）
この指摘も、システムを検討する事前検討で完了しておくべき「あるべき姿（To-Be）」を要件定義段階で検討しなければならない・・・と言っておられます。
下の図はガイドのP74にあるシステム開発工程を示すものですが、ガイドを読んでいると「企画段階」でやるべきことに殆ど言及がなく、専ら、要件定義段階で「何でも吸収しよう」というスタンスに感じられIPAには、是非再検討をお願いしたいと思います。
