2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2009年10月 | トップページ | 2009年12月 »

2009年11月

2009年11月27日 (金)

【共通フレーム2007第2版】要求/要件/ニーズの関係

P35において、「②ニーズ」が次のように説明されている。

「要求/要件以前のステークホルダの意図、要望、思い、夢などである。必要性が十分検討されていないか、曖昧な状態のものである。企画プロセスや要件定義プロセスは、ニーズを十分検討し、要求/要件まで変換するプロセスと考えられる」。

さて、旧版においては、「要求」が「システム化されるかどうかはまだ決まっていない状態にある要望事項」となっている。

難しい。

第二版では、ニーズの一つとして「要求/要件以前のステークホルダの要望」が挙げられている。
一方、旧版では、要求が「…システム化されるかどうかはまだ決まっていない状態にある要望事項」と定義されている。

「要望」をキーに考えると、旧版でいう「要求」は、第二版でいう「ニーズ」の一部と思われるが…。

そう考えると、第二版の要求・要件の定義変更とあいまって、旧版中の「要求」「要件」の記述は、第二版では意味が異なるので、共通フレーム準拠をうたうプロセスは、すべての「要求」「要件」「ニーズ」に対する記述について見直す必要が生ずる(まあ、普通はそんなことはしないと思うが、本来的にはすべき)。

この「ニーズ」という概念の定義は第二版で追加されたものだ。
要求、要件の定義変更に伴い旧版では要求が担っていた部が「ニーズ」となったと考えられる。

しかし、旧版の「要求」の全部が「ニーズ」になったのか、一部が切り出されただけなのか、第二版の記述だけではわからない。

さらに理解を難しくさせるのは、次の記述があることである。

「(注)ニーズと要求/要件は、プロセスによって相対的なものである。企画プロセスは、経営や市場のニーズから事業要件を導く。事業要件は、次の要件定義プロセスにとってはニーズであり、このプロセスでさらに検討を重ねて業務要件を作り上げる」。

このような注を入れてしまうと、わざわざ「要求」「要件」「ニーズ」と3つも定義する意義が分からなくなる。

「要求」「要件」の二つで十分ではなかろうか。

そもそも「要求」「要件」さえ、英語では同じ「requirement」の訳なのだから。

少なくとも、用語の定義であるこの部分で「ニーズと要求/要件は、プロセスによって相対的なものである」と書かれてしまうと、それ以降どう読めば良いか戸惑うのではないだろうか。

2009年11月24日 (火)

【共通フレーム2007第2版】ユーザビリティによる差別化は実は厳しい

P11「(10) ユーザビリティの問題」において、ユーザビリティのニーズが高まっているとして、「特にWeb系の商品は競合が多くなりやすく、商品そのものの魅力もさることながら、分かりやすさ、使いやすさなどは、他社との差別化の大きな要因になり得る」と書かれている。

「特にWeb系の商品は競合が多くなりやすく」の部分は、前の版では「特にWeb系の商品は参入障壁が低いことから競合が多くなりやすく」と書かれていた。

まあ、「参入障壁が低いことから」というのは、そこだけみれば、言いたいことは変わらないので、あろうとなかろうと構わないとも言える。

ただ、「分かりやすさ、使いやすさなどは、他社との差別化の大きな要因になり得る」の部分と組み合わせて見ると、残した方が良かったかもしれない。

「特にWeb系の商品は参入障壁が低いこと」とは、開発環境の差・使用技術の差が、他に比べて、大手・中小・個人でそれほど大きくないことを意味していよう。だから「競合か多くなりやすく」と言い、ユーザビリティが「他社との差別化の大きな要因になり得る」と言うのだ。
確かにそうだろう。

しかし、それは一回に限り有効の技かもしれない。
ユーザビリティによる差別化は、実現したものを見れば誰でも真似できてしまうものが多く、継続的に「他社との差別化の大きな要因になり得る」とは限らないと考えるからだ。

他社を出し抜くユーザビリティ向上のアイディアが継続的に出せれば良いが、Web系の商品は参入障壁が低く、競合か多くなりやすいと旧版で書かれていた通り、ライバルは多く厳しい。

一度新規受注したら継続的に保守開発も受注できる等のメリットがあれば別だが。

特許を取れば良いというのは別な話である。

特許を持ち出すならば、そもそも特許ビジネスに特化すれば良く、Web開発業務などしない方が良いということになってしまう。

ユーザビリティによる差別化…これは、今回リードしても次回また同じスタートラインから競争しなければならない過酷なレースに参入することなのかもしれない。

2009年11月20日 (金)

【共通フレーム2007第2版】段階的見積りの意義

P9「(6)見積もりの問題」において「一般的にユーザ企業は、…おおよそのプロジェクトの方向性だけで予算を見積ろうとする。…プロジェクトはしかし、その金額で受注し、プロジェクトの終了時点で最終的に膨らんだ数字を見てトラブルが起こる」が追加されている。

また次のP10の「図1―4 見積り時期と見積り誤差・リスク」においても、「あいまいさが多く残る段階の見積りを、より明確になった段階で再見積りできるルールづくり等が、プロジェクト成功の鍵となる」という文が追加で添えられた。

これら記述の背景にある考え方は理解できるし、くどいくらいに感じるこれら記述を追加した意義はあろう。
実践はなかなか難しいだろうから。

ユーザ企業は、年度等周期を持って予算を立て消化していく仕掛けになっていることが多い。
この周期に段階的見積りは合わせづらい。

だから、ここで書かれている見積り方式の採用が難しいのは誰もが分かっている。
また、このユーザ企業の仕掛けをお役所的と言うこともできない。
ユーザ企業は、決算という大変な数字合わせの課題を背負っているのだから。

それゆえに、しつこいくらいに記述することには意義がある。

現実に採用は困難でも、考え方は頭の中に持つべきという意味で。

ただ一点、気になる部分がある。

それは「プロジェクトの終了時点で最終的に膨らんだ数字を見てトラブルが起こる」という記述に表れている。

ここでは、「あいまいさが多く残る段階の見積り」により「プロジェクトの終了時点でトラブルが起こる」のは「最終的に膨らんだ数字」のときだと言っている。

「プロジェクトの成功」要因の一つ「見積り内に収まること」に縛られている気がする。

確かに「プロジェクトの終了時点で最終的に膨らんだ数字を見てトラブルが起こる」ことは良くある話ではある。
しかし、逆に「プロジェクトの終了時点で、最終的に予算に全く達しない数を見てトラブルが起こる」ことは少ないのではないだろうか。

これはおかしな話ではないだろうか。

あいまいさが多く残る段階の見積りには、不確定分のリスクを小さく見積る場合だけではなく、大きく見積ってしまう場合もあるのではないだろうか。

それなのに、「終了時点で最終的に膨らんだ数字」しかトラブルの原因にならない現実はおかしいのではないか、という視点も必要だろう。

見積り通りなら問題にならないというユーザ企業の特性を逆手に取ったベンダの営業活動は可能である。

よってここでは、あいまいさが多く残る段階の見積りは、ベンダのみならずユーザ企業にとっても本当は良くないのだということを意識しておかなければならない。

2009年11月17日 (火)

【共通フレーム2007第2版】V字モデルにおける対称性の確保③

更に、

「要件定義の段階まで戻ることもありえるが、もし要件定義等の手戻りが長引いた場合、請負であるが故に運用テストの期間に期限がある以上、契約に係るトラブルの発生へと発展する可能性も否定しきれない」とあるが、なぜここで「運用テスト」しか考慮しないのか。

「要件定義」の手戻りで影響を受けるのは「運用テスト」だけならばそれで良い。しかし、普通は、その間の全工程が影響を受けるはずである。

そして、その全工程において「請負であるが故に期間に期限がある以上、契約に係るトラブルの発生へと発展する可能性も否定しきれない」ことになるはずである。

ならば、開発の全工程を準委任とせよということになるのではないか。

対称性を意識せよという考え方自体は良いと思われるが、契約形態とのリンクについての記述は良く分からない。

(恐らく、本書がイメージする契約の形態が、私のイメージするものと異なることにより生ずる違和感だろうが…)

2009年11月13日 (金)

【共通フレーム2007第2版】V字モデルにおける対称性の確保②

続く文も微妙で、「しかも、要件定義が準委任であるならば、V字モデル上で対となる運用テストも準委任としなければ、対称性は確保されない」と、また仮定の話になっている。
仮定の上に更に仮定を乗せており、危うい三段論法の印象を受けてしまう。

更に、最初の文と異なり、こちらは意味においても、理解が難しい。

「対称性は確保されない」とあるが「対称性」は確保しなければならないのだろうか。

それに対する答えと思われるが、対称性については、次のように補足されている。「要件定義(準委任時)が曖昧なままで行った運用テスト(請負時)で何らかの不具合が生じた場合、要件定義の段階まで戻ることもありえるが、もし要件定義等の手戻りが長引いた場合、請負であるが故に運用テストの期間に期限がある以上、契約に係るトラブルの発生へと発展する可能性も否定しきれない。そのために、また取引の適正化のためにも、そのような対称性を確保することが望ましい」。

「請負であるが故に運用テストの期間に期限がある」とあるが、準委任だと期限がないというのだろうか。これは、恐らく定常的要員確保のために準委任契約を結ぶケースをイメージしているのだろう。しかし、請負より準委任という文脈では、そのように理解するのは難しい。

当該開発に対する個別契約と考えるのが普通ではないだろうか。

2009年11月10日 (火)

【共通フレーム2007第2版】V字モデルにおける対称性の確保①

P9の「(5)不明確な取引の問題」において、第2版で次の追加がなされている。

「また、『請負・準委任』の問題がある。これは、超上流をユーザ責任と考える場合、超上流における取引契約類型を請負契約とするのはおかしく、準委任とするのが適切である。しかも、要件定義が準委任であるならば、V字モデル上で対となる運用テストも準委任としなければ、対称性は確保されない」

恐らく良いことが書いてあると思うのだが、今一つ分からない。

「超上流をユーザ責任と考える場合」という仮定を自ら置いているので、「超上流における取引契約類型を請負契約とするのはおかしく、準委任とするのが適切である」というのは、我田引水に見えてしまう。
ここは「超上流をユーザ責任と考える場合」という仮定ではなく、「超上流をユーザ責任と考えるので」と言い切って良いところだろう。但し、本書が啓蒙書ではなく、共通フレームという位置付け上、言い切りを避けるという考えも理解できる。そうだとしても、何かうまい表現にすべきだろう。もしくは、「超上流をユーザ責任と考える場合」しか当てはまらないというのであれば、この一連の記述は我田引水のみの意味しかもたなくなる。

2009年11月 6日 (金)

【共通フレーム2007第2版】正直な告白:「開発」と「保守」の使い分け

P7において「(注)本書においても、『第3部 共通フレームとガイダンス』を除き、『開発』と『保守』という用語を使い分けておらず、もっぱら『開発』を使用している。しかし、個々の文中においては、『開発』を『開発又は保守』と捉えてよい場合が多いため、適宜、そのように読み替えていただきたい。」という記述がある。

正直にこれを書いたことは、評価すべきであろう。

しかし、「『開発』を『開発又は保守』と捉えてよい場合が多い」および「適宜、そのように読み替えて」の記述からは、著作者も、どの箇所で「開発」を「開発又は保守」と捉えてよいか分かっているということなので、ちゃんと記述すべきであろう。

「適宜読み替えよ」という言葉は、モデルにおいては使うべきではない。
「以後、常に読み替えよ」ならば良いが。

この記述、初版では無かった。
だれかに指摘されたのだろう。
しかし、その指摘に対し、このような対応で済ますのは、「横着」と言われても仕方がないだろう。初版でもどこかに書かれていたのならば、「横着」には当たらないが、「適宜読み替えよ」はやはり良くない。

2009年11月 3日 (火)

【共通フレーム2007第2版】「第2版刊行にあたって」における自己評価

viiページ「第2版刊行にあたって」において「共通フレーム2007で取り決めた『契約の変更管理プロセス』が、2008年3月に発行されたソフトウェアライフサイクルプロセス改訂版(ISO/IEC 12207:2008)に採用されました」とある。
これは確かに日本発の世界への誇るべき貢献であるといえよう。

しかし、ここで止めておけばよいのに次の文が続いてしまう。
「これは、国際規格をベースに日本の産業界で修正して作った共通フレーム2007が、今度は、国際規格への改訂・強化に貢献できるほどの内容であることを意味しています」。

これでは共通フレーム2007全体が「国際規格への解読・強化に貢献できるほどの内容である」ようにとれるが、検証されたのは「契約の変更管理プロセス」部分だけである。
一部が評価されたから全てが素晴しいものであると自ら言っているように取れるが、共通フレームの性格上、そのようなことは言い切れないはず。

故にこの文は蛇足だ。

どうしても言いたいのなら、「共通フレーム2007で取り決めた内容が、ISOに採用されたのか…すごいな、共通フレーム2007は、国際規格への改訂・強化に貢献できるほどの内容なんだ」と読者が自発的に想起できるような文にすべきであった。自ら書いてしまうと、ミスリーディングと言われても仕方がなくなる。

著作者としての気持はわかるが。

さて、共通フレームの本質とは関係の無いところから始まりますが、新しくなった「共通フレーム2007」についてこれから見ていきます。

「共通フレーム2007第2版」というより「共通フレーム2009」で良かったと思わなくもないですが…と、これまた本質とは関係の無いところを突っ込みたくなるのですが・・・。

« 2009年10月 | トップページ | 2009年12月 »