読者です 読者をやめる 読者になる 読者になる

arclamp

ITアーキテクト 鈴木雄介のブログ

「ITプロジェクトのリスク予防への実践的アプローチ」への違和感

IPAから2013/3/27に「ITプロジェクトのリスク予防への実践的アプローチ」が公開されました。読んでみて感じたことを簡単に(参照:ITプロジェクトのリスク予防への実践的アプローチを公開


リスクを発現させない
この資料の目的は「リスクを発現させない」ということにフォーカスされています。

そのためにリスクの発生要因となる「リスク事象ドライバー」を整理し、そこで把握された要因について回避や軽減といった予防策を取るように推奨されています。リスク事象ドライバーは以下の通り。

  • システム化の目的が明確でない
  • 現行機能の調査確認が不足している
  • 現行システムとそのドキュメントが整合していない
  • パッケージ選定に関する検討が十分でない
  • 性能の検討が十分でない
  • 可用性の検討が十分でない
  • 運用要件の検討が十分でない
  • 運用に向けての制約条件が明確でない
  • 要件を獲得すべきステークホルダーが網羅されていない
  • システム部門による要件とりまとめが十分でない
  • ドキュメントの更新が管理されていない
  • 仕様の変更管理ができていない
  • ユーザーによる仕様の確認が充分でない
  • 要求の優先度が曖昧になっている
  • 業務要件の網羅性が検証できない
  • 設計と実業務の整合性が検証できていない
  • 経営層によるプロジェクト運営の関与が十分でない
  • 経営層によるスコープ決定への関与が十分でない
  • 経営層がパッケージ導入の意図・目的を明示していない
  • ステークホルダー間の力関係のアンバランスである
  • 高次の調整・決定機関が機能していない
  • 十分なコミュニケーションが取れていない
  • 業務用語が共有されていない
  • 業務知識が不足している

(ちなみにリスク事象ドライバーの一覧の網羅性はどうやって検証されているんだろうか)


リスクを発現させないことはできない
上記のリスク事象ドライバーというのは多くの場合、プロジェクトやシステムを取り巻く環境要因であり、ある種の前提条件であるように思います。これらのリスク事象ドライバーはない/少ないほうがいいに決まっていますが、多くの場合は受け入れなくてはならないものです。

なのでリスク事象ドライバーの分析は「発生するであろうリスクを発見する」ためのアプローチとしては非常に有効なものの、どんなに予防してもリスクがなくなることがあるようには思えません。


原因を知っても物事は前に進まない
このモデルに違和感を覚えたのは「リスクの原因を分析することに意味があるのか」ということです。

リスク事象ドライバーはどれも簡単に解決できないことです。かつ、顧客サイドの問題も多く含まれています。そういった問題があることが分かってもプロジェクトが前に進むわけではありません。リスク事象ドライバーについて把握することは大事ですし予防できることはやってもらいですが、「リスクの原因」を突き詰めることにどこまでの意味があるかは疑問です。

もう1点。こうしたリスク事象ドライバーが解決できていないことを他人のせいにしてしまうのではないでしょうか。自分ではないナニカが悪いという逃避も物事を前に進めません。

解決できない事を解決しようとするのは時間の無駄です。問題を解決できるようにして、ささっと物事を前に進めることが現実的なアプローチです。

この資料を使ってリスクを想定し共有するのは良いことだと思います。それができたら「リスクの発生要因をなくす」のではなく「リスクに対処する」ということをしたほうがいいでしょう。