詩と創作・思索のひろば

ドキドキギュンギュンダイアリーです!!!

Fork me on GitHub

リスクを直視しないという罪:『熊とワルツを』

ウィッシュリストに入れてたのを同僚が贈ってくれた。

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

リスクのあることを知りながら何もアクションをおこさないことは罪である……といったエピソードからこの本は始まるのだけど、もうこの言葉だけで重要なことはほとんど言ってしまっているような感すらあった。自分が今までしてきたのこれは罪だったんだ! と知らされる衝撃があった。いわゆる罪の文化というのもあるのかなと感じる。

もちろんこのことは導入であって、より詳細に、

  • リスクとは何なのか
  • リスク管理をする理由・しない理由
  • リスク管理の方法

といった話がメインの内容として続く。

リスクとは何なのか

この本では、リスクとは顕在化する前の問題であり、逆に問題は顕在化したリスクであるという風に描かれている。ふたつは表裏一体である。プロジェクトを進行し、スケジュールの見積もりをある程度の確度をもって定めるには、リスク管理を行うことで問題を発生させないこと・軽減させることに努めなくてはならない。リスクが問題に移行する前に策を打っておくことで、リスク軽減できるというのもポイントだ。

リスク管理において陥りがちな問題のひとつに、プロジェクトに関連する、チーム外の部署に任せている部品に関するリスクを知らず知らずのうちに無視してしまう、ということがある。発注したコンポーネントの完成は当然期限に間にあうもので、そうでなければ請負先の責任、という態度だ。

これがメインプロジェクトの主要な箇所を構成する要素であればプロジェクト全体のスケジュールや完成度に多大な影響が及ぶわけだから、そのリスクに無頓着でいられるはずもない。本来ならば、発注側がそのようなリスクの管理においては責任を負わなければならない。別にチームやプロジェクト単位の話に限らず個人のレベルでも同じようなことは言えて、たとえば他の人に依頼した仕事のその後をトラッキングせずにただ待つというのもよくないことなのだと思った。

リスク管理の方法

このように不明瞭だったリスクの責任の所在を、リスク管理を行うことで明らかにできる。リスク管理は以下のような手順で構成される。

  • 問題になりそうなこと(リスク)を洗いだす。これには過去のプロジェクトにおける問題が参考になる。きのうの問題は今日のリスクである。
  • それぞれのリスクが生じた時のコストと発生の確率を見積もる。
  • リスクを軽減するための方法と、そのコストを検討する。この軽減コストはプロジェクトのコストに上乗せする。
  • リスクが問題に移行する前兆(移行指標)を検討する。ボールが転がってきたあとには、かならず子供が走ってくるといった具合。

リスクを真剣に考えていくと、これが現実になったらプロジェクトそのものが立ち行かなくなる、というようなものもある。これをショーストッパーという。この概念を知れたのもよかった。ショーストッパーに関してはプロジェクトの管轄の範疇外とならざるをえないので、そのリスクを抱えるのはプロジェクトの発案者となる。プロジェクトの中の人はそれを仮定として受けとるしかない。

肝心なのは考えられる限りリスクを洗い出すこと。チームとして他人と一緒に仕事をしているわけなので、なんとなく、プロジェクトをはじめようというときにネガティブなことを言ってやる気を削いだり白けさせてしまってはいけない……などと考えてしまうのも人情(西洋でもそういうものらしい)。なのであえて儀式として取りおこなうとよい。その際、このプロジェクトにおいて考えうる最も破滅的なシナリオは何か? とそれぞれに問う。いわば悪い方を向いたブレインストーミングだ。

ソフトウェア開発プロジェクトにおける、よくあるリスク(「曖昧な仕様書」など)についてもいくつか挙げられていて、参考になる。その他数値的なツールの紹介もされているのだけどあまり興味がなく読み飛ばした。

心配しないこと

エントリを書くにあたって本を読み返してみると、以下のような言葉が目を引いた:

リスク管理は、プロジェクトについて心配することとは違う。

また、

リスク管理が個人的な心配という形でしか行われない場合、それはコミュニケーションの断絶を意味する。

個人の心配をチームのリスクへと昇華させ、プロジェクトの責務の一部としてその軽減にあたりましょう。とまとめられると思う。面白い本だった。

はてなで一緒に働きませんか?