アカウント名:
パスワード:
「IT業界からはこれが普通です」という声が多く寄せられているようだ。
後でいくらでも修正できるソフトウェア(ごめんなさい語弊がありますね)と一度作ったら容易に変更できないハードウェアの違いだろうなあとしか。
しかしみんな慣れ過ぎだよ(涙
未完成のままリリース [youtube.com]しないだけ、IT業界よりはましだと言える。
空母信濃なんてまさに未完成のままリリースしたからあっさり沈んだのでは?
信濃沈没はそういう経緯ではない。あれは船としてはひとまず形になっていたが軍艦としては未完成の状態で別の工廠に移す最中に撃沈されたからな。沈没現場は日本近海だったのも大きいし。本番環境に配備テストしたらサーバが火を吹いたとか工場の通路に穴が空いてたとかそういうレベル。産業スパイの妨害が一番近いかもしれない。
本番環境に配備テストしたらサーバが火を吹いたとか工場の通路に穴が空いてたとかそういうレベル。産業スパイの妨害が一番近いかもしれない。
付け加えると、その配備テストを行ってるほとんどが配属されたばかりの新卒だったとかなんとか_(:3」∠)_
# あれ?…空母信濃の話だよ…ね…?(震え声
試験がマトモに出来ず、かといってスケジュールは守らなければいけない。でもって、設置はしたけどサービス前に燃えたってのが空母大鵬かな。ダメコンもまともに教育されてない新兵が…とか。
やっぱり昔話の筈なのに、何故か自分がダメージを受けるという不思議。
信濃はあれだな炎上する前に轟沈したからな。本当は巨大戦艦になるはずのところを強引に空母に改造(しようとした)から完成したらしたで問題が山積したはず。
工事を急いで水密試験などをかなりすっ飛ばしたそうな。未完成というより、完成したけど組み合わせテストも無しで運用したようなもんかな。
空母信濃は呉海軍工廠で艤装工事するために回航してたとき撃沈されましたリリースされる前の段階です
え、あれ?まさにそんな感じで、内装工事は引き渡すためにヨーロッパまで移動中の船内でやってたらしいけど……納品前だからOK?
ものが豪華客船なので数の上では宿泊施設に事欠かないが、調理器具くらいならともかく、客室なんかは新品のまま引き渡す必用があるだろうし、作業員は一体どこで寝泊まりしてたんだろう。
倉庫や空のプールの底に寝袋持ち込んで雑魚寝とか?(涙
んなわけない。
ソフトだろうがハードだろうが設計が変更が容易って思う事がアレですわ。
隣の設計者が、客先からのレビュー結果の電話をうけて
「今頃テーブルのキーが変わるの!?画面変わるけど!?」
と叫んでたので、設計変更を指示すること自体が容易なのはなんとなくわかる。
んなわけがない。
辻褄を合わせるときのコストが全く違います。galaxy note 7の不具合がソフトの問題なら、パッチ当てれば爆発しなくなります。
ソフト対応の方がコスト優位なのは大量生産品だから。ハードの対応費用は対応製品数に比例しますが、ソフトの対応費用は対応製品数に依存しない固定費なので、数が多いければ多いほどソフト対応の方が相対的に低コストになります。
今回の問題のような一品ものの場合は、ソフト対応の優位性はそれほど大きくないでしょう。
機械分野における基本設計や詳細設計というのは、IT業界で言うソフトウェア開発のほぼすべての作業。
で、「船殻工事や設備・内装工事」ってのはIT業界でいうビルドで、これを実際の土地に作ったビルド環境で、実在する材料を使って、人間が一つ一つ作業して行ってるわけ。実際のところ、開発のコストの上に、こういった莫大なビルドのコストが丸々乗っかるのが機械業界。今回の菱重の一件、ビルドのコストがソフトウェア並みに低ければ、赤字は大分少なかったと思いますよ。
#さすがに鉄を切った張ったしてる現場のコストを無視できる元請けなんていないと思った?#残念。末端のn次請けではよくある話でした。#ましてや、CADの中にある段階なら、いくら話をひっくり返してもタダだと思ってる元請けが多いのはこっちの業界でも同じ。
ソフトウェア開発でビルドコストがかからないと考えていることが甘い。IT業界で動作環境限定しているのは何故かとか自動ビルドを導入するのは何故かとか。
わざわざ量の比較を丁寧に説明してくれるのに、アリナシの1bitの極論に落とし込むってのはなんかの宗教か?
昔々の共有VAXで長時間のビルド中にそこそこの確率でポカで落とされたり、とかのコストと現在のビルドコストが一緒だとでもいうのだろうか。
お若いの、年寄りの話は聞くもんじゃ。
むしろ物理的制約無い故にちゃぶ台返し行っても期間もコスト変わらない、と考える人が多い(国内での話)のでむしろマイナス作用が大きい。。
一品モノの金融ソフト「せやな
> ソフトの対応費用は対応製品数に依存しない固定費なので、
おひとりさまで100人日のデバッグ作業もこなせるってこと?
そらサムスンの技術者も、パッチ当ててnote7の問題解決しろとせっつかれたろうよ。60%しか充電できないパッチとか。それ解決じゃねえだろと思いつつ、エンジニアは作ったと思うよ。
60%充電で爆発しないなら、割りと悪くない対応なんじゃないかな...というか、バッテリーライフが伸びるから、そのパッチマジでほしいですね。
NECの某モバイルルータ、バッテリ寿命を伸ばすかわりに70%程度までしか充電させない設定ができましたっけ、そういえば。
正にその通り、70%で充電停止ですしかしこれで本当にそれなりに長く持つからどうしたものか。
by中の人
追伸 銀河のあれば充電速度と消費電力計算も不味いと思う、もしかして充電容量だけ六割相当にしてるだけだったりして
そもそもそれでも燃えたとか、交換品も燃えたとかめちゃくちゃだと思うんだけど…
ソフトウェアはデータを作り直す=IT業界はサービス残業が基本なのでコストはかからないハードウェアは物を作り直す=材料費がかかる
現場からしてみりゃ容易じゃないんだけど、上層部からしたら容易なんだよ。
下手すると金型とか、一点ものとかそういう高価なものまで作り直さないといけないしな。
少し違うけど、自前で大量のハードを買ってデータセンター作った後に「やっぱAWS使うわ」とか言われたら・・・GoogleCloud使う予定でAWSに乗り換えるのとは大きな違い。
まあ普通に配線や配管一つ取ってみても、配管した後に「やっぱいまのなし」ってやろうとすると、内装壊して壁を引っぺがしたり、ビルでいえば数階層取り壊したりしてから改めて作り直しする「デリートとビルド」に膨大なコストと時間ががかかるけど、ソフトの場合はデリートとビルド「だけ」なら、ほとんどコスト0だしね。
ただしどこを削除して変更するか、設計図を引いて検証する作業そのものはやはりかかるから、複雑な物を作る時の変更コストは安くはない。そして作ってる対象というのは年々複雑になる傾向があるから……。
結果として「ソフトのことはよく分からんけど、ソフトなら変更なんて簡単でしょ?チャチャッとやっちゃってよ。」になって現場が泣きを見ることも多いと。
ソフトウェアは、自社開発で、ハードウェアは外注の比較になってないか?
ハードウェアでもあるだろ、サンプルもらってタダで仕上げろって
いや、だからデスマが絶えないのだろ?
むしろ、ハードウェア設計の不具合もソフトでどうにかごまかすのが今の開発だろ
>例えば、セレモニーに使った3層吹き抜けの多目的シアターの天井にぶらさがる照明。>直径3メートル、重さ900キログラムの照明には50万個の発光ダイオード(LED)が埋めてある。>ショーの内容にあわせて電子制御する仕組みだ。http://www.nikkei.com/article/DGXMZO01967040W6A500C1000000/ [nikkei.com]
照明AとB、CとDがそれぞれ同期してON/OFFしなければならない所を、ちょっと配線を間違えてAとC、BとDがそれぞれ同期してたら、やっぱし「ソフトウエアで直せ」って言われるのかなあ。
たしかに壁を引っぺがして、船内の配線をやり直すのに比べたら、ソフトウエアを書き直す方が早そうな気はする。
そして照明制御プログラムのソースをみたら、配線に負けず劣らずのスパゲッティで、涙するとかあるある。
よくあることじゃん。
で、コードだけ見るとどう見ても間違ってるから気を利かせて直す奴がいて、そいつが辞めたころに誰かがその地雷を踏む。
これって、コードにひとことコメントを書けば済む話なんですけどね。
いや普通にチューブマーカーなりで書かれてはいるのだけどな。他にもブロックごとにコネクタを変えて間違ってつなげないようにするとかイロイロ行われている。が、もともとの図面が間違っているなら、そんな現場側で理解できる対策なんぞ何の役にも立たない。どころかこの前見たのは、職人が経験で正しく配線したものを、検査人が間違った図面を頼りに確認してわざわざ違う様に繋ぎなおしてしまっていた。でもって、それで基盤が一枚パー。
プログラムコードのことだったんですが、これはこれで良いので、結果オーライということで!
その例では図面作った奴:アホ職人:図面の間違いに気づいたならフィードバックしなさいな検査人:被害者じゃねーかな
コードの間違いをコードで治すw
それが出来るのはソフト連動の機能部品のみだ。それ以外のモノが山ほどあるから焼け石に水。
手で触れるブツ(材料費)以外のコストは0だと考えるんですよね実際は人件費に変わるだけなのにその人件費は無駄なコストと考え低賃金や長時間サービス残業等で無限に圧縮しようする
普通と言ってるが、正常とは言ってなぃ
ハードにもソフトにも仕様変更がかからない部分があってそういうところから開発を始めるから、ソフトもハードも関係ない。
コードって、いったん埋め込むと後から修正するのは大変だよ。
埋め込んだが最後、どこを通過しているか、どこで分岐しているか。スパゲッティになって他のコードと絡んでしまうと最悪。追っかけきれない。追っかけているうちに無駄にループしているのを見つけるのも多々ある。そういう場所に限ってなかなかアクセスできなかったりする。
後からいくらでも修正可能なんて、絶対にない。
#天井裏のコードの話だよねw
往々にして後で修正すればいいやでゴミを作る会社ほど、「後の修正」でバグを出すなとか「金がかかるから既存を使え」とかゴミをゴミのまま存続させようとするのでロクに修正できない
最終的には使ったプログラミング言語が駄目とか他者に責任を押し付けて被害者面
前向きに考えるんだ。造船業界にもアジャイル開発の波がやっとやってきたんだと。まだ彼らは慣れていないだけだ。営業航海しながら船体を同時に開発していく、ローリングリリースの時代になったんだと。
で、2隻同時に航海して「ほんじゃお客さん、ただ今よりグリーンからブルーに移ってください」と。
さらにコレを「我が社では一日に1万回デプロイします(ドヤァ」とかすごいな乗りたい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
そりゃ (スコア:5, すばらしい洞察)
「IT業界からはこれが普通です」という声が多く寄せられているようだ。
後でいくらでも修正できるソフトウェア(ごめんなさい語弊がありますね)と
一度作ったら容易に変更できないハードウェアの違いだろうなあとしか。
しかしみんな慣れ過ぎだよ(涙
Re:そりゃ (スコア:1)
未完成のままリリース [youtube.com]しないだけ、IT業界よりはましだと言える。
Re: (スコア:0)
空母信濃なんてまさに未完成のままリリースしたからあっさり沈んだのでは?
Re: (スコア:0)
信濃沈没はそういう経緯ではない。あれは船としてはひとまず形になっていたが軍艦としては未完成の状態で別の工廠に移す最中に撃沈されたからな。沈没現場は日本近海だったのも大きいし。
本番環境に配備テストしたらサーバが火を吹いたとか工場の通路に穴が空いてたとかそういうレベル。産業スパイの妨害が一番近いかもしれない。
Re:そりゃ (スコア:1)
本番環境に配備テストしたらサーバが火を吹いたとか工場の通路に穴が空いてたとかそういうレベル。産業スパイの妨害が一番近いかもしれない。
付け加えると、その配備テストを行ってるほとんどが
配属されたばかりの新卒だったとかなんとか_(:3」∠)_
# あれ?…空母信濃の話だよ…ね…?(震え声
Re: (スコア:0)
試験がマトモに出来ず、かといってスケジュールは守らなければいけない。
でもって、設置はしたけどサービス前に燃えたってのが空母大鵬かな。
ダメコンもまともに教育されてない新兵が…とか。
やっぱり昔話の筈なのに、何故か自分がダメージを受けるという不思議。
Re: (スコア:0)
信濃はあれだな炎上する前に轟沈したからな。本当は巨大戦艦になるはずのところを強引に空母に改造(しようとした)から完成したらしたで問題が山積したはず。
Re: (スコア:0)
工事を急いで水密試験などをかなりすっ飛ばしたそうな。
未完成というより、完成したけど組み合わせテストも無しで運用したようなもんかな。
Re: (スコア:0)
空母信濃は呉海軍工廠で艤装工事するために回航してたとき撃沈されました
リリースされる前の段階です
Re: (スコア:0)
え、あれ?
まさにそんな感じで、内装工事は引き渡すためにヨーロッパまで移動中の船内でやってたらしいけど……
納品前だからOK?
ものが豪華客船なので数の上では宿泊施設に事欠かないが、調理器具くらいならともかく、
客室なんかは新品のまま引き渡す必用があるだろうし、作業員は一体どこで寝泊まりしてたんだろう。
倉庫や空のプールの底に寝袋持ち込んで雑魚寝とか?(涙
Re: (スコア:0)
んなわけない。
ソフトだろうがハードだろうが設計が変更が容易って思う事がアレですわ。
Re:そりゃ (スコア:2)
隣の設計者が、客先からのレビュー結果の電話をうけて
「今頃テーブルのキーが変わるの!?画面変わるけど!?」
と叫んでたので、設計変更を指示すること自体が容易なのはなんとなくわかる。
Re:そりゃ (スコア:1)
んなわけがない。
辻褄を合わせるときのコストが全く違います。
galaxy note 7の不具合がソフトの問題なら、パッチ当てれば爆発しなくなります。
Re:そりゃ (スコア:1)
ソフト対応の方がコスト優位なのは大量生産品だから。
ハードの対応費用は対応製品数に比例しますが、
ソフトの対応費用は対応製品数に依存しない固定費なので、
数が多いければ多いほどソフト対応の方が相対的に低コストになります。
今回の問題のような一品ものの場合は、ソフト対応の優位性はそれほど大きくないでしょう。
Re:そりゃ (スコア:3, すばらしい洞察)
機械分野における基本設計や詳細設計というのは、IT業界で言うソフトウェア開発のほぼすべての作業。
で、「船殻工事や設備・内装工事」ってのはIT業界でいうビルドで、
これを実際の土地に作ったビルド環境で、実在する材料を使って、人間が一つ一つ作業して行ってるわけ。
実際のところ、開発のコストの上に、こういった莫大なビルドのコストが丸々乗っかるのが機械業界。
今回の菱重の一件、ビルドのコストがソフトウェア並みに低ければ、赤字は大分少なかったと思いますよ。
#さすがに鉄を切った張ったしてる現場のコストを無視できる元請けなんていないと思った?
#残念。末端のn次請けではよくある話でした。
#ましてや、CADの中にある段階なら、いくら話をひっくり返してもタダだと思ってる元請けが多いのはこっちの業界でも同じ。
Re: (スコア:0)
ソフトウェア開発でビルドコストがかからないと考えていることが甘い。
IT業界で動作環境限定しているのは何故かとか自動ビルドを導入するのは何故かとか。
Re: (スコア:0)
わざわざ量の比較を丁寧に説明してくれるのに、アリナシの1bitの極論に落とし込むってのはなんかの宗教か?
昔々の共有VAXで長時間のビルド中にそこそこの確率でポカで落とされたり、とかのコストと現在のビルドコストが一緒だとでもいうのだろうか。
Re: (スコア:0)
お若いの、年寄りの話は聞くもんじゃ。
Re: (スコア:0)
むしろ物理的制約無い故にちゃぶ台返し行っても期間もコスト変わらない、と考える人が多い(国内での話)のでむしろマイナス作用が大きい。。
Re: (スコア:0)
一品モノの金融ソフト「せやな
Re: (スコア:0)
> ソフトの対応費用は対応製品数に依存しない固定費なので、
おひとりさまで100人日のデバッグ作業もこなせるってこと?
Re: (スコア:0)
そらサムスンの技術者も、パッチ当ててnote7の問題解決しろとせっつかれたろうよ。
60%しか充電できないパッチとか。
それ解決じゃねえだろと思いつつ、エンジニアは作ったと思うよ。
Re: (スコア:0)
60%充電で爆発しないなら、割りと悪くない対応なんじゃないかな...
というか、バッテリーライフが伸びるから、そのパッチマジでほしいですね。
Re: (スコア:0)
NECの某モバイルルータ、バッテリ寿命を伸ばすかわりに70%程度までしか充電させない設定ができましたっけ、そういえば。
Re: (スコア:0)
正にその通り、70%で充電停止です
しかしこれで本当にそれなりに長く持つからどうしたものか。
by中の人
Re: (スコア:0)
追伸 銀河のあれば充電速度と消費電力計算も不味いと思う、もしかして充電容量だけ六割相当にしてるだけだったりして
Re: (スコア:0)
そもそもそれでも燃えたとか、交換品も燃えたとかめちゃくちゃだと思うんだけど…
Re: (スコア:0)
ソフトウェアはデータを作り直す=IT業界はサービス残業が基本なのでコストはかからない
ハードウェアは物を作り直す=材料費がかかる
現場からしてみりゃ容易じゃないんだけど、上層部からしたら容易なんだよ。
Re: (スコア:0)
下手すると金型とか、一点ものとかそういう高価なものまで作り直さないといけないしな。
少し違うけど、自前で大量のハードを買ってデータセンター作った後に「やっぱAWS使うわ」とか言われたら・・・
GoogleCloud使う予定でAWSに乗り換えるのとは大きな違い。
Re: (スコア:0)
まあ普通に配線や配管一つ取ってみても、配管した後に「やっぱいまのなし」ってやろうとすると、
内装壊して壁を引っぺがしたり、ビルでいえば数階層取り壊したりしてから改めて作り直しする
「デリートとビルド」に膨大なコストと時間ががかかるけど、
ソフトの場合はデリートとビルド「だけ」なら、ほとんどコスト0だしね。
ただしどこを削除して変更するか、設計図を引いて検証する作業そのものはやはりかかるから、
複雑な物を作る時の変更コストは安くはない。そして作ってる対象というのは年々複雑になる
傾向があるから……。
結果として「ソフトのことはよく分からんけど、ソフトなら変更なんて簡単でしょ?
チャチャッとやっちゃってよ。」になって現場が泣きを見ることも多いと。
Re:そりゃ (スコア:2)
また、そういうところってソフトウエアに期待する部分でもあるので、プロセスルールでガチガチに縛っても誰も幸せにならない気がします。
あと、ソフトウエアの再設計で取り壊しに相当するのは、ファイルの消去や文章の削除ではなく、それまでになんとか一貫性合理性を持つように構築した概念の破棄なので、結構コストかかります。作るのに手間取ったり手を抜いたりしたらその分、一部をやり直すのにコストが高くなるのは、同じようなもんだと思いますね。
Re: (スコア:0)
ソフトウェアは、自社開発で、ハードウェアは外注の比較になってないか?
ハードウェアでもあるだろ、サンプルもらってタダで仕上げろって
Re: (スコア:0)
いや、だからデスマが絶えないのだろ?
Re: (スコア:0)
むしろ、ハードウェア設計の不具合もソフトでどうにかごまかすのが今の開発だろ
Re: (スコア:0)
>例えば、セレモニーに使った3層吹き抜けの多目的シアターの天井にぶらさがる照明。
>直径3メートル、重さ900キログラムの照明には50万個の発光ダイオード(LED)が埋めてある。
>ショーの内容にあわせて電子制御する仕組みだ。
http://www.nikkei.com/article/DGXMZO01967040W6A500C1000000/ [nikkei.com]
照明AとB、CとDがそれぞれ同期してON/OFFしなければならない所を、ちょっと配線を間違えて
AとC、BとDがそれぞれ同期してたら、やっぱし「ソフトウエアで直せ」って言われるのかなあ。
たしかに壁を引っぺがして、船内の配線をやり直すのに比べたら、ソフトウエアを書き直す方が早そうな気はする。
そして照明制御プログラムのソースをみたら、配線に負けず劣らずのスパゲッティで、涙するとかあるある。
Re:そりゃ (スコア:1)
よくあることじゃん。
で、コードだけ見るとどう見ても間違ってるから
気を利かせて直す奴がいて、そいつが辞めたころに
誰かがその地雷を踏む。
Re:そりゃ (スコア:1)
これって、コードにひとことコメントを書けば済む話なんですけどね。
Re: (スコア:0)
いや普通にチューブマーカーなりで書かれてはいるのだけどな。
他にもブロックごとにコネクタを変えて間違ってつなげないようにするとかイロイロ行われている。
が、もともとの図面が間違っているなら、そんな現場側で理解できる対策なんぞ何の役にも立たない。
どころかこの前見たのは、職人が経験で正しく配線したものを、検査人が間違った図面を頼りに確認してわざわざ違う様に繋ぎなおしてしまっていた。
でもって、それで基盤が一枚パー。
Re:そりゃ (スコア:2)
プログラムコードのことだったんですが、これはこれで良いので、結果オーライということで!
Re: (スコア:0)
その例では
図面作った奴:アホ
職人:図面の間違いに気づいたならフィードバックしなさいな
検査人:被害者
じゃねーかな
Re:そりゃ (スコア:2)
コードの間違いをコードで治すw
Re:そりゃ (スコア:1)
# フィードバックする事で、図面作った奴の機嫌を損ねて、次の仕事から呼んで貰えなくなったりとかね。
Re: (スコア:0)
それが出来るのはソフト連動の機能部品のみだ。
それ以外のモノが山ほどあるから焼け石に水。
Re: (スコア:0)
手で触れるブツ(材料費)以外のコストは0だと考えるんですよね
実際は人件費に変わるだけなのに
その人件費は無駄なコストと考え低賃金や長時間サービス残業等で無限に圧縮しようする
Re: (スコア:0)
普通と言ってるが、正常とは言ってなぃ
Re: (スコア:0)
後でいくらでも修正できるソフトウェア(ごめんなさい語弊がありますね)と
一度作ったら容易に変更できないハードウェアの違いだろうなあとしか。
しかしみんな慣れ過ぎだよ(涙
ハードにもソフトにも仕様変更がかからない部分があってそういうところから開発を始めるから、ソフトもハードも関係ない。
Re: (スコア:0)
コードって、いったん埋め込むと後から修正するのは大変だよ。
埋め込んだが最後、どこを通過しているか、どこで分岐しているか。
スパゲッティになって他のコードと絡んでしまうと最悪。追っかけきれない。
追っかけているうちに無駄にループしているのを見つけるのも多々ある。
そういう場所に限ってなかなかアクセスできなかったりする。
後からいくらでも修正可能なんて、絶対にない。
#天井裏のコードの話だよねw
Re: (スコア:0)
往々にして後で修正すればいいやでゴミを作る会社ほど、「後の修正」でバグを出すなとか「金がかかるから既存を使え」とかゴミをゴミのまま存続させようとするのでロクに修正できない
最終的には使ったプログラミング言語が駄目とか他者に責任を押し付けて被害者面
Re: (スコア:0)
前向きに考えるんだ。造船業界にもアジャイル開発の波がやっとやってきたんだと。まだ彼らは慣れていないだけだ。営業航海しながら船体を同時に開発していく、ローリングリリースの時代になったんだと。
Re: (スコア:0)
で、2隻同時に航海して「ほんじゃお客さん、ただ今よりグリーンからブルーに移ってください」と。
さらにコレを「我が社では一日に1万回デプロイします(ドヤァ」とかすごいな乗りたい。