システム開発において、プロジェクトマネジメントを実施していると「課題」「リスク」「ToDo」という言葉が出てきます。しかし、これらの違いは一体なんでしょうか？わかっているようでわかっていないことも多いと思いますので、今回は整理していきます。
そして、課題とリスク、ToDoの違い以外にも、QAについても絡めて整理していきます。
課題とリスクの違い
課題とは、現在においてプロジェクト進行の問題となっている事柄、QCDSに影響を及ぼしている事柄のことです。
一方、リスクとは、将来においてプロジェクトのQCDSに影響を及ぼす要因のことです。
つまり、課題とリスクの決定的な違いとは、プロジェクトが見ている時間軸の違いです。課題は現在時点を見ており事象が顕在化しているが、リスクは現在は事象が発生していないが将来にわたって顕在化する可能性があり潜在的であると整理することもできます。
一方で、課題とリスクの共通点は、プロジェクトおよびチームが抱える事柄ということです。個人で抱える課題やリスクは基本的にありません。たとえ、個人が抱えているような課題やリスクがあったとしてもそれはプロジェクト全体での課題、リスクとして整理し、対処していくこととなります。
リスクマネジメントについては、こちらの記事にて詳しく解説していますので合わせてご覧ください。
スポンサーリンク
ToDo（タスク）とは
続いて、ToDo、つまりタスクについて整理します。
課題やリスクと異なり、ToDo（タスク）とは、いまやらなければいけない事柄、作業です。
リスクを検知したら、リスク対策を検討します。そして、潜在的なリスクが顕在化したら課題となり、リスク対策を講じます。このように、リスク対策を”検討”したり、リスク対策を”実行”したりといった、やらなければいけないことがToDoです。また、課題やリスクといった事柄から発生するToDo以外にも、もっとラフに日々のプロジェクト遂行の中で出てくる宿題、持ち帰り検討事項もToDoです。
そして、もう１つ重要な観点がリスクや課題とToDOとの違いは、ToDoは「個人が」実施できる形で整理したことと定義することができます。
スポンサーリンク
QAとは
続いて、QAについても整理しておきます。QAは言うまでもなく質疑です。
プロジェクト課題やリスクを検討したり、ToDoを実行していくうえで必要となる情報を収集するために、主にベンダーと（顧客）発注者との間でやりとりされる質疑です。
例えば、AsIsの業務がどのようになっているか知りたいと思ったらベンダーは発注者側にヒアリングが必要です。そういった際に、ベンダーから質問を出して、それに対して発注者側が回答するという流れになります。こうした日々発生するようなやりとりがQAであり、QAを起点でToDoが発生していく関係にあります。
厳格な整理をするとQAが発生したら、QAを回答するためのToDoが発生するといった関係性にあります。しかし、QAが発生したら、それをToDoに焼き直すといったそこまで厳格な整理はしないのが通常です。
スポンサーリンク
リスク、課題、ToDo、QAの管理
では、ここまででリスクや課題、ToDoそして、QAについてそれぞれ整理しました。
次に、これらを実際にプロジェクトでどのように管理するかについて解説します。プロジェクトによって様々なタスク管理ツールを導入することもありますが、もっとも原始的な方法はExcelで管理台帳を用意することです。
ここで問題になるのは、どういった粒度で管理する必要があるかです。リスク管理用、課題管理用、ToDo管理用、QA管理用とすべて分けて管理するのも手段の一つです。しかし、その分管理が複雑化します。したがって、私が過去に実施していたプロジェクトで多かったのは、リスク管理台帳と、課題/ToDo/QA台帳の２つを用意していました。
なぜ、これら２つかといえば、時間軸が関係します。リスクは比較的に長い目で対処する一方で、課題/ToDo/QAは比較的に短期的な事項が列挙されます。したがって、未来を見据えるものと、いまを対処するものという切り口で分けて管理することをお勧めします。
課題/ToDo/QA台帳は、日々更新をかけていく一方で、リスク管理台帳は月１回や開発工程の切り替え部分で見直しするといったように対処する周期に応じて分けると管理しやすいです。
スポンサーリンク
課題・リスク・ToDo・QAを細分化する
最後に課題やリスク、ToDo、QAについてもう一段階、整理してみます。特に、システム開発に特化して整理すると、これらは、プロジェクトに対するものとシステムに対するものに分けることができます。したがって、課題に焦点を当てていうなれば、プロジェクト課題とシステム課題と２つに大別することができます。
プロジェクトに対するものとは、プロジェクト遂行上のQCDSに影響を及ぼすような事柄であり、それに付随するような実行事項であり、関連する質疑です。
具体的には、次のようなものが挙げられます。
- 要件定義工程で現場キーマンの意見を聞きたいが会議に参加してくれない
- 新技術を使ったシステム開発を予定しているが、技術者を確保できるか不透明
- 周辺システムとのデータ連携を予定しているが、他ベンダーの開発が遅延している
このようにプロジェクトを今後遂行していくうえで、品質や納期、コスト、スコープに影響を及ぼすような顕在化しているもしくは潜在的な事象のことです。
一方で、システムに対するものとは、実際に開発・保守対象となるシステム要件、システム仕様に関するようなリスクや課題、それに伴う対処事項などです。
具体的には、次のようなものが挙げられます。
- 銀行口座番号など重大な個人情報を扱うため、厳格なセキュリティ要件の実現が必要
- 受注登録画面の画面構成や売上レポートの帳票レイアウトについて検討が必要
- 対向システムとのデータ連携項目が未定のままである
これらのように開発するシステムに直接的にかかるような内容になります。
もちろんプロジェクトに対する事柄も、システムに対する事柄も常に関連しあっています。システム要件を決められないということはプロジェクト遂行上の課題やリスクにもなりますので当然です。しかし、これらを分けて整理することで、誰が何を検討、実行しなければいけないのかを整理しやすくなります。主には、プロジェクトに対することは、プロジェクトマネージャーを中心にプロジェクトオーナーも巻き込んで検討しますが、システムに対することであれば現場のシステムエンジニアやプログラマー、現場担当者やユーザと共に検討を進めることができ、より円滑にプロジェクトを遂行することができます。
スポンサーリンク
プロジェクト関係者で認識を合わせることが重要
いかがでしょうか。リスクと課題の違いの整理からはじめて、そこから発生するToDo、そしてQAの関係性について整理しました。最後には、それらをどのように管理していくか、そして、プロジェクト視点とシステム視点という２つの視点で整理することの重要性を解説しました。
プロジェクトによって様々な見解はあると思います。しかし、重要なことは、それぞれのプロジェクトでリスクや課題、ToDo、QAといったこうしたものをどう定義するかです。プロジェクト関係者の認識があってこそ、安定したプロジェクト遂行が可能となります。
ぜひ、今回の内容を１つの例として日々のプロジェクトマネジメントに活かしてみてください。
コメント