解説/Review

プロジェクト・リスクの識別と記述
木野 泰伸

Project Risk Identification and Description
Yasunobu KINO
Abstract– In planning or design phase, project members make decisions with limited or uncertain
information. Those decisions might turn into risks. The facts which they make decisions with uncertain information are not described on any specific documents, but only recognized by decision makers
themselves. Therefore, it is difficult for a third person to find out the risks. In order to manage thesetypes of risks, it is important for those who make decisions with uncertain information to share theirexperiences. However, since not all engineers have the knowledge of risk management, it is extremely
difficult to describe risks appropriately. In addition, when various kinds of people are involved in therisk identification process, same risks tend to be listed too many times because they are expressed
differently by different people. This article will discuss the standardization of risk description which
will reduce the fluctuation in expressing risks. Existing risk models will also be examined.
Keywords– project management, risk management, risk model, risk description

1. はじめにうに適切な言葉で表現することは意外に難しい．複数のメンバーで個別にリスクの洗い出しを行う場合は，同一プロジェクト計画の立案や設計作業を実施する時にのリスクを別の表現で記述してしまうことがある．そのは，検討の前提となる全ての内容が確定した状態では場合，単にリスク項目が重複しているというだけの問題なく，不確定な状態で行っている．そして，不確定な状にとどまらない．例えば，各リスクの発生確率と影響の態で判断したという事実は，計画書や設計書に記載され大きさを用いて，プロジェクト全体のリスクを計算してることなく，担当者が自分自身の意識の中にのみ保持しいる場合は，関連するリスクを重複して計上してしまう．ている場合が多い．しかし作業が進むに従い，前提とのこのようなことを発生させないために，作業者による表ずれが生じることがある．このことが後に問題を発生さ現の揺れが少なくなるように，できる限り標準化されたせ，プロジェクトに多くのリスクが存在する原因の一つ形でリスクを記述することが望ましい．になっている．

本稿では，「プロジェクトは，本質的に，不確実な情報このようにプロジェクトはその特質から多くのリスを残した状態で計画や設計がなされる」ことに注目し，クを内包しており，リスクを認識し，適切に管理するこリスクをその発生場所で識別することの大切さ確認し，とは，プロジェクトを成功させるうえで，非常に重要でさらに人による表現の揺れを少なくする新たなリスクのある．リスクを管理するためには，はじめに，チェック記述方法について検討する．

リスト，ブレーンストーミング，識者へのインタビュー

なお，プロジェクトには，建設，IT（Information Tech-などの手法を用いて，多様な角度から漏れなく識別するnology）システム開発，研究開発など多くの種類があり，ことが重要である．しかし，チェックリストは，リストまた，自社内だけで行う場合や，プロジェクトの一部に記載されてないリスクは識別できず，識者へのインタや全体を外部に発注する場合など，多様な形態がある．

ビューやブレーンストーミングは，参加した人の知識にこれら種類や形態の違いにより，プロジェクトの特性に影響を受けるため，重要なリスクを見逃す危険性がある．

差があり，議論が発散することがあるため，本稿では，また，識別されたリスクは言葉として記録される．こSI（System Integration）事業など，IT システム開発プロジェクトの受注企業の視点を前提に検討した．のとき，他のメンバーとの間に認識のずれが生じないよ 筑波大学大学院ビジネス科学研究科

東京都文京区大塚 3-29-1

 University of Tsukuba, Otsuka 3-29-1, Bunkyo-ku, Tokyo

Received: 26 January 2008, 10 March 2008

Oukan Vol.2, No.1

21

Kino, Y.

Table 1: 課題懸案事項一覧表の例
番号 日付 タイトル
46

1

2
357

1/31 [DB転記]
エラーの扱い詳細対応法

担当/期限 ｽﾃｰﾀｽ

DB転記時にエラーが起こったら、どのよう エラー経路が設定されていればその Bに、ユーザーに知らせるか？
先へ、設定されていないときは、直 2/7
前の処理者へ、直前の処理者がプログラムの時は、起票者に送られる。
（2/7 のメールを参照）
2/16 [業務（伝票照会）] アーカイブDBを経路に設定する場合、以下 ③の方法で実施する。アーカイブ名 A
アーカイブの設定の方法があるが、どの方法を用いるか？
は"STATUS_ALL"
2/20①経路を明示的に設定し、分岐を用いる②経路を明示的に設定し、直列に設定する③アクションボタンのプロパティーで指定する
1/10 [承認者決定]
マスターDBからは、第１承認者の情報のみ Yes ただし、移行時は、データの A
第２承認者の指定が流れてくると考えているが正しいか。正 信頼性悪し。第１承認者の上司を第 1/16
しい場合、第２承認者はどのように指定す ２承認者とする。
るのかを検討する必要がある。
1/10 [代行設定]
代行者の代行は出来ないようになっている 出来ない仕様になっている。
A
代行者の代行か？
1/16
1/23 [ダウンロード]
ダウンロードをどの方式で実現するか未決 Aさんより情報をBさんへ
C
どの方式で実施？
IE5はOK、IE4を確認中
3/10
2/8 [マスターDB]
レスポンスを向上させるために、Viewの設 レスポンスの観点でチューニングを Dレスポンス計が必用になるかもれない。
実施する
3/15
2/20 [メニュー画面]
タイトルの並び順がソートされてしまい、 project Idを設定し、その並びでAタイトルの並び順国内と国外が逆になってしまう。
ソートさせる。
3/15

済

2/7

済 2/19

済 1/20済 1/16

Fig. 1: 2 つのチームが同時に設計作業を実施している例

このようなプロジェクトが本質的に持つ問題を解決するため，従来から行われているプロジェクトとしての

2. プロジェクトのリスク公式なリスクマネジメントに加え，実作業者であるメンプロジェクトには，独自性，有期性，段階的詳細化という性質がある [1]．以下では，段階的詳細化がリスクを発生させる様子について確認する．

バー個人のレベルでリスクを意識し，統合的に行うことが重要になる．

2.2 リスク発生現場での把握
前述のようなリスクを把握するためには，リスクが発2.1 不確実な前提から生じるリスク生する，もしくは組み込む現場で記録することが重要でプロジェクトは，初期段階において，全ての作業が詳細に計画されているわけではなく，プロジェクトの進行ある．その方法として，多くのプロジェクトで Table 1のような一覧表を用いて管理している．に伴って，詳細化されていくという特性を持つ．また，Table 1 は，筆者が実際にプロジェクトで使用した一製品やサービスといった，プロジェクトが作り出す最終覧表の抜粋である．このような表は，企業やプロジェク的な成果物についても，プロジェクト開始当初は，詳細トにより名称が異なるが，本稿では，課題懸案事項一覧な仕様が決まっておらず，徐々に詳細化してゆく．

表と表記する．課題懸案事項一覧表そのものは，納品対計画や設計が，プロジェクトの進行に伴って詳細化さ象になるような正式な文書ではなく，プロジェクトに参れることがリスクとなることを，もう少し具体的に確認加するメンバーが，主として自分自身の作業のために作したい．例として，Fig. 1 のように A，B という２つの成しているものである．そのため，その記述内容についチームがデータを受け渡しするインターフェースを持つて，あまり厳密なとり決めをしていない．また，課題，懸処理を同時に設計している場合について考える．

案，リスク，問題など，用語の整理や使い方に対する標B チームは，A チームが作成する処理 A から，どのようなデータが来るかを正確に知ることができれば，処理 B を設計するうえでの問題はない．しかし，現実的には，A チームは，まさに処理 A の設計を行っている最中であり，処理 B に渡すデータ内容や項目が確定しているわけではない．その場合，B チームは，処理 A から来ると思われるデータを自ら想定し，その想定に従って設計作業を行う．後に，A チームの設計が終わって，この想定が正しければ問題は発生しないが，想定に誤りがあると，B チームは設計の修正をしなければならない．
このような例は，決して特殊ではなく，プロジェクトの日常作業で多く発生する．そのため，設計者も心の中で気にはなっているが，設計書に，あえて「ある想定を前提にしている」ということを書き込むことはない．そのため，第三者が文章レビューをしても想定が含まれていることを発見することは難しく，後に想定がずれた場
合は，テストフェーズで初めて発覚するケースもある．

準化も必要性は低いと考えている．重要なことは，日々22の作業の中で気になる事柄を気軽に記入できることである．そのため，既に発生している問題等が混在しても差し支えない．
ところで，Table 1 のタイトル項目にある括弧で囲われたキーワードは，時々表記を見直し，ソートに利用している．

2.3 統合的リスクマネジメント
プロジェクトメンバーが個人的に課題懸案事項一覧表を作成し，日々の作業の中で発生する，気になる事柄を書き留めることが重要であると述べた．この課題懸案事
項一覧表は，プロジェクトの公式な成果物ではなく，どちらかというと非公式なものである．そのため，この非公式なものと，プロジェクトとしての公式なリスクマネジメントとの連携が重要となる．その関係を Fig. 2 に表した．

横幹 第 2 巻 第 1 号

Project Risk Identification and Description

事象発生前可能性
不確実性
チャンス
発生確率・・・
現在ある事象事象発生後
結果
影響影響度
インパクト・・・

将来
Fig. 3: 各種標準おけるリスクのモデル

Fig. 2: 総合的リスクマネジメント

いリスクを抜き出し，リスク管理表に加える．そして，Fig. 2 では，プロジェクトに関連する組織を大きく，
a) 企業や部門のレベル，b) プロジェクトのレベル，c)メンバー個人のレベルの３つの層で捕らえている．そして，プロジェクトのライフサイクル全体を見渡し，具体的に行う作業内容から，リスクマネジメントを大きく次の３つに分けて考えている．
I．プロジェクト構想・計画段階
この段階では，企業や部門レベルの組織が重要な役割を果たす．企業や部門のレベルは，プロジェクトを持つ企業や部門のレベルであり，複数のプロジェクトを横断的に管理する組織，たとえば，事業部であったり，品質保証部であったり，横断的に管理するという意味においての，PMO（Project Management Office）がそれにあたる．
ここでは，プロジェクトの契約前に，プロジェクトが持つリスク内容やその大きさを評価し，契約金額や契約条項に反映させることが目的の一つとなる．また，あまりにもリスクが大きい場合は，受注しないという判断も考えられる．
II．プロジェクトメンバー個人のレベル
プロジェクト実施時において，プロジェクトメンバーが，日々の作業を実施する時に認識するリスクを扱う．
不確実性を持ったまま計画や設計作業を行うことによるリスクを課題懸案事項一覧表などに記載し，管理していく．なお，プロジェクトメンバーによっては，リスクという用語にこだわり，十分に記載できないこともあるので，「気になること」「心配事」を気軽に記入してもらうことも重要である．
III．プロジェクトのレベル
ここでは，多くのプロジェクトにおいて従来から実施されている一般的なリスクマネジメントを行う．通常，各フェーズでは，次フェーズの詳細計画を立てる．そのドラフトができた時点で，リスクの識別を行う．その時，メンバー個人で記入している課題懸案事項一覧表から，プロジェクトのレベルとして，管理することがふさわしリスクの識別をした後，可能なリスクについては対応策の実施までを実施し，詳細計画を見直す．

3. リスクの記述
前章では，リスクを発生現場で捉えることについて見てきた．そして，従来から行われているプロジェクトとしての公式なリスクマネジメントとの関係を確認した．
ところで，リスクは識別されると，それを文章として表記し，管理する．しかし，リスクを適切に記述することは，意外に難しい．特に，リスクの洗い出しを複数人で行う場合は，人により表現の揺れが生じ，本来，同じであるはずのリスクを別々に記述することがある．この問題を解決するため，いくつかのリスクモデルを参考に，標準的で，人による揺れが少なくなる表現方法を検討した．
なお，リスクの記述は，前提とするリスクモデルに影響を受けるため，各種ガイドや標準におけるリスクのモ
デル，構成要素とリスク原因によるリスク特定法によるモデル，FTA（Fault Tree Analysis）によるモデルについて確認する．

3.1 各種標準におけるリスクの定義とモデル
現在，AS/NZS4360[2] や JIS Q 2001[3] をはじめ，多くのリスクマネジメントに関する標準が存在する．それらの標準で定義されているリスクの表現や用語には，違いが存在するが，その中身を吟味すると概ね次のように集約できる．
リスクは，過去や現在のことではなく，将来に発生する可能性がある「ある事象」のことであり，そのある事
象は，２つの付属的な要素を持っている．一つは，事象が発生する前の “発生するかもしれない” という可能性に関するものであり，「可能性」，「不確実性」，「チャンス」，「発生確率」などと表現される．もう一つは，ある事象が発生した後に関することであり，それは，「結果」，「影響」，「影響度」，「インパクト」などと表現される．これを図で表現すると Fig. 3 のようになる．

Oukan Vol.2, No.1

23

Kino, Y.

リスク原因の分類
構成
要
素トリガー（前のリスク）●
リスクを連想する

リスク事象～ が ～ する可能性（確率）があるある状況や条件

結果 影響/（次のリスク事象）

・・・

最終的な損失Fig. 5: 再検討したリスクのモデル
Table 2: Fig. 5 のモデルを基にした表現

Fig. 4: マトリックスによるリスクの特定

3.2 構成要素とリスク原因によるリスク特定法によるモデル
次に，構成要素とリスク原因によるリスク特定法 [4]でのリスクのモデルについて検討する．本特定法は，プロジェクトで作成される課題懸案事項一覧表から，リスクと思われるものを抜き出し，それを整理していくことから導き出された方法である．この特定法では，Fig. 4のようなマトリックス表を作成し，その交点一つひとつに対して，「（構成要素）には，（リスク原因）は存在するか？」と考えることにより，リスクを想定していく．
このことから，リスクを「（構成要素）が（リスク原因）する可能性がある」と表現する．また，本特定法では，「プロジェクトの構成要素」と「リスクの分類された原因」から構成されたモデルとなっている．

「（構成要素）が（リスク原因）する」の部分は，Fig. 3のある事象に対応し，「可能性がある」は，Fig. 3 のリスク発生前の事柄に対応している．このことから，この表現には，リスク発生後の事柄が不足しているといえる．
そこで，「（構成要素）が（リスク原因）する可能性があり，その結果〜となる」と表現すると Fig. 3 のモデルと一致する．なお，この表現は，リスクマネジメントの重要な要素である「発生の可能性（確率）」と「影響の大きさ」というリスクを管理するうえでの基本的な要素は含んでいるが，FTA のモデルで述べたリスクの連鎖に3.3 FTA によるモデルついての考えが加味されていないので，そのことを考慮

最後に信頼性工学などの分野で用いられている FTAし，リスクのモデルを Fig. 5 のように表記した．

（Fault Tree Analysis）について検討する．FTA は故障のFig. 5 では，リスク事象を，「〜が〜する可能性があ要因を分解してゆき，木構造で記述する．そして，分解る」と表現し，もしそのリスクを発生させる特別な状態された要因ごとの故障確率から全体の確率を計算する．

や条件があれば，それを付属する要素のひとつとして考FTA では，故障を扱っているが，リスクについても同様に考えることができる．
リスクの要因を分解し，木構造で記述するには，ある一つのリスクをより細かな要素に分解する方法や，時系列に連鎖するリスクを関連づける方法が考えられる．このうち，後者の考えにより書かれた図は，リスクの連鎖を現したモデルであるといえる．

えている．そして，このリスク事象は，「結果/影響」を引き起こす可能性を持つ．なお，リスクが連鎖している
場合は，この「結果/影響」が次のリスク事象となり，さらにその次の「結果/影響」を引き起こす可能性を持つ．
そして，最終的に損失にたどり着く．また，リスク事象は，それを引き起こすものとしてトリガー的な事象を持つ場合がある．リスクが連鎖している場合，トリガーは，一つ前のリスク事象と考えることができる．

4. モデルに基づいた表現の検討

このモデルを用いて，各要素を文章にしていくと，情前章で確認したモデルでは，使われている用語やその報量の多いリスクの表現となる．しかし，記述が長くな

意味に若干の違いがあるが，決して，相反することを述り，決して読みやすいわけでない．そこで，実際の運用べているのではなく，互いを補完する関係にある．

においては，Table 2 のような表形式で記述することがそこで，はじめに「構成要素とリスク原因の分類によるリスク特定法」によるモデルをベースとして，適切なリスクの表現について検討する．このモデルでは，リスクを「（構成要素）が（リスク原因）する可能性がある」と表現する．ここで，「（構成要素）が（リスク原因）する」の部分と「可能性がある」の部分に分けてみると，24現実的であると考えられる．

Table 2 を用いて，どのようにリスクを表現できるかを確かめるため，例として「テスト用ソフトウェアの配達遅延の可能性がある」，「テストで使用したパラメータやプログラムが本番に移行できない可能性がある」という２つのリスクを考え Table 3，Table 4 に記述した．

横幹 第 2 巻 第 1 号

Project Risk Identification and Description

Table 3: テスト用ソフトウェアの配達遅延の可能性のあるリスクる．ところで，リスクを管理するためには，文章で記述する必要があるが，リスクを適切に表現することは意外に難しい．そのため，人により表現が異なり，同じリスクを重複して記述してしまい，管理を複雑にする．
そこで，人によるリスク表現の揺れを少なくすることを目標に，新たなリスクの記述方法を検討した．
今後は，プロジェクトの現場で利用し，本当に人による表現の揺れを減らすことができるかを確認する必要がある．また，試行することにより改良を加えていきたいと考えている．

Table 4: テストで使用したパラメータやプログラムが本番に移行できない可能性のあるリスク

参考文献[1] Project Management Institute: A Guide to the Project Management Body of Knowledge Third Edition, 2004.
[2] Standards Australia and Standards New Zealand: Australian/New Zealand Standard 4360:1995, Risk Management, 1995.
[3] 日本工業規格: JIS Q 2001 リスクマネジメントシステム構築のための指針, 2001.
[4] 木野泰伸: プロジェクトの構成要素とペリルの分類を利用したリスク事象特定法の提案, プロジェクトマネジメ
ント学会誌, Vol.3, No.6，pp. 28-33, 2001.

5. おわりにプロジェクトでは全ての前提条件が確定した状態で設計や計画立案が行われているのではなく，不確実な要素を残しながら行われている．このことが，後に問題を発生させる一つの原因であり，言い換えると，リスク木野 泰伸を組み込んでいるといえる．このようなリスクは，設計書や計画書に明記されることは少なく，第三者によるレビューでは発見されないことが多い．そのため，不確実性を前提として設計や計画を立案する作業者本人が，そ1966 年生．1990 年関西学院大学理学部物理学科卒
業．同年，日本アイ・ビー・エム株式会社入社．多数の SI プロジェクトに従事．2003 年筑波大学大学院経営・政策科学研究科単位取得退学．博士（システムズ・マネジメント）．2005 年より，筑波大学大学院ビジネス科学研究科准教授．プロジェクトマネジメン
ト学会，日本品質管理学会などの会員．の場で記録することが望ましい．このような観点から課
題懸案事項一覧表を作成し，管理することは有意義であOukan Vol.2, No.1

25