ルーカスをbeBitへと導いたスイスの奨学金制度
リードシニア機械学習エンジニアのLukas Schmidさんが、日本にたどり着くまでの少し変わった経緯と、beBitで働くことへの満足感について語ってくれました。
スイス出身で多言語を操る機械学習エンジニアのLukas Schmidさんは、日本を訪れたことがありました。日本の自然や伝統、テクノロジーを楽しむ一方で、「観光ではなく、日本で実際に暮らし、働くのはどんな感じなんだろう？」と考えるようになりました。
その好奇心を満たすため、2019年に在日スイス商工会議所（SJCC）の奨学金制度に応募しました。
プログラムには、フルタイムの日本語学校で6ヶ月日本語を勉強する期間が含まれていました。その後、少なくとも6ヶ月は日本企業で働く、という内容でした。
ただし、この奨学金では「どの」日本企業で働くかまでは決まっていませんでした。「プログラム側から仕事は提供されません。最初はインターンシップでもよかったのですが、とにかく仕事は自分で探さなければいけない。そこが一番大変なんです」とLukasさんは説明します。最初の求職活動では、あらゆる規模の日本企業に応募したそうです。
「でも最終的には」と彼は続けます。「beBitに惹かれた一番の理由はプロダクトでした。プロダクトがとてもおもしろかったんです。…USERGRAMは、特定のクライアント企業のWebサイト上でのユーザー行動を観察できるツールなんです。」
USERGRAMは、ユーザーがWebサイトをどのように閲覧し、操作したかという詳細な「デジタルの足跡」であるクリックストリームデータを収集することで、それを実現しています。「[ユーザーのクリックストリームデータ]をいろいろな観点から分析できるんです」とLukasさん。「ユーザーがそのWebサイト上でどのページを辿って、最終的に商品を購入したり、映画を視聴したり、何らかの行動に至ったのかを見ることができます。」
Lukasさんによると、USERGRAMはGoogle Analyticsに近い部分もありますが、個々のユーザージャーニーを理解できるよう、クライアント向けに特化している点が異なります。「例えば、商品を購入したユーザーを見たいとか、何人のユーザーがその商品を購入したか知りたいとします」とLukasさん。
『今月は500人のユーザーが商品を購入した』と分かったとします。USERGRAMでは、そこからさらに掘り下げて、その一人ひとりについて、どのページを見て、サイト上でどんな経路を辿ったのか、といった体験を確認できます。
さらに、類似ユーザーを探したりパターンを特定したりするためのフィルタリング機能もあります。「例えば、1000人のユーザーがその商品を買おうとしたけれど、うち200人は購入に失敗してしまった。なぜ失敗したのか？[USERGRAMのクライアント]はその理由を見つけることができます。」
「プロダクトに惹かれた、というのが一つです」とLukasさん。「でも、いわゆるスタートアップ的な雰囲気もすごく好きでした。…5年経ってもまだスタートアップって呼んでいいのか分かりませんが！」と笑います。
彼が言う「スタートアップ的な雰囲気」とはどういう意味でしょうか。「本当にいろんな分野に関わることができますし、学べる場所がたくさんあります。そして、みんな変化に対してすごくオープンなんです。」
『CI/CDがちょっと遅い気がするから、この別のライブラリを試してみない？』と言ったとします。そうするとみんな『いいね、やってみよう！』という感じなんです。それが本当にうれしいし、新鮮ですね。
「みんな本当にフレンドリーで、何か質問があれば気軽に聞けますし、ちゃんと時間を取って説明してくれます。」
また、beBitの役割分担やチーム運営の柔軟さも、Lukasさんのお気に入りです。「僕はずっとfeature teamに所属していますが」と彼は話します。「他のチームとコラボレーションすることもよくあります。」こうした連携によって、開発者は別の領域に挑戦したり、新しいスキルを身につけることができます。
「例えば『この人は少し違う機能に取り組んでみたい』とか、『あのfeature teamで急に大きなプロジェクトが始まって、人手が必要になった』といった状況になったら、『じゃああなたは3ヶ月くらいあっちでそのプロジェクトを手伝ってきて』という感じになります。」
「それで、その後元のチームに戻ってくることもあれば、そのまま残ることもあります」とLukasさんは笑います。「どちらのパターンもあります。キャリアの成長という意味でも、とても大事なことだと思います。そこはかなり柔軟ですね。」
できるだけ官僚的で面倒なことは減らすようにしています。
beBitの柔軟さは、別の面でもLukasさんを支えてきました。「僕の場合、昨年父親になったんですが、4ヶ月の育休を取ることができました」と話してくれました。「これは本当に素晴らしいことです。」
「法律上は最長1年まで取得可能で、会社はそれを拒否できません。でも、『拒否できない』ということと、マネージャーから『もちろん、行っておいで』と言ってもらえることの間には大きな違いがあります。今回はそのあたりの話し合いもとてもスムーズで、ほとんど議論もなく決まりました。そこが本当に良かったですね。」
開発者の多くはフルリモートで働いており、Lukasさんも同じ働き方を選びました。「ここから[オフィス]までの通勤は40分くらいです。そこまで長くはないですが、今は朝に子どもを保育園に送って、9時には家に戻って仕事を始められます。もし出社していたらそれはできなかったと思います。」
とはいえ、会社のオフィスのことも高く評価しています。「オフィスは一つの福利厚生ですね。本当に良いオフィスなんです。場所も大手町で、東京駅のすぐそばなので、とても便利です。」オフィスには仮眠用のベッドが置かれたナップルームが2部屋あり、社員は短い昼寝を取ることもできます。
フレンドリーで柔軟な職場環境は、Lukasさんのキャリアに大きくプラスに働きました。彼は2020年にMachine Learning EngineerとしてbeBitに入社し、2021年にはSenior Machine Learning Engineerに昇進。いまでは自身のfeature teamを率いています。
Lukasさんによると、beBitにはエンジニアリングチームが4つあり、それぞれ5〜7名のエンジニアと、UI専任のデザイナーが所属しています。「組織体制としては…プロダクトマネージャーとプロダクトオーナーがいて、その下にチームがあります」とLukasさんは説明します。「ユーザーやクライアントとの直接のコミュニケーションは、基本的にプロダクトマネージャーが担当します。」
この役割分担には理由があります。beBitのクライアントの多くは日本企業である一方、開発チームは主に英語を使っているからです。また、開発者が扱うクライアントのフィードバックを、会社側で丁寧にモニタリングしているからでもあります。
「もしチームがクライアント一社一社のフィードバックにすべて対応しなければいけないとしたら」とLukasさん。「それは本当に大変です。…機能開発なんてできなくなってしまいます。時間が足りません。なので、ある程度はフィードバックを受け止めて整理し、優先順位を付けてくれる“シールド”があるのはありがたいですね。」
一方で、フィードバックがチームに届けられた後は、開発者側が主体的に解決策を考える必要があるとLukasさんは言います。「最初に『こういう課題があります。どう解決できるでしょうか』と問題提起するのはプロダクトマネージャーの役割です。…もちろんプロダクトマネージャーだけでも解決策を提案できますが、エンジニアであるあなたは技術的な側面を理解していて、問題解決のためのツールセットも持っています。だからこそ、あなたの知識が必要なんです。一緒に取り組む必要があります。」
フィードバックループに対応することだけに終始してしまうと、イノベーションは生まれにくくなります。ビジョンを持つことも必要です。クライアントが抱える課題をカバーできる、新しい機能をこちらから提案していく。それも、クライアント自身がまだ完全には自覚していないような課題に対して、です。
方針が決まると、チームはすぐに動き出します。「1つの機能に対して設定する最長のタイムラインは、1四半期くらいですね。本当に大きな機能なら、2四半期ということもあります」とLukasさん。「例えばjourney featureのようなものでは、1四半期でPOC（Proof of Concept、概念実証）を実施し、次の四半期で本実装を始めました。そのうえで、リリースしてフィードバックをもらうところまでは持っていくようにしています。」
そこから先はサイクルがどんどん速くなります。機能のサイズにもよりますが、基本的にはもっと短くなるはずです。スプリントは2週間なので、理想的には2週間ごとにフィードバックを受けられるのがベストですね。
同時に、beBitは機能の作り込みすぎ（feature creep）も避けるようにしています。「新機能をリリースしたものの、ユーザーが実際にはあまり使ってくれない、と気づくこともあります。そういうときは、機能を改善するか、その時点で“殺す（終了させる）”かの選択になります。」
最近も、まさにそんな事例があったそうです。「別の機能の開発を進めているうちに、数年経ってから『この機能、メンテナンスしているけど、実際どれくらいの人が使っているんだろう？ これに今後も投資し続けたいのかな？』と気づいたんです。そして最終的に『いや、もうやめよう』という結論になりました。単にそこに存在しているだけでも、メンテナンスにはコストがかかりますから。」
beBitへの応募を考えている人に向けて、Lukasさんはいくつか具体的なアドバイスもしてくれました。「まずは、コーディングスキルを磨き直すことですね。これは常識と言っていいでしょう。」
より重要なポイントとして、応募者は自分のスキルを誇張しないように、と強調します。履歴書に書いた技術スタックについては、beBitのチームは「しっかり理解している」と見なして面接に臨むからです。
「履歴書に『Django』と書けば」とLukasさんは言います。「面接ではDjangoに関する質問をします。」もしその言語やフレームワークをよく知らないのであれば？「正直に『詳しくは分かりませんが、勉強する意欲はあります』と言ったほうがいいです。『Djangoは分かります』と書いて、なんとか面接を乗り切ろうとしても…必ずバレます。」
beBitの技術課題は、開発者の実際の業務内容を反映するよう、日常的なコーディングタスクを中心に構成されています。コンピュータサイエンスの問題は、ほんの少し含まれている程度です。さらに重要なポイントとして、Lukasさんは技術課題ツールについても教えてくれました。「そのツールにはGoogle検索機能が統合されています。同時にAI検知機能もあって、誰かがAIを使おうとしたかどうかを確認できるようになっています。もちろん、すごく賢く立ち回ればすり抜けることもできるかもしれません。でも、できるだけコードのコピペはしないでください。…調べ物をするのはOKですが、丸写しは避けたほうがいい。チートしたように見えてしまうかもしれませんから。」
Lukasさん自身、beBitに入社して4年以上が経ちましたが、今後もしばらくは在籍し続けるつもりだと言います。適切なマネジメント、フレンドリーな同僚、そして「官僚的な面倒ごと」を避ける文化が、彼のロイヤリティを高めているのです。
多くの人は3〜4年で転職すると思います。それはよくあることですが、僕の場合は、新しいことを学び続けられる限りは、このままで満足です。
beBitで得られているチャンスに感謝しつつ、エンジニアとしてこの先も成長していきたいと考えています。「新しいスキルを身につけたり、これまでとは違う領域を開発してみたりしたいですね。そういったことが続けられる限り、僕はとてもハッピーだと思います」と話してくれました。