見出し画像

クローズドαリリースに向けてSaaS企業のCPOがプロダクト開発体制の再編とFullstack TypeScript Blitz.js へ移行した話

Ryotaro Morikatsu

どうも、株式会社digsasのCPOを務める森勝と申します。

CPOを名乗っているものの、Web開発会社のExit、IoT企業での経営企画経験もあり、ファイナンス・プロダクト開発・採用・CSを中心に動いています。

おおよそ8か月前に、当社のCPOとしてジョインしてから、やはりスタートアップらしく、大きな決断をいくつもしてきました。

その中でも、特にインパクトの大きかったものが、開発スタックの移行でした。


簡単に書くと

2020年7月（ジョイン時）：Vue2(Nuxt.js) x Go
2020年9月：React(Next.js) x Go のDDD化
2020年10月：ReactのDDD化
2020年12月：Blitz.js（Next.js x TypeScript Node x GraphQL）
2020年1月：クローズドαリリース

という変遷がありました。


この8ヶ月の間に起きたこと

まずはじめに、当社では「変遷するビジネスにIT投資のモノサシを」持つためのSaaSとして、IT投資におけるSaaSの導入プロジェクト設計や、導入後の利活用評価、ビジネスへの影響の可視化などの機能を中心に持つプロダクトを開発しています。


これらの機能を組織に取り入れていくことで、「ビジネス部門とIT部門の垣根をなくしていき、誰もがビジネスを意識したIT導入を行うことができるようになっていく」のが、当社プロダクトの特徴です。


私がジョインした20年8月当時は、SIer出身のメンバーが開発&ディレクションを進めており、チームメンバーはほぼ副業メンバーの方々でした。

アイデアが機能仕様レベルに落ちていないケースもあり、副業メンバーの方々にも要件定義を手伝ってもらいながら、なんとか進んでいる状況でした。

ネーミングが揃っていなかったり、コミュロスによる想定漏れ、意図が伝わっていないスキーマ、CSSフレームワークママのUI、コードの端っこには、未だにあるHello World…


これはアカン……


私は火種の小さいうちにと思い、digsasのすべてにテコ入れをはじめました。


見えてくる課題

当時のdigsasには、大きく分けて３つの課題がありました。


1. プロダクトロードマップという名のアイデアボード

SaaS企業におけるプロダクトは、唯一の生産資本と言っても過言ではありません。ということは、ファイナンスに非常に影響が大きく、それは人員計画にも影響します。

digsasのプロダクトロードマップには、ビジョンドリブンの面白いアイデアが連なっていました。

しかし、そのどれもが繋がっておらず、また、なぜ実装すべきなのか、実装して良いのか？、リサーチ結果、などのログがありません。機能に対する工数予測はなく、実装は副業メンバーのスケジュールに依存していました。

これでは、事業計画や人員計画のフィジビリに説得力が出ません。


2. 意思決定のロジックが不明瞭

アイデアとは「〇〇ができたら良いな」レベルのもので良いのですが、これを実装するためにリソース投資をするとなると、何かしらの形でリターンが必要です。アイデアがリターンを得る仕組みになるための仮説検証をする必要があるはずです。

アイデアが出る
社内外にどんなインパクトがあるか仮説を立てる
リサーチやプロトタイプによる検証を行う
開発の意思決定をする

未来の自分たちやメンバーのために、車輪の再発明ならぬ再考にならないよう、このようなログを残すことが非常に大切です。


3. ビジネスと開発の乖離

プロダクトではIT導入状況・契約状況・ライセンス状況、などのデータを取り扱うため、慎重な設計が必要でした。

幸いなことに、副業メンバーは DevOpsに精通したインフラエンジニア・FinTechのコーポレートエンジニア・海外のGoスペシャリスト、など、バックエンド設計やCIに関しては堅牢になっていました。

1が不十分な状態では仕方がありませんが、堅牢な設計とビジネスの意思が反映された設計は必要十分ではありません。

このバランサーとなる人物が不在でした。


実際に行ったこと（歴史）

1. CI（コーポレートアイデンティティ）の掘り下げ

当初「日本のITレベルを世界標準に」というミッションだったdigsasでしたが、密なディスカッションを重ね「IT投資の意思決定における判断軸がないことが原因」というところに辿り着き、現在の「変遷するビジネスにIT投資のモノサシを（作る）」、というミッションを掲げ直しました。

※この話もなかなかに紆余曲折ありました。


2. アイデアの洗い直しと、再ログ化（on Productboard）

スプレッドシートやドキュメントに点在していたアイデアを、productboardというSaaSに統合しました。ロードマップベースで、工数把握ができて、Figma埋め込めたらなー、と思って探してたらありました。

そして、メンバーの時間を取って、アイデアが出た理由をいくつかの項目に絞ってヒアリングし、ログを書き直しました。


3. 経験上ニーズを強く感じる機能群でMVPのプロトタイプ制作（on Figma）

リサーチを十分行っていたものの中から、MVPの定義を決めました。

特に私は、ジョイン前まで事業会社のDX推進を行っていたため、ユーザー企業のターゲットと全く同じ層でした。

私がほしいと思うものは、大抵ダイレクトにリサーチと同じ効果を得られると踏み、機能の策定をしなおし、どんどんFigmaに落とし始めました。


同時に、digsasのカラーパレット・プレゼン資料マスタ・コンポーネント・フォントなど、対外のアセットをざっくり定義しました。


4. その他のアイデアは代表にリサーチを依頼

これは代表の得意分野なので、完全におまかせしました。

非常に良質なフィードバックが返ってくる（事実と仮説の切り分けが済んでるので私は聞くだけで良い。）ので、私の作業と並行しました。


5. Figmaベースで再リサーチ、社内ディスカッション

Figmaができあがったら、それを代表に持ってもらい、再リサーチをしてもらうフェーズを組みました。

個人的にはここまでのプロセスがあって始めて開発ができると思っています。

とりあえずやってみる、は宗教上できません、笑


6. 工数感の見積もりとロードマップへの配置

工数は1週間単位でざっくり出しました。あとはパズルです。

どのアイデアを
いつ
どのように
どれくらいのレベルで出すか

もちろんフィードバックをもらいながら増減することもあるので、キツめのスケジュールではなく、8割くらいの感覚です。


7. 事業計画・人員計画、バックオフィス系サービスの見直し

一番大事なので、知人にも壁打ちさせてもらいつつ、計画を立て直しました。

スプシで簡易的なPLの予実を立てる
CF不足時期を洗い出す
セールス計画（実現可能なミニマムと理想の成長曲線）と資本政策を立てる
販管費のざっくり勘定で人員計画を立てる

当社の週次定例会では、これを毎週ピボットしています。

バックオフィスには使い慣れたfreeeを入れ、できるだけ最低工数で分析できるよう、仕訳のタグ付けのルールを整備。


8. リリースに向けた記事およびHPのデザイン

利権や規約関連の調査と、打ち出しのライティングを代表と進めました。

実際にできあがったデザインはこちら。


9. Productboardに並んだアイデアと工数を見つめながら、ざっくりERDをデザイン…

既にあったOpenAPIを見ても、table設計を見ても、ビジネスの意思が反映されているようで、開発都合な状態になっていました。

私がFigmaで画面をデザインしながら、ERDまでざっくり検討したほうが今は良いと判断しつつも、実装者以外がERDを書いてから実装に落とすと、コードとドキュメントのダブルスタンダードになるという指摘を、副業メンバーから受けました。

確かに…

しかも、コードベースでドキュメントのジェネレートとかできるのか…などと、久々の開発現場に意気揚々とした私は、ERDを書くのをやめ、今ある設計を拡充してもらう方針で進めることを判断しました。

私はフロントエンド寄りの人間なのでVueを触りつつ、Goは勉強しながら読めるようになれば良いと。


Vue2 から React への移行と、Clean Architecture化

実は今回の記事は、当社も仲良くさせていただいているログラスさんの記事に触発され、そういえばうちもめっちゃ変えたな〜〜と思って筆を取ったのがきっかけです。

Vue2 の良いところは、学習コストの低さゆえの誰でも書けること。ちゃんと設計すればパフォーマンスも良い。


しかし、BtoB SaaSにおいて、誰でも書けることは、ロジックの破綻と負債に繋がります。

フロントの初期設計もなく、レビューワーがいなかったこともあり、一寸先の闇が既に見えていました。


Vue2には慣れていたものの、MVPで実装することを決定したドローイング機能や、大量のデータ処理を考えると「React」の方が良いと考えました。


そして、Domain層、Application層、Infra層、Presentation層くらいの簡単な設計を行い、各メンバーにフロントも書いてもらう方針に舵を切りました。


初DDD（と言ってよいのか？）でしたが、一回これにすると、もうこの設計しか思いつかないくらい良いものですね。

MVCやFluxに比べてコード量は相当増えるんですが、切り分けが十分にできていて、ユニットテストも楽なので、作業スピードが非常に早くなりました。

しかし、次に待っていたのは、中々進まない採用の課題でした。


採用が全く進まない

私がGoに不慣れなため、勉強を進めていましたが、書ける人が来てくれるならそれで良いのです。

私はそもそもCPOとしてジョインしているので、CTOの募集とともにテックリードなどの募集を始めました。


ところが、コーポレートエンジニアを採用していくにあたって、Reactにも精通したGoエンジニアは希少です。

なぜならフロントエンド出身でバックエンドを学びたい層は珍しく、またGoを書きたい層がReactを書くのは、当社のようなリソース不足のケースが多いと思います。


両方書きたい！
digsasのビジョンにも共感！
スタートアップ万歳！
条件もOK！

という気概を持ち、当社の採用方針にマッチするエンジニアはなかなか見つかりませんでした。


自分が不慣れだからGoエンジニアを探すのか？

バックエンドを副業メンバーに依頼していたため、私の時間も使えるフロント実装の方が早く進みすぎてしまい、待ちの状態が続いてしまいました。

とにかくリリースして、仮説検証のサイクルを進めたい中、このロスは素直に飲めません。


エンジニア採用が進まないうちは、私が寝る間も惜しんでGoを勉強することも覚悟してました。かと言って、それでロスをなくせるのか？という葛藤が生まれます。

私が付け焼き刃で勉強したところで、リリースしてDBが壊れた、APIに不具合が出た、となったらすぐ直せるでしょうか？


私が不慣れだからという理由で、あと数ヶ月後のリリースまでにGoエンジニアの採用投資を本格的に始めるのは、本当に正しい選択なのか？


そもそも、Goである必要はあるのか？


二言語分のスキルを必要としつづけることは、コミュロスリスク・コスト増加に、つながり続けるのではないか？


エクイティと引き換えてまで必要な運営コストなのか？



そんなことを考えているうちに、ふと思い出しました。

この世には、 Node.js とかいう大発明があります。


シングルスレッドでの可用性、TypeScriptでNodeが書けるか、Next.jsとの相性、DBとの相性、セキュリティ、その辺がクリアできるのなら、今あるコードを全捨てしても数ヶ月で取り戻せるのでは？


そんな淡い期待を胸に調べ始めました。


Blitz.js という Fullstack TypeScriptへの移行

ありました。


他にもいくつか似たようなプロジェクトはあったのですが、スポンサーがついていること・Star数が急増していることなどから、当時は、まだα版だった中、手元で開発の検証をしてみました。

想定している大抵のことには対応ができているのは、Blitzくらいでした。（また、仮にプロジェクトがなくなってしまっても、依存の調整と再構築でリカバーできそう）

Node.js作者によるDenoやそのFrameworkも気になっていたのですが、すぐにはNodeモジュールの互換性が効かなそうなので、あくまでNode製にしました。


（mizchiさんの記事に非常に丁寧にまとまってます）


そして、もともと作っていたDDD構成と統合し、OpenAPIからも離れ、きれいにLayeredになっていたGoから脱しました。


現在のスタックは、以下になります。

の地味にRecoil使ってますが、超絶複雑ないわゆるフロントの状態管理はありません。DDDできれいに解決済み。

そして、こんなことになりました。


控えめに言って最高の選定だった

スタートアップ初期のWeb開発現場に2つの言語が存在するケースは相当なコミュロスを覚悟すべきです。


コミュロスをなくすために割いている努力は多いと思います。

OpenAPIなどを社内で使っていたことなどもその一種。まず、それがなくなりました。

コードをシングルスタンダードとして見れる状態です。


そして、アプリケーションの95%はTypeScriptで書ける・読めるので、TypeScriptが書けるエンジニアなら、すぐにでもジョインできる環境が作れました。


また、静的型付けが付くことでSchemaの変更をした時点で、フロントエンドまで Type Error が発生するようになり、バグがほとんど出ません。


しかも、GraphQLのmutation/query毎にエンドポイントが分かれる仕様で、ヘルスチェックやユニットテストもしやすいため、必要最低限のテストで良くなりつつあります。


その上で、DDDによるロジックの配置にこだわっていることで、追加・削除が高速でできるようになりました。


中でも一番よかったこと

2020/1/4にα版リリースをしてから、上場企業を含むお客様に使い始めています。

頂いたフィードバックを高速で反映することができ、お客様のより良い体験に繋がっていると確信を持って言えます。


計画より多くのアイデアを取り込みながらも、既にQ2に計画していた機能をリリースしはじめることができ、当初の想定より1年ほど早くβ版を出せるのではないかというレベルです。

むしろ事業計画を詰める方向で修正を進めるべきで、圧倒的人材不足が次の課題になりそうです。


まとめ

結果からしたら、良いことづくしでした。

MLのためのPythonなど「あえて役割を分けやすい」言語選定をすることももちろんあります。


しかし、言語は言語。

特にスタートアップにおいては、多言語コミュニケーションになってしまうより、みんな英語のほうが良いはずです。

そして、フロントエンドは今の所JavaScript（TypeScript）しか選択肢がありません。


後からリファクタが必要になってしまうことももちろんあるかもしれませんが、アプリケーションをシンプルに保つには、静的型付けを一言語で行える環境を作ること、にあるのかもしれません。


当記事が絶賛お悩み中の創業予定者・プロダクト関係者・開発リーダーの方々のご参考になれば幸いです。



※先も書いていた通り、圧倒的人材不足が次の課題になりそうなので、読んでいる方々の中に、当社のビジョンに共感し、TypeScriptをそれなりに書けるよ、という方がいれば、ぜひ話しましょう！

お問い合わせからいただければ、すぐご連絡させていただきます。


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