Site cover image

ふつうのITエンジニアの独り言

本業はAndroidとiPhoneのアプリ開発のエンジニアです。将来はフリーランスで海の近くで妻とのんびり暮らすことを夢見て、幅広くIT技術に触れていきたいと思います。このブログはその備忘録と私のポートフォリオとして活動記録を記すものです。

自分の死後に嫁や子どもにメッセージを自動で配信するサービスをタダで用意したい(その1) ~実現方法を考える~

目次


はじめに


 先日、妻と二人で出かけていて、ふと「今、二人とも事故に遭って死んでしまったとき、娘たちは生きて行けるのだろうか?」という話になった。おそらく、祖父母や親戚がサポートしてくれるから、生きていくことについては心配ないと思う。貯金や投資資産なども、まぁ調べればなんとかなるはずだ。でも、デジタルで保存されパスワードで保護された情報はどうなのか、Googleドライブに保存された数万を超える思い出の写真の数々を、娘たちは取り出すことができるのか・・・。

 そんな会話をしている中で、「死後に残された家族にメッセージを送れる仕組みがあったら安心できるよね。」という結論に至った。調べてみたところ、要求に合致しているサービスが既に存在することがわかった。でも、この為に毎月お金を払い続けるのは嫌だなぁ・・・というケチっぷりから、自作できないかと考えだした。

既存サービスを調べてみる


既存のサービスを調査したところ、çというサービスが有ることが分かった。月額110円、年額990円なので決して高いサービスではない。素直にこれを利用するのもありだが、エンジニアとして「無料で実現する方法を考えたい」という自己満足のために、これを利用することはしない。

lastmessageでできること
サービス 説明
ラストメッセージ発信 • メッセージや写真、動画を死んだときに配信
• 宛先はグループや個人に
秘密ボックス • 死んだあとに公開したい秘密情報を保存
• ラストメッセージと一緒に配信
アカウント情報を一括管理 ・アカウントとパスワードを紐づけ管理
・自身のアカウント管理が目的なのかな?
生存確認 • 定期的なログインでの確認
• 電話確認
聞き取る機能 ・家族間で聞きづらいことを確認し合うためのサービス
・質問事項を作成して、家族に書いてもらう

要件を考える


 自分が作りたいものを整理することで、開発するシステムの構成が見えてくる。まずは要件を基本の5W1Hで洗い出すことにする。

5W1H 要件
なぜ(Why) • 大切なことを大切な相手に残して置くことで、いつ何が起こっても大丈夫という安心感が得られる
• 死んだあとに大切な人が苦労しないように
だれに(Who) • 配偶者
• 子ども
• 両親
• 親友
どこに(Where) ・メールアカウント
・Line アカウント
何を(What) • 個人情報
 ◦ 本籍、経歴、家族構成、親戚連絡先
• 思い出
◦ 家族写真、動画、メッセージ
• 資産
◦ 保険、株式、投資信託、暗号資産、貯金口座
• 秘密情報
◦ PCログイン情報、各種アカウントとパスワード情報、口座暗証番号
いつ(When) • 死後の一定期間あと特定の操作がないとき
• 意識が戻らない状態となってから一定期間あと特定の操作がないとき
どうやって(How) • 定期的に生存確認をおこなう
その他 • 無料であること
• 利用するサービスが将来的に安定していること
• メッセージがセキュリティで守られていること
• 継続して利用者がメンテナンスしていく上で、わかりやすいUIであること

システム構成


 要件を出したので、これを実現できそうなシステム構成を考えてみる。

graph LR
  User[自分]
  TargetA[メッセージ送信先A]
  TargetB[メッセージ送信先B]
  TargetC[メッセージ送信先C]
  TargetD[メッセージ送信先D]
  TargetE[メッセージ送信先E]
  Check((生存確認))
  Conditions[(発動条件)]
  Mail((メール配信))
  messageA[(配偶者宛メッセージ)]
  messageB[(子ども宛メッセージ)]
  messageC[(両親宛メッセージ)]
  
  subgraph 配偶者グループ
	  TargetA
  end
  
  subgraph 子どもグループ
	  TargetB
	  TargetC
  end
  
  subgraph 両親グループ
	  TargetD
	  TargetE
  end
  
  subgraph メッセージ
	  messageA
	  messageB
	  messageC
  end
  
  subgraph 生存確認システム
	  direction TB
	  Check-.->|参照|Conditions
  end
  
  subgraph メール配信システム
	  direction TB
	  Mail-.->|参照|メッセージ
	end
  
  User--条件編集-->生存確認システム
  User--ログイン-->生存確認システム
  User--メールUMLクリック-->生存確認システム
  生存確認システム-->|定期生存確認メール|User
  生存確認システム--死亡トリガ-->メール配信システム
  
  User--編集-->メール配信システム
  メール配信システム-->|送信|配偶者グループ
  メール配信システム-->|送信|子どもグループ
  メール配信システム-->|送信|両親グループ
  
  subgraph 凡例
		direction TB
		Actor[アクター]
		Process((処理))
		Setting[(設定系)]
  end
ブロック名 要素 概要
生存確認システム 生存確認 自分の生存確認を行うための処理を行う。生存確認には、特定のURLクリックや管理サイトへのログインで生存確認する。
死亡判定となる条件が近づくにつれ、メールの配信間隔が短くなってくるなどで、生存確認漏れがないようにできる。
発動条件 メールの送信頻度の設定や、死亡判定となる条件を設定できる。
メール配信システム メール配信 死亡判定が確定したときに任意の宛先にメールを配信する。
メッセージ設定 宛先グループと、送信するメッセージの管理を行う。
メッセージは、写真や秘密情報を含める。

 システム構成を説明すると、自分が生きているのか死んでいるのかをシステムは判断する必要がある。もし生きている状態で、恥ずかしいメッセージが送信されてしまったらと思うと目も当てられない。なのでシステムは本人が死んだと判定する条件と、その条件を満たしたときにのみメッセージを発信できる仕組みが必要になると考えた。

 生存確認の方法としては、「生存確認システムに一定期間内でログインすること」というのが一番確実ではあるが、毎回ログインするというのは面倒くさい。となると、メール配信された中に埋め込まれたURLをクリックすることで生存確認が行えるというのが、面倒くさがりな私でもギリ許されるアクションではないだろうかと思う。もっというと、死亡判定に近づくにつれて、メールの頻度が増えてくるというのも良いかもしれない。直前に一回だけしか送られないと、気付かないということも考えられる。そういった自体を避けるためにも、メールは何度か送信されてもらわないと困る。

 メール配信システムでは、死後に送信したいメッセージを管理し、死亡判定がくだされたタイミングでメッセージを任意の相手に送信できるようにする。そのためには、誰あてに送信したいかを設定でき、送信するメッセージも宛先に応じて編集したい。

実現方法を考える


生存確認システム

 定期定期に自分宛てにメールを送る必要があるため、このシステムに必須なのはメールが任意のタイミングで送信できることである。メールを送信する方法としては

  • AWSのサービスを利用する
  • 自前のメールサーバーを立てる

というのが真っ先に思い浮かんだが、どちらも維持管理にお金がかかるので、これらのサービスは除外して考える。そうなると、無料かつプログラマブルにメール配信が可能な方法があるのか・・・と考えたところ、Googleのサービスに、「Google Apps Script」というものがあることを思い出した。通称GASは、GoogleのサービスであるスプレッドシートやGmailをJavaScriptベースで操作することができるものであり、生存確認メールを送信するのに良さそうである。

 発動条件についても、スプレッドシートで管理すると、GASからのアクセスも用意なのでスプレッドシートを使うことにする。

メール配信システム

 メール配信システムでも、結局やりたいことはメールの自動送信なので、GASでGmailから送信するのが最も簡単である。

 肝心のメッセージだが、これがちょっと難しい。メッセージには写真や動画、ファイルなどを添付して送信したい。例えば、Gmailでメールの下書きを用意しておいて、そのメールに宛先をつけて自動送信する方法があると思う。でもそれだと、ファイル上限の制限であったり、下書きメールを間違って削除してしまったりする可能性もあるだろうが、ある程度の目的は達成できるので、この方法で実現を試みる。

 最後に、メッセージの送信先のグルーピングであるが、これも例のごとくスプレッドシートで実現できる。

まとめ


 自分の死後に、残された家族にメッセージを送信するシステムと、その実現可能性について検討してみた。結論としては、GAS + スプレッドシート + Gmailで簡単なものは実現できる。ただ、この構成だけではすべての要件を十分に満足しているとは考えられない。

 スプレッドシートは表計算シートなので、利用者のユーザインターフェースとするには分かり難く、シートの構成を誤って変えてしまう可能性がある。また、Gmailは相手がメールを普段から使っていることが前提となる。普段、Lineしか使っていない娘に対してのメッセージ送信方法としては適切ではない。

 まずは最低限のシステムを完成させたあとで、LineのAPIを利用してメッセージを送る方や、スプレッドシートではなく、設定画面を用意して無料のホスティングサーバを利用するという方法も検討して改善して行きたいと思う。