月別アーカイブ: 2021年4月

東京湾一周(?)ドライブ

緊急事態宣言によって、幻に終わったドライブプラン。

この週末、東池袋とお台場で荷物と人の移動をサポートしつつ、日中の時間調整を子供とのドライブに充てる予定だった。
参考までに掲載。また使うかもしれない。

若干ドライバーにはハードなプラン。
わりと走りっぱなし。しかも子連れ。。。

湾岸経由ではなくアクアライン経由としたので、タイトルに(?)を追加した次第。

行程表

06:00発、貸出
06:30着、自宅
06:45発、(外環 ⇒ 首都高5)
07:30着、東池袋
07:45発、(首都高B,Y,11)
08:45着、お台場
09:00発、(首都高B ⇒ 東京湾アクアライン ⇒ 富津館山道、途中休憩:大井PA)
10:05着、金谷港、東京湾フェリー
–:–発、(航送(<6m)+大人4,100円、小人400円)
–:–着、久里浜港(5便10:25 ⇒ 11:05、6便11:20 ⇒ 12:00)
12:00発、(5便なら久里浜で昼食、6便なら金谷の売店で弁当)
12:30着、くりはま花の国(休憩)
14:30発、(横横道路 ⇒ 首都高B)
16:00着、お台場
16:15発、(首都高B,C2)
17:30着、東池袋
18:00発、(新青梅街道)
19:15着、帰宅
19:30着、返却

今度1人で深夜ドライブするかなぁ。
あ、でも東京湾フェリーって夜行便ないのか。詰み。

さくらのレンタルサーバに Nextcloud 入れてみた感想

インストール方法は割愛

ググれば既に解説されてるサイトがいくつかヒットするので、詳しくはそちらを参照。
自分の場合、この時点での最新バージョン(21.0.1)をインストールしたが、以下の点にハマったこと以外は、問題なくインストール、稼働してます。

ハマったこと

WAF は必ず「無効」にすること。

別に Nextcloud の問題ではなく。

インストールの途中で Nginx のエラーが出たり(レンタルサーバは Apache 稼働)、スタイルシートなどが反映されず、レイアウトが崩れたり、最初、理由がさっぱり判らなかった。無駄にすること数時間。

結局原因は「これ」。

WAF を有効にしてたのをすっかり忘れてた。
無効にしてインストールしたら、すんなり入った。

いきなり結論

重い

所詮「レンタルサーバ」(共用サーバ)なので、レスポンスは期待してなかったけれど、Web 画面はかなり「もっさり」してる。
遅いからと言って、レスポンスか返ってくるのを待たずにあちこちクリックすると 500 エラーになる。
でも、この辺りは WordPress(特にダッシュボード、管理画面)の挙動でも同様なので、期待しないほうが良いかも。

一応 Nextcloud 内部でも、キャッシュなどのレスポンス対策は施されているようだが、大量のユーザを抱えての運用には耐えられないと思う。
レンタルサーバ上の Nextcloud は、あくまで個人利用ぐらい。

ちなみに、レンタルサーバのプランを上げることによって「重さ」が軽減できるとは考えないほうがいい。

「多少」は軽くなる可能性があるものの、体感できるほどのレスポンス改善はおそらく期待できないと思う。

IT技術者じゃないとインストールは難しい、かも?

インストール等はかなり簡単にできるようになってはいる。しかしながら、Apache などの conf 設定や、Nextcloud 自体の config 設定など、細かな設定調整をしようとすると、IT技術者としての知識や経験・勘所が必要な部分がどうしても出てくる。

また、セキュリティ面の部分も考えると、適切なIT技術者がインストールや設定を担当するのが望ましいと思う。

Android, iOS などのアプリ提供を謳ってるけど、アプリで直接できるのは、ストレージ機能ぐらい

CalDAV, CardDAV を用いた同期(連携)については、Android, iOS の Nextcloud アプリを経由してやれるようだが、あくまで同期だけ。
Android, iOS の Nextcloud アプリが、直接カレンダー機能などのグループウェア機能を提供してるわけではない。

WebDAV に関連する機能は、レンタルサーバのプランに依存する

さくらインターネットの場合、レンタルサーバでも「マネージドサーバ」プラン(1台、丸ごとレンタルプラン)じゃないと、そもそも WebDAV 自体が使えない。

そして、それは WebDAV を使用した規格である CalDAV, CardDAV も使えないことを意味する。

カレンダーやメール閲覧機能について

Nextcloud システムは、アプリ(というかプラグイン?)機能として、カレンダーやメール、連絡先などの各種グループウェア機能を導入することができる。

しかしながら、機能面ではお世辞にも洗練されているとは言えない。
Nextcloud をビジネス上の統合環境として捉えるのであれば、選択するも良いとは思うが、その場合は、専用サーバを建てて運用するのが良いかと。

そして専用サーバを建てるぐらいであれば、Google Workspace(旧 G Suite)などのサービスを使ったほうが良い気がする、のだが?

それにレンタルサーバで Nextcloud を運用する場合、付加機能はそのままサーバ負荷になってしまう。
あくまでクラウドストレージとして割り切って、これらのアプリ導入は控えたほうが良いと思う。

外部ストレージ

たとえば、NextCloud のストレージから別サーバの領域を「外部ストレージ」として繋ぎ込むことが可能。
接続できるのは、Amazon S3 などの各種クラウドサービスのオブジェクトストレージや、FTP, SFTP で接続できるサーバ領域など。

ちなみに SMB/CIFS などにも接続できるが、今回はさくらのレンタルサーバに Nextcloud を設置したので、使えない(使わない)のではないかと。

自分の場合、いくつかの Web 領域として無駄に保有してる領域を FTP 接続して使ってみた。

「1つの外部ストレージの接続設定=1つのディレクトリ」として認識する

そのため、外部ストレージ配下の最大容量は、外部ストレージとして接続した先で個々に提供されている領域の上限になる。
接続先の領域サイズが極端に小さい場合は、その領域内に保存するファイルの容量に注意する必要がある。

あと、当たり前だが、ストレージ領域として合算された領域サイズとして、一連で使える訳でもない。

Web領域を繋ぎ込むことも可能だが、セキュリティに注意

ホームページ領域として提供された空間を FTP, SFTP で外部接続して有効利用すること自体は可能。
ただし、これらの領域は元々ホームページの領域として公開されている領域なので、外部接続先として繋ぎ込むディレクトリに対し、適切なアクセス制限を施さないと、ホームページの領域として丸見えになってしまうので、注意すること。

ちなみに ISP によっては、そもそもアクセス制限を施すことができない場合ホームページサービスもあるので、注意。
その場合、外部ストレージとしての使用は望ましくない。

遅い

ただでさえレンタルサーバ上の Nextcloud 本体への接続が遅い状況下で、さらに FTP 接続した先の外部ストレージを参照する以上、レスポンシブとは言い難い。
フォルダの同期という形で利用するのであれば、違和感を感じることはないかもだが、Nextcloud のWeb画面からテキスト等を直接参照・編集する場合には、かなり遅く感じる。
(たまに 500 エラーも発生する。)

レンタカー vs カーシェア

前回記事に関連。

弾丸で関西往復。往復で1000kmぐらい?
レンタカー2日間利用で、レンタカーかカーシェアかを考えてみた。
ちなみに5ナンバーワゴンを検討。

以下、2021年4月現在の48時間料金で試算。

ニッポンレンタカー

ちなみに以前はトヨタレンタカーを使ってたのだが、近所の店が、いつの間にかニッサンレンタカーになってしまった。
悪いけどニッサンレンタカーは使わない。。。

  • W-K、23,100円(会員料金:20,790円)
  • W-A、36,300円(会員料金:32,670円)

ちなみに会員料金は「10%引」。
最初は消費税分だけの割引になるが、利用回数の多い「ゴールド会員」様は 20% 割引になる。
ただし、割引対応車種やシーズン等によってかなり左右されるので、正直そこまでのメリットは感じにくい。

ちなみにこの手の会員サービスの割引、どこのレンタカーもやってるけど、特に「ブランド系レンタカー」の会員割引サービスは、とにかく「例外ルール」が大盛りすぎ。とても判り難い。本当にメリットあんのか?
消費者目線のサービスとは、とても言えない。

タイムズカー(カーシェア)

  • ベーシック、9,900円
  • ミドル 、13,200円
  • プレミアム、20,900円

レンタカーの場合、車種やプラン等によってはカーシェアより安くなることはある。
ところがミニバンなどのワゴンクラスの場合、一般的にカーシェアのほうが安い。

でもワゴン車はカーシェアでも人気あるので、それはそれで「空いてない」という問題が生じることがある。
(自分も予約開始時刻に合わせて取得することが多い。)

燃料費

これとは別に実際には「燃料費」がかかるのだが、タイムズカーの場合、利用料金に含まれる。
今回の場合、長時間利用ということで「距離料金」が生じるので、これに「燃料費」が含まれていると考えると、判りやすい。
というわけで、関西往復1,000km走るとすると、1.6万円。

燃料は車両付属の「専用カード」で給油。
自前で給油してしまっても、距離料金は必ず取られるので、絶対に「専用カード」で給油すること。

レンタカーの場合、完全自費で燃料入れることになるが、1万強ぐらい。
「燃料費」と考えると、若干レンタカーのほうが安くなると思うが、それでもレンタカー本体の料金が高いので、カーシェアとは比べものにならない。

結論

料金面では、カーシェアの圧勝。

ただ、カーシェアよりもレンタカーのほうがメリットある場合もある。
例えばワンウェイや乳児用のシート、ETC貸出などのオプション。いつも洗車済・整備済・満タンの車両が前提だし。

対してカーシェアは、とにかく汚いことや破損が目立つ。
例えばマットに泥や枯れ草がくっついてたり、シート下に菓子をこぼしたものが落ちてたり、飲み物やゴミが放置されてたり。
使用前点検もちゃんとやらないと、バンパーやサイドを擦ってたり。

結局のところ、前の利用者の問題ではある。
ただ、この手のマナー違反は、使用の都度報告しないと、自分の所為にされ、後日疑われることだってある。

このあたりの「割り切り」で、利用の選択肢としても良いかと。

大阪まで船移動を考えてみた

東京から大阪まで「往路は楽に車移動できないか、子連れだし」と、フェリーでの移動を考えてみた。

ところが

現在、東京ー関西を直通する一般向けフェリーはない。
そのためオーシャン東九フェリーで四国・徳島まで向かい、そこから神戸淡路鳴門道を経由して大阪に向かうことになる。

ちなみに今回は用事での移動。レジャーじゃないので、弾丸。
土曜午後出発、日曜日中着、月曜早朝までに戻り。

タイムスケジュールとおおよその料金

  • 土曜
    • 15:00発、レンタカー貸出、W-A、29,040円
    • 16:00発、自宅出発、関越、首都高
    • 17:30着、東京有明埠頭
    • 19:00発、オーシャン東九フェリー
      運賃12,730円/人、2名個室10,000円/室、自動車航送(<5m)34,700円/台、計44,700円。
      (船中泊)
  • 日曜
    • 13:20着、徳島沖洲桟橋
    • 14:00発、徳島道、大鳴門橋、阪神高速
    • 16:30着、大阪目的地着
    • 18:00発、阪神高速、名神、新名神、伊勢湾岸道、新東名、東名(高速代10,250円)
  • 月曜
    • 2:00着、自宅到着

自力で陸送した場合

高速代10,250円、燃料代5,000円。計15,250円。
しかも土曜日中に出発すれば、夜には着いてしまう。
日曜までのホテル泊したとしても、コロナ禍の影響で宿代は1万位で泊まれる。そうなると往路総額で2.5万。

結論、断念

これ、良案だと思ったものの、差額を考えてプラン断念。残念。

Redmineと別サーバの git リポジトリを連携する

ここでは概念的な話のみ。
実際の設定方法等については、各自でググッてください。

あと、これは昔話です。Redmine のバージョンは若干古いです。
最新の Redmine や Git では状況が異なる可能性あり。

「Redmine や Git には余計な手を加えず、Redmine や Git の標準機能だけで連携を実現する方法を導き出したらこうなった」というお話です。

下調べ

もしかしたら最新の Redmine は、こんな面倒なことしなくても、標準機能だけで別サーバの Git リポジトリを直接参照できるかもしれない。
でも、自分が環境構築した当時、調べてみた限りではこんな状態だった。

プラグインでの連携

そのプラグイン自体が最新だか何だかよく判らなかったし、情報が少ないし、よくわかんなかった。
プラグインがメンテされる可能性も未知数。

トリッキーな方法で連携

Redmine のプログラムソース弄ってなんたらとか、ディレクトリをマウントしてどうたらとか。
文字通りトリッキーな方法すぎて、正直メンド臭そうだった。

制約

あと、命題を実現するうえでの制約が以下。

Redmine の制約

標準的なパッケージ(プラグインとか入れない状態)では、 Redmine と同一のサーバ上にある Git リポジトリとしか連携できない。

前述の通り、絶対にできないわけではない。
プラグインの利用とか色々細々と弄れば、異なるサーバ間でも連携できるかも知れない。
あくまで、Git と Redmine 本体が提供している標準的な機能だけで可能な設定では実現できないという話

当方の運用上の制約

Git リポジトリを管理しているサーバは、Redmine とは別のサーバ

Redmine 搭載のサーバと Git リポジトリを管理しているサーバは、それぞれ公開の場所も、管理上のポリシーも異なる。
そのため Redmine サーバを、Git リポジトリとして一緒して運用する(開発者などに公開して操作させる)ことができない。

でも Redmine は、システム開発の基幹。何とかしてこれらを連携させたい。

そこで出た妙案

Git リポジトリには hook(フック)機能がある。

これを使う。具体的には以下。

  • Git ベアリポジトリに push されたら
    1. ssh で Redmine サーバにログイン。
    2. Redmine サーバ側にある Git ノンベアリポジトリから、Git サーバのベアリポジトリの内容を fetch。

これによって、以下のメリット。

  • Git ベアリポジトリの管理は、Redmine と別サーバ。
  • でも Redmine サーバ自らの Git ノンベアリポジトリ(クローン)にも、その内容が常時同期される。
  • Redmine は、同一サーバ上の、同期された Git ノンベアリポジトリの内容と連携することで、あたかも Git リポジトリの本体と連携しているように見える。

余談

そんなの GitHub とか GitLab 使えば、Redmine とか要らなくね?

その通り。
GitHub, GitLab で世界が完結できている幸せな方々については、Redmine なんか必要ない。
ぜひともこの話はなかったことにしてほしい。

でも世の中 Redmine をポータルにして運用している組織は沢山いるような気がしたので、記事にした次第。

私的高速移動考(下り線)

東京起点、東名-新東名の話。
まぁ、たまに使うので。

トラック事情

東京というか東京近郊発の物流路線便は、20~23時を中心に配送センターや営業所を出発する。

これは宅配関連であれば、日中集荷した荷物を拠点で仕分けし、長距離便のトラックに乗せるため、この時間となる。
また、工場などでの製造した品についてのチャーター便の場合も、概ね翌午前中着を目標としていることが多い。そのため、やはり20時以降に出発する事が多いと思う。

京阪神までの物流距離であれば、概ねこのスケジュール感で動いているのではないかと。

なので概ね以下の時間帯が混雑しているような感じ。

東京~御殿場⇒20~23時
御殿場~富士⇒21~00時

ちなみに、0~5時頃まで、富士~豊田までの間もトラックはそれなりに走ってる状況。
さすが幹線。

走り難いか?

指定速度以上の速さを出したい「スピード至上主義者」みたいな方々には、トラックの多い新東名は走りにくいと思う。
トラック同士の追越はとても遅いので、それに焦れる普通車は多いのではないかと。
でも巡航してるトラックもそれなりにいるので、ACC使って「流れ」に乗って走るのは楽。

個人的な走り方

深夜時間帯については、第1、第2走行車線はトラックが多く、走りにくいので、結果的に普通車は第2走行車線、はたまた追越車線をずっと走ることになる場面が多い。
というか、それが「暗黙の了解」のような気がする。

走行提案

以降は個人的な意見妄想・戯言です。
あまり気にしないでください(笑)

できれば、こう言った走りをしてほしい。

トラック

過積載・ローリーなどの80km遵守車は第1走行車線必須として、巡航は基本、第1・第2走行車線。
追い越したいときだけ、第2走行・追越車線を走る。

普通車

巡航は第2走行車線、追越用途で追越車線を走る。
追越車線走行中、自分より速度の速い車両が続行してきたら、すぐ第2走行車線に戻る。

IC・JCT・SA・PAなどで流出するとき

流出の3kmほど手前(混雑時は5km手前)から、第1走行車線に移動することを思考する。出口の予告標識に差し掛かる頃までには、第1走行車線に移動。

この時、前方に特大車など低速車がいても焦れないことが大事。

一番危険なのは

雨の中、トラックが混雑している時間帯

これが1番危ないです。あと、トラック同士の追越中とか。
このような状態では危険なので、頻繁な追越はせず、第2走行車線を巡航するようにしています。

浜松いなさ、岡崎SA間

この区間は2車線。
しかも勾配の抑えられている新東名の中でも、周辺景色と2車線の所為か、それなりのアップダウンがあるように見えてしまう区間。
なので、交通量の多い時間帯の追越には気を付けている。

実家弾丸見舞い(練馬⇔三重)

お馴染みの「机上の空論」。
といいますか、検討した備忘録。折角考えたので記事にしてみた。

はじめに

トヨタレンタリースには「片道GO!」プランという激安プランがある。
この利用を考えたスケジュール設定を検討してみた。

ちなみに、元々はワンウェイ利用された車両の回送を、自社や代行業者の自腹でやっていた。(今もそれで回送してる車両もあるはず。)
それを、おそらく「激安料金で貸し出したほうがコスト下がるんじゃね?」という事で始まったのが、このプランなんだと思う

正直なところ、急ぐなら夜行バスでも新幹線でも使うのが良いのだが、荷物牽いて道中移動とか交通費とか時間の融通とかロマンとかなどを鑑みて、レンタカーにしてみた。

ちなみに同様のサービスは、ニッポンレンタカーも開始してる。
それ以外のレンタカー屋さんもやってるかも。

行程

  • 1日目
    • 12:00、トヨタモビリティサービス(往路指定店舗)、往路貸出
    • 14:00、自宅着
    • 22:00、自宅出発、東京IC-東名-新東名-伊勢湾岸道-新名神
  • 2日目
    • 4:00、鈴鹿PA/SIC着、仮眠4h
    • 8:00、出発
    • 9:00、実家着、昼食・買物
    • 13:00、病院着、見舞・買物
    • 16:00、実家戻り、伊勢湾岸道-名古屋高速
    • 19:00、トヨタレンタリース名古屋(復路貸出指定店)、往路返却-復路貸出、名古屋高速-名神-中央
    • 23:00、小黒川PA着、仮眠6h
  • 3日目
    • 5:00、出発、中央-調布IC
    • 10:00、自宅着
    • 12:00、トヨタモビリティサービス(自宅最寄店)、復路返却

【往路】
鈴鹿PA/SICだと行き過ぎるので、本当な長島PAで休憩したいところだが、四日市市内通過の際、確実に渋滞へ巻き込まれる。

【復路】
中央道経由にしたのは、到着時の都心渋滞を避けつつ、ゆっくり帰るため。寄り道設定も可能。
急いで帰る場合は、みえ川越IC-伊勢湾岸道-新東名-東名が一直線ルートだし速い。

メリット

  • 通常レンタカーを借りた場合、コンパクトカークラスで1.2万円なのに対し、「片道GO!」を利用した場合は「往路+現地移動4.4千円(48h)、復路2.2千円(24h)、合計6.6千円」と、およそ半額で済む。
  • 返却店は管轄地域の営業所であれば、どこでも返却オッケー。

本当は往路も24h貸にしたところだが、そうすると現地移動で利用する時間が不足してしまう(別途、移動の足と調達必要が生じる)ため、ここだけ48h貸にしている。

デメリット

  • 貸出店が選べない。指定店舗まで出向く必要あり。
  • 燃料代は自腹。
    そのため特にハイエースなど大型車を利用した場合、コンパクトカーよりも燃料費がかかるので、レンタカー代が半値で済んでも、燃料代でメリットが削がれる可能あり。
  • レンタカーマイルは利用不可だし、付与もされない。
  • 電話予約のみ。
    そのためトヨタレンタカーメンバーとして(ゴールドメンバーになるため)のカウントも対象外。(だったはず?)
  • 延長・装備オプションは一切できない。
    特に指定場所以外の返却や遅延した場合、正規料金での精算になる。
  • レンタカーのゴールド会員だと、最初から20%引。
    「特割GO!」の「直前割」の場合、最大で40%引の場合もある。
    こうなると、50%引との差額や片道返却などの手間を考えると、正直微妙な気もする。
  • 足かけ3日間なので、確実に疲れる。
    (新幹線利用で日帰りできることを比較して)

駿河屋通信買取のポイント

追補記事として「駿河屋通信買取のポイント(2024年現在の追補・訂正)」を追加しました。

一部誤解している点あるかも。。。

駿河屋の通信買取の場合、「あんしん買取」の場合は3千円以上の買取、「かんたん買取」の場合は商品点数が30点以上であれば送料無料。
ただし、いくつか守るべきルールがある。

「ゆうパック」の「着払い」で送る

ヤマトや佐川急便など「ゆうパック」以外で送付した場合、送料無料にはならない。

また、元払い(発送人が送料を支払った状態)で発送しても、送料の買取時精算はしてくれない。

100サイズ以上で送る

「あんしん買取」かつ3千円買取がほぼ確実な場合であれば、100サイズ以下で送付しても問題はない。

必ず「1箱あたり3千円を余裕で超える額」を目安に送ること。

よく誤解されがちだが、「あんしん買取」の場合は「3千円以上の見積であれば、すべて送料無料になる」わけでではない。
品物の状態によっては買取額が「減額」されることだって十分にあり得る。
そして最終的に買取額が3千円に満たない場合になってしまった場合、送料が買取額から「天引き」されるおそれがある。

さらに「送付の際に適当な箱がなかったから」などの理由で複数口で送ってしまった場合にも、買取額が「1箱あたり1,500円」に満たない場合は、逆に送料が請求されてしまうので、注意。

大量の物品を送るときは注意

種類によっては、1回あたりの買取数を制限している場合がある。
よく確認すること。

個人的な心構え

気長にやる

「査定が遅い」「連絡がない」とかいうツイートなどをたまに見かけるが、こう言った短気または文句の多い方々には、心身によろしくないので、通信買取はお勧めしない。

買取依頼する品物の種類の量、繁忙期(コミケなどの大規模同人誌即売会の開催日前後)などにおける買取依頼の場合、見積提示が遅れたり、買取依頼(送付)してから、査定・買取額確定までに時間がかかることは、よくある話。
自分の場合、見積り依頼⇒買取完了まで最大1ヶ月近くかかった事もある。

個人的には通信買取は「忘れてても別にいいや」ぐらいの気長な感覚でやるのをお勧めする。

あまり高額買取に拘らない

中古買取全般で言える事だが、「自分の感覚よりも65%ぐらい低い査定になる」と思っていたほうが、心のストレスになりにくいかと。

実際のところ、ニッチ。希少な品物であれば買い取り価格は高くなるが、駿河屋で取り扱っているマンガ・アニメ・ゲーム・同人という分野は、たとえニッチな品物であっても、需給が成り立たないような品物については、二束三文の買取になる。

それ以外にも、流通量が多いもの(たとえば同人の場合、大手サークルなど発行部数が多い作品など)や、紙製品の多い分野なので、品物の状態(劣化具合)など、場合によっては買取価格が付かないこともある。

基本的に中古買取に利益性は、ほぼ皆無

中には利益をあげるような「プロ」も確かにいると思うが、そういう特殊な人達の事を考えるのは時間の無駄。
あくまで「不要品を上手に処分する」程度で考えるのが良いかと思う。

買取ルールは絶対に守る

これは鉄則

たとえば駿河屋で買取していない一般の生活雑貨や衣料品は送らないとか、買取依頼の書類は適切に準備する、適切な整理・荷造りを行う、などといった決まり事は必ず守るべき。
相手との商取引の効率を重視・尊重する点からも最も重要。

これは一般的な商取引でもそうなのだが、客は店よりも立場は上ではない。この点をはき違えている人は、商取引だけでなく、人とのコミュニケーションの在り方など、基本的な部分から考えを改めるべき。

あとこれもよく誤解されているが、買取を依頼するのは「個人」であるのに対し、買取店は会社であり「組織」である。
「個人」は小回りが効くし自由度は高いけど、会社や企業という「組織」は、ルールに則って運営されているものなので、個人に比べて自由度は低いもの。
よく自身の都合とか、自分が有利だったり、自分の効率を優先する形で物事を進める方がいるが、これらは往々にして迷惑なことが多い。相手の都合に配慮して取引をすることが必要。

まぁ「心象」だけでビジネスは成立してはいないけど、「心象」はビジネス上において重要なポイント。

「店頭買取」「通信買取」どちらを選ぶ?

正直なところ、何とも言えない。
なので以下は、あくまで個人の推測。

商業作品の場合であれば、買取相場をオンラインで確認することも可能だと思う。ところが同人作品のように、バーコードや商品コードのないような物品の場合、いちいちオンラインでは査定していないのではないかと思う。

そうなってくると、店頭の買取担当者の「目利き」に一存することになってくる。
別に店頭買取担当者の「目利き」を疑っているわけではないが、担当者だって人間である。個人差として習熟度や得意不得意はあるはず。

これは、おそらく通信買取でも同様の状況が生じているとは思う。
ただし通信買取の場合、「目効き」のスタッフが複数人いる場所での査定を行っているはず。
その場合、たとえ習熟度が低かったり、不得意分野のスタッフが査定にあたっていても、熟練・得意分野のスタッフに確認しやすいと思うのは、邪推だろうか。

確かに送料の問題はあるが、その点を考えると、通信買取のほうが高額になる可能性は高いかと。

自分なりのベストプラクティス

「あんしん買取」に「かんたん買取」を追加して通信買取する

駿河屋には「あんしん買取」という買取額の事前見積するシステムがある。
これは買取を依頼する側(つまり我々自身)が、駿河屋の買取Webを使って検索し、買取依頼する品物の査定額を調べてから、その内容に沿って送るというもの。
(ただしこの時点での査定額、あくまで買取予定額。実際の買取額は、品物を送付して状態を査定してから決定となる。状態が悪いなどの理由で実際の買取額が減額されることはある
これを使えば、買取最低額はクリアできるし、現実の買取相場も把握できる。
(幻想を抱かずに済むという意味も、多分にある。)。

その点を利用して「あんしん買取」でおよそ1万円分の品物を準備。残りは「追加分」として、それ以外の品物と一緒に箱詰めして送っている。

しかしながら「同人作品」などをはじめとして、品物にJANコードや商品型番などが付属していない品物もある。
それに「そもそも検索するという『手間』」も含め、買取検索の利用には「限界」がある。
なので、自分の場合は、1回の発送(1箱分)あたり5千~1万円前後を目処に「あんしん買取」の品物を設定している

「あんしん買取」には「追加分」として「かんたん買取」依頼品を同梱することが可能

個人的には、上記「あんしん買取」の買取金額を目処に買取を依頼。
実際に送付する際には「かんたん買取」の「追加分」を含めて大きめなダンボール箱に同梱して、発送している。

通常「かんたん買取」のみで発送した場合、30点以上の買取であることと、買取金額が1,500円未満だと、送料が請求されてしまう恐れがある。
しかも「かんたん買取」は、事前に買取金額が判らないからので、発送時点で送料がかかるかどうかも不明。

これを回避するため「あんしん買取」で送料無料となる3千円をクリアし、そこに「かんたん買取」分を追加することで、なるべく多くの品を一度に発送できるようにしているというからくり。

若干面倒なように見えるが、同人グッズなどをはじめとする買取価格を検索しても見つからないような品物については、この「追加分」として同梱することで手間を省略し、なるべく多くの品物を一度に送って買取を依頼することができる。

ちなみに「買取検索」でヒットしないものは、個別に問い合わせて買取金額を確認することができる。
だが、同人グッズのような品物を個々に問い合わせて金額を確認することは現実的ではないし、往々にして「現物確認しないと査定できない」「0円買取」と言われるのがオチなので、手間を考えると、とっとと送ってしまうのが良いと思う。

箱は最大100サイズ超ぐらい、重量 20kg 前後を目標

若干大きめではあるが、容積や箱の運搬などを踏まえると、これ位のサイズが最も現実的ではないかと思っている。
自分の場合、近所の小さな郵便局に持ち込んで発送しているのだが、窓口や保管場所が大きくないし、ほぼ女性職員で占めるため、検量などで手持ち可能な限界として、このサイズ・重量に配慮して送っている。

発送物によっては、このサイズ・重量にならない場合もある。あくまで目安。

ゆうパックは30kgまで遅れるのだが、20kg超えると、いよいよ1人では持ち運べなくなってくる。それぐらいの重量。

ちなみに小学1年生手前の平均体重が20kg。成長面において「だっこ」の限界ライン。
(20kgだって結構な重さがあるし、個人差によって持ち上げられないとは思うが。。。)

同じ品物は送らない

単なる「記憶違い」や、同人の場合は「共同購入などのミス」によって、品物をダブって購入所持している場合がある。
この場合、同じ品物を送らないように配慮すること。

複数個の同一品を買取依頼した場合、店からしてみれば「不良在庫」に繋がるリスクが生じる可能性だってあるわけで。
その点から買取金額が下がったり、場合によっては買取不可となる可能性もあるので注意。

「あんしん買取」の見積依頼は月金土日曜日に出す、祝日にも注意

見積依頼を出してから見積金額が表示されるまで、概ね2日~4日ほどかかる。

あくまで経験からの「およそ日数」。
買取窓口が繁忙なタイミングによっては、それ以上かかることもある。

あとこれが大事なのですが、見積金額が提示されてからは5日以内に荷物を必着させないと、見積金額での買取が保証されなくなる。
しかも最終的に提示される買取金額も、個々の買取金額ではなく、総額表示のみになってしまう場合あり。

この辺を加味すると、火水木曜日あたりに見積依頼した場合、回答が週末に掛かってくる可能性が生じる。
そうなると郵便局が休業日のため月曜日まで発送を待つ必要が出てくる。
結果、その影響により「5日以内の必着」に遅延するリスクが発生する。

なので、この曜日のタイミングにも十分注意すること。
同じ理由で年末年始やゴールデンウイークなどのタイミングにも十分注意。(自分は連休に見積依頼することは避けている)

でも、たとえ5日以内の必着から遅れたからと言って、経験上「1日程度」であれば、総額表示の買取にはなってしまうものの、ほぼ買取金額に近い金額での買取になると思う。
(こんな「つまらない事」で客と揉める気は、店にはない思う。。。)

ただし、相場が日々変化するような品物、例えばコミケ直後の同人誌や、入手困難な最新ゲーム機器など、「転売ヤー」の餌食になりそうな品物の買取の場合は別の話。
タイミングに左右される品物の買取において遅延して、買取価格が安くなってしまうのは、買取を依頼する側の自己責任。

NVR500 の共有フォルダでハマったはなし

SMB の話です。

どうやら最近の Windows10 では SMBv2, SMBv3 で繋ぐみたいで。しかも SMBv3.1 つまり最新バージョン優先のようで。
SMBv1に至っては、設定しないと接続できない状況にまで成り下がったらしく。

調べてみると、SMBv1 はランサムウェアの餌食になったらしく、その影響で、Windows10 の途中で SMBv1 での接続が既定では無効にされたみたい。

その影響で、NVR500 の共有ディスクは参照できないのだと思い至ったので、以下のサイトなどを参考に SMBv1 で接続できるように設定してみた。

ところが

いくら設定をしても「¥¥xxxxxxxx~」ではネットワーク接続できない。
IPアドレスでもドメイン名を入力しても、だ。

でも windows7 環境で接続を試みたところ、あっさり繋がった(共有フォルダが参照できた)。

なので今度は試しに「ネットワークドライブの割り当て」で確認してみたところ、こちらも駄目。
ホスト名・IPアドレス、いずれの方法でもサーバが見つからない。

でも ping を打てば返ってくるし、そもそもルータからクライアントの IP アドレスは払い出されてる(ルータのDHCPサーバ機能は動いてる)し、そもそも Windows10 マシンからインターネットには繋がってる。ネットワーク的には問題ない。

ここまでやって気付いたのだが、もしかしたら認証まわりか、ポリシーまわりの設定がおそらく影響している可能性を疑っている。

断念

とまぁ、ここまで色々なことをやってきたのだが、これ以上を色々と調べて試すとなると、今度はレジストリとかポリシーまわりの設定まで弄る必要が出てきそう。

でも、それはそれで煩わしい(トリッキーだ)し、いよいよ本当にPC本体のセキュリティを危険に晒すリスクもありそうだし。
そもそもそこまでして、繋ぎ込むメリットもないだろう、という気分になってきた。

というわけで、ここで調査打ち切り。

有効活用の模索 ⇒ 断念

ここで方針を変えて、レガシーな共有ドライブを、ownCloud 経由でディスクとして利用できないかを検討してみた。

…とまぁ、ここまで図を作ってみたのだが、これも結局は断念することにした。

理由は以下。

そこまでしてSMBv1 しか使えない機材を、ずっと使い続ける必要はのか? メリットは?

この点に尽きる。

いくらネットワーク上のルールを厳格にしたとしても、今のご時世、ここまでしてわざわざトリッキーなネットワーク環境を構築するだけの、自身が納得できるメリットにはならなかった。

それにゴチャゴチャ難しい環境を構築したとしても、機材は老朽化する。
そんな機材を無理矢理使ったとして、「それが壊れたら」と思うと、今度は復旧そのものが難しくなってしまう可能性が高い。

それぐらいであれば、最新の機材を準備して快適な環境を手に入れたほうが、カネはかかるが、精神衛生上よろしい。
いや、たとえ今すぐに手に入れなくても、故障したときの事を考えて、スムーズにリプレースできるような環境を維持しておいたほうが良いのではないかと、考え至った次第。

気がついたら、機材・環境は老朽化

スマホなど端末の進化は著しいものがあるが、それはサーバとかネットワークも一緒。
いつの間にか(というか「あっ」と言う間に)機材はポンコツになり、ネットワークプロトコルなどの規約も進化してる。

そう考えると、ルータやサーバの類も、それらが作られた時代のものを頑なに利用するのは、セキュリティや故障のリスクを考えると、良い手段とは言えない。

先人の教えに「大事に使え」というような考え方もあるし、それが可能なものもある。
しかしながらモノによっては、長く使うことが、最終的に大きな不利益を被る危険性があることも、認識しておく必要がある。

とはいえ、カネかかるなぁ。(溜息)

余談1、DroboFS は何故か繋がってる。

ちなみに同じ状況(SMBv1 しか対応していないの)は、我が家で所有している DroboFS でも発生している、はず。

そころが、なぜかこちらは、SMBv1 で接続しているにも拘わらず、普通に参照できる。読み書きも正常。何故?

確かに DroboFS には、個々のユーザIDとパスワードを設定しており、フォルダ毎にそれぞれびアクセス権も設定している。
対して NVR500 には、元々、代表的なユーザIDとパスワードは設定できるものの、個々のユーザを設定することはできない。

その辺りの「違い」が今回の原因なのか?

余談2、リプレースを考えている。

色々と考えた結果。やはり SMBv3 に対応しているNASへのリプレースを考えている。
そうした場合 Synology などが割とリーズナブル、かつシェアも高そうなのだが、個人的なポリシーとして NETGEAR の ReadyNAS を採用するつもり。

ちなみに、我が家にはオンプレサーバが何台かあるので、これらの資源を有効活用すべく、フリーのNAS用OSとか ownCluod を利用することも検討した。ところが、色々調べてみて結果的に不採用。メーカーのサーバを利用したほうが安全そう。

不採用1:フリーのNAS用OS

FreeNAS など、いくつか代表的なOSが開発されているが、いかんせん「安定性に欠ける」というような記事が散見される。

確かに「どんなマシンでも動くようにする」ためには、それだけ「汎用的なプログラムが必要になる」のは当たり前。
それに対してメーカー製のNASは、製品に特化したOSを構成することになるし、それだけ「余計な部分」が削ぎ落とされている。
つまり、安定稼働の追求力が、フリーに比べて桁違い。

しかも最近は AWS (S3 ストレージ)などのクラウドを使ったバックアップの連携まで考えられているとなると、メーカー製NASは、その「手厚さ」も桁違い。

それにアプリケーションサーバのOSをフリーで選定するのとは訳が違う。
NASのOSは「ストレージデータ」というかなり大事な資産を管理している。
これを破損することは勿論の事、サーバそのものの安定稼働やバックアップにまで考慮すると以下略。

不採用2:フリーのオンラインストレージソフトウェア

要するに ownCloud の事。商用に例えると DropBox が近い。

こちらも検討したものの、やはり FreeNAS と同じで安定性やサポートに一抹の不安が残った。

それともう1点。

ownCloud 上で管理するファイルは、あくまでローカルファイルとの「同期による共有」となる。
つまり、原則としては、実体ファイルはローカルにも存在することになるため、ローカルディスクの容量を逼迫してしまう。

まぁ厳密にはクラウド(サーバ)上にのみデータを保存する形にして、必要に応じてデータをダウンロードする形での運用も可能だが、その場合は運用や設定に手間が生じることになる。

ちなみに「その1」:商用NASとしては、Drobo も採用候補だった

ところが、そもそもNAS製品については主力製品ではないようで、該当製品が2つしかない。
しかも米国サイトのサポートをページを見た限りでは、SMBv2 のサポートに留まっている(SMBv3 にまだ対応していない)模様だったのと、国内シェアやクラウド連携など機能面で弱そうだったので、今回は採用を見送った次第。

ちなみに「その2」:「個人的な理由」とは

こちらは「続きを読む」参照。

続きを読む