勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

「ITプロジェクトのリスク予防への実践的アプローチ」を読む

IPAで公開された「ITプロジェクトのリスク予防への実践的アプローチ」を読んだ感想。IPAの各種情報は出来るだけウォッチするようにしている。ソフトウェア産業の発展を願って公表される資料なので、出来るだけキャッチアップして活用していきたいと考えている。

「ITプロジェクトのリスク予防への実践的アプローチ」には何が書かれているのか

「ITプロジェクトのリスク予防への実践的アプローチ」のサブタイトルは「ユーザー/ベンダー協働によるリスクへの対処」である。文字通り、この文書はユーザとベンダが

  • リスク事象の予防モデルを共有し
  • モデルに従い「リスク事象ドライバー」を特定し
  • ユーザとベンダーで、「リスク事象ドライバー」を軽減または回避する対策を検討する

ことについて書かれている。
基本的には一般的なリスク管理のフレームとなっているのであるが、定性評価重視となっているのが使いやすくて良いと思う。定量評価(被害額や顕在化確率などの分析)をやることも重要だろうと思うけど、これはあくまで「リスク予防」を主眼に置いていると理解。

なお、ここで言う「リスク事象ドライバー」の定義は以下の通りである。

プロジェクトにおいて存在する、特定のリスク事象を誘発しうる要因である。例えば、「要件獲得の対象とすべきユーザー側の対象者が正しく特定できていない」というリスク事象ドライバーが要件定義プロセスにおいて存在した場合、「要件定義に漏れが生じる」というリスク事象が発生しうる。
情報処理推進機構:ソフトウェア・エンジニアリング

また有識者が検討した主要な24の「リスク事象ドライバー」の詳説が資料として付いているのが素晴らしい。この資料編では、各「リスク事象ドライバー」について

  • どんな「リスク事象ドライバー」か
  • これによって引き起こされるリスク事象は何か
  • 一般論的な観点での、リスクの把握方法
  • 一般的な予防策
  • 解説

が整理されている。

ひと通り読んでみて感じたのは
「このドキュメントそのものをプロジェクトの早期で利害関係者で読み合わせるといいのではないか」というもの。IPAという機関が発行していることもあり、意外とイケそうな気がする。お客さまと1時間くらいのセッションで、いろいろとリスク防止策について議論が出来るような気がする。

24のリスク事象ドライバー

リストアップされている24のリスク事象ドライバーは下記の通り。リストを見ただけで心が折れそう。

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

ちなみに解説文書は、けっこうストレートに厳しい事を書いているので面白い。

ドキュメント不全の現行システムについて、要件定義をやり直すことなしに再構築を行うことはほぼ不可能である。

意義なし。

また、「現在動いているシステムと同様の仕様でシステム構築して欲しい」という要求に対しては、現行システムに関するドキュメントやその他の情報の正確性を前提とすること、またはそれが確保できない場合には、スクラッチ開発に変更すべきことをユーザーに伝えることも必要である。

あるある。

わが国ではとかく、「作業の詳細が明確になる前に総額での見積りを求める」「一度決めた予算額は、いかなる理由があろうと変更することができない」といった不条理な慣行があり、「委託側が強い」という力関係のアンバランスから、プロジェクトが迷走しがちである。このことは、必ずしも委託者側の利益にはならない。品質にしわ寄せが来れば、最もひどいダメージを受けるのはICTシステムの利用者である。

orz...