PMBOKあるいはISOなどの標準規格での開発プロセスのサポートプロセスで管理すべき、 課題、懸案、リスク、（問題？）…

Question

PMBOKあるいはISOなどの標準規格での開発プロセスのサポートプロセスで管理すべき、
課題、懸案、リスク、（問題？）の違い、定義を教えてください。

職場の先輩に
・課題....現時点では着手できない、解決方法が不明な、解決できないとプロジェクトのQCDに悪影響がある事項。
・リスク..現時点では着手できない、解決方法、解決手順がわかっている、解決できないとプロジェクトのQCDに悪影響がある事項。
・懸案....現時点で本来なら解決すべき事柄で、解決できないとプロジェクトのQCDに悪影響がある事項。
と教えられました。

ただ、職場の先輩のオレオレ定義っぽいので、標準規格を調べています。
標準規格での定義を教えてください。

（当たり前ですが、社内規格は知恵袋で質問できないので自分で調べます）

Answer 1

PMBOK関連の講師の人から聞いたこともあるのですが、「規格本そのものの転記」に煩い団体が居るので、、２次資料しか引用できかねますが、、
懸案管理に関連して、PMBOKとITIL v3での用語定義を紹介します。

>標準規格での定義を教えてください。

☆PMBOK®ガイドでは；
「リスクとは、それが発生すれば少なくともスコープ、スケジュール、コスト、品質といったプロジェクト目標に影響を与える不確実な事象・状態」とあります。

WBSに定義されたタスクを推進する上で必ず発生する予定作業や、リスク対応策の立案などで着手すべきとして予定したコトは、課題と言います。
すでに発生してしまった脅威は、問題といいます。

https://www.pmi-japan.org/topics/pmi1/pmbok_5_9.php

PMBOKやCMMIでのリスクは、「投機的リスク」（マネジメント次第で利益（好機）にも損失（脅威）にもなり得るリスク）概念を採用している。

http://www.newspt.co.jp/data/info/mr/mr80/mr8009.pdf

http://www.newspt.co.jp/data/info/mr/mr80/mr8009.pdf

PMBOKでの「ツールと技法」の一つである”リスク登録簿”の中では、”リスク識別”の為の”本プロジェクトの状況”欄でSWOT分析できるよう、”リスク・トリガー（リスクが顕在化したと認める条件）”と、”実際に発生した問題現象”とを対応付け易く記入します。
つまり、問題現象を未来形で表現したのが、リスク識別情報です。
http://pmstyle.biz/column/i2m/i2m23.htm

｛未だ顕在化していない問題”現象”、発生した問題”現象”｝に対して、対応策として｛todo,対応者や対処、対応期限｝などを決め、進捗を管理する課題ログの様式を、統一様式にし、viewで絞り込み見れるようにしたり、課題管理用の短冊をファイリングしなおす手法を提案している人も居ます。
下記資料でも「問題”現象”は、数多在る記入項目の一つだ」という位置づけでは、PMBOKと共通しています。

・問題・課題、Todo、リスクの『「超」整理法』
http://www.it-innovation.co.jp/2016/04/04-004042/

☆ITIL V3では、チョット PMBOKと違う体系の定義になっています。

懸案（インシデント）とは、「サービスレベルアグリーメントとして定義された”サービス受益者がやりたいコトを阻害する要因」をインシデントと言います。
でも、例えば、「顧客クレーム対応窓口サービス」で苦情を受け付けることは、そのサービスの定常運用（やりたいコト）ですから「苦情はサービスリクエスト」と分類し、「対応策が決まっていない、予定外のコト」がエスカレーションすべきインシデントと分類されます。

ITILでは、サービスの定常運用開始前に想定したあらゆるコトに対して、Q&Aシナリオやオペレーション・マニュアルとして準備する前提です。
にも関わらず”予定外のコト”が発生した場合、それは”問題”と分類されるべきことでしょう。

ITILでの”問題管理”とは、「インシデントを発生させる可能性のある未知の原因」を突き止め、当面の暫定処置（ワークアラウンド）だけではなく、再発防止策（根治プラン）とるまでの、一連の活動を言います。

直面した”問題現象”に着眼するするのではなく、散々調べてヨウヤク分かるであろう”未知の原因”の存在を認識しようとする処が、PMBOK的な課題ログの記入項目の一つとしての”問題現象”とは、ニュアンスが異なります。

再発防止策（根治プラン）には、一旦運用を止めて、新種のサービスを定義するような、長期間のシステム改善（サービス再開発）も必要になる場合もありますから、インシデント管理より長期に跨る活動です。

また、もし現行サービスのサービスレベルアグリーメントに「ワークアラウンドまで実施すれば良い」と規定した場合、問題管理活動では、「そんな”現行サービス”を止めて、改善した”新サービスを企画せよ”」等と言って、現行サービスと利害が対立しうる活動です。
｛リコール→旧製品の出荷停止→改善版新製品出荷｝のような、長期の問題管理活動は、PMBOKのプロジェクトマネジメント知識領域には無く、プログラム（プロダクト）・マネジメント側に チョット触れられているだけです。

http://www.itmedia.co.jp/enterprise/articles/0710/10/news003_2.html