なぜプロジェクトマネジメントが機能しないのか 33 スコープの不確実性②

日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はＰМ、ある時はＰМОとして、お客様と問題解決に取り組んでいます。本記事では、まだＰМＢОＫには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います。
マガジン：https://note.com/think_think_ab/m/m0e070db46016

定義すべき要件の粒度

補足：
本記事にて述べる「要件定義」について、
今回の例は、システム開発プロジェクトのため、
内容がシステム開発に限定されます。ご容赦ください^^;

さて、
第３２回 スコープの不確実性①（https://note.com/think_think_ab/n/n8957f15a84f1）では、

プロジェクトの３大不確実性のうちのひとつ、
ユーザ部門と開発部門のミスコミュニケーションによる
スコープの不確実性について、

そのスコープが定義される要件定義工程の
問題について述べました。

では、そもそも、
要件定義で、サービス部門（もしくはユーザ部門）は、
要件をどこまで具体的に定義すればよいのでしょうか。

①サービスレベルでしょうか。
②オペレーション（いわゆる業務）レベルでしょうか。
③画面の機能説明レベルでしょうか。
④画面オブジェクトひとつひとつの機能説明レベルでしょうか。

①〜④のいずれも「要件」に変わりはありませんが、
要件定義の際、どこまでの粒度で「要件」を定義すればよいのでしょうか

業務フローの意味

目的と手段の関係※で整理すると、
※第１１回 目的と手段
（https://note.com/think_think_ab/n/nfadb53b6a3f0）参照

サービス
↑
↓
オペレーション（いわゆる業務）
↑
↓
システム

との関係のため、
システム側（開発側）に対しては、
いわゆる業務レベル（前述②）の要件提示が必要となります。

その際の要件提示の資料は、
いわゆる「業務フロー」と呼ばれるものです。

「業務フロー」は、
　特定のサービスを実現すために必要な業務の流れと
　その流れにおける各部門の役割分担を定義するものですが、

実は、
「人手の作業」と「システムの作業」の役割分担を定義します。

いいかえると、
特定のサービスを実現するために、やらなければいけないことのうち
どこを「人手」でやって、どこを「システム」でやるかを定義します。

余談ですが（そして、あたりまえですが）、
人手でやる部分を増やして、システムでやる部分を減らすと
人手の負担は増えますが、システム費用は少なくなります。

逆に、
人手でやる部分を減らして、システムでやる部分を増やすと
人手の負担は減りますが、システム費用は大きくなります。

したがって、
オペレーション部門（いわゆる業務部門）などのユーザ部門だけで、
業務フローを作成すると、

極端な場合、
なんでもかんでもシステムにやらせるようになります。

場合によっては、
システムではできないことも定義されることがあります💦

そうした流れで定義された業務フローが
業務部門側で正式決定されてしまうと、

後の設計工程で変更することは、
とても大変な調整ごとになってしまいます。
（状況によっては、サービス部門も巻き込んだ複雑な調整が必要となり、
　調整だけでかなりの工数が必要となる場合もあります。）

では、どうすればよいのでしょうか。

それは、
業務フローの作成に、
システム側（開発側）も深く関わり、

業務フローが正式化する前（要件定義の最中）から、

システムでできること、できないことを説明し、
状況によっては、システムでできないことはないが
その実現には費用が大きくかかることなどを説明することです。

適切な説明を、
適切なタイミングで繰り返し働きかけることで
実現性のある業務フローになっていきます。

では、
システム側（開発側）は漫然と業務フローをみていれば、
前述のような指摘ができるのでしょうか。

実は、
漫然と業務フローを見ているだけでは、
システムでできること、できないことを可視化することはできません。

では、
システム側（開発側）はどうすればよいのでしょうか。

すみません。また続きは次回になってしまいます💦

次の記事（３４回）