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

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

サービス要件のオーナー②

前回から、
確定できたと思われるＱには、実は不確実性が潜んでいる可能性があること

その理由は、
本来は要件を持っているはずであるにもかかわらず、
要件定義に参加していない要件オーナーが存在することを説明し、

ひとつめのサービス要件のオーナーとして
企画部門、サービス部門、営業部門をあげました。

サービス要件のオーナーには、もうひとつ、
サービスそのものの利用者であるユーザがあります。

例えば、
Ｂto Bサービスにおける
提供先企業の固有要件を取り込む必要がある場合などです。

プロジェクトマネジメントにとって、
要件オーナーとしてのユーザが、企画／サービス／営業部門と
決定的に異なる点は、

ユーザは、
企画／サービス／営業部門のように、
要件定義工程に物理的に参加頂くことができないことです。

なぜならば、大抵の場合、
ユーザ企業との契約はプロジェクトの後半、もしくは終盤、
場合によっては、システムリリース後に決まる順番となるため、
要件定義の工程でユーザ要件を事前に確認することができません。

こうした状況下のもとでは、
要件が後から発生するとの状況をあいまいにして放置することなく、

対処としては、要件定義以降の要件追加・変更は、
「予算も期限も別途調整する」との条件で
　プロジェクトのスポンサー（お客様）と明確に握っておくべきです。

余談：
サービス要件のオーナーについて、実は、
前述のようなＢtoＢユーザの他に、ＢtoＣユーザの場合があります。

この場合も、
ユーザがプロジェクトそのものに参加することはありませんので、
留意が必要です。

保守要件・運用要件のオーナー

昨今では、
開発チームや部門がそのまま保守・運用を担当することは少なくなり、

開発部門とは別の、
保守・運用チームや場合によってはグループ会社などの別事業者が
保守・運用を担当することが増えてきました。

それに伴い、
要件定義の要件に、保守・運用要件を考慮する必要が出てまいりましたが、

なぜか、
保守・運用要件のオーナーたる保守・運用チームや部門が
要件定義工程から参加することは、ほとんど見かけたことがありません。

保守・運用業務で必要となるシステム要件も必ずあるはずなので、
ＱＣＤバランスを確定させる要件定義完了までに、
要件を可視化しておくべきです。

保守・運用チームの参画が遅れ、
保守・運用の要件定義がプロジェクトの後半になってしまうと、

大抵の場合、その頃には、
予算も、リソースも、時間もないため、システム化される範囲は限定され、
手作業に負担が寄せられることになります。

本件の対処は、
要件定義工程からの参加を当初から計画しておくだけで、
防ぐことができるため、早い段階から保守・運用チームの参画を
計画することをお勧めします。

セキュリティ要件のオーナー

セキュリティ要件のオーナーは情報セキュリティ部門になります。

情報セキュリティ部門がプロジェクトに参加することは
ほとんどありませんが、

昨今では、
大抵の場合、情報セキュリティ規定が定められているため、
要件定義工程で規定を読み込むことで必要な要件は理解できると思います。

留意すべき点は、
新しい情報技術については、規定に明確に定義されていない場合があるため

もし、
採用する情報技術などで、情報セキュリティ規定に記述がない場合は、
はやめに情報セキュリティ部門に確認が必要です。

特に、
既存の規定にない項目に対する新たな判断については、
時間がかかることが想定されるため、はやめはやめの振り出しが必要です。

いずれにしても、
セキュリティ要件は、他の業務要件などとは異なり、
重要なセキュリティ要件を満たせない場合は、
リリース全体が止まってしまうため、注意が必要です。

法規制要件のオーナー

法規制要件のオーナーは法務部になります。

こちらもプロジェクトに参加することはほとんどありませんが、
プロジェクトの条件によっては、個別に要件を確認する必要があります。

例えば、
介護サービスや食材配達事業者が、個人宅のデジタルキーを事前の契約で
利用する場合など、

不正利用などが発生した場合は、
当該のサービスだけではなく、会社全体に対する
レピュテーションリスク（風評被害リスク）に拡大する場合もあるため、
プロジェクトだけの責任ではすまなくなる場合があります。

こちらも、
セキュリティ要件同様、法規制要件が後で問題になると、
リリースそのものが止まってしまうこと、

コーポレートととして、あらたな判断が求められる場合は、
判断に時間がかかることから、やはり早めの振り出しをお勧めします。

次の記事（４０回）