ドメインと情熱に惹かれたエンジニアがTebikiに入社して感じたこと

※この記事は 2024年05月10日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。

はじめに

2024年1月に入社した村上です。前職では小説投稿サイトの開発・運営を行っていました。

入社して数ヶ月が経ちましたので、入社前に持っていた思いと実際に入社して感じたことについてお話しします。

入社したいと思ったきっかけ

端的に言えば、「これから伸びる市場で、ユーザーに喜ばれるプロダクトを作れそう」と感じたからです。

具体的には以下の二点が大きな理由です。

1. 挑戦的な事業領域

以前ECサイトを運営している会社に所属しており、自社工場の見学や日常業務を通じて製造現場を垣間見てきました。

それまでは「製造現場ではパッケージのソフトウェアががっつり導入していたり、ロボットなどで高度に自動化されていそうなので、Webエンジニアにできることはない領域」という印象を持っていました。

ただ、(ここには書けませんが…)実際にはWebエンジニアの技術で解決できる課題が多く存在しており、未開拓だと感じました。

それから数年経って、次はどの事業ドメインに挑戦しようかなと考えていたところ Tebiki社からスカウトメールが来て「まさしくやりたい領域をやっている会社だ!」と、そのままの勢いでカジュアル面談を申し込んだという流れです。

2. ドメイン知識と情熱の感じられる環境

これまでのキャリアで、ユーザーに特に喜ばれるプロダクトを作るためには深いドメイン知識と情熱が必要だと感じていました。

面接の中でCEOの貴山さんと話す機会があり、「元工場長であったこと」「過去に自身が必要と感じた製品を作っている」という話を伺って、この領域に人生をかけているんだろうなというのを短時間で感じることができました。

また、入社前に参加したスプリントレビューでは、CEOだけでなくCTOや他の開発メンバーも顧客の課題に対して深い理解を示し話し合っているのをみて、CEOの知識と情熱が伝播していることを感じ、このような環境であれば良いプロダクトを創出できると感じ入社を決めました。

さらにその他の理由として、以下の点も私の入社を後押ししました。

  • FS/CSの組織がしっかりしていて、システム導入で一番大変な思いをするお客様と、その難しさをごまかさずお客様と共有しつつ真正面から並走している

  • tebiki 現場教育というプロダクトが既にPMFしているし、お客様と良い関係が築けている

  • プロダクトのデザインが良かった

開発しているプロダクト

tebiki 現場分析というプロダクトの開発にエンジニアリングマネージャーという役割で関わっております。 tebiki(てびき)現場分析|かんたんデジタル現場帳票 tebiki現場分析は現場帳票の作成、記録、承認、分析がかんたんにできるシステムです。帳票作成や記録入力がしやすく、紙では難しかった画像の記録や、遠隔地・リアルタイムでの記録内容も可能になります。また、データ分析の専門知識がない担当者でも直…tebiki.jp

このプロダクトのやりたいことをエンジニア向けの言葉を使うと、

  • 製造現場で「モニタリング」や「オブザーバビリティ」を簡単にできるようにしたい

  • ただし、現状ではそのデータソースは帳票という紙に記入されていることが多いので、帳票のデジタル化も一緒に必要がある

と理解しています。

1エンジニアとして、「モニタリング」や「オブザーバビリティ」がない世界は思い出せないくらいお世話になっていています。そのため、1日でも早く良いものを作って行きたいと思っています。

チームの朝会の様子チームの朝会の様子

実際にTebikiに入ってみてどうだったか

ストック情報が日々生み出されている

入社して一番驚いたのは、tebiki 現場教育に蓄積されているストック情報の量です。想像以上に多くの情報が蓄積されており、毎日約5 ~ 6個の新しい情報が加わっています。

また、tebiki現場教育はオンボーディングにも活用されています。

Tebiki社では、新入社員のオンボーディングにこのシステムを使用し、1週間の内、約80%が動画による学習、残りの20%がOJTで構成されています。内容としては「MVVの理解」「プロダクト理解」「営業プロセス理解」「顧客理解」など。また、これらが終わると、職種ごとのオンボーディングコンテンツが充実しています。任意で参照できるコンテンツも色々あって、例えば「非エンジニア職向けのスクラムとは?」など職種を超えてコラボレーションするのに役立つものも色々あったりします。

オンボーディングのコンテンツが日々洗練されており、1年前に比べてオンボーディングに要する時間が短縮されているという話を聞いて、自社のプロダクトながら良い話だなーと思いながら聞いてました。

(※ 開発チームのADRやDesignDocなどのドキュメントは、jira とかにまとまっているチームが多いです)

良い意味で驚きの少ない

逆に、アーキテクチャ/コードベース/開発の進め方などは良い意味で驚きが少なかったです。

例えば、

  • 技術選定の背景・理由などはたいていドキュメントにまとまっており、あとから見ても妥当と思えるものが多い

  • バージョンアップを随時やって 例えば Rails はパッチバージョン含めて最新を使ってたりする

  • スプリントレビューでは Sales/CS などのユーザーに近い人を巻き込んで、フィードバックをもらっている

  • 新機能を作る際にはユーザーインタビューや工場見学をさせていただいたりなど、直接ユーザーの声を聞く機会を作っている

  • 必要に応じて、別サービスや共通基盤として切り出している

言葉にすると結構素朴なんですが、事業課題や特性に合わせた技術選定を行っており、良い仕事をしているなと感じました。

私たちは仲間を募集しています!

私たちは仲間を募集しています! Tebiki 社では、エンジニアを募集しております。興味がある方は、ぜひカジュアルにお話しましょう!

▼採用HP

https://tebiki.co.jp/recruit.html

▼募集中のエンジニア求人一覧

https://herp.careers/v1/tebiki/requisition-groups/2514f131-4e3b-4f50-9539-27aa01a6639f