トイレの修理

Scrum Fest 新潟の報告よりこっちを先に書きたい。


先週我が家のトイレが壊れました。(結局、配管づまりだった)

5年に一回ぐらいメンテナンスをしており、そろそろと思っていたところ壊れました。


そして、トイレの修理が大変なことになりました。


こちらの方の記事にもある通り、INAX と TOTO とで思想・哲学が異なっているようですね。

https://suidouya3.com/knowledge/toto-or-lixil/


家を買うときに、トイレどうする? INAX がいいと思うんだよねー。革新的な最先端のトイレだからと言われたので、もちろんそっちにしました。

Linux と発音近いしw


当時、タンクレスのトイレって最新鋭 (INAXしかなかった)だし、ウォシュレットの機能がいろいろついていたり(コックピットっぽい) とか、なんかこう男の子の心がくすぐられたんですよね。


勝手な想像ですが、ざっとこんなイメージです。

ビルバイン → INAX

ダンバイン → TOTO


そんなこんな革新的な最新鋭トイレが壊れるとえらいことがおこります。


修理業者がみつからない!

「すみません。うちでは、このタイプの便器外せないんですよね。。。」

これが、なんと 3 社。。。


最終的に水道局の人、LIXIL の2か所から派遣ということで 便座を外して修理を行いました。


そんなことで、修理する工数も増えて結局修理に12万かかるという始末。

泣けるでぇ


修理、メンテナンスを考えるなら TOTO がいいのかもしれません。

ですが、私は断然 INAX 派ですw


最後に、家を買うときにトイレの機材でワクワクするとか意味わからんっと乾いた笑いが妻から飛んでいたことを覚えています。

う〇こできればいいやろっと言われた記憶があります。


閲覧数:14回0件のコメント

最新記事

すべて表示

前提条件 ゆるふわWeb系QAの戯言です。 きっかけ アジャイルでどうテストすればいいかという悩みの本質は、ほとんどテストではなく、それ以前の問題に起因するのでは?という話を聞いて、自分なり考えてみた。 アジャイル開発でテストが難しい理由はQAプロセス設計の難しいことが大きな原因では? たぶん、WFだとあんまり考えないで順序通りに実施してもそこそこ上手くいく。それは、WFの開発プロセスが確立してい

今週もテストアーキテクチャ設計をやっていた。 テストアーキテクチャ設計とはいかのあたりを参考にしてもらえればいいかと。 https://www.jasst.jp/symposium/jasst12tokyo/pdf/A2-3.pdf https://jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf 特に機能性の部分ではあるが、製品の心臓部である。 というか、

ここ最近、機能性部分のテスト設計を行っているが、このテスト設計は開発設計書を補完するものだと思う。 (あくまで機能部分です) そして、実装した機能に対しての意味付け(理由)を可視化・明示するものほかにならないとは思った。 考え方、見え方次第になるが、バグがあったときに、なぜバグではないのかを説明する義務が発生する。 速度が遅いとかいうのもバグの一つだ。 開発担当者に、なぜこの実装となるのかをしつこ