チェックリストでリスクを見つけてプロジェクトを幸せにしよう

極論すれば、プロジェクト管理とは

　「リスク管理とイコールである」

と言っても過言ではありません。

現実や過去が望まない状況とならないように常に未来予測を行い、リスクを避け続けるコントロールを行うことこそがマネジメントの本質だからです。

ありとあらゆるすべてのリスクを回避すれば、プロジェクトはかならず

期限通りに、
要件通りに、
お客様も満足して、
幸せに、

終わるはずなのです。
全てのリスクが発生しなければ、そうならないとおかしいはずです。

たとえば、たまに

　「品質に注力しようとすると、コストがかかる」

という言い回しをする人がいます。
おかしいですよね。

そもそも見積る時点で納品するであろう製品の品質は、100%となるように見積もっているはずです。最初から予算の中に品質を100%にすることが大前提ですし、お客さまとして求めているのは必要な機能に対して品質100%であることですから、これ以上品質を上げなくていいような仕事ぶりになっていなくてはいけません。

まさか、

　「品質70%のつもりで見積もってました」

なんてプロジェクトは存在しないはずです。もしそうなら見積り条件に明記する等しておかないとお客さまも納得はしないでしょうし、非常に大きなリスクとなるはずです。

仮に、100%にできなかった場合をリスクとして想定するなら「どうすれば既存予算で100%にできるか」その工夫を試行錯誤するのがエンジニアやリーダー、マネージャーの責務のはずです。

なにひとつ工夫しようとせず、ただの人海戦術しか選択肢を持たマネジメントは

　マネジメントしていない

のと変わりません。
素人でもできることです。

そんな中、IPAが幸せへの最短ルートと言うべきドキュメントを出しています。

それが、

　ITプロジェクトのリスク予防への実践的アプローチ(PDF)

です。長いですが、一読の価値はあるというか百読の価値あるドキュメントです。
色々なシチュエーションごとに編纂されていて、

　「プロジェクトの最初に」
　「プロジェクトの途中で」
　「プロジェクトが終わってから」

それぞれ違う読み方ができると思います。

ただし、大学の先生が監修しているためか非常に長いので「長い」「多い」と言うだけで読む気が無くなるような人には勿体ない資料かも知れません。

リスクチェックシート（「システム化の目的が明確でない」場合）

汎用的に作られているため、「○○の案件では…」と言った個別の仕様には耐えられません。そう言うミニマムな資料にはなっていません。

個別の制約は、個別のプロジェクトごとにテーラリングするのが常識です。

しかし、これをチェックするだけでも割といい線でリスクの洗い出しが出来るはずです。リスクが見つかったら、対応方法を考えなければいけません。基本的にはチェックに引っかからないようにすればいいのですが、どうするのがより良く対応できるのかは実際に資料を読んだ方が良いでしょう。

一番大事なことは、

　プロジェクトの成功のためにはベンダーの努力だけではダメで、
　必ずユーザーにも協力をしてもらわなければならないシーンがやってくる

ということです。
IPAが推奨する方法としても、

　「こういう協力をしてもらいましょう」

という対応策がほとんどですので計画段階…具体的にはお客さまとのキックオフミーティングの段階までにどこまでお客さまを巻き込み、合意を取っておけるかでプロジェクトリスクの難易度、ひいてはプロジェクトの成功率が変わるということです。

ベンダーとユーザー、お互いの幸せのために、そして企業と従業員の幸せのために、
リスクが顕在化しないマネジメントを心がけましょう。

また、ここでは「進捗が遅れる」とか、「見積もりを誤った」とか、そういう自己責任で起こりうるリスクに対する対応はココには入っていません。

けれども、このリストに対応をあらかじめ取っていればそもそもそういった事象が発生しにくくなることは間違いありません。

　「ちゃんとこういう工数考えてる！？」

と言ってくれているリストにちゃんと対応すれば基本的に工数が足りなくなることは無いはずです。