半年でテストコード・プロトタイプを導入し品質管理と開発速度の両方を向上。FULL KAITENフロントエンド開発について深堀り！
現在FULL KAITENの開発を支えているフロントエンド（FE）チーム。業務委託のエンジニアも合わせて6名。仕事内容は？メンバーは？他社と違うところは？FE歴十年を超える赤木（あかちゃん）と、その赤木と前職で同じチームに所属していた出口（でぐっちゃん）にインタビューしてみました！
フロントエンドエンジニア（FE）はこんな仕事をしています！
■業務内容
新機能の開発
機能改善要望についての開発
障害発生時の対応
■FEの範囲
React/Redux、Next.jsを使用したWebアプリケーション
■使用技術
・開発言語
TypeScript、JavaScript、HTML5、CSS3
・ライブラリ・フレームワーク
React/Redux、Next.js、chart.js、MaterialUI, Devexpress、webpack 、Jest
・API通信
GraphQL、REST
・インフラ
Amazon Web Services
・AWS製品
Elastic Beanstalk、Lambda、S3、Cognito
・ツール
Notion、Jira、Slack、GitHub、CircleCI、Sentry、Figma
■開発プロセス
スクラム開発（2週間のスプリント）
FEメンバー紹介！
現在フルカイテンのFEチームには3名の正社員が在籍（他に業務委託のエンジニアが3名）。お互いのことがどんな風に見えているのかな？一言で答えてもらいました！
赤木（赤ちゃん）マネージャー：
・誰かと会話するのがとにかく好き。「技術はそんなに興味ない、とにかく人が好き」と本人は言っているが、実際は技術も結構好きだったりする。
・頼れるフロントエンドを極めしおじさん。経験や知識に奢らず技術に貪欲さがある。
出口（でぐっちゃん）リーダー：
・穏やか、温厚、丁寧。FEに限らず幅広く知識がありオールマイティに対応できる技術力の持ち主
粂（ひろし）：
・ユーザ目線でものづくりできる人。いわゆる“エンジニア“っぽくない目線も持っていて話していておもしろい。
FULL KAITEN_FEのここが魅力！
専任開発
フルカイテンは専任開発制をとっていて、バックエンド・FEと分かれて開発を行います。
出：以前はフルスタックエンジニアだったのですが、専任開発でFEの知識を深めたいと思っていたところ、先に入社していた赤木からフルカイテン良いよ！と声をかけられて転職しました。FE開発に専念することで知識がさらに深くなり、経験値が確実に上がっています。
テストコード
出：品質管理に力を入れていて、テストコードを書いて自動化していることも弊社の魅力じゃないでしょうか。
赤ちゃん（以下「赤」）：確かに、今のFULL KAITENほどの規模で（エンジニアが30名弱）テストコードやろうぜ！って旗振ってるところはなかなかないんじゃないですかね。品質管理よりも、とにかく「どんどん作れ～！」っていうのがほとんどなんじゃないでしょうか。
赤：テストの自動化って、エンジニアのスキルとしても大事なことなんですよ。FEとしての高みを目指すため、ステップアップして大きなプロダクトに関わりたいって言う時には外せない。だからとても良い経験になると思います。
FULL KAITENのテストコードは、僕が入社した時に提案し、取り組み始めて半年経ちました。当初テストケースが3つだったのが、今は1300ぐらいまで増えましたね。
テストコードを書き始めたきっかけ
赤：顧客が多くなってきたのと、お客様の規模感が変わったことですね。これからもどんどん大きくなっていくだろうし。
僕の入社時は「とにかく価値提供だ！」という勢いで、品質を重視する余裕はなかった。入社2ヶ月でリーダーになった頃、将来のために今から品質管理もきちんとしておこう！と提案しました。CTOは全く反対しなかったですね。
テストコードを書き始めた結果
出：地道にやっていくものなのですが、必ず開発速度の向上に繋がるはずです。
赤：地味な効果ですが、確実に未然にバグを防げていますね。これから顧客もFULL KAITENも規模が大きくなっていきますから。何と言っても「継続は力なり」ですよ！
計画的リリース
FULL KAITENは自社開発のプロダクトであるので、エンジニアは上流工程から携わることになります。これはとてもやりがいのあることなのですが、技術選定や仕様の会議に時間を取り過ぎて「開発の時間が取れなくなった」「開発に集中できなくなった」という悩みもありました。しかしそれが今は改善されているらしい！とPOの島田からタレコミがあったのです。
リリース1ヶ月前からテストフェーズに入れている
赤：でぐっちゃんが入ってきてスケジュールに余裕ができるようになった。開発の流れを変えてくれたよね。今までリリースぎりぎりまでコード書いてパンパンだったけど、今は1ヶ月前にはテストフェーズに入れるようになった。
出：先ほど話したテストコードもですが、タイムリーに修正を入れたり、プロトタイプを作ってお客様の反応を得ながら開発を進めていくようになりました。
チームのみなさんの改善のサイクルがすごく早いのでありがたいです。
赤：そう、メンバー発信でどんどんPDCAを回していける。改善提案がチーム全体に浸透するのが早いし、問題が起きた時に何が問題なのか？再現しないようにはどうすればいいか？をメンバーで考える。トップダウンじゃないから、進め方も自分達で決める。
半年前はバグのもぐらたたき
赤：以前は潰しても潰しても新しいバグが出てくる、まさにもぐらたたき状態でした。今のものではどうにもならんと、積極的にリファクタリングし、半年で7割ぐらいのコードは書き換えて、もう設計から見直して根本からやり直しています。そういう地道な作業が品質改善に繋がり、結果、時間の短縮や顧客満足にも繋がっていますね。
出：これも、やろう！と言って実際にできているとこ（会社）なかなかないですし、そういう時間さえ取ることが許されていないんじゃないかなと思いますね…
赤：そういう意味では、こういう変革についてCTOからダメって言われたことないね。「トップダウンではなく現場に任せる」主義のCTOの影響があって、現場も自ら考えて動くようになっていくんですよね。考え方がチームに影響して浸透してる。かと言って「放任」ではなくて、ある程度の道幅や提案はくれる。それをこちらが断ることもできる。
プロダクトの立て直しは自分が過去に何度もやってきたことなんで、慣れたものなんですが、ここ（フルカイテン）では、上から振り回されているっていう感覚も、開発させられている感も全くないですね。
CTOの柳本は以前のインタビューでも「育てるという感覚は疑問を感じますし、上下関係には無理が出てきている」「育てるより、その人がやりたいことを実現できる環境をつくることが大事。環境を整えても、その環境で活躍するかはその人次第」と話していました。
彼の紹介記事はこちらです。
プロトタイプ
出：これまでは、完璧なものを作って最後までできてから、CSやお客様に確認してもらい、指摘があった箇所を作り直すという流れでした。最近はプロトタイプを作って事前にCSやPOに触ってもらい、「こういう方向なら問題ないよね」「ここは違うよね」とポイントを押さえてから実際の開発作業に入る、という流れに変えました。なぜなら
・触ってみないと分からないことが多い
・やってみて「なんか違う」が早く判明する
・手戻りがないので結果早く作業が終わる
赤：プロトタイプを作成するようになり、開発がぐっと早くなりました。例えば最近の新機能「ヒートマップ」を以前の流れで作っていたら、10日ほどは無駄にしていたんじゃないかな。ただ、プロトタイプもテストコードと同じく、誰にでも作れるわけじゃない。もちろんスキルが必要だし、確認したいポイントを押さえるセンスも必要なので場数を踏むことが大事なんですよね。
このプロトタイプの導入についてでぐっちゃんが提案した時、CTOは即「OK」だったし、どういう風に進めるのかも現場に任せられている。
出：実際には赤木さんと会話しながら決めていますね。
赤：こうして場数を踏んで経験値を上げることで、色んな引き出しを持ち、エンジニアとしての懐が広くなっていけばいいと思っていますね。
上流工程から携わる
FULL KAITENは自社開発プロダクトなので、エンジニアが揃って「自分達で相談しながらプロダクトを作っていくのが楽しい」「育てていく感覚」「技術選定など上流工程から携われるのはスキルアップに繋がる」と言います。
難しい問題が、それに合わない人もいること。受託開発などで、「指示されたものを指示された通りに作る」事をベースとして開発して来た人もいます。
今のメンバーはみんなFULL KAITENにあれこれ意見しながら開発しているようです。それはエンジニアとしてもとても貴重な経験になりますよね。
価値観の違い
赤：そうなんです。リアルな話をすると、業務委託の方がFULL KAITENに入ってきてまず戸惑うのがそこなんですよね。言われたものをこなすのが今までのスタイルだったわけで、そこに馴染めない人もいる。もちろんそれが楽しいと言う人もいる。そこは人の価値観それぞれですからね。自由度が高いことを「やりがいがある」と思うのかどうかは人それぞれですが、とにかく自分で考えてプロダクトを形にしたい人にはFULL KAITENは最高の環境じゃないですか。
赤：もう1つ新しく入ってきた人が戸惑うことがあって、それは「1人で、自己完結で何か作らないといけない」という認識。今のFEはチームでのアウトプットの最大化を重視しているので、色んな人に聞いて、最短プロセスでやっていくことを大事にしているんですよね。
---
個別に開発するのではなく、様々なバックグラウンドを持つ人達が知識や経験を出し合えばより良いものが作れる。チームワークがとても大事なんですね。
チームのカルチャー作り
赤：チームでの会話がしやすいようにバーチャルオフィス「Gather」を導入しています。コードレビューをウォークスルーで話しながらやろうよ〜と思って。意図的に話しかけて、テキストベースでやらないようにしていますね。
例えばひろしができない！って悩んでいる時、ベアプロしてもらえませんか？って気軽に聞いてきます。そんな風に声をかけ合える言える文化ができつつありますね。
出：私が良いと思うのは、それに取り組むんだけど、強制する空気はないってこと。仕事のやり方は人それぞれ、黙々とやりたい人も時もあるし、誰かと話したいタイミングもありますよね。
スキルよりコミュニケーション重視
赤：今、とてもチームの雰囲気が良い感じです。技術で尖っている人よりも、FEチームはコミュニケーション重視ですね。採用もミッションへの共感・カルチャーフィット・コミュニケーション能力を主に見ています。
成果・顧客の声の共有
自分ちが育てたプロダクトが、どこで誰に使われて、どんな風に役立っているのか。それを知ることはとても大切ですね。FULL KAITENではお客様からのフィードバックや成果をエンジニアに報告する文化が自然と生まれました。定期的なミーティングの中で今は仕組み化されています。
赤：FEって実はお客様に一番近くて、お客様の声を一番聞きやすいポジションなんです。それでも今までの職場では、成果や感想を聞くことはなかなかなかった。悪い所、治してほしい所はいっぱい聞かされてきたけど（笑）
フルカイテンでは主にお客様と接するCSが成果や感想。フィードバックをslackで送ってくれますね。それをFEの業務委託の方にも共有します。
定期的にCSとのオフライン会もあり、そこでも色々と成果について聞くことができます。その1つ1つがチームのモチベーションを上げています。
そもそもどうしてこんなにお客様の声がもらえるんだろう？FULL KAITEN特有かな。バーティカルSaaSだし、顧客が抱えているペインと解決する課題の大きさのせいかな。あと、CSがすごくハイタッチにお客様を支援しているから生の声をもらう機会が多いとかかな。そしてCSがちゃんとこちらに共有してくれる文化が自然と出来上がっているから。
これは意外と手間だし難しいんですよ。とても嬉しいですね。
出：本当に嬉しいですよね。頑張ろうって気持ちになります。
---
その他にも3カ月に1度の全社会議でお客様の声を共有する機会もあります。
お客様の声は社員みんなのモチベ―ションになっていますね！
成果事例紹介の記事はこちら！
全社会議「ALLHANDS」の様子はこちら！
フルカイテンではエンジニアを大募集中！
BE・FEエンド・データエンジニア・データサイエンティストなど、現在の募集職種は下記採用ページをご確認ください。
エンジニア専用採用ページ
エンジニアリングマガジン
開発に関する記事をまとめました！