blog.cntlog logo

個人開発で家事・育児で悩む人向けのWebサービスパパダッシュを作ってみて

制作物紹介

投稿日

個人開発で家事・育児で悩む人向けのWebサービスパパダッシュを作ってみて
2020年2月2日に「パパダッシュ!!」というWebアプリを作成しました。 このWebアプリは家事・育児で悩む人がパートナーに向けてヘルプを出しやすくするサービスです。 ※私にはヘルプを出す奥さんもいないのに、思いつきで作ってしまいました。 この記事では個人開発に興味をもっている方向けにパパダッシュをリリースするまでの考え方と出してみた結果についてご紹介します。

リリースした後のユーザーの反応

リリースの告知は自分のtwitterのアカウントで行ったくらいですが思った以上の反応をいただけました。 自分の見立て通り、困ってる事と解決の方法が結びつけれそうで多くの方から好評を頂いています。

どういう考えから作ったのか

自分で作っておいてなんですが、機能的にはテンプレートをチェックしてそれをページとして公開できるだけなのでシステム的にはどこにでもある平凡なものです。 なぜ好評であったかを振り返ると自分のデザイン（設計）がユーザーにフィットしたからだと自画自賛します。 Webデザイナはかっこいい画面を作るのではなく課題解決を目的とすることが本来期待されてる役割だと考えています。 今回考えていた夫婦間の課題は、「相談のしにくさ」と考えていました。 仲が悪いわけでもないのに「相談がしにくい」とはどんな状況なのかを考えたときに、「申し訳無さ」といった罪悪感があって言い出しにくいという仮設を立ててこのアプリを設計しました。 そこでアプリのようなテンプレートで書き出せれば、言い出しやすい（メッセージで送りやすい）のではと思いこのアプリの設計が始まりました。 ユーザーは「家事・育児の負担が大きい人」「外で働き、家事・育児をサポートする人」の2軸で考えました。 このアプリで重要なのは言うまでもなく「家事・育児の負担が大きい人」です。 なぜならこの方が言い出せなければ、サポートができない状況になるのでなるべく考えず簡単にフォローを依頼できるという体験を重要視しています。 そしていかにサポートする人が自然にフォローの依頼を受け取れる気持ちになれるかというあたりを次のフェーズで重要視して設計しています。 この２つの体験が概ね問題なければこのアプリで達成したいことは実現できるので、それらを実現するフローや機能を精査してつくりました。

ユーザーから好評だったところ

一番多かったのが、「これなら私でもできそう」といった自分が気がついていないアプリ自体のニーズです。 チェックして送るだけなのでそのシンプルな設計が受け入れられました。 リリースする前はシンプル過ぎて「これなら直接メッセージを送るわ」とか言われたら仮設が大外れになるのでその点が受け入れられてよかったです。 あと「家事・育児の負担が大きい人」の「今の気分」を必須の選択制にしてるところがピンポイントで褒められました。 これは「家事・育児の負担が大きい人」の振り返り的な意味と「外で働き、家事・育児をサポートする人」がどのくらい今大変で助けを求めてるかの指針になるため必須の機能として入れていました。 気分の選択制はアプリならではの機能なので設計がフィットしていてすごく嬉しいです。

ちょっと以外だったこと

私は過去（2017年）に「俺の嫁が可愛い」というサイトを作って、人生できっと最大であろうバズを起こしたことがあったのですが、その時の印象に引っ張られてか今回作ったパパダッシュも「優しいインターネットの世界をまた作った」などを言われることが多かったです。 公開6日で100万PVを叩き出したWebサイト「俺の嫁が可愛い」を公開してみて 他にも俺の嫁が可愛いを作った人はいつも穏やかな世界を作るなど、べた褒めされてしまい自分が褒められてる感覚が実はあまりなかったりします。 自分としてはニーズがあるもの（課題解決をできるもの）を作るのは当たり前とか自分のスキルが活かせて嬉しいみたいな感覚で、優しいとか世界平和みたいな感覚で作っていないので「第三者からだとそう見えるんだ…」というのがとても驚きでした。

なぜWebデザイナがアプリを一人で作るのか

改めてお断りしますが、私はWebデザイナであって、エンジニアではないです。 エンジニアでなくてもパパダッシュくらいのWebサービスは作れます。 誤解というよりは私の信念なのですが、令和のWebデザイナは設計だけではなく、改善も求められてると考えています。 Webデザイナはコードが書けなくても良いみたいな風潮があるのは知っていますが、自分としてはコード書けないWebデザイナは半人前という目で見ています。（ケースに寄りますが） このあたりの話はこの記事の本筋ではないのでご興味ある方は下記の記事を御覧ください。 Webデザイナーのコーディング不要論のついて思うこと 現役Webデザイナーが将来性とキャリアについて考えてみた 私が自分でコードを書く理由は改善のためです。 私はそれほど優秀なデザイナとは思っていないのですが、改善は得意と自負しています。 そのため、基礎設計を最速で行い仮説検証をしてサービスを育てられます。 その品質の担保のために自分でコードを書いて仮説検証をする必要があるという考えの元、今のスキルに行き着きました。 仮説検証において優秀なエンジニアが必要かと聞かれたらそれほど重要度は高くないですが、仮説検証において優秀なデザイナが必要かと聞かれたら必須だと答えます。 理由はあえて言わなくてもいいと思うのですが、一発目で作ったデザイン（設計）でうまくいくなんて無理ですし、リスクが高すぎます。 そこで設計しかできないデザイナが改善をしようとしたときにコードを書くという壁が出てきます。 よくコーダーやフロントエンドエンジニアがいたらデザイナはコード書けなくても大丈夫みたいな話を聞きますが、個人的にはその論調には否定的です。 なぜならコーダーやフロントエンドエンジニアをユーザーに受け入れられるかどうかわからない仮説検証でデザイナが振り回して一体何割の人がついてくるのかが疑問だからです。 もっとストレートにいうと自分で設計したものなら自分で責任持って作ろう。それができないなら自分でお金払って完成させよう。そのための「プロのデザイナ」だろう。 というくらいの心づもりがデザイナには必要だと思っています。 ※私個人の考え方です。 そのため私は自分で仮説検証をして改善をするためにCSS/JavaScript、解析周りといったスキルを身に着け今のようなアプリを作れるスキルを身につけました。 このあたりはWebデザイナという言葉で括るよりはUXデザイナーのほうがニュアンスは近いかも知れません。

どういう技術構成で作ったか

技術には疎いので、そんなに自信をもって強調するするものでは無いのでですが以下の構成で作りました。
  • ionic（UIフレームワーク）
  • Angular（JavaScriptフレームワーク）
  • firebase（認証とDBとStorage）
  • netlify （サーバー）
この構成で作った理由はこの書籍を読んだからです。 Ionicで作る モバイルアプリ制作入門 ionicは2年前にホウビンゴというアプリを作りました。 当時のことは下記にまとめていますのでご興味がある方は御覧ください。 Webデザイナーが3日でスマホアプリを公開した方法 このとき読んだionicの本は先程紹介したionic本の過去作です。 新しくなったionic本はionic4対応でコードが直されているのと、firebaseを使った開発が書かれているのでその点だけでも十分な価値の情報でした。 余談ですが、ionic本を読んでからionic3で作ったホウビンゴをバージョンアップさせています。 書籍の中でfirebaseはAuth認証とDatabeseについて書いてあり、パパダッシュ!!でもそのあたりのコードがかなり参考になっています。 流石にコピペで作ったとは言わないですが、パパダッシュ!!のコードはこの書籍に書いてあることが7,8割だと思います。 リファクタリングについてやコンポーネントの作り方など、まだまだパパダッシュ!!に落とし込めていないコードもあるので、そのあたりは今後進めていきたいと思います。 本を読むだけでは自分はなかなか理解が薄いので、こうやってアプリを作って理解力を高めています。 前作は3日で作ったのですが、今回は年末年始を書けて作るつもりだったのがおもったよりfirebase周りで手こずってしまいモチベーションが落ちてしまいましたが、日を空けて本を読み直したらなぜかスラスラ頭に入ってきたので、そのままの勢いでリリースまでできました。

画面フローの作り方

 今回は画面の数も少なかったのでmiroで必要そうな画面を書き出して導線を整理しました。 なお、ユーザーの導線、緑のところはシェアされてそれを受け取ったユーザーの導線として分けています。 普段ならSketchなどを使って画面を作りながらやっていくのですが、ionicがUIフレームワークなのでインブラウザデザイン中心で作りました。 インブラウザデザインは時間はかかると思われやすいのですが、やってみると改善が当たり前なので本質的なところに気が付きやすく最近はこっちでやるほうが最終的に質が高いものを出せると思っています。

苦労したところ

ログインしてる人とそうでない人はページにアクセスした時の挙動の管理に結構頭を悩まされました。 基本的にはfirebaseのDatabeseには振り回されっぱなしで、正直ionic本がなかったらパパダッシュ!!のリリースはできなかったと思います。（というか作ろうとすら思わなかったかも） 試行錯誤と言えば聞こえは良いのですが、やってみて失敗を繰り返したからこそionic本に書かれてたことが理解できていきました。 そういった意味ではすごく価値のある情報でした。 今後もログインやDBをつかったWebサービスはつくっていくのでこの苦労は決して無駄にならないと思います。もっと数も作って慣れていきたいです。

マーケティング戦略で気をつけたところ

Webサービスやアプリは使ってもらってなんぼなのですが、まずは認知をしてもらうことが何より重要と考えています。 特に今回の場合は仮説を立てたものの自分の周りでユーザーになってくれる人はいないので、なんとかユーザーをネットで見つけるというのが重要な課題でした。 余談ですが、私自身妻も子もいないのでユーザーと程遠いところにいます。なんで作ったかと聞かれたら「思いついちゃったから…」みたいな軽い気持ちです。反省はしてません。 twitterでシェアを多くもらうためには下記のことが重要だと考えました。
  • わかりやすい（思えやすい・口にしやすい）サービス名
  • アカウント登録なしでも始めて体験できる
  • ユーザーに刺さりやすい言葉を使う
  • シェアしやすいLP・ツイートを用意しておく

パパダッシュ!!というサービス名について

サービス名は当初sosとselfをかけ合わせたような名前で考えていましたが、口にしにくい、読みにくいなどあまり乗り気ではなかったです。 一番最初はパパとかママとかサービス名に使えばいいかと考えていたのですが、多様な家庭環境があるので閉鎖的イメージのサービス名はやめようと考えていました。 しかし利用シーンを想像してる中で「パパダッシュ!!」と思いついてしまい、めちゃくちゃしっくり来たので意識をかえてこのサービス名にしました。 口にしやすい・覚えやすいサービス名としてはニーズを抑えたものだと自負しています。 もちろんリリースしてから反発や疑問を投げられましたが、説明したら納得はしてくれました。 リスクはあるのは承知の上での決断ですが、結果的はこの「パパダッシュ!!」というサービス名があったからこそこれだけの反響を得られたと思っています。

集客の戦略

パパダッシュ!!については初動が今後の命運をかけるといっても過言ではなかったので、目標は一人ガチユーザーを見つけてその人からフィードバックをもらうということです。 ひとまずコミュニケーションを取れるユーザーは何人かと繋がれたのでここ数ヶ月はこの人達と向き合って改善はできるので大成功です。 成功するためには運だけでなく戦略も必要で、シェアをもらうための戦略で一番シンプルなのが共感です。 今回はこのツイートに乗ることで世間的に共感されやすい時期にリリースすることにしました。 これだけのシェア数のある投稿ということはそれだけ共感しているユーザーがいるということなので母数としては文句のない戦場で戦うサービスだというのは証明されていました。 あとはここからどれだけシェアをもらえるかです。 シェアをもらうためにはパパダッシュ!!が有用なサービスと理解してもらう必要があるのでアカウントの登録不要なゲストアカウントのようなものを準備しました。 これが功を奏して、ログインユーザーの8割はゲストアカウントでログインをされています。 一応リリース4日時点で600人弱の方がゲストアカウントでパパダッシュ!!を試してくれています。 もともとシンプルな設計なので、クリックを数回するだけで全容が見えるので多くの方がサービスの中身を理解してくれました。 こんな感じで利用キャプチャ動画を作ってくれる人もいるので嬉しい限りです。 個人サービスの製作者の集客方法としては「持たざる者」の集客方法というのがとても参考になります。 以前バズった「俺の嫁が可愛い」はこの記事にかいてある「任意拡散タイプ」になります。 反響がとても取りやすいサービスだったので、自分のツイート以外でもサイト内の投稿がシェアされてどんどん人を呼び込むようなサービスになっていました。 今回のパパダッシュ!!では任意拡散を狙ってはいますが、コンテンツでのシェアはほぼ期待できません。 あくまでコンセプトに対しての任意拡散になります。 私が次に狙ってる任意拡散はユーザーが実際にパパダッシュ!!を使って「楽になった」「改善された」という投稿をしてくれることを狙っています。 もしユーザーがそういったパパダッシュ!!で解決できたという投稿をしてくれたら私のシェアの比ではないと予想しています。 だって私のフォロワーは技術者系が多いのですが、当事者であれば似た悩みを抱えてる信頼関係のあるフォロワーが」いるはずなので説得力が段違いになります。 そのためにはきちんとユーザーの課題解決に向き合ったデザイン（設計）が必要になるのでやりがいがありますね。

シェアしてくれた属性の変化について

2月2日にパパダッシュ!!は公開したのですが、初日は知り合いの技術者が中心にシェア・いいねをしてくれました。 3日は知り合いでなくても、Webデザイナ、個人サービス開発系の方々から反応をもらえました。 この頃から、ママWebデザイナーといった方々から反応をもらいはじめました。 4日からはマタニティ垢の人たちにも届いて、ユーザーの声が拾いやすくなり成功を感じました。 その後5日までは順調に伸びたのですが6日に落ち着いたって感じです。

シェアの数字で見ているところ

シェアはされたらされただけ嬉しいのですが、私はもう一つ数字を別の視点で見ています。 それはリツイートといいねの比率です。 俺の嫁が可愛いの投稿のときに気がついたのですが、リツイート数の方が多いです。 これは自分が見たい・好きを超えて積極的にシェアしたい良いコンテンツの傾向なのでは？と仮説を立ててバズった投稿を見ていますが、リツイートの方が多いのはかなり珍しいです。 パパダッシュ!!もシェアの反応を見てたのですが、リツイートのほうが多くなることはなかったです。 とは言え、リツイートがいいねの倍以上あるのでそれなりに共有したい良いコンテンツを作ったのではないかと自負しています。

今後の改善

ユーザーから頂いたフィードバックを中心に改善した後は、サポートする側をいかに舞い込みやすくするか、手伝いやすくするかの改善をしようと思っています。 リリースしてみて思ったのですが、この点の設計がまだ甘いもっと改善できそうという気持ちがあります。 また改善ではないのですが、Android版・iOS版のアプリを出す予定です。 ionicで作っているので、いつでも出せるのですが検証が増えてしまうので、タイミングは躊躇しています。 できれば好意的なレビューで整えたいのでパパダッシュ!!のファンができてからアプリ配信を考えようと思っています。

マネタイズについて

いくつか考えているものはあるのですが、マネタイズはおそらく買い切りの機能解放になると思います。 とはいえパパダッシュがきちんとユーザーの課題解決につながると自信が持てたタイミング以降でだすのでまだ先になると思います。

最後に

パパダッシュ!!で今回のような反響をいただけたのはデザイナとしてとても自信がつきました。 俺の嫁が可愛いの反響が大きすぎて、一発屋感が自分のなかでずっと合ったのですがこの数年間で身につけたスキルは誠実にユーザーと向き合ってるものと証明できました。 ものすごいアプリを作ったわけではないですが、自分が今後やっていきたい分野での小さな成功体験をできました。 今回ionic本で学んだfirebase周りの知識を活かせれば作りたいと思っているサービスがまだまだ作れそうですので、今年はそういったアウトプットの年にしていきたいと思います。 まだまだパパダッシュ!!は未熟なサービスですが、結構いい線ついてるサービスだと思いますので今後とも宜しくお願いします(ゝω・) パパダッシュ!!

カテゴリ:制作物紹介の記事