あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える

手を動かす前に「解決したい課題は何か」を考えよう

まずは何をつくるか、を考える必要があります。

この時点で注意すべきは、「何をつくるか」より先に「何を解決するか」を決めることだと思います。僕たちエンジニアは「こんなことができれば良いな」と考え出すと、設計や実装のイメージがどんどん湧いてきます。具体的な形が思い浮かんだら「じゃあ手を動かしてつくってみよう！」となりがちですし、実際に開発をスタートできます。

しかし、ここはグッとこらえ、自分が課題だと捉えていることは何か、どうなったらこの世界が少しでも良くなるのかを考えることをオススメします。

誰も困ってないことを「課題」として据えてしまっていたら、自分がつくろうとしているものが他の人に使ってもらえる可能性は低いでしょう。「明らかに多くの人にとって課題だし、どうにかして解決したい！」と思える対象であればいいのですが、課題設定が正しかったとしても、解決の方法を見誤るケースも多々あります。だから僕たちはなるべく早くサービスをつくることで、どのアプローチなら課題を正しく解決できるのか、どんどん試していきたいのです。

……と偉そうに書いていますが、僕の場合は解決済みの課題と解決手法がすでにあり、その仕組みや利用方法を他社にも展開していきたいと考えたのです。

前職のクックパッドには「Groupad」というWikiとBlogが融合したような社内情報共有サービスがあり、社内では積極的に情報の見える化が行われています。他人の投稿を見ているうちに、アイデアや経験が情報としてインプットされ、新たなアイデアを生んでいく……という好循環が発生し、それが強い組織づくりの一つの要素だったと思います。

このサービスを他の組織でも使えるようにすれば、多くの人が使ってくれるのでは？ そして、導入したチームでより良いものづくりが行われ、結果として今よりもさらに素晴らしい製品があふれる世界になれば良いなと思ったわけです。

「自分がつくりたいものをつくる」ということはとても大事だと思いますが、多くの人に使ってもらうならつくりたいものはみんなの使いたいものなのかを考えていきたいですね。

サービスのコンセプトを考えるときに参考にしたのは、名著『アイデアのつくり方』です。

誰と、何をつくるか？

課題の設定ができたら、どうやって解決するかを考えます。課題の解決ができて売上げが立てば生きていけますので、解決手法は「小説を書く」でも「お店を始める」でも、自分が一番上手にできるであろう手法を選ぶのが良さそうです。僕の場合はずっとIT業界にいましたし、品質はともかくWebサービスやアプリをつくることはできそうです（というかそれしかできません）。ひとまず、Webサービスをつくっていくことにしました。

取り組むべき解決手法が決まったら、メンバを集めるかどうか考えます。僕の場合は自分で開発ができそうなこともあり、1人でコツコツ開発を始めました。出資を受ける、貯金を切り崩すなど何らかの方法でまとまったお金を用意する当てがなければ、まずは1人で始めるのがいいのかなと思っています。特にエンジニアの場合はそれができるわけですから。

前職を退職した時点で、一生遊んで暮らすにはとんでもなく足りないが、2～3年全く収入がなくても死にはしないな、くらいのお金があったので「しばらくのんびりやっていくか」くらいのテンションでした。ありがとうクックパッド、と感謝している反面、相当ぬるいことを考えていたな、と今は思います。

複数人で始め、かつ会社員であれば休日に開発を進めるのも悪くありません。生活費などを心配せず開発できますし、つくり始めたものが良さそうだ、という感触を得られた段階で会社化するといった考え方でもいいのではないでしょうか。

僕は、起業した2015年1月から2015年5月までは1人で開発を行い、2015年5月にクックパッドから1人エンジニアが出向で来てくれて2人体制になりました（資本関係はないのですが）。その後、デザイナが必要ということで元クックパッドの知り合いに業務委託でお願いしたのが2016年1月。2016年5月にはクックパッドの関連会社からエンジニアをさらに1人受け入れ、2016年8月にもクックパッドを退職したエンジニアを1人受け入れました。他にも、あるエンジニアに副業として業務委託をお願いしていたり、別のデザイナの方にも入ってもらったりしています（何パッドなんだwという感じですが）。

一緒に働いたことがある人ならばパーソナリティも知っていますし、コードレビュー等を経ているのでエンジニアリングの能力も分かります。人柄、実力が分かっている人と働けるのは、小規模の会社では非常にありがたいことなのです。とはいえ、まだ何のサービスもローンチしていないドスタートアップに何の関係もない人が来てくれる、ということはなかなか起きませんが。

お金はどう用意する？

昔に比べると、手軽に使えるクラウドサービスがあったり情報を無料で探せたり、いろいろな費用が本当に安くなったな、と思います。しかしそれでも、お金がなければ仲間を増やすこともできませんし、社員がいる場合は給与を払わなければいけません。そうなんです、サービスをつくっていくにはお金が必要なんです、お金は本当に大事。

僕は「スタートアップだから給与が低いのは仕方がない」とは思いませんし、能力が高い人と働きたいと思っているので給与も高めにしたいです。そうすると人件費が支出の多くを占めてくるわけですが、その他オフィスの賃料や、GitHubやSlack等のサービス利用料も必要です。

お金を用意するには、いろいろな方法があると思います。しかし、1人で始めるなら、まずは自分で賄うことができそうです（最初の僕はこれ）。しかし、徐々に仲間を集めてやっていこうとすると、上記のようにお金が必要になってきます。よくニュースで見る「資金調達」というやつですね。自己資本による調達（エクイティファイナンス）という、株式を発行して出資してもらう方法や、他人資本による調達（デットファイナンス）という、銀行等からお金を借りる方法があります。

コードを書いているとあまり馴染みのない世界だと思いますが、ファイナンスに関しては以下の書籍によく紹介されており、参考にしました。

ソースコードの方がよっぽど読みやすいな～と思いながらも、何度も読み直しています。

なお、僕は、日本政策金融公庫と1つの信用金庫からお金を借りています。この辺は顧問契約を交わしている税理士さんと共に進めました。ちなみに税理士さんには毎月の会計処理や経費精算、決算書の作成等、自分ではできない（知識がない）業務をお願いでき、大変助かっています。

また、ありがたいことに技術顧問的な仕事を僕に依頼してくださる方々がいらっしゃり、その仕事の収益をサービス開発の方に回していました。ですので、自分はもっぱら外でお金をつくり、サービスの開発はそれができる人たちに任せる、という分業スタイルです。

他にも、業務委託で他社の仕事を受けながら、空いている時間で自分たちのサービスを開発していく、というスタイルもあるでしょうし、最初からガツンとまとまったお金を集めてやっていく、というスタイルもあると思います。

この辺には絶対的な正解はないでしょうし、「自分たちがどうやっていきたいか」が大事ではないでしょうか。

インターネットサービスをどうやってつくるか

この辺はサービス開発の話になってくるのでだいぶ話がシンプルになりそうです。

設計

サービスのコンセプトを決めたあとは悩むよりつくりながら考えるというスタンスで、1人でコツコツつくりだしました。今思うと、開発を始めた時点でサービスの全体的な設計や、本質的な価値をいかに実装し提供していくのかなど、もう少し全体の思想をまとめておくべきだったかなという気はします。

スケジュール通りに開発を進めるのは難しいですが、リリース前なら大きな変更もききます。しかし、一度ローンチしてユーザ様が増えてくると、設計思想などの全体的な変更や、思い切ったことはなかなかやりづらくなってきます。少なくともベータリリースの頃には「一回この方向性で試す」と思える状態には持っていきたいところです。

自分の資産を活かせる開発環境や言語を選ぼう

使ってみたい言語、というのはあるでしょうが（できればElixirを使いたかった……）、サービスローンチまでの時間を考えると、勉強しながらじっくりつくるよりもサクサクつくれることが大切です。僕はつくり始めたときに自分の資産（技術、知識、人脈等）を一番活かせそうなRuby/Railsを選択しました。 ここでの選択は、サービスのリリース後にも影響してきます。「調べられる情報の量」や「その技術を使っている開発者の多さ」は技術的なサービス運用のしやすさや人材採用にもつながりますので、堅めに選んでおくのが良いのかなと思います。

というわけで、Ruby、Rails、AWSというよくある感じになりました。今だともうちょっと別の選択肢もありそうですね。

開発の進め方、考え方

「なるべくシンプルに考える」「難しいものは使わない」「迷ったらやらない」「あったら良いなであればいらない」等々、サービス開発でも組織づくりでも、そこに流れる一貫した思想、というものはあります。複数人で開発を進めていく上では、そもそも考え方が合う人たちを集める、というのがまず大事でしょうし、細かいところは日々のコミュニケーションを厭わず行うことで調整していけばいいと思っています。

日々の開発フローは、PMがタスクを分割してTrelloにカードを追加。対応優先度を決めたあと、Slack上でエンジニアやデザイナとコミュニケーションを取りながら開発を進めていきます。オフィスは白金台にありますが、各自リモートで作業することが多いです。こみ入った話や、がっつり議論したい、というような場合はオフィスに集まって話し合うことがあります。

Trelloの各カードで定義された案件は、誰かによってアサインされるというよりは、自分でやりたいものや、自分がやるのが一番早そうなものを選んでもらっている感じです。「得意ではないけどやりたい」というケースもあると思うので、その場合はやる気を尊重してアサインすることもあります。

自作ツールは避け、慣れない業務は得意な人に任せよう

ツールの利用に対してもいろんな考え方があると思います。特にサービス開発を始めたくらいの時期だと「少しでもお金を節約したい」となると思います。「月額500円か～、悩むなあ」みたいな。一方、少しお金に余裕が出てきたり組織の規模が大きくなってくると、ツールに対してある程度のお金を払うことに抵抗感はなくなってくると思います。ですので、最初はOSSを使って自分たちで頑張る、という選択肢も当然あるでしょう。

僕たちはなるべく自作ツールをつくらず、世の中にある良さそうなものを使う、という基本的な方針があります。ある特定のツールを集中して開発し、売っていこうとしている人たち（ツールの開発元）よりも、自分たちが片手間でつくるものの方が良いわけがない。また、社内ツールやちょっとしたものでも運用の仕組みをなるべく増やしたくない、と考えています。ですから、PaaS（Platform as a Service）なりSaaS（Software as a Service）なりの既存のツールを使っていくことになります。

社内で使っているツールはこちら。こうして見ると結構使っていますね。

僕たちのKibelaも「お金に余裕はないけどそれでも使いたい」と思っていただけるようなサービスにしたいですね。スタートアップを支援したいという思いもあり、Kibelaは基本的に5人まで無料です！（宣伝）

「自分たちの持ちものをなるべく少なくしよう、得意な人に任せよう」という視点はツール以外にも適用しています。例えば、財務関連の業務を税理士さんにお願いしていたり、契約書等の話があれば法律事務所にその都度相談させてもらったりしています。自分が時間をかけて大して質の良くないものを出すより、お金がかかってもプロの方にお任せした方が、少なくとも自分よりは上手にやっていただける。そうして生まれた時間で、自分だけができることをやりたいのです。

しかし組織が大きくなってくれば、開発以外の業務量も増えていきます。社内に専任のメンバを置きたくなったり、自前でツールをつくったり、みたいなことがある程度起きるんだろうと考えています。が、それまでは持ちものは最小で。

サービス開発フェーズでの参考書籍

若干古くなっていますが、『リーンスタートアップ』は小さくサービス開発を始める方にとって必読の書ではないでしょうか。その実践編である『Running Lean ―実践リーンスタートアップ』や、サービス開発に関する基本的な考え方が紹介されている『Getting Real』もおすすめです（日本語版がなくなってしまって残念です）。

リリースまでに決めるべきこと

サービス名

サービスを開発し始めた当初は「Kintan」というプロジェクトコードをつけていました（以前の職場の近くにあった焼肉屋さんの名前です）。最初に1人でつくっていたものは、いわゆるアルファ版ですが、その後、社外のデザイナの方だったりエンジニアに入ってもらって関わるメンバが増えたタイミングで、デザインなどアルファ版でつくったものをいったん全て捨て、全員でコンセプトを見直しました。そのタイミングで、サービス名を考えることにしました。

サービス名を考える様子

まずは

• 情報共有サービスであることを表現する名前
• 使いやすいツールであることを表現する名前
• 何でもない名前であること

くらいの条件を決めて、ブレストのようにとにかくいろいろな名前を出していきました。出し切った後は、アイデアをまとまったカテゴリに分け、どういう方向性があるのかを確認します。

上手くいけば今後さらに新しいサービスを開発していきたいし、その際に一連のブランド名として成り立つように、といった展望を見据え、「Kibela（キベラ）」という名前にたどり着きました。キベラは“木べら”です、使えば使うほど手に馴染むツールであるようにという願いを込めています。

同時に、同様のサービス名が存在しないか、ドメインを取得できるか、検索で引っかかりやすいか、といったことも調査し、問題なさそうだったので無事決定となりました。それにしても名前を考えるのは難しい。

デザイン

デザインもとにかくシンプルで簡単に。誰が見ても使い方が分かるUI、使っていて楽しくなるUXを目指しています。

KibelaのUIの一部。

最初は支援してくれる会社のデザイナの方が協力してくれたので大変ありがたかったです。次に業務委託でお願いしたデザイナは前職で同僚だった方なのですが、その方が独立することになり、代わりとなるデザイナをまた紹介してくれました。今振り返ると、本当に人のつながりでサービスが立ち上がったのだと思います。

デザイナの方には大きな方向性を直接話し合い、ユーザ体験の設計やデザインの細かい部分は、ほぼお任せしています。違和感があるときは言葉に気をつけながらも、きちんと思いを伝え、話し合うようにしています。思っているのに言わない、というのは何も思わないよりも悪です。

サービスを展開していくに当たって、その世界観を表すデザインは非常に大事な要素です。しかし、こうした感覚を共有して一緒にやっていける人を見つけるのは難しいなあと思います。どうやったら良いのか、未だに答えはありません。

セキュリティ：プライバシーマークを取得

個人情報や非公開情報、クレジットカード情報等を扱わないサービスにする、というのが一番手軽そうですが、解決したい課題によってはそうもいかないので、何かしら対応が必要です。立ち上げ間もないスタートアップの場合、セキュリティに予算を投じるのは難しい、という事情もあるかもしれませんが、もしトラブルが起きたら一発で信用を失ってしまいますので、しっかりと取り組むべきでしょう。

弊社の場合は、組織内部の情報を扱うこともあり、まず会社としてセキュリティを高めること、社員が少ない時期からメンバがセキュリティ意識を持って運営していくことを目指して、プライバシーマークを取得しました。これも、セキュリティコンサルタント業務を行っている友人に仕事をお願いして手伝ってもらいました。また、サービスに関してもセキュリティ診断を行ってもらい、ある程度安全が担保された状態で、自分たちとしても安心感を持ってサービス運用を行っていきたいと考えています。実際、結構お金がかかるのですが信頼には代えられません。

利用規約

サービスを公開するときは、利用規約やプライバシーポリシーをつくる必要もあります。僕は知り合いの法務の方に草案をつくってもらった後、バックオフィス業務を総合的に支援してくれるAZXさんに英語版の作成を依頼しました。

利用規約やプライバシーポリシーのつくり方、運用のポイントを網羅しているのが書籍『良いウェブサービスを支える「利用規約」の作り方』です。なお、Kibelaの利用規約草案をつくって下さったのは、著者の一人である片岡玄一さんです。

いよいよリリース

さて、こういった諸々の作業を行い体制を整え、サービスリリースを迎えます。ここからがスタートです。

ティザーサイトをオープンしたら、数百チームの方々から申し込みがあった

いきなり正式リリースではなくベータ期間を取り、密なコミュニケーションを取れる範囲の方々と正式リリースに向けて完成度を高めながら進めていきたいと考えていました。

2016年5月頃に「2016年8月にベータリリースを行います、先行して試用いただける方はメールアドレスを登録してください」という1枚のページをつくりSNS等で共有できるようにして、メールアドレスはGoogleフォームでつくったフォームで集めました。自前で登録システムをつくると手間がかかるので、ここでもなるべく社外にあるツールを使います。

ベータ期間は知り合いがいる数チームに使ってもらえれば良いな、という程度に考えていたのですが、想定以上にはてなブックマーク等で盛り上がってしまい、結果的には数百チームの方々にご登録いただけました。「井原さん頑張って！」みたいな絶対将来のお客さんにならなそうな友人からの申し込みもたくさんありましたが（笑）。

ディザーサイトはもう存在しませんが、このようにはてなブックマークで予想だにしない（歓迎コメントばかりではありませんが……）盛り上がりが！

僕たちはこの時点でバズが起きると思っていなかったので嬉しい誤算でした。多くの方とコミュニケーションを取るのは楽ではありませんが、結果的にたくさんの反応やフィードバックをいただけました。

ベータリリース

そしてティザーサイトのリリースから約3ヶ月（この間にベータ版に必要な機能を頑張ってつくっています）、ベータリリースを行いました。登録いただいたメールアドレスの方々に、毎日少しずつサービスの登録URLをご案内していきます。

ベータリリース当初は、仮にとんでもないバグがあっても（知る限りはなかったですが）直接お詫びできるように、面識があったり、知り合いがいるチームを選んで登録URLをご案内していました。そこでいただいたフィードバックを元に微調整を行いつつ、徐々にご案内する範囲を広げていきます。申し込みいただいた方々全員にご案内し終えるまでに、2ヶ月程度をかけたと思います。もっと早くご案内したかったのですが、想定以上に多くの方にご登録いただいた影響があったかもしれません。その節はお待たせしてしまい申し訳ありませんでした。

正式リリース

2016年8月のベータリリースから約半年、引き続きいただいたフィードバックを元に実装を行ったり、正式リリース時には必要な機能を追加したりして2017年3月に晴れて正式リリースを行いました。ここで、どなたでも登録できる状態になったのです。

なお、Kibelaには約2ヶ月の試用期間があり、3ヶ月目から課金が発生するのですが、正式リリース時点では課金機能がまだ実装されていません。課金機能のように、実際にユーザが使うまで後ろ倒しにできるものは可能な限り実装を後ろ倒しにし、今やらないといけないことに注力したのです。リリース時点でつくり込みができなかった機能は他にもあるのですが、まずは自分たちのサービスがどんなものか試してもらえる状況を目指しました。

なお、実装の優先度は

• 機能の重要性
• 期限（特定のタイミングで提供しないと成り立たない）
• 手動運用で回るか（退会機能は自動にしたいが、最悪直接DBを触ってもできる）
• 代替手段がないか（頑張ってもどうにも解決できない）

などを考えタイミングを決めています。

サービスリリース後にすること

無事にリリースを終え、やっと走り始めることができました。しかしリリースはゴールではなくスタート。今のKibelaに何かしらの価値を感じてくださっているのなら、それをもっと磨いていきたいし、必要なものはまだまだたくさんあります。本当に、まだやりたいことの1%もできていない、という気持ちです。

お客様の声を聞く

お客様からのご意見は、主にサービス内チャットのIntercomというサービスを通していただいています。「使い方がわからない」「データの移行をしたい」「頑張ってください」等のお問い合わせをいただきますので、基本的にはメンバ全員でそれを確認し、適切なメンバが返答しています。誰からのお問い合わせか、というのが分かるので、知り合いの場合はその知り合いが対応することが多いですね。会話の履歴も残りますので、後から振り返ることも可能です。

自分たちのサービスを使ってくださっている方がいらっしゃるというのは、本当に嬉しいものです。「知り合いでもないのに、わざわざ選んでくださった」と思うと、本当に感謝しかなく、可能な限りご要望にはお応えしたいのです。しかし「こういった機能が欲しい」というメッセージをいただいても、ご要望をそのまま実装することはありません。この方は本当は何をしたいのかと考えることを大事にしています。

例えば「文書にタグをつけられるようにして欲しい」というご要望の裏には「情報をもっと簡単に探せるようにしたい」というニーズが隠れているかもしれません。そのため、いただいたご要望はいったんTrelloにカードを立て、後日メンバの間でどう解決すべきなのかを考えます。

Intercomのチャット以外でのお客様との接点は、Twitterの公式アカウント、各メンバのTwitterの個人アカウントでのやり取りが中心です。 「Kibela」等のキーワードのTwitter検索結果をIFTTTでSlackのエゴサーチチャンネルに流し、さらにBotによってSlack上から返信したりLikeしたりリプライできるようにしています。

公式アカウントからだけでなく、僕個人でも見に行って反応することが多いですね。

たまに悲しい気持ちになるツイートを見ることもありますが、それは僕たちが満足いただけるものを提供できていないだけです。いただいたご意見と同様に、「どんな課題が残っているのだろう」ということを考え、Trelloにアイデアなどを登録しています。

ユーザさんにとって、サービスの開発元に自分の思いを言語化してリアクションする、というのは、とても手間のかかることです。それだけに個別の事例に丁寧に対応すると、その後も利用し続けてくださることが多いように思います。引き続き、真摯に対応していきたいと思っています。

機能追加と改善

ユーザサポートの項にも書きましたが、お客様からいただいたご要望はSlackのBotに話しかけるとTrelloのFeedbackというリストに入るようになっています。また、こんなものがあったら良いんじゃないか、というメンバからの雑なアイデアもBot経由でTrelloのIdeaというリストに入ります。

基本的に、週次の定例MTGではこのFeedbackとIdeaに新規に追加されたものを確認し、対応を行うものはIceboxへ、現状対応を行わないものはFeedbackに残したままにしたり、不要と思われるものは削除します。要望があったり必要だと思われるものは再度カード化されるので、カードをガンガン追加したり削除したりしています。慎重にじっくりやるよりは、カジュアルにアイデアを出し合えるようにしているつもりです。

あとは、今までの開発と同様、Iceboxへ入ったものにPMが優先度をつけ、デザイナやエンジニアと徐々につくるものの解像度を上げながら（仕様等を固めながら）、各エンジニアが自分がやりたいカードを取って開発を進めていきます。誰も取らない（取りたくない）カード、みたいなものもときにはあると思いますが、そこは「今回は○○さんお願いします」的なコミュニケーションと共にお願いしています（あまりないですが）。

大きめの機能をリリースしたタイミングには、ブログを書いて周知しています。「こんな機能をリリースしました」というお知らせに加え、パーマリンクがあるとSNS等でのシェアや、お問い合わせをいただいた際にご案内することもできるので便利です。

お客さんを増やすための営業活動・広告配信

どんなに良いものをつくったとしても、サービスそのものを知ってもらわないと使ってくれる人は増えないでしょう。何かしらの手段で、多くの人が自分たちのサービスを知り、試してもらう必要があると思います。

GoogleのAdWords等のクリック課金広告は少額から始められるので、僕たちも現在少しずつ試しながら効果検証を行っています。他にも、Facebook広告やTwitter広告もありますし、自社のサービスと相性の良い広告手法を模索している最中です。

今は少しずつですがサービスの売上げも立ちつつあります。そろそろマーケティングや営業の方にも入っていただき、より多くの人にリーチすることを考えています。まさに試行錯誤している最中なので、これからもさらに力を入れてやっていきます、ということですね！いや～、やることがたくさんあります。

まとめ

僕たちはKibelaというサービスを開発、リリースするに当たって、こうやってきました、こうやっています、ということを書いてきましたが、まだサービスが最高に利用されているわけでもないですし、僕たちのやり方がベストだとも思っていません。どうしたらもっと上手にやれるかな、ということを日々試行錯誤している状態です。

自分が一番上手にできると思わず（そんなわけがない）、先人の知恵を参考にしたり、成功した方の意見を伺ったり、自分たちのやり方や考え方よりも良さそうなものがあれば、どんどん取り込んで試していくべきだと考えています。

こうやって改めて振り返ってみると、ある程度やり方が分かっているものから、初めてなのでさっぱり分からないものまで、多種多様なことを行ってサービスの開発や立ち上げ、運営をやっています。何が一番良いのか分からないわけですが、それでも、今一番良いと思える方法を選びながら、前を見て進んでいくしかないんだと思います。

自分が考えたアイデアをサービスとして自分で形にして、世の中に対してその価値を問えるエンジニアは、本当に素敵な仕事だと思います。僕たちは引き続き頑張っていきますし、皆さんが今後つくられる素敵なサービスによって僕自身や世界の生活がもっと楽しくて便利になることを、楽しみにしています。オンラインでもオフラインでも、どこかでお会いすることがありましたら、ぜひサービス開発についてお話を聞かせてください！

長文を読んでいただき、ありがとうございました！

著者プロフィール

井原正博（いはら・まさひろ） @ihara2525

株式会社ビットジャーニー代表取締役、個人の発信を組織の力にする情報共有ツール「Kibela」を開発中。
プライベートでは100マイルを走るウルトラトレイルランナーであり基本的に交通手段はランニング。各所へ走って移動するため、街中を走る姿を多くの知人に目撃されている。

編集：薄井千春（ZINE）