前に、日経ビジネスと、日経ソリューションビジネスでボケツッコミと書いたけど、今度は、日経ビジネスと、日経コンピューターでボケツッコミやってますね(^^)v
日経コンピューターの2005年2月7日号、13ページ「日本発で要求定義の標準手法確立へ」っていう、要求仕様の標準化、openthologyの話。その3段落目、
「ユーザー企業の要求精度が高まれば、システム開発の失敗は少なくなるはず」
これと、
日経ビジネスの2005年1月31日号、64ページ(富士ソフトABCの話)で、
「実は、建設会社の方が、情報サービス会社よりずっとまとも。きちんと設計書を作って、細かい部材の仕様まで決めてコストをはじき出している。だが、IT業界は、ビルに例えれば、まだ何階建てにするかも決まってないのに、いきなり見積もりを出す。」
この2つ、一見すると、(現場に出てない人には)同じ内容に見えますよね。
つまり、「きっちり設計書をつくれば」=「要求精度が高まれば」失敗は少なくなる
ところが、違うんですねえ。
つまりですね、今後、メルマガやブログで説明するけど、PMBOKのような、現行のプロジェクトマネジメント論や実際に現場でやられていることに従うと、要求仕様に入る前、あるいは途中で、もう、見積もりださないといけないんです。
だから、要求精度を高めても、
要求仕様を決める前(つまり、設計書をちゃんと作る前に)見積もりをだせ!
といわれてしまう現在のやりかたでは、
結局、要求仕様をきめたころには、見積もりも全て決まっているので、
要求仕様の精度を高めても手遅れ、結局、見積もりオーバーで失敗になってしまうのです。
つーわけで、日経コンピューターの見解は、結局、ボケになってしまうのです(^^;)
ウィリアムのいたずらが思うに、プロジェクトを成功させるには、方向が逆で、
・要求精度を高めなくても、ある程度のリスクをとりながら、見積もれる手法と、
・そのリスクに対するリスクヘッジ手法
について、研究しなければいけません。
まあ、この話を、今後、このブログとか、メルマガで話していくんですけど。。。
でも、だからって、今回のこの、「要求仕様の標準化」が無意味ってわけじゃなくって、大いに意義があるのですよ!
理由は、現在のプロジェクトが、標準にくらべて、どれだけ、ずれているかが分かるから。
たとえば、時刻で考えてみましょう。
アメリカと日本と、イギリスと、インドで、日が昇るときは、ぜーんぶちがいますよね。
だからって、時刻をきめなかったら、みんなで、いつ、会議しましょう!なんてことは
きめられない。アメリカ、日本、インドの人がネットで会議なんつーのもできない。
でも、ここで、イギリスを標準にして、標準時刻をきめ、日本は何時間ずれてる、インドは
何時間ずれてる!って決めれば、アメリカ、日本、インドの人が、ネット上で会議するのも
可能。イギリス時間(GMTいまはUTCなのかな?)で、何時って決めれば、あとは、
各国、GMTから、ずれてる時間を足せばいい。そうすれば、会議にみんな出席できる。
というわけで、要求仕様の標準がきまれば、このプロジェクトは、標準から、どこがずれているので、どういうリスクがあるので、どーいう管理をしなきゃいけないかが分かる。
そういう意味で、意義がありますね。
で、実際の内容については、ダウンロードできるみたい。
そのサイトは、ここ
http://www.openthology.org/download.htm
ウィリアムのいたずらも、いまダウンロードしたばかりなので、今度、内容を読んで
もし、なんか、ネタになりそうなことがあったら、このブログに書きたいと思いますです。
日経コンピューターの2005年2月7日号、13ページ「日本発で要求定義の標準手法確立へ」っていう、要求仕様の標準化、openthologyの話。その3段落目、
「ユーザー企業の要求精度が高まれば、システム開発の失敗は少なくなるはず」
これと、
日経ビジネスの2005年1月31日号、64ページ(富士ソフトABCの話)で、
「実は、建設会社の方が、情報サービス会社よりずっとまとも。きちんと設計書を作って、細かい部材の仕様まで決めてコストをはじき出している。だが、IT業界は、ビルに例えれば、まだ何階建てにするかも決まってないのに、いきなり見積もりを出す。」
この2つ、一見すると、(現場に出てない人には)同じ内容に見えますよね。
つまり、「きっちり設計書をつくれば」=「要求精度が高まれば」失敗は少なくなる
ところが、違うんですねえ。
つまりですね、今後、メルマガやブログで説明するけど、PMBOKのような、現行のプロジェクトマネジメント論や実際に現場でやられていることに従うと、要求仕様に入る前、あるいは途中で、もう、見積もりださないといけないんです。
だから、要求精度を高めても、
要求仕様を決める前(つまり、設計書をちゃんと作る前に)見積もりをだせ!
といわれてしまう現在のやりかたでは、
結局、要求仕様をきめたころには、見積もりも全て決まっているので、
要求仕様の精度を高めても手遅れ、結局、見積もりオーバーで失敗になってしまうのです。
つーわけで、日経コンピューターの見解は、結局、ボケになってしまうのです(^^;)
ウィリアムのいたずらが思うに、プロジェクトを成功させるには、方向が逆で、
・要求精度を高めなくても、ある程度のリスクをとりながら、見積もれる手法と、
・そのリスクに対するリスクヘッジ手法
について、研究しなければいけません。
まあ、この話を、今後、このブログとか、メルマガで話していくんですけど。。。
でも、だからって、今回のこの、「要求仕様の標準化」が無意味ってわけじゃなくって、大いに意義があるのですよ!
理由は、現在のプロジェクトが、標準にくらべて、どれだけ、ずれているかが分かるから。
たとえば、時刻で考えてみましょう。
アメリカと日本と、イギリスと、インドで、日が昇るときは、ぜーんぶちがいますよね。
だからって、時刻をきめなかったら、みんなで、いつ、会議しましょう!なんてことは
きめられない。アメリカ、日本、インドの人がネットで会議なんつーのもできない。
でも、ここで、イギリスを標準にして、標準時刻をきめ、日本は何時間ずれてる、インドは
何時間ずれてる!って決めれば、アメリカ、日本、インドの人が、ネット上で会議するのも
可能。イギリス時間(GMTいまはUTCなのかな?)で、何時って決めれば、あとは、
各国、GMTから、ずれてる時間を足せばいい。そうすれば、会議にみんな出席できる。
というわけで、要求仕様の標準がきまれば、このプロジェクトは、標準から、どこがずれているので、どういうリスクがあるので、どーいう管理をしなきゃいけないかが分かる。
そういう意味で、意義がありますね。
で、実際の内容については、ダウンロードできるみたい。
そのサイトは、ここ
http://www.openthology.org/download.htm
ウィリアムのいたずらも、いまダウンロードしたばかりなので、今度、内容を読んで
もし、なんか、ネタになりそうなことがあったら、このブログに書きたいと思いますです。