株式会社Faber Company 開発運用チームの菅原です。
ある新卒エンジニアの一年間（前編） - Faber Company 開発ブログ に引き続き、後半6ヶ月間のできごとをメインにお伝えします。 まだこちらの記事をお読みでない方は、ぜひ前編から通してお読みください。
Faber Company（ファベルカンパニー）について
株式会社Faber Company は、「辺境の知からマーケティング・ゼロを実現する」を使命として、企業のマーケティング生産性の向上を目指しています。 蓄積したマーケティングの知見を現場につなげるため、さまざまなサービスを展開しています。
この記事では、中でもコンテンツSEOツールである「ミエルカSEO」を取り上げます。 Faber Company が現在運用している SaaS では最も古いもので、リリースから9年という歴史のあるプロダクトです。
ミエルカSEOの開発は、日本の Faber Company とベトナムにある子会社 Faber Vietnam Co., Ltd とで行われています。 Faber Company で働くエンジニアは、ベトナムのメンバーと直接英語でやりとりしながらプロダクトの開発・運用を行っています。
半期を終えて
最初の半年が過ぎたところで、上長と面談して次の半年間の目標を設定します。これまでに見つけてきた課題をどうやってチームで解決するかに注目して、半年かけて目指すものを決めました。
特に注目したのがお客様の手元で発生する不具合です。 これまでオブザーバビリティの向上に十分なリソースを割けておらず、お問い合わせをいただくまで開発チームが不具合に気付けない状況が続いていました。
エラーの発生数を減らし、それでも起こるエラーにはできるだけ早く気づけるようにするための取り組みを提案しました。
Inspection team
プロダクトオーナーと協力して、不具合対応を主に行うチームを新しく立ち上げました。
はじめの半年の間も不具合対応に関わることはあったのですが、日々の対応に忙殺されて、そもそも起こるエラーを減らすための根本対応になかなか手が出せていないという課題がありました。
このチームは、お客様のお問い合わせを受けた後の技術的な初期対応と原因調査を担当し、開発チームに対して対応と再発防止策を提案するチームです。 機能開発をおこなうエンジニアが突発的な調査タスクに対応しなければいけなくなる頻度を下げ、より素早くお客様にお返事できるようになりました。
指標を追う
より安全に、よりスピーディーに開発を進めていくため、コード品質の追跡をさらに拡充させました。
上半期で導入したスペルチェックに加えて、SpotBugs によるソースコードの静的解析や GitHub Actions 上での自動テスト実行を導入し、定期的に計測・報告できるようになりました。
特に自動テストは製品・チームにとって大きな変化となりました。
社内最大のプロダクトであるミエルカSEO は30万行規模の Java バックエンドをもっています。 私が入社した時点では一部のコア機能にはテストコードがあったものの、メンテナンスできるのは特定のエンジニアだけに限られており、ほとんどの機能開発を手動でのテストに頼っていた状況でした。
カバレッジの計測・監視からはじめ、ベトナム側のリーダーエンジニアと協力してテスト方針の策定やテスト環境の整理をおこない、チーム全員がテストコードを書けるように働きかけました。
現在は、新機能のコードには必ずテストコードがセットになるようになり、既存コードにも継続的にテストコードが追加されています。
カバレッジも徐々に改善し、9ヶ月間で8ポイントアップとなりました。
お客様に安心して使っていただける製品をめざして、今後もさらにテストを充実させていく予定です。
しかし、テストコードを書いただけでは製品はよくなりません。この資産を的確に活かしてインフラ更新やアーキテクチャ改善に繋げていきます。
テスト戦略や詳しい状況については、別の記事でお伝えします。
レビュー
2024年が明けてからは、ベトナム人エンジニアが書いたコードをレビューする機会も増えました。
前半の間はベトナム側のチームリーダーにレビュー依頼が集中しすぎており、彼は多いときで月間90件以上（！）のレビューをこなしている状態でした。
コードレビューが一人に集中すると、レビューが開発上のボトルネックになって開発速度を落としてしまうほか、他人のコードを読んで議論することによる学びの共有ができず、メンバーのスキルアップにつながらないデメリットも生まれます。
チームの再編でリーダーの負荷を分散しつつ、私もこの時期に新たに Faber Vietnam に参加したメンバーのレビューをお手伝いすることからスタートしました。
ミエルカSEO のコードレビューでは必ず 2人のレビュアーが指名されます。 実装したメンバーとのコミュニケーションはベトナムにいるもう一人のレビュアーに助けてもらいながら、設計の考え方や命名方法の議論を進めました。
彼は大学を出て初めて商用のコードを書いたとのことで、レビューが詳しくてよかったとリーダーを通じて伝えてくれました。
現在は、DBテーブル構造やクラス設計の変更がある箇所、日本側のメンバーとすりあわせが必要な箇所など、手戻りの影響が大きい場所やベトナムメンバーだけで意思決定できない場所について重点的にレビューに参加しています。
設計方針をコーディングを始める前に相談する機会も増え、少しずつ「ワンチームでいいものを作る」に向かっていけている実感があります。
Faber Company 開発運用チームで一年働くとどうなる
まずはコミュニケーションと向き合うことになりました。 学生の頃に海外に行ったこともあり英語には抵抗がなかったのですが、最初の数ヶ月はベトナムなまりが全く聞き取れず苦労しました。。。
とはいえ Faber Company の選考に英語力の要件はありません（記事公開時点）し、ベトナムメンバーも全員がペラペラなわけではありません。
英語は手段にすぎません。擬似コードを書いたり、SQL を書いたりしながら、あの手この手でなんとかしてコミュニケーションをとっています。
次の課題はプロジェクトマネジメントでした。
機能開発、不具合対応、負債の返却、という異なる性格のゴールにいっぺんに向き合うのはかなりエキサイティングである一方、限られた時間と開発リソースをどう使って目標を達成するかを考えなくてはいけません。
日越両方のエンジニアや、社外のアドバイザーに相談しながら、早くから「決める」「腹を括る」経験を積めるのは Faber Company のいいところです。
そして、個人的にありがたかったのが学会参加です。
私は電子系が専門で情報の勉強はしていなかったので、サービスの表面的なところは組めても、内部で使っている自然言語処理の詳細はよくわからないことが多かったです。
会社から人工知能学会・言語処理学会などに参加し、いろいろな方に入門書を尋ねて勉強のとっかかりをつかむことができました（話を聞いてくださった皆さん、ありがとうございました）。
学会参加について詳しくはレポート記事をご覧ください！
プロダクトとそれを支える技術の両面に関わりながら、これからもよりよいサービス作りを目指せたらと思います。
Faber Company は一緒に働く仲間を募集しています
株式会社Faber Company にご興味のある方は、採用サイトをご覧ください！
