にしし ふぁくとりー:西村文宏 個人サイト

Presented by Nishishi via Movable Type. Last Updated: 2020/07/01. 12:04:12.

Sakura Scope (2020年06月)

ちょっと倒錯気味な、ただの日記です。(^^;)
これはやばいと思われた場合は、お早めに閲覧を中止されることをお勧め致します。

通話可能なナースコールが激しく便利だった件

あらゆる病院でこのナースコールシステムを採用すれば良いのに! と思った話

今年の3月に腹痛から2週間入院しましたが、そこの病院に備え付けられていたナースコールの仕組みが、(私は)今まで見たことのないとても便利な仕組みになっていて驚きました。

設置されていたナースコールは、単なる「呼び出しボタン」ではなく、看護師の持つ携帯電話っぽい端末と直接会話ができる通話機能付きでした。これなら間違えて押してしまったときに看護師に無駄な移動を強いることもなく、患者側の緊急度がすぐに伝えられるので優先順位も付けやすく、特に少人数の看護師さんで回している最近の病院では無駄を省ける便利な仕組みで感心しました。(もしかしたら既に広く普及しているのかも知れませんけども、ここ2~3年の間に私が病棟に入ったことのある3つの病院では、今回に私が入院したところだけでしか採用されていませんでした。)

▼目次:

古い「単なる呼び出しボタン」でしかないナースコールの問題点

かつて父が入院した2つの病院では、どちらも(昔からある)「押したらナースステーションに伝わるだけ」のナースコールでした。
患者がベッド脇のナースコールボタンを押すと、しばらくしてから看護師さんが病室まで来てくれる(というか、来るしかない)仕組みです。

なので、間違えて押しちゃったとしても、病室まで来てくれた看護師さんに「間違えて押した」と伝えるほかなく、看護師さんの時間と手間が無駄になります。
どれくらいの緊急性で呼びたいのかの緊急度も伝えられません。
看護師さんが忙しい時間帯には押してもなかなか来てくれない問題もあり、どうにか改善する方法はないものなのかなと思うこともありました。

特に病棟の1フロアをほんの数人の看護師さんらで担当している場合には、ナースコールには即応できないケースが多そうです。
その結果、同じ患者が何度もボタンを押すことになり、看護師さんは余計に即応できなくなっていく悪循環に陥っていそうに感じました。

通話機能のあるナースコールの利点

私が3月に入院した病院では、ナースコールがそのまま電話になっていました。看護師さんは1人1台の専用携帯電話(※)をポケットに入れて持ち歩いています。患者がベッド脇のナースコールのボタンを押すと、看護師さんが持つ携帯電話に着信するので(看護師さんが電話に出れば)そのまま病室の患者と通話ができます。(看護師さんは電話で喋り、患者は壁のマイクに向かって喋ります。)

※携帯電話と言っても、形は昔にあった「折りたためないガラケー」みたいな感じの端末でした。外線に繋がるような電話ではなく、病棟内だけで通話できる子機のような電話端末なのだと思いますが。落とさないようにするためか、どの看護師さんも紐で下げていました。

患者がナースコールのボタンを押すと、以下のような感じのやりとりになります。

  • ➡患者 :ナースコールを押す。(→担当看護師の携帯電話が鳴る。)
  • ➡看護師:電話で「どうしました?」と尋ねる。(→患者側では、ベッド脇のスピーカーから看護師の声が聞こえる。)
  • ➡患者 :壁のマイクに向かって用件や症状を話す。
  • ➡看護師:その場で回答するなり、「すぐ行きます」と返事するなりする。

これ、忙しい看護師さんに対して、ものすごく時短になる仕組みですよね。
ナースコールは、ベッド脇の紐の位置をちょっと調整しようと触っただけでも誤ってボタンを押してしまうことがあります。そんな間違えて押しちゃった場合でも、通話で「どうしました?」と尋ねられたときに「間違えて押しちゃいました」と言えば済むので、看護師さんに無駄な移動をさせてしまわずに済みます。

他の患者を診ているときにナースコールが鳴る場合もよくあるでしょうが、その場の通話で「どうしました?」と質問できるので、緊急性が低ければ「じゃあ今の患者さんの後に行きますね」という感じの返事ができます。すると、その患者はいつ頃に看護師さんが来てくれそうかの予想ができるので、何度もナースコールを押す必要性がありません。もちろん緊急性があれば、すぐに対応に行けるでしょう。

すごく便利です。
全国のあらゆる病院でこのナースコールを採用すれば良いのに、と思いました。(いや、もしかしたら既に採用が進んでいるのかも知れませんけども。どれくらい普及しているのかな……?)

▼看護師さんへ緊急性をすぐに伝えられるメリットも大きそう

私は入院中に24時間ずっと点滴をしていた期間が1週間以上あったのですが、そのときに三方活栓のキャップが何かの拍子に外れて(たぶん元々栓の向きが180度間違っていて)、血管から血液が逆流して床にポタポタ流れ出てしまう状況に遭遇しました。そのとき急いでナースコールを押したのですけども、通話機能があったためにすぐさま状況を知らせることができて、ほんの数十秒くらいで対処に来て頂けました。これがもし「単なる呼び出しボタン」でしかないナースコールだったら、来て頂けるまでにもっと時間が掛かっていたかも知れません。

(ただ、ナースコールの仕組み云々以前に、もし寝ているときにそんな事態になっていたら結構怖い状況になっていたのではないかな……?^^;)

▼看護師さんの方からも患者へ通話ができる(笑)

ナースコールといえば、「患者→看護師」の一方向に伝えるシステムだという先入観があったので、まさか看護師さんの側から患者のベッド脇のナースコールに発信できるとは予想していなくて、入院中に1度だけ驚きました。

私が入院していた病院では、シャワーが使えるのですが、利用者がバッティングしないように30分単位での時刻予約が必要でした。
朝に点滴を交換に来て下さった看護師さんに予約したい旨を伝えたところ、「じゃあ後で空き時刻を調べますね」と言われたので、お知らせに来てくれるのかな……と思っていたら、いきなり壁のナースコール通話口から看護師さんの私を呼ぶ声が聞こえて驚きました。(笑)
向こうからも連絡できるのか! と。

このように「ただ情報を伝えれば良いだけ」の場合には、わざわざ移動しなくても通話で済むのは便利ですね。

入院先を選べる場合には、ナースコールの機能もチェックできたら良さげ(笑)

私が3月に入院したときは、そもそも緊急な入院だったので選択の余地はありませんでしたが(もちろん緊急に診てもらう先の病院は選べましたけども、まさか入院が必要になる症状だとは予想していませんでしたので)、事前に入院治療が必要だと分かっている場合で(短期間では済まない場合で)病院が選べるなら、ナースコールがどんな仕組みになっているのかもチェックできたら理想的な気がしました。

病棟が綺麗かどうか・広いかどうか、病室の設備がどんな感じか、ネット接続はできるかどうか、……というような入院時の病院選択チェック項目がいくつかあると思いますけども、そこに「直接通話ができるナースコールが設置されているかどうか」も加えておきたいです。
入院時は、どうしても看護師さんを呼ばなければならないケースがあります。そのときに、単なる「呼び出しボタン」でしかないナースコールしかない場合と、直接通話できるナースコールのある場合とでは、看護師さんとの連絡の取りやすさが全然違います。いざというときに看護師さんが円滑に対応できるようになっているかどうか、という点は入院中にはとても重要ですよね。なので、この点もチェックできたら理想的だと思います。

ただ、そこをチェックするのはなかなか難しい気もしますけどもね。過去にそこに入院したことのある人に質問するくらいしかなさそうですし。
ネット上で情報を探すとしても、そこまで報告している人が居るかどうか分かりませんし、何より「どこに入院したか」は割とクリティカルな個人情報なので、明かさない人々の方が多そうですし。(私もそうです。)

まあ、チェックできるならした方が良いのではないか、という話でした。^^;

HTML内にdata-lightbox属性があれば動的にLightboxを読み込むようJavaScriptを書いてみた

常時Lightbox用のJavaScriptとCSSを読み込ませるのは通信量の無駄な気がしたので、必要な場合に限って動的に読み込ませるよう書いてみました

ブログ記事の中に時々大きな画像を掲載して見せたいことがあるので、初期状態ではサムネイル画像だけを見せておき、拡大版画像はLightboxを使って表示できるようにしました。しかし、毎回の記事で大きな画像を掲載しているわけではありませんから、問答無用で常時Lightboxを読み込んでしまうように記述すると、無駄に通信量が増えてしまって望ましくないようにも思いました。

そこで、Lightboxを必要とする「data-lightbox」属性がHTML内のどこかに1つ以上存在している場合のみ、Lightbox用のCSSとJavaScriptをCDNから動的に読み込むJavaScriptをjQueryで書いてみました。

必要な場合に限ってLightboxのJavaScriptとCSSを動的に読み込むソース

Lightboxを動的に読み込ませる方法として書いたJavaScriptソースは下記の通りです。
(jQueryは既に読み込まれていることが前提になっています。)

$(function() {
   // ▼body要素内に「data-lightbox」の文字列がある場合に限って
   if( $('body').html().indexOf('data-lightbox') >= 0 ) {
      // ▼LightboxのCSSを動的に読み込む
      var lbcss = document.createElement('link');
      lbcss.rel = 'stylesheet';
      lbcss.href = 'https://cdnjs.cloudflare.com/ajax/libs/lightbox2/2.11.0/css/lightbox.min.css';
      document.head.appendChild(lbcss);
      // ▼LightboxのJavaScriptを動的に読み込む
      var lbjs = document.createElement("script");
      lbjs.src = "https://cdnjs.cloudflare.com/ajax/libs/lightbox2/2.11.0/js/lightbox.min.js";
      document.body.appendChild(lbjs);
   }
});

書いていることは単純で、body要素の中身を全部取得して、indexOfメソッドを使って data-lightbox の文字列が存在するかどうかをif文で判定しています。data-lightboxの記述が1つ以上あれば、if文の中身が実行されます。

if文の内側では、Lightbox用のCSSファイルとJavaScriptファイルをCDNから動的に読み込んでいます。

動的に読み込ませる処理は簡単で、document.createElement('要素名')でlink要素やscript要素を生成し、必要な属性値を指定して、document.head.appendChildでhead要素の末尾に加えてやれば良いだけです。そうするだけで、ブラウザはそのソースを読み込んでくれます。

備考:jQueryが読み込まれていない状況の場合

私のサイトではjQueryは(ほぼ)常用しているので、jQueryは(動的には読まず)常に読み込ませています。
もしjQueryもLightboxと一緒に動的に読ませたいなら、jQueryの記述は当然使えませんから、例えば$(function() { ~ });の代わりにはdocument.addEventListener("DOMContentLoaded", function() { ~ });と書いたり、$('body')の代わりにはdocument.getElementsByTagName('body')[0]などの記述方法を使ったりすれば良いのではないかと思います。たぶん。

モバイル環境ではLightboxは読ませないようにしたい

先程のソースは話を簡単にするためにbody要素を対象にしましたが、広大な範囲を対象にして文字列を探すのは処理の無駄が多すぎるような気がしましたので、私のサイトでは「id="container"」が指定された範囲だけを対象にするように書きました。ブログ記事の本文は、このid名の範囲内にありますので。まあ、現代の閲覧環境ならbody要素全体を対象にしたところで、体感速度に変わりはないとは思うのですが。省ける無駄は省いておくに越したことはないかなとも思いまして。

あと、画面幅の狭いモバイル環境では、Lightboxを使っても大して拡大できない(または全く拡大されない)ことがよくあるので、Lightbox自体を読み込ませることが無駄だとも思います。むしろ、Lightboxを使わずに素直に画像への通常リンクの形にした方が最大限拡大できて良さそうな気もします。

というわけで、「閲覧者の画面幅が800px以上の場合」かつ「id="container"が指定された要素が存在する場合」だけに限ってLightboxが必要かどうかの判定をするよう、以下のように書いてみました。

$(function() {
   // ▼画面幅が800px以上で、id="container"が存在する状況で
   if(( window.screen.width >= 800 ) && ( document.getElementById('container') )) {
      // ▼body要素内に「data-lightbox」の文字列がある場合に限って
      if( $('#container').html().indexOf('data-lightbox') >= 0 ) {
         // ▼LightboxのCSSを動的に読み込む
         var lbcss = document.createElement('link');
         lbcss.rel = 'stylesheet';
         lbcss.href = 'https://cdnjs.cloudflare.com/ajax/libs/lightbox2/2.11.0/css/lightbox.min.css';
         document.head.appendChild(lbcss);
         // ▼LightboxのJavaScriptを動的に読み込む
         var lbjs = document.createElement("script");
         lbjs.src = "https://cdnjs.cloudflare.com/ajax/libs/lightbox2/2.11.0/js/lightbox.min.js";
         document.body.appendChild(lbjs);
      }
   }
});

上記のJavaScriptによって、以下の3条件を満たしている場合にだけ、LightboxのJavaScriptとCSSが動的に読み込まれます。

  1. 閲覧環境の画面サイズが800px以上
  2. id="container" が付加された要素が存在する
  3. その中に「data-lightbox」の記述がある

なお、ここでwindow.screen.widthを使ったのは、ブラウザのウインドウサイズではなく、画面サイズで判断したかったためです。PC環境で、たまたまブラウザのウインドウサイズが800px未満だった場合には、ユーザが自分の意思でウインドウサイズを広げればLightboxが使える方が楽でしょうから。

もし、ブラウザのウインドウ幅など「描画領域の横幅」を使いたい場合は、document.body.clientWidthを使えば良いと思います。

とはいえ、これで本当に無駄が省けるのかどうかはイマイチ自信がないのですけども(笑)

このJavaScriptを実行する速度(=HTMLソース内の一定領域内に指定の文字列が存在するかどうかを確認して、あったら外部ファイルを読み込む処理をする速度)のことを考えたら、最初から問答無用でLightboxを読み込ませてもあまり変わらないのかも知れません。LightboxのCSSはわずか2.5KBで、JavaScriptは9.05KBですから両方で11.5KB程度しかありません。初回は読み込みに時間がかかるとしても2度目からはキャッシュから読まれるわけですし、何よりCDNから読み込んでいるので初回アクセスの時点でも既にユーザのブラウザにはキャッシュが存在する可能性もあります。(そもそもそういう状況を期待しているからこそCDNから読み込ませているわけで。)

なので、そこまで気にしても実は意味がないのかも知れません。
どうなのかな……。(^_^;;;

ただ、自前のスクリプトで動的に読み込むかどうかを判断するメリットの1つとして、「画面サイズが狭い場合には読まない」ようにできる点はあります。
たとえdata-lightbox属性が付加されていたとしても、モバイル端末ではLightboxは読み込まれませんから、モバイル閲覧環境でだけは無駄な通信を確実に排除できている気はします。^^;

切手を買わなくてもネット(Amazon Pay)で郵便料金を支払う方法があった

切手を買いに行けないので、郵便料金をネットで払う方法がないか探したら、Amazon Payが使えた

緊急事態宣言が出ていたときに郵便を出す必要があったのですけども、切手のストックがありませんでした。
コンビニや郵便局の窓口には極力行きたくありません。
しかし郵便は出す必要があります。(郵便ポストは近くにあります。)
というわけで、ネットで郵送料を支払って郵便物をポストに投函する方法がないものか、と探してみました。

実は最初から1つ心当たりはありました。
郵便局はわりと以前から「クリックポスト」というサービスを用意しています。
これは、ネット上で郵便料金(固定額)を決済して、郵便伝票をプリンタで印刷して郵便物に貼れば、切手不要でそのままポストに投函できるサービスです。

クリックポスト

厚み3cmまで、かつ重量1kgまでという制限はありますが、荷物追跡もあり、料金は198円固定ですからとても安いです。

厚みと重さ以外に、全体の縦横サイズとして最小9×14cm~最大25×34cmという範囲の制限もありますが、この範囲内ならたいていの封筒で問題はないでしょう。(貼付する伝票がA6サイズくらいあるので、この伝票よりも小さな(例えば細長い茶封筒みたいな)封筒は使えませんが。)

▼ネットで郵便料金が払えるとはいえ決済手段が限定されていたのだが、いつの間にか2種類に増えていた

ただ、このクリックポストは決済手段が限られています。
記憶が定かではありませんが、元々はYahoo!オークションのために作られたサービスではなかったかな、と思います。
なので、Yahoo! JapanのIDがないと利用できなくて、Yahoo!側(Yahoo!ウォレット)に登録してある決済情報で決済されるのだと認識していました。

ちょっと面倒ではあるのですが、(ほとんど使っていないとはいえ)Yahoo!のIDは所有していますし、一時的にカード情報を登録して使っても良いかな、と思ったのですけども。
改めてクリックポストのウェブサイトを確認してみましたら……、

なんと、郵便料金がAmazon Payでも支払えるようになっていました!(驚)

まさか、Amazonアカウントを使って郵便局のサービスにログインできる仕組みが用意されているとは全く予想しなかったので驚きました。
いつからこんなことになっていたのでしょうか。(^_^;)
Amazonにアカウントのある人なら使いやすくて便利でしょう。(Yahoo! JapanのIDでもログインできます。)

固定料金(198円)なので、もちろん軽い内容物で済む場合の普通郵便料金と比較すれば高いですが、
わざわざ郵便局の窓口へ行ったり、またはコンビニまで切手を買いに行ったりする手間を考えれば、充分安いと言えます。
もちろん、そこそこ重たい物を送る場合には、普通郵便よりもクリックポストの方が安くなることもあるでしょう。

郵便料金をネットで払ってから、伝票を印刷して郵便物に貼ってポストに投函するだけ

クリックポストの利用方法は簡単で、

  1. ネット上のクリックポストサイトにAmazonアカウントを使ってログインする
  2. 宛先や差出人情報を登録する
  3. Amazon Payで郵送料を決済する(1通198円固定)
  4. 郵便物の表面に貼り付ける伝票がPDFで手に入るのでプリンタで印刷する
  5. 伝票を貼った郵便物をポストへ投函する

以上です。(※AmazonアカウントではなくYahoo! IDを使ってログインする場合は、Yahoo!ウォレットで決済されます。)
ポストへ投函した後は、以下のような感じの流れです。

  1. 郵便局で受け付けられた時点でカード決済される(Amazon Payから決済のメールが届く)
  2. クリックポストサイト上のマイページで、荷物追跡番号を確認すると配送状況が分かる
  3. 翌日か翌々日あたりには相手先に届く

クリックポストサイトでは、下図のように過去の郵便情報が管理でき、貼付するための伝票を再印刷したり、追跡番号を確認したり、配送結果を確認したりできます。過去6ヶ月分の情報だけが保管され、それを超えると自動的に削除されると案内されていました。

クリックポストのマイページ

クリックポストのウェブサイト側からは特にメール連絡等はないので、自力でマイページを確認する必要があります。(ただし、支払いに関する情報はAmazon Pay側からメール連絡は届きます。)

▼郵便料金の課金タイミングは、申込時ではなく、郵便局で荷物が受け付けられた時点

198円の郵便料金が課金されるのは、ネット上で伝票を作成したタイミングではなく、伝票を貼付した荷物が郵便局で受け付けられたタイミングです。
なので、伝票を作成しても使わなければ費用はかかりません。伝票を使わなかった場合の連絡(キャンセル手続き)は不要だとヘルプに書いてありました(※)。
ポストに投函した荷物が収集されて、郵便局内で受け付けられた時点で、ようやくAmazonに登録してあるクレジットカード(=Amazon Pay)で決済されます。

※決済方法として登録してあるクレジットカードがデビッドカードの場合は、申込時に一旦即時決済されているので、お問い合わせフォームからキャンセルを依頼する必要があるようです。なので、デビットカードではないクレジットカードを登録してあるIDを使う方が無難でしょうね。

どちらにしても、伝票作成後に間違いに気付いても簡単に作り直せるのは便利で良いです。(伝票の有効期限は作成から1週間だけです。)
Amazonにアカウントがある人なら、事前準備はほとんど不要で利用できます。
まあ、プリンタは必須ですけどもね。(^_^;)

決済のためには、使えるブラウザに制限がある

クリックポストでは、ウェブサイト上で決済手続きが必要なのですが、そのための仕組みがなぜか特定のブラウザでしか動作しないようでした。
基本的には、「そのOS標準のブラウザ」または「Chrome」のようです。ただし、Windows10の場合は、「IE」か「Chrome」のようですが。^^; Edgeはダメなんですかね。(試してはいません。)
iOSやAndroidでも使用可能だとあるので、スマートフォンなどのモバイル端末からでも使えるようです。(私は試していませんけども。)

Windows上で試してみたところ、Firefoxでは決済画面で正しく処理できませんでした。(ログインは正常にできますし、履歴の確認などもできるのですが。)
Chromeを使えば問題ありませんでした。
ログインしようとする前に、動作要件をチェックしておいた方が良さそうです。

郵便局のサービスにAmazonのIDでログインできるとは

しかしまあ、郵便局のサービスがAmazon決済で利用できるとは、なかなか驚きでした。
一民間企業として考えれば別に何も驚くことではありませんけども、元々が国の機関だったことを考えると。(^_^;)
進歩したものだな、と感心してしまいました。
とはいえ、よくよく考えると郵政民営化から既に12年半くらい経っているのでしたね。^^;

というわけで、切手を買わなくてもネット(AmazonPay)で郵便料金を支払える(切手の調達が面倒ならクリックポストで郵送料をネット決済できる)話でした。

※ちなみにですが、クリックポストを使うには印刷した伝票を貼る必要がありますが、クリックポスト対応のシールシートというのも販売されていました。A4サイズのシール状になっている紙で、簡単に剥がして貼れるようです。たくさん投函する場合には良いかも知れません。(^_^;)

5年ぶりにPC筐体を開けて内部をウェットシートで掃除

PC筐体を開けたのはたぶん5年ぶりくらい

たぶん5年ぶりくらいにメインPCの筐体を開けて中を掃除しました。
ここ最近は、ほんのちょっとCPU使用率が上がるだけでファンの回転音がすごかったので、相当にホコリが溜まっているのだろうなと思ってはいたのですけども、PC筐体の設置方法がちょっと容易には出しにくい感じに(5年前に)してしまったので、今まで放置してしまっていたのでした。

メインPC筐体外観

メインPCは、EPSON DirectのBTO製品Endeavor Pro4700です(購入したのは2009年)。拡張性を重視したタワー型PCなために重たいので、動かしにくいんですよね。(^_^;)
とはいえ、さすがにファンの音がすごくなってしまったので、一念発起して開けることにしました。

雪が積もったのかと思うようなPC筐体内部

PCの筐体を開けたら、雪が積もったのか!? と思ってしまうくらいホコリが積もっていて驚愕しました。
さすがに(たぶん)5年間も筐体を開けなかったら、ホコリが大変なことになりますね。
CPUのヒートシンクとファンの間にも大量にホコリが詰まっていて、明らかに冷却効率が悪そうな感じになっていました。というか、ほとんど冷却できていなかったのでしょうね。

メインPC筐体の中:雪が積もっているかのようなホコリ全体 メインPC筐体の中:雪が積もっているかのようなホコリ拡大

最近のPCはたいていそうでしょうけども、ネジなし(ドライバー不要)でいろいろ簡単に分解できる仕様なので楽でありがたいです。
筐体後部のファンも、数個の留め具を手でスライドさせるだけで簡単に取り外せました。

メインPC筐体の内部:底面にも側面にもホコリがびっしり PC筐体背面の冷却ファンを取り外したところ

PC筐体の内部は、底面にも側面にもホコリがびっしりです。ファンの黒い羽根もホコリで白くなっています。
1つ1つ片っ端からウェットシートで拭き取りました。

どっさり

CPUの冷却ファンはちょっと奥まっていて小さいので苦労しましたが、隙間から細長く折りたたんだウェットシートを詰め込んで、ファンをぐるぐる手動で回すことでホコリを取っていきました。

CPU上の冷却ファンにもホコリがたくさん CPU上の冷却ファンのホコリも掃除

上記写真の下部にある白い塊はすべて、CPUファンに付いていたホコリです。(^_^;)
そりゃこんだけホコリが詰まっていれば、冷却できないのも道理ですね……。

HDDもほこりだらけ

約5年間もPC筐体を開けずに済んでいたのは、ストレージだけは筐体を開けなくても交換できる仕組みのある筐体だからです。
PC筐体前面にある取っ手を引くと、3.5インチHDDが4台接続できるSATAボックスが開きます。
ここでストレージが交換できるので、PC筐体内部を触る必要性がとても低下します。それ自体は便利な仕組みですが、だからこそ掃除するチャンスも低下してホコリが溜まるわけですけどもね。(^_^;)

HDDにもホコリが結構溜まっていた HDD/SSD用フロントローディング部分も綺麗に掃除

引っ張り出すと、ここもそこそこホコリだらけです。
わりとHDDが詰まっているためか、空間に余裕のある筐体内部ほどではない気もしましたが。
ここは5年ぶりというわけではなく、たぶん4年前にストレージを交換したとき(システム用ドライブをHDDからSSDに変更して、バックアップ用HDDを大容量なものに交換したとき)に開けたはずです。
まあそれでも4年も経っていたのですね……。いつの間に。

一旦全部引き抜いてから、綺麗に拭き掃除しました。

ウェットシート25枚くらい

今回の掃除のためにOA用ウェットシート(デスク周り用ウェットシート)を多数調達しておきましたが、結局20~25枚くらい使った気がします。

デスクまわり用ウェットシート
サンワサプライ製OAウェットティッシュ超強力タイプ(デスクまわり用ウェットシート)

この手のウェットシートには大判タイプもありますが、PC筐体の内部を掃除する場合には、小さいタイプの方が取り回しが楽で扱いやすくて良いです。特にファンの羽根の奥に詰まったホコリを取ろうとする際には。

というわけで、PC筐体は内部も外部も拭いて綺麗になりました。
最初にPCの筐体を開けたときに、謎のネジ(下記写真)が1個だけ底面に転がっていたのですが、結局最後まで何のネジなのか分からないままでした。(笑)
どこのネジなんだ……?

綺麗に掃除できたPC筐体内部 PC筐体内部の底面に1個だけ転がっていた謎のネジ

床に置いたPC筐体に向かって背中を丸めて4時間くらい掃除していたので、背中が痛いです。
しかし、CPU使用率の上がる作業をしても、冷却ファンの音が全然うるさくならなくなりました。
やはりホコリが溜まりすぎて冷却ができていなかったのですね……。ものすごく大量のホコリが出てきましたからね……。
もっと早くに掃除すべきだったのですが。(^_^;)

あとシステム用SSDを交換する予定

今回は掃除だけでしたが、この後に、システム用のSSDを交換する予定です。(これは前面から交換できるのでPC筐体を開ける必要がありませんから、掃除と同時に行う必要はないので。)
それはまた後日。
筐体を開けたついでにメインメモリも増やそうかな、とちょっと思ったのですけども、そこは見送りました。
あと、USB 3.1ボードを追加しようかな、とも思ったのですけども(今マザーボードにあるUSBは2.0)、今のところそんな高速接続が必要なUSB機器もないので、ボードを追加するとそれだけホコリが溜まる部分も増えることにもなりますし、やはり見送りました。(^_^;)
というわけで、今回は本当に掃除だけ。

とりあえず、PC(ファンの回転音)が静かになって良かったという話でした。

2020年06月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

他の月

--- 当サイト内を検索 ---