0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

読書感想『熊とワルツを - リスクを愉しむプロジェクト管理』

Posted at

はじめに

リスク管理で定番の本。
こちらを読了したため、学びになった点をメモしておきます。

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

書籍自体は2003年。230ページぐらい。
口語調のため、文章は読みやすいです。

どうしても経験側な話が多く、即効性のある知識は多くないですが
「リスク」 を考えるきっかけに良さそう。
入門にもgood、たまに見返すと基本原則にも納得感が増しそうという感想です。

リスクとは?

リスクといっても身近なものでして、
「未来に起こりうる不確実性とその影響」
が私個人の理解です。

「コードレビューぼこぼこにされたらへこみそう。。」
「来週の発表が不安だな~」
「このお店の料理はおいしいのかしら?」
など、日々のたらればは頭の中に浮かび、とめどなく考えてしまいますね。

未来は何が起きるかわかりません。
それは楽しい一方で、様々な不安と困難を秘めています。
脳はこれまでの経験を元にシミュ―レーションすることで、対策を取ろうとします。

リスクはそんな 不確実性 の話です。

本書では、以下2つの定義があります。

1.将来起こりうる出来事で、望まない結果を生むもの。
2.望まない結果そのもの。

冒頭の定義。
1は可能性であって、2はもう起きたこと・結果です。
1は回避や軽減したい、2は何かしらの対応が必要です。

考える結果と、それによる影響を表す加重パターン

中盤からの再定義。
この定義によってリスクを数字から 「確率=図」 に落とし込めるようにします。
リスクの 視覚的に捉える ことでリスクにより立ち向かいやすくなります。

リスクとリスク管理の効能

さて、そんなリスク、つまり危険になぜ挑むのか。
端的には 「利益を得るため」 です。

リスクと利益は表裏一体であり、
何かしらの利益を得るためは、何かしらのリスクを背負う必要がある。

ノーリスク、という旨い話はほぼありません。
もしそんな話があったとしたら、

  • それは旨く見えるようで旨くない話
  • 旨くなるまで工夫(リスクを徹底的まで管理した)した話
  • そもそも当人にとってリスクではない話

など考える方が無難のように思われます。

本書では、リスクを取ることを以下のように紹介しています。

  • リスクのないプロジェクトには手をつけるな
  • プロジェクトがリスクだらけだということは、海図のない水域の乗り出すということだ。みごとにやってのければ、能力は伸びる・競争は優位に立てる・ブランドを築ける
    (*一部加工した引用です)

リスクの効能は、他にもいくつか紹介されています。
個人的に 「人材の成長機会を高める」 は覚えておきたい点でした。
挑戦することは新たな技術獲得につながる、学習機会として捉えるマインドは保ちたいですね。

リスク管理からの逃避

しかし、リスクは怖いですし、明確に見えるものでもなく、めんどくさいです。
都合の悪い現実を絶えず見ることになり、
起きるかわからないことに一定のコストを払い続けることになります。

「リスク管理をしない」理由 も紹介されており、

  • リスク管理の能力不足
  • 懸念することが多すぎる
  • やる前から弱音を出すな
  • データがないです

など、様々な文句が容易に思いつきます。

最終的には 「無視する」 という選択も取ってしまうもの。
短期的には良いかもしれまんせんが、長い目で見るといつか痛い目をみてしまう。

リスクを管理する前段階として、
リスクと向き合いやすい状態にすること も必要そうです。

個人的には、前節の効能のように「知識を身に着ける」のがその第一歩と考えています。さらに「損失回避を使う」のも一手と考えています。最悪のシミュレーションをしてみる。昨今ではAIと協力することで、シミュレーションの種類も精度も増すことができると期待しています。

リスク管理の実践編

本記事では、具体的なリスク管理方法は割愛します。
他の記事を参考にしていただき、今回はメモ程度を書いておきます。

  • リスクのトリガー

    • 発生する前に検知する条件を設定しておく
    • 「ここまで来たらやばい、何とかせんといかん」という境界
  • ソフトウェアの5大リスク

    • スケジュールの欠陥
    • 要求の増大・変更
    • 人員の離脱
    • 仕様の崩壊
    • 生産性の低迷
  • 現在稼得価値(EVR)

    • あるシステムのうち、開発が済んだ割合(%)
    • 稼働できる≒価値を生み出せる部分
  • インクリメンタル開発

    • 最低限稼働できるモジュールやクラス図を分割し、作業に起こす開発方法
    • EVRの計算にも必要
    • さらに優先度をつけることで、後半で「これ要らないね」とオマケもつきやすい
    • 優先度づけの2つの基準
      • 1.提供する価値
      • 2.リスクの洗い出しやすさ: 技術的にリスクのある部分を早めに顕在化する
  • 究極のリスク軽減は 「早く始める」

終わりに

当たり前の話が多かったですが、
このような基本は見直す機会がないとつい忘れてしまうものです。
自身の戒めのためにも文章として残し、見返すきっかけになれば良いと思いました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?