riskとuncertaintyと災害とプラグマティズム
copinemickmack 日本人はriskも全てuncertainty として扱おうとするところがある。だからriskに優先度をつけるという発想に乏しい。それは多分日本が有数の災害国でいつ何時破滅が訪れるかしれない、という悲観的な想定のもとで培われたプラグマティズムだと思う。
この解釈が正しいかどうかには疑問がある
「頑張って欠陥なく仕上げても災害でダメになるかもしれないから、当面動く程度の仕上がりでいい」という文化になる気もする
関連 日本人の仕事
copinemickmack 「心配事の大半は起きない。だったら期待値の低いことにリソースを振り向けるのは非効率だろ。もっと優先度の高い問題がある」。確かに機能面でもかなりの重大なバグが山積みになっている。非機能はどうしても後回しにされがちなのは日米共通だ。もうこうなると良し悪しというより価値観の問題だ。
copinemickmack 結局、客とも相談してコードは直さないことになった。問題になったらまたその時対処しよう、ということになった。リリース後、心配していた性能問題は出なかった。でもその理由はサービスが当たらなかったからではなく、重大なバグが見つかって全面的に処理を作り直すことになったからだった。
copinemickmack 米国人のプログラマの言うことは半分は当たっていた。心配事の大半は起きない。その通りだ。これは期待値で優先度を考えろ、という意味で、教訓的なものだと思う。でも個人的には後半にもう一文付け加える必要があると思う。それは「問題は誰も予想しなかったところで起きる」
copinemickmack 日本語だと「不確実性」という一語しかないが、英語ではriskとuncertainty という言葉で区別する。riskは確率がある程度分かるもの、uncertainty はそもそも確率が分からないもの。riskの方は期待値で合理的に対処が出来るがuncertainty は扱いにくい。我々2人とも後者に翻弄されてしまったのだった。
copinemickmack risk管理は米国人も真面目にやる。といっても日本人みたいに全部潰すわけではなく期待値の大きものから優先度をつけて対処する。uncertainty については、ある種の諦念を持っているように見えた。「想定できないものは想定できない」という感じ。
過つは人の常、赦すは神の業。
copinemickmack ちなみに予測可能なriskと不可能なuncertainty の区別は、経済学者フランク・ナイトが行ったもの。これ豆な。
higlabo RiskとUncertaintyは参考になった。
Risk→危険度
Uncertainty→不確実性
という感じだろうか。
危険度のほうは損害が起こることが確率的に確実に予測されるという事。
cats_works アメ車と日本車のコンセプトの違いみたいな話ですね。
片や壊れて動かなくなったら直せばいい、
片や壊れないようにまわりこみ、クオリティを高める。
日本人の思考は国土の自然環境の変動幅が大きいことも影響しているように思います。
smile27364 のソフト屋はバグに優先順位をつけ上位の物から修正し、優先度の低いものは対応しない方針でした。
日本ではできる限り修正していたので驚きました。
どれを直すかを客と交渉し、これは今回、これは次回、これは直さない、という風にリソース配分を調整し、工数を減らしていたのが印象的でした。
Taklm0128 今やる必要あるか?
ある/なし、についても議論は様々あるだろうが、違う角度からの意見として。
「納期や予算に余裕があれば、やる」
これには教育的な観点がある。
この米国人がコードの不味さを理解し、二度とその脆弱性を作らなくなるし、直した履歴が後進の教訓になるかもしれない。
tyatopon 現場踏んできた人間からすると、
「有識者が心配する悪いことは大体起きる」
と思ってますねぇ
もはやマーフィーの法則かな?ってくらいに。
若い頃は米国人PGと同じ考えでしたが、実際にいろいろ起きるのを目の前で見ちゃうと(苦笑)
DaisukeIkegami 日本人は自然災害と共に生きてきたので
「コントロールできないもの(自然)には抗えない」
とわかっている一方で
「コントロールできるものはコントロールしよう」
となりがちなのかもしれない。
災害(障害)が起きてから対応するのはストレスですもんね。
forthten 勉強になりました。ガルブレイスの不確実性の時代が人気を博していたときは未確定じゃなく不確定とはイヤガラセな題名の本を売るもんだなと思った。Uncertaintyでした。
Bear212No これはうちの会社でもよく議論になります。
機能とかはquantified impactでprioritizeしろ!と口酸っぱく言うけど、起こるかわからない事態、特に事態の定義さえないunknown unknownsをどうquantifyするべきか。
最終的に経験値の高いTLによるjudgement callに行き着きがち。
satonmybeat 想定された負荷と性能要件を満たすのであればバグではなく、満たさないならバグなので直すべきですね。
Taklm0128 議論は様々あるけれど、
おれはやっぱり実存するものこそ最優先かなと思う。
問題が起きるかもを考えることも大事だけど、それって哲学的なもので。
「実在のものより哲学を優先してはいけない」というのが真理だと思う。
つまり、納期が迫ってるのに、起きないかもしれない不具合を憂うなって感じ
VietorisMayer 昔の日本の製品の質の高さはその慎重さ、リスク回避が行き届いてるところにあったのでしょうね。日本人が完全にアメリカ人の真似を取り入れたらアメリカ人には勝てない。思考が違う。新自由主義的なコストカット意識から脱却することこそ次の社会に向けてのステップだと思います。
nekkokokko 安心と信頼ってそういう事なのに
軽視するコメント多くて今どきっぽい世知辛さある
MM1707562032201 興味深い会話です。
どんな手を尽くしても「しょうがないよね。」で終わるものが沢山あるなと
そこをさらにユーモアや笑いに昇華できたら最高なんですが、それが日本人としてセンスないんですよね。。。
go_4_it_poll 仰りたいこと分かります。日米で組んでPJして思うのは日本人は心配性だということです。日本の方は不必要なStudyが多いことは事実ですが、米国の方は猪突猛進過ぎる面もあります。これが上手く噛み合うと日本が問題の芽を先に摘み、米国がすごい勢いで仕事を進めるというシナジーが起きて面白い。
hannnora アメリカと日本の商品販売も似たようなところがありますね、日本は卸から小売へとチェックをして通過したものしか販売しないので品質はいいですが手間や廃棄があるぶんコストが高くつきます
アメリカはそのまま販売するのでコストが安く済みますが適当に買うと傷んでいたりして使い物にならない事も
Hyotangtugi 日本の労働災害対策として実施されている「リスクアセスメント(危険の予測評価)」のコンセプトは、災害の可能性はその大小に即した強度の対策を取って一つ残らず潰す、というものです。
今どき流行りのカタカナ語ながら、これってとても日本的だったんですね。
Mahaluto_HLLJ 米国人の言っている事は至極真っ当な事だし、実際結果を出す人っていうのはこういう考えの人なんだろう。
でも事前にやれるだけの事はやっておきたいのよね。
OiLmaDiPworHksO テストだのリグレッションだのいろいろやらされてリリースしたらPMの伝達ミスでの仕様ミスがあった。修正したが、それをPMは客に伝えることはしなかった。その後修正で障害が起きた。正直に伝えようってPMや上級マネージャーに進言したらお前が報告しろと。。
ANINEKObySYSTER 自動運転車の日米の開発姿勢の違いが正にこれの典型で。
米中ともに「何人か死んでから直せばいいじゃん」。
aniaimugi1 いや、処理データ量も要件定義、設計しないで、開発始めちゃダメ
nonose987 どのくらいのデータ量に耐えられるようにするのかを要件として決めてないの?
szking99 問題起きても「起きたの?じゃ直すね」くらいにしか思わない文化ですからねぇ
electricmania_ ヌケモレ絶対許さないヤツですねー。
ヌケモレがあれば、クリティカルではない事でも
鬼の首を取ったように責め立てられますね。
クライアントやらユーザーやら上司やらに。