☆信州大学附属図書館の所蔵はこちらです☆ https://www-lib.shinshu-u.ac.jp/opc/recordID/catalog.bib/BA64988516

リスク見積もるのは難しいよなぁ。Risk Mitigation CostとRisk Exposure Costをどう適切に見積もるか。高過ぎてもダメだし、低すぎてもあれだし。プロジェクトマネジメントにおけるリスクの考え方の基本。

そもそもシステム開発プロジェクトにおけるリスク管理とは何なのか、から具体的なハウツーまでコンパクトにまとめられており、非常に有益に感じた。 特にリスクを分析していく過程で「誰が負うべきリスクなのか？」は重要な観点に思えた。なぜなら「誰が」の選択肢が観点として無いまま分析を進めると、結果自身が負えるリスクしか直視しない（手に負えないリスクは無視する）という行動を度々目にするから。 しかし、理屈をわかっていてもうまく実践されないのがリスク管理の常だが、これも随所に引用されるウィリアム・キングドン・クリフォードの「信念の倫理」を使ってうまく解説してくれる。 曰く、信念こそが人がリスクから目を背ける理由となりえるものであり、確たる証拠もないのにリスクをないものと取り扱うのは罪である、というようなことが書かれている。 邪かどうか、信念の性質に関わらず、信念そのものが現実から目を遠ざけリスク軽視という罪を生み得る。うーん、深い。

語り口は軽く、とても読みやすい。プロジェクトマネジメントにおける、今でも「あるある」とうなづけるような例と陥りがちな罠が語られており、今も昔も変わらない（むしろ悪化している）現状に若干絶望したりもする。 入門本とも言えるし、内容もかなり王道的。 切り口は「リスクマネジメント」であり、プロジェクトマネジメントについて学習してもなお敢えて目を逸らしがちな部分について芯を食った説明をしている。 良本でした。

リスクに対する考え方が平易に説明されています。書かれたのがかなり昔で、いま活かせるかというと難しいと思いました。まずは計測すること。確率分布的にリスクを捉える点や上層部に対してどういう説明をすべきかまで言及されており、あらためて勉強になりました。

リスク管理について書かれた本。 私ぎ勉強になったと感じたのは、リスクの管理手順がより具体的に書かれているところである。 中では、リスクの扱い方法として、回避、抑制、軽減、かわすの4要素があると記載されており、 回避、リスクを伴う部分をやらないこと 抑制、リスクが発生した時のために時間と資金を準備しておくこと 軽減、リスクが発生する前に抑制コストを軽減する措置をとること 受容、なにもしないこと とある。 実際のプロジェクトだとどう扱うか、などと対比してみると、原則が理解できると思う。

ソフトウエアのリスク管理について書いてある。TOCのゴールドラットとかぶっているところもあり、信頼できる。マネージャーならどうせリスクを背負わなきゃならないんだから、それを楽しみましょ。

ソフトウェア開発におけるリスク管理について書かれた本。といってもソフトウェア開発に限らずいろいろなプロジェクトに適用できると思う。 リスクが発生しないように管理し、リスクが発生したときのためにどのように準備をしておき対処をするか、というのは実際にやってみると非常に難しいのだが、3部の「リスク管理の方法」が考え方や手法として参考となる。 何度か読んで実践することが大事だと痛感している。 本書を託していったTさんに幸あれ。

正直、ふーん、というか、ああ、この人のいつものか。という感じ。リスク管理の観点としてはもちろん大事なことが書かれていたとは思うけど、それを学ぶにはこの人の本でなくていいかな。

タイトルのセンスが抜群。ほれぼれ。 リスクがないプロジェクトには価値がない。 熊とワルツを踊らなきゃ。 で、私が結構勘違いしていたのが、これはシステム開発者の方向けの本だったのですね。 かといって全然身の回りに使えないわけではなく、むしろプロジェクト管理においての基本的なことを学べてなるほどなーと思いました。 自分の仕事に関連したプロジェクトのひとつに大規模なシステムの開発があって、私は直接関わったことはないもののとにかく様々なトラブルトラブルでスケジュールが遅れ、コンサルが入ってベンダーを叱りまくってお尻を叩いて叩いて幹部級まで呼びつけてとかまぁとにかくいろいろありました。 でも、こんなにトラブルって通常よくあることなんですか？という問いに対してコンサルさんは程度の差はあれどあります、驚くべきことではありませんと答えていたのも印象的で。そんなもんなんですね。 この本にも出てきた「ナノパーセント 日」、つまり何にも問題なくプロジェクト達成できる最楽観スケジュールでみんな考えがちなんだろうね。考えがちというか、政治的事情やらなにやらでお尻が決まってしまってデスマーチ不可避になるとかね。 「不確定性の幅は、その組織の開発プロセスにどれだけノイズがあるかで決まる（p67）」というのがこの本のキーとなる文章。

熊とワルツを踊る = リスクの評価、抑制、軽減を行うこと。 インクリメンタル開発の下りを読んで、今時だとアジャイル開発でやってそうだなーと思ったら関連文献に XPエクストリーム・プログラミングが載ってた

なぜリスクを管理するのか。なぜリスクを管理しないのか。リスク管理の方法。数量化の方法。嘘かまことか。訳の問題なのか日本語の文章がわかりづらい。リスクのないプロジェクトには手をつけるな。コアリスク、スケジュールの欠陥、要求の増大、人員の離脱、仕様の崩壊、生産性の低迷。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが効果を上回ることがあきらかだからだ。

おもしろおかしく書いてあるのでついつい笑って済ませてしまいたくなりますが、本書の内容を知らずにある程度規模の大きなソフトウェア開発をすると、たぶん相当イタイ目に遭います。 ただ、一度くらいイタイ目に遭っていた方が、実感を持って本の内容を受け止められそうなので、ある程度開発経験のある人向けの「リスク管理」の本なのかなと思います。 でも、駆け出しのプログラマであっても「ナノパーセント日」は知っておくときっと役に立つと思います。 「ナノパーセント日」は、プログラマが予想するプログラムの完成予定日。 ナノは10億分の1であり、ここではほとんどゼロ、という意味。 つまり、この日までにプログラムが完成する可能性は限りなくゼロに近い、と言う主張です。 実際にプログラムが完成するまでにかかる期間は、経験的に、予想の1.5～3.0倍と言われています。 プログラマはリスクを織り込まない楽観的な見通しを立てる傾向が強い（技術者の性？あるいは神ならぬ人間の能力の限界？）、という戒めです。 自分は慎重だと思い込まず、計画は楽観過ぎないか、自分に都合のよい仮定をおいていないか見直してみる、これがきっとリスク管理の第１歩です。

人々合意することになっている協力することになっている根深い対立があってそれができなくても表向きは取り繕われることが多い。 スペースシャトルの開発において、氷点下で仕様通りの性能を期待できないことを知っている人は大勢いた。しかしそれを言わなかった。それはそこら中の会社でも誰もリスクを口に出さない理由と同じである。以下のような不問律が企業文化ニコニコ漏れている。マイナス思考しない。解決策が見つからない問題を持ち出さない。問題だと証明できないことを問題だと言わない。水をささない。すぐに自分で解決を引き受けるつもり脳内問題を口に出すな。 破綻的結果についてのブレインストーミングをやってみる。 どうしてもいるものだという選定理由。

http://kashiwabaray.com/blog/index.php?itemid=395 リスク管理がテーマの1冊となります。リスク管理は仕事でも重要となるので、参考となる1冊でした。「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」も面白かったですが、こちらもおすすめできる1冊です。 ■リスクを管理すべき理由 ―リスク管理は積極的にリスクをとれるようにする 一般的な企業文化の中でリスク管理が難しいのは、不確定なものを系統的にあつかうことになるからだ。 ―リスク管理は不意打ちを防ぐ この業界には、「やればできる」思考が蔓延している。そのせいで、「できない」ことを示すような分析は叩かれる。リスク管理をすれば、多少の「できない」思考は許容される。リスク管理のしくみを導入すれば、少なくともある程度の時間は、人びとにマイナス思考を許すことになる。 ―リスク管理は成功するプロジェクトを作る ―リスク管理は不確定要素を限りあるものにする 無限の不確定要素の前では、人はリスクを避けるか、自暴自棄になるかのどちらかである。どちらも最悪だ。 ―リスク管理は最小限のコストによる保険である 不確定要素がわかれば、自分の身をしっかり守るためにどれぐらいの備えが必要かもわかる。 リスクを管理した上でリスクを受け入れるのと、リスク管理をしないでリスクを受け入れるのは訳が違う。リスクを避けるのではなく、リスクに積極的に立ち向かおう。 【1読書1アウトプット】 リスクに積極的に立ち向かう

☆4 本編よりも、付録A「信念の倫理」に強く共感したよ！私が科学好きなのも、知ることが楽しいのも、全てここに繋がってた。 世代を重ねて蓄積された人類の財産にアクセスしながら、これからも責任をもって、注意深く私の信念を言葉にしていきたいと思ったよ。 リスク管理は、もっと大きな仕事を扱うようになったら徐々にこの本から取り入れていけばいいかな、と思った。 読み物としても、飽きずに面白く読めたよ。

前半は抽象的で啓蒙的な内容。ソフトウェア開発に限らず様々なプロジェクト管理に適用できる「考え方」が記述されている。 後半は実践的な内容となり、リスク管理が業務に組み込まれている環境でなければ取っ付きにくい。

リスクとは何か？ 実例を交えて書かれています。 仕事でリスクを考え始めたときに読むことを薦めます。

先輩から借りた。思えばリスクを想定しないまま（または、わかってて放置したまま）走ることが、ままある。おこちゃまなPJ管理から抜け出さねば。。

「え? 今頃、読んでるの?」と言われそうではあるが、リスク管理の名著。"熊とワルツを" ってゆータイトルで、そんな中身、想像できるもんか!! (^^; 日本では "リスク" を "危険" と訳すせいか、"ない方が良いもの" と捉えられているように思う。"リスク管理" が "リスクヘッジ" を意味しているように思えてならないのだが、そーではなくて、"期待通りにうまくゆかない可能性" ぐらいの意味が妥当なんぢゃなかな? …と思われる。うまく付き合ってゆく対象だと思って欲しいところ。 家を出てから会社に行くまでに交通事故に遭うかもしれない…とか、エンゲージリングを買ったもののプロポーズを断られるかもしれない…なんてのもリスクだ。通勤しないとか、プロポーズしないとかで、リスクを完璧に回避できるけれども、多くの人は稼ぐために毎朝出勤するだろうし、勇気を持ってプロポーズをしたりなんかする訳だ。保険に入るとか、慎重にタイミングを見計らうとか、日常の中でリスクヘッジ & リスクテイクをしている訳だけれども…。 それをプロジェクト管理において、もっと論理的に展開しようというのが本書の内容だ。リスクはテイクし過ぎてもヘッジし過ぎてもうまくゆかない。そのバランスを可能な限り論理的に進めてゆくノウハウが詰まっている。世の中、白か黒かハッキリしていれば単純明快なのだけれども、そう簡単にはゆかない。持っているスキルや周りの環境によって、妥当な判断は刻一刻と変化する。 勇気を持って…だけど無謀ではなく…新たなチャレンジをするために、本書を一読されたい。

何故、欧米人が新しいことや難しいことに取り組むことを「チャレンジング」と言うのかが分かる。すなわち、こういったことはすべて、リスクを取ることになるからだ。リスクとその成果を如何に数値化するか、を求めている。

プロジェクトにおけるリスク管理の大切さを説いた本。著者本人の体験等ケーススタディがしっかりと書かれているので読み易かった。 目に見えない潜在的なリスクを想定して、(想定したリスクが起こる前、起こった後の)対策を考えておき、しっかりと全体の工程をウォッチしていくという事が大切なんだと思った。が、まだまだ今のプロジェクトへうまく適用させる方法が思いつかない･･･(;_;) まだまだ消化できてないのだろうなぁ･･･ また、もう一度読んでしっかりと消化しておきたいと思った。

リスクを回避するのではなく、リスクを計測し管理する手法を提唱する良い本です。主な対象はプロジェクトの管理責任にある方、またはその上層部だと思います。

まず非常に楽しい。コミカルに書かれていて読みやすい。 しかし内容は怖い。ソフトウェア開発におけるリスク管理が形骸であることを幾つもの面や事象から指摘している。 ゆえにとても面白い。 しかしデマルコ／リスターの本は面白く、とても納得いくのだが、著者自身も作中で書いているようにこれを現場に導入するにはハードルが高い。 しかし現状の不足、目指すべき高みを意識できる良著。

・良書。プロジェクトのリスク管理の入門書。 ・投資クラスタで馴染みのリスク・リターンを他の事に生かせないかと思い読んでみた。 ・モンテカルロ・シミュレーターとか面白そう。 ・紹介されているリスク管理ツールRiskologyは、残念ながらダウンロードページが既に削除されている模様 ・ただしグーグルのキャッシュから辿った所、ツール自体はまだ置いてある模様 ・Riskology 　http://www.systemsguild.com/riskology/RiskologyV4.xls ・マニュアル 　http://www.systemsguild.com/riskology/RiskologyManual.pdf ・日本語マニュアル 　http://www.jttk.zaq.ne.jp/bacae808/Risk_yaku/japanese.doc

定番図書のひとつ～ プログラム主体の立場からすると、やらなければいけない事項 というよりは、やって欲しい事項が記載されている。 内容としては7年前といささか古いので、その後の進展が あるかもしれない、その点については他の人に譲る。 むしろ巻末に付随している、ウィリアム・キングドン・クリフォードの 「信念の倫理」の抜粋が、個人的にはこの本を読んでの最大の収穫だった。 （暴論だが、この論文の理念を具象化した一つが本書・・・？）

半分同意で半分うーん、といった感じ。 現在のＩＴのプロジェクトが決められたコストと期間での実行を要求されているのには同意。 信じる権利があるものだけを信じることを『リスク管理』という、という考え方にも賛同。 違和感の部分は、ＰＭＢＯＫなどのフレームワークを勉強していたせいか、現代的なプロジェクトはこの本に書かれているようなことを、少なくとも半分程度は克服している、と感じている点。 リスク管理を深めていくよりも、リスク管理を含めたプロジェクトマネジメントのレベルをあげていくことが不幸な仕事を無くしていくと信じる。

置き土産に @you_got 殿からいただいた（んだよね？）本。リスク管理について正面から理論的に述べています。著者が言うナノパーセント日がふつう期限になっちゃうんだけど、リスク図を見せながら「その日にできる確率はナノパーセントです。その2か月後までにできる確率なら70％です」なーんて言っても「ガタガタ言わずに期限までに上げろや」ってなるんだよなー。で直前になって、遅らせることができる機能を1.5次開発に回すってことになる。アジャイルとは言ってないけど、インクリメンタルな開発で機能を分けて段階的に納品するといいよってことをこの本でも言っていた。あと、「完成が遅れるプロジェクトのほとんどは、あまりにも工期が短いためだ」というのは印象的。開発の稟議を通すのに、あーでもないこーでもないってやってるからなんだよなー。えらい人自らがプロジェクトを失敗へと導いている。

リスクをとらない（回避する）だけのプロジェクトに価値はない。 新しい領域に足を踏み入れる場合、必ず何かしらのリスクは存在するもので、生み出そうとする価値が大きければ大きい程、リスクが発生する可能性も高くなる。 リスクを取らないということは、新しい領域へのチャレンジがなくプロジェクトメンバーや会社の成長にもほとんど寄与しない。 リスク管理の正しい方法を知ることで、新しく、そして価値のあるプロジェクトへ安心して参画することが可能となる。 本書はそんなリスク管理のノウハウを具体的に示しています。 私自身は大規模なプロジェクトへの参画経験がまったくないため、実感をもって本書のノウハウを吸収することはできませんでしたが、いつの日か役に立つのではと思っています。

リスクを積極的に取りましょう、リスクをコントロールしましょうと言う本。 リスク管理の方法などが書かれている。 当時、客先に飛ばされて１プログラマだったから活かし用が無かったけど、今見たら違うのかも？

さすがデマルコという感じの読みやすく分かり易い本になっていると思います。 リスク管理の定義、なぜリスク管理をしないか(できないか)から始まり、リスク管理の方法へと続くが、小難しい数式等を用いず理解し易いです。 この本を読むと、どうして多くのプロジェクトで 「何か奇跡的な事が起きるかのような楽観的なスケジュールを立てるのか」 について理解できると思います。

リスクとはそもそも何か、というところから始まって、リスク管理がうまくいかない理由について述べられている。そしてリスク管理が行われない理由についても述べられている。（例：早く終わる可能性のあるスケジュールをひくことが許されないなど）この項が一番参考になった（苦笑）。 あと身にしみて感じるところがあったのが、問題の原因はより早い時期に発生しているが、問題を認識し始める時期（天罰期という　笑）についての説明とその対処法。バージョンごとにリリースするというのが意外と現実的な方法だと分かった。 この本が扱う範囲は入門から中級までかなり広いと思うがリスク管理をやる上で読んでおいてよい1冊だと思う。[2007/1/4]

ちょうど、あるプロジェクトでリスクマネジメントについて非常にナーバスになっていたときいに読みました。 プロジェクトマネジメントのなかでのリスクの考え方について随分参考になりました。 ナーバスになりすぎないで、早めはやめの対応が重要であることを説いており、実際の場面でも応用の聞く内容だったと思います。

リスク対策を洗い出して検討しておく。たったそれだけのことが出来ないプロジェクトがどれほど多いことか。リスク管理に敏感になり始めた人に必読の本。

リスク管理に注目したデマルコの著作。「リスクが無いプロジェクトは、やる価値もない」とリスク回避をこき下ろした上で、納期に遅延(リスク)を見込まずに、バラ色の未来だけを描いてスケジュールを引く従来の慣習を「子供の遊び」と厳しく批判する。10年後には「ピープルウェア」と並ぶ古典になっているかもしれない。