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

エンジニアがサービスのアイデアを思いつき、それをリリースするまでにはどのような過程があるのでしょうか。情報共有ツール「Kibela」が世に出るまでのフローを、起業した井原正博さんが詳細に振り返ります。

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

ヤフーやクックパッドでの開発を経て、ビットジャーニーで代表を務める井原正博(いはら・まさひろ/@ihara2525)です。プライベートで超長距離のランを楽しむかたわら、情報共有ツール「Kibela」の開発・運営を手がけています。

1Kibela - 個人の発信を組織の力にする情報共有ツール

「Kibela」は僕自身が2015年に起業して立ち上げたサービスですが、この記事では、僕がサービスをいかに開発したか、その方法からリリースまでの過程を振り返りつつ、サービスの現在の状況までお伝えします。

「自分でもサービスを立ち上げてみたい」「プロダクトがリリースされるまでのフローを知りたい」といった方々に対して、一つの事例として何かしらの参考になれば幸いです。可能な限り具体的な事例を赤裸々に書いていきたいと思いますので、よろしくお願いします。

サービスをつくる準備をする

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

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

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

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

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

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

前職のクックパッドには「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という感じですが)。

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

もしクックパッドのサポートがなく、メンバを集めるとしたら……?

僕の場合は自分でサービスがつくれたので、引き続きしばらく1人で開発していたと思います。仮に自力で開発できなければ誰かにお願いすることになると思いますが、お金の問題なども考えなければいけません。

サービスを作る経験が少ない中、1人でやるとしたら

  • Webサービスのつくりかたを勉強する
    • サービスを立ち上げた経験がなければ、自社サービス開発を行うような大きな会社に入り、サービス開発の進め方を学んでみる、というのも良い経験になるんじゃないかなと思います
    • 僕自身もヤフーで多くの人と出会い、いろいろなことを学ばせてもらいました
  • もしくは独学で基本を身につけたあと、設計やソースのレビューをお願いできそうな「師匠」を見つける
のいずれかを選ぶような気がします。

サービス開発の進め方を体系的に分かっていないと難しい部分や、勉強することがめっちゃあったりするので、困ったときに質問できる存在があると、非常に助かると思います。

お金はどう用意する?

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

僕は「スタートアップだから給与が低いのは仕方がない」とは思いませんし、能力が高い人と働きたいと思っているので給与も高めにしたいです。そうすると人件費が支出の多くを占めてくるわけですが、その他オフィスの賃料や、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)なりの既存のツールを使っていくことになります。

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

ツール名 説明
G Suite メール、各種ドキュメント
Slack コミュニケーション
Kibela 社内情報(投稿ができるまではQiita:Teamやesa.io)
GitHub コードの管理
Zeplin , Abstract デザイン
Zoom ビデオ会議
SideCI 自動コードレビュー
Trello タスク管理
CircleCI CIツール
New Relic パフォーマンス監視
Datadog モニタリング
Mixpanel サイト解析
Intercom CRM

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

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

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

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

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

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

サービス名

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く