見出し画像

創業期から約4年関わっていたスタートアップを退職

walkersumida

創業期から関わっていた株式会社マツリカを2月で退職しました。自身の振り返りの意味も込めた退職エントリーです。

本投稿の最後にこの4年で気づいたことをいくつか挙げてみました。誰かの役に立てればと思います。

簡単に自己紹介

学生時代からITベンチャーでプログラマーを3年弱行い、新卒で東芝情報システム(SIer)に入社。2年後に退職し、独立を試みるも失敗。その後マツリカと出会い意気投合し創業期から関わる。営業支援ツール「Senses」の設計から開発、運用までを行う。3年目には新規プロダクト「Notia」を0から立ち上げ、最終的にはNotia事業責任者兼Sensesプロダクトマネージャーに従事。事業の成長に必要なことは一通り経験。また、五反田のRubyコミュニティ 「Gotandarb」のOrganizerも務める。

関連リンク: @walkersumida, GitHub, Wantedly, Gotandarb

振り返り

大手SIerから独立→失敗→スタートアップへ

新卒で東芝情報システムに入社し、ヘルスケア関連のシステム開発や導入に従事していました。しかし、学生時代にITベンチャーで働きWEB系サービスに魅了されていた影響もあり、自分でサービスを作り世の中に広めてみたいと考え、2年で退職しました。

その後、アイディアを形にするべく一年間開発し投資家のところにプレゼンに行きましたがボロボロに言われて、起業のノウハウを学ぶためにベンチャーに入ることにしました。

そのとき、スカウトメッセージをもらったのがマツリカでした。出会ったその日に代表の飯作と意気投合し他のメンバーにもすぐに会ってほしいと言われ、なんだかんだで4時間も話し込みました。そのあと、熱い握手を交わしjoinが決定しました(笑

エンジニア社員としては二人目だったので、ここから鬼のようにSensesの機能開発をすることになります。

エンジニアとして周りに追いつくのに必死だった1年目(2016年)

1年目はとにかく、開発スキルを伸ばすために必死だった記憶があります。朝から晩まで毎日開発に明け暮れました。できないことはとにかく一秒でも早く出来るようになりたい性格なので、必要とあらば土日も自主的に開発してました。そしてなにより、プロダクトに貢献したかったというのもあります。

このとき主に使っていた技術はRailsとAngularJSです。マツリカに入る前は、SPA構成での開発をしたことがなかったので始めは結構苦労しました。また、SensesはSFAなので、営業の業務知識が必要でした。しかし、これまでエンジニア一筋でやってきた私は当然営業経験0だったので、この頃は渡された設計書通りに開発を行いました。

エンジニアとしての活動範囲を広げた2年目(2017年)

1年半ほどSensesの開発にコミットし、エンジニアとしてスキルが格段にあがり、Sensesの仕様もほぼわかるようになりました。そんな中、少し新しい刺激が欲しくなり20%ルールがやりたいと直訴しました。アイディアの種となったのは、Sensesの機能で評価が高かったメール連携の部分でした。メール関連の機能で更にユーザに価値を与えられる何かが生み出せないかと、一緒にやることになったNo.1セールスの久保(@fumitakakubo)と模索して生み出されたのが、このあと出てくるNotiaです。

もちろん、この20%(週1日)ルールは全員が出来るものではなかったし、結果がでなければすぐに中止されるというプレッシャーの中はじまりました。正直週1日で開発できる機能は限られるし、簡単に中止になることが目に見えてしまいました。そこで、私の得意技である土日稼働を実施しました(笑

そう、気づいたらいつの間にか20%ルールではなくなっていました。

エンジニアは私しかいなかったので、開発周りはすべて1人でやりました。0から開発をしてみると、足りないスキルが山程ありました。インフラ、セキュリティ、Google Gmail API...etc. それらの知識の取得もとにかく土日でカバーしました。

残りの稼働日はもちろんSensesの開発を行っていました。1年目とは違い、技術面からこういう仕様にしたほうがいいのではないかと提案を多くするようになったと思います。また、大きな機能を一人で開発できるようになり、設計からリリースするまでの責任を負えるようにもなりました。

ユーザ視点に立った開発の重要性に気づいた3年目(2018年)

Notiaのベースがある程度出来上がり、あとは正式ローンチに向けて本格的な負荷対策をする必要があったため、Notiaにコミットする時間を増やしたいと、また直訴しました。なんとかお願いが通り、追加で必要な開発を行いました。

このとき大変だったのは、データ量やリクエスト数です。インフラをうまく構成しないと、すぐにダウンすることが予想できたので、色々試行錯誤しました。

また、知り合いなどの一部ユーザにβ版を配布しました。フィードバックをもらうため、ヒアリングもおこないました。いただいた意見も参考にしながら、開発をすすめました。

そして2018年12月12日に無事正式ローンチ。その後Twitter上でも続々と話題になり、多くの嬉しい声をもらうことができました。これが私と久保のモチベーションになっていました笑（Twitterで「notia.io」で検索してみてください！）

ローンチがゴールではありません。更にユーザ視点に立つために、チャットでのCS対応もちゃんと行うことにし、ユーザの声を直接聞き取れるようにもしました。もちろん、これも私が対応しておりました(笑

CSをやる前は、結構ボロクソに言われるイメージを勝手に持っていたのですが、Notiaのユーザさんたちは、心温まるメッセージを送ってきてくれる方が多く、CSに対するイメージがガラッと変わりました笑

もちろんご立腹のユーザさんからも問い合わせが来たりすることもありました。でもCSとして最後は必ずファンにしてみせる、という思いでコミュニケーションを取りました。自分が怒っているとき、どうされたら気持ちが落ち着き、納得できるかを考えながら言葉を選んでいました。これもすごく貴重な体験だったと思います。

更に、久保の営業にも同行し、直接ユーザさんの声を聞きにも行きました。ここでも学ぶことが多く、営業初心者である私はいきなり本題に入るなど今考えると恥ずかしいことをたくさんしてました。営業は難しいですね笑

3年目は、Notiaの開発を通して、ユーザ視点に立った開発の重要性に実体験から気づくことができました。始めは一緒に企画していた久保が欲しがるものをとにかく開発しました。数人を満足させることができないプロダクトがいくらスケールしてもユーザ数は増えませんし、満足させることもできません。また、スケールするのが早すぎると色々な意見、要望が来てしまうので、自分たちが混乱しプロダクトの方向性がブレる要因にもなります。その点ではNotiaはうまく歩んでくることができたと考えています。

最終意思決定をたくさんした4年目(2019年)

Notiaローンチ後はSNSで拡散されたり、ご縁もありバウンシーさんにも取り上げてもらったりしました！

そして、ローンチ後のビック機能リリースはSlack連携強化！重要と判断されたメールをSlackにリアルタイムで届け、さらにSlack上から返信できるという機能です。これは、完全にSlackトレンドの波に乗せてもらいました。そのお陰で日経にも取り上げられ、日本の多くのビジネスマンにリーチすることができました。

Notiaの開発が落ち着いたので、そこで得られた経験や知識をもとにSensesのPdM(プロダクトマネージャー)も兼任することになり、一人で開発していた環境からチームを持つことになりました。やはりチームって良いですね笑

メンバー構成は、デザイナー、エンジニア、QAエンジニア、そしてPdMです。マツリカの場合のPdMの定義は幅が広く、企画から設計、プロジェクト管理などを行っています。

PdMで重要なのは、何(What)を作るのか？なぜ(Why)作るのか？この2つに大きな責任を持つことです。なので、仕様の最終意思決定にも必ず関与します。ここの判断を誤ったまま開発がスタートしてしまうと、後工程にいけばいくほど仕様変更に工数がかかってしまいます。なので重要なのは、ある程度動くものができたら、開発環境を使ってユーザ(社内のメンバー)にヒアリングし、ちゃんとユーザが欲しているものを作れているかを適宜確認することです。早い段階で仕様に誤りが見つかったとしても、本番にリリースしてから気づくよりは遥かに工数を無駄にしなくて済みます。これは積極的に行うべきです。

それと、ユーザが欲しいと言った通りに開発したとしても、実際に動くものをユーザに使ってもらうと、「んーなんか違う」という反応になることはよくあります。なので、重要なのは実際に動くものを早い段階で使ってもらうことです。良い意味で、ユーザが欲しているものをそのまま鵜呑みにして開発するのは避けたほうがいいです。

そして、2019年の最後の大仕事は、Notiaのセキュリティ審査突破です。NotiaはGmail APIを利用しているのですが、ある時期からGmail API利用の審査が極端に厳しくなりました。どのぐらい厳しいかと言うと、第三者であるセキュリティ会社にセキュリティチェックを行ってもらい、セキュリティホールがないことを証明してもらわなければなりません（しかも結構な額がかかりました・・・）。そして、そのセキュリティ会社はGoogleが指定した数社なので、全部アメリカの企業です笑

実際にAWSの監査用のアカウントをセキュリティ会社に提出するなど、本格的に行いました。やり取りが英語なのと、時差が-16時間というのにもだいぶ疲弊させられました笑

この審査を通して、ハッキングされないように最大限の防御をするのは当たり前なのですが、もし万が一ハッキングされた場合にいかに被害を最小限に食い止められるか、そんな構成や仕組み、組織体制にすることの重要性を学びました。セキュリティに終わりはなく、常に新しい攻撃手法や、脆弱性が生まれてくるものなのですが、Googleが定めるセキュリティ基準を満たしているというお墨付きをもらう事で、安心と自信を手に入れることもできました。

気づいたこと

ここに来るまでにだいぶ文字数が来てるので、気づいたことは箇条書きにして、別途記事を書きたいと思います！@walkersumida でnoteを投稿したら発信しますので、興味があるかたは是非フォローをお願いします！

- 動くものができたらすぐにフィードバックをもらう体制にする
- スコープの範囲を適切に切ることの重要性
- 正しいものを最速で作ることの難しさ、重要性
- ソリューションではなく課題が重要
- ユースケースベースの開発(ミニマム問題)
- 誰のために開発する機能なのかを考える
- 競合を調査することの重要性
- 継続の重要性

退職理由

ここまで書くのにだいぶ疲れてしまいました笑

読んでくれた皆さんにも感謝です！

退職理由は、色々なタイミングが揃ったので辞めただけで、マツリカに対して不満はありません。振り返りを読んでいただければわかると思いますが、だいぶ自由にさせてもらったし信頼もしてもらってました。本当に感謝です。

今後

今後は、また素晴らしいサービスを0から開発するために奮起します！進展があり次第、発信していきます！引き続きよろしくお願いいたします！(@walkersumida)（あっさりですみません笑

この記事が参加している募集

退職エントリ

2,477件

この記事が気に入ったらサポートをしてみませんか？