随筆（2023/2/21）:H3ロケットが打ち上がらなかったことと、故障時の警告ランプや、ダンプカーのブレーキの話

1.信頼のないブレーキの壊れたダンプカーを成功とは言いたくない

H3ロケット、打ち上げ「中止」。

これを外形的には、飛んでないから、稼働してないから、目に見える「成功」がないから「失敗」と呼びたくなるのは、まあそりゃそうなのです。

が、正直

「ブレーキの壊れたダンプカー」

が、そのままつつがなく動いて見えたとして、こんなダンプカーの稼働を「成功」と呼ぶ訳がないんだよな。

そいつらはいつ本格的に故障したり爆発したりするか分からんリスクの塊だし、おそらくごくふつうにリコール食らうやつじゃん。

そのレベルのものを、たとえ稼働したとしても、「成功」として素通しするか？

「いくつかの課題が見つかったので次は直したものをお出しします」

ということで、直したものを作らないと、その製品は実は何も信頼ならん。

そういう文脈での話がなされていたのではないのか？

2.ブレーキの壊れてないダンプカーや、ブレーキに故障のおそれがあったら即警告ランプがつく機械の方がよほど信頼できる

で、ものを新たに作る時の話をすると。

ものを作る時にうまくいくかどうかは、当然ながら本当は確証は持てない。初めてやることが成功するかというと、ふつう生きてても、「そんな都合の良い話ばかりな訳ねーだろ」となるだろう。

だから、リスクが読み切れない間は、非常時に直ちに停止できるということと、エラーメッセージの充実した中での動作確認というのは、ほぼ常に必要になってくる。

ものがプログラムなら、まだお値段のするものが失われる度合いは少ない（ないとは言わない。パソコンが爆発したらパソコン代は損をするだろう）。

で、機械等の場合、たいていそれは爆発したらものすごい損だ。

失われるから「何がアカンかったのか、どう直すと良くなるか」の指針も相当立てづらくなる。

中止して検証するなら、それは直しやすくなるので、次にマシなものが出てくるサイクルもかなり早い（というか、失われたらかなり遅くなる、というべきだろう）。

そういうことを繰り返して、故障の原因をできるだけ取った上で稼働するようでないと、安定した運用のできる製品にならない。

これで量産などしたら、客の前で爆発する地雷を売ってるようなものだ。そんなものは失敗製品なんだよ。そんなんリコールだよ。

3.「稼働するか」の前に、「故障してたら直ちに止められるか」、そして「故障があったら直ちに分かるか」を用意しておかないと、安定的な「成功」にたどり着かない

ということを考えると、「稼働するか」と同じくらい、「故障してたら直ちに止められるか」、そして「故障があったら直ちに分かるか」ということは大事になってくる。

「このブレーキは故障したらちゃんと警告ランプがつく」
「このダンプカーはブレーキがちゃんと効く」
そして
「このダンプカーはちゃんと走る」

ということが保証された場合、（ダンプカーに限らず）ものづくりは成功にどんどん近づく。

逆に、これらのどれかが欠けていると、それはたとえ一見成功しているように見えても、いつか故障するリスクを抱えたガラクタになってしまう。

そんなものを成功と呼びたくはない。むしろリコール対象を量産する訳だから、失敗の一類型であろう。

4.困難を解決したいなら、困難の度合いに応じて、リスクはたくさんあり、それらを取り除くまでには膨大なエラーメッセージと緊急停止ブレーキが要る

「何か世の中に問題があり、例えば非効率や力不足や機能の少なさがあり、それを解決するには新たな開発をせねばならない。そのやり方は未だに不明なところが多い」

場合、それが解決したら大きなメリットがあるのは明らかだ。

が、そのためには膨大なリスクをクリアせねばならないのもまた明らかだ。

だって、現にできてないものを、できるようにするんだよ。できない要因の洗い出しと防止はせねばならない。

で、途中まではかばかしい成果が上がらない、実験的な状況が続くのは、むしろ当たり前だ。

プログラミングで、自分の満足の行く便利なアプリを作ろうとしたら、たいてい膨大なバグ取りの日々が続くだろう。

そんな経験、ない？　設計が完璧ならバグ取りなんか要らない？

人のニーズがあったとして、それの内訳を完全に理解していて、それに対応しきれる設計を作れることは、ふつうない。

大抵は「あれ？　こうだったっけ？　足りなくない？」と悩むことになるし、「あれがやりたいのにその通り動かない。ナンデ？」と悩むことはもっと多いだろう。

＊＊＊

バグ取りのためには、事程左様に、エラーメッセージは整備されていなければならない。

また、しばしばプログラミング用の統合開発環境には「停止ボタン」がある。
軽微な失敗が観測されたら、その場で止めてテキパキ直さないと、修正の際にあまりにも非効率的だからだ。
で、エラーメッセージが出たら緊急停止して直す。

この繰り返しで、どんどんまともな製品に近づけていく。
いつか、誤作動の可能性をなくし切ったように判断されたら、これをリリースすれば、世間一般でいう「成功」というものだろう。

5.「成功に近づいている途中経過は、たった今成功していないから、失敗である」という反対キャンペーン、会計上はともかく、開発上はお話にならない

「成功に近づいている途中経過は、たった今成功していないから、失敗である」という理由に基づき、予算をなくして、もっとリスクの少ない投資に回そうとする話は、常にある。

会計の観点からは、これを一概に否定する気にはなれない。赤字でスッカラカンになって、店の操業すらできなくなってはいけないのだし。

＊＊＊

という訳で、「リスクがあるからやめましょう」はごもっともなんだけど、だったら非効率や力不足や機能の少なさの問題は何一つ解決されないし、困り続けるままだ。

それに耐えられるかどうかは当事者の困り具合の話で、反対キャンペーンをやる側がそれを「だって今でも非効率や力不足や機能の少なさに耐えてきたんだろ？　じゃあ耐えてくれよ。ずーっとな」みたいなことを言える道義がある訳ないんだよな。

開発による解決がしたいのか、節約した方がまだ割に合うのか、そこは慎重に考えた方がいい。

後者がよほどシリアスなら、前者の困りごとを放置してでも、節約せねばならないのかもしれない。

そこまで突っ張れないなら、前者のシリアスさを、後者が軽く見るの、本当にいけない。当事者じゃないんだから。

＊＊＊

特に「困りごとでコストが生じているものを、解決したら、長期的にはコストは減る」系の解決なら、後者を前者に優越させることが、コストに鑑みて実は損である。ということさえありうる。

こうなると、会計の理屈で、他所への迷惑と、会計上の不利益をもたらしていることになる。前者は「悪い」し、後者は「バカげている」。そういうドツボにはまっている気配があるなら、そこに固執するの、やめましょう。

特に今回のH3ロケットの売りは「低価格」なのだから、正にここは達成したら旨味の大きいポイントだ。

それ「に」また反対キャンペーン？　今のロケットの運用の高コストを改善するより、やめた方がコストが下がる？　そうはならんやろ？

6.「ブレーキの壊れた、警告ランプのつかないダンプカーが走ってると、成功に見える」の、成功と呼びたくはないし、もしそれを成功と思いたいのなら、やめましょう

警告ランプとブレーキが効いたダンプカーは「まとも」なんだし、それはちゃんと警告ランプとブレーキが効いたから、またしも直しやすい類いのリスクなので、直せばもっと「まとも」になるし、基本的には正しい方向であろう。

「ブレーキの壊れた、警告ランプのつかないダンプカーが走ってると、成功に見える」の、成功と呼びたくはないし、もしそれを成功と思いたいのなら、やめましょう。

それは、そういう、失敗への道です。

（以上です）