機能のブログで、「見積もりの期間で、できそうかっていうことを考えて、リスクがあればヘッジする」というやり方について、今日は書きます。
その前に、前提として。。。
システム開発の受注の方法において、最近のトレンドは、
まずＲＦＰ（提案依頼書）をもらってから、
見積もり、検討をして
提案書を書く。
という流れだと思います。で、その提案書の中に、期間や金額を書き入れるか、まあ、書かない場合でも、ある程度決めていくと思います。
このとき、だいたいユーザーの都合で、期間や金額は、きまってしまう。
また、会社で、仕事をやる場合は、ある程度、作業の流れは決まっている。
だから、ここで、ＳＥができることは、与えられた期間、金額で、ＲＦＰに書かれていることができるか？やる場合のリスクを考え、問題があったら、ヘッジするっていうことしか、出来ないわけです。で、その結果を、提案書に書くと。。
で、そのリスクのマネジメント方法ですが、PMBOKだと
（プロジェクトマネジメント知識体系ガイド
PMBOKガイド2000年版 日本語・公式版
プロジェクトマネジメント協会から引用）
・リスクマネジメント計画
・リスク識別
・定性的リスク分析
・定量的リスク分析
・リスク対応計画
・リスクの監視・コントロール
となります。
実際、提案書を作る程度の状況では、定性的リスク分析、定量的リスク分析は出来ませんし、リスクマネジメント計画なんつー堅いものを作る必要も無い。
つまり、リスクを挙げて、（リスク識別）それが起こったら、どうする（リスク対応計画）を、徹底的に、読みきっていき、「これなら出来る！」というところまで、ありありと、絵が書けるかどうか、時間のある限り、詰めていくといいうことになります。
そういう意味で、PMBOKでは、リスク識別として、特性要因図なんか使ってたけど、それより、シナリオを読んでいくって言うほうが、重要ですね。
つまり、こんなかんじ。
（１）ＲＦＰを実現するには、どんな技術を使うか
→これが、思いつかないようなら、あなたに、その仕事は出来ないはず。
即、逃げることを考えよ
（２）それを、実際やったとしたら、どんなふうになるかのシナリオを作る
（３）そのシナリオが描けなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（４）そのシナリオどおりやって、予算、期間的に間に合うか。
間に合わなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（５）それは、ＲＦＰで言っている要望を満たしているか
この満たしているとは、言っていない要望も含む
満たしてなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
で、（５）までＯＫになれば、そのやり方でＯＫ。それで提案する。
提案書は、その案で書ける。
でも、（５）までＯＫにならないのに、その仕事を受けなければいけないことがある。
そういうときは、できるだけ、問題になるところを避けられる、技術的方法を見つけるって
いうことになる。
だから、置き換え方法、他のやり方が見つからないと、結局、行き詰まって、開発不能になる。
たとえば、Web系で開発してしまった場合、ユーザーから、入力をタブで移動させて
くれないと、やりにくい！といわれてしまった場合、HTMLしか知らない人の場合、
もう、開発不能になってしまう。
でも、毎日、そんな、「ユーザーインターフェース変えろ！」とか言われたら、気がめいって、病気（うつ病とか）になっちゃいますよね。
でも、ウィリアムのいたずらだったら、じゃあ、
そこjavaのappletで？
いや、めんどーならWindowsで画面を開発して、ポート80番でSocketつかって、送ります？
とか、いろいろ回避案が出てくる。
そういう意味で、ＳＥさんは、自分が出来る技術をいろいろ持ってたほうが、身の安全を図れると思う。ようするに、それが、技術における、リスクヘッジだね。
でもでも、じゃあ、ウィリアムのいたずらのやってるシステム開発って、
リスクを分析して
シナリオ作って
その中で、取れるリスクを取っていく
っていうことじゃん。それじゃー、株式投資と同じじゃん。
じゃあ、株式投資のほうが、手っ取り早くていいじゃん！
っていう結論になりますよね。これは、この前のヒモの話とは違い。。。
そのとおり。。。という雰囲気、（開発とは、関係ないけど）最近ありますね。
IT産業のIは、InfomationのIじゃなくって、investmentのＩじゃないかって。。。
そんな話、今度書こうかな。。。
その前に、前提として。。。
システム開発の受注の方法において、最近のトレンドは、
まずＲＦＰ（提案依頼書）をもらってから、
見積もり、検討をして
提案書を書く。
という流れだと思います。で、その提案書の中に、期間や金額を書き入れるか、まあ、書かない場合でも、ある程度決めていくと思います。
このとき、だいたいユーザーの都合で、期間や金額は、きまってしまう。
また、会社で、仕事をやる場合は、ある程度、作業の流れは決まっている。
だから、ここで、ＳＥができることは、与えられた期間、金額で、ＲＦＰに書かれていることができるか？やる場合のリスクを考え、問題があったら、ヘッジするっていうことしか、出来ないわけです。で、その結果を、提案書に書くと。。
で、そのリスクのマネジメント方法ですが、PMBOKだと
（プロジェクトマネジメント知識体系ガイド
PMBOKガイド2000年版 日本語・公式版
プロジェクトマネジメント協会から引用）
・リスクマネジメント計画
・リスク識別
・定性的リスク分析
・定量的リスク分析
・リスク対応計画
・リスクの監視・コントロール
となります。
実際、提案書を作る程度の状況では、定性的リスク分析、定量的リスク分析は出来ませんし、リスクマネジメント計画なんつー堅いものを作る必要も無い。
つまり、リスクを挙げて、（リスク識別）それが起こったら、どうする（リスク対応計画）を、徹底的に、読みきっていき、「これなら出来る！」というところまで、ありありと、絵が書けるかどうか、時間のある限り、詰めていくといいうことになります。
そういう意味で、PMBOKでは、リスク識別として、特性要因図なんか使ってたけど、それより、シナリオを読んでいくって言うほうが、重要ですね。
つまり、こんなかんじ。
（１）ＲＦＰを実現するには、どんな技術を使うか
→これが、思いつかないようなら、あなたに、その仕事は出来ないはず。
即、逃げることを考えよ
（２）それを、実際やったとしたら、どんなふうになるかのシナリオを作る
（３）そのシナリオが描けなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（４）そのシナリオどおりやって、予算、期間的に間に合うか。
間に合わなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（５）それは、ＲＦＰで言っている要望を満たしているか
この満たしているとは、言っていない要望も含む
満たしてなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
で、（５）までＯＫになれば、そのやり方でＯＫ。それで提案する。
提案書は、その案で書ける。
でも、（５）までＯＫにならないのに、その仕事を受けなければいけないことがある。
そういうときは、できるだけ、問題になるところを避けられる、技術的方法を見つけるって
いうことになる。
だから、置き換え方法、他のやり方が見つからないと、結局、行き詰まって、開発不能になる。
たとえば、Web系で開発してしまった場合、ユーザーから、入力をタブで移動させて
くれないと、やりにくい！といわれてしまった場合、HTMLしか知らない人の場合、
もう、開発不能になってしまう。
でも、毎日、そんな、「ユーザーインターフェース変えろ！」とか言われたら、気がめいって、病気（うつ病とか）になっちゃいますよね。
でも、ウィリアムのいたずらだったら、じゃあ、
そこjavaのappletで？
いや、めんどーならWindowsで画面を開発して、ポート80番でSocketつかって、送ります？
とか、いろいろ回避案が出てくる。
そういう意味で、ＳＥさんは、自分が出来る技術をいろいろ持ってたほうが、身の安全を図れると思う。ようするに、それが、技術における、リスクヘッジだね。
でもでも、じゃあ、ウィリアムのいたずらのやってるシステム開発って、
リスクを分析して
シナリオ作って
その中で、取れるリスクを取っていく
っていうことじゃん。それじゃー、株式投資と同じじゃん。
じゃあ、株式投資のほうが、手っ取り早くていいじゃん！
っていう結論になりますよね。これは、この前のヒモの話とは違い。。。
そのとおり。。。という雰囲気、（開発とは、関係ないけど）最近ありますね。
IT産業のIは、InfomationのIじゃなくって、investmentのＩじゃないかって。。。
そんな話、今度書こうかな。。。
アクセス
トータル
ランキング
