  |
はてなキーワード: POSとは
紙の本なんてのはいい例で、第三次世界大戦待ったなしのこの現代で、EMP攻撃されたときに増田も見れやしないので挙がってくる
それ以外にも現金払い（銀行使えない）、ガス（停電）、有人レジ（POSの端末やシステム障害）もその1つと言える
きっぷというシステムは、未だにJRの怠惰で電子マネー100%になっていないから挙がってくる、これは徳島県に電車が居ないのも共通する
まだ光とは違うナローバンド回線が存在していたり、先ほど言った現金払いなんかもこの一つになる（被ることはよくあること）
スマートロックを導入したいけど高いから普通にカギで閉める、ハイエンドPC使いたいけどクソ高だからザコPC使うなど
Not Financial Advice。個人的メモ、現状の文字起こしと雑な未来予想。自分もWeb3ヤーとして整理したかった。
根源的にビットコインは規制で禁止することはできないので、できるところから規制されるトレンドは今後も続くだろう。目下、短期のナラティブはETF承認である。AML/CFT観点でビットコイン現物の流通はなるべく制限したい規制当局側と、ビットコインのエクスポージャーが欲しいだけの大多数の投資家の思惑の両方が、現物ETF承認という形で結実するのである。その後、ビットコインETFが高い流動性を持つようになれば、既存金融機関はビットコインETFを担保にした金融サービスや派生金融商品を展開できるようになる。
また、大手マイニングプールと、（すでにマイニングプールの株主となっている）ETF取扱金融機関が提携する未来もありえるだろう。例えばマイニング収益はプール参加者のウォレットアドレスに引き出されることはなくなり、プール参加者の証券口座にETF残高として入金されるようになる。これはプール参加者と規制当局どちらにも利点がある。プール参加者にとっては、ブロックチェーン手数料や秘密鍵保管といったブロックチェーン特有のリスクを負わなくて済むし、ビットコインETFを通して既存金融の多種多様な流動性へ容易にアクセスできるようになることも喜ばしい。規制当局にとっても、本質的に規制できないマイナーとBTC現物が切り離されることは喜ばしく、win-winなのだ。すでに大手マイニングプールはマイナーにKYCを求めているので、マイナーは分散思想よりも規制された安定を選んでいる。マイナーが投資家保護環境の整ったETFに乗り換えるのは合理的な選択なのだ。
ビットコイナーの思想とは相反するものの、市場原理とは相反しない力が優勢となって働くことで、ビットコインはATHを迎えるのである。
マイニングプールが結託して51%攻撃を起こすことは、マイニングプールにとっても合理的ではないので、少数マイナーの寡占状態が直接的にビットコインを破壊に導くとは考えにくい。しかし、大きな金額を動かさないといけない巨大プールは既存金融に保護されざるを得ず、規制の圧力に対しては脆い。同じ51%でも1 ✕ 51よりも25+26の方がCensorship ResistanceやOpennessといったブロックチェーンの本源的な価値は損なわれやすい。なのでマイナーに寡占が起こることを問題視しないのも間違いである。
https://x.com/nook_ethereum/status/1696476655475171759
仮の話だが、完全に当局の規制を受けてコーポレートが牛耳る、本源的な価値を失ったビットコインが、too big to failな状態でゾンビ化した時どう振る舞うのだろうか？そのタイミングで古参クジラは離脱して一時的に売り圧が発生する気もするが、そのままトリクルダウンとなるほどのトリガーかというと分からない。これはビットコインに使われる暗号の危殆化などのリスクと一緒で、起こるまで想像ができない。そのフェーズはP2P電子決済システムビットコインという壮大な社会実験の重要なハイライトになるに違いない。
ビットコインのブロックスペースを使って、レイヤー2上で好きなブロックチェーンを誰でも立てられるようにする新機能。まだ提案段階の機能だが、賛否両論を招き、界隈を真っ二つにしている。
ちょっと前に流行ったStacksの仕組みと異なり、BTCを子チェーンにオプトインするような仕組みも備える。もちろんオプトアウトもできる。
ただし、Drivechainが認められると、ビットコインのスケーラビリティを向上させるソリューションとしてのLightningネットワークの意義がかなり失われる。Lightningは”P2Pで”高速決済したい人が使うための機能という、かなり思想が強い人向けの錆びついた技術になり得る。
Drivechainの提案自体は昔からあったが、最近になって流行り出したのは単なるナラティブ作りであろう。ordinalsやStacksもそうだが、新しい技術はそれだけで盛り上がりやすい。ordinalsの場合だと、昔から追っていた人は、自分が優位でいられる情報が非対称的な時期に、短期で出口流動性（イナゴ、養分）をたくさん集めて、たんまり儲けて売り抜けることができた。
ちょうどBitcoin, not Cryptoな時期で、Drivechainのような特大アップデートがあればナラティブとしては強力だ。しかし、だからこそ、どうしてもDrivechain利権の存在を勘繰ってしまう。Lightning利権とも対立しそうだ。
Lightningはビットコインにマルチシグだけあればできる機能だが、Drivechainはソフトフォークとは言え、これだけのために新規のオプコードやメッセージの追加など、開発リソースをかなり費やす大幅なアップデートなので非常に図々しい。ソフトフォークをexcuseにすればなんでもありだと言うわけではない。
今更dAppsが走るサイドチェーンを作っても、Ethereumで起きているようなゴタゴタをビットコインに持ち込むだけで、Bitcoin, not Crypto神話を汚すだけになるだろう。
実質管理者のいるDeFiも規制の煽りを受けて存続は難しくなっていくだろう。ハッキングやインサイダー、スキャム（詐欺）、ラグプル（持ち逃げ）から投資家を保護できないファイナンスは、たとえゲイリー・ゲンスラーがSEC長官を退任したとしても長期的には必ず規制対象になる。また、そうはならなくとも投資家の方から勝手に離脱していく。
しかしながら、オフショアで規制の及ばないチェーンを舞台に、リスクを恐れない投機家の間でDaFi（Dark Finance、闇金融）に転じたDeFiがしぶとく生き残るのはどうしようもない。
ただ、そのようなDeFiはもう社会生活の金融インフラになることはないだろう。結果的に今のDeFiはDaFiかCeFiに分岐していく。
CeFiという語彙は以下のツイートから使わせてもらった。ブロックチェーンを使っているが、規制もされている金融サービスくらいの意味だ。
https://x.com/kimurayu45z/status/1695988782871498898?s=46
ブロックチェーン上の金融サービスに規制をかける場合、どのようなものになるだろう。まずCeFi事業者に対する当局による管轄、投資家のKYCは必須になる。そうなってくるとブロックチェーンでやる必要はあるのかいよいよ分からなくなってくる。かの有名なWhy Blockchain？の声がまた聞こえてくるのだ。
少なくとも、トークンでガバナンスするような機能をプロトコルに組み込む必然性はなくなり、ガバナンストークンは株や証券に近いものになっていく。また、仮にアプリケーションどころかL1チェーン自体が規制されれば、PoSなどのトークンベースのコンセンサスアルゴリズムはもはや茶番になる。
ユーザー目線でも、KYC済みのアドレスをスマートコントラクトに登録してまで、入札や取引したい投資家がどれくらいいるのか今のところ分からない。
もしもかつてのDeFiバブルが違法事業者の非合法的な取引で盛り上がっていただけの幻想だった場合、KYC後のクリーンなCeFiにどのような実需があるのだろうか。
MEVというのは、ブロック生成者が承認前のブロック内の取引を盗み見れることをいいことに、他人の取引を先取りしたり、順序を利己的に入れ替えることが可能である性質から生じる、ブロック生成者が独占できる収益源泉のことである。
https://keccak255.substack.com/p/mev
MEVがあるせいで、ブロック生成行為が中央集権化しやすくなったり、ユーザーのサービス体験が低下したりするため、dAppsが動くブロックチェーンにおいては重要な課題だ。
もちろん技術的に解決するSuaveのようなソリューションが提案されているのだが、分散化にメドがたっているわけではない。また、問題が外部化するだけで本質的な解決にはなっていないのではと思う。
Suaveについて参考までに
https://writings.flashbots.net/mevm-suave-centauri-and-beyond
また、MEV利権がすでに巨大化している政治的な事情もあり、問題はかなり複雑化している。このように込み入った問題を、さまざまなステークホルダーの思惑が入り混じる、非効率的な分散ガバナンスで解決するのは前途多難と言わざるを得ない。
チェーンのTVLが巨大化し、RWA（real world assets）などのMEVファクターがチェーンのエコシステムの隅々まで組み込まれれば、MEVがもたらすマイナス・サムの影響はユーザーにも感じ取れるくらい甚大なものとなるだろう。さらに、可視化できないリスクを嫌う大手投資家の参入を阻むことにもつながる。
そうなったとき、パブリックブロックチェーンの夢は雲散霧消するか、中央集権が正当化された世界でregulatedなブロックチェーンが生き残っていくかのどちらかになる。
一旦DaFiやCeFi、MEVのことは忘れて、全てが解決して、DeFiがそのままメインストリームになった社会を想定してみる。そこで注目したいのは、チェーンに閉じたDeFiでは信用創造ができず、分散型ステーブルコインなどの場合は常にover-collateralized（過剰担保）させなければならない点だ。つまりロックされた資本以上の価値が市場に再投資されない。原資本は再投資のたびに指数関数的に薄まっていく構造になってしまうのだ。
そのような先細りの金融インフラの上に展開される資本主義及び自由市場経済社会が、規制された金融に基づいた現状の社会よりも、高い資本効率と経済成長率を達成できるのかは甚だ疑問である。
一昨年のDeFiバブルの正体が、USDTなどの法定通貨担保型のステーブルコインがチェーン外から流入することで起こったに過ぎなかったのだとすれば、DeFiの世界はCe要素なしには拡大できないということになる。実際、USDT、USDCなどの法定通貨担保型のステーブルコインの時価総額は無視できないほどに巨大だ。そういった規制アセットの流入なしにはリターンが期待できない構造的欠陥がある限り、DeFiは規制を拒んで信用収縮の道を選ぶか、信用創造のために規制を受け入れてCeFi化していくしかない。
分散や自己主権といったブロックチェーンの思想を全く気にしない大多数のユーザー目線で見ても、国際送金や金融取引が瞬時に透明性高く行えるブロックチェーンが便利なのは間違いない。しかし、それは既存の金融サービスが規制というかなり重いハンデを付けられた状態で戦ってくれているからそう見えるだけで、ブロックチェーンという技術自体がイノベーションだからではないのではないか？つまり、仮に規制の側が妥協して、金融業界がリバタリアン並みの自由化を勝ち取った時、ブロックチェーンは、例えばApple銀行のような大規模なWebインフラを使った金融サービスに技術として勝てるのだろうか？
もしも、ポンジスキームやスキャムであることが明らかなミームトークン、発行主体を名指しできるXRPや、ガバナンストークン全般が、規制されない（もしくは証券ではない）と判決された場合、Apple銀行がプログラマブル・トークン発行プラットフォームを立ち上げればブロックチェーンは競争に負けてしまうのではないか？秒間取引処理数が少なくて、手数料も高く、ウォレットも使いにくいブロックチェーンの優位性はどこにあるのだろう？
とはいえ実際に既存金融が完全自由化することはありえない。あり得るのは、既存金融業界とブロックチェーン業界が融合していく中で、その両極からの声を取り入れながら、長期的には両者の境界線が最も曖昧となるような規制環境が整備されていくシナリオだ。それはトークンの証券化かもしれないし、証券という概念が古くなるような全く違う新しい法概念や規制のフレームワークの誕生かもしれない。そうなったとき、果たしてブロックチェーン技術が市場で競争力を持つのかは、改めて問われなければならない。使いやすさより分散思想を優先するユーザーなんて殆どいないはずだ。
日本のWeb3界隈は、昔から霞ヶ関を巡回する界隈と海外組の界隈に二分されていたが、最近は海外からの出戻り組が増えてきたように思える。かつてJapan色がなかったAstarが最近はJapanを押し出すことが増えてきたので、これも出戻り組と言えるだろう。京都で開催されたIVS Cryptoでは、かつての海外組が、今後は日本にもコミットしていくしたたかな姿勢も見せていた。
Astarが政府機関やJTCと手を取り合って、提携関係や共同研究関係を結び始めたときは、何をしているんだと正直思っていた。しかし、当時から規制側に歩み寄らなければブロックチェーンは存続できないと読んでいたのか、単なる嘘から出た誠なのか、こうなった今では一定の妥当性が理解できる。
とはいえ規制と近づきすぎるとパブリック・ブロックチェーンの特性が邪魔するはずなので、その擦り合わせは茨の道だろう。Why Blockchainの最前線で闘う姿勢は評価したい。
渡辺氏も、もしAstarがダメになっても、日本は偉い人と仲良くしておけば何とかなる国なので、かつてのホリエモンのような毒を出さなければ、どこかしらの利権に入れてくれるだろう。そこら辺を踏んでいるのか、彼のポジショニングは上手いなと思う一方で、FTXのサムが破滅直前まで政府と蜜月関係を結ぶのに奔走していたことを思い出させるから少々怖くもある。当局に近づくと不透明性が増すので、個人的にはまだASTRに買いを入れる勇気が持てない。
さて、クリプト・コミュニティ一般の話だが、これも昔よりは成熟してきたと思う。悪しき通貨が自然淘汰される市場原理が働いたというのもあるが、個人の中にも、かつては歯に衣着せぬ物言いでオピニオンリーダーになったインフルエンサーが、今ではバランスの良いコメンテーターになったりと、心境の変化なのかポジショントークなのか、変化を感じざるを得ない。日本人垢にも外国人垢にもそんな人は多い。
例えばVitalik氏は、かつては大衆向けに過激なことを吐いていたが、最近は難解な理論の提示にとどまり、過激な使い道を見つけるかどうかは受け手の自由ですよ、という我関せずな態度に改まった。
むしろ危ないのは、陰謀論界隈や極右派をバックにした米国会議員をはじめとするすでに過激なコミュニティが、ビットコインやWeb3に活路を見出そうとしていることだろう。余計なポリコレリスクを抱えると面倒である。
このタイトルは煽っているように聞こえるかもしれないが、流行りに乗っただけで煽ること自体は本意ではない。ジブリのあの映画を見た頃、こんなこと考えてたんだなぁと後でエモくなるための筆者なりのギミックなのだ。もし不快な思いをしたクリプトに携わる人や投資家の方がいれば、そこは大目に見ていただきたい。
契約書袋綴じを指示されて和書の袋綴じをして怒られたって棘がバズってるけど
https://b.hatena.ne.jp/entry/s/togetter.com/li/2205369
いや、元々契約書の綴じ方も和綴じの袋綴じをしていて今でもやる場合があるのだ。そして昭和の契約書やら判決文、戸籍謄本などの法的文書は和綴じの方の袋綴じがされている。
そもそも現代の契約書の綴じ方には「袋」になっているところがない。なのに袋綴じと言われるのは和綴じから変わったからなのだ。
なんで平成中期というか1990年代前半に替ったかというと、コンピュータの出力法が変わったせいなのだ。
契約書などには割り印をする。ページの差し替えをされない為だ。そして契約時点で書面の内容に異存なしという意味で双方のハンコをページにまたがる形で押す。また背表紙の封紙と表紙にも割り印をする。
ページの割り印の仕方は、上の余白で折って隣のページとまたがる様に押印する。
でもこれちょっと無理やりだと思わない？
実は1990年代までは今のように両面印刷して製本するのではなく、原稿用紙のような升目用紙（内容証明用紙のようなの）に手書きで書き、それを半分に折って重ね袋綴じしていた。綴じるのに使うのは布の「こより」で、千枚通しで穴を開けてから紐を通す。河野太郎が廃止させたやつだね。だから千枚通しはオフィス用品だったのだ。
そして袋綴じされた紙を膨らませて片側のページを山型に折ってそこに割り印をしていた。
「ワープロ」を使うようになっても同じ。片面印刷して袋綴じにして割り印をする。
なんでパソコンじゃなくてワープロなのか？これは後で説明する。
戸籍謄本などはやはり手書きで同じように袋綴じされて割り印され渡された。
そもそも「謄本」と云う言い方をするのは、昔はコピーが無かった（青焼きはあるがコストが高くナンセンス）ので手写しであり、書面の中身を全部写したのが謄本で、労力が大変なので必要な部分だけ写したのが「抄本」だった為だ。今でも閉鎖謄本/抄本を請求するとこの形式で出てくる（流石にコピーを使うが）。そして和綴じ式の袋綴じで割り印されている場合がある。
こより綴じの方は昭和後期には省略されてホチキスになり、これは市役所や弁護士が先行したようだ。だが契約書類はこよりorこより＋封紙＋割り印が使用されていた。
コンピュータで印刷するというのは今では当たり前で、印刷するのは白いオフィス用紙で、一枚ずつ印刷される。
だが嘗てはコンピュータで使われるプリンタはラインプリンタが主流だった。ページプリンタはDTPなど特殊分野でのみ使用され、一般的なOA機器メーカーはラインプリンタしか製造していなかった。
ラインプリンタの用紙というのは、両側に穴が沢山開いてて薄緑などで罫線が引かれていて、ミシン目が入ってて切り取りが出来る連続用紙の事である。
ラインプリンタの場合、印刷の区切りが一行づつになっていて、プリンタに印刷指示が送られるとそのテキストを印刷して改行の必要がある場合は改行しそこで終了する。ミシン目まで行送りするという事は無い。
だから票として一枚ずつ切り離す場合は、ミシン目が来るところまで行送りを行って停止するという印刷指示を組んでおく。
また、嘗ての標準出力の延長でもあるのでコマンドラインとの相性も良く、リダイレクトやパイプ（|）でデバイスファイル（lp、PRN）にテキストを流すとそれが印刷されるという簡単さであった。
ラインプリンタはページプリンタに押されて無くなったかに見えるが、実はPC POSで印刷されるレシートはラインプリンタの生き残りだ。
プリンタの印刷方法はインクをしみ込ませたインクリボンを活字で叩くというのが主流で、日本語圏だと沢山のピンを弾いて打つ、ドットマトリックス方式が主流だった。これだと一字のドット数が16*16くらいが限界なので、細かい漢字は打てない。
だからカタカナ+数字しか出力されない伝票などの使用が主で、ページプリンタは普及しなかった。
一方、ワープロ専用機は最初からサーマルプリンタを備えていてページプリントが前提であった。だから普段のオフィス業務はコンピュータ＋ドットマトリクス、文書の清書はワープロというのが一般的だった。
これで法的文書もワープロで作成し、縦書きで出力して手書きと同じ袋綴じにするというのが増えてきた。
今でも弁護士の文書で表題に倍角文字が使われたりするのもこの名残だ。
これがWindows95が普及するとページプリンタの普及も進み、イントラネットに接続される複合機が普及するなどで印刷＝ページプリントとなったのだ。そしてやがて法的書類も両面印刷して製本するという形になった。
その時に本来の袋が出来る袋綴じは過去のものとなって袋が無いのに袋綴じと言われるようになった。故に今の袋綴じ方が当たり前になったのは20年位かと思われる。
因みにワープロより早くから、またワープロと平行する形で和文タイプというのがあり、これで升目用紙に、または白紙に升目用紙と同じ字の間隔で印刷するという方法もあったのだが、和文タイプというのはとても時間が掛かった。
この人は流石に遅過ぎなのだが、タイプするのが超絶大変な代物で、行政書士、弁護士など気合が入った士業と法務局、裁判所など気合が入った役所、気合が入った大企業の契約書など、兎に角気合が相当入ってないと使われない清書用アイテムだった。ある意味、100kgぐらいの巨大複合機より気合がある。
というわけで袋の部分が無いのに袋綴じという謎かけみたいな名前の背景にはオフィス史とコンピュータのプリンター史が隠れていたのであります。
昭和日本ではオフィス用紙も法的文書も原稿用紙も、B5だった。ずっとA4より小さい。会社でも役所でも裁判所の判決文でも全てB5だ。
だが1990年頃に役所関係の書類をA4にするというお触れが出た。これは国際化の一環で、ISOに定めれているのはA列だけでB列は日本独自規格。困ったことに当時一番の貿易相手国だったアメリカはアメリカンレターサイズをN倍したANSIという独自規格なのだが（またですか）、まぁレターサイズはA4に近いしA4を標準化すれば万事うまくいくでしょとの見込みだ。
これに数年遅れで企業も倣ったのでB5というのはパージされることになった。
世の中全部B5からA4に変わったのに、大学ノートだけはB5が主流のままだ。あれは何でなんでしょね？小さいと使いにくいのに。
今はオフィス用紙として白くてある程度の厚みがあるものが使われているが、これはコンピュータ印刷が一般化するまではとても薄いペラペラでテカテカつるつるしている紙が使われ、これが「公的な場所で使う」紙だった。
先述の手書き＆ワープロの升目用紙も全てこの極薄＋つるつるの紙である。両面印刷して製本されなかったのもこれが理由の一つだろう。
これは「カレンダー紙」で、紙を押しつぶす鉄製のカレンダーロールの間を極圧で通して押しつぶし、薄くする。
トレーシングペーパーやクッキングペーパーと同じだ。
また、請求書類の封筒は中の請求書の名前住所が見えてあて名書きを省略してあるが、あの透けた部分が透明ビニルじゃなくて透けた紙である場合もある。この透ける紙もカレンダー紙だ。
公的書類でカレンダー紙が使わるようになった理由だが、増田は羊皮紙の代替ではないかと考えている。羊皮紙は中世の欧州から使われていた「紙」で、羊やその他の皮膚の薄い動物の皮を剥ぎ、石灰水で皮下脂肪を除去して薄く削いで引っ張り、紙のようにした。 https://w.wiki/7FnV
鞣しをしないのがポイント。これは高額なので貴族の手紙や証文、聖書の写本など「公的」な書面に使われた。
これの代替の紙としてカレンダー紙が使われ、それが「高級紙」として日本に輸入されて、ペラペラなカレンダー紙を契約書や判決文に使うようになったのではないか？と推測している。
こういう訳で、昔の契約書やら公的書類などはやたら薄いのが特徴だ。破れそうで怖いのだが、そっとめくるだけなら破れない。
なお、トレーシングペーパーやクッキングシートは長期間放置するとバラバラに崩壊してしまう。これは硫酸で晒しをする為に酸性になっているからで、昔のペラペラ重要書類はそうはならないので、硫酸晒しをやってないのではないかと考えられる。
https://qiita.com/NaYuA/items/1cda0211ec44fb25d422
みんな大絶賛してるけど、これやばいやつよね
いわゆる「学生チート」ってやつで、社会人が言ったら全力全方位で駄目だしされるやつ
この「手放し称賛」が人を伸ばすんだと言う話をするなら、そのへんの大人も手放し称賛されるべきよね
さておき
POSの時【POSはPoint of Saleの略です】と説明してるのに対して
みたいなのが、非常に「わかってない感」を出しちゃってるよね
いや多分、脳内ではわかってるんだろうけど
説明口調で書くなら
みたいになる
技術用語として「await 演算子はプロミス(Promise)を待ち」みたいに直訳でドキュメンが出回ってるし
非同期で行うサーバーサイドの処理ではPromiseを使いましょうみたいなのが
サーバー書き込みなので、当然Promiseを返します、になってるんだろうけど
新人とかの、「わかってないけど書けます」連中が、大体こういう理解の仕方をしてるから
（Promiseを返すのはなんでだ？サーバー処理だから（ｷﾘｯ）
もちろん、学生なんだから良いじゃん、良いじゃん、すげぇじゃん
というのもアリなんだけども
このわかってない感満載の文章を、手放しで称賛して、「考えて行動するだけでスゴイ」みたいになってるの
「みんながあんまり誉めたりするから、私自分が優秀な人間だって勘違いしちゃったじゃない！！」を思い出させる
まぁ、学校自体はスゴイ進学校らしいから、当人はそんなんならずに大成するんだろうが
ちょっと話してみたい。昔の話だ。
若い頃、都内の繁華街にある飲食チェーンで店長職を務めていた。今はもう会社を辞めて実家に帰り、細々と親の仕事を手伝ってる。農業を営んでるから、食料品という意味では繋がってる。
あの頃はまだ30代半ばで、男が乗っている時期だった。心も体も無理がきいて、若者の考えもなんとか理解できて。懐かしいなぁ。今では50代が近づきつつある。
守秘義務とか一応あるから、どこの飲食チェーンかは言わない。読んでるうちにわかるかもしれないが。できればそっとしておいてほしい。
何の話をしようか迷ったが、『人』の話がいいだろう。何人かに絞って話がしたい。皆、よくも悪くも思い入れがある。三人だけ挙げよう。
もちろん仮名だ。雰囲気で名付けている。背は低めだったかな。危なっかしいけど、素直な子だった。だが、ある事件を機に店を辞めてしまった。
大学二年生で、MARCHクラスの大学に通っていた。やんごとなき方々が通いそうな大学名だった。私は専門学校出なので、大学生と聞いただけで眩しい感じがした。
彼は夕方～夜のメンバーだった。クローズまで残ることもあった。ところで、ある従業員I氏との折り合いが悪く、さらにスダ君が好きだった女子店員TさんがI氏と交際していることもあってか、勤務中に不安定な感じになることがあった。若さというものだ。
閉店作業中にI氏と諍いになることがあったらしい。マネージャークラスのアルバイト従業員の場合、連絡日誌を付けるのだが、そういう報告をみかけた。
実際、迷ったものだ。I氏は当時、二十代前半のフリーターで、付き合っていたTさんは大学四年生だった。I氏はほかの女子アルバイトにも手を出していた。時には、新人クルーを無理やり自分のビッグスクーターに載せて、当店の近くにあるラブホテルに直行することもあった。
相関図
I氏 ⇔ Tさん ← スダ君
↓
当時は2000年代の半ばだった。男のそういう行為も甲斐性のひとつとされた時代だ。迷惑行為ではあったが、相当の戦力だったため目を瞑らざるを得なかった。
ある年の秋、閉店数時間前だった。いつもだと、店の目の前にある事務所でシフトを作ることが多いのだが、この日ばかりは実店舗で指揮を取っていた。どんな時間帯にもインして、店舗の運営状況を確かめねば……という意識もあったが、正直この日は気分だった。
夜９時頃、スダ君がお店にインしてきた。この日は3時間半のシフトだ。だが、様子がおかしい。足早にタイムカードを切ったかと思うと、店の奥にあるシンクに手をかけてうずくまるように立っていた。
ほかのアルバイトも「様子がおかしいのでは？」と察していた。私は、スダ君と仲のいい大学生ふたりに事情を聴くように指示した。こういう時はこれでいい。私が聞いても真実を答える保証はない。聞き取りするとしたら彼らの後だ。
大学生ふたりが聞き取ったところによると、スダ君が事務所に入った時、こんなことがあったらしい。
・運悪く、スダ君が入ってきた音に気が付かずに目撃することとなった
・過去にもスダ君の目線からみてそうなのでは、と思うことがあった
これには悩んだ。どう対処すればいいのか。店を預かる者としては判断に迷うところだ。というのも、I氏もTさんも、はっきりいって当店の最高戦力（I氏はマネージャークラス、Tさんは接客専門職クラス）であり、辞めてもらっては困る。困るのだ。ただでさえ人手不足なのに。
本来は免職処分とすべきだ。事務所を本来の目的以外に使うな、とは言わない。待機時間に学校での課題を片付けたり、シフトを上がった後にお喋りをするとか、そういう使い方をしてもいい。少しくらいは。
ただ、過去においては、休憩室で飲み会を催していたクルー３名をまとめて免職処分にしたことがある。線引きが難しい。
結局、I氏もTさんも当店に残すことにした。I氏は「次やったら辞めさすぞ」と何度もクギを差したうえで、出勤停止の処分とした。Tさんは、大学卒業まで残り数か月だったのもあり、比較的温情のある処分をした。※思惑までは書かない。自分なりにバランスを取ったつもりだ。
スダ君には、「人生いろいろあるけど挫けてはいけない」「あなたはひたむきだから。きっと報われる時がくる」など精一杯フォローしたものの、冬になるまでには店を辞めて、同系列チェーン店に移籍した。確か、そこの店長から電話があって、「面接に来たけど、彼どんな子？」と聞かれたから、「ひたむきでいい子です。ちょっと心が弱いところもありますね。でも、戦力になりますよ」と答えた。今でいうリファラル採用だった。
それから約一年後、あの時スダ君から聞き取りをしてくれた大学生から連絡があった。スダ君が、移籍した先の系列店でマネージャークラスにランクアップしたという。私もその店に行ってみたところ、確かにスダ君がいた。社員と同じ服装でキビキビと働いていた。あの頃とは雰囲気が違う。人間として成長したのだ。
それからすぐ、私も遠方の店に異動になってしまって、スダ君を見ることはなくなった。今はどんな人間に成長しているのだろう。いい男になっているだろうか。そんな未来を願っている。
この子は、いわゆるプレーヤータイプの極致だった。ほかの繁盛店から移籍してきた子で、クルーとしての実力は折り紙付きだった。POSでの接客もキビキビとこなすし、サービスレベルは最低限以上だし、料理を作るオペレーション作業も人並み以上にできた。
どんな分野でもマルチに活躍できる子だった……ただし、現場作業に限っての話ではあるが。残念ながら、性格であるとか、人格であるとか、気質であるとか、そういうところに問題のある子だった。
話は逸れるが、圧倒的美人だった。街を歩いていたら男は皆振り返るし、雑誌でモデルをしていたとして不思議ではない。そういうルックスの子だった。
ただやはり、性格に難があった。気に入らないクルーに雑談を振られても冷たい態度を取ったり、無視することがあった。相手のことをミカンの皮くらいにしか思っていないのだ。
ある時だったか、フナモトさんの接客の現場でこんなことがあった（※当時は、女子で厨房に入る子は極端に少なかった）。母親と子どもふたりがレジに並んでいて、子どもがおもちゃ付きセットの説明を求めた。店内のカウンター横には、おもちゃの反則セットが豪勢に飾ってあった。※フナモトさんmaidになる。
だが、彼女は冷たい様子で「ポケモンです。種類はこちらから」とメニューを指さすだけだった。そのお子さんが十秒ほど迷っていたところ、フナモトさんがローファーの先でコーヒーシロップやストローが入ったラックを何度も蹴り飛ばすのが見えた。
またある時などは、夜の店内におばあさんがテイクアウトの注文後、「お水を持ち帰りでくれませんか」と言ってきた。フナモトさんはマニュアルどおり「お水は持ち帰りができません」（※衛生管理上の問題。お客の家で水が品質劣化した場合など）と答えたところ、おばあさんは「車にいる孫が薬を飲むので……水がほしいんです」とのこと。
さて、こういう時はどうすべきか。一応、会社のマニュアルには、接客については「ルールに準じつつも、自分らしい接客スタイルを求めてください。お客様のためになる接客を。迷った時はマネージャーに指示を仰ぎましょう」といったことが書いてある。
フナモトさんはおばあさんに告げた。「その子がカウンターまで来るなら用意できます」と。なるほど、機転が利いている。おばあさんが了承したところ、フナモトさんが水を用意してカウンターの前にいるおばあさんに水を届けた。
しかし、おばあさんは水を取って、そのまま車に戻ろうとしたのだ。フナモトさんが一瞬早かった。おばあさんの二の腕を掴んで、水泥棒をガードしたのだ。
船「ダメっていいましたよね!?」
婆「いいでしょ。やめて！」
船「ダメって言ったよな、おい!?」
婆「ちょっと！」
船「おい!! ……お廻りさん呼びましょーか？」
婆「……」
さすがに堪忍したのか、おばあさんは諦めて外の渋谷通りに留めてあった車に歩いていった。私はその様子を観ていたけど、どっちもどっちだと感じた。フナモトさんはお客様ファーストではなかったし、おばあさんにしてもジュースを買えばよかっただけのことだ。別に水でなくてもよかった。
私だったら、「本来は衛生管理上の問題があり認められませんが、今回はお薬の事情があるということで持ち帰りを認めます」と言っていただろう。マニュアルに反する行為ではあるが、これなら上の人間が観ていたとしても申し開きできる。
三つ目になるが、フナモトさんが専門学校を卒業する半年前のことだ。店内のポジションを替わりたいという要望があった。弊社では、漢字表記だと接客専門職とでもいうべきランクがあり、それに選ばれるとお洒落な制服を着ることができる。昔懐かしい、アンナミラーズの制服にちょっと似ている。
だが、それはフナモトさんのわがままに過ぎなかった。本人から理由を聞いたところ、「可愛い制服だから、最後に着てから卒店したい」とのことだった。当然却下したのだが、それに激昂したフナモトさんは「だったら店を辞めます!!」と宣言して、マネージャールームのパイプ椅子を立った。そのまま事務所を出て行き、二度と連絡してくることはなかった。残りのシフトはバックれてしまった……。
約二週間後、別の系列店から「フナモトさんという子が面接に来ているけど、どんな子ですか？」という問い合わせがあった。ちょっと迷った挙句に、こんなことを答えたかな。
「一本筋が通った子です。いい方に働くこともあれば、そうでないこともあります」
と告げた。嘘は言っていない。確かに嫌な別れ方はしたけれども、かつての仲間だ。応援はしたい。少なくとも、ほかの店への移籍を妨害したくない。
人格者じみたことを書いたけれども、保身のためでもあった。フナモトさんとは過去に二度、ホテルに行ったことがある。お店の公式飲み会があると、私はいつも若い子だけの方がいいだろうと思って（一万円を置いて）早めに帰るのだが、その時は最後の方まで残っていた。
宴も酣(takenawa)ということになって、二次会に行こうと幹事が言い出した後で、フナモトさんと帰り道が一緒になり、いろいろ話すうちに飲み直そうということになった。私はまだ三十代だったので、いろいろと抑えることができなかった。
フナモトさんの見た目はクールビューティといったところだが、いざ一緒に寝てみると情熱的なところがあった。やはり、体のいろいろな部分が柔らかかったのを憶えている。そういう体験が二度あった。
それで、上の段で電話を受けた時は、フナモトさんが暴走したらよくないことになるのでは……!? という懸念があった。そうはならなくてよかった。
思い返すと、これも懐かしい記憶だ。あの子は今も元気にしているだろうか。健やかであってほしい。
この子も鮮烈だった。当時は大学生。独得な雰囲気の子で、普段はボーっとしているかと思えば、厨房でのオペレーション中は熱気に満ち満ちていた。閉店時のクローズ作業も抜群に早かった。
難点があるとすれば、マイペースなところや、人を怒らせる発言をするところや、常識のなさだった。ある時などは、冗談だと信じたかったが、早朝の開店作業中に「今日は気合いを入れるためにビールを飲んできました!!」と宣言していた。
今でいうところの、発達障害というやつだと思う。そうでないならパーソナリティ障害か。医師ではないので判断はできないが。
さて、そのワタベ君だが、大学三年生のある時に「マネージャーになりたい」と言ってきた（※説明が遅れたが、正社員の仕事をするアルバイトをいう）。確かに、作業能力的には余裕でマネージャークラスだった。しかし、彼の発達障害的な言動は、他のアルバイト仲間の間では賛否両論だった。マイルールに対して過剰適応なところがあり、それが特に若い高校生クルーとの間に軋轢を生んでいた。
当時のマネージャー全員に賛否を聞いたところ、半々ということになった。これは低い数値だ。普通は八割以上が賛成する。そして、ワタベ君本人に対して「貴君の意に添いかねる」という意思を告げたところ、なんと……彼は弾けた。バックレたのだ。
フナモトさんと違って、自分のシフトはちゃんと消化していったが、店長である私に何も告げずに店を辞めた。ほかのアルバイト仲間には辞めることを伝えていたらしい。なんということでしょう……（劇的ビフォーアフター）。
でも、これでよかったのだ。こういう極端な行動を取る人間は管理者として相応しくない。彼がマネージャーになっていたとして、またどこかで軋轢を生んで誰かが店から消えてしまうような、そういう事態になっていたに違いない。
それから、約七ヶ月が経った頃だった。なんと、ワタベ君がお店に戻りたいという（ほかのマネージャーから聞いた）。なんでも、そのマネージャーにワタベ君が電話をかけて「就職活動が終わったので店に戻りたい」という旨を伝えたらしい。
これは、社会人でいうところの根回しに相当する行為だ。ワタベ君は成長したかもしれなかった。直球ストレートではなく、カーブを覚えた的な意味で。ワタベ君やるなぁ……。
実際、この時期はとんでもない忙しさだった。スタッフの頭数があまりに少なく、基準に達していない人でも雇わざるを得ず、それがまた現在のクルーとの摩擦を生むという悪循環だった。さすがの私も、相当な日数出勤することになった。時間外手当はゼロだった。名ばかり管理職というやつだ。
話が逸れた。数日後、ワタベ君とマネージャールームで面談をしたところ、次のような意見があった。
・もうマネージャーになりたいとは思わない
・これまでは申し訳なかった
・週に四日以上必ずシフトに入る
まあ、バックレではあるが、これからちゃんとするならいいだろうということで、ワタベ君を再雇用することにした。
しかし、私が人を見る目がないのは皆様すでにお分かりのとおりだ。本当に見る目がない。この会社でも、最終的にはエリアマネージャー（部長級）までは行けたのだが、そこでさらに上のクラスの人達と揉めごと（本部長クラスのセクハラ関係）を起こしてしまい、最終的には理不尽な降格処分（店長に戻れ!!）を突きつけられ、会社を辞めることにした。
さて。ワタベ君は普段はマジメだった。しかし、稀に凶悪な面を見せることがあった。ある日の早朝、お店の目の前に食品資材を搬入するトラックが停まっていた。ワタベ君は、せかせかと動いてトラックドライバーと協力し、荷台から野菜ジュースやコーラのシロップタンクやPotatoを下ろし、店内に運んでいた。
だがある時、見てしまった。トラックドライバーの目を盗んで、ワタベ君が野菜ジュースが50本ほど入ったビニル巻きの段ボールを――丸ごと盗んでいるのを。一瞬の早業だった。私でなければ見逃していたね。※一応、どうやって盗んだのかは伏せる。同様の行為を防ぐため。
その時ほど、自らの人を見る目のなさを恨んだことはない。ワタベ君はすでに雇用三ヶ月目だったし、彼がいなければ深夜と早朝のシフトが回らない。困った事態だった。当時の私には、見て見ぬ振りしかできなかった。
それから、ワタベ君は大学卒業まで店に在籍した。発達障害はやはりそのままで、ほかのアルバイト仲間との小競り合いが度々起こった。実は、ある時期から人手不足は解消していて、別にワタベ君には辞めてもらってもよくなっていた。クビにしようかと思ったことがある。しかし、性格や人柄が悪いとしか思えない彼が、多くのスタッフから嫌われながらも、一部のスタッフには懐かれているという現象を目の当たりにして思い留まった。
なぜ、そんな判断をしたのか？ 彼は本当に悪どい人間なのか、と思ったのもあるが――今風の言葉でいえば「多様性」だ。彼は確かに、社会人以前に人として未熟なところが多くあった。だがしかし、一部の得意分野においては紛れもなく輝いていた。だったら、嫌なところには目を瞑ろう。それが当時の私の判断だった。
風の噂だと、新卒時点での彼は、都内の某区役所で地方公務員としてのキャリアをスタートしたらしい。東京生まれの東京育ちだから、やはり地元が一番ということだろう。彼も、元気でやっているといいのだが。
以上で終わりになる。
当時を振り返ってみて、間違いだったと思われる行動は多々ある。どれだけ後悔しても足りない。でも、それも人間だ。迷いながら進んでいくしかない。
ところで、満たされない心というのは、すごく大切だと思う。当時も今も、満足できる仕事をこなすというのは、とてもとても遠いことだと錯覚していた。
成長していくためには、これまでの自分を一人ずつ殺害していく必要があるのだと30代の頃は思っていた。朝が来るから起きるのです、みたいな当たり前のことだと思っていたけど、違うんだな。
人生が満たされなくても、自分は自分なのだ。理屈も何もない。ただ、それだけだ。だから、店長として飲食チェーンで働いていた頃の失敗だらけの自分も、今では受け入れられる。そういう情けない私まで含めて私なのだ。再確認できてよかった。
毎年6月24日や8月6日を不謹慎だ叫ぶ人々や、3月11日を「何らかの記念日だし普通の日とすべき」と書かれたアンサイクロペディア、これら全てに怒りを感じたので増田は何ならそういう日の幸福な側面を扱ってやるというリストを作りました
それがオールラッキーデイズ（All lucky days）です
今日は何の日か分かってるよナ
本番は翌日に発表するゼ
徐々に分散していこう
結局富める者がどんどん富んでいくPoSの仕組みだとポンジ感は拭えないし、それでも分散とか全く気にしない大衆層がトークンを買い支えてしまっているのが問題。そういうトークンの配分でガバナンスなんて笑わせる。衆愚でマネーゲームできるようにしたことをイノベーションと呼んでいるのがweb3。
ガス代の安いレイヤー2のようなチェーンがでてきたので、マネーゲーム以外のアプリケーションが生まれる素地は整備されてきたような気がする
L2でガスが安くなったらギャンブル的なプロダクトの割が良くなるだけでは。それにDeFi以外のアプリケーションとして期待されていたNFTやBCGも結局はmoney Legoのパーツ化してマネーゲームに組み込まれている。
それならcosmosとかの方が良かったはず。どうして日本人は日本のプロダクトを贔屓するのか。そのせいで世界から取り残されてweb2で散々負けたのではないだろうか。
これは同意
スマレジはスタンダードコース「一店舗利用」なら0円で利用が出来る。
https://help.smaregi.jp/hc/ja/articles/360014532914-自動釣銭機-RT-300-とは
ヤフオクで本機15万ぐらい
https://page.auctions.yahoo.co.jp/jp/auction/d1054688183
なんか投資関係の記事がバズっているので、暗号資産クラスタについてぶっこんでいく。（この記事はfinancial adviceではありません）
日本ではまだ怪しい投機扱いされている暗号資産だが、アメリカでは既存金融にすでに取り込まれている。
仮にこの記事にブコメがついたとしたら、やっぱり投機投機書かれるだろう。そういう人はこの記事の対象ではないし、すでに三周は遅いので無視して良い。
さて、暗号資産というやつは、実はナスダックとの相関性がかなり高いことがわかっている。ので、投資すべきタイミングは米株と同じ考え方で良い。
レバレッジナスダック（いわゆるレバナス）は一度下がってしまうと、元の価格に戻ってきても評価額は減価してしまうが、暗号資産は元の価格に戻ってくる動きをしやすい。
身も蓋もないが、レバナスよりマシな商品と考えればあまり外れていない。
ので、もし現状のマクロ経済状態では米株投資すべきでないと考えるのなら、今は暗号資産投資をすべきではないし、逆に投資しても良いと考えるのなら検討しても良いだろう。
これ以外の暗号資産にお金を入れてはいけない。お兄さんとの約束だぞ。
慣れてる人はスマコン系の代替L1通貨とか、ORU/zkRUのL2系通貨にお金を入れてもまあ良いと思う。ただ、これは自分で一次情報を取れて、かつ本当に詳しいと自認できる人だけにしたほうが良い。
情報を追いたいのならumbrelやLNを追っかけているビットコイナー、またはMergeやDA、Shanghaiを追っかけてるイーサリアンをフォローしておこう。
ただしtoxicなビットコイナーはやめとけ。心が汚れる。あと「ビットコインも環境問題でPOSに…」とか言ってるイーサリアンもやめとけ。心が汚れる。
詳しくなった人はsolana/avax/cosmos(atom)などの代替チェーン情報を発信している人をフォローしても良い。ただし火傷に気をつけろ。
stepnとかiost, xym, xrp, 魔界アルトなんかの情報を追っかけてる人、あなたは向いてない。いますぐ暗号資産投資をやめろ。金を失う最短ルートを走っている。もう一度チャートを見直して冷静になれ。
aptosやsuiが天下を取る…と中身を理解しないまま思ってる人も情報の取り方を再考したほうが良い。あなたは賢いように見えて、大口投資家の出口だ。
NFTは消費として買っても良いと思えるものを買え。これはそういう業界だ。
投資としてNFTを扱いたいのなら、細心の注意を払って行え。今の市況では、難易度が高すぎる。キュレーターより厳しい世界だ。
情報をフォローしたいのなら、XCOPYやNOUNSに言及している人にしておけ。
WBTCはおすすめしない。カウンターパーティーリスクがある。
ETHは、PriorityFeeやMEVが貰えるようになるので多少利率が高まる。
課税イベントは起こさないほうが将来的な利益は高いだろう。なのでガチャガチャしないことをオススメする。
この記事の言っていることが正しいかどうかは、界隈のこの記事に対する反応を参考にすること。
ガソリンスタンドのタンクに水が混入して給油した車が故障、っていうニュースが世間を騒がせているが、自分が働いていたスタンドでも同じ事故が発生して騒ぎになった事があるので説明するよ。
https://b.hatena.ne.jp/entry/s/www.asahi.com/articles/ASQ8W6QFCQ8WULFA00P.html
ガソリンスタンドの貯蔵タンクは地下に置く事が義務付けられている。近所が火事になってもどうやっても引火しないようにする為だ。
でも地下って事は豪雨で付近が冠水したり洪水になったりすると水が入ってしまう可能性がある訳だ。
地下タンクには
1.荷卸し用（勿論燃料油）のハイプ
2.エア抜き管
3.給油機に繋がる吸い上げ管
が繋がっているが更に
b.直付け残量計
が付いている。b.直付け残量計はタンク直上にあって古い石油ストーブの燃料計みたいに針がゆらゆらして値を示すやつね。中にフロートが浮いててそのフロートアームの反対側が指針になってる簡単な造りだ。で、この直付け残量計の上にはマンホールがあって、水が入らないようにパッキンがはまっている。
増田の働いてたスタンドは、古くてマンホール面の地面が不等沈下して歪みが出ていた上にパッキンが劣化していた。
更に残量計のケースに使われているパッキンも痛んでいた。因みにここはガソリン蒸気などに晒されるのでゴムが痛みやすい。大体のスタンドはそのままになっていると思われる（フッ素ゴム、シリコンゴムなどを使うと痛まないがそれらの材質が一般化したのは20年くらい前の事だ）。
更に悪いことに、そのタンクは増設した小さいタンクで、普段は管路を締めきって使ってなかった。だから何度もの大雨で水が溜まって行ってしまったのだ。
そしてそのスタンドの夜勤で危険物保安監督者は増田だけで、管路の切り替えも増田しか出来なかった。
ただこの件では増田に落ち度が無かったので会社から叱られたりもしなかったが。
タンクローリーから荷卸しする注油口にもパッキンがあって、これが痛んでいてここから水が入るってケースもある、というかこっちの方が多い。
例えば、付近が冠水して注油口から水がドバーッと入ってしまったとする。すると水は重いので地下タンク内のガソリンを押し上げてしまう。それがエア抜き管からドバーっと吹き出してしまう。これは水面に乗って広がってしまうので火が付いて付近が火の海になる可能性があるのだ。洪水のせいで大火災の危険が生じるのだ。
2.計量器（スタンドの目に見えるところにあってガソリンを出すあれ）
スタンドの店員は毎日地下タンク残量を計量して記録する義務がある。
POSシステムは各タンクから出して販売した数量を記録していて、残量の推定値を表示する。
ローリー荷卸しがあったらそれも打ち込むので地下タンク残量とPOSの値は正確に一致するはずである。
…が、一致しないとなったらなにか原因があるって事だ。増えてる場合は水の混入である。
一般的にこれをやる意味は寧ろ「数字が足りない」場合に備えてだ。数字が足りない＝配管かタンクどっかからの漏洩で土中にしみ込んでしまっているという事で、非常に重篤な状態である。
勿論環境汚染でもあるのだが、土中にしみ込んだガソリンが地下水に混じって暗渠（地下化された川）や下水道に流れ込むと、そこで蒸気が溜まって爆発事故になる。台湾の高雄の大爆発事故は、パイプラインから漏洩した燃料がこうやって暗渠に流れて起きたものだ。
閉店間際のスタンドで店員がマンホール覗いてメモしてるのはこういう理由があるのである。
壊れないよ。だって燃料油には水が少量混じっている事が多いから。
スタンドの方ではパッキン類がちゃんとしてても地下タンクに水は入ってしまう。
ガソリンを売るとタンクの液面が下がる。すると負圧になってしまうので、エア抜き管が設置してある。スタンドにローリーが来てる時に頭が痛くなったりきつい臭いがするのは卸したガソリンがタンク内の蒸気混じりの空気をエア抜き管に押し出している為だ。
ガソリンが減って液面が下がると逆に空気を吸い込む。夏であれば高温多湿の空気が涼しい地下、しかもガソリン気化熱で更に温度が下がったタンクに入るとどうなる？
そう、結露です。結露してそれはガソリンの下の方に溜まるのだ。そしてローリーの荷卸しがあった時には攪拌されてオイルタイプのドレッシングみたいな混じり方をする。
その間に給油に来たお客の車に給油されるからモーマンタイである。
でも車のタンクの方でも結露は起こっているよ。ガソリン使えば空気は吸い込むし、ブレーキでガソリンが揺すられると気化が激しくなって気化熱で温度が下がる。そしたら結露するのは当然で、給油する前に何度も何度も結露し、その水はガソリンの下に溜まる。それは車の揺れで燃料ポンプ吸い込み口に吸い込まれてエンジンで燃焼されてしまう。
軽油の場合は水との親和性が高いので下に溜まらずに「水っぽい軽油」になってこれもエンジンで燃焼されてしまう。
だから相当量の水の混入じゃないと車の不調にはならないのだな。
水抜き剤はこういう理由で必要とされるケミカルなのだ。どうしても水はタンクに溜まるから。一番の問題はエンジンじゃなくて、燃料ポンプが錆びちゃう事なんよね。ある日急にエンストしてエンジンが掛からない、高速や山道を全開で走ってたらエンストとか。タンクが錆びてその錆で燃ポンが壊れるって事もある。
水抜き剤の仕組みは単純で、アルコールだ。アルコールは親油性と親水性両方があるから水をアルコールに溶かしてエンジンで燃やしちゃえっていうケミカルだ。
だからイソプロピルアルコールでも代用できる。酒用アルコールはだめだぞ糖分入ってるから。
こんな単純ケミカルなのでホムセンでは100円くらいで売っているので、それを入れよう。ぼったくり価格のスタンドのは原価40円くらいで同じ代物であるし、違いが出せようはずもない。
元ブでもエンジン故障を冠水路走行でのウオーターハンマーと混同してる人がいるが、それは空気を吸う所から水を吸い込んだ場合で、空気は圧縮できるが水は圧縮できないのでエンジンが物理的に破壊されてしまうってもの。
燃料路からの混入では燃料:空気比率は12:1程度になる上に気化した水は圧縮出来、すぐに排気されるので物理破損されない。
因みにハイオク車にレギュラー入れると調子が悪くなるのは、ノッキングが発生するから。
今の乗用車はノッキングを感知すると点火時期を遅らせるので、ピストンが下降工程にある時に燃焼が起きて馬力に変換されないし熱効率も悪くなり燃費も悪化する。ノックセンサーがない古い車ではエンジンがぐちゃぐちゃに壊れる原因であった。（経験あり）
水混入による修理と言っても燃料を入れ換えてリターンパイプを外してエンジンを空回しするだけのはず。
インジェクション方式では一定した燃料の圧力が必要なので、エンジン側に調圧バルブがありそこで余分な燃料をリターンパイプ経由でタンクに戻している。
だからのタンク側のリターンパイプを外してエンジン回せば管路の燃料も全て抜けてしまう。キャブレター式ではキャブの分解が必要だが、インジェクション車は燃圧が高いので力で押しきりがしやすいのだ。
それからもし自分がこういうトラブルにあったとしてもスタンドの会社がレッカー代から休業補償も払ってくれるから大丈夫だ。
その為に領収書は捨てずにとっておいた方が良い。
因みにタンクへの雨水混入も消防法抵触事件なので、タンクへの混入を認めなくても監督官庁である消防署巻き込むとスタンドは認めざるを得ない。書類や実際の燃料油の採取やパッキン状況等を有無を言わせず調べられるので。
自動で安価をつけて返信するプログラムでもこんなに長く複雑になる(一部抜粋)
/**************************************
以下のCSV_DIR, FILE_PATHS, SETTINGSを書き換えてね。 <h3>o- *************************************/</h3>
//CSVファイルが置かれてるディレクトリのパス。投稿前にエラー出たら大体ここの設定ミス。 例："C:\\Users\\sakuraimasahiro\\Documents\\iMacros\\Macros\\rentou\\";
'C:\\Users\\USER\\Desktop\\iMacros\\Macros\\rentou\\';
//ファイルのパス。CSVは絶対パスで、拡張子も必要。iimは相対パスでよく、拡張子不要。
const FILE_PATHS = {
textCsv: CSV_DIR + 'textNoAnker.csv',
//レス用投稿文が書かれたCSV。通常とレス用で分けないなら同じファイルを使えばいい。
replyTextCsv: CSV_DIR + 'textReply.csv',
};
baseWaitTime: 5,
//baseWaitTime+0～waitTimeRange（ランダム）だけ待つ
waitTimeRange: 5,
//連投しすぎだと忠告された場合に処理を一時停止させる時間(秒)
waitTimeForAvoidingPunishment: 60 * 30,
//メール
mail: 'sage',
//名前設定
name: '',
//以下、偽装ワッチョイ設定。浪人でワッチョイを非表示にしてるときだけtrueにしてね。
//妙なニックネーム（ﾜｯﾁｮｲ、ｱｳｱｳｳｰなど）をランダムで決めて付加するかどうか。true=付加する。false=付加しない。
//妙なニックネームの後に付く8桁の文字列をランダムで決めて付加するかどうか。
},
//アンカー無し投稿をするならtrue。しないならfalse。noAnkerPostかreplyPostのどちらかはtrueにすること（両方trueでもOK）。
//アンカー付き投稿（返信）をするならtrue。しないならfalse。もしnoAnkerPostとreplyPostの両方がtrueの場合、投稿は返信が優先され、返信対象が見つからなくなったらアンカー無し投稿をする。
//最初に取得するアンカー無し投稿文CSVファイルの行番号。もし返信用と同じCSVファイルを使うなら-1と入力。
noAnkerPostTextCsvStartRow: 1,
//最初に取得する返信用投稿文CSVファイルの行番号。もしアンカー無しと同じCSVファイルを使うなら-1と入力。
//テキストCSV/返信用テキストCSVの取得行が最終行に達したら最初の行まで戻るかどうか。true=戻る。false=マクロ終了。
//返信する場合、これより小さなレス番には返信しない。返信を投稿すると、この数値は前回の返信先のレス番に更新される。
minAnker: 895,
//返信する場合、名前に以下の文字列を含む投稿にアンカーをつけて返信する(ﾜｯﾁｮｲやIPなど名前フィールドにあるものならなんでも可)。配列で複数指定可能。指定無しなら空配列（[]）。filterNamesとfilterNamesNotIncluded共に無指定ならレス番1から順に返信していく（minAnkerが設定されてればそこから順に）。以下のfilter系は全て併用可能。
//↑とは逆に、名前に以下の文字列を含まない投稿にアンカーをつけて返信する。↑と併用も可能。
//返信する場合、本文に以下の文字列を含む投稿にアンカーをつけて返信する。
filterText: ['自演かな', '自演わらわら', 'スクリプト使うの', '安価ガバ', '>>660', '自演で擁護', '最後' ,'あいうえお', 'かきくけこ', 'さしすせそ', 'なにぬねの', 'はひふへほ', 'まみむめも', 'やいゆえよ', 'やゆよ', 'らりるれろ', 'わいうえを', 'わをん', 'わいうえをん'],
},
//自分のIPアドレスの確認。VPNとかでIPを変更してマクロを動かしてるとき、突然VPNが作動しなくなってIPが元に戻ったときにマクロを止めるためのもの。
//以下の文字列が自分の現在のIPアドレスに含まれている場合、マクロを一時停止する。基本的に自分の本当のIPアドレスを入力。
},
//浪人設定。最後に動作を確認したのは5年くらい前で、今も同じように動作するかは、浪人を持ってないから確認できずわからない。
//浪人にログインしてるかどうかをチェックするかどうか。trueならする。falseならしない。trueにしていてもし浪人にログインしていないことを確認したらログインしにいく。
password: '1234',
},
};
/**************************************
設定箇所終わり。
https://info.5ch.net/index.php/%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%82%81%E3%81%AA%E3%81%84%E6%99%82%E3%81%AE%E6%97%A9%E8%A6%8B%E8%A1%A8 <h3>o- *************************************/</h3>
/**************************************
・NULL演算子(??)は使えない。論理積(&&)は使える。
・オブジェクトの分割代入はできない。
・importはできない。 <h3>o- *************************************/</h3>
/**************************************
関数 <h3>o- *************************************/</h3>
/**
* ここから始まる。
*/
checkSettings();
var _TextCsvCursors = new TextCsvCursors(
SETTINGS.postSettings.noAnkerPostTextCsvStartRow > 0
? SETTINGS.postSettings.noAnkerPostTextCsvStartRow - 1
: SETTINGS.postSettings.noAnkerPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
SETTINGS.postSettings.replyPostTextCsvStartRow > 0
? SETTINGS.postSettings.replyPostTextCsvStartRow - 1
: SETTINGS.postSettings.replyPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
);
var _LoopStatuses = new LoopStatuses(0, SETTINGS.postSettings.minAnker);
const _MyPosterName = new MyPosterName({
name: SETTINGS.nameSettings.name,
});
const _ThreadUrl = openPromptThreadUrl();
//ループ
while (true) {
SETTINGS.ipSettings.checkIp && checkCurrentIpNotTheIp();
//スレを開く
openUrl(_ThreadUrl.fullUrlHttps());
//浪人にログインする設定なら、浪人にログインしているかどうかを確認し、していなければログインしにいく。
if (SETTINGS.roninSettings.checkLogin) {
}
}
if (SETTINGS.postSettings.replyPost) {
const targetAnkerNumber = createPostDOMList()
.filterPostnumberHigher(_LoopStatuses.currentMinAnker())
.filterByPostername(SETTINGS.postSettings.filterNames)
.filterByPosternameNotIncluded(
SETTINGS.postSettings.filterNamesNotIncluded,
)
.filterByText(SETTINGS.postSettings.filterText)
if (targetAnkerNumber !== null) {
const r = _TextCsvCursors.takeNextRowTextAsReply(targetAnkerNumber);
messageDisplay(`返信対象有り。アンカー先: ${targetAnkerNumber}`);
return {
...r,
updatedLoopStatuses:
_LoopStatuses.updateMinAnker(targetAnkerNumber),
};
}
}
if (SETTINGS.postSettings.noAnkerPost) {
//返信対象無し、或いは返信しない設定の場合。アンカー無し投稿文を作る。
const r = _TextCsvCursors.takeNextRowTextAsNoAnker();
messageDisplay('返信対象無し。アンカー無し投稿。');
return {
...r,
updatedLoopStatuses: _LoopStatuses,
};
}
return null;
})();
if (p) {
//投稿。
nickname: SETTINGS.nameSettings.nickname,
korokoro: SETTINGS.nameSettings.korokoro,
area: SETTINGS.nameSettings.area,
}),
SETTINGS.mail,
p.text,
);
//_TextCsvCursorsと_LoopStatusesを更新。
_TextCsvCursors = p.updatedTextCsvCursors;
_LoopStatuses = p.updatedLoopStatuses.incrementPostCount();
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
} else {
`返信対象が現われるのを待機中...。`,
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
}
wait(SETTINGS.baseWaitTime + randomRange(0, SETTINGS.waitTimeRange));
}
}
/**
* 投稿処理と投稿結果を見てリトライしたりマクロ終了したり。
* @param {string} serverName サーバー名
* @param {MyPosterName} _MyPosterName
* @param {string} postMail メール
*/
serverName,
postMail,
_MyText,
retryTimes = 0,
) {
const r =
retryTimes === 0
? new ValuesOfPost(serverName, _MyPosterName, postMail, _MyText).post(
postTo5chTread,
)
serverName,
postMail,
_MyText,
).postSubstring(retryTimes, postTo5chTread, postConfirm);
if (r) {
back();
return;
}
wait(7);
const error = createPostErrorMessage().analyze();
messageDisplay(error.message);
if (error.order === 'KILL') {
kill();
} else if (error.order === 'SKIP') {
return;
} else if (error.order === 'TRUNCATE') {
back();
serverName,
postMail,
_MyText,
retryTimes + 1,
);
} else if (error.order === 'WAIT') {
wait(SETTINGS.waitTimeForAvoidingPunishment);
serverName,
postMail,
_MyText,
retryTimes,
);
} else if (error.order === 'LOGIN') {
serverName,
postMail,
_MyText,
retryTimes,
);
}
return;
}
/**
* 現在のIPアドレスに、SETTINGS.ipSettings.avoidTheIpの値が含まれていないことを確認する。含まれていたらマクロを一時停止。
* @returns
*/
function checkCurrentIpNotTheIp() {
openUrl('https://www.cman.jp/network/support/go_access.cgi');
const _IpAdress = createIpAdressFromCMan();
if (_IpAdress.includes(SETTINGS.ipSettings.avoidTheIp)) {
pause('現在のIPに指定した値が含まれていることを確認。');
}
return;
}
/**
* @returns
*/
if (
SETTINGS.postSettings.noAnkerPost === false &&
SETTINGS.postSettings.replyPost === false
) {
return kill('設定エラー。noAnkerPostとreplyPost両方ともfalseになってる。');
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow < 0 &&
SETTINGS.postSettings.replyPostTextCsvStartRow < 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRowとreplyPostTextCsvStartRow両方とも-1になってる。',
);
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow === 0 ||
SETTINGS.postSettings.replyPostTextCsvStartRow === 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRow/replyPostTextCsvStartRowの初期値は-1或いは1以上で。',
);
}
}
/**
* 入力フォームを表示して入力されたスレのURLを受け取る。
*/
function openPromptThreadUrl() {
const url = prompt('スレURLを入力');
}
/**
* 開いてるスレのレス全て読み取ってPostListインスタンスを作って返す。
* 重すぎるので使うのやめ。どうやらインスタンスの大量生成が原因な模様。
*/
const posts = window.document.getElementsByClassName('post');
return new PostList(Array.from(posts).map((e) => new Post(e)));
}
/**
* 開いてるスレのレス全て取得してPostDOMListに格納して返す。
* @returns
*/
function createPostDOMList() {
const posts = window.document.getElementsByClassName('post');
for (let index = 0; index < posts.length; index++) {
//HTMLCollectionからElementを1つずつ抽出して配列に。
arrPostDOMList.push(posts.item(index));
}
return new PostDOMList(arrPostDOMList);
}
/**
* 開いてる投稿結果画面に表示されてるエラーを読み取ってPostErrorMessageインスタンスを作って返す。
*/
function createPostErrorMessage() {
window.document
