私は 2019 年 3 月に NoSchool に CTO として転職し、ほぼ 2 年が経ちました。

ベンチャーに入社したら成長できる！といった言い回しはよく耳にしますが、

実際に何が成長できるのか、逆に何は成長しないのかを自分なりにまとめてみます。

成長とはなにか？

本記事で言うところの「成長」は以下の通りに定義します。

• 提供できる価値の幅が広がること
• 同じコストでより高品質な成果物が提供できるようになること

提供できる価値の幅が広がることとは、例えば

• 決済処理に初めてチャレンジして実装ができるようになった
• Web だけでなくアプリも実装できるようになった

といった成果物の種類が広がることを指します。

同じコストでより高品質な成果物が提供できるようになることとは、例えば

• 要件定義が上手になって、手戻りが少なくなった
• Firebase といった、低コストで開発できる手段を身に着けた

といった、同じ種類の成果物でもコスト面での改善が見られることを指します

※上手に MECE に定義できているかはわかりません

成長したこと(Before/After)【テクニカルスキル編】

フロントエンド

Before

• JavaScript の文法レベルの基礎知識は有している
• jQuery を問題なく記述できる
• Vue.js での SPA を構築はできるが、Firebase Hosting および Netlify でのデプロイのみ経験があり、また、Fat な Vuex などアンチパターンを踏みパフォーマンスの低いアプリケーションを作ってしまっていた

After

• Nuxt.js を用いた SSR アプリケーションを、AWS をインフラとして構築できる
• TypeScript でそこそこのモジュールや型定義を自前で構築できる
• jest を用いた自動テストを記述できる
• composition-api で状態管理にこだわった Vue アプリケーションを実装できる
• Lighthouse スコア向上のため、PurgeCSSやキャッシュコントロールを含めた包括的なパフォーマンス改善を行える
• Next.js の Incremental Static Regeneration を活用できる

パフォーマンス改善は優先度下げがちなので、SEOに紐づくことになっていくのは良いアップデートだなと思っています。

サーバーサイド

Before

• Symfony を使った PHP アプリケーション構築、Sinatra を使った Ruby アプリケーション構築
• 大規模なアプリケーションの設計はゼロから行ったことがなく、クラス設計の知見が薄い

After

• 設計手法を工夫することで、ベンチャーの変化に耐えうるような設計を自分なりに模索できる
• Laravel を用いて、認証・認可、バリデーション、バッチ、メール送信等を使ってベーシックな Web アプリケーションの要件を一通り満たすことができる
• PHPUnit を使った自動テストを構築できる
• SPA のバックエンドとして、API でのログイン・ログアウト管理を実装できる
• Pay.jpを用いた決済処理を構築することができる。実際にやってみるとわかりますが、気が狂うほど考えないといけないことが多いです

インフラ

Before

• AWS は EC2、S3、EMR、DynamoDB といったサービスの経験が断片的にあり、セキュリティグループやサブネットといったネットワーク構築は基本的な範疇で問題なく遂行できる
• Linux の基本的なコマンド操作は問題なくできる

After

• 基本的なネットワーク構築を完遂できた上で、CodeDeploy を用いた自動デプロイや、ECS をベースとしたコンテナ中心の環境構築、CloudFront を用いたキャッシュコントロールなども設定できる

品質管理・運用

Before

• Rspec を用いてテストコードを書くことができる
• PHPCS や自動テストの CI などは、他部署に設定していただいた内容を踏襲していたので、自分で決めたり、その内容の妥当性について考えることはそうなかった

After

• GitHub Actions を用いて、サーバーサイド、フロントエンドの自動テストを構築できる
• ESLint と PHPCS を導入できる
• 自動デプロイの設定を完了し、デプロイ終了時に Slack 通知する等の業務フロー構築もできる
• Sentry を使ってフロントエンドでのエラーログを収集できる

総じて

リードエンジニアが務めるような基盤構築に関われた

基本的に Web アプリケーションを開発しているチームにおいては、一部のリードエンジニアを務めるレイヤーの方々に、以下のような基盤を構築してもらっていることが多いと思います。

• インフラ・ネットワーク設計（AWS を使うか？AWS のどのサービスを使うか？整合性は結果整合性にするか？）
• クラス設計（アーキテクチャはなにか？）
• 技術選定（フロントエンド、サーバーサイドそれぞれ何を選ぶか？）
• 品質管理体制（QA チームを発足するか？Linter は？レビュー体制は？）

ベンチャーで開発していると、このレイヤーの基盤構築に関わることができ、それによって前職ではしなかった経験ができたように思います。

成長したこと【ビジネススキル編】

自学自習スキル

（Before はあまり覚えていないので割愛します）

After

• 利用しているライブラリの問題点があったときに Issue やソースコードを必要に応じて調査し、場合によっては PR を出すことができる（前職のときよりも、活動が活発な OSS を採用することが多いので、必然的に GitHub を参照するメリットが大きくなっている）
• Twitter で、技術分野ごとにその道を極めている（著書がある、新技術を率先して試している）方々をリストに入れてウォッチする（ある時点の発言だけ見ると流行に振り回されるので、そうではなく、線で見てどういったカテゴリの技術やフレームワークが伸びていくか見据えるイメージ）
• GitHub を定期的に調べて便利なライブラリが出ているか調べる（アプリのレコメンド機能がおすすめ）

総じて、自分が技術選定に関わることが増えたので、どうやって技術トレンドを追っていくかと、トレンドとの付き合い方が上達したと思います。OSS との距離感も、ここ１年ほどでぐっと近くなった実感があります。

要件定義スキル

Before

• 現職に入社して 1 年目の頃は、言われた機能をそのまま実装することで、リリース後に何度も考慮漏れしたり、バグを起こしてしまっていた（最たるものが、ゲスト質問というログインしなくても質問サイトに質問を投稿できる機能がありました。これはかなりデータをぐちゃぐちゃにしてしまった上にその後の新機能にも多く影響したので、反省点が多い機能でした）

After

• 要件の抜け漏れをリリースする前に気がつけるようになった（※理想パターンは要件定義の段階で気がつくこと）
• 要件自体は成立していても、そのままリリースすると既存のデータと不整合が起きたり、リリース後の機能拡張の余地を考えられていなかったりすると指摘できるようになった

以前より上達はしていますが、未だに間違えてしまうことはあります。特にデータの取り扱いに関してまだまだ事前に深く考察できるようになりたいと思っています。

問題解決スキル

（Before は割愛）

After

• 以前に比べて、なにか問題が起こってそれを解消するような機能を実装して欲しいとなったときに、それなら既存の SaaS を使って簡単に解決できますよ、といった「実装する以外」の解決案を提示できるようになったと思う
• • 自社メディアを運営したい → 入稿画面はmicroCMSで作ろう
  • 顧客からのよくある質問を集約し、フリーワード検索できる仕組みを作って欲しい →Zendeskを使おう
  • 画像を自動でトリミングしたい →imgixで自動でトリミングできるようにしよう
• フロントエンドからインフラまでバランス良くスキルが身についたので、バグや予期しない障害が起こったときに、なんだかんだいって解決できることが多くなった
• • Safari で電話番号を表示しているページだけ Vue Router のrouter.push()が効かなくなる？的な挙動を昔踏んだことが有って、それを解決したときは我ながらよく解決したなと思いましたｗ
  • Next.js10 のバグを発見して起票したり
  • AWS のテクニカルサポートを有効活用して問題解決できることも増えました

成長が難しいこと【テクニカルスキル編】

さて、成長したことばかり書いてしまうとフェアではないので、自覚している成長が難しいと思うことを書いていきます。

そもそも事業に関係ないスキル

こちらは当然ですが、事業に関係ないスキルは伸びないです。ブロックチェーンだったり VR といった、シーズ寄りの技術は弊社には無関係なので、そういったエッジの技術を身につけたいのであれば、そういう**最先端技術を持っていることそれ自体を差別化にしている企業**に入社するのが賢明だと思います。

参考記事

IT事業は「サービス」と「ソフトウェア」に分類でき、その分類によってDDDを適用すべきかが決まるのでは、という考察

*※一応補足。教育ツールにVRが使われる可能性が無いという意味ではなく、例えば弊社がVRを導入するなら、VRをAPI等で提供しているSaaSを使うはずで、VR技術そのものは扱わないだろうという意味です。そのため、私自身もWebRTCや機械学習をSDKやAPI経由で使う素振りは個人でやってますが、技術そのものに深入りするのは趣味の範疇でやってます*

事業規模から見て Too much なスキル

アクセス数月間 1000 万 UU といった規模感のサービスになると、大規模トラフィックをさばくためのインフラ技術が別途必要になるはずですが、そういったスキルは身につきません。むしろ、現実問題トラフィックが少ないことに甘えている場面はかなり多いです（かなり破壊的な変更を含むリリースをカジュアルに行ったりします。正確に言うとアプリケーション層のテストはするが、インフラ層のテストはほとんどせずにリリースしている感覚です）。

データ量も少ないので、バッチ処理も気軽に回しますが、これが 100 万レコード相手に回すバッチであれば実行方法をちゃんと考えないと本番 RDS を落とすことにもなりかねなかったりしますしね。

また、プロダクトの変化が激しいことで、今取り組んでもそのうち捨てるな、と思えるものには手を出さないことにしています。たとえば自動テストについても、コードベースのテストは回していますが、E2Eテストはまだ回していないなどです。

専門性が高いスキル

うまく表現するのが難しいのですが、フロントエンドでも、TypeScript4.1のTemplate Literal Typesを使った型芸とか、サーバーサイドならRustやCQRSを使うとか、そういった各領域のスペシャリストが触るようなレベルの技術は基本的には使いません（正直好奇心との葛藤はありますｗ）。

主な理由は以下のとおりです。

• ある程度枯れた技術を使わないと、仕様変更があってプロダクトに影響がおきがちだから
• 単純に実装時間、改修時間がかかるから（たとえばheadlessCMSの会社だとAPIにRustを使っても良い気はするけど、自社でフロントエンドも管理画面もアプリもやっている、となると手が回らないので枯れているLaravelを選ぶほうが妥当）
• あまりにも特定の領域で専門性を高めすぎると採用に影響するから

格安の代替サービスが存在するスキル

Too muchの話と同じですが、多額の初期費用が掛かってしまうようなスキルは身につかない事が多いです。ここでの初期費用は、開発コストとサーバー費用などのことを指します。

たとえば現状、リアルタイムチャットを速攻で開発し、サーバー費用も抑えて、フロントよりのエンジニアでもサーバー処理を組める、といった条件を満たすならFirebaseくらいしか無いのも事実です。つまり、リアルタイム通信を処理するサーバーを自前で構築して管理したい、みたいな欲求は基本的に叶えられないことが多いと思います。

ということで、格安の代替サービスが存在するスキルは、そっちのサービスを積極的に選択するので、身につかないことが多いと言えます。

※選べる技術に制限はある中で心がけていること

私が普段開発するとき、 【今後優秀な人が入社したときに活躍する土台だけはできるだけ作る】 ことは心がけています。

Laravel を API サーバーとして用いずに MPA としてまるっと作ってしまうと、フロントエンドに明るい人が入社したときに、まずは MPA を切り剥がすことから始まってしまいます。

基幹事業のインフラを全部フルマネージドな Heroku 等で作ってしまうと、インフラに明るい人が入社したときに、まずは Heroku を AWS に移行することから始まってしまいます。

こういった考えには賛否両論あると思うのですが、私としては【最新のフロントエンド技術は使わなくていいから、せめて SPA にはしておきたい】【最新のインフラ技術は使わなくていいから、せめて AWS で ECS や RDS を使ったベーシックなネットワーク構築はしておきたい】といった考えで進めることもあります。

*※SPA をやっている理由は、弊社のアプリケーションがリアルタイムチャットだったりリッチな管理画面が求められることが多いので、MPA やってるとしんどいだろうなと見越したという理由のほうが大きいです。ベンチャーで MPA やっている会社が悪いという主張ではないです*

*※ここでの発言は、先程のFirebaseを選ぶことがあるという発言とは少々矛盾しているので、ケースバイケースというように捉えていただければと思います*

成長が難しいこと【ビジネススキル編】

体系立てて学ぶこと

前職にいたときは、社内でエンジニアのスキルマップが策定されており、それに従ってスキルを上げておけば、ほぼ自然に昇給していける感じでした。

ベンチャーだとスキルマップは随時変わっていきますし、汎用的なスキルよりも、なんだかんだいって即時性のあるスキルが要求されることもあって、体系立ててスキルを学ぶ余裕は業務内では作れないと思います。

こちらの記事に昨年読んだ本をまとめましたが、ベンチャーに転職して、逆に基礎理論の勉強の大切さが身に沁みています。基礎がないと、次から次へと応用するタスクが生まれるので自分の引き出しがかすれていきます。

事業の100を101にするような改善施策を打つこと

当然ながら、思い切り0→1のフェーズなので、ページのほんの一部分のボタンデザインでABテストすると言った細かい改善はまだ打っていません。

トラフィックもばらつきがあってまだまだ少ないので、GTMでイベントを収集してRedashで分析して改善施策を打つ・・・といったこともまだ少なく、そもそもオンライン家庭教師という生き方をどうやって定義して広めていくかを進めている段階です。

何十万件といった大規模データを分析したい！といったスキルを伸ばすのはもっと先のフェーズになると思います。

まとめ

弊社は2021/01/12時点、代表と私の2名でやっています。

エンジニアの組織文化としてはOSS活動や、ブログ記事等での発信を積極的に推奨していきたいです。理由は簡単で、自分が普段からオープンソースやブログに助けられているからというのと、自分たちが関わっている技術の利用者が増えないと、回り回って自分たちに不利益が来るからです（廃れる）。

会社のテックブログを作っても寄稿するモチベが皆あるわけじゃないと思うので、開発メンバーが書いているブログサイトのRSSを統合して表示するだけのサイトを企業の公式テックブログとして公開したいななどと思っています。

また、テストコードやエラー監視ツールなどを活用して品質を保持していくことにこだわりがあるチームを作りたいです。もちろんビジネスを進めるのが最優先なのですが、事業のコアとなる機能はしっかり品質を保つ、プロトタイプ的にとにかく動かしてみようという機能はさっさと作る、というメリハリが大事かなと思います。

ということで本記事を読んで興味を持っていただいた方、ぜひご連絡ください！