プロジェクトをアーキテクトするために必要な、プロジェクトを高い位置から俯瞰するということについて考えています。
前回は、前略目的から考えるプロジェクトのＱＣＤについて優先順位を考えることと、関連するプロジェクト群(プログラム）の存在を確認し、プロジェクトとの関係を明らかにすることがポイントになるということを考えました。
今日はもう一つのポイントである「リスク」の存在と、プロジェクトアーキテクチャの関係について考えて行きます。
プロジェクトには人間と同じようにそれぞれ個性があります。ですから、一つとして同じプロジェクトは存在しません。
プロジェクトの目的も、プロジェクトに携わる人も、プロジェクトの環境もそれぞれことなります。そのためプロジェクトのリスクもプロジェクト毎に異なります。
プロジェクト開始前に特定可能なプロジェクトのリスクを上げ、そのリスクを回避するために必要なプロジェクトの構造を設計します。
先ほど上げたようにプロジェクトには個性がありますが、プロジェクトにおけるリスクは２つのカテゴリーがあります。一つは比較的汎用的なリスクで、もう一つはプロジェクト固有のリスクです。この２つが合わさってプロジェクトの個性を形作っています。
汎用的なリスクは、業種、業界に特有なリスクであったり、組織の特性に依存するリスクであったりします。このようなリスクを組織的に排除することが難しく、恒常的に存在するのであれば、それを回避するために様々なルールが組織に設けられているはずです。
例えば、重要な書類のＷチェックや複製を取るルールであったり、なんらかの決済に必要な一連の手続きだったりするわけです。このように、汎用的なリスクについては、機能しているどうかは別にして、組織内部にそれを排除するための仕組みがインクルードされています。
これに対して、プロジェクトに固有のリスクについては、プロジェクトに関わる人の経験や見識から想定することが必要となります。
例えばパッケージソフトウェアを導入するプロジェクトの場合、パッケージソフトウェアの基本機能を十分に評価することが望ましいのですが、そのような作業をちゃんとプロジェクト作業として設計するなどということです。
次回もこのテーマを続けて行きます。