なぜですか

書きたいと思ったことを書きます

短歌の話

2019年の末ごろから、1日1首というルールで短歌を作っています。今日(1月19日)でちょうど119首目。ここまで作ってきて、なんとなく思ったことを。

良い短歌

良い短歌ってどういうもののことなんでしょうか。自分の好みの短歌を仮に「良い短歌」とするなら、「読み手が追体験し、感情を共有できるもの」だと思っています。

読み手が追体験し、感情を共有できるもの

短歌は文字数が31文字と限られているので、意味や意図を説明し尽くすことができません。読む側もそれはわかっているので、自ずと言外のそれらを読み取ろうとするものだと思います。

シモーニデースの曰く「絵は言葉を使わぬ詩、詩は言葉で描く絵である」、ホラーティウスが詩論で曰く「詩は絵のごとくに(ut pictura poesis)」。これらの言葉は、詩が読み手の頭の中でイメージを描くものだということを示しているのでしょう。つまり、言外の意味や意図は、そのイメージの中、あるいはそれを見る主人公(読み手)の感覚の中にあるべきものだと思います。

このイメージが得られるような文は、かつて修辞学の述べた「エクフラーシス(ekphrasis)」すなわち視覚筆写であると言えます。それがデュナミス(dynamis)として成り立てば、読み手に主人公を理解させ、主人公に寄り添った追体験の結果、読み手が特定の感覚を得られる状態、つまりエネルゲイア(energeia)が成立する。言外の意味や意図を読み手に感じてもらうには、この状態を作り、イメージと追体験と共感を得る必要があります。

なかみがだいじ

ただ、それだけで良い短歌として十分かというと、きっとそうでもありません。たとえば短歌を作ることがお客にラーメンを提供することなのであれば、いろんな準備を経てラーメンを食べてもらえるまでが、短歌で言う追体験や共感が得られた状態を指すはずです。食べてもらうところまで行ってやっと、よりおいしいラーメンを食べてもらうこと、つまりより良いイメージや追体験や共感を持ってもらうことについての追求ができる。そして真に重要なのはその部分だと思います。

では良いイメージや追体験や共感とはそれぞれ何なのでしょうか。良いイメージは「エクフラーシス(視覚筆写)によりもたらされるもの」と書きましたが、つまりはそのままギリシア語源の通り、「はっきり述べる」ということだと思います。明確に述べられるからこそ、読み手は安心して具体的なイメージを掴むことができます。

具体的なイメージは、より具体的で鮮明な追体験を行うことを読み手に保証するものです。同じイメージを共有することで、読み手は、自分自身を主人公にしたり、あるいは書き手を主人公とした情景を頭の中に描くことができます。

それは実際の書き手や書き手の見たものとはほとんどの場合で異なりますが、視覚情報すべてを正確に叙述することは非常に困難で、31字ならなおのことです。それに、良い共感のために、書き手と読み手のイメージが完全に一致している必要はあまりありません。詩によって得られる共感は、あくまで読み手の想像する共感であって、その答え合わせをする機会はあまりなく、それでいて「良い短歌」は成立しているからです。

きっとそれが短歌

書き手は、31文字の言葉だけを自分の支配下に置いています。そして読み手側はそれを受け取って、自分の頭の中にイメージを思い浮かべる。そのイメージや追体験が二人の間で共通しているかどうかは別として、二人の間にうまれた感情が一致したり、近似したりするとき、そこに短歌の書かれる意味がある。それが短歌を通じての共感だと思います。

そして共感の中でも良いとされるのは、読み手にとってありふれていないもののことでしょう。読み手にとって今までにない感情、懐かしい感情、着目せず見過ごしてきた感情を呼び起こすような短歌が、良い短歌なのではないでしょうか。

そういう短歌が作れるようにもう少し続けてみて、そのうち気が向いたらどこかに発表してみようと思います。それでは。

インターネットでの身の守り方

「インターネット」とは何でしょうか。「パソコンを使ってWebサイトを見たり、動画を見たりするやつ」というのは、インターネットを表した言葉のひとつと言えます。そこでまた別の見方をしたとき、インターネットとは「時間や場所を超えるもの」とも言うことができます。

時間と場所を超えるもの

ピンと来づらいかもしれませんが、インターネットを使って日頃やっていることは、インターネットを使わずにやっていることと、じつは大きく違いません。 Amazon楽天を開いてしていることは、インターネットを使わずにお店に出かけていってやっている買い物ですし、Youtubeで見ている動画は、スマホの録画を直接見せ合うことや、映画館で映画を見ることと同じです。

インターネットが持つ、インターネットの外との最大の違いは、それがいつでも・どこでもできることにあります。それがつまり「時間と場所を超えること」なのです。これはインターネットの利便性に直結し、さらに危険性にも直結する特徴です。

インターネットの危険についての考え方

インターネットの危険性は上で説明した特徴をそのまま反映するものであり、つまりそのために起こる危険に対処すること防ぐことができます。具体的には以下に説明します。

現実と変わらないということ

インターネット上での行動は、現実と同じ程度に安全であり、同程度に危険でもあります。つまり、危険な場所での行動は慎むべきですし、安全な場所での行動をなるべく心がけるべきです。安全性が判断できない場所での行動は避けるべきです。

接する相手についても同様です。危険な人物ではなく、信頼できる相手とのみ接するようにしましょう。また、そのどちらかの判断がつかない相手に対しては、決して油断しないようにしましょう。

時間と場所を超えるということ

インターネット上での行動は、時間と場所を越えます。つまり、ある情報がいつ、どこで見られているかはわかりません。さらに、多くの場合誰に見られているかもわかりません。

たとえば今あなたがSNS上でした発言が、数年後、予期せぬ人物(例えば数年後のあなたのことを理由もなく一方的に憎み、殺害を企図している人)に見られる可能性は十分にあります。

インターネットでの危険とその対策

情報漏洩

情報漏洩とは「その情報の持ち主が意図しない範囲の人間が、その情報を知ってしまうこと」を意味します。どんな情報についても、それを開示するにあたっては、信頼できる相手・場所かを判断するようにし、それが信用できる相手や場所だったとしても、入力する機会は極力減らしましょう。

個人情報には、氏名や住所、写真などはもちろんのこと、Eメールアドレスや会員番号など、氏名や住所に紐付いて個人を特定することができる情報すべてを含んだもののことです。あなたの個人情報はもちろん、他人の個人情報についても、インターネット上に公開する際には細心の注意をはらいましょう。

ちなみにメールアドレスと性別とを紐付けた情報は、1件あたり1000円程度でやりとりされているそうです。

情報漏洩の対策

原則は、「信頼できる相手、場所にのみ情報を開示すること」です。それが難しい場合は、「誰に知られても良い情報だけを開示すること」を意識しましょう。

情報は、あなたが情報を取り扱うすべての場所から漏洩する可能性があります。つまり、買い物をするショッピングサイトや発言を行うSNS、閲覧するだけのWebサイト、およびPCなどの端末そのものの中です。

偽名を名乗る

インターネットでのみ使用する名前を持ちましょう。これはいわゆる「ハンドルネーム」と呼ばれるものと、偽の氏名・住所・性別とがあります。

ハンドルネームについては持っている人が多くいることでしょう。インターネットで使用するあだ名を考えて、Twitterなどの名前として使用します。ローマ字で表現できる名前にしておくと、海外のサービスを利用する際の利便性があがります。また人と重複しづらい名前にしておくことで、登録時の煩雑さ(勝手に重複回避用の数字を入れられるなど)を防ぐことができます。また、ハンドルネーム内に個人情報を推測できる情報(誕生日の数字4桁など)を使用するのは絶対にやめましょう。

偽の氏名・住所・性別などについては、信頼性の低いショッピングサイトやその他Webサイトにおいて、理由もなく個人情報を求められた際に使用するもので、予め考えておくと便利です。また、その際の決済手段などは、クレジットカードではなくWebマネーなどを使い、お届け先も最寄りのコンビニを指定するなどして、相手に一切こちらの本当の個人情報を渡さないように心がけましょう。

複数のメールアカウントを使い分ける

メールアカウントは複数持ちましょう。一つは信頼性の高いWebサイトなどで使用するためのもので、他方はそれ以外です。メールアドレスのユーザー名、署名欄などに、氏名や誕生日などの個人情報を使用しないようにしましょう。

SNSなどのアカウントと個人を紐付ける情報を開示しない

TwitterInstagramのアカウント名、プロフィール、投稿内容に、個人の氏名や住所、性別、顔などや、それらを推測できる情報を掲載するのは避けましょう。可能であれば、公開範囲を「友人までに限定する」などの設定をしておきましょう。

投稿内容について、以下の内容からでも行動範囲をある程度特定することが可能です。

  • 選挙区や候補者
  • 天気や地震
  • 部屋の間取りの情報
  • 夜間にサイレンが鳴っていた
  • よく行く店

実際の自分の行動に紐づくような情報の開示は、それだけで危険です。「いついつ旅行に行くんだ」という情報は、その間留守にしているということを意味します。住所を知られていたら何が起きるかは、想像に難くないでしょう。

また、誤解されがちですが、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箇所で情報漏洩が起きてしまっただけでも、その他すべてのサービスにログインできる状態になってしまいます。極めて危険ですので絶対にやめましょう。

パスワード管理アプリケーションを使用する

可能であれば、AppleGoogle の提供しているパスワード管理アプリケーションを使用するようにしましょう。複雑なパスワードを設定してくれ、さらに入力の手間も省けます。

また、One Password などのアプリケーションを使用することで、覚えておくパスワードを1つだけにすることも可能です。

情報漏洩対策を行う

前述の通り、アカウントの乗っ取りは情報漏洩によって起こります。それは多くの場合サービス側の不手際によることが多いのですが、自分で開示した情報から推測されてしまうこともまたあります。

氏名、アカウント名、誕生日などはパスワードに使用されることが多いものです。また、「秘密の質問」として設定されやすい内容(母親の旧姓や出身地名、好きなプロスポーツチームなど)も、第三者の目からは隠しておくべきでしょう。

共有のPCに情報を残さない

ホテルや図書館、ネットカフェなどで使用できる共用パソコンは便利ですが、自宅のパソコンと同じ感覚でそこにログイン情報を記憶させてしまうと、後から利用する人がそのままあなたのアカウントにログインできるようになってしまいます。パスワードなどの情報は絶対に記憶させず(「ログインしたままにする」機能の使用もやめる)、使用を終えて席を立つ前に、ブラウザの履歴も消しておきましょう。

ウイルス感染

インターネットの情報は、私達人間が直接情報をやりとりして見ているわけではありません。PCやスマホなどの端末が代理で情報を受け取り、その中身を私達が理解できる形にして表示してくれています。

その過程において、端末にあなたが意図しない動作をさせるような情報が送られてくることがあります。それは結果として、あなたの個人情報を誰かに送ったり、あなたのパソコンやスマホについているカメラに写った画像を送ったりします。

ウイルス感染の対策

アンチウイルスソフトをインストールする

基本中の基本です。これをせずにインターネットを使用することは、全裸でライオンの檻の中に入るようなものです。無料で使用できるものの中で個人的なおすすめは、SophosまたはESETです(あくまで参考です。何かあっても責任は負いませんよ)。また、必ず定期的なスキャンも設定しておきましょう。

AdBlockerを使う

ブラウザの拡張機能として、AdBlocker(広告ブロック)を入れておきましょう。広告以外にも、そのWebサイトが追加で読み込もうとしているさらなる他のURLをブロックしてくれます。AdBlocker を使っていると表示できないWebサイトもあるので、オンオフ切り替えながらの使用が前提になります。

怪しいURLを開かない

基本その2です。開くことで何が起こるかわかっているか、または絶対に信頼できるURL以外は開かないようにしましょう。仮に信頼できる人から送られてきたURLだったとしても、そのアカウントが乗っ取られている可能性もあります。不用意に開くことはしないようにしましょう。

怪しいメールを開かない

これも基本です。知らない人物や、身に覚えのない内容のメールは開かないようにしましょう。

怪しい記憶媒体を読み取らない

信頼できる外付けHDD、SSDUSBメモリや、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段)でした。

f:id:mizunokura:20200109031658p:plain

スタッキングシェルフは1区画の寸法が縦370x横370x奥行280mmなのですが、少し頑張れば、ここには文庫本を3列に並べることができます。さらにその上に20cmほどの空間が残りますが、ここにも平積みすることができます。

f:id:mizunokura:20200109030647p:plain

こういう感じでその他のスペースにも本が並んでいました。

また、なんとなく場所がわかれていたものの、漫画の区画や文庫の区画、単行本の区画、大型本や雑誌の区画などが混在している状態でした。この収納の仕方は、置いているだけで整理されているとは言えません。どんな本があるのかわかりづらいうえに、あることがわかっている本でも取りづらい。使い勝手が悪いことこの上なしです。

f:id:mizunokura:20200109030709p:plain

全体像はこんな感じ。ごちゃごちゃ。

追加した本棚

新たに追加でおけるスペースが1箇所あったので、そこに置く本棚をいろいろと見ました。そして最終的に、無印良品のスタッキングシェルフ(3x5段)を選びました。安くなっていたこともありまして。

さらに既存の本棚の上にもう1段追加できそうだったので、増設パーツも購入することにしました。そこにスペースがあったから仕方ない。中途半端な我慢が一番良くない。

豊富なオプションパーツ

ところで、スタッキングシェルフには豊富なオプションパーツが用意されています。それもまた追加購入の決め手でした。

半分の箱

f:id:mizunokura:20200109030742p:plain

見てください上から二段目にあるこの箱。ちょうどスタッキングシェルフの1区画の半分に入るような大きさになっているんです。するとこうできるんです。

f:id:mizunokura:20200109030808p:plain

じゃーん、横並び二段。

ブックエンド

これは正確にはスタッキングシェルフ用のパーツではないんですが、無印良品ではブックエンドも売られています。これを、今回は10枚購入しました。

f:id:mizunokura:20200109030821p:plain

中途半端な我慢が一番良くない。あとこれはそんなに高くない。これがあると本棚の上にさらに本が置けるんです。

どうなったか

f:id:mizunokura:20200109030844p:plain

こうなりました。スペースに余裕が生まれたので、本を整理することもできるようになりました。具体的には、

  • 本棚の上:イタリア関係
  • 最上段:言語・哲学関係
  • 二段目:岩波文庫・辞書ほか
  • 三段目:英語関係・雑誌・歴史・講談社学術文庫
  • 最下段:技術書・その他大型本・SF・小説

こんな感じで並んでいます。小説などはあまり読み返さないので、前後列での配置で妥協しました。

また、本の列の手前にスペースができたのですが、これも意外な便利さにつながっています。読んでいる途中の本や次に読もうと思った本、頻繁に手に取るのでいちいち出し入れしたくない本などをここに置いておけるのです。

マンガ本や雑誌などは、追加で購入したもうひとつの本棚に移動しました。その結果、場所がはっきりと別れて使い分けができて便利になりました。

これから

とはいえ今後も本が増えていくことは予想できます。そういうときには、無印良品のスタッキングシェルフ用オプションである曲がった鉄板を購入することで、本の列の上に文庫サイズの本を置けるようになるみたいです。

https://roomclip.jp/photo/v0cl

この方のような感じ。ただこれ3500円ぐらいするんですよね…。同じようなものが100円ショップにもあるんですが、そっちは横幅がスタッキングシェルフの1区画に対してぴったり合わないので美しくない。もしかしたら、先述した半分の箱を買い足すかもしれません(箱は2500円程度)。それでは。

なくそう、要件定義と思い込み

要件定義は無くすことができる

そうなんです。要件定義はなくすことができるんですよ。

そもそも要件定義はなぜ必要か

通常、開発手法のうちどれを採ったとしても、要件定義はほぼ必ず行われるでしょう。たとえばウォーターフォール型ならば要件定義→設計→実装→検証→リリースという手順を踏み、スパイラル型でも左記の手順を小出しに何度も行って品質を高めていくものです。やはり要件定義からは逃げられません。

それはなぜなのでしょうか。要件定義の目的は「いま何が問題になっているのか」をその問題の当事者から設計・実装担当者へ共有し、お互いのコミュニケーションを通じて「それをどう解決するか」についての共通認識を持つことです。それがあればこそ、問題の当事者の望む実装がただしく行えるのです。ここがおろそかであれば、最悪の場合リリースされても使われない機能が生まれることになります。きっと心当たりがおありでしょう(筆者にもあります)。

それなら自分が当事者になればいい

しかし、「いま何が問題になっているのか」や「それをどう解決するか」を知っている問題の当事者には、運用担当者やマーケティング担当者たちだけがなれるというわけではありません。設計や実装を担当するエンジニアが問題の当事者になることもまたできます。

問題の当事者になるために一番効果的なのは、実際のマーケティングや運用を担当することです。長期間担当し続ける必要があるかどうかは作業内容や難易度によると思いますが、問題点を把握するためにはこれが一番手っ取り早い方法です。次には作業を横で観察すること。そして次には、各作業担当者とのコミュニケーションを密接に取ることが挙げられます(要するにこれが要件定義です)。

ご覧の通り、ごく当たり前で様々な現場でしばしば見かける工夫です。しかし「何が問題で、どう解決すべきか」を正確に把握するという目的を念頭に置いていないのでは、全く意味がないことでもあります。そもそもそれを意識していても問題点や需要を正確に把握することは非常に難しく、自分以外の本当の作業担当者たちがどう考えどう操作し、どうなっていればもっと理想的なのか、その姿を想像する力や経験も多分に求められる作業です。それらの不足から、一人でわかった気になって、その先は無いものだと思い込んでしまうことが非常によく起こります(「自分は要件定義が得意だ」と思っている人は、大抵の場合これに陥っています)。

このことから、始めは「要件定義をなくす」ことではなく「要件定義の場をスムーズにする」ことを目的とし、「これやってみて思ったんですけど…」「このまえ横で観察してて気付いたんですが…」といった会話を切り出すための、切り札を集める感覚で現場に入っていってみるのが良いでしょう。

じつは普段何気なくやっていること

ところで、こういったことは普段何気なく実施しているものでもあります。特定の目的でシステムを構築する場合、絶対に必要になる機能がいくつか頭に思い浮かぶと思います。オペ画面であれば作業者のログイン機能や権限の管理機能は言われなくても必須ですし、決済系のAPIを構築する場合には、決済のログを数年単位で保管する仕組みや決済情報の安全な保存機構およびフローを用意する必要があります。

こういったことは、主に経験から「あれを作るのであれば、とくに新たに議論しなくても、言うまでもなく必要だ」と考えられるものです。同じように「こんな問題で困っているなら、とくに新たに議論しなくても、あれがあれば解決できる(はず)」という考えをもつこともまた可能です。こういう「言わずもがな」の積み重ねもまた、システムエンジニアにとって必要な要件定義の能力だと思います(実際、大工の親方や整体の施術士さんたちは、こういう考え方をしているような気がします。想像ですが)。

ただしこれらに気をつけろ

しかしこの方法にも注意点があります。先述しましたが、わかった気にならないことです。解決策の提示は、的確であればまったく問題ないのですが、ズレてしまっていてはただの思い込みです。ホワイトデーやクリスマスの翌日にメ○カリなどに大量に出品されているネックレスや指輪、あれが「思い込み」です。少しでも不安要素があったり、過去の経験が現在の事象にも当てはまるかわからないのであれば、素直に相談するのが良いでしょう(それで問題なかったのならそれはそれで失うものは無いのですから)。

それから、周囲にとって予期しないことをしないことも重要です。問題解決に効果的な機能だったとしても、たとえば全体に影響するスキーマに変更を加える必要があるだとか、実装工数がものすごくかかるだとか、自分一人でどうにかできる以外のリスクがある場合には、素直に周囲に伝えるべきでしょう。むしろ、普段の情報共有による信頼が、「これで解決できるはず」というあなたの考えや行動を後押ししてくれるものです。

要件定義はいつもそばにある

ということで、「要件定義は無くすことができる」という書き出しをしておきながら、じつは「要件定義は別の方法でもできる」という内容の記事でした。会議という方法だけにとらわれず、問題点の把握と解決策の発見という目的を忘れずに、普段から観察することが利便性の高いシステム構築の助けとなるはずです。もし思い込んでいる自分がいたら、一度落ち着いて周囲を見てみることをおすすめします。それでは。

サブスクリプション・システムの生活史

はじめに

この記事は、筆者が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クラスがリクエストを受け取る
    • ControllerクラスがOrderPresenterクラスをnewする
      • OrderPresenterクラスはnewされると以下を作成する
        • お客様の情報(User.new)
        • 定期購入の情報(Subscription.new)
        • 受注の情報(Order.new)
        • 決済処理モデルクラス(PaymentTransaction.new)
      • OrderPresenterクラスが決済処理モデルインスタンスの与信確保メソッドを呼び出す
        • 決済モデルインスタンスが外部決済サービス経由でカードの与信を確保する
        • 初回の受注の決済ステータスを「与信確保済み」に変更する

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年間でした。 以下に面白かったものをいくつか紹介します。

書籍

モンテレッジォ 小さな村の旅する本屋の物語

モンテレッジォ 小さな村の旅する本屋の物語

イタリア山中のある村をテーマにした書籍です。かつて関所として堅い「守り」を領主に提供していた村が、その必要性を失い、野外へ労働力を売り出して石を運搬し、やがて混迷するイタリアにおいて聖なる御札や聖書を売り歩くようになり、ついで書籍や、さらに後の世の禁書販売にも目をつけ、現代まで伝わる書店の礎となった物語が描かれています。

物語イタリアの歴史―解体から統一まで (中公新書)

物語イタリアの歴史―解体から統一まで (中公新書)

中公新書の「物語 〇〇の歴史」シリーズはいずれも読みやすさ・面白さ・わかりやすさにおいて優れたものが揃っているのですが、このイタリアの歴史はその中でも特に気に入りました。イタリア半島シチリアサルデーニャを舞台に、歴史の流れそのものを説明するのではなく、各時代の人物にスポットライトを当ててその生涯を描くことで、よりドラマチックに、臨場感溢れる生き様が伝わってくる内容になっています。

ローマはなぜ滅んだか (講談社現代新書)

ローマはなぜ滅んだか (講談社現代新書)

かつてイギリス、スペイン、フランス、ドイツ、ハンガリー北アフリカ、エジプト、中東、メソポタミアアッシリアアルメニア…などなど、広大な版図を有したローマ帝国が、どうして滅亡するに至ったのかについて述べた著作です。地中海世界としてまとまることなく、結局は分裂してしまった帝国には何が足りなかったのかを考えるにつけ、現代に生きる私達の生き方についてより考えさせられる内容でした。

番組

www2.nhk.or.jp

マッテオ・インゼオさんと日本人のゲストが、イタリアを歩きながらイタリア語を勉強するという内容の番組です。現在のゲストは俳優の田辺誠一さんで、北イタリア(トリノ、ミラノ)の自動車やファッションにふれる旅をしています。

www6.nhk.or.jp

毎回日本語のナレーションつきで、その人を主人公として、世界の街を散歩する、という体(てい)の内容の番組です。主人公は日本語ですが、相手の返事は現地語で字幕がつくので、リスニングの勉強に役立てています。またこちらはAmazonPrimeビデオでも視聴できます。ローマ、ボローニャの回が配信されていて、とてもおもしろいですよ。

で、来年の目標

ここからは、「誰に向かって言ってるんだろう、どこに向かって行ってるんだろう」のコーナーです。

イタリア関係

来年はもう一度イタリアに行こうかなと考えています。今度は主に南イタリアへ。カゼルタにもまた行きたいな。そしてそれまでにはもっと喋れるようになっておかないといけないなと思っています。あ、州の名前と場所は覚えました!

積読消化関係

年末に分析哲学に呼ばれたので、そこに再入門しています(はじめて呼ばれたと思っていたのですが、15ぐらいの頃に一度触れていたものがじつはそれでした。呼び方を知りませんでした)。

別記事で詳細に述べるかもしれませんが、ここ数年は物事の論拠を客観的事実に依っていたところを、主観的感覚とのバランスをとる必要があるなと感じています。そういうわけで、意識してそうすると思います。

というわけで、みなさま良いお年を。

人間扱い

ある時、友人と池袋の中華料理店で食事をしていたところ、そこにあったテレビではバラエティ番組が流れていた。それがやがてCMに切り替わり、友人が言った。「日本のテレビは番組とCMとの区切りがなく、急に切り替わる。これは悪いと思う。見ている人を人間扱いしていない」と。

正直ピンと来なかった。というのも、「今からCMが始まります」と言われても、その逆に急にCMに切り替わっても、いずれにしろ僕らは同じようにテレビをじっと見ているだろうからだ。間に予告があろうとなかろうと、ただテレビの映像を視聴し続けることに変わりはない。もしCMが嫌ならいったんテレビから目を離せば良いが、それもまた、予告があろうとなかろうと変わりないと思ったのだった。

コンビニにて

それから数日後、コンビニで、自分の前の客が店員さんに対して終始無言を突き通すのを見かけた。品物を出して、バーコードを読み取ってもらい、合計金額を告げられたら、お金を出して、店員さんが商品を袋詰めするのを待ってからそれらを受け取って、店を出る。確かに無言で済ませることができる。

一見すると乱暴な態度の客にも思えるが、もしかしたら店員さんもそのほうが楽なのかもしれない。そのときにはそんなことを考えた。

路上にて

また別の日、やや狭い路上で、女子大生風の3人組とすれ違うことがあった。向こうは道幅いっぱいに広がり、完全に対抗する自分の進路を塞いでいる。しかしこちらを見ることもなく、気付いているのかいないのか、結局こちらが街路樹の植え込みに踏み込んで、かろうじて避けることができた。彼女たちは歓談しながら過ぎ去っていった。

東京のような人口の過密した場所では、必ずしも誰もが自分の都合を考えてくれるはずがない。そんな場所で相手のことを考えていると不平等だし、相手の都合を考えて行動していたら、それが自分の不都合になってしまうこともまたあるだろう。だから、彼女らのように他人に対して無関心な態度を貫くほうが、ここでは上手くやっていきやすいのかもしれない。そのときはそんなことを考えた。

飲食店にて

今日、飲食店で、自分の持ち帰りの注文ができあがるのを待っていたところ、店員さんがレシートの番号を呼び上げた。自分の番号ではなかったのでそのまま観察していると、店員さんが二度三度、続けて声を上げた。しかし、それでも誰も受け取りに来なかった。それから四度目でやっと親子がやってきて、袋を受け取ったのだが、店員さんが「○○番のお客様でしょうか?」と尋ねるのに対し、親子はひったくるようにして無言で袋を取ると、そのまま立ち去った。

ここで、友人の言葉を思い出した。

人間扱いしていない

思い返せば、コンビニの無言の客も、3人組の女子大生風たちも、飲食店の親子もみな、他人を人間扱いしていない。テレビが突然CMに切り替わるのも同じことだ。相手の存在や、発する言葉、やりとりをあえて無視している。そのほうが自分に考えるべきことが少なく、かつ(相手の配慮のおかげによって)自分のしたい作業の流れが妨げられることもないので、自分にとっての都合が良いからだ。

自分さえよければ、相手がどうだろうと構わない。それが「人間扱いしない」ということだと、ようやく気付いた。

そしてそれ以来、「果たして自分は人間扱いされているだろうか」ということに意識が向くようになった。