企業の経営課題と環境問題を解決する「世の中になかった全く新しい」プロダクト。フロントエンド開発は、まだ正解のないUIへの挑戦
フルカイテン株式会社のメイン顧客は、年商30億円以上のアパレルとスポーツ用品小売企業。他にも雑貨屋GMSなど多岐にわたる企業様に、在庫問題を解決するSaaS「FULL KAITEN」を開発・提供しています。
フルカイテンは「世界の大量廃棄問題を解決する」というミッションをかかげています。在庫問題の解決を通して社会問題となっている「大量生産」を「適量生産」に導き、廃棄を減らすからです。
大手企業で導入されているため、在庫が減る数字はインパクトが大きく、自分の仕事が社会に役立っていると実感しながら働けるのが魅力です。また、競合他社がおらず、これまで世の中になかったサービスを、顧客の手応えを確認しながら開発していくのが醍醐味でもあります。
そんなフルカイテンのメンバーのうち、4割を占めるエンジニア。
今日はフロントエンドエンジニア「ひろし」の仕事を通して、フルカイテンの開発体制やチームメンバーについて解説していきたいと思います。
開発環境について
「FULL KAITEN」バージョン3の開発を行っており、主に
・AWSのフルマネージドサービス
・CircleCI
・Github
・Docker
・PySpark
等を使っています。
助かるのは、皆が開発に効率よく注力できるよう、利用できるサービスはできる限り採用してもらっていることです。
特にCircleCIは、全開発チームで導入することで、V2で課題であったシステム領域における属人化の解消につながると考えています。
メンバーが提案したサービスを積極的に承認してくれる環境というのはありがたいです。
フルカイテンのフロントエンド開発に使う技術
フロントエンドの開発ではReact.js+TypeScript
FWはNext.js
APIはGraphQL
を使って開発しています。
テストの自動化は目下構築中で、E2EはPlaywrightを使用します。
グラフやテーブルなどの複雑なUIや認証機能など、OSSを使えるところは開発者・利用者数や運用状況を見た上で極力OSSを使うよう開発しています。
フルカイテン開発チームメンバー構成と開発の進め方について
フロントエンド以外の領域ではバックエンド、データ連携、データサイエンスチームがあり、各チームで裁量を持って開発を進めています。
2021年春先にバージョン3をリリースし、しばらくは不足機能や要望の多い機能追加、想定していなかったバグの修正などに追われていました。
その間は各チームを超えてペアプロする機会が中々持てなかったのですが、ここ最近はリリース後の混乱期もようやく落ち着き、徐々にですが越境する動きも出てきましたので、フロントエンドでもRustやデータ基盤の技術に触れる機会も増えてくるのではと思います。
各チームの壁を越えてタスクに取り組もうとする理由は、スクラムチームとしてのあり方やスキルアップの為でもあります。
また、現状では各領域での担当が1,2人なので属人化してしまうとリスクも大きいためです。
これはエンジニアメンバー全員で雑談(オンライン)したときに上がった話で、リモートの環境でも開発の進め方についてメンバーで話し合うことは、結構多い印象です。
フルカイテン開発チームの特徴
スタートアップではフロント/バックエンド問わずフルスタックで開発するパターンが多いかと思いますが、現時点のフルカイテンでは、私はフロントエンドエンジニアとして専任開発をすることがほとんどです。
インフラ⇒DB⇒バックエンド⇒フロントの流れで開発するのに慣れていたので最初違和感は感じていましたが、今はバックエンドチームとこまめに認識合わせしながら進めています。
また、専任でやることでフレームワークの使い方やベストプラクティスを考えるのにより時間を使えるようになったので技術的な理解が深められていると思います。
キャリア構築にあたってよく「T字型」を目指せと言われますが、まさに1つを深めつつも横展開していくのに良い環境のように思います。
特にフロントエンドは技術の進展が早いので、キャッチアップしていくために完全専任とはいかずとも主軸を置いてやっていこうと考えています。
フルカイテン開発チームの魅力
第1に、エンジニア目線になりますが、バージョン3開発時やその後の状況に応じて取り入れる技術スタックも全てエンジニアメンバーで選定するので、スキルアップが図れる点が魅力だと思います。
もちろん運用することが前提なので何でも良いという訳では無いですが、その点の裁量が大きいのはエンジニアとして成長できる要素の一つだと思います。
また、開発プロセスやチーム開発のあり方についてもよくメンバーで議論して改善中であり、その点に興味のある人にとっても挑戦できる良い環境だと感じます。
第2に、誰と働くかという「人」の部分でいくと、メンバーの皆さんがコミュニケーションが丁寧で優しいです。
弊社のプロダクトは仕様がややこしいので、相手の理解度やコミュニケーション齟齬に対して各メンバーが意識を持っている点はとても重要になります。
その点ちょっとした質問や、以前聞いたけどどうしても思い出せない・追えない情報に対して改めて質問しても、背景から丁寧に答えていただけたり、Slack上で言語化が難しければ気軽にGoogle Meetを投げて口頭ベースで認識齟齬をなくして進めていけます。
また、技術力があるからといって優劣を感じさせる空気を作ったり、難しいコミュニケーションを取ったりしない良さも大きいです。
第3に、技術だけでなく、弊社プロダクトをご契約いただいている企業様のドメイン(業界)知識に開発メンバーが高い関心がある点も挙げられると思います。
当初はBiz側からの要望をプロダクトに反映させていく(良くも悪くも)社内受託的な傾向があったのですが、そのスタイルだと、今まで世の中になかった類のプロダクトを開発していることもあり、リリース後に想定外の仕様バグが浮き彫りになりました。
元々エンジニアメンバーもドメイン知識が少ないことには問題意識があったので、こういった失敗を活かすことができました。
それからは、ユーザーが何を考えているかを知るために、2週間に1度、CSチームからプロダクトの活用状況やユーザーの思考回路をヒアリングする会を設定し、知識を取りに行くようになりました。
1日のシンプルなスケジュール
リモートワークのメリット・デメリット
エンジニアは各チームのメンバーが全員バラバラの地域に住んでいるので完全オンラインで業務を行なっています。(大阪本社は自由出社、東京シェアオフィスは水曜日の任意出社です)
その中で気になった、メリデメは以下となります。
メリット
・オンライン上の会話は主に個別のタスクに絞った会話になるので、無駄なくサクッと仕様を決めてすぐに開発作業に取り組める
・Slack上のやり取りは残るので、過去に仕様が決まった文脈がわかる
・以前と比較して、言語化力が上がった...気がする
・疲れたらベッドに寝転がるといったオフィスではやりにくい小リフレッシュが可能
デメリット
・(人によりますが)シンプルに、家では気が抜けがち!?
・エンジニアチームとビジネスチームが同じ空間にいないことで、ドメインに関する質問をすぐ出来ない
→ 他チームに積極的に情報を取りに行く姿勢も求められるが、フルカイテンでは「質問責任・説明責任」というカルチャーがあるので煙たがられたることはない
・ややこしい仕様をSlackだけでやり取りすると仕様バグの温床になる
→ 議事録を取る。実装中に問題が生じるとすぐにGoogle Meetで関係者に確認
・無駄話のなさ・心理的にタスクで繋がるだけの関係に陥る
→ 時々開催するリモート雑談会や、月1で東京大阪のプロダクトチームが集まるオフライン会で解消
こんな環境で仕事しておりますが、現在フルカイテンではフロントエンドエンジニア募集中です。
大阪・東京・それ以外の地域の方もお待ちしています。
ちょっとでも興味のある方はカジュアルなお話からでも。よろしくお願いします!
FULL KAITENでは一緒に働く仲間を募集しています!
世界の大量廃棄問題を解決する!AI×SaaSプロダクト「FULL KAITEN」
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?