新規プロダクト開発のログ ~アイデアから開発チームが出来るまで

## モチベーション

いま作っているプロダクトが、アイデア着想から数えると1年6ヶ月かかってOpenβを公開できました  :tada: :tada: 
ここまでくるのに、めっさ時間がかかったので、何をどうするとリリースまで短く出来るのか、ログとふりかえりを書いておくと、アンチパターンとして誰かの材料になるように思ってます (私もめっちゃ参考にしました)

あとは宣伝半分です w

## 作っているもの

- [Hoppers | ホッパーズ](https://www.hoppers.team) というセールス向け、"チームみんなの営業ノウハウを共有できる" アプリを作っています (宣伝!!)
- 無料のベータ版ユーザーを絶賛登録受付中!!
- まだOpenβなので、Release Candidateを絶賛開発中です

## 開発タイムライン

これまでの開発のログを時系列で書いていきます。(ふりかえり) とあるのは、いまふりかえってみて思うことです。
あと、書いていると長くなったので、ここではアイデア～開発チームが出来るまでを書いてます。

### アイデア着想～MVP開発

#### 2016年8月

1. 当時、自社ではセールスの案件進捗表をSpreadsheetsでやっていたので、自社のセールスメンバーとイケてないよねぇ、という話をしていた
1. その会話で、案件情報をTrelloみたいにカンバンで進捗管理できれば最高じゃん!! というアイデアが生まれた
    - 通知もいくとレポートレスじゃん、とアイデアが膨らんだ
1. 市場としてはCRM/SFAという領域で、割と大きい市場だったので、ちょっとやってみようかという気持ちになる

#### 2016年9月

1. UIが革新的、というアイデアだったので、まずUIイメージを作って、MVPにしようと作業を始める
1. 当時Sketchやプロトタイピングツールの存在そのものを知らなかったので、どうにかパワポで画面を作って、画面をコマ送りしながら、スライドショーを動画にした
2. スタートアップやUXに強い [kenken](https://twitter.com/lorenzhart) を巻き込んで見てもらうと、"これ何が課題なんすかねぇ" という根本的な指摘を受ける
3. アイデアだけが先行してしまって、"逆に課題を探す" という順番になってしまった
- (ふりかえり) **"潜在的な問題意識から突如降ってきたアイデアは、課題の言語化にとっっっても困る (しかもだいたい外れる)"**

#### 2016年10月

1. 課題仮説を "セールスメンバーは感情をチームに共有できていない" として、その動画を知人友人に公開して、実際にインタビューし始めた
    - 通知ということだけで、ここまで発想を拡大した。。このあたり中二っぽい
2. 社外で3チームにコンタクトが取れたので、インタビューすると、当たり前だが、ツールではなくオープンなチームであれば解決できていた
    - 仮説課題は棄却された
3. 一方で、このインタビューから、"セールスメンバーは失敗も含めてナレッジを共有できてない" という新しい課題を見つけることができた
4. (ふりかえり) **"インタビュー大事。でも、新しい課題を見つけたら、課題があるかどうか何回も、たくさんインタビューをやること"**
    - 新しい課題を見つけて、インタビューに行かなかったため、今のOpenβリリースになって苦しんでいる

#### 2016年11月

1. "ナレッジを共有できていない" を解決するにあたって、そもそもナレッジを共有したいと思うのか検証すべく、自社のセールスチームの会議に参加してみた
1. 毎週の営業進捗報告だけの会議では発言が少なかったものの、メンバーが受注した背景を会議のテーマにすると、かなり発言が多かった (=メンバーはナレッジを共有したがっている、というのがわかった)
2. 次にどうやって解決するか、というところで、カンバンで進捗管理 + Slack連携すると、ナレッジが共有できると思い、Trello に chrome extension をいっぱい入れて、案件管理表を作った
    - なぜ、これが効くと思ったのかは、今思えば謎だが、初期のアイデアを捨てきれなかったんだろうなぁ
3. 自社のセールスチームで使ってもらったが、ナレッジは一向に共有されなかった
4. (ふりかえり) **"UIでなんとかなるという幻想はダメ、絶対"**

#### 2016年12月 ~ 2017年1月

1. どんなタイミングでナレッジが生まれるのか、ふりかえってみると、OKであれNGであれ案件が進捗したときにインタビューすると良さそう、と考えた
2. 試しに、自社のセールスメンバーに案件が進捗したときに、「どうやったの?」と聞くと、ほとんどで、工夫したことを教えてもらえた
3. この体験をプロトタイピングしようと、今度はパワポでなくMarvelを使った (Sketch使いたかったけど、残念ながら、あたしゃWindows)
4. Marvelで作成!! が、、肝心のプロトタイプをシェアすると、日本語がレンダリングできず、文字化けすることに気付く。。orz
5. Prottに課金してプロトタイプではなく、画面デザインを作った!!
    - なぜか、Web版もスマホ版も作った (デザインに夢中になりすぎ)
1. 社内でプロトタイプを見せると、まず社内向けに作ってみよう、となった (ヤター!!、有頂天!!)
- (ふりかえり) **"あくまでプロトタイプだからデザイン頑張るべきではない"**
    - ちなみに自分でデザインし始めると、この機能は他のアプリどうやってんだっけと、いろいろなUIを模倣すると、いろいろなことに気づけた

#### アイデア着想～MVP開発のふりかえり

- 課題から考える方が良さげだなーと思うんですが、アイデアから入ったほうが自分は熱狂しやすかったです
- アイデアから入るにせよ、課題仮説がないと "答え" をシンプルに、柔軟に変えられないと考えています
    - "答え" だけが決まっていると、解くべき問題は無限に増えてしまうので、結果、機能が増える
    - ex. UIが革新的! -> こんな機能が欲しい! と言われたら作るしかない
    - ex. 営業ノウハウを集められる -> こんな機能が欲しい! -> ノウハウ収集を軸に判断できる
- ユーザーインタビューはとても気付きが多いのだけど、ユーザーを見つけるのが本当に大変でした (セールス活動に近い)
- 結局、ユーザーインタビューを継続的にやることをサボってしまったので、Openβのときに、改めて仮説課題があるかどうか不安になってしまっている
    - このMVPまでのフェーズの課題仮説のテストのカバレッジが狭かった
- プロトタイプはあくまでプロトタイプ。デザインは全然あとで良いと思います

### 開発チーム組成と技術選定

#### 2017年2月

1. デザインがSPAだったので、当時話題を席巻していたReactで行こうぜ、と息巻いていた
1. 自社の開発チームにReactどう?って聞くと "なにそれ美味しいの?" 状態だった :scream: 
1. バックエンドは自社の他サービスも PHP/Laravel スタックだったので、それで進めることで決まった。が、リソースは掛けれられない、という状態
1. 旧知のエンジニア(副業OK)に声を掛けてみると、"いまちょっと時間が厳しいんだけど、バックエンドなら書けるよ" とOKもらう -> フロントの課題は残る
1. 同時に自社の開発チームにReactの勉強会に行ってもらうと、"JSX無理、わかんない" となって、いよいよフロントエンジニア探しに
1. 開発イベントを主催していたときに、参加していた学生たち(卒業済み)と飲む機会があって、そこに参加していた [:octocat: shuyuhey](https://github.com/shuyuhey) (副業OK) に声を掛けてみると、"modernなJSはやったことないけど、そろそろやるかなぁ" というところだったので、お願いできた!!
- (ふりかえり) **"SPAはReactなどという妄想に取り憑かれていた。他もあるよね"**
- (ふりかえり) **"とはいえ、技術的なチャレンジがないと、いいエンジニアは来ないよね"**

#### 2017年3月

1. ローンチチーム(外部)と、そのあとメンテチームが別だったので、メンテするときに学習コストが高すぎないことが一番の選定ポイントだった
1. フロントエンドはRiot.jsに決定
    - html/cssが混ざってる分、理解しやすそうというのが選定ポイントだった
1. ついでにcssは流用できそうなコンポーネントが多そうということで Materialize に決めた
1. バックエンドは PHP 7.0 / Laravel 5.3 に決定した
1. 外部でバックエンド書く旧知のエンジニアが本業で長期の海外PJにアサインされてしまった :scream: 
1. 自社開発のエンジニアにバックエンドに急遽、入ってもらった
- (ふりかえり) **"Riotでも何でもそうだけど、cssの影響を受けるので、コンポーネントをそのまま使える、ということはない気がする"**
- (ふりかえり) **"開発時間が長くなったこともあるが、学習コストは割と吸収できる、というより慣れる"**
- (ふりかえり) **"チームにフルタイムで開発できる人がいないと、初期は開発リズムが生みにくい (PullRequest->レビューがおよそ半日掛かる)"**
- (ふりかえり) **"Riot、エコシステムが、がががが、でも、いいぞ"**
- (ふりかえり) **"隣の芝生はいつまでも青く見えるぞ (React...Vue...)"**

#### 開発チーム組成と技術選定のふりかえり

- 手に慣れた技術 (ex. jQuery etc.) の方が開発スピードは出たと思います
- 実際、commit のグラフを見ていると、手に慣れるまでにバックエンド含め3ヶ月以上は掛かっています
- とはいえ、入ってくれた shuyuhey によって自社開発チームの開発レベルや文化は明らかに変わったので、ローンチ以降を考えると、何とも言えないです。。
    - 技術選定は自社の置かれている環境によるとしか言えない
- 技術選定は楽しい時間

というわけで、Openβ公開を機に、これまでの開発ログを書いてきました。
1つの記事にまとめるつもりが長くなってしまったので、次回は技術選定以降の実装以降のところを書きます。