ClassDoを退職し日本に帰国しYuimediに入社しました

 · 15 min read

れこです。約 2 年勤めた ClassDo を退職し Yuimedi に転職しました。それに伴いシンガポールから日本に帰国しました。ということでこの 2 年の振り返りと今後の話を書きます。

ClassDo とは

ClassDo はシンガポールを拠点とする EdTech 系の SaaS を作っているスタートアップ企業の名称であり、プロダクトの名前でもあります。シンガポール、マレーシア、日本などからフルリモートで働いています。社内の公用語は基本的に英語です。

— ClassDo | Your indispensable assistant for personalised learning

シンガポールってどんなところ？

シンガポールについて詳しくない方向けに概要を書いておきます。

  • ほぼ赤道直下にある常夏の都市国家。東京 23 区より少し大きいくらいの面積
  • 気温はだいたい 27-33℃ くらいで安定して暑く湿度も高い。乾季と雨季があり四季はない
  • ゲリラ豪雨は頻繁に起きるが台風、地震、火山噴火や津波などの自然災害はほぼ無い
  • 公用語は英語、中国語、マレー語、タミール語
    • 英語以外の話者も英語が話せるので、英語が話せれば多くの場所で通じる
    • シンガポール特有のアクセントや語彙・イディオムは Singlish と呼ばれる
  • 在星日本人は 2021 年時点で 36,200 人（海外在留邦人数調査統計｜外務省）

なぜ ClassDo（シンガポール）に行ったのか

きっかけはリファラル採用のお誘いがあったことで、以下の理由で転職しシンガポールへの移住を決めました。

  • 英語コンプレックスを解消するため英語話者の多い会社に勤め英語話者が多い国で暮らしたかった
  • やりたかった Web フロントエンドの仕事ができる
  • 当時コロナ禍が開始した直後だったので今まさに必要とされる事業だと感じ共感した
  • 当時の在籍エンジニア 2 人はもともと知り合いで詳しく中の事情を聞けて腹落ちできた

とくに英語に関しては全くと言っていいほどできませんでした。読み書きなら多少はできるけど聞くのと話すのは全くできず対面でコミュニケーションできないコンプレックスを抱えていたのでそれを解消するいい修行の機会だと感じました。 「別に日本に居ながらでも英語は勉強できるのでは？」 と思う人もいると思いますが、私は自分に甘いので必然性がなく好きでもないことを努力し続けることができない人間であり、もともと持ってる得意分野を手土産に自分の苦手分野が必要とされる必然性のある環境に自分を放り込んで上達せざるを得なくする方法が自分に合っているためシンガポールへ行くことを選びました。

振り返り

居たのは 2 年弱でしたが、行ったことない場所や未体験のことを優先してやっていたので色んな事を経験できたと思います。笑い話、苦労話、趣味の話、食事事情、海外移住やコロナ禍のあれこれなどシンガポール生活の話はいろいろありますが全部書くと中身が散らかってしまうので割愛し 仕事、コンプレックスだった英語、対外的な活動の 3 点に絞って振り返ります。シンガポールでの生活についてはお話しする機会があればぜひその時いろいろ話させてください。

仕事について

軸足はソフトウェア開発者ですが、時期に応じて組織に足りない機能を補えて自分の興味関心が重なる領域を選んで仕事していました。

  • フルスタックエンジニア
  • データエンジニア
  • スクラムマスター
  • エンジニア受け入れ体制の整備

プロダクト開発的なところ

ClassDo の言語は主に TypeScript （と一部 Go）です。主な使用技術は Vue.js、Apollo（GraphQL）、Prisma、serverless（フレームワーク）、Docker、k8s、インフラは AWS という感じのスタックです。その他特徴的な要素としてはリアルタイム同時編集、ビデオ通話、Personalized learning のためのデータ分析・可視化などがあります。PO は技術者上がりではないので技術の詳細は分からないけど技術的な観点からの提案や懸念が具体的にどのようなコスト・リスク・インパクトに繋がるのかを正確に把握しようと努めており、その上でどうバランスを取るかを考え意思決定している環境でした。

私が具体的にやってたことは新規開発や既存機能の改修、フロントエンド・バックエンドのパフォーマンス最適化、管理画面のリニューアル、メディア変換サーバの構築と運用、技術負債の返却、あとはログ収集・データ分析基盤の整備、後述するデータエンジニアリングと掛け合わせた学習データの可視化などが主で、フロントエンド/バックエンド/インフラ拘らずやってました。Node.js・TypeScript・serverless あたりはすでにある経験値の切り売りをしていましたが、Vue.js、GraphQL、k8s、Prisma 辺りは 本番での運用経験値がなくほぼゼロからの学習でした。Vue.js コミッターの同僚やGraphQL Tokyoの co-organizer の同僚などにレビューで鍛えていただきました。また、リアルタイム共同編集やビデオ通話の開発・運用経験もなかったのでフロントもサーバの実装もこれまで考慮したことなかった観点を多く得られました。

データエンジニア

ユーザのフィードバックやアプリケーションのデータとログは蓄積してるけどそれを利活用する土壌が整っていなかったのでデータエンジニアリングと統計学に入門しデータ分析基盤（データレイク、DWH、データマート）用のパイプラインの設計・構築・運用保守をやってました。また、作った基盤を用いてアプリケーションのデータやログデータの解析、利用状況の調査、利用開始フローのファネル解析、KPI や財務モデリングの仮説検討・根拠出しのデータ分析、ダッシュボードを整備して各種メトリクスの可視化、ダッシュボードを見る/定期的に見直す啓蒙活動などをやってました。

スクラムマスター

組織が大きくなるにつれ従来のやり方では開発がスムーズに回らなくなり、サイロ化やコンテキスト共有・属人化・進捗などの課題がありました。業務フローや開発プロセスから根本的な課題を整理した結果スクラムの導入で多くの問題を解決できそうだったのでスクラムマスターになってスクラムを導入しました。エンジニア・PO 以外の関係者も巻き込みスクラム勉強会（日本語・英語）を開催したり都度トラブルシューティングしながら Sprint Retrospective でプロセスを改善し組織に定着させました。スプリントを重ねるごとにスクラムマスターとして積極的にコミュニケーションを Proxy せずとも自律的にコミュニケーションが成立するようになったのでその後は自分も 1 開発者として開発に参加していました。
なるべく独自の要素が混じらないようスクラムガイド 2020 を原則としつつ、不明瞭な箇所やガイドに明記されてないアンチパターン、運用して分かった経験則などついてはスクラム（マスター）経験者にヒアリングしたりカンファレンスの登壇資料やブログ記事を読み漁り補っていました。

エンジニア受け入れ体制の整備

入社後の立ち上げフローを整え最初の 1PR 出すまでのチュートリアルやより詳しい情報へ潜っていける資料を整え、新しく入った方が本筋じゃないことに手間取ることなくキャッチアップできるよう社内の情報整備や新しいメンバーの伴走をやってました。あとはリファラル以外の選択肢を広げるため候補者の情報管理ツールや求人メディアの選定と導入をしたり、採用ページや採用資料作ったり足回りを整えてました。

英語について

英語については当初の目的であったコンプレックスは無事解消できました。結局のところ流暢にはなれませんでしたが英語ネイティブと一緒に仕事・課題解決することへのハードルは感じなくなったので、日本に戻ってきても英語を使う必然性を作りながら場数を踏みながら上達していければいいかなと考えてます。

入社当初は英語が起因のコミュニケーション課題を強く感じたため文法・単語・リスニング・スピーキング・シャドーイング・瞬間英作文などを毎日 2-3h くらい勉強していました。勉強をしてく過程で自分から何かを提案したりミーティングのファシリテーションをするようになったり同僚のホームパーティに招待してもらうなどで使用機会が増え英語でコミュニケーションを取ることの怖さ・抵抗は徐々に薄らいでいきました。前述のスクラムの導入などチームを跨ぐような課題解決や合意形成をする時に英語ができないと何も物事を進められないのでそういう課題に挑むたびに上達したと感じます。他にはシンガポール人インターン生のコードレビューや実装のメンターをやるのもいい機会になりました。

対外的な活動について

シンガポールにいる間はコミュニティ活動はほとんどしませんでした。シンガポールにも JS のコミュニティがあり移住したてのころはリモートで開催してたんですが、徐々に開催頻度が減るにつれて疎遠になりました。シンガポールで開催されているJSConf Asiaのスタッフになりネットワーキングしようと狙っていたのですがコロナ禍により開催されませんでした。唯一携わったのは去年に開催されたJSConf JPの運営スタッフとして web サイトの運用と当日スタッフをやってました。という感じで日本・シンガポール共に技術コミュニティにはほぼ全く参加していませんでした。GitHub では OSS に PR 出したり自分の作りたいものを粛々と作っていました。いくつか作ったものを紹介すると

今後について

振り返りは以上です。今後の話としては 5 月からYuimediと言う会社に転職しました。すでに@watildeがブログにて書いてましたが、Yuimedi は世界で医療データの利活用を広く推進するためのプロダクトを作っています。

プロダクトは、現状としては Node.js, Electron, TypeScript, React, NestJS, AWS あたりの技術スタックの上で、npm のようなエコシステムを持つ医療データに特化した ELT ツールのようなものを作っています。この領域では、dbt や Dataform など、様々な先駆者がいる理解をしていますが、ヘルスケア業界特有の非機能要件や要求されるユーザー体験に大きなギャップがありそうです。利用者の声を聞きながら、長期的に目指すビジョンの実現に合わせて形を変えながらチーム一丸となってプロダクトの開発をしていければと思います。

— AWS を退職して Yuimedi に入社します – watilde’s blog

個人的に Yuimedi に魅力を感じていることは以下の通りです。

  • 自分を含め Node.js の core collaborator が 4 人在籍（うち 1 人は社内制度の 1 つ OSS Day で継続的なコミットを認められ Nominate された（本人のブログ））
  • 技術者だけでなくドメイン領域（医療）のスペシャリストも在籍している
  • 今は Closed β で PoC を回している。ローンチまでにやりたい技術的なことがモリモリ
  • 海外展開を見据えて R&D している
  • バックオフィスがこの規模・フェーズのスタートアップにしてはかなり整っており働きやすい
  • ベストプラクティス・業界標準をリスペクトしつつ全体感を持ちながら手探りができる。目の前にある課題一点だけでなく全体感を持ちながら How を検討し、ベスプラがあれば積極的に検討し社内固有のオレオレ要素を減らすことを良しとしている

自分と重なる部分としては以下の通りです。

  • プロダクトの 0-1 段階からエンジニア兼壁打ち役としてパートタイムで働いたが雰囲気やカルチャーが自分と合っていた
  • 前職で入門したデータエンジニアリングと統計学をもっと深めたいと感じた。そして Yuimedi や医療ドメインにはそれが必要とされている
  • 前前職が CureApp と言う治療用アプリを作る会社だったので医療 x ソフトウェアの領域に多少土地勘があり貢献できそう

その他の個人的な抱負は資格を取ることです。これまで技術に関連する資格を取ろうと思ったことがなかったのですが、統計検定準 1 級受験体験記 | MoT Lab (Mobility Technologies Engineering Blog)を読んで資格を取るために勉強をすることで独学の偏った知識を補完しその分野を包括的に理解する 1 つのいい機会だと感じたので Professional Scrum Master Ⅰ(PSM Ⅰ)と統計検定準 1 級の取得を目指し勉強しようと思います。

カジュアル面談のお誘い

近況報告は以上です。もし当記事の内容や Yuimedi に興味があったら転職意向の有無に関わらずお話してみませんか。また、医療データの標準規格（CDISC CDASH、OHDSI OMOP CDM、FHIR など）について詳しい方、そういう開発の仕事をされている方、そういう方が知り合いにいる方がもしいたらお話聞かせていただけると大変助かります。
知ってる方でも初めましての方でもオフラインなら Twitter（@L_e_k_o）にてご連絡いただくか、リモートならこちらのリンク（Google カレンダー）から都合の良い時間帯を抑えていただけますと幸いです。なお Twitter の DM はフォローしてない方にも open になっております。

© 2012-2022 Leko