最近のメルマガで、以下のように見積もりの話を取り上げています。
業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実
「コピーされるほど儲かるシステム」の場合の見積もり例
システム開発において、一番重要なのは、リスクヘッジだと思うね！
完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！
長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ
しかし、無計画に書いたので、話が混乱してしまいました。
ちょっとまとめます。まず提案書を書くまでの内容の大枠は、「業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実」で書いた、以下のとおりです（不備もあるけど）。
（あ）まず、分かっている範囲の開発内容から想像して、各種要素技術
に分解し、その技術を使って、ユーザーが希望するものが、出来
そうか、読みきる。
→読みきれなければ、それがリスクとなる
（い）手順、予算、期間は大体決まっていることが多い
→そこで、それを、並べる
（う）（あ）を（い）の中に当てはめて、大丈夫かあ？って考える。
→ダメそうだったら、それは、リスク
（え）（あ）や（う）で起きたリスクを他のものに置き換えられないか等、
リスク回避の対応策を考える。
これが基準です。
でも、（い）だけやっても、実は、それらしい見積もりがかけてしまいます。
その例を、今度のメルマガ（１３話）で示します。
現実問題として、現場がわかっていないマネージャーが見積もりを立てる場合、（あ）、（う）、（え）はできません。したがって、そのような人が作成する場合、（い）だけの作業をした見積もりがでてきます。
この危険性についても、１３話で述べます。
で、（あ）のやりかたについてですが、これは、「完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！」に書かれている、
（あ－１）まず、ユーザーの利用の仕方の絵を書く
（あ－２）つぎに、その絵を実現するための技術を書く
（あ－３）その技術を実現する手順の絵を書く
になります（ブログでは、（１）、（２）、（３）とかいてありますが、あとあとの説明のため、（あ－１）、（あ－２）、（あ－３）と書きます）。
実際の開発では、この（あ）の部分について、ユーザーと話し合いますが、そのときの現場で起こる問題点が、「長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ」になります。
で、「 システム開発において、一番重要なのは、リスクヘッジだと思うね！ 」で挙げられている、以下のやりかたは、
（１）ＲＦＰを実現するには、どんな技術を使うか
→これが、思いつかないようなら、あなたに、その仕事は出来ないはず。
即、逃げることを考えよ
（２）それを、実際やったとしたら、どんなふうになるかのシナリオを作る
（３）そのシナリオが描けなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（４）そのシナリオどおりやって、予算、期間的に間に合うか。
間に合わなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（５）それは、ＲＦＰで言っている要望を満たしているか
この満たしているとは、言っていない要望も含む
満たしてなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（１）が、上記の（あー２）、（２）が、（あー３）になります。
（あー１）の部分は、書き忘れました(^^;)。
で、（４）は、（う）と（え）に該当します。（５）は、（え）のあとにやる作業です。
（かきわすれました ^^;)
結果として、まとめると、こんなかんじになります。
（あ）要素にわける
（あ－１）まず、ユーザーの利用の仕方の絵を書く
（あ－２）つぎに、その絵を実現するための技術を書く
（あ－３）その技術を実現する手順の絵を書く
（い）手順、予算、期間は大体決まっていることが多い。
→そこで、それを、並べる
なお、（あ）と（い）は、入れ替え可能。どちらが、先でも良い。
（う）（あ）のシナリオどおりやって、予算、期間的に間に合うか、
大丈夫かあ？って考える。
→ダメそうだったら、それは、リスク
（え）（あ）や（う）で起きたリスクを他のものに置き換えられないか等、
リスク回避の対応策を考える。
（お）で、大体システムが思いついたら、それは、ＲＦＰで言っている要望を
満たしているか、もう一度確認する。
→みたしてなかったら、他の案を検討する。
「「コピーされるほど儲かるシステム」の場合の見積もり例」で示した見積もりのしかたは、だめだめな例としてあげました。
（あ）もどきを行い、（い）を中心におこなったものです。
まじめに、（あ）の分析をしていない、かつ（う）以降をなにもやっていないものです。
でも、だめだめ加減がたりません。
もっと、だめだめな例を１３話のメルマガで示します。
でも、一番問題なのは、そんなだめだめな見積もりを仮に作ったとしても、ユーザーは気がつかず、その提案に乗ってしまうことなんだけどね。
業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実
「コピーされるほど儲かるシステム」の場合の見積もり例
システム開発において、一番重要なのは、リスクヘッジだと思うね！
完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！
長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ
しかし、無計画に書いたので、話が混乱してしまいました。
ちょっとまとめます。まず提案書を書くまでの内容の大枠は、「業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実」で書いた、以下のとおりです（不備もあるけど）。
（あ）まず、分かっている範囲の開発内容から想像して、各種要素技術
に分解し、その技術を使って、ユーザーが希望するものが、出来
そうか、読みきる。
→読みきれなければ、それがリスクとなる
（い）手順、予算、期間は大体決まっていることが多い
→そこで、それを、並べる
（う）（あ）を（い）の中に当てはめて、大丈夫かあ？って考える。
→ダメそうだったら、それは、リスク
（え）（あ）や（う）で起きたリスクを他のものに置き換えられないか等、
リスク回避の対応策を考える。
これが基準です。
でも、（い）だけやっても、実は、それらしい見積もりがかけてしまいます。
その例を、今度のメルマガ（１３話）で示します。
現実問題として、現場がわかっていないマネージャーが見積もりを立てる場合、（あ）、（う）、（え）はできません。したがって、そのような人が作成する場合、（い）だけの作業をした見積もりがでてきます。
この危険性についても、１３話で述べます。
で、（あ）のやりかたについてですが、これは、「完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！」に書かれている、
（あ－１）まず、ユーザーの利用の仕方の絵を書く
（あ－２）つぎに、その絵を実現するための技術を書く
（あ－３）その技術を実現する手順の絵を書く
になります（ブログでは、（１）、（２）、（３）とかいてありますが、あとあとの説明のため、（あ－１）、（あ－２）、（あ－３）と書きます）。
実際の開発では、この（あ）の部分について、ユーザーと話し合いますが、そのときの現場で起こる問題点が、「長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ」になります。
で、「 システム開発において、一番重要なのは、リスクヘッジだと思うね！ 」で挙げられている、以下のやりかたは、
（１）ＲＦＰを実現するには、どんな技術を使うか
→これが、思いつかないようなら、あなたに、その仕事は出来ないはず。
即、逃げることを考えよ
（２）それを、実際やったとしたら、どんなふうになるかのシナリオを作る
（３）そのシナリオが描けなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（４）そのシナリオどおりやって、予算、期間的に間に合うか。
間に合わなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（５）それは、ＲＦＰで言っている要望を満たしているか
この満たしているとは、言っていない要望も含む
満たしてなかったら、それはリスク
→他のやり方で実現できないか、考え直す（２）へ
（１）が、上記の（あー２）、（２）が、（あー３）になります。
（あー１）の部分は、書き忘れました(^^;)。
で、（４）は、（う）と（え）に該当します。（５）は、（え）のあとにやる作業です。
（かきわすれました ^^;)
結果として、まとめると、こんなかんじになります。
（あ）要素にわける
（あ－１）まず、ユーザーの利用の仕方の絵を書く
（あ－２）つぎに、その絵を実現するための技術を書く
（あ－３）その技術を実現する手順の絵を書く
（い）手順、予算、期間は大体決まっていることが多い。
→そこで、それを、並べる
なお、（あ）と（い）は、入れ替え可能。どちらが、先でも良い。
（う）（あ）のシナリオどおりやって、予算、期間的に間に合うか、
大丈夫かあ？って考える。
→ダメそうだったら、それは、リスク
（え）（あ）や（う）で起きたリスクを他のものに置き換えられないか等、
リスク回避の対応策を考える。
（お）で、大体システムが思いついたら、それは、ＲＦＰで言っている要望を
満たしているか、もう一度確認する。
→みたしてなかったら、他の案を検討する。
「「コピーされるほど儲かるシステム」の場合の見積もり例」で示した見積もりのしかたは、だめだめな例としてあげました。
（あ）もどきを行い、（い）を中心におこなったものです。
まじめに、（あ）の分析をしていない、かつ（う）以降をなにもやっていないものです。
でも、だめだめ加減がたりません。
もっと、だめだめな例を１３話のメルマガで示します。
でも、一番問題なのは、そんなだめだめな見積もりを仮に作ったとしても、ユーザーは気がつかず、その提案に乗ってしまうことなんだけどね。
アクセス
トータル
ランキング
