t_wの輪郭

夜に賃貸物件の情報を探し、朝に問い合わせをし、夕方に内見するループを回していく。

ちまちま問い合わせして優良な不動産屋をつかむまで頑張るしかない

企業相手の問い合わせとかも、チャットボット相手に壁打ちさせてから人間のオペレーターが対応するようになんのかな

有給休暇の申請がシステム上でできなくなってる件の問い合わせ

　フォームから人事に問い合わせを送信した。一仕事終えた気分だ。顧客には何の価値も提供していないのに。

　いまさらになって自社のメールをチェックしたところ、yammerの投稿がお知らせとしていくつか飛んできていた。Clickbaitっぽいタイトルで釣ってこようとしてくる。「Surprise」、「BREAKING NEWS」、「Save the date」。自身の承認欲求のためにシステムを私物化している。いや、承認欲求ですらなくて、何らかの指標でそうせざるを得ないのかもしれない。悲惨だ。
　Yammerからくるメールは10割方仕事とは関係がない。社内コミュニティ系の内容だ。自動でゴミ箱に入れるように設定したいが、なぜかYammerからのメールは設定しても設定しても送られてくる。困惑。

　疲労感が強い。背中の疲労感。1日中機材の試験をしていた。職場の椅子と相性が悪い。

　2週間のサイクルで仕事をしているのだが、前回（初回）のサイクルと比較して、作業速度が3倍になった。かなり時間を余らせられる見込みで、余った時間で何をするかが問題になってきそうだ。余った時間で自動化できそうな作業は自動化してしまおう。そうするとまた時間が余るようになる。左うちわができるぞ。

　経費精算が差し戻されて、会社に失望した。いや、元々ダメな会社だと思っていたが、確信の度合いが高まった。会社の指示でドライバー保険に入ったのに、経費精算が通らないのは駄目だろう。上司を通して関係部署に問い合わせをかけているが、この会社の事務処理は本当に塞路化・硬直化しているので、というか労働者を舐めているので、訴訟したほうが早い可能性すらある。一度訴訟というものをやってみたかったところだ。それぐらいしないと仕組みや体質が変わらない気がする。とにかく経費精算が通らないのなら運転を伴う業務はボイコットするつもりだ。お客さんには迷惑をかけることになるが、一従業員から訴訟されるよりも、客から訴訟されるぐらいのほうが影響が大きいだろう。

　月額100円のPKMSを作りたい。企業内へのPKMS導入において価格がネックあるならば、安価なPKMSを作れば普及させられるはずだ。
　PKMSの低価格化を目指すには、雇用をほぼ一人に絞る必要がある。雇用を一人に絞ったとき、浮かび上がってくるだろうわかりやすい問題は以下が考えられる。

• セキュリティ対応
• 悪質な投稿への対応
• 問い合わせ対応

■セキュリティ対応
　セキュリティ対応に関してはセキュリティを低廉化し、セキュリティホールがあっても情報を漏らさない体制を作ることができればいい。極端なことを言えば、サーバーに配置されるデータがすべて暗号化もしくはハッシュ化されていればセキュリティホールによる情報漏洩リスクはかなりなくせるはずだ。
　パスワードをハッシュ化するように、メールアドレスもハッシュ化すれば個人情報漏洩リスクをさらに低減させることができる。なぜ一般的なサービスでメールアドレスをハッシュ化しないというと、利用者に対するメールによる連絡が目的だからだ。つまるところ営業活動が目的である。これをすっぱり諦めてしまえばかなり安全側に倒すことができる。また、パスワードの再発行に関しては、メールアドレスを利用者に送ってもらい、そのメールアドレスに対してパスワード更新のURLを送付することで実現できる。もちろんメール送信の際にはハッシュとの突合を行う。メール送付機能が悪用されることを防ぐためだ。メールアドレスもハッシュ化は悪質な利用者の停止にも対応できる。利用停止した利用者のメールアドレスのハッシュさえ持っていれば、同じメールアドレスでの再登録を防ぐことができる。
　E2EEのPKMSというのも魅力的な考え方だ。PKMSに入力されるデータは社外秘や個人情報になりうる。これらを平文で持たず、サーバー内では暗号化されていることでかなり安全になる。ただ、多対多のE2EEを実装するのはどうも難しいらしい。要研究だ。

■悪質な投稿への対応
　PKMSの投稿が一般公開されている場合、普及するにつれて悪質な投稿に対する対応というものが必要になってくる。この対応は必ず人の稼働という形でコストを必要とする。そうであるならば、一般公開されず、個人・チーム内で閉じた空間での利用に限定し、さらに月100円(仮決め。正直いくらでもいい。)を支払わせることで悪質な投稿による影響や、そもそも悪質な投稿がされる可能性を低減させられる。
　一般公開しないという方針は利用者が入力した情報が漏洩する危険性を発生させるが、E2EE化し、暗号化した情報のみをサーバに持たせるようにすれば安全にできるはずだ。

■問い合わせ対応
　検討中。正直なところどんな問い合わせが来るか想像がつかない。安定拡大しつつ、対応する資料や仕組みを整えるしかないかもしれない。可能な限り問い合わせが来ない体制にしたい。PLGの考え方が役に立つだろう。人が問い合わせに対応するのではなく、PKMS自身に問い合わせ対応させる。そういうことができればよさそうだ。Helpfeelが参考になる。