![見出し画像](https://assets.st-note.com/production/uploads/images/119769842/rectangle_large_type_2_f6c6f2dacf81c317f7d81a9237070907.jpeg?width=1200)
なぜプロジェクトマネジメントが機能しないのか 33 スコープの不確実性②
日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はPМ、ある時はPМОとして、お客様と問題解決に取り組んでいます。本記事では、まだPМBОKには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います。
マガジン:https://note.com/think_think_ab/m/m0e070db46016
定義すべき要件の粒度
補足:
本記事にて述べる「要件定義」について、
今回の例は、システム開発プロジェクトのため、
内容がシステム開発に限定されます。ご容赦ください^^;
さて、
第32回 スコープの不確実性①(https://note.com/think_think_ab/n/n8957f15a84f1)では、
プロジェクトの3大不確実性のうちのひとつ、
ユーザ部門と開発部門のミスコミュニケーションによる
スコープの不確実性について、
そのスコープが定義される要件定義工程の
問題について述べました。
では、そもそも、
要件定義で、サービス部門(もしくはユーザ部門)は、
要件をどこまで具体的に定義すればよいのでしょうか。
①サービスレベルでしょうか。
②オペレーション(いわゆる業務)レベルでしょうか。
③画面の機能説明レベルでしょうか。
④画面オブジェクトひとつひとつの機能説明レベルでしょうか。
①〜④のいずれも「要件」に変わりはありませんが、
要件定義の際、どこまでの粒度で「要件」を定義すればよいのでしょうか
業務フローの意味
目的と手段の関係※で整理すると、
※第11回 目的と手段
(https://note.com/think_think_ab/n/nfadb53b6a3f0)参照
サービス
↑
↓
オペレーション(いわゆる業務)
↑
↓
システム
との関係のため、
システム側(開発側)に対しては、
いわゆる業務レベル(前述②)の要件提示が必要となります。
その際の要件提示の資料は、
いわゆる「業務フロー」と呼ばれるものです。
「業務フロー」は、
特定のサービスを実現すために必要な業務の流れと
その流れにおける各部門の役割分担を定義するものですが、
実は、
「人手の作業」と「システムの作業」の役割分担を定義します。
いいかえると、
特定のサービスを実現するために、やらなければいけないことのうち
どこを「人手」でやって、どこを「システム」でやるかを定義します。
余談ですが(そして、あたりまえですが)、
人手でやる部分を増やして、システムでやる部分を減らすと
人手の負担は増えますが、システム費用は少なくなります。
逆に、
人手でやる部分を減らして、システムでやる部分を増やすと
人手の負担は減りますが、システム費用は大きくなります。
したがって、
オペレーション部門(いわゆる業務部門)などのユーザ部門だけで、
業務フローを作成すると、
極端な場合、
なんでもかんでもシステムにやらせるようになります。
場合によっては、
システムではできないことも定義されることがあります💦
そうした流れで定義された業務フローが
業務部門側で正式決定されてしまうと、
後の設計工程で変更することは、
とても大変な調整ごとになってしまいます。
(状況によっては、サービス部門も巻き込んだ複雑な調整が必要となり、
調整だけでかなりの工数が必要となる場合もあります。)
では、どうすればよいのでしょうか。
それは、
業務フローの作成に、
システム側(開発側)も深く関わり、
業務フローが正式化する前(要件定義の最中)から、
システムでできること、できないことを説明し、
状況によっては、システムでできないことはないが
その実現には費用が大きくかかることなどを説明することです。
適切な説明を、
適切なタイミングで繰り返し働きかけることで
実現性のある業務フローになっていきます。
では、
システム側(開発側)は漫然と業務フローをみていれば、
前述のような指摘ができるのでしょうか。
実は、
漫然と業務フローを見ているだけでは、
システムでできること、できないことを可視化することはできません。
では、
システム側(開発側)はどうすればよいのでしょうか。
すみません。また続きは次回になってしまいます💦
次の記事(34回)
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?