新規アプリ「静かな本棚」開発履歴メモ|進捗確認と広報方針の話
こんにちは。ETEOTOです。
今回の内容は、アプリ開発の進捗の確認と広報活動についての方針を話し合いました。
本記事は、その過程を記録したものです!
「静かな本棚」開発進捗
まずは進捗確認から
進捗を確認しましょう。
開発期間のロードマップはすでに作成済み。
では、そのロードマップに沿って、現時点で何ができているのかを見ていく。
画面を順に確認していった。
想定していた進捗(ロードマップ上の前提)
開発期間のロードマップ上では、この時点ではまだ機能を作り込むフェーズではないという想定だった。
予定していた作業は、主に以下の内容である。
App Storeにリリースするために必要な事柄の調査
App.tsxを画面・コンポーネント単位でどのように分けるかの検(App.tsxに1ファイル構成の雛形が用意されていたため)
上記方針に沿った、最低限のファイル分割
つまりこのフェーズは、設計と準備を整える段階であり、
ユーザーが直接触る機能の実装は、次の工程で進める想定だった。
実際に確認された実装状況(想定以上に進んでいた点)
しかし、実際に進捗を確認したところ、状況は大きく異なっていた。
確認の結果、ほとんどの機能がすでに実装されていた。
現在、アプリには以下の4画面が存在する。
ホーム画面
ことば登録/編集画面
ことば一覧画面
ことば詳細画面
画面遷移も一通り揃っており、
登録 → 一覧 → 詳細といった基本的な操作はすでに成立している状態だった。
さらに、ユーザー体験に直結する以下の機能も実装されていた。
各画面への遷移
お気に入り機能
感情ラベルの追加
色をテーマ変数として分離
全文・感情・日付・出典・メモの登録機能
登録した言葉の削除機能
これらは本来、
設計フェーズ完了後に段階的に実装していく想定だった機能である。
AIを使って実装を進めていたこともあり、
ロードマップ上の想定よりも開発フェーズが一段先まで進んでいる状態だった。
この状況をどう捉えたか
設計者・プロジェクトリーダー側についても、
AI前提で開発を進めるという認識は以前から共有されていた。
ただ、今回の進捗を確認したことで、
その前提をロードマップ上でどこまで具体化できていたか、という点には見直しの余地があることが分かった。
お気に入り機能で見つかった問題
一方で、動作確認の中で問題も見つかった。
今回のアプリでは、
ことば登録時にお気に入りを設定すると、
その言葉がホーム画面に表示される仕様になっている。
しかし実際には、
お気に入りが1件のときは表示される
2件以上登録すると、ホーム画面に1件も表示されなくなる
という挙動が確認された。

お気に入り登録するとホーム画面に登録した言葉が表示される

2件以上登録した場合


この問題は機能部分で致命的なバグであるため優先順位を高く設定し修正する方針で決定した。
UIの細かい違和感(フィルタが強すぎて埋もれる、など)も出たが、結論は決められなかったので、これに関しては次回に持ち越しすることに。
アプリの広報方針についての議論
進捗確認の流れで、アプリの広報活動についても話題に上がった。
まずX(旧Twitter)の運用方針について。
今後は、
宣伝や技術発信よりも、開発進捗や過程を発信する形はどうか
という提案が出た。
一方で、
アプリを「欲しい人」は、開発進捗にそこまで興味がないのでは?
いきなりユーザー獲得を狙うのは早いのでは?
という意見も出た。
しかし、まずは
同じ個人開発者にETEOTOという存在を知ってもらうこと
そして、開発過程に共感してもらうことを優先する。
人は情報そのものより、「それを見たときの感情」を強く覚える。
これは心理学で、感情が記憶を強化すると言われているため。
だからアプリの機能説明や宣伝より、「なぜそのアプリを作りはじめたのか」「どのように作っているのか」の方が心に残る。
人は自分と似た経験や悩みに触れると、無意識に共感する。
共感が生まれると、それはただの情報じゃなく「自分ごと」になる。
すると応援したくなるし、記憶にも残りやすい。
たとえば、次のような発信は同じ立場の開発者に共感されやすい。
ユーザーの要求を分析していると、つい要件が増えがちでした。優先度の低いものは削り、必要最小限に絞りました!
全部実装したい気持ちはありますが、期限を踏まえて優先度の低いものは削り、必要最小限に絞りました!
迷いや判断、削る決断が具体的に書かれているため、
「あるある」と感じられる経験に落ちている。
一方で、次のような投稿は印象に残りにくい。
今日もアプリ開発を進めています!
要件定義と設計をしました!
事実は伝わるが、何に悩み、どう判断したのかが見えず、
読み手が自分の経験と重ねにくい。
以上の理由から、広報活動の目的を、開発過程に共感してもらうことにする。
アプリを欲しい人に知ってもらうのは、その次の段階にする。
この考え方は、noteでの発信についても同様とした。
次に話題になったのは、広報の負担分散について
各自が思ったことを自由にポストする、という案も出た。
ただ、この方法では投稿内容が被ってしまう可能性が高い、という懸念も共有された。
そこで別案として挙がったのが、
「視点」ごとに担当を決めてポスト案を考える
具体的には、
開発
実装
企画
広報
といった視点をあらかじめ決め、それぞれの立場から発信内容を考える、という方法。
この方法であれば、
同じテーマを扱っても切り口が自然と分かれるため、
投稿内容の重複を避けやすい。
その点から、現時点ではこの案が有力そうだ、という方向で話は落ち着いた。
ただし、実際に運用してみなければ分からない部分も多く、
この方法が最適かどうかについては、明確な結論を出さず、今後試しながら判断していく
なお、Eteotoではこれまでにも
「成長リスト」 というアプリを開発・リリースしています!
今回の「静かな本棚」は、その開発経験を踏まえつつ、
あらためて価値やスコープを見直しながら取り組むプロジェクトとなります!
もしよろしければ、
成長リストをご利用いただいたご感想
今回の企画内容についての率直なご意見
などをお寄せいただけましたら、今後の改善や検討の参考にさせていただきたいと考えております!
