リスクの回避と低減
リスク分析・評価のプロセスで順位付けられたリスクは、その優先順位に基づき、対策を進めていくことになります。 リスク対策には大きく分けて、下記の４つの方法があります。 リスク回避 リスク低減 リスク移転 リスク保有 それぞれの対策が適するリスクを、先ほどのリスクマトリクスに当てはめると、おおよそ以下の通りとなります。 少しいびつな形をしていますね。 教科書的には、マトリクスをきれいに４分割し、右上に「回避」、右下に「低減」、左上に「移転」、左下に「保有」と表示するのですが、実務上は、その通りにはなりません。 企業それぞれのリスク特性によって上の配分は変わりますが、抱えるリスクの１／４を保有できるような企業はほとんどないでしょうし、リスクの１／４を回避してしまえば、事業そのものが大幅に縮小もしくは事業が成り立たなくなってしまいます。 このプロセスでは、リスクの特性と、かかるコストを睨みつつ、
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
第10回 損害規模を縮小し，発生頻度を減らすリスクコントロール手法：ITpro
第10回 損害規模を縮小し，発生頻度を減らすリスクコントロール手法 ITプロのためのリスクマネジメント入門 記事一覧へ >> 第6回と第7回でリスクの調査方法を，第8回と第9回では分析の結果を数値化し，リスクマトリクスにプロットして調査結果の全体像をはっきりさせることを学びました。今回からは，プロットされた各リスクへの対策について解説します。 ◆大きく2つに分けられるリスク対策手法 リスク対策手法にはさまざまなものがあり，実際にリスク対策を行う時には，いくつかの手法を組み合わせることが多いものです。ここではリスク対策を大きく2つに分けて考えます。損害の発生を防止または軽減するための手法「リスクコントロール」と，損害発生に伴う経済的損失を補填するための資金繰り手法「リスクファイナンシング」です。 もう少し説明を加えると，リスクコントロールは組織やシステム，技術的工夫によって，まずリスク固有の
ビジネスのリスクはこうすれば低減できる！ / SAFETY JAPAN [浦嶋繁樹氏] / 日経BP社
リスクコントロールによるリスク処理手法 まずは、次の図を見ていただきたい。第5回で紹介したリスクマトリクスである。 念のために説明しておくと、１～４のボックスに該当するのは、次のようなリスクである。 １－しばしば発生して、危険が大きいリスク ２－たまにしか発生しないが、危険が大きいリスク ３－しばしば発生するが、危険は小さいリスク ４－たまにしか発生しないで、危険も小さいリスク リスクコントロールによってリスクを処理する場合、まず現在扱っているリスクが，このマトリクスのどの部分に当たるのか、正確にプロットすることが重要である。 もちろん、その前に、リスクマトリクスの軸をきちんと定義するべきなのは言うまでもない。 たとえば、横軸の「頻度」については、リスク発生の確率を基準にするのか、件数を基準にするのかを決定する。また、確率をとった場合には、中央のラインを50%にするか30%にするかと
デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ ― ＠IT
ユーザーの要件定義があいまいでシステム開発中も修正に次ぐ修正。プロジェクトは大幅に遅れて、予算が超過。しわ寄せは下請け、孫請けへ。デスマーチ……。新3Kともいわれるこんな日本のIT業界が2009年4月に大きく変わるかもしれない。そのきっかけとなるのが「工事進行基準」の原則義務付けだ。 【関連記事】 工事進行基準を分かりやすく解説してみよう【基本編】 工事進行基準を分かりやすく解説してみよう【対応編】 工事進行基準（用語解説）とは会計基準の変更によって2009年4月にシステム・インテグレータ（SIer）など受注ソフトウェア開発業に原則として義務付けられる収益の計上方法。開発期間中にその売り上げと原価（費用）を、工事（ソフトウェア開発、システム開発）の進捗度に応じて、分散して計上する仕組みだ。 これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」
[ThinkIT] 第1回：プロジェクト管理力を強化するための具体的プラン (1/3)
最近、日本の国際競争力は低下傾向にあると言われています。家電や自動車、ゲームなどまだまだ元気な産業もあるでしょう。しかし、造船や鉄鋼、半導体のようにかつては花形だったのに、その地位を奪われつつある産業も少なくありません。まして、建設・土木業やIT産業は、国内需要に甘んじて努力を怠り、一度も国際競争力を持てる水準になったことがありません。 IT業界の一員として、現在の国際競争力のなさに非常に歯がゆい思いがしています。しかし、なんとか巻き返しをと考えてみても、新技術の創造性、要素技術の保有、開発生産性、そして仕様や契約面でも、なかなか勝てる部分が思い当たりません。IT関連技術やソフトウェア製品は、米国やイスラエルなどの海外製品に圧倒され、残った労働力も中国やインド、韓国の技術者たちに脅かされつつあります。 そんな中、唯一これが突破口になるのではと期待しているのが「プロジェクト管理」です。プロジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
