アカウント名:
パスワード:
ああ、ソフトウェアの設計にも安全係数の考え方ができたら、 どんなに楽なことか。
常識的には、ソフトウェアの品質は、 欠陥を見つけて修正して、それが枯れたことでしか測れません。 そもそも欠陥が出ないと品質が測れないということは、 仮に超優秀なプログラマがいて、本当に無欠陥のコードを書いたとしても、 それは品質測定ができず、受け入れ不可能ってことになります。 だから、テストで欠陥がある程度出てくれないと困るのは確かです。
でもね、欠陥の検出率を測定して、 ある一定以上の欠陥が出ていないとしたら、 まず、テスト担当側の方法を疑うのが普通であって、 開発会社にペナルティを科すってのは、全くデタラメなやり方ですね。
できたばかりのコードそのものの品質の高さを「客観的に示せ」というのは、 これも無理な話ですが、 欠陥修正が速いとか(=昼間のテストで出た問題は、夜中に小人さんが修理してくれていて 翌日すぐに再テストできるとか?)、本当に平均して欠陥が少ないとか、 いつもテスト期間の短縮に貢献しているのだというデータは 取ろうと思えば取れるはずなのですけどね。(たいへんだけど)
私も発注側の人間。
ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
安全係数 (スコア:3, 興味深い)
ギリギリの安全係数で設計して、その代わりに検査で問題点を摘出するというアプローチしか取れません。
また、いったん飛び立ってしまえば着陸するまで修理は出来ないし、あちこち飛び回っているので、
どの時点で修理をするかを決め、必要機材を先回りして準備しておかなければいけないといった事情あり、
予測ということが重要でしょう。
これが地上の構築物であれば思いっきり安全係数を掛けて、検査を軽くするという
ライフサイクルコストを考えたアプローチも取れるのですが。
ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。
事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
Re:安全係数 (スコア:2, 興味深い)
ただ、インターネット世代だと、日々出てくるセキュリティホールや、時代の変化による陳腐化に晒されるといった類のソフトウェアもあるので、定期的な見直し、修理点検も必要といえば必要ですね。
>事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
これも、広くいろいろなハードウェア、条件でインストール、実行されると、思ってもみなかった不具合が出て来たり。
オープン化以前の、用途特化した汎用機の時代のほうがやりやすかったのかも。
Re:安全係数 (スコア:2, 興味深い)
裏を返せば恐ろしい事実が浮かび上がってきますね。
つまり、ソフトウェアでは、
上の人たちが話していたようなリアル物と違い、
「予測不可能な」壊れ方が大半を占める、ということになるので。
リアル物の疲労とかの壊れ方は、ある意味で予測可能なんですよね。
これくらいの力がかかってるから確率的にこれくらいの時期に駄目になるだろうとか。
ところがソフトはその発想が通用しない。
時間によって壊れるのではない。
実は最初から壊れてるだけで、それが発覚してないだけ。
それがバグ。
だから全く予想不可能なタイミングでとんでもない大バグで壊れたり…もとい実は最初から壊れてたのが発覚したり…する。
お仕事開発(つまり企業)においてしばしばイタイとされてるのは、
この「予測可能性」について勘違いしまくった人が開発工程を決める、
という状況だと思います。
＃某通信系大手に「バグ率」という言葉を散々振りかざされてウンザリしたのでAC
＃バグが多いならまだしも、少な「すぎ」てもペナルティを科されたんだよね…
＃もしウチの社員がテメーラより3倍優秀だったらバグも1/3になることは全然おかしくないだろうに…
Re:安全係数 (スコア:0)
> ＃バグが多いならまだしも、少な「すぎ」てもペナルティを科されたんだよね…
> ＃もしウチの社員がテメーラより3倍優秀だったらバグも1/3になることは全然おかしくないだろうに…
多分そこの中の人の上の人です。
コードの品質が高いことを客観的に示せば受け入れてもらえたはずですよ。
データに基づいて説得できなかった時点で負けですね。
せっかくコーダは優秀なようなのに、マネージャがゴミじゃダメだよな。
Re:安全係数 (スコア:2, 興味深い)
じゃあとりあえず殺意を覚えさせてください(わら
少なくとも御社(だとすればの仮定の話ですが)の
あのドキュメントを書いたかたがたへ、ね。
殺意自体は冗談ですが、こっちがかなり非効率に忙殺されたのは間違いないと思いますので、(埋め合わせをして頂ける日が来るまでは)恨みは記憶から消えないでしょうね。
>客観的に
それをいうなら、あの方法論の適用の的確さもまた、客観的に示して欲しいものです。
つまり弊社社員たちが平均的だということを。
いつ測ったの？
(御社(だとすれば)がうちから持っていったデータは、履歴書の束だけのはずですよー)
というかそれ以前に、
●平均的人間ならばこれくらい、という相関がそもそも有るのかどうかを。
●平均かどうかをどうやって測るのかを。
客観的に示して欲しかったです。
要するに片手落ちなんです。こちらが出すものにはそうやって客観性だのなんだのといった真っ当なスジを期待なさる(実際そうでした)割には、そちらからくれるものはスジもへったくれもないものばかり。
それとも上流サマはそうやって下請けに無理難題言うのがお仕事なんでしょうか？
「文句があるなら換えは幾らでも居るぞ」ってか？
結局俺らの頬を札束で叩いてるだけじゃんかorz
というかぶっちゃけ、
そちらからのドキュメントが平均的(優秀でなくてもいい)日本人に判読可能であったことも、客観的に示して頂けると凄くありがたいですね。しゃれぬきに日本語としてすら判じ物で、それの意味を問いただすのだけで工数(与えられた期間)のうち半分以上を食ってしまったってのが実情なので。
(しかも「なかなか返事をもらえない」という待ち時間がその大半を占めた。たしかに質問と回答自体に時間がかかるわけではないが、待ち時間が凄かったわけね。電話を「3日後にまたかけて」とか言われて、かけてみたらまた待たされたりとかさ。)
こっちの品質を言うまえに、そちらの命令書(ドキュメントの文字通り山)の品質を、どうにか客観的に評価してもらえたら、助かったのですが。
その状況でバグ率とか言われてもねえ。
それともこれは引っ掛け問題で、判読できなくてそちらの意図と違うものを実装してしまったら、それをバグにカウントすることで帳尻が合う、ということだったのでしょうか？だとすれば優雅ですね。下請けに引っ掛け問題を出してコミュニケーションロス「で」遊ぶ暇が有るんですから。
＃ACはこういうために使うのか！と今更気付いたのでAC
日本語をクリアしたとしても、その次にはIT畑で典型的な問題が待ち構えています。
それは「ロジックの抜け」です。
ドキュメントを日本語でダラダラ書かれたドキュメントにありがちだし、そうでなくてもありがちなことなんですが、
「xxなときにyyしろ」
というような指示の羅列があったとき、
そのケースに抜けが有る、
ってのが典型的に良く見かける「ミス」です。
Waterfall(大量の「出来上がった」ドキュメントを一気に渡す方式)をやりたいなら、そういう抜けを絶滅させてから下請けに渡して頂きたいものです。
逆にいうと、上流サマが机上の空論こね回してるだけでは、そういう抜けは発見しきれないのが判っているからこそ、Waterfallは不味いって話に近年なってるのですね。
Re:安全係数 (スコア:1, おもしろおかしい)
とりあえず落ち着こうぜ
Re:安全係数 (スコア:0)
埋め合わせさえしてもらえれば、べつにどうということは有りません。
でもそれは恐らく永遠に無いのでしょう。「とりあえず」などと言える日はおそらく来ません。たぶん何十年も前から、そして何十年後も、同じ態度で居続けるんでしょうね、ああいう大企業さまは。
そんな仕事っぷりでも高給(聞くところによると俺らの3倍らしい)をもらえるという意味では、確かにそういう外道な会社の社員になった人間のほうが勝ち組。おめでと。
(そんな彼らから仕事めぐんでもらわないと仕事がない弊社一同は負け組)
建築と違って基準法が無いから「設計」をやった人らが罰せられることは永遠に無いでしょうね。それどころか上のコメント(バグ率についての反応)を見れば判るように俺様法律状態です。一方的に下請けを罰するだけ。「説得できなかった奴が悪い」と開き直る。
我々がやれることといえば、せいぜいこうやってACで暴露ともいえない弱気な暴露もどきを弱小掲示板サイトに書くことだけ。おめでと。
Re:安全係数 (スコア:0)
たとえ下請けの仕事しかないにしろ、他にもっとましな開発方法論を持っている元請けから仕事を取ることができるでしょう。
つまり、営業に問題があるのではないか。
Re:安全係数 (スコア:1)
ああ、ソフトウェアの設計にも安全係数の考え方ができたら、 どんなに楽なことか。
常識的には、ソフトウェアの品質は、 欠陥を見つけて修正して、それが枯れたことでしか測れません。 そもそも欠陥が出ないと品質が測れないということは、 仮に超優秀なプログラマがいて、本当に無欠陥のコードを書いたとしても、 それは品質測定ができず、受け入れ不可能ってことになります。 だから、テストで欠陥がある程度出てくれないと困るのは確かです。
でもね、欠陥の検出率を測定して、 ある一定以上の欠陥が出ていないとしたら、 まず、テスト担当側の方法を疑うのが普通であって、 開発会社にペナルティを科すってのは、全くデタラメなやり方ですね。
できたばかりのコードそのものの品質の高さを「客観的に示せ」というのは、 これも無理な話ですが、 欠陥修正が速いとか(=昼間のテストで出た問題は、夜中に小人さんが修理してくれていて 翌日すぐに再テストできるとか?)、本当に平均して欠陥が少ないとか、 いつもテスト期間の短縮に貢献しているのだというデータは 取ろうと思えば取れるはずなのですけどね。(たいへんだけど)
私も発注側の人間。
Re:安全係数 (スコア:0)
え？「テスト担当者」も弊社ですが何か？
変だって？「普通」でないって？
でも、こっちでテストしろと、あちら様に命じられたんですもの。普通という言葉すら歪曲するのが大企業様の恐ろしいところ。
(あれ？そういや「テストの方法」を命じられた記憶が無いです。「いかにテストするか」を縛ってないくせにバグ率(行数あたりのバグ件数)は縛り、しかも実はコッチの言い値ですか？なん
Re:安全係数 (スコア:1, 参考になる)
まぁ、相手は大会社様ですからね、その大会社様の会社全体で見るとサンプル数も多いんですわ。
するってーと、案外、それなりに平均的な値とか傾向っつーのも出てくるんですよ、特に案件の規模が大きくなってくるとね。
傾向の出方も、バグ数だけの話じゃないんですよ、バグの種類とか、各工程での出方とかね。
この辺をきちんと見ていくと、これ数字捏造でしょ?とか、テスト本当にやったの?とか、テストの力入れる部分違うんじゃない?とか、そういうのも大体見えてくるんです。
SI工程なのに発見すべき工程がUTばかりだとテスト不十分だったのかなーとかね。
捏造なんかだとSIで発見されたバグがUTでなおってたりなんてのが大量にあったりしますね。
ま、こんな整合性を整えてまで捏造するならきちんとテストする方が楽ですし、本来捏造なんてやる気出ませんし、そもそも捏造が必要な事態に陥るほどの状況ですからね、こういう部分も雑になりますわな。
あと、大会社様の中でも、受け入れは別部門だったりすることがあって、そういう場合だと、担当部門の方も、その別部門の人を説得せにゃならんのですわ。
受け入れが別部門じゃなくとも、大会社様のお客様がITにそれなりに詳しかったりすると、やっぱり説得が必要ですし。
なので、その説得材料として、「まずは俺を納得させろ」なんつーことはよくあります。
そういうわけで、アドバイス。
テストをやる前に、テストのやり方については充分に大会社様と話をしておきましょう。
テストの目的とか、項目の抽出の仕方とか、目標のバグ件数とか、記録すべき事項とか。
で、記録すべき事項については、確実に周知・徹底して、きちんと残しましょう。
場合によっては、大会社様が残さなくていいといった内容についても記録に残すべきです、もちろんコストと相談してですが。
こういったことをしっかりやっておけば、話し合いで何とかなることが結構あります。
もちろん、プロジェクトの状況にもよりますよ、受け入れ側視点で見ても、もっと早く相談してよって言いたくなるケースもあります。
Re:安全係数 (スコア:1, 参考になる)
テスト目的やテスト観点、試験項目はきちんとレビューしてもらおう。→やるべき試験についての事前ネゴ
テスト期間や項目数にもよるが、最低でも週1、可能なら毎日、試験消化状況やバグの発生状況について話す場を設けてもらおう。→状況把握してもらおう&捏造してないことを知ってもらおう
政治的・コスト的に可能なら、担当部署の品質管理チームに数人混ぜてもらおう。→相手がどういう考えでいるのかを知ろう&手法を学び取ろう
同じく政治的・コスト的に可能なら、自社内部にも品質管理チームを持とう。担当部署の品質管理チーム分隊という感じでもOK。→大会社様と同じ意識を持とう&内部の記録ミスなんかは随時正そう
Re:安全係数 (スコア:0)
客観的に示したところでやっぱり主観的に否定されて終わってたでしょうねｗ
Re:安全係数 (スコア:1, 興味深い)
運用環境の違いや、それに合わせたコンフィギュレーションの差異なんかは個体差といって差し支えないし、そのような設定の変更を繰り返すうちに元に戻せなくなる場合も珍しくはない。交換＝再インストールで解決したりとかね。
これをオペレーションの問題でありソフトの不備では無いと言い張るならそれで構わないけれど、現実にはそんなに厳密なオペレーションが可能な設計でもなければマニュアル等が完備されてるわけでもない場合が珍しくないわけです。そのような不備をも含めて「バグ」と称するなら確かに元コメントの言うとおりではあるけれど、見方によっては「ソフトウェアも経年劣化や疲勞を起こすし、そうなったら交換すれば良い」という考えの元、コストダウンを図っているといえなくもないでしょう。
個人的にそれよりも気になるのは「ソフトウェアに製造工程はなく試作品がそのまま出荷される」ということをよく理解してない開発者が非常に多いということですね。敢えて飛行機ではなくガレージキットで例えさせてもらいますが、ガレキなら試作品、つまり原型が「切った貼った削った盛った」のツギハギだらけであろうと、型さえしっかり取れば量産品は継目なしの一体成形で出荷することもできるわけです。ところがソフトウェアの場合、出荷される製品はあくまで試作品のコピー、ツギハギまでも含めた良くも悪くも完全なコピーなのです。
酷い場合、バグを潰すのではなく、バグによって壊されたデータの修正ルーチンを別途組み込む、といった場当たり的なツギハギが、必然性もないまま放置され、出荷されてしまうことすらも。で試験に漏れた特定の条件で修正ルーチンが走らなかったり、２回以上走ったりとか。
そしてW2Kの記憶は忘れられた！ (スコア:1)
バグを潰しきったなんて、そんな夢物語！
最近なんてハッピーマンデー砲なんて軍事兵器が投入されたばっかりでありますよ！？
たとえ、バグがあろうが無かろうが、安全では無いし、経年劣化を防ぐためにメンテナンスは必要なのであります！
ソースコードのフリーズ＝メンテナンスの放棄なんて勘違いはしてないと思うけど！
Re:そしてW2Kの記憶は忘れられた！ (スコア:0)
設計してしまったところに基本的な敗因があるんじゃないですか。
メンテが必要な祝日なんてデータとして持つべきでしょう。
Re:そしてW2Kの記憶は忘れられた！ (スコア:1)
旧い時代の汎用機だって休日には休日のスケジュールに従ってジョブを流すだけでありますよ？
問題点がそこだけだから大丈夫だろう。と思っている事が地獄の扉を開ける原因だと言っているのであります！
Re:そしてW2Kの記憶は忘れられた！ (スコア:0)
ユーザという生き物は
「祝日のメンテの必要があるシステムなんでバグだ！」
程度のことは軽く言い放ちますよ。
Re:そしてW2Kの記憶は忘れられた！ (スコア:0)
「祝日の初期データ準備とかメンテとか全部お客さんでやってくださいね」とか
アホなこと言ってたら別だけど。
# 運用まで頭が回らないSEっているよね。
# そういうのはSEって呼んじゃいけないと思うけど。
Re:安全係数 (スコア:0)
組み込み系、特にメカがかかわる奴とか、デバイスドライバ、あるいは通信系の低いレイヤーでは
個体差、というか条件によって発生する問題もありますからね。
Re:安全係数 (スコア:0)
バグをつぶしきるのが難しいところですね。
どれだけテストをやれば、バグをつぶしきれるのか
一つのバグを修正したために、新たなバグが発生しないのか
ハードと違い、プログラムは、一本一本手作りなので
一本一本テストしていくしか結局は意味ないですよね
経年劣化はないですが、データ量が増大してレスポンスが問題になったり
OSやDB、その他使用している環境のバージョンが変わって、かつ上位互換が
完全に取れていないときなど、問題になりますよね。
Re:安全係数 (スコア:3, すばらしい洞察)
>一本一本テストしていくしか結局は意味ないですよね
ハードも設計者にとっては一本一本手作りです。
製造ライン作るのだって一本一本手作りです。
よろしく ^_^/
Re:安全係数 (スコア:1)
パッケージ販売してるところとかはまた別と思うけど。日本のSIerを早くパッケージ市場に乗り出せば良いのに。
そんなに斬新なシステムばかり要求されるわけじゃ無いでしょ。
Re:安全係数 (スコア:0)
CPUの演算機能やOSのシステムコール、コンパイラのライブラリを疑う人はまずいないですよね。
枯れてしまえば問題ないということでしょう。
>>データ量が増大してレスポンスが問題になったり
データ量に依存するようなシステム設計は問題だろうし
負荷テストなんて常識の範囲だと思いますが。
Re:安全係数 (スコア:1, すばらしい洞察)
>枯れてしまえば問題ないということでしょう。
CPUの演算機能はたまにバグがあると結構騒がれますが、OSやコンパイラ、ライブラリレベルなら
今でもかなりバグがあります。
そもそも「枯れてるから問題がない」といっても、枯れた時点でバグ0ではありません。
結局のところどこかにバグがいるからバージョンアップをしている、という側面もあります。
ただ、ソフトとハードというのは、やはり比較すべきものではないでしょうね。
非常に誤解を招きやすい。