新しいものを表示

H3への反応の違い、防衛的悲観主義者的な考え方(><)と、楽観主義者の考え方の違いそのまんまな典型例なのでは?><
って気がする><
この事象に限らずわりと毎度毎度だけど><

H3打ち上げ失敗 JAXA会見【速報中】“H2A ただちに影響せず” | NHK | 宇宙 www3.nhk.or.jp/news/html/20230

"...また「H3」の試験機に衛星を搭載したことについて、JAXAの布野理事は「これまでも『H2B』の試験機では宇宙輸送船の『こうのとり』を打ち上げている。ロケットの開発においては万全を期して効率的な打ち上げを実施するという意味でも試験機で衛星を打ち上げるということはこれまでも実施してきている。『H3』でも万全な開発を行ってきたが、このような結果になって申し訳なく思っている」と説明しました。..."

@hadsn 「打ち上げ失敗」と「失敗」の混同って失敗だよね?><
失敗として認識出来た?>< 反省した?><
PDCAでいうと、その混同と言うDに対してCとAを十分に行った?>< どんな教訓が得られた?><
それとも強く指摘されて「そんな必要はない」と思った?><

@hadsn このやり取り自体、メタにオレンジが実演したって事に気づけた?><
オレンジが強く責めた事で次回に活かせる反省点の有無はどう見えた?><
記者の態度により工学的な視点を持てなかった事に反省できた?><
それともオレンジに反発して、自分はなにも改める点はないと考え将来に類似事象にあった時の事になんて想像をめぐらせなかった?><
もしかしたらJAXAの人も同じくらい愚かに軽く考えたかもしれないよ?><

@hadsn 「打ち上げ失敗では無い」と工学的な面での失敗があるかどうかは違うって話を最初からしていた人、オレンジ以外にどれだけ居た?><
オレンジの話に「それはそうだ」って形で肯定した人は少数居たけど、積極的に自分からそういう説明をした人はFediverse上ではオレンジは見かけなかったし、それ以外でも はてな匿名ダイアリーの業界関係者を名乗る匿名によるひとつの記事だけかも><

工学的な視点で「打ち上げ失敗(専門用語)」と「失敗」の違いをわけて考えられなかった事、そして記者の態度に自分の考えを惑わされたことを、工学関連の何らかに携わっている者ならば恥じて反省すべきでは?><
自分が行う工学的な作業でも同じように惑わされて失敗に陥る危険の兆候だよ><

三つの実験/調査をひとつにまとめた論文だからすごく長い><;

@hadsn 少なくともFediverse上にいるプログラミングをお仕事にしている方々のわりと多くが、その愚かな大衆側の反応をして「失敗では無い」と言って「打ち上げ失敗」と「失敗」の違いを理解しようとせず、記者が捨て台詞で間違ったことを言ったかのように言ってたけど><

記者の態度が悪かったのも事実ではあるし、通信社が出した「打ち上げ失敗」という記事は誤報だけど、「一般に言う失敗である」という点は工学的な視点でも間違ってないよ><

Frankly, We Do Give a Damn: The Relationship Between Profanity and Honesty - Gilad Feldman, Huiwen Lian, Michal Kosinski, David Stillwell, 2017 journals.sagepub.com/doi/full/

"...Innocent suspects, for example, are more likely to use swear words than guilty suspects when denying accusations (Inbau, Reid, Buckley, & Jayne, 2011). ..."

@hadsn 話の枕としてプログラミングの事例(失敗を強く恐れるプログラミング初学者)を元に話はじめて、実際プログラミングの場面でも対処すべきかつそれで絶望すべき「失敗」が多々あるって言ったじゃん?><
ファイルを新規作成しようとして名前衝突して作れなかったので名前を変えるなり既存のファイルを削除が必要になる場面を失敗って言わないとでも?><
Linuxのman見てみ?><
で、プログラミング初学者は「なんか失敗って出た・・・ よくわかんないしもうだめだ」ってわりとなってるでしょ?><
あらゆる面でド素人ならば、最初はそうなっても仕方ないけど、何らかの工学(プログラミングも当然含む)に触れてきた人が、失敗という言葉を避けたり「対処可能な失敗」と「取り返しがつかない失敗」、「有用に設計した失敗」と「なんの役にも立たない繰り返された失敗」の違いがわからないわけ?><

H3の話題で読みはぐっちゃってたけど、さっきのリーナスの話題の時に出てきた論文も、関連する事が書いてあるのでは?><

H3も事故原因究明に困難が生じても「はじめてだから仕方ない」は通用しないからね><
H2 8号機という教訓(テレメトリでどうにかなる部分ではなかったけど、情報把握の重要さを強く学べる事象)があり、組織運営上の問題(意思決定システム設計と作業環境構築の問題)ではASTRO-H事故という教訓があるわけだから、全然はじめてではない><

@hadsn 成功に目を眩ませるのも、攻撃(というか強い指摘)への反動で問題への注視を疎かにしてしまうのも、同様にクリティカルシンキング出来ていない証拠だし、打ち上げ延期の話の時にもオレンジが書いた通り、オレンジは全員が詳しくなるべき派なので、そこにばかり行って問題に注視できない事をかなりストレートに責めてたはずだよ?><
オレンジは、記者が酷いし「打ち上げ失敗(専門用語)」では無いという話とは別に、広義の(工学的な場面でも使う)失敗ではあるし、問題を混同するなって何度も指摘したよ><
覚えてる?><

打ち上げ延期に対して全面的に誉めてしまった人々は、「はやぶさ」の「こんなこともあろうかと」から何を学んだのか?><
「これ、今回は打ち上げ前だったから検証に手間隙かけてもいいけど、打ち上げ後だったら原因不明になるじゃね? ヤバくね?」って考えるのが正しいクリティカルシンキングなのでは?><
めでたしめでたしの話を、めでたしめでたしだけのみの話に終わらせたらダメなんだよ><

宇宙機というものは、問題が起きた時に現地に行ってどうにかするって事が基本的にできない(※1)ので、あらかじめの準備が必要で、十分なテレメトリも現地に人間が行けないからこそ入念に作ることが必要なの><
延期の時も、すぐに状況がわからずに実物にアクセスしての原因究明でやっとわかって、それに対して責めてる人が居なかった(それどころか一部称賛されてた)けど、打ち上げ後にはそれが出来ないんだよ?><
で、今回は打ち上げ後に問題が起きたね?>< どうするの?><
(※1 ハッブルとスペースシャトルの組み合わせという素晴らしい例外があったが過去のものになってしまった)

@hadsn その手のデータが迅速に出せない事自体をオレンジは組織設計(意思決定環境構築)の失敗の問題とテレメトリ設計思想の問題の両面で責めてるの><
打ち上げ延期も打ち上げ失敗自体も(そして実用衛星の打ち上げに使った事も)オレンジは責めていない><

@hadsn 一般人の宇宙機マニア かつ 航空安全マニア かつ UXデザインマニアですら改善すべきとソースつきで指摘できる点(報告書でも指摘されてる)を関係者であるJAXA(というかISAS)の人々がやってなかったのが、ASTRO-Hの事故><
打ち上げ延期の時にもそれ関連のオレンジの過去ツイートを自分で引用した><

orange さんがブースト

ここがこういう風に異常検知したのでこのようにシーケンスが中断したって出せる情報を全て説明すれば、涙目で記者会見する必要も無いかも><
広報のプロセスも状況把握と組織内の認識の共有も、あともしかしたらテレメトリの設計思想も他所のロケット屋とか宇宙機関の姿勢をもっと学ぶべきかも><
ある意味機械のデザインと組織のデザイン両方に共通する問題かも><
すぐに状況を報告できないテレメトリとすぐに状況を報告できない組織><

古いものを表示
:realtek:

思考の /dev/null