インターネットでの身の守り方
「インターネット」とは何でしょうか。「パソコンを使ってWebサイトを見たり、動画を見たりするやつ」というのは、インターネットを表した言葉のひとつと言えます。そこでまた別の見方をしたとき、インターネットとは「時間や場所を超えるもの」とも言うことができます。
時間と場所を超えるもの
ピンと来づらいかもしれませんが、インターネットを使って日頃やっていることは、インターネットを使わずにやっていることと、じつは大きく違いません。 Amazonや楽天を開いてしていることは、インターネットを使わずにお店に出かけていってやっている買い物ですし、Youtubeで見ている動画は、スマホの録画を直接見せ合うことや、映画館で映画を見ることと同じです。
インターネットが持つ、インターネットの外との最大の違いは、それがいつでも・どこでもできることにあります。それがつまり「時間と場所を超えること」なのです。これはインターネットの利便性に直結し、さらに危険性にも直結する特徴です。
インターネットの危険についての考え方
インターネットの危険性は上で説明した特徴をそのまま反映するものであり、つまりそのために起こる危険に対処すること防ぐことができます。具体的には以下に説明します。
現実と変わらないということ
インターネット上での行動は、現実と同じ程度に安全であり、同程度に危険でもあります。つまり、危険な場所での行動は慎むべきですし、安全な場所での行動をなるべく心がけるべきです。安全性が判断できない場所での行動は避けるべきです。
接する相手についても同様です。危険な人物ではなく、信頼できる相手とのみ接するようにしましょう。また、そのどちらかの判断がつかない相手に対しては、決して油断しないようにしましょう。
時間と場所を超えるということ
インターネット上での行動は、時間と場所を越えます。つまり、ある情報がいつ、どこで見られているかはわかりません。さらに、多くの場合誰に見られているかもわかりません。
たとえば今あなたがSNS上でした発言が、数年後、予期せぬ人物（例えば数年後のあなたのことを理由もなく一方的に憎み、殺害を企図している人）に見られる可能性は十分にあります。
インターネットでの危険とその対策
情報漏洩
情報漏洩とは「その情報の持ち主が意図しない範囲の人間が、その情報を知ってしまうこと」を意味します。どんな情報についても、それを開示するにあたっては、信頼できる相手・場所かを判断するようにし、それが信用できる相手や場所だったとしても、入力する機会は極力減らしましょう。
個人情報には、氏名や住所、写真などはもちろんのこと、Eメールアドレスや会員番号など、氏名や住所に紐付いて個人を特定することができる情報すべてを含んだもののことです。あなたの個人情報はもちろん、他人の個人情報についても、インターネット上に公開する際には細心の注意をはらいましょう。
ちなみにメールアドレスと性別とを紐付けた情報は、1件あたり1000円程度でやりとりされているそうです。
情報漏洩の対策
原則は、「信頼できる相手、場所にのみ情報を開示すること」です。それが難しい場合は、「誰に知られても良い情報だけを開示すること」を意識しましょう。
情報は、あなたが情報を取り扱うすべての場所から漏洩する可能性があります。つまり、買い物をするショッピングサイトや発言を行うSNS、閲覧するだけのWebサイト、およびPCなどの端末そのものの中です。
偽名を名乗る
インターネットでのみ使用する名前を持ちましょう。これはいわゆる「ハンドルネーム」と呼ばれるものと、偽の氏名・住所・性別とがあります。
ハンドルネームについては持っている人が多くいることでしょう。インターネットで使用するあだ名を考えて、Twitterなどの名前として使用します。ローマ字で表現できる名前にしておくと、海外のサービスを利用する際の利便性があがります。また人と重複しづらい名前にしておくことで、登録時の煩雑さ（勝手に重複回避用の数字を入れられるなど）を防ぐことができます。また、ハンドルネーム内に個人情報を推測できる情報（誕生日の数字4桁など）を使用するのは絶対にやめましょう。
偽の氏名・住所・性別などについては、信頼性の低いショッピングサイトやその他Webサイトにおいて、理由もなく個人情報を求められた際に使用するもので、予め考えておくと便利です。また、その際の決済手段などは、クレジットカードではなくWebマネーなどを使い、お届け先も最寄りのコンビニを指定するなどして、相手に一切こちらの本当の個人情報を渡さないように心がけましょう。
複数のメールアカウントを使い分ける
メールアカウントは複数持ちましょう。一つは信頼性の高いWebサイトなどで使用するためのもので、他方はそれ以外です。メールアドレスのユーザー名、署名欄などに、氏名や誕生日などの個人情報を使用しないようにしましょう。
SNSなどのアカウントと個人を紐付ける情報を開示しない
TwitterやInstagramのアカウント名、プロフィール、投稿内容に、個人の氏名や住所、性別、顔などや、それらを推測できる情報を掲載するのは避けましょう。可能であれば、公開範囲を「友人までに限定する」などの設定をしておきましょう。
投稿内容について、以下の内容からでも行動範囲をある程度特定することが可能です。
- 選挙区や候補者
- 天気や地震
- 部屋の間取りの情報
- 夜間にサイレンが鳴っていた
- よく行く店
実際の自分の行動に紐づくような情報の開示は、それだけで危険です。「いついつ旅行に行くんだ」という情報は、その間留守にしているということを意味します。住所を知られていたら何が起きるかは、想像に難くないでしょう。
また、誤解されがちですが、Twitterのブロック設定は「ブロックされた人のアカウントでログインしている人から見られなくなる」機能です。未ログインの状態では普通に見られるので注意しましょう。
端末に個人情報を残さない
自分の個人情報について端末に保存しないことはほぼ不可能ですが、他人の個人情報については、意識して削除することができるはずです。「デスクトップ」などのローカル上などには絶対に残さず、できる限り手元の端末上に個人情報を残さないようにしましょう。
端末の記憶媒体を暗号化する
持ち歩く可能性のある端末（PCやスマホ）の記憶媒体は、可能な限り暗号化しておきましょう。決して万全というわけではありませんが、第三者がそれを持ち去ったとしても、記憶媒体だけを取り出して情報を抜き出すことが容易にはできなくなります。
パスワードを複雑なものにしておく
パスワードは、どんなに複雑にしても時間や労力をかければ破れます。それでも時間や労力をかけさせることに意味はあります。最低でも8文字以上、小文字・大文字を含め、数字や記号を混ぜたものを使用してください。一般的に設定されやすいパスワード（0000, 1111, 9999など）、推測しやすい一般的な単語（password, secret, happy, speed など）、氏名、誕生日などの個人情報を用いたものを使うのは、絶対に避けてください。
迷惑メールを真に受けない
世の中の大半の迷惑メールは、文面からそれが嘘だと見破れます。しかし、最近は手口が巧妙になってきているのも事実です。
近年流行したメールでは、「あなたのスマホまたはPCのカメラやデスクトップのキャプチャから、あなたのプライベートの恥ずかしい映像（たとえば自慰行為中の様子など）を手に入れた。これを公開されたくなければ、どこどこへ仮想通貨で支払いをしろ」というものがあります。これを真に受けてお金を払った場合、ネットに動画がアップされることはありません。犯人がお金を受け取って満足したからでしょうか。いいえ、違います。最初からそんな映像は存在しないからです。そしてあなたのメールアドレスは、"カモ"のリストに追加され、他の詐欺グループの手に渡ります。
アカウント乗っ取り
アカウントの乗っ取りは、情報漏洩の結果としてしばしば発生します。
例えばAmazonで情報漏洩が起きたとしましょう。Amazonに登録されているあなたのアカウント情報（アドレス、パスワード）が漏洩しました。それを手に入れた誰かが、Facebookなどの別のサービスで、同じアドレス・パスワードを使ってログインしようとします。無事ログインできたら、あとはなんでも好きなことができますね。
アカウント乗っ取りの対策
メールアドレスに「+サイト名」をつけておく
サービス登録の際、アカウントに使用するメールアドレスに以下の細工をしておきましょう。
たとえばTwitterに登録する際、アドレスを hogepiyo@gmail.com にしようとしているのだとしたら、
hogepiyo+twitter@gmail.com に変更します。これでも普通にメールは届くので、サービスの利用上問題はありません。
さて、登録後のある日、あなたに迷惑メールが届きました。そのメールの宛先は hogepiyo+twitter@gmail.com になっていました。これで、このメールアドレスがTwitterから漏洩したのだということがわかります（あくまで一例です）。
ただしこの設定は、登録できるサービスとできないサービスとがあります。
2段階認証を設定する
サービス側で2段階認証機能を提供してくれている場合、ぜひ設定しておきましょう。第三者がログイン情報（アドレス、パスワード）を手に入れたとしても、スマホなどに送られてくる確認用PINコードを入力しない限りログインできなくなります。
複数サービスで同じパスワードを使わない
冒頭で例示しましたが、複数のサービスで同じログイン情報を用いている場合、どこか1箇所で情報漏洩が起きてしまっただけでも、その他すべてのサービスにログインできる状態になってしまいます。極めて危険ですので絶対にやめましょう。
パスワード管理アプリケーションを使用する
可能であれば、Apple や Google の提供しているパスワード管理アプリケーションを使用するようにしましょう。複雑なパスワードを設定してくれ、さらに入力の手間も省けます。
また、One Password などのアプリケーションを使用することで、覚えておくパスワードを1つだけにすることも可能です。
情報漏洩対策を行う
前述の通り、アカウントの乗っ取りは情報漏洩によって起こります。それは多くの場合サービス側の不手際によることが多いのですが、自分で開示した情報から推測されてしまうこともまたあります。
氏名、アカウント名、誕生日などはパスワードに使用されることが多いものです。また、「秘密の質問」として設定されやすい内容（母親の旧姓や出身地名、好きなプロスポーツチームなど）も、第三者の目からは隠しておくべきでしょう。
共有のPCに情報を残さない
ホテルや図書館、ネットカフェなどで使用できる共用パソコンは便利ですが、自宅のパソコンと同じ感覚でそこにログイン情報を記憶させてしまうと、後から利用する人がそのままあなたのアカウントにログインできるようになってしまいます。パスワードなどの情報は絶対に記憶させず（「ログインしたままにする」機能の使用もやめる）、使用を終えて席を立つ前に、ブラウザの履歴も消しておきましょう。
ウイルス感染
インターネットの情報は、私達人間が直接情報をやりとりして見ているわけではありません。PCやスマホなどの端末が代理で情報を受け取り、その中身を私達が理解できる形にして表示してくれています。
その過程において、端末にあなたが意図しない動作をさせるような情報が送られてくることがあります。それは結果として、あなたの個人情報を誰かに送ったり、あなたのパソコンやスマホについているカメラに写った画像を送ったりします。
ウイルス感染の対策
アンチウイルスソフトをインストールする
基本中の基本です。これをせずにインターネットを使用することは、全裸でライオンの檻の中に入るようなものです。無料で使用できるものの中で個人的なおすすめは、SophosまたはESETです（あくまで参考です。何かあっても責任は負いませんよ）。また、必ず定期的なスキャンも設定しておきましょう。
AdBlockerを使う
ブラウザの拡張機能として、AdBlocker（広告ブロック）を入れておきましょう。広告以外にも、そのWebサイトが追加で読み込もうとしているさらなる他のURLをブロックしてくれます。AdBlocker を使っていると表示できないWebサイトもあるので、オンオフ切り替えながらの使用が前提になります。
怪しいURLを開かない
基本その2です。開くことで何が起こるかわかっているか、または絶対に信頼できるURL以外は開かないようにしましょう。仮に信頼できる人から送られてきたURLだったとしても、そのアカウントが乗っ取られている可能性もあります。不用意に開くことはしないようにしましょう。
怪しいメールを開かない
これも基本です。知らない人物や、身に覚えのない内容のメールは開かないようにしましょう。
怪しい記憶媒体を読み取らない
信頼できる外付けHDD、SSD、USBメモリや、DVD・CDだけを読み取るようにしてください。
第三者に端末を触らせない
喫茶店やコワーキングスペースでのPC作業中に席を立つなどして、第三者がPCを持ち去ったり操作したりすることができる時間を作ってはいけません。持ち去られていなかった場合でも、意図しないものがインストールされている可能性はあります。また画面をロックしていたとしても、USBメモリなどを挿すなどは可能です。端末からは絶対に目を離さないでください。
インターネット外の危険との組み合わせ
インターネット上での行動についていかに安全を心がけていても、その周囲の環境が危険に満ちていれば、安全とは言えません。
インターネット外の危険との組み合わせの対策
公共のネットワークを使用しない
公共のWiFiや、ビジネスホテルの無線・有線LANを使用しての情報のやりとりは非常に危険です。通信の内容を覗き見できることはもちろん、表示するWebサイトのすり替えなどが容易に行えるからです。漏洩した場合に致命的な情報（銀行口座のパスワードなど）は、絶対に取り扱わないようにしましょう。
VPNを使用する
公共のネットワークを使用する場合、必ずVPNを設定してください。VPNを利用することで、通信の覗き見やWebサイトのすり替えなどができなくなります。
自宅のWiFiには必ずパスワードを設定する
自宅にWiFiルーターが置かれている場合、必ずパスワードを設定するようにしましょう。暗号化方式はWEPやWPAではなく、WPA2のセキュリティ方式に設定するのが理想的です。出荷時に設定されているパスワードからも、変更できる場合は必ず確認しておきましょう。
ちなみにWEPのパスワードは、方法さえ知っていれば小学生でも破ることが可能だそうです。
炎上
いわゆる「炎上」はインターネットに限った出来事ではありませんが、ここではインターネットでの炎上に限った内容を記します。
炎上の対策
SNSをしない
炎上は、他人の逆鱗にふれることによって起こります。しかし、どんな意見でも他人の逆鱗に触れることがありえます。公開状態のSNSでの発言は、どこでどんな人が見ているかわかりません。あまり現実的でないかもしれませんが、SNSをしないのが最短で最善の策ではあります。
発言する前にすこし考える
とはいえ、人はなにか発言したくなるものです。公開されている場ですこし思い切った発言をする前には、以下について考えてみることで炎上のリスクを避けることができるでしょう。
- 誰に見られても良い内容か
- 法的に問題ないか
- 倫理的に問題ないか
- 特定の人々を敵に回さないか
自分の最も尊敬する人に見られても問題のない、法的にもクリアな、倫理にもとることもない、また特定の人々を攻撃してしまうような内容でもないものだけを発言しましょう。それ以外は心に秘めておくのが無難です。「少しぐらい大丈夫でしょ」と思っての行動は、1回目は大丈夫なこともあります。しかし、複数回続けると必ず身を滅ぼします。
個人を紐付ける情報を開示しない
こちらは上述した通りです。炎上してしまった際、あなたのアカウントのみならず、あなた個人や家族や、所属する組織が攻撃にさらされてしまう可能性があります。
公開範囲を限定する
全世界に対してあえて発言したいのでもない限り、発言を公開する範囲を限定しましょう。
炎上させたい人に近づかない
世の中には、炎上を見て楽しむ人が存在します。そして彼らは、あえて他人を炎上させるようなことを喜んでします。発言する前に十分考えていたとしても、曲解した内容に変えることで火種にすることもできます。そもそもそういう人には近づかない、発言も見せないようにしましょう。
挑発に乗らない
SNS上では、多くの人があなたの発言を見ています。しかし、あなた自身を見ているわけではありません。誰かに図星を突かれるようなことがあったとしても、それは当てずっぽうでしかありませんし、あなたにそれを否定する義務もまたありません。多くの場合、放っておいたところで何の名誉も傷つきません。第三者から見ても正しいと思えるような指摘でない限りは、あえて挑発に乗ることはせず、ブロックなどをして静観するのが得策です。
危険は他にもある
インターネットを使うにあたり、考慮すべきことの例を挙げていきました。しかし、日々の技術の発達や使われ方の変化などにより、危険もその対策もまた日々増減しています。上記の例を基礎にして、頭の中の情報を更新していくと、より安全にインターネットを使うことができるでしょう。それでは。
本棚増えた
本棚を買い足しまして、ついでに整理の仕方を変えてみたという話です。
なんで増やしたの
我が家は本が多すぎて、本棚は過密状態、そしてさらに本棚から溢れ出していました（いわゆるビブリオマニアな人からすれば少ない方ですが…）。しかし、そんな状態が長く続いた後に、昨年の10月にゆえあって引っ越しをしまして、その結果家全体が広くなり部屋数も増えたのでした。そしてちょうど書斎に使えそうな部屋もあった。これはやるしかない。
どういう状態だったか
もともとあった本棚は、無印良品のスタッキングシェルフ（3x5段）でした。
スタッキングシェルフは1区画の寸法が縦370x横370x奥行280mmなのですが、少し頑張れば、ここには文庫本を3列に並べることができます。さらにその上に20cmほどの空間が残りますが、ここにも平積みすることができます。
こういう感じでその他のスペースにも本が並んでいました。
また、なんとなく場所がわかれていたものの、漫画の区画や文庫の区画、単行本の区画、大型本や雑誌の区画などが混在している状態でした。この収納の仕方は、置いているだけで整理されているとは言えません。どんな本があるのかわかりづらいうえに、あることがわかっている本でも取りづらい。使い勝手が悪いことこの上なしです。
全体像はこんな感じ。ごちゃごちゃ。
追加した本棚
新たに追加でおけるスペースが1箇所あったので、そこに置く本棚をいろいろと見ました。そして最終的に、無印良品のスタッキングシェルフ（3x5段）を選びました。安くなっていたこともありまして。
さらに既存の本棚の上にもう1段追加できそうだったので、増設パーツも購入することにしました。そこにスペースがあったから仕方ない。中途半端な我慢が一番良くない。
豊富なオプションパーツ
ところで、スタッキングシェルフには豊富なオプションパーツが用意されています。それもまた追加購入の決め手でした。
半分の箱
見てください上から二段目にあるこの箱。ちょうどスタッキングシェルフの1区画の半分に入るような大きさになっているんです。するとこうできるんです。
じゃーん、横並び二段。
ブックエンド
これは正確にはスタッキングシェルフ用のパーツではないんですが、無印良品ではブックエンドも売られています。これを、今回は10枚購入しました。
中途半端な我慢が一番良くない。あとこれはそんなに高くない。これがあると本棚の上にさらに本が置けるんです。
どうなったか
こうなりました。スペースに余裕が生まれたので、本を整理することもできるようになりました。具体的には、
こんな感じで並んでいます。小説などはあまり読み返さないので、前後列での配置で妥協しました。
また、本の列の手前にスペースができたのですが、これも意外な便利さにつながっています。読んでいる途中の本や次に読もうと思った本、頻繁に手に取るのでいちいち出し入れしたくない本などをここに置いておけるのです。
マンガ本や雑誌などは、追加で購入したもうひとつの本棚に移動しました。その結果、場所がはっきりと別れて使い分けができて便利になりました。
これから
とはいえ今後も本が増えていくことは予想できます。そういうときには、無印良品のスタッキングシェルフ用オプションである曲がった鉄板を購入することで、本の列の上に文庫サイズの本を置けるようになるみたいです。
https://roomclip.jp/photo/v0cl
この方のような感じ。ただこれ3500円ぐらいするんですよね…。同じようなものが100円ショップにもあるんですが、そっちは横幅がスタッキングシェルフの1区画に対してぴったり合わないので美しくない。もしかしたら、先述した半分の箱を買い足すかもしれません（箱は2500円程度）。それでは。
サブスクリプション・システムの生活史
はじめに
この記事は、筆者が2018年から関わり続けているあるサブスクリプションモデルのサービス（詳細は後述）で、それを実現・継続するための運用やシステムがどのように変化していったかを述べ、さらにこの先にどのようなことが待っているのかを予測しようというものです。あくまで筆者の個人的な振り返りであり、その他のシステムにとって一般的でない内容を含む場合もありますが、参考にできる部分もあると思います。
サービスについて
筆者の関わっているサービスの概要は以下です。
- サービス開始は2016年ごろ
- 定期購入モデル
- 月に1度、商品4〜6品が詰められた箱が届く
- 商品の内容は、お客様の属性（性別やアレルギー情報、ご要望など）によって変わる
- 定期購入契約を解除せずに、商品を届けない月を選ぶことができる（お届けをスキップできる）
ここでは具体的に名前を出さず、仮に「フェノックス（以下、略称POX）」と呼ぶことにします。
POXの概略図
お客様にとっての流れ
※図はTBD
- 購入画面でPOXを注文する
- しばらくすると、1箱目が届く
- 箱を開けて楽しむ
- またしばらくすると、2箱目が届く
- 箱を開けて楽しむ
運用者にとっての流れ
※図はTBD
- POXを受注する
- 1箱目の発送を行う
- 継続した受注を作る
- 2箱目の発送を行う
POXの運用の流れ
上の図をそのまま書き出したようなものですが、大まかに以下の作業の流れによって、フェノックス（POX）は運用されています。
- 企画
- 商品の仕入れ
- （新規／継続）受注
- 決済完了
- 受注ごとに詰め込む商品を決める（商品割り当て）
- 商品箱詰め
- 発送
- お問い合わせ対応
- 会計処理
POXのこれまで
サービス開始から自社システム化まで（2016年〜2018年7月）
サービス開始当初、お客様からの受注は社内開発したシステムではなく、外部のカートシステムを利用していました。一部顧客情報の管理（個人情報以外）はGoogleSpreadSheet上で行い、社内に設置したNASに保存した個人情報と紐付けて、商品を発送していました。
つまりこういう状態でした。
※図はTBD
- 企画：なし
- 商品の仕入れ：GoogleSpreadSheetなど
- （新規／継続）受注：外部カートシステム
- 決済完了：外部カートシステム
- 受注ごとに詰め込む商品を決める：GoogleSpreadSheet
- 商品箱詰め：社内で手作業
- 発送：社内で手作業
- お問い合わせ対応：電話やメール
- 会計処理：GoogleSpreadSheet
初期には月間の出荷数が10箱未満の月もあり、これでも全く問題なく作業が行えていました。しかし、お客様や受注が少しずつ増えていくにつれて、GoogleSpreadSheetでの管理が厳しくなっていき、月間300箱を超える頃には、運用担当者（当初1名、その頃には2〜3名）の残業が常態化してしまっていました。
担当者が増えているにも関わらず作業時間がなかなか減少しないのは、受注ごとに箱の内容物を決定する「商品割り当て」の作業が、商品の在庫が共通であるために複数の人員で分担しづらく、また箱数に応じて純増していき、しかも割り当てに考慮する情報が多く複雑であることが理由です。最終的にこの作業は受注数が月6000件（！）になるまでSpreadSheet上で行われることになりましたが、その頃になるとひとつひとつの割り当てに対して連動する関数の処理に時間がかかりすぎ、もはやまともに作業が行えなくなっていました。
サービス開始から1年以上が経過した2018年4月ごろになり、月間の発送箱数が300件ほどになってきたころ、POXのさらなるサービス拡大という事業目標に対して、他社カートシステムのカスタマイズ性の低いカートシステムや、運用コストの大きさがふさわしくないことが認識されはじめ、5月には自社開発のシステムへ移行が検討されました。
自社システム化検討期（2018年5〜6月）
先述の理由から進められてきた自社システム化の検討ですが、この時期に考えられていたことには誤算もありました。
当時は「サービス開始当初は運用フローが決まっていなかったために、SpreadSheetと外部カートシステムの利用のほうが都合が良かった。しかしながらフローが固まってきたために、多少柔軟性を失ってでも自社システム化したほうが良い」と考えられていました。しかし、実際には自社システム化した後にも運用フローは大きく変化しています。それは、以下の理由によると思われます。
SpreadSheetと外部カート（と人力）の場合
- マーケティング施策は運用フローに直接影響する
- 運用フローはシステムの制限を受ける
- システムの制限がゆるければ、運用フローにもマーケティング施策にも課される制限がゆるくなる
- 運用フローは問題なく変化する
自社システムの場合
- マーケティング施策は運用フローに直接影響する
- 運用フローはシステムの制限を受ける
- システムの制限が比較的厳しく、運用フローにもマーケティング施策にも課される制限が厳しくなる
- しかしマーケティング施策の検討自体はシステム担当者不在のもとで（あるいはあえて考慮せずに）行われるため、システムの制約を受けない
- マーケティング施策に合わせたシステムの変更が検討される
- コストなどが見合うと判断されれば、むしろより柔軟なシステム変更が余儀なくされる
- 運用フローも変化する
ご覧の通り自社システム化することによって起こったことは、4番目の「マーケティング施策の検討はシステムの制約を受けない」ということが明らかになって、自社システムであることを理由にむしろより柔軟な変更を要求されるようになるということでした。むしろそうして柔軟な変更が行えるということが自社システム化のモチベーションでもあるため、考えてみれば当たり前の話です。
具体的にPOXの場合では、当初は月一回だけ行うとされていた箱の発送作業とそれに付随する割り当てなどの作業が、月に複数回行われるよう変化していきました。また、自社開発の商品が登場し、割り当て作業時などでの特別な取り扱いを要求されるようにもなっていきます。
つまり、自社システム化することで運用フローをある程度固定し効率化できる部分もある一方で、運用フローが完全に固定されることはありえず、その変化に合わせて、すでに実装された運用フローを変更するためのコストのほうが増えてしまうのでした。
これに対応し続けていくためには、外部サービスの使用・自社システムの開発に関わらず、受注や定期購入や商品などのモデルを、なるべく柔軟に取り扱える状態を用意し続けることが必要だろうと思います。変化のない事業などありえず、事業が変化していくのであれば、システムもまた変化していくしかないのです。
自社システムリリース（2018年7月〜12月）
自社システム化すると言っても、いきなりすべてが実装完了して、これまで使っていた道具が一気に入れ替わるというわけではありません。
自社システム化の目的は「カスタマイズ可能なカートシステム（＝新規顧客獲得）」と「運用コストの削減」でした。これらはまったく異なる目標であり、実装の対象も前者がお客様向けのWebアプリケーション、後者が運用者向けのそれと、まったく別物です。いずれかを選択するしかありません。そしてここで優先されたのは、「カスタマイズ可能なカートシステム」のほうでした。
その後、お客様側におよそ40日間、運用側（いわゆるオペ画面）に60日間をかけて並行した開発が行われ、それぞれ無事にリリースが行われました。ここで用意されたのは、いずれの実装もあくまで必要最低限を満たしたものであり、現実的には「頑張ればカスタマイズできないこともないカートシステム」と「最小限度の情報が見られるオペ画面」と呼ぶべきものでしたが、カスタマイズ性のほうはたしかに良くなっており、その後購入画面のABテストやその結果としての改修、お客様自身で契約の情報を確認する画面（マイページ）を充実させるための実装が行われることになります。
そしてそれが功を奏したのか、10月には月約1000箱、12月には月約2500箱が出荷されるまでに規模が拡大していきました。
※図はTBD
- 企画：なし
- 商品の仕入れ：GoogleSpreadSheetなど
- （新規／継続）受注：外部カートシステムと自社システム
- 決済完了：外部カートシステムと自社システム
- 受注ごとに詰め込む商品を決める：GoogleSpreadSheet
- 商品箱詰め：社内で手作業
- 発送：社内で手作業
- お問い合わせ対応：電話やメール
- 会計処理：GoogleSpreadSheet
しかし規模が拡大する一方で、運用コストもまた増大していました。カート部分を自社システム化したものの、外部のカートシステムで継続契約してくださっているお客様もそのまま残っていたため、運用担当者としては外部と自社との2つのシステムを使った作業を行う必要がありました。また、発送する箱数の増加にあわせて自然とお問い合わせの件数も増加しており、そちらに時間を奪われてしまうこともしばしばでした。
また、お客様側画面の改修とそれに伴う運用フローの変更に対してシステムの改修を行うにあたり、実装上の問題点に突き当たることが多かったのもこの時期でした。以下に具体例をふたつ挙げます。
密結合すぎる購入処理の実装
さきほど書いた通り、当初は箱の発送とそれに関わる作業とが月に1回行われると想定されていました。そのため、実装も当初は月1回の発送で固定されていました。また、購入時の情報入力の順番も一方通行で、非常に変更が入れづらい構造になっていました。
より具体的な実装は以下のようになっていました。
- Controllerクラスがリクエストを受け取る
OrderPresenterクラスをnewしただけで、お客様の登録が完了して与信が取られて契約が完了してしまうのです。それはつまり、newするためにそれらの処理が要求する情報をすべて用意する必要があるということでもあります。
業務フローが固定的であればそれでも（まあギリギリ…）許容できなくもないのですが、固定的でない現実を前にこれではあまりにも密結合すぎました。また、決済処理モデルクラスが受注の情報を直接書き換えるようになっていることも、責任範囲を明らかに逸脱しています。
ということで、Presenterとして実装するには違和感がありすぎたこともあり、OrderPresenterクラスは廃止して、Controllerがビジネスロジックを表現する実装に変更しました。また、決済処理モデルクラスの行っていた責任範囲の逸脱も是正されました。ここは購入という重要な機能だということで、実装工数がかかったことももちろんですが、検証にも多くの時間がかけられました。
購入画面は文字通り購入に直接影響するため、マーケティング施策の都合から大きめの変更が入る可能性が非常に高い箇所です。高い可用性を確保しておきましょう。
ところで、Presenterは本来こういう任意のビジネスロジックを表現するための実装パターンではありません。もし何らかの理由から購入処理をControllerクラスに書きたくない場合には、Concernsに逃がすのが良いのでしょうか。今のところその必要性は感じていません。
確定受注と未確定受注の存在
POXは、受け取らない回を選ぶことのできる（スキップのできる）定期購入です。それを実現するため、契約時内部では初回の確定している受注と、その後に続く未確定な受注を作成するようになっています。未確定な受注にはそれぞれ発送日が決められており、発送日にもとづいた締日に未確定受注は確定受注へと切り替わります。基本的に未確定受注の情報についてはお客様自身で変更することができますが、確定受注の情報はすでに発送作業に入っている可能性があるため、変更することができません（お問い合わせでの対応はできます）。
そんな未確定受注は、当初の意図通りにスキップ受注を表現することに使われています。また、受注は宛先住所などの情報も持っているため、一部の回だけ別の住所にお届けすることもできるようになります（年末は実家に帰っているのでそちらへお願いしますなどの要望がある）。さらに、スキップ分を含めた受注を数えるときなどの実装がシンプルになります。
しかし、むしろ未確定受注にはデメリットのほうが多くありました。実装する人にとってもお客様にとっても、仕様が複雑になりすぎるのです。
たとえばお客様が配送先住所を変更した場合に、未確定の受注については一緒に変更されていても、確定済みの受注は変更されず、変更前の住所に届いてしまいます。確定済み受注があることを強調して画面で伝えたとしても、実際にはそういった文言はあまり注意して見てもらえません。結果としてお客様の意図しない宛先に発送されてしまい、お問い合わせにつながってしまいます。
この宛先の情報が定期購入と受注とに分かれているのですが、未確定受注の情報は定期購入と連動して変更されるべきである一方で、確定受注の情報は変更しても大丈夫な場合と、変更してはいけない場合とがあり、実装者にとって大きな混乱のもととなりました。とはいえ冗長的に情報を持っていることはメリットとなる場合もあり、かんたんに切り捨てることもできずに残っています。
これに関してはあまり良い解決策が思い浮かびません。未確定受注という実装を活かしきれていないのかもしれません。
決済手段の追加と運用限界（2019年1月〜2月）
自社システム化から半年近くが経ちましたが、まだ運用コストの増大が本格的に顧みられることはなく、購入者数の増加を意図した施策が採られ続けました。「初回後払い購入」と「キャリア決済」の導入です。
まず「初回後払い購入」とは、初めてPOXを購入する人に限り決済情報の入力を後回しにして、まず購入を確定するという施策です。1つ目の定期購入が未決済のときに2つ目を購入しようとすると、決済情報の入力を促されて購入をすすめることができなくなります。また当初は、決済情報の入力がされていなくても1つ目の定期購入の1箱目のPOXを送付し、2箱目以降については締日に決済情報を確認してから送付するかしないかを決定するという流れになっていました。これは後に見直され、1箱目についても決済が完了していなければ発送しないようになりました。それでも8割を超えるお客様が決済を完了してくださっており、問題とはなっていません。
続いて実装された「キャリア決済」とは、ドコモ払い・auかんたん決済・ソフトバンクまとめて支払いでの決済が行えるようにする機能です。実装当初はじつは懐疑的だったものの（筆者はほとんど使ったことがなかったもので…）、現在は全お客様のうち3割以上が利用してくださっており、結果的にやってよかった施策でした。
ただ、キャリア決済は非常にコントロールするのが難しい性質のものでもありました。例えば決済対象の月と発送回数とが一致しない問題があります。キャリア決済では継続利用が始まった月からお支払いが発生するので、継続利用を開始した月に初回の発送がある場合（例：12月1〜10日までが受付期間で、25日に発送が行われる）では問題にならないのですが、継続利用を開始した次の月に初回の発送がある場合（例：11月26日〜12月5日までが受付期間で、12月25日に発送が行われる場合の、11月26〜30日にキャリア決済で購入された場合）には、開始月と翌月の2回の決済が行われた後に初回の発送が行われることになってしまいます。
問題ない場合
- 12月2日に購入（12月分の支払いが発生） → 12月25日発送分に当たる
問題ある場合
- 11月26日に購入（11月分の支払いが発生）
- 12月分の支払いが発生 → 12月25日発送分に当たる
このような二重決済を防ぐため、現在は一度行われた決済を取り消す処理を行っていますが、仕組みとして無理やりな感じは否めません。運用上でも実装上でも障害対応中にも常に「どの決済がどの受注分なのか」を意識しながら対応を行う必要があり、複雑さが足かせとなってしまっています。
また、先述の通りPOXは受注をスキップすることもできるので、対応する受注分の継続決済も取り消す必要があります。お客様の決済に関わる箇所ということが、さらにシビアな対応を要求してきます。利用者の割合が大きく実りの多い施策ではありますが、安易な気持ちでは手を出さないほうが良いと思います。
さらに注意点として、キャリア決済は、サブスクリプションモデルにありがちな一括購入（最初に一括で半年分や一年分の利用料を支払ってもらうことで、値下げを行いつつ継続率を上げる施策）との相性が非常に悪いということも留意しておくべきでしょう。各キャリアの継続決済では、初回に一括で支払って一定月間請求しないということができないはずです。
一定期間の請求を取り消すこともたしかにできますが、取り消す前に一度請求がかかってしまうため、一時的なお客様の負担が大きくなってしまいます。予期しない請求にお問い合わせも増加することでしょう。一括支払い分を分割して継続請求していくこともできますが（それはもはや一括購入なのかと思いますが）、途中でお客様がキャリア側の継続利用契約を解除することができるため、結果的に割安で購入されてしまうリスクが生まれてしまいます。一括購入は、キャリア決済では行えないようにするのが良いでしょう。
さて、立て続けに採られてきた購入者数増加施策の結果、この頃には月間の発送数が5000箱を越え、これまでGoogleSpreadSheetで行ってきた発送に関わる作業に本格的に限界が見えてきました。ここに来てようやく運用コスト削減が意識され始めました。
商品割り当て作業のシステム化（2019年3月〜10月）
運用コストのうちの大半を締めていた発送関連の作業は、以下の流れで行われていました。
- 受注の情報を集めてくる（自社システム、外部カートシステム、その他）
- 発送作業に使用する商品を決定する
- 各受注に商品を割り当てる
- 箱詰め作業
- 発送作業
- 発送伝票番号の取得
中でも商品の割り当ては、各受注の詳細情報（コース種別、アレルギー、要望など）を考慮しながら行うもので、すべてを機械的に割り振るのが難しい部分でした。とはいえ9割方の受注についてはパターンに当てはめられるものだったので、残り1割は人間の作業として割り切ってしまい、半自動的な商品割り当て機能を目標に実装を進めることにしました。
そうなると当然ながら、割り当てに使用する商品と在庫状況の管理も自社システムで行わなければなりません。また在庫を共有している都合上、外部カートシステムの受注もCSV形式で自社システムへ取り込む必要が出てきます。まずはそこからということで地道に実装していき、やがて4ヶ月後の7月ごろには自動商品割り当てロジック、手動で割り当てを行う画面、発送作業用CSVの出力機能などが出揃ったことで、少しずつ作業担当者の残業時間も削減されていきました。
こうして当初の目論見は果たされたわけですが、ついでに嬉しい効果もありました。実装上、受注とその情報を持った別のモデル（「発送」と呼んでいるもの）を用意していたのですが、受注情報から発送を作成することで、「この受注はすでに発送作業に入っている」という意味合いを与えてやることができました。また、有効な全受注を対象に作業を行わず、作成された発送モデルだけを対象に作業を行えばいいので、予期せぬ情報の更新（お客様によるマイページでの変更など）が起こることもありません。さらに作業を行うタイミングで新規作成しているため、作成時期ごとに分割してCSV出力してやることで、実際の発送作業側への依頼を分割して出すことも可能になりました。この頃には外部の倉庫会社へ梱包作業を委託していたのですが、「いっぺんに1万件の依頼が来るよりも、分割して少しずつ依頼をかけてくれたほうが嬉しい」といった要望に応えやすい構造になっていました。
ともあれ、こうしてPOXの発送作業は今や月間3万箱の発送に耐えるものとなったのです。
- 企画：GoogleSpreadSheetなど（自社オリジナル商品の企画）
- 商品の仕入れ：GoogleSpreadSheetなど
- （新規／継続）受注：外部カートシステムと自社システム
- 決済完了：外部カートシステムと自社システム
- 受注ごとに詰め込む商品を決める：自社システム
- 商品箱詰め：外部倉庫に依頼
- 発送：外部倉庫に依頼
- お問い合わせ対応：自社システムの問い合わせフォームと電話、メール
- 会計処理：自社システム出力のCSVとGoogleSpreadSheet
実装の効率化とお掃除の期間（2019年11月〜）
さてここまでで、運用フローはかなりの部分が自社システムで締められるようになってきました。残るは企画、仕入れ、お問い合わせ対応、そして会計です。このうち、発送箱数の増加に比例して作業が大幅に増加するのはお問い合わせ対応です。また、少しの工夫で大きな効果が出やすいのも、お問い合わせにつながってしまうようなわかりにくさの改善でした。2019年の11月から年末にかけては、こういった細部の改修や、今まで細やかに対応できてこなかったアラート、あるいはインフラ面での心配事などに（やっと）工数を割くことができました。
運用担当者が、発送作業にかかる工数がある程度減少したことで、現状を冷静に分析できるようになってきたのもこの頃からです。そういったモチベーションを支え続けるために、お客様の行動やお問い合わせの内容に関する情報を提供することも、運用改善のために重要なシステム側の対応として行うことができました。それ以前にも情報を出すことはあったのですが、ほか作業で手一杯の忙しいときに情報を出されても、考える時間を持てないのは残念ながら当たり前ですよね…。
ともあれ、次の運用改善やシステム改修に向けた準備期間を、自社システム化から1年半が経ったここにきてやっと、しっかりと持つことができたのでした。
そのほかPOXでやってきたこと
歴史を振り返ったところで、その他にやってよかったことなどを紹介していきます。
やってよかったこと
FAQページの充実
当たり前の話ですが、FAQページが救うことができるのは、FAQページを見てくれるお客様だけです。たまに喧嘩腰でのお問い合わせをされるお客様もいます。しかし、そういった方々の中にも、FAQがあればそちらを見てくださる人がいます。FAQページには、そういった人たちが喧嘩腰になるのを防ぐ効果があります。
また、お問い合わせを受けた際に「FAQページのこちらの内容になっておりまして…」という案内を出すようにして、対応をある程度パターン化することもできます。こうすることで対応工数を減らすことができ、さらに対応のサイクルが見えることで改善の糸口を掴むことにもつながります。
このように良いことずくめなので、FAQページはぜひ用意しましょう。
お問い合わせページ
お問い合わせページを自社ドメイン内に持つこともまた重要です。外部アンケートフォームや自社ポータルの問い合わせフォームを利用しても良いのですが、そちらではお客様や定期購入の情報と、お問い合わせとを紐付けることが難しくなります。定期購入などのIDをお客様に入力してもらうこともできますが、とくにお怒りであるお客様は、入力してくださらないことのほうが多いでしょう。もし入力してくださったとしても、番号を自社システムのOPEで検索する必要があります。それよりは、最初からお客様のお問い合わせ情報から直接リンクされていることのほうが、毎回のお問い合わせ対応の手間は減るはずです。
大きな手間でもないので、ぜひお問い合わせページも個別に用意したいですね。
操作ログ
お客様や運用作業者が、定期購入や受注などの情報をいつどこから変更したのかという情報は、お問い合わせ対応の担当者から要望されることが多いものです。実際、お客様が自身で変更したことを忘れてしまってお問い合わせをいただくこともしばしばあります。そういった場合に「システムのほうで記録が残っておりまして」という言葉は非常に強力なキラーワードとなるようです。そしてそれを言うためには、「誰がいつどこで操作したのか」の記録は閲覧できるようにしておく必要があります。
とはいえ、そのときのたった1件（としかエンジニアからは見えない）のために、全顧客の全操作をログに残すのはナンセンスだなあ、とエンジニアは考えがちです。筆者もそう考えていました。
しかし実際に実装してみると、払った工数に対してお問い合わせ対応の時間削減効果は多大でした。またそれ以外に、お客様の行動が記録されているということは、マーケティング担当者にとっても有意義なことだったようで、システムが送信しているメールのログと一緒に閲覧できる画面を用意してあげることで、メール受信が与えるお客様への影響を測ることができるようになりました。また、障害対応を行う際の材料として、エンジニアが利用することもあります。
ということで見た目には地味ですが、一石三鳥の効果を持つのが操作ログでした。これにはまだまだ利用シーンがありそうな気がします。
処理の非同期化
sidekiq や delayed_jobs で行う背後処理の実装は当初はありませんでしたが、最終的にOPE画面にとっては必須のものとなりました。たとえば受注などの情報を出力する際に、その件数が増えてくるとどうしてもタイムアウトしてしまうようになります。制限秒数の上限を延ばしたとしても、それは一時的な対応にしかなりません。素直に背後処理にしてしまうのが良いでしょう。
背後処理にしてしまうと、いつ何が始まって終わったのかがわかりにくくなってしまいます。そのため、POXでは運用担当者のチャンネルに背後処理の開始終了を連絡するbotを追加しました。こうすることで、操作を行った人がフィードバックを受け取れるようになり、安心感につながります。また、なかなか開始しない背後処理について自主的に気づき、システム担当者へ連絡してくださるようにもなりました。システム担当者が自分でそれに気づくこともあります。
背後処理の実装時には、ぜひSlackなどへの通知もあわせて追加してみてください。
未だにできていないこと
できていなくてもまだなんとかやってこれていること。
テストの充実
めちゃくちゃ怒られそうですが（誰から？）、POXには、クリティカルな部分以外のユニットテストが存在しません。しかし、コード量の増加に伴ってそのことによる弊害が増えてきたのもまた事実です。やっと守りの対応ができている今の時期に、思い切ってユニットテストを追加していくべきなんだと思っています。
ブラウザでの自動テストもまた存在していません。こちらは開発に並行して改修し続ける運用を回せる未来が見えていないために、2020年も着手できない気がしています。重要性はわかってはいるんですが…。
会計系機能
こちらに関しても、発送した箱の数や各商品の在庫数をCSV形式で出力する機能だけにとどまっています。
まとめ
いかがでしたか？ サブスクリプションモデルのシステム開発の一例をご紹介しました。じつはこの記事は、社内のWikiに書き残した個人的な振り返りがベースになっています。公開用に書き直す上で細かいことや退屈な内容はなるべく記載しませんでしたが、そういったものも含め、何が必要で、何が必要でないのか、また何をやるべきで、何をやらないほうが良いのかを整理する意味でも、個人的には有意義な振り返りができたと思います。次に同じようなシステムを用意する際にはもっとうまくやれることでしょう。読んでくださった方の何らかの参考になれたなら幸いです。良い2020年にしましょう。それでは。
2018年を振り返る
知る人ぞ知る、毎年恒例のその年を振り返る記事です。 前年末の目標の結果発表と、次年の目標を立てるだけの内容です。
↓去年の。 mizunokura.hatenablog.com
さっと目標の結果報告
「イタリア語を続けて勉強する、あわよくば翻訳も」といったような目標を掲げておりました。 イタリア語の学習は現在も続けていて、ゆっくりとではありますが身についてきている気がします（語学系ってあんまり「できる」って実感わかないですよね）。
翻訳のほうは、じつは過去に漫画を1本やっているんですがそれは今年ではありませんでした。 イタリア語が原版で、そこから英語に翻訳された書籍の、そのさらに日本語への翻訳作業はやりまして、その際にイタリア語原文を当たったりはしましたが、それで翻訳したと言うにはややずるいかもしれません。 翻訳結果については、おそらく近々発表します。
イタリア語の学習モチベーションのためもあって、イタリア語や、イタリアそのものに関する書籍や番組をよく読みよく見た1年間でした。 以下に面白かったものをいくつか紹介します。
書籍
- 作者: 内田洋子
- 出版社/メーカー: 方丈社
- 発売日: 2018/04/06
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
イタリア山中のある村をテーマにした書籍です。かつて関所として堅い「守り」を領主に提供していた村が、その必要性を失い、野外へ労働力を売り出して石を運搬し、やがて混迷するイタリアにおいて聖なる御札や聖書を売り歩くようになり、ついで書籍や、さらに後の世の禁書販売にも目をつけ、現代まで伝わる書店の礎となった物語が描かれています。
- 作者: 藤沢道郎
- 出版社/メーカー: 中央公論社
- 発売日: 1991/10/01
- メディア: 新書
- 購入: 4人 クリック: 19回
- この商品を含むブログ (18件) を見る
中公新書の「物語 〇〇の歴史」シリーズはいずれも読みやすさ・面白さ・わかりやすさにおいて優れたものが揃っているのですが、このイタリアの歴史はその中でも特に気に入りました。イタリア半島とシチリア、サルデーニャを舞台に、歴史の流れそのものを説明するのではなく、各時代の人物にスポットライトを当ててその生涯を描くことで、よりドラマチックに、臨場感溢れる生き様が伝わってくる内容になっています。
- 作者: 弓削達
- 出版社/メーカー: 講談社
- 発売日: 1989/10/20
- メディア: 新書
- 購入: 1人 クリック: 11回
- この商品を含むブログ (29件) を見る
かつてイギリス、スペイン、フランス、ドイツ、ハンガリー、北アフリカ、エジプト、中東、メソポタミア、アッシリア、アルメニア…などなど、広大な版図を有したローマ帝国が、どうして滅亡するに至ったのかについて述べた著作です。地中海世界としてまとまることなく、結局は分裂してしまった帝国には何が足りなかったのかを考えるにつけ、現代に生きる私達の生き方についてより考えさせられる内容でした。
番組
マッテオ・インゼオさんと日本人のゲストが、イタリアを歩きながらイタリア語を勉強するという内容の番組です。現在のゲストは俳優の田辺誠一さんで、北イタリア（トリノ、ミラノ）の自動車やファッションにふれる旅をしています。
毎回日本語のナレーションつきで、その人を主人公として、世界の街を散歩する、という体（てい）の内容の番組です。主人公は日本語ですが、相手の返事は現地語で字幕がつくので、リスニングの勉強に役立てています。またこちらはAmazonPrimeビデオでも視聴できます。ローマ、ボローニャの回が配信されていて、とてもおもしろいですよ。
で、来年の目標
ここからは、「誰に向かって言ってるんだろう、どこに向かって行ってるんだろう」のコーナーです。
イタリア関係
来年はもう一度イタリアに行こうかなと考えています。今度は主に南イタリアへ。カゼルタにもまた行きたいな。そしてそれまでにはもっと喋れるようになっておかないといけないなと思っています。あ、州の名前と場所は覚えました！
積読消化関係
年末に分析哲学に呼ばれたので、そこに再入門しています（はじめて呼ばれたと思っていたのですが、15ぐらいの頃に一度触れていたものがじつはそれでした。呼び方を知りませんでした）。
別記事で詳細に述べるかもしれませんが、ここ数年は物事の論拠を客観的事実に依っていたところを、主観的感覚とのバランスをとる必要があるなと感じています。そういうわけで、意識してそうすると思います。
というわけで、みなさま良いお年を。
人間扱い
ある時、友人と池袋の中華料理店で食事をしていたところ、そこにあったテレビではバラエティ番組が流れていた。それがやがてCMに切り替わり、友人が言った。「日本のテレビは番組とCMとの区切りがなく、急に切り替わる。これは悪いと思う。見ている人を人間扱いしていない」と。
正直ピンと来なかった。というのも、「今からCMが始まります」と言われても、その逆に急にCMに切り替わっても、いずれにしろ僕らは同じようにテレビをじっと見ているだろうからだ。間に予告があろうとなかろうと、ただテレビの映像を視聴し続けることに変わりはない。もしCMが嫌ならいったんテレビから目を離せば良いが、それもまた、予告があろうとなかろうと変わりないと思ったのだった。
コンビニにて
それから数日後、コンビニで、自分の前の客が店員さんに対して終始無言を突き通すのを見かけた。品物を出して、バーコードを読み取ってもらい、合計金額を告げられたら、お金を出して、店員さんが商品を袋詰めするのを待ってからそれらを受け取って、店を出る。確かに無言で済ませることができる。
一見すると乱暴な態度の客にも思えるが、もしかしたら店員さんもそのほうが楽なのかもしれない。そのときにはそんなことを考えた。
路上にて
また別の日、やや狭い路上で、女子大生風の3人組とすれ違うことがあった。向こうは道幅いっぱいに広がり、完全に対抗する自分の進路を塞いでいる。しかしこちらを見ることもなく、気付いているのかいないのか、結局こちらが街路樹の植え込みに踏み込んで、かろうじて避けることができた。彼女たちは歓談しながら過ぎ去っていった。
東京のような人口の過密した場所では、必ずしも誰もが自分の都合を考えてくれるはずがない。そんな場所で相手のことを考えていると不平等だし、相手の都合を考えて行動していたら、それが自分の不都合になってしまうこともまたあるだろう。だから、彼女らのように他人に対して無関心な態度を貫くほうが、ここでは上手くやっていきやすいのかもしれない。そのときはそんなことを考えた。
飲食店にて
今日、飲食店で、自分の持ち帰りの注文ができあがるのを待っていたところ、店員さんがレシートの番号を呼び上げた。自分の番号ではなかったのでそのまま観察していると、店員さんが二度三度、続けて声を上げた。しかし、それでも誰も受け取りに来なかった。それから四度目でやっと親子がやってきて、袋を受け取ったのだが、店員さんが「○○番のお客様でしょうか？」と尋ねるのに対し、親子はひったくるようにして無言で袋を取ると、そのまま立ち去った。
ここで、友人の言葉を思い出した。
人間扱いしていない
思い返せば、コンビニの無言の客も、3人組の女子大生風たちも、飲食店の親子もみな、他人を人間扱いしていない。テレビが突然CMに切り替わるのも同じことだ。相手の存在や、発する言葉、やりとりをあえて無視している。そのほうが自分に考えるべきことが少なく、かつ（相手の配慮のおかげによって）自分のしたい作業の流れが妨げられることもないので、自分にとっての都合が良いからだ。
自分さえよければ、相手がどうだろうと構わない。それが「人間扱いしない」ということだと、ようやく気付いた。
そしてそれ以来、「果たして自分は人間扱いされているだろうか」ということに意識が向くようになった。
「ごめんなさい」は失礼か
「ごめんなさい」は目上の相手に使うべきではないという話をしばしば耳にする。
ある界隈では、「ごめんなさい」は目下に、「すみません」は目上に使うべきだとされているらしい。曰く「『ごめんなさい』の『ごめん』は許諾を、『なさい』は命令を意味するため、「許しなさい」という言葉に由来するからだ」ということらしい。
また別の界隈では、「ごめんなさい」はその場で謝って取り返しがつくようなことに対して使い、「すみません」はもうどうしようもないことに使うべきだとされているらしい。曰く「『すみません』は『もう謝っても済むことではありません』だから」ということらしい。
そんなこと考えて使ってる？
いずれも、文法や由来を理由に「使ってはいけない」「正しくはこう」というルールを説明しようとしている。しかし、普段私たちは、言葉を使う際に文法や由来など気にかけているだろうか。たとえば、「こんにちは」は「今日（こんにち）はご機嫌いかがでしょうか」の省略が由来*1なので、言われた相手は機嫌について答えなければならないなどと、考えたことがあるだろうか。自分はない。
また、「幸」の漢字はその由来が「手かせをされることを免れた人の姿」とも「男女の性交の様子」とも言われていて諸説あるが、はたしてそれと意識して使っているだろうか。幸子さんはそう意図して名付けられているのだろうか。決してそんなことはないはずだ。
「絆（きずな）」という言葉の由来（動物を繋いでおく綱）を持ち出してきて、「絆という言葉を使う人々のことが気に入らないと思っていたが、その理由がわかった」などという言説が Twitter において流れていたが、それについても、「絆」という言葉を使うその人々が「動物をつなぐ綱」だと意識して使っていない限り、そういった人々について嫌な感情を持つことと言葉の由来とはまったくの無関係であって、その「理由」は的外れだと言わざるを得ない。
大切なのは由来や文法ではない
つまり何が言いたいかというと、「使ってはいけない」「正しくはこう」と言いたい人がそう言ってしまうのは、文法的におかしいからとか、由来がどうこうだからではなく、単にその人にとって気に入らないからだということだ。その理由は様々だと思うが、言葉が耳慣れないように感じるということや、今までの習慣と外れるのが嫌だということ、その他に、言葉はともかくそもそも相手自体が気に入らないということもあるだろう。
いざ気に入らない他人の行動をやめさせたいが、ただ「嫌だからやめろ」と言うのでは、不服を唱えられたり、いかにも自分の権力を振りかざしているようで具合が悪かったりするのだろう。そこで初めて文法や由来が持ち出されてくる。文法や由来に照らし合わせることで、それが大勢のように思われてきて、相手の納得を得られやすいうえに、自分の直接さが目立たなくなる。姑息な（その場しのぎの）手段が利便性ゆえに常套化したのではないだろうか。
自分の目的を見誤るな
しかし言葉は決して、相手の行動を束縛したり、相手との関係性において優位に立ったり（マウントを取ったり）、攻撃したりするためだけに存在するのではない。言葉は道具であって、それが使われる際には使う人の伝えたい意図があるはずだ。
「ごめんなさい」は、単純な謝意であることが大半だ。もちろん言い方によってはそうではないこともある。しかし、それに由来や文法は関係ない。謝意以外のものを感じ取った際に言うべきは「ごめんなさいを使うな」ではなく、「不満があるなら言ってみて」や「心から謝ってほしい」であるはずだ。もしも相手の言葉に心からの謝意を感じたのであれば、素直にその気持ちを受け止めるべきだ。「ごめんなさいは、由来からしてふさわしくない」などと言うべきではない。
「絆」を使う人々に対して言うべきは「そんなに浅い関係性を、自分は絆と呼びたくない」ということであって、「絆という漢字は〜」といった、言葉狩りに繋がりかねないような持って回った講釈ではない。場合によっては素直に「お前らが気に入らない」と言うべきだ。
じゃあ「サーセン」でいいのかよ
だからといって、もし「気持ちがこもっていればいいなら、どんな言い方でもいいですよね」と感じたなら、それは自分本位が過ぎるように思う。たとえば「『ごめんなさい』の代わりに『サーセン』と言ったっていいじゃん」という気持ちは、はたして「ごめんなさい」で伝わるのと同等かそれ以上の謝意なのだろうか。意図が伝わるのなら、深く頭を下げて「サーセンした！！！！！」と言ってもいいとは思う。しかし「じゃあそれでいいじゃん」としてしまうのは、誠意の欠如が相手に伝わってしまうのではないだろうか。
言葉は一方が発信しただけでは意味がなく、受け取られて、理解されて初めて意味があるものだと思う。受信側の素直な受け取りや理解はもちろん必要だが、発信側にも、より意図が伝わりやすい言葉の選択が必要だ。「サーセン」と「ごめんなさい」とのどちらがより自分の意図が伝わりやすいか、考えるべきだと思う。
それをもって、もっと素直な世の中になればいいのに、などと思う、最近。
*1:もちろんこれにも諸説あります
鎌でガラスを掻く
2年ぶりに海で泳いだ。場所は南紀白浜が白良浜（しららはま）。『白い砂浜に青い空』という情景描写がお世辞抜きにそのまま当てはまる海だった。朝から出かけて、体が熱くなったら泳ぎ、疲れたら休み、日が落ちる少し前に旅館へ戻った。そしてその結果、脚が猛烈に焼けたのだった。
あとから聞いた話では、白良浜のように砂が白く海の透明度が高い場所では、海面での屈折や砂からの反射によって、海に浮かんでいるときのほうが日に直接照らされているよりも、日焼けが進行するらしかった。しかしそれはあくまであとから聞いた話なのでもう遅く、その日の夜、温泉につかろうとしたところを、両脚への激痛と後悔とが襲ったのだった。
平日だったこともあり、温泉内には他に誰もいない。「あ〜〜〜〜〜〜いて〜〜〜〜〜〜」などと呻きつつ、我慢して肩まで浸かった。そのまましばらく湯の中にいると、両脚の痛みに慣れはじめ、お湯からの痛みに耐えるという感じではなくなってきた。
そうしてやっと、あらためて周囲の状況を確認することができた。
ガラスのむこうにカマキリがいた。
4センチ程度の、まだ小さく若いカマキリだった。木製の窓枠の上に立ち、両腕のカマを使って、ガラス窓をひっかいていた。そうしているうちに、たまにとっかかりが見つかり、そのカマキリはガラス窓を登りはじめた。と思うと、次の瞬間窓枠に落ちる。なかなか諦めることなく、それを繰り返した。
カマキリにとって、このガラス窓は何だろう。自然界には存在しない人工物で、きっとこれまでの進化の過程の中でそれが存在した期間があまりに短く、種として適応することが未だできていない構造物。そのために、登りたくとも上手く登攀することができない物。そこに何かがあることはわかっても、全体像を掴むことすらままならない何か。
ヒトにとって、そういうものはあるだろうか。ヒトの腕ではうまく登れず、理解することもままならない何か。仮にそれがあったとして、幾人かはその存在に気付くことはできたとしても、人類全体としてその感覚や知識を共有できるだろうか。ここでは具体的に明らかにはしないが、最近評論を読んだ物事が、そのガラス窓と重なって見えた気がした。
カマキリの上方にはガがいた。
有翼のガは、このガラス窓をどう理解しているのだろう。カマキリとは違い、ガラス窓の上のほうに留まることができる。同様に、下方に留まることもできる。しかして、全体像は把握できるだろうか。その点について同じ性質を持つ木や岩と、どう違うのだろう。もしかしたら彼らの世界観では、いずれも「留まるもの」と呼ばれているのかもしれない。
もっと脚力のある虫、たとえばカナブンはどうだろう。ガラス面は無理でも、木枠の横辺を伝って上に登ることはできる。ぐるっと一周して空間を認識できるとしたら、彼らにとってのガラス窓は、「四角い道」なのかもしれない。もしかしたら飛んでぶつかることで、「面」として把握できるかもしれない。
ガラスの反対側にはヒトがいる。
ちょっとやそっと温泉に浸かったところで脚の痛みは引くわけもなく、またいくらか呻きながら湯をあがり、その場を後にした。
