「何かつくってみたい」を支援する100programでランダムな人と交換日記ができるアプリを開発した。
課題
交換日記をする人が減っている。
実際に、自分も小学生のころはしていたが中学生以降は全くやっていない。
周りでやっている人を見ることもなくなった。
その背景の一つには、デジタル技術の発達がある。
スマホ１台で簡単にすぐ遠くの人と繋がれる時代。届くまでの時間と紙に書く手間がかかる交換日記をする人は明らかに減った。
一方で、アナログならではの良さもある。
- LINEのように１日何通もやりとりできないので、１通にその日の思い出が詰まる。
- 編集や取り消しができないからこそ心のこもったメッセージでやりとりできる。
- なかなか届かないからこそ、それを待つ楽しさがある
解決策
アナログ日記の良さを残しつつ、デジタルの便利さを融合するアプリを開発した。
アプリのコンセプト
ユーザーは１日１通だけ宛先不明の日記を書く。
この日記はランダムな時間にランダムな人に送られる。
日記が届けられた相手とは通常のチャットアプリのようにやりとりができる。
しかし、この場合も、送れる日記は相手につき１日１通に制限されるほか、届く時間もランダムである。
| 従来のチャットアプリ | Dialy（本アプリ） | |
| 送信の候補 | 友達のみ | 友達＋ランダムな誰か |
| 相手にメッセージが届くまでの時間 | 即時 | ランダムな時間経過後 |
| メッセージ送信数 | 無制限 | 送信先につき１日１通 |
使用の流れ
- ユーザーは好きなタイミングで日記を記入する。
2. 日記はすぐに相手に届くわけではないのでサーバーに蓄積される。
3. BeRealのように毎日ランダムな時刻で日記が一斉送信される
アプリの特徴
新たなつながりを得られる
ランダムな相手に日記が届いてやり取りが始まることで運命的な出会いにつながる可能性がある。マッチングアプリとは違う新たな出会いの始まり方。
待ち時間を楽しめる
１日１通。しかも、いつ届くかわからない。すると相手が何を送るか考えてワクワクしながら待つはず。従来のチャットアプリにはないアナログの良さを感じられる。
技術の紹介
担当
４人で開発を行った。
自分、Wさん、Cさん、Iさんとする。
全員がgit未経験などで自分が一番プログラミングの経験があったので、テクノロジー系の部分のリーダーを担当した。
また、実際の作業は以下のように分担した。
バックエンド
- 自分（python経験あり、バックエンド未経験）
- Cさん（プログラミング自体未経験）
フロントエンド
- Wさん（flutter初めて）
- Cさん（少しだけflutter使用経験あり）
開発したもの
自分が担当した部分
- djangoによるデータベースに使うモデルの定義
- アカウント登録、ログインなどの認証処理
- アカウント情報やアイコンの登録
- 自分に届いている手紙の一覧を返す処理
- 手紙をランダムな相手に一定時間経過後に送る処理（celeryを使用）
- dockerの構築
- frontend側からHTTPリクエストでバックエンドと通信→その内容を基にUIを更新
- gitのmerge
振り返り
開発者として
- バックエンドは未経験だったが基本の機能が実装出来てよかった。
- バックエンドは今までアルゴリズムの適用などをするだけだと思っていたが、データベースの処理やモデルの定義などの知識が結構必要なのだと気づいた。
- 今までdockerにあまり触れてこなかったが、今回の開発を通じてかなりdockerを使えるようになれた
- dockerを使うと共同開発での環境整備が楽なだけでなく、自分自身の環境構築も楽になった。postgreやnginxは既存のbase imageを使うだけでほとんどの作業が済んだ。
テクノロジー部分のリーダーとして
たくさん反省があります。。。
- 最初のタスクの割り振りをプロジェクトのリーダー（Iさん）に任せていたが、自分がやったほうがよかった。プログラミング未経験だとタスクごとの重さがわからず大変だったと思う。
- 仕事を振る時にできる限り具体的に振るとよいと知った。
- 「日記が書き込まれたときにそれをデータベースに保存」というタスクでお願いしていた。
- 本人は結局何をやればいいかわからず調べるだけで終わってしまったらしい。
- どのファイルをいじるべきか。このコードと似た感じで値を変えてほしい。などを細かく説明すると迷わずタスクに取り組めていた。
- 後から詳細に説明するならば最初から詳細に説明すべきだった。
- gitの運用ポリシーを最初に強く言えばよかった
- mainブランチで作業してしまう事案
- git pullを忘れて古いcommitから新しいブランチを切って作業を始めてしまう事案
- commitメッセージが適当すぎて後からどこでどの編集をしたのかわからない事案
- この人にこのタスクをこの期間で任せられるか見極めてから振るべきだった。
- プログラミング未経験の人に任せるのはバックエンドよりもフロントエンドのほうがよかった。本人にとてもやる気があったとしても、バックエンドの複雑な知識（HTTPやデータベース）を学んだ上でコードを書くのは難しい。
- HTTPリクエストを聞いたことがない人に、フロントとバックの接続をHTTPリクエストでやってもらうのを３日でやってもらおうとした。前述の反省を生かしてタスクを詳細に説明したが、そもそも前提知識が少ない状態では難しそうだった。
- 本人のやる気や自分への遠慮で「やる」と言ってくれるが、それに甘えてはいけない。できるかできないかギリギリくらいのラインを見極めるのは経験をもっと積む必要がありそう。
- 開発をフロントとバックで分けて始める前に、フロントに要件を伝えるべきだった。
- バックエンドと通信をする場合はStateful Widgetなのに、Stateless Widgetで作っていた。事前に説明をしていれば防げたはず。
- フロントになるべく早くバックエンドのリスポンスの形式を伝えるのも大事。
- あらかじめ接続する前提でダミーデータをもとに作ってもらうなどをするとよさそう。
１メンバーとして
- 思ったことは遠慮せずに言うと本人のためにもなると実感した。
- 特に、プレゼンのフィードバックではよくないところはよくないと言う。
- 「他の人はいいじゃんって言ってくれるけど自分で納得してない部分があった。そこをきちんと言語化してくれたからよかった」と言ってもらえた。
- リーダーの士気のあげ方がよかった
- 成果が生まれた時は感情込めてめっちゃ素直に喜ぶ
- 自分から率先してディスコに常駐して作業する。