社内ハッカソンで新規サービスを作ってみて

はじめに

新しい技術にチャレンジし続けるeishisのアドベントカレンダーDay25です！

昨日は「スクリーンサイズとリアルタイムビュー【これからはじめるXD】」でした。

スクリーンサイズとリアルタイムビュー【これからはじめるXD】

今回は社内ハッカソンで新規サービス（アプリ）をつくったので、そのプロセスなどをご紹介します。
もちろん人や企業によってやり方は様々ですが、新規でサービスを作りたい、という方に少しでも参考になればと思います。

※どちらかというとサービスをメインとしていく！というより他の業務をしながら開発する方の参考になると思います。

サービス開発において大事にしていること

新規でサービス開発をするといっても、いきなり「作れ」と言われても何を作れば良いかわからないですよね。

bageleeの運営会社であるeishisでは、お客さんの作りたいサービス・アプリの開発をサポートする受託開発事業をメインとしています。
それでも、会社全体の20%ほどの時間を自社サービス開発に費やし続けています。

それを継続できる理由として、私たちがサービス開発において自分たちが使い、簡単に検証でき、技術的なチャレンジがあることを大事にしていることがあげられます。

それぞれについて解説します。

自分たちが使うサービスであること

後述しますが、サービス開発において大事なことは「誰かの困ったを解決する」ことです。
またどうでも良いことより、その深刻さ具合（ここでは「痛みの強さ」と表現します）が重要となります。

教科書的な新規事業の作り方としては、業界規模やマネタイズのしやすさ、競合などを調べた上で事業を創っていくことが多いのではないでしょうか。
ですが、どんなサービスでも個人的に大事なのは「作る側の熱意」だと考えています。

そのためにまず「作る側がユーザーであること」がモチベーションを維持しやすく、またユーザーとして使い込み機能改善をしていく為にも「作る側がユーザーとして使い込むこと」はとても重要です。

参考：ゆるっぷるアクティブユーザーの遷移（上から月間、週間、日間のアクティブユーザーの遷移）

なので、eishisとして取り組むテーマは「自分たちがほしいもの」とし、その中でどんなサービスを展開するかは、後述のカスタマージャーニーなどを用いて決めています。

簡単に検証できるサービスであること

テーマが決まり、その後に仕様を決めていくと、「この機能もつけたい、あれも」とどんどんやりたいことが増えていきます。
ここで重要なのは、あくまでも最初は機能を絞りプロトタイプに近いものとし、「本当に必要とされるサービスなのか」を検証をしながら改善していくことです。

その理由として、リリースが先になれば先になるほど熱意が冷めてしまうこと、また本当にユーザーに使われるものか検証してみないとわからない為です。

その為、まずは限定公開でも良いのでサービスのリリースを短い期間でできることを重要視しています。

もちろん最初からプロモーションをしていく場合などはリリース段階にしっかりと作り込む必要がある為、ケースにもよってはきます。

今回は社内ハッカソンという形で、コワーキングスペースに丸一日チームで引きこもり、他の仕事を一切せず集中して機能を絞り開発することで短期間でプロトタイプが開発できました。

技術的なチャレンジがあるサービスであること

「サービス開発を通して成長できる」という意識が開発者側にあると、よりモチベーションを継続しやすいです。
それはサービスを作る過程自体に意味があると思える為です。

要件定義を行う

さて、前置きが長くなりましたが、実際のサービス開発の過程をお見せします。
自分たちが使うサービスであることを大前提とし、ランニング人口が多いeishisでは「ランニングアプリ」をテーマとすることにしました。

プランナー、デザイナー、エンジニアの3人1チームとし、コワーキングスペースに引き篭もり1日で要件定義からデザイン・開発まで進めました。

要件定義では以下のような項目をまとめていきます。

• 誰をターゲットとするのか
• どんな課題をどう解決するのか
• 何が特徴か

ユーザー属性とユーザー行動を分類する

最初に「ランニングアプリ」を使うユーザーとして、どんな属性に分けられるか、ざっくり分類しました。
そしてユーザー属性と、そのユーザーの行動を分類し掛け合わせ「誰がいつどんな行動をして、どんなことで困っているか」を可視化することにしました。

今回は属性を以下の4属性に分類しました。

• ランニング未経験者
• ランニング初心者
• ランニング中級者
• ランニング上級者

そして次にユーザーの行動を分類します。
ランニングに関わる行動として、以下の4つに分類しました。

• ランニング前
• ランニング中
• ランニング後
• ランニングをしない時間

そうして出来たこのようなマトリックス図に、シナリオ（どんな行動をするのか）、またそれに伴う課題を入力できるようにし、メンバーで共有できるようGoogle Spread Sheet上で共有します。

ペルソナシートを埋める

次にマトリックス図を埋めていきたいのですが、そちらを埋めていく為にはユーザーのシナリオや課題を具体的に洗い出す為にも、一回ペルソナ（人物像）を作っていきます。

こちらもSpread Sheet上でユーザー属性毎にシートを作成し、ペルソナをまとめました。

ペルソナのポイントはまた別記事でもご紹介していきますが、プロフィールや日常の行動などを具体的にし、イメージしやすくすることです。

カスタマージャーニーマップを埋める

次に、先程のマトリックス図（カスタマージャーニーマップ）を埋めていきます。
ペルソナ作成を途中で行ったのは、より行動シナリオや課題をイメージしやすくする為です。

細かいですが、それぞれのフェーズでどんな行動をし、どんな課題（痛み）があるかを埋めていっています。
痛みの強いものは太字にし、最終的には痛みの強いものを解決するサービスを作っていきます。

企画を集約する

こうして出てきた痛みを集約し、その解決策をディスカッションしていきます。
付箋を使い整理することもあります。
この課題から解決策を考えていく作業が一番難しい作業です。

ここでは、企画を集約し以下の4点をまとめます。

• Problem（痛み）
• Goal/Solution（解決策）
• Features（そのサービスならではの特徴）
• Screens（必要な画面）

今回は「ランニングが継続しない」という初心者の痛みを解決するサービスにすることにしました。
他のサービスなども見てみると、初心者としては「ハードルが高すぎる」という障害がありそうで、そこを「敷居を低く継続できるようなゆるいインタフェースと演出」を提供していくことにしました。

デザイン要素を仮決めする

企画が定まってきたところで、重要なデザインの方向性を決めます。

もちろん途中で変わる可能性はありますが、こちらもSpread Sheet上でデザインの要素を洗い出します。

タスクをまとめる

企画、デザインの方向性が固まったら、いよいよデザイン、開発に取り掛かります。
ちなみにハッカソン当日は午前中まででここまでが終わり、午後からタスク整理及びデザイン・開発に着手しました。

タスク管理ツールとしてはTrelloを使用しました。
以下の5つにリストを分け、それぞれにタスクを分配しています。

• Idea（ジャストアイディア）
• Backlog（今後実装していくタスク）
• ToDo（優先して着手していきたいタスク）
• Doing（着手中のタスク）
• Done（完了したタスク）

アウトプット

さて、こうして出来たのがこのような開発画面です。

走った結果に応じて、ランニングの島が少しずつ発展していく、というゆるーいランニングアプリです。
検証を行い、年明け以降にリリースを予定しています。

まとめ

今回は社内ハッカソンを行い、新規サービスを作る過程をご紹介しました。
1日という短い期間で要件定義から実装まで、だいぶスピーディに進めることができたと思います。

もちろん、もっと時間を取ってサービス企画をできることが理想ですが、どうしても勢いが無いと新規サービス開発に着手できないこともあります。
そんなときには今回ご紹介したようなアプローチで、まずは作ってみるのもオススメです。

個々の手法についてはだいぶダイジェスト版となっているので、また別の機会に詳細はご紹介していきます！