メンテモエンジニアリング

Engineering at Mentemo Inc.

Chakra UI 2年目のあれこれ

Chakra UI 使ってますか？

お久しぶりです、メンテモの @Qrymy です。書こう書こうと思っている内に時間が過ぎて、気づけば前回のエントリから2ヶ月が過ぎようとしています。今日はこれまでの記事とか少し毛色を変えて、メンテモのフロントエンドについて皆さんにお伝えできればと思います。

掲題の通り、皆さんは Chakra UI を使っていますか？メンテモは使っています。なんと Chakra UI をメンテモのリポジトリにインストールしたのは 2020年6月5日 ということなので、Chakra UI キャリアは2年ということになります。v0.8.0 というバージョンでした。この2年のキャリアを生かして、Chakra UI のあれこれをご紹介します。

メンテモは Chakra UI を導入してよかったです。少なくとも、React / TypeScript 環境でフロントエンドをやる上で有力な選択肢の一つになるのではないかと思います。

そもそも Chakra UI とは

タイトルから走ってしまいましたが、そもそも Chakra UI が何なのかご説明します。一言でいうならば、CSS 属性を Props として渡せる React 向けのコンポーネントライブラリです。特徴は Tailwind CSS にインスパイアされた Utilify first と、TypeScript で開発されていることであると言えます。

コード実例

つまり、面倒な CSS と一定の距離を置くことができる コンポーネントライブラリです。 chakra-ui.com

なぜ Chakra UI か

登用したのが2年前のことになるので、もうだいぶ記憶が薄れていますが、なぜ我々が Chakra UI に決定したかをお伝えできればと思います。一般的に React でスタイリングをするとなると、以下のような選択肢から選ぶことが一般的だと思います。

まず、スコープを絞れないという観点で純粋な CSS を読み込むという選択肢はなくなり、CSS Modules はコンポーネントをスタイリングする際に参照すべきファイルが増えること、型定義を効かせることが難しく (可能な方法があったら教えて下さい) typo が発生した場合に気づかずにスタイルが非適用というリスクがあるため選択肢から外しました。

残るは、CSS in JS / CSS フレームワーク / コンポーネントライブラリですが、最終的には TypeScript との相性で決定しました。Chakra UI を使うことで既存の Linter/Formatter エコシステムで容易にコードの品質担保が可能なこと、Props base であることから typo やミスに気づきやすい (tsc が落としてくれる) ことから Chakra UI を導入することに。当時、まだ v1 に達してもいないライブラリをメインに使うことは今考えると恐ろしい意思決定だと思います。(今同様の状況に直面したならば、確実に選ばないでしょう...)。とりあえず、人気が出てメンテナンスし続けられるライブラリになってくれて一安心です。

Chakra UI を使う上でのイロハ

ここからはせっかく2年間も Chakra UI を使っているのでちょっとしたおトク情報をお伝えできればと思います。

Props を並び替える設定を入れよう

ご存知の通り、Chakra UI は JSX の Props にスタイルを渡していくことになります。シンプルな (≒ あまりスタイルを当てる必要のない) コンポーネントならまだしも、複雑なコンポーネントになるととんでもない量の Props が発生することになります。またかんたんに padding と言っても、paddingX px paddingLeft paddingRight などなど大量の Props が存在します。これらがバラけた箇所に点在していると、スタイルの重複やコンフリクトが発生しやすくなります。そこでメンテモでは、ESLint の react/jsx-sort-props を有効にして、Props の順番を整列しています。

アップデートは慎重に

Chakra UI はまだまだ新しいライブラリなので、アグレッシブなアップデートがしばしば行われます。major version のアップデートについては Migration Guide が出されるのでまだマシですが、minor version のアップデートに罠が潜んでいます。詳細は覚えていませんが、Chakra UI 内部のプロパティの初期値 (たしか flexbox 関連のなにか) がサイレントに変更され、それを知らずに Renovate が出した PR をサクッとマージした結果、本番環境のレイアウトが大変なことになったという事件もありました。当たり前ですが、スタイルのあれこれは CI で落とせない (ビジュアルリグレッションテストなどを導入していない場合) 上に、ユーザ体験にクリティカル・ヒットするので怖いです。

Spacing は 4 を掛けよう

Chakra UI だけではなく Tailwind CSS もそうですが、最初は Spacing の数字がとっつきづらいと思います。「2 とか 4 とか 12 とかなんだそれ」という気持ちになって面倒くさくなる人も多いのではないかと思います。これだけ覚えると Chakra UI がぐっと楽になるので教えると、「4 を掛ければ px になる」です。2 => 8px, 4 => 16px といった具合に、Figma などのデザインを Chakra UI で実装するときはこれを覚えておくと楽になります。また、Chakra UI の Spacing は number 型で渡すよりも string 型で渡した方が吉です。これは推論が効くので、Default Theme の Spacing にあるかどうかわかるからです。Chakra UI の場合、Default Theme の Spacing に無い値を渡すと、px として解釈してしまうので思わぬデザイン崩れにつながることがあります。

まとめ

まだまだ書けることはたくさんあるのですが、ちょっと長くなりそうなので今日はここまでとします。以上、メンテモ内の古参ライブラリ Chakra UI についてのご紹介でした！

メンテモが Vercel を剥がすまで (移行作業編)

engineering.mentemo.com

この記事は↑の記事の後編です。 前編からだいぶ日が空いてしまいましたが、今回はメンテモのWebアプリケーションがVercelからCloud Runに移行するまでの実際の作業を紹介します。

はじめまして。 @itometeam です。メンテモで業務委託として開発全般のお手伝いをしています。

メンテモのWebアプリケーションはフロントエンドにNext.jsを使っています。 元々は例に漏れずVercelを使っていましたが、スケールするにつれてどうしてもボトルネックになる部分が増えてきたため別の環境に移すことを検討し始めました。

もちろんVercelはNext.jsのデプロイ先として今後も一番の選択肢としてあり続けると思います。 Webサーバをクラウド上に構築する上で意識するべきことをほとんどおまかせでやってくれますし、プレビューURLの自動生成など開発体験においても優れています。 メンテモがVercelの利用をやめた理由は前編のとおりですが、この記事はVercelに文句をつけるものではなく、あくまで同様の対応が必要になった場合の参考として読んでもらえればと思います。

移行先の選択

移行先の選択肢はたくさんありますが、メンテモではもともとWebアプリケーション以外がGCPに載っていたのでWebサーバーの移行先もGCPに統一することにしました。

Vercelは動作環境とCDN、ビルド環境など様々な要素を含むため、同様のことをするためにはGCPのサービスをいくつか組み合わせる必要があります。

Vercelからの移行を完了させるには最低でも以下の機能の代替を探す必要がありました。

ちなみにVercelは各Pull Requestごとに自動でプレビュー環境を作ってくれますが、これは今回の移行では見送りました。

サーバーをどこに載せるか

実際にNext.jsのサーバーを載せるインフラについてはCloud Runを選んでいます。GAEも選択肢としてあがりましたが、マシンスペックの選択肢が多いことや実行環境に縛りがないこと、スケーリングの自由度が高いことを勘案してCloud Runに決めました。

特に自動スケーリングが早く、なおかつ普段は最小限のインスタンスしか起動しないCloud Runの特徴はメンテモのような初期のWebサービスにマッチしているように思います。

ZennやメルカリShopなどメンテモより規模の大きいプロダクトでもNext.js on Cloud Runが採用されていることも決め手の一つになりました。

zenn.dev

engineering.mercari.com

ビルドをどこでやるか

VercelではGitHub連携をしたら勝手にデプロイフローを組んでくれて、特定のブランチにプッシュするだけで自動デプロイしてくれます。

メンテモではこの代わりにGitHub Actions上でコンテナのビルド、アップロード、Cloud Runのリビジョンの更新までをやっていました。

しかしGitHub Actionsはジョブの並列数に限りがあり、またデプロイだけで10数分かかっていたのもあって頻繁にワークフローが詰まるようになってしました。

GitHub Actions上では他にもテストやLintなどの各種チェックも走らせているため、CIの待ち時間によって開発体験が悪化するのを防ぐために現在ではデプロイのワークフローをCloud Buildに移行しています。

CDNどうするか

Vercelでは多くの静的アセットが自動的にCDNにキャッシュされますが、載せ替えに伴ってこれらも代わりのものを用意する必要がありました。

またメンテモでは多くのページでNext.jsのISRを使っていましたが、Cloud Runへの載せ替えの際にこれらをすべてSSRに変更しました。

代わりにstale-while-revalidateヘッダーを使ってCDN側で同様のキャッシュ戦略を行おうと考えていたため、移行先のCDNはそれに対応しているものに限定して考えると、Cloud CDNとFastlyが候補として残りました。

Fastlyはキャッシュのインスタントパージが魅力的で最後まで悩みましたが、ほとんどのインフラがGCP上に載っているためできるだけそこに寄せたかったこと、 メンテモのビジネスの都合上インスタントパージできないことがクリティカルになりづらそうだったことなどからCloud CDNを選びました。

環境変数どうするか

Vercelではコンソールに環境変数を打ち込むと勝手に暗号化してくれて、Next.jsのビルドフローに合わせて適切にそれらを利用してくれます。 また、vercel cliの vercel env pull コマンドで、設定されている環境変数をローカルの開発環境に簡単に持ってくることもできます。

Next.jsはビルド時、サーバーのランタイム、クライアントのランタイムでそれぞれ環境変数にアクセスすることができ、 環境変数の渡し方も .env に書く方法、実行するマシンの環境変数として渡す方法、 next.config.js の env フィールドに埋め込む方法があってそれぞれに微妙に挙動も異なります。

さらに適当にこれらを扱うと本来サーバーからしかアクセスできないはずだった機密情報が簡単にクライアント側のコードに埋め込まれてしまうため、Vercelをやめて他の環境に移る際に一番気をつける必要があるところだと思います。

メンテモではサーバーで使う環境変数はすべてGCPのSecret Managerに格納しています。

デプロイを行うCloud Buildと実行環境のCloud Runにはそれぞれ起動時にSecret Managerから値を取得し、ローカルの開発環境ではgcloudコマンドを使って値を取得しています。

アーキテクチャ図

最終的にメンテモのインフラ構成は以上のようなものになりました。Vercelを使えばこれらを全部おまかせできると思うと改めてVercelの便利さがわかりますね。

移行手順

インフラ構成が決まってしまえばあとは、それをTerraformに起こしていくだけです。

今回はインフラの大規模な更新だったのもあったため、先に新しいインフラをすべてGCP上に作って社内でテストをした上で最後にDNSの切り替えをするという流れで向き先を変更しました。

移行してよかったこと

コストは安くなった

当初のモチベーションであったインフラのコストカットは無事達成できました。

VercelのEnterprise版とくらべて圧倒的に安くなっているのはもちろんのこと、Proプランとくらべてもかなり安くなりました。 CDNのおかげでCloud Runは最初の無料枠に収まっているためまだ請求が発生してもいません。

Terraformで管理できる範囲が増えた

インフラのほとんどすべてがGCP上に移行できたため、Terraformで管理できる範囲が大幅に増えました。

Vercelからも最近になって公式のTerraform providerが出ましたが、移行を決めたときにはまだなかったのでVercelだけコンソールをいじる必要があり、特に環境変数の管理などに不満を感じていました。

registry.terraform.io

GCPに移行してからはほぼ全てがTerraformで管理できているので、ステージング環境と本番環境の乖離などが起こりづらくなっています。

デプロイフローの選択肢が増えた

Vercelはデプロイへのトリガーが基本的に指定したブランチへのpushしかないですが、コンテナベースのインフラになったことでデプロイフローにかなり自由が効くようになりました。

Cloud Runはリビジョンを切り替えることで即座にトラフィックを新しいバージョンに流すことができるので、現在のメンテモではmainへのpushごとにDockerイメージを作成してアップロードしておいてリリースはリビジョンを切り替えるだけというフローになっています。

これによってバグが起こったときに環境が戻すのが容易になりました。

移行のデメリット

ISRは厳しい

Next.jsのISRはSSRしたページを一定期間キャッシュしておくことでWebサーバーのリクエストを高速化する機能です。 静的サイト生成機能の付加機能として説明されることが多いですが、どちらかというとSSR+stale-while-revalidateキャッシュという理解が近いと思います。

キャッシュ切れしたあとのリクエストに関しても新しいSSRが終わるまでは古いキャッシュを返すので、1回目のSSRが終わってしまえば実質キャッシュヒット率が100%になるというとても便利な機能ですが、 Cloud Runではキャッシュがインスタンスごとに分散してしまうのでうまく動きません。

AWS上ではISRをサーバーレス環境でもうまく動かせる serverless-nextjs というのがあるみたいですが、これはS3でキャッシュを共有して更新の同期をSQSのFIFOキューで行うという設計になっているらしく、これを別環境で再現しようとするくらいならシンプルにSSR+CDNでのstale-while-revalidateキャッシュでいいんじゃないかなと思っています。

やっぱりVercelの開発者体験はよかった

なんども言うけどVercelはよくできてる。

株式会社メンテモとして Mozilla への寄付を開始しました

メンテモ代表の若月です。表題の通り、この度株式会社メンテモとして Mozilla への継続的な寄付を開始しました。今回のエントリーでは意思決定までの背景をお伝えできればと思います。

寄付の詳細について

このページから、毎月5,000円を継続的に寄付することにしました。金額は非常に少額ですが、長期的に寄付を続けることを重視してこの金額に設定しました。今後、会社の業績や規模の拡大に伴って、こちらも見直していくことができればと考えております。

f:id:mentemo:20220330112027j:plain

ことの発端

www.j-cast.com 先日こちらの記事が話題になりました。内容をまとめると、

といったものになります。Firefox は言わずとしれたブラウザの一つですが、現在は非常にシェアを落としていることがわかります。この記事は話題に上がり、多くの声はこれからのウェブ標準を危惧するものです。

ブラウザのサポート

私もいちウェブエンジニアとして、ブラウザのサポートを切りたい気持ちは非常によくわかります。事実、メンテモも Internet Explorer を明示的にサポートしていません。プラットフォームの数だけ対応すべき事項が増えることもあり、そういった側面から見ると対応ブラウザを絞る、ということは合理的ではあります (もちろん、サービスにおけるブラウザシェアが偏っている前提でマイナーなものを切るのであれば)。

余談ですが、フロントエンドを数年やってきた中でブラウザ間の差分には苦しめられてきました。かつては Internet Explorer, 現在は iOS Safari。癖が強くて対応が大変です。新しい API が出るたびに Can I use で確認する日々です。-webkit-* や -moz-* といったベンダープレフィックスを手で付けていた時代が懐かしいですね。

ウェブ標準への懸念

しかしながら、ウェブ標準という観点で見ると好ましいことではありません。ウェブ標準とはこのようなものです。

ウェブ標準（ウェブひょうじゅん、英: Web standards）とは、World Wide Webにおける様々なものを定義したり記述したりするための、形式に則った非独占的なインターネット標準やその他の技術仕様を指す。出典：Wikipedia

Firefox のシェアがだんだんと落ちていき、Mozilla がウェブブラウザの開発およびウェブ標準への提言をやめると、ウェブ標準が独占的になる可能性が危惧されます。

qiita.com

寄付の背景

メンテモもウェブサービスを開発する企業として、これからのウェブ標準に対する危機感を覚えています。シードスタートアップなので微力ではありますが、会社の意思表明という意も込めて少しでも力になれたらということが寄付の背景です。

お決まりの

今回もお読みいただきましてありがとうございます。恒例のアレではありますが、メンテモは絶賛採用中です。特にフルタイム2人目のソフトウェアエンジニア氏を探しております。課題とやることは山積みです。よろしければ以下要項をぜひチェックしていただければと思います。

open.talentio.com

メンテモが Vercel を剥がすまで (経緯編)

採用関連のエントリーを何本か上げてきましたが、あれからメンテモのプロダクトもガラッと変わりました。これは絶好のチャンス、ということで今回はよりエンジニアリングらしい記事を書いていこうと思います。タイトルの通り、メンテモは Vercel を剥がしました。近い規模のスタートアップが同様に Vercel を剥がそう、といった事例もあるかと思いますので、メンテモ社が Vercel を剥がすまでの経緯をご紹介できたらと思います。

メンテモの技術スタック

こちらが旧来の技術スタックです。基本的には Next.js がすべての責務 (ウェブ/API) を持っており、Firestore へのアクセスも Next.js の API Routes 経由で行われるといったものでした。選定の経緯として非常にシンプルで、

  • インフラ構築に割く工数が無い
  • CI/CD 周りで楽をしたい
  • SSR/SSG がある都合、利用可能な IaaS が限られている

というものです。Next.js/Nuxt.js を使う多くのチームが同様の経緯で Vercel を利用しているのではないでしょうか。

移行までの経緯

メンテモが Vercel を剥がすことになった理由は複数個あり、具体的には以下のとおりです。

  • 固定課金費用/従量課金費用が高い
  • SSG が増えることにより、ビルド時間が膨大になる
  • 通知の送信等をバッチ処理的に行う際に timeout してしまう

一点ずつ、それぞれ解説していきます。

固定課金費用/従量課金費用が高い

Vercel には 2022/02/17 時点で 3つのプランが用意されており、商用利用する場合は必然的に Pro Plan を選択することになります($20/mo per member)。固定費用という面では開発に参加するメンバー全員の権限が必要となるので、$20 * メンバー数が必ず毎月のランニングコストとして発生します。トラフィックが増えてきたとはいえ、業務委託メンバーにも権限を付与しなければならないのでなかなかの負担です。

また、一定の時期から Vercel Alert という不穏なメールが届くようになりました。これは Serverless Function の Limit (1,000GB-Hours/mo) を超えてしまいそうだという内容のものです。

Vercel Alert という不穏なメール

2021/10 の Vercel 料金プラン改定までは、これを突き抜けると Enterprise Plan に移行するしか道がないため、本当に不安でした (噂では相当な金額らしい)。改定後は突き抜けても Pro Plan の契約を続けられるようになりましたが、100GB-Hours 超過ごとに $55 の課金が発生するため、ピーク時の月額費用はとんでもないことに。

ピーク時の Vercel 課金額

当たり前ですが、サービスが成長するに従って課金額も増えていくので困っていました。山梨本社の家賃よりも高くなってしまう未来が容易に想像できる状態に...。

SSG が増えることにより、ビルド時間が膨大になる

メンテモはメンテモ ノートというメディアを運営しており、この実装は SSG 領域から Notion API を叩いて静的ページを作成するというものです。記事の本数は右肩上がりに伸び続けますが、同時にビルド時間もぐんぐん伸びていきました。ピーク時には Production 環境へのデプロイに40分程度かかることに。開発速度を最大化したい現在のフェーズにおいて、致命的なボトルネックとなっておりました。

ビルド時に SSG せずに、ISR で記事を作成するという方針も可能性としてはありましたが、

  • 初回アクセス時の遅延が想定されること
  • Notion API が Beta であることから不安定 (502, 504 エラーが一定量発生する) で、初回アクセス時にこれらのエラーが出るとレンダリングされない

という理由で却下されました。よって、初回ページはビルド時の SSG で生成し、記事の更新に追いつかせるために ISR でフレッシュな状態を保つという実装になっておりました。

遅すぎるビルドに対する悲痛の声

通知の送信等をバッチ処理的に行う際に timeout してしまう

Vercel の Serverless Function は 15秒間でタイムアウトする仕様があります。

For Teams, the execution timeout is 15 seconds (Pro plan) -- Serverless Function Execution Timeout

基本的にはこのタイムアウトで問題ないのですが、通知の送信やメンテモ ノートの記事集計をバッチ処理的に行う際に、どうしても突き抜けてしまうことがありました。こちらは仕様上の問題で、こちらができることとしては1ハンドラをタイムアウトまでに終了させる改善をすることしかありません。こちらも移行プロジェクトを前に進めた要因の1つです。

新体制移行まで

こんな経緯で、遂に Vercel を剥がそうという話が現実味を帯びました。環境が丸っと載っているメインのサーバを移行するということで、気合を入れて取組むプロジェクトです。今回は長くなってしまいましたので、ここまで。次回移行、実際に移行作業を計画 => 実行したエンジニアからのエントリーをお待ちください！

いつもの...

＼ メンテモは絶賛メンバー募集中です ／

open.talentio.com

次回作

engineering.mentemo.com

とあるスタートアップが Twitter Spaces からフルタイムエンジニアを採用した話

こちらの記事は三部作です

あけましておめでとうございます。前回、前々回とフルタイムエンジニア採用について準備したことを書きました。今回さらに How に落として、どのように採用ターゲットにアクセスし、フルタイムエンジニア採用に至ったかを書くことにします。

サマリ

  • メンテモ初のフルタイムエンジニアは Twitter Spaces 経由で採用しました

そもそもの始まり

昨年8月、弊社では嬉々として採用ページをオープンしたものの、当たり前ですが特になにも反応はなく、実際に露出を高めていく必要性をひしひしと感じていました。採用媒体などはお金も手間もかかるので、資金力とリソースの少ない現フェーズではなかなか検討しづらい状況でした。「お金も手間もかからない、サクッと露出できる方法はあるのか？」と都合の良いことを日々考えている中で、株主であるジェネシア・ベンチャーズの相良さんと吉田(愛)さんとミーティングをしている際にふとこんなアイディアが出てきました。

Twitter Spaces でクルマxエンジニアトークをしたらいいのでは？

当時、Clubhouse が流行った後で Twitter Spaces が追従して公開されてしばらく経ったくらいの時期でした。サービスが公開されて間もなかったこともあり、フォロー中のユーザが Spaces の部屋を立てるとプッシュ通知が送られる仕様があります。Twitter が力を入れて伸ばしていくフェーズだということもあり、インプレッションをかんたんに集められるかもという淡い下心を抱きながら技術顧問の田籠さんに相談することに。

f:id:mentemo:20220112222429p:plain
ミーティング後に田籠さんに連絡をした際の Slack

田籠さんに快諾(?)いただき、実際にアジェンダを詰めていきました。タイトルからセッションの内容、実際にどのような進め方にするかを主に田籠さんが考えてくださり、8/12 (木) の 20:30 - 実際に Spaces を開始。

まさかの結果に...

結果、アクティブに聞いてくださっている方が常に25人くらいいらっしゃる大盛況ぶりで、予定していた1時間を少しはみ出るくらいの話をして閉じることになりました。前半はクルマについての与太話、後半はメンテモのエンジニアリングについての話という構成に。最後は「メンテモの SO プールは 15% ですよ！」という田籠さんのメンテモ一押しポイントの紹介で締まりました。

f:id:mentemo:20220113101648j:plain

Spaces が閉じた後、エンジニアの方数名からちらほらフォローを頂きました。注目すべきはなんと、DM が2件来たことです。まずはカジュアル面談から、ということで面談プロセスに進みました。

f:id:mentemo:20220112223525p:plain
DM を報告した際の Slack

祝！採用

この後も順調に面談プロセスを進み、遂に1名のフルタイムエンジニア採用に繋がりました。クルマxエンジニアリングという文脈でトークしていた甲斐もあり、アバルト124スパイダーに乗るクルマ好きのエンジニアの方にジョインしていただくことに。思ってもいない結果になり、田籠さん含めメンテモ一同、本当に驚きました。

良かったこと

クルマ、という熱狂的なファンの多いドメインxソーシャルと相性の良いエンジニアという職種の組み合わせがきれいにワークしたことが今回の結果に繋がったと考えています。また、当初の目論見通りリリースされてから日の浅いサービスを使うことで、インプレッションを容易に集めることができました (後日談ですが、採用に至った方は田籠さんが Spaces を始めました、という通知をフックに聞き始めたそうです)。再現性のある手法かはわかりませんが、とにかくメンテモにとっては思ってもみない結果になりました。

余談...

Spaces のアーカイブは残らないので書き起こしを考えている方はきちんと録音をするように...

f:id:mentemo:20220112224450p:plain

ところで

メンテモは絶賛採用中です。もし少しでも興味を持っていただけましたら、ぜひ以下リンクをご覧ください。

open.talentio.com

こちらの記事は三部作です

とあるスタートアップが最初のフルタイムエンジニア採用のために準備したこと

こちらの記事は三部作です

前回のエントリーから少し時間が経ってしまいました。その間に技術顧問の @tagomoris のエントリーが盛り上がりを見せたり、メンテモ自体も日々変化を遂げたりと慌ただしい日々を過ごしています。

こんにちは、メンテモの若月 (@Qrymy)です。メンテモ という会社の代表兼エンジニアです。前回のエントリーではそもそも最初のフルタイムエンジニアを採用する決意をするまでの記録を執筆しましたが、今回はもう少し How に落として、実際に採用するにあたってどのような準備をしたかという点にフォーカスして話を進めていきたいと思います。

会社の情報を公開

そもそもメンテモは長いことステルスだった事情もあり、コーポレート・サイトさえもかなり簡素なものでした。@tagomoris からのアドバイスもあり、まずはインターネット上に会社の情報を公開するという部分において以下のような準備をしました。

余談ですが、公開ページを持つことのできる ATS (採用管理システム) の選定にはかなり悩みました。候補は HERP と Talentio でしたが、しばらくは完全に無料で運用できるという部分が決め手となり、Talentio を採用することに。ただ、公開ページを作るのはなかなか時間がかかる上、更新などもまあまあ大変なので気合をいれて取り組んだほうが良いかもしれません。

その他有料媒体も検討しました。ヘッドハンターから人材データベース、求人広告まで幅広く考えてはみたものの一旦見送りました。理由としては、

  • 多くのサービスがかけた工数に比例して成果が出ている：メンテモには独立した人事があるわけではなく、私が兼任することになるので張り付くことが難しい
  • 単価が高く、初期スタートアップからすると躊躇する金額感

勤務形態や制度を考える

メンテモは基本的に定時出社定時退社の正社員がほとんどですが(これまでフルタイムエンジニアが不在だったこともあり)、エンジニアとなると別に定時である必要性もそこまでないので、働きやすい形態を考えることになりました。合わせて、コンピュータ貸与やカンファレンス参加等の制度を考え、ラフではありますが明文化しておきます。さらに、メンテモはこれまで就業規則を持たない会社でしたが、メンバーが増えてきたこと、勤務形態が複数化してきたこと、リモートメンバーも増えてきたこともあり、このタイミングで就業規則を整備中です。 合わせて、山梨本社勤務かリモートワークか選べる制度、リモートワークの場合は手当を支給するなど、細かい部分を含めて入社を検討してくださる方との齟齬が起きないように調整していきます。ここでも @tagomoris からのアドバイスに助けられました。

面談フローを考える

面談フローだったり、採用プロセスだったりは別エントリーでまたの機会にお伝えできたらなと考えております。

ストックオプション付与制度

キャッシュで還元することが難しいスタートアップにおいて、SO(ストックオプション) は強力な武器になります。メンテモは第三者割当増資を実施する際に、SO プール：15% をどうにか通したおかげで、一般的なスタートアップよりはやや多くの SO を付与することができます。ではこれをどう使おうかという部分もまた、非常に難しいポイントです。一般的に変数は以下のような形になるのではないでしょうか。

  • 税制適格無償 SO または信託型 SO
  • 付与タイミングと回数
  • 入社前の付与個数の握り
  • 退職時の扱い

等々です。現時点で完全に付与制度が FIX しているわけではないので、ここで明言はできませんが、チーム全員で成功を目指すことのできる制度作りをしている最中です。

まとめ

今回は最初のフルタイムエンジニアを採用するために準備したことを書いてみました。設計から運用まで、一覧にしてみると本当にやることが多くて大変です。採用関連のサービスが一般的な支出に比べて高いことにも納得できます。会社の数だけ採用プロセスがあるとは思いますので、知見をお持ちの方がおりましたらご意見・ご質問等お待ちしております。

なおメンテモは絶賛採用中です。ご興味をお持ちの方はぜひ下の採用ページをご覧ください。

open.talentio.com

こちらの記事は三部作です

スタートアップ技術顧問は技術を見ない

こちらの記事は三部作です

タイトルは嘘です。(必要なときに)見ます。最近は通知を送る方法*1について考えられる設計のパターンをいくつか例示した上で、今ならどれを選択しどんな感じで実装していったらいいかについて議論したりしました。

初めまして、@tagomorisです。今年の6月からメンテモで技術顧問をしています。技術的な専門としてはデータ処理基盤からWebサービス一般・ITインフラまでですが、メンテモの技術顧問では技術領域を特定せず、ありとあらゆる事についてソフトウェアエンジニアの観点から相談に乗る、という形で毎週1回、2時間ミーティングするのが基本の形です。他にも要望に応じて様々なことをやっています*2。

このエントリでは自分がメンテモにどう関わっているのか、普段何をしているのかをざっくりと紹介してみよう、それによってメンテモの紹介もいっしょにさせてもらおうと思います。

メンテモの技術顧問でやっていること

メンテモは若月さん(@Qrymy)という創業者が自分でコードを書いて経営をしている会社です。このため技術と技術者がかかわるあらゆることが一人に集中しています。

自分の役割は彼の疑問や相談をなんでも聞いて、そこに過去の経験や自分の知識から参考になる情報・選択肢を返すということです。そこには技術的な内容はもちろん、採用・評価・組織といった技術部門の非エンジニアリング領域の話も、あるいは必要があればエンジニアリングにあまり関係のない話までなんでも相談に乗っています。もちろん若月さん自身でなんでもできる人ですが、そこに他人の視点を加えて視界を広げるということがメインの役割かなと思っています。

メンテモの技術顧問で気をつけていること

それであれこれ相談に乗るときに、単に知識だけを返すということはあまり無く、もちろん自分なりの意見がある程度含まれることとなりますが、特にメンテモの文脈で会話をしているときは以下の3点に気をつけて話をするようにしています。

とにかくスピード

スタートアップ企業にとにかく大事なのはスピードだ、というのが自分の考えです。求められているものを実装するにも、求められていると思っていたものが実はそう重要ではなかったことを知るためにも、とにかくサービスの実装と改善のサイクルを早く回す必要があります。じっくり考える必要のある事柄ももちろんありますが、それでもほとんどの場合においてはスピードが最優先です。

これは単純に思えてなかなか徹底が難しい話で、うっかりすると「これを素早く実行するためには何をしたらいいか」を考えだして時間が経ってしまう、みたいなことにもなりかねません。またエンジニアリングをやっているとどうしても安全に・高信頼の・後々まで使えるようなものを作る方向に頭が動きがちなところがあります*3。

技術顧問を始めるときに若月さんと話をしていると性格的に慎重な方向に思考が向きがちなところを感じたので、自分はメンテモの文脈で話しているときは強く意識してスピード最優先の方向に思考を振っています。

維持に手をかけない

スタートアップ企業一般にどうしても人数が限られていて、やりたいことが何でもできるわけではない、ということがあります。ましてメンテモは現在はサービス開発にフルタイムで働けるのが一人だけという状況で、ひとつひとつの作業に費せる時間は長くありません。

こういう状況で作った何かの仕組みが、例えば維持するのに毎日ひと作業しないといけないということになると、これは致命的です。新しいことをやる余力がどんどん削られて、開発スピードも低下しますし、関わっている人間のメンタリティにもよくありません。

ということで、何かを考えるときには可能な限り、人手がかからない方向に倒すようにしています。また日常的に負荷がかかっている作業などはできるだけ早めに対処し、後々に楽ができるようにアドバイスをしたりもします。

今必要な回答以外にも色々な選択肢はある

基本的には上述のような方針で相談に乗るのですが、この方針だけで回答を返さないようにし、実際の会話の中では「今のメンテモには必要ないが、こういうケースやこういうやりかたもある」という話を可能な限り紹介するようにしています。これはもちろん時間がかかるし、今のメンテモへの即効性という意味では優先度が低いことかもしれませんが、絶対に必要だと思っています。

メンテモというサービスには長く続き、大きく発展してほしいと思っています。そうなれば創業者の若月さんは長く会社を率いることになり、今のメンテモとは全く異なるステージ・規模・人数・組織形態のチームとサービスを経験することになります。そうなったときに必要なのは今のメンテモとは全く異なる方法と思考になるでしょう。そのときに、今このときからの時間をかけた様々なインプットは絶対に必要となるでしょう。

もちろん短期的にも、問題に対して様々な選択肢をリストアップすること、その中からきちんと理由をつけてひとつを選ぶことを繰り返すことはエンジニアリング・ビジネスの両面で非常によい訓練になると思っています。

実際の話

ふわっとした話だけしてもなんなので、実際にあったやりとりをふたつ紹介して具体性を上げてみましょう。

実例1：「開発体制をどうすればいいか?」

技術顧問をはじめて初日に相談されたのがこれでした。まだほとんど人数もいないので体制も何もないのでは、ともちろん思ったのですが、確認してみるとチームをどう作ったらいいのか聞きたいという話です。

が、それは何のために? という質問を何度か繰り返すと見えてきた問題は、実際には開発体制の問題ではありませんでした。開発フローの中で手詰まりや他の人の作業・確認待ちが発生することが多かったり、あるいは開発時にブランチが大きくなりすぎてレビューやリリース前の確認作業に手間がかかりすぎたりといったことが日常的に発生していて、これを解決するためには開発体制をどうにかしなければと考えていた、というのが実情でした。

これは実際には開発体制ではなく開発タスクの粒度コントロールやリリースのサイズ、デプロイタイミングなどの問題だと思われました。開発時のタスク粒度が大きすぎるのがブランチの肥大化を、開発用のメインブランチとリリース用のブランチの乖離も大きくなっておりリリースの低頻度化を招いていたという状況です。

自分からのアドバイスは要約すると、とにかく今の体制で可能な限りスピードを上げるべきで、そのためにはまずpull-requestのサイズを小さくしてレビュー負荷を下げると同時にマージまでの時間を可能な限り短縮すること、同時に開発用メインブランチとリリースブランチの差分をほぼゼロにするところから始めるようアドバイスしました。こうすることでサービスに対する要望が出てから改善がリリースできるまでのリードタイムをできるだけ短縮し、それによってサービス改善のサイクルを高速に回すことができるようになります。バグやミスを含んだリリースによるサービスへの影響が心配なところですが、そもそもユーザー数が非常に少ない現段階ではサービス改善速度向上による利益のほうがはるかに大きいはずです。

またこの方向性を長期にわたって手間少なく維持するための手段として、デプロイ頻度を可視化するというアドバイスもしました。デプロイが実行された回数をGitHubのAPIから取得するなどして、それを週に一度Slackにポストする、という簡単な仕組みです。これだけで毎週どういうペースで開発が進められているかが手間をかけずに把握できます。

なおこのとき、いわゆるKPIを設定するのはどうかと質問されました。例えば「週に5回以上デプロイすること」などといったことです。これには自分は強く反対しました。デプロイ頻度は有効な指標にはなりますが、これを目的にしてしまうと簡単にモラルハザードが起きます。大きな機能追加や障害対応、あるいはビジネス上の理由でデプロイ回数が少なくなることは普通で、こういったときに有害なKPIが存在すると、デプロイ回数をクリアするためだけに雑な実装の、あるいは必要な確認を怠ったデプロイが実行されかねません。このようなことも考える必要があるので、KPIの設定にはいくら慎重になってもよいと言えるでしょう。

こののち上記の提案を実施した結果、今ではリリースブランチの乖離もなく、最近ではデプロイ/リリース頻度も目に見えて向上してきました。

実例2：「ドキュメントはどう整備すればいい?」

もうひとつの実例はドキュメント整備についてで、これはチームの拡大を考えはじめた比較的最近の話です。メンテモはスタートアップの(おそらく)ほとんどのケースと同じく、サービス開発に関するドキュメントが非常に弱い状態です。これはサービス開発に関わっているのがオリジナルの開発者を含め数人という状況ではごく当然で、むしろ不要なドキュメント整備のコストを払っていないという意味では正しいとすら言えます。

とはいえ、新しく人が増える見込みがあるのにドキュメント皆無という状況は理想的ではありません。入ってくる人にある程度の調査能力・自己解決能力を求めるにしても、そのとっかかりがどこかにまとめて書かれているだけで必要な時間は大幅に短縮できます。また知っていないと調べようがない情報などもあります。

このケースでは、まずほとんど空白だったメンテモのGitリポジトリにREADMEとしてある程度の情報をまとめておくようアドバイスし、具体的な項目のリストも作りました。Gitリポジトリは開発に関係する人なら誰もが見るもので、かつ非エンジニアリング部門の人はほとんど見ないため予備知識がある人のことだけを想定して書くことができます。コードとも近いので、必要に応じて実装をチェックしながら参照もできます。 現在のメンテモのメインリポジトリのREADMEには以下のような内容が、各項目についてごく短く書かれています*4。

  • 実行環境・デプロイ
    • 実行環境
    • データ保存
    • デプロイ
  • インフラ
    • 開発環境
    • モニタリング・運用
    • レポートページ
    • モニタリング
    • 障害報告
    • メトリクス
    • ログ
    • 障害対応
  • 開発関連
    • 手元の環境
    • サービス実行手順
    • タスクの確認方法
    • Pull Request の検索方法

これでも足りない部分はあるでしょうが、現状では整備に時間をかけすぎない(サービス開発に時間を使う)という方針です。

またこの時のアドバイスのもうひとつの内容として「新しく入った人に、タスクのひとつとして、ドキュメントの追加をしてもらうよう運用する」ということがあります。当然ですが開発に参加した人には知らないことが数多くあります。あれこれ調べたり人に聞いたりすることでしょう。このときドキュメントに欠けている部分については新人にドキュメントを更新してもらい、質問を受けた人が更新されたドキュメントを確認するようにします。

これはドキュメントに足りない部分が最もよく分かるのは新しい人だということ、質問に回答した内容が新しい人に正しく伝わっているかの確認にもなるということから、いろんな場所で有用なアイデアだと思います*5。

まとめ

この記事では自分(@tagomoris)が普段技術顧問としてどのような形でメンテモの開発に関わっているかを紹介しました。これからチームが大きくなるにつれてこの形も少しずつ変わっていくかもしれませんが、これが技術顧問って何をやるの? という疑問をお持ちの方への参考になればと思います*6。

なおメンテモは絶賛採用中です。メンテモの開発者になった暁には技術顧問として自分もついてきます! 興味のある方はぜひ以下のリンクをどうぞ!

open.talentio.com

こちらの記事は三部作です

*1:キューとワーカーを用いて安定して通知を送るアーキテクチャ

*2:このエントリを書いたりとか

*3:自分もあまり意識していないとかなり強いこの傾向があります

*4:1〜3行くらい、場合によってはURLがひとつだけ

*5:たぶん最初は何かの本で読んだんだったと思いますが、いま出典が思い出せません。なんだっけ……。

*6:なお技術顧問が実際に行っている業務は本当に千差万別で、自分の知り合いにも技術顧問をやっている人は何人もいますが、みんな全然違うことをやっていたりします。いろいろですね。

とあるスタートアップが最初のフルタイムエンジニア採用を決意するまで

エンジニア採用 エンジニア組織

こちらの記事は三部作です

メンテモエンジニアリングをはじめました

はじめまして、メンテモの代表、若月(@Qrymy)と申します。メンテモは「クルマの未来を、みんなで創る。」というミッションを掲げる山梨県のスタートアップで、現在は同名のメンテモというサービスを提供しております。カーオーナーの方がいらっしゃればぜひ覗いていただけると嬉しいです。(現在は山梨県のみの提供となっております)

mentemo.com signal.diamond.jp

さて、前置きが長くなりましたが、メンテモエンジニアリングというブログをはじめました。主にメンテモの開発周りやプロダクトチーム周りのお話ができればと思っており、第一発目は代表である私の番という形です。

ではやっていきましょう。

なぜフルタイム不在だったのか

メンテモは現在、フルタイムエンジニア不在という状況です。スタートアップの創業というフェーズにおいて、フルタイムエンジニア不在という状況もなかなか珍しいのではないでしょうか。なぜ不在だったかと言えば明確に以下の理由からです。

  • 代表である私がコードを書くことができるから
  • 最初はなるべく小さなチームで事業を創りたかったから
  • 一人目のフルタイムエンジニアは開発チームのカルチャーに色濃く影響を与えるという仮説を持っており、慎重になっていたから

以上です。特に3つ目の理由は非常に大きく、一人目のフルタイムエンジニアは組織に大きな影響を与えるものだと考えています。開発体制や社内の雰囲気など、初期フェーズでは本当に納得のいく採用をしたいという気持ちを非常に強く持っていました。 採用は大胆になりすぎても難しいし、消極的になりすぎても良くないというのが最近思う難しさです。本当に難しいですね。

何を創っているのか

今はひとつのアプリケーション上で、一般のお客様向け画面、事業者様向け画面、社内用管理画面の全部を提供しています。

ちなみに、サーバ <=> クライアントまでコードは一貫して TypeScript で書かれており、メインのリポジトリ (monorepo) の Languages は以下のような状態です。

GitHub リポジトリの Languages
GitHub リポジトリの Languages

メンテモ開発チームの現状

現状のメンテモ開発チームをご覧ください。

主にコードを書くのは、@Qrymy と @itometeam の2名となります。うち、@itometeam は業務委託の副業エンジニアとなりますので、フルタイムでコードを書く人員は実質1名ということになります。 Contributors を見ると、このような状態になっています。

GitHub の Contributors
GitHub の Contributors

なぜフルタイムエンジニアを採用する気になったのか

メンテモの成長と共に創業者が開発や障害対応、他トラブルシューティングまでやっていたら回らなくなってきたからです。ついにいつかは来るべき時が来ましたね...。

まとめ

「とあるスタートアップが最初のフルタイムエンジニアを採用を決意するまで」というタイトルで一本目のエントリを書いてみましたが、いかがでしたでしょうか。 次回以降は、「どうやって採用したの？」という How の部分について言及できればと思っております。

ということで、お決まりの締めにはなってしまいますが、メンテモは絶賛採用中です。ご興味を持っていただけた方はぜひ採用情報をご覧いただけますと幸いです。

open.talentio.com

こちらの記事は三部作です