自分の中のリスク、課題、QA管理を整理する

次の案件がやばそうなので「本質（開発）にフォーカス」しておきたい。そのため可能な限り管理負荷を減らしたい。ただ、管理のどこが自分にとって負荷なのかわからなくなってきたのでまとめておく。

きっかけ

なんとなく「例外系」の事をこう読んでいる気がする。あと用語の統一もされていそうでされていないので定義してみようと思う。

はじめに

PMBOKを参考にしつつ、自己流でまとめています。

リスク

「もし，それが起れば，プロジェクトの目標にプラスやマイナスの影響を与える不確実な事象」。
直感的には「やばそう」な事がリスク。語尾に「かも」がついたらリスク。
（ただし、なぜなぜ５回は実施してそもそも課題ではないか、という事はある）

誰かやめるかも
サーバのHDDが消えるかも
予算がショートするかも

課題（問題）

確実に発生する事、発生してプロジェクトに影響を与えていること（タスクの進行を妨げる）。

仕様が決まっていない
誰かがやめる
サーバがない

インシデント（QA）

QA、というか質問。基本的に「今から行う作業」のための確認事項。課題との明確な違いは「消化する以外にタスクが発生しないこと」。ただ、インシデントから課題が発生する事はある。

XXの意味がわからない→誰もしらない→課題「顧客に確認」

共通している事

管理すること。誰がいつまでに何をしなくてはいけなくて、終わっているか監視する必要がある。

共通していない事

対応方法は全部異なる。

リスク管理

発生の可能性と発生時影響を確認し、優先度を決めた上で「受け入れる」、「軽減する」、「回避する」の対応を行う。

課題管理

課題作成者が何を持って課題の解決となるかを定義（完了の定義）し、依頼された者が対応する。

インシデント管理

聞くだけ。

それぞれ負荷が高いところは？

消化状況の監視と対策

課題のステータスとして、TODO、DOING、DONEでは危険。そもそも決める事に時間がかかっているから課題なのでDOINGではなくタスク（進捗管理のためタスクのライフサイクルについて考えてみた - kaji_3's blog）みたいに管理しないと行けないか。とうかタスクと課題って一緒だよな。課題だけ管理する必要ってもしかしてない？

課題の作業ボリュームの監視

「やる事」が決まったら作業ボリュームがわかるのでスケジュールに反映すればよい。ただ、スケジュールを動的に作成する仕組みでもないと組み換えは難しい。かといって、「スケジュール範囲外」とする事で放置された課題が後に爆発する事は多い。また、スケジュールに組み入れないと負荷がわからない。

まとめてみて

タスクと課題が一緒かも、と思いつけたのが最大の発見でした。今までは上記をすべて「課題」って言っていたような気がします。うまい運用方法はまだ発見できていませんが、思いついたらまとめてみます。