こんにちは。la belle vie株式会社 採用推進室です。
今回はエンジニア領域でよくご質問いただく開発環境の実態、開発プロセスなどについて、
la belle vie のTech組織（Technology Innovation & Solution部）の今後の方向性のお話も交えつつ紹介させていただきます。

※Technology Innovation & Solution （以後、TS&Iと表記）
※監修：Productチームリーダー　関口

Q.まず初めに、TS&Iチームで運営しているサービスはどのようなものがありますか？

大きく分けると3つに分類され、1つ目にGLADD・GILTそれぞれのPC版WEBサイト、SP版（android、iOS）WEBサイト、2つ目としてこれらに付随したGLADD、GILTそれぞれのバックオフィスシステム、3つ目にブランドベンダーさんとの在庫連携システムや、ファミリーセールプラットフォーム（WHITE Label）を運営しています。

Q.これらのサービスを運営するエンジニアチームは、どのような組織構成になっているのでしょうか？

現在はGLADD、GILTのサービス毎のチーム分けをしており、それぞれのサービスにフロントエンド、サーバーサイド、モバイルアプリのエンジニアが紐づいていて、そこにプロジェクトベースでProductチームが関与し、エンジニアが動きやすいように舵を取って進めていく体制をとっています。ただ、両サービスのシステム統合などインパクトの大きいプロジェクトが控える状況下においては、組織内の業務効率化やチーム力の向上、また、それぞれの領域をまたいだコミュニケーションのさらなる活性化が必要になるため、技術組織としてより一つにまとまりやすい形への転換を考えているところです。

Q.次に開発スタイルと、現在の形が出来上がるまでの背景について教えてください

GLADD、GILTともにアジャイル開発を進めています。背景については会社統合前にさかのぼりますが、まずGLADDについてはサービスのスピーディーな成長を重視していたため、開発体型の構築よりも、言ってしまえば問題が起きたところから解決していく“五月雨式な開発”＝アジャイル開発として進行していました。その後2社の会社統合があり、GLADD側のエンジニアもGILT開発を担当するようになったため、既存のシステムを解き明かしながらどのようにうまく運営していくか？という課題が発生しました。GILTも近しい思想、開発スタイルではあったと思いますが、同じくすでに市場に投下されているサービスであったため、いずれにしてもウォーターフォール型のように、１から計画を立て、形にしていくというスタイルがマッチしなかったというのが現在の開発スタイルにつながる背景の１つです。

その後、GILTチームで試験的にスクラムを使ってアジャイル開発をおこない、ある程度エンジニアの能力向上や、円滑な連携づくりも効果が出始めてきたため、これをどうGLADD側に落とし込むかという点を考えていた時に、これも当然ですが、組織文化の壁にぶつかりました。先ほどの組織体制の話にも繋がってくるように、開発環境からしてもGLADDはこうだから、GILTはこうだからという壁を取り払って組織を作り、加速させていくことで今後、更なる個々の技術ノウハウや会社全体のサービスクオリティの向上につながってくると考えています。

現在使っている開発環境をリスト化してみましたが、上述の通り、後付けで作り込んできた部分も多いため、書き出してみるとかなり多岐に渡っているのがわかるかと思います。

----------------------------------------------------------------------------------------------

◆GLADD
・サーバーサイド：PHP、GO、Python、TypeScript
・フロントエンド：Vue.js、Sass、jQuery、PHP
・フレームワーク：CodeIgniter、Echo
・データベース：MySQL
・アプリ言語：Swift、Java、Kotlin
・インフラ：AWS(EC2、ELB、SQS、VPC、ECR、ECS、ElastiCache など)
・監視・BI：Kibana、NewRelic、ServerDensity、Google Analytics、Amplitude、Tableau
・仮想環境：Docker
・開発環境：IntelliJ、Source Tree
・ドキュメント：DocBase
・ビルド・QA：Jenkins、SonarQube
・ログ集計：LogWatch
・外部サービス：GitHub、SendGrid、Salesforce
・タスク管理：Redmine、Backlog
・構成管理：Git、Docker
・デリバリー：Jenkins

◆GILT
・サーバーサイド：Ruby、Java、Node.js、TypeScript、Scala、R、MeteorJS、AWS、Lambda、Ruby on Rails、Sidekiq、Python、Shell
・フロントエンド：HTML、CSS、LESS、Angular1系、Vue、jQuery、CoffeeScript
・データベース：PostgreSQL、Redis、MongoDB
・アプリ言語：Swift、Java
・インフラ：AWS、Zeus
・監視・BI：Kibana、New Relic
・仮想環境：Docker
・ドキュメント：DocBase、Google Drive
・外部サービス：GitHub Enterprise、GitHub、OKTA
・タスク管理：JIRA, Backlog
・構成管理：Git、Docker、AWS CDK、Terraform、Nexus、Jinja
・デリバリー：Jenkins、Capistrano、AWS CodeDeploy

----------------------------------------------------------------------------------------------

また、現在の開発スタイルを選択したもう1つの理由としては、WEBシステムであるという要因が大きく、現代のIT業界のスピード感を考えたときに、長いスパンで計画を立てていくよりも変化への適応を優先し、市場トレンドや時代の流れに合わせていくことを会社として選択したということが理由となります。

全社的なアジャイル開発への挑戦という意味では、業界的にはやや遅いのかもしれませんが、例えば大手の大きな組織内だとプロジェクトの一部ではアジャイル開発を取り入れているものの、企業全体、サービス全体でみるとそこまで導入しきれていないということは多々あるかと思います。
そういう意味ではエンジニア一人一人の力が作用しながらサービス全体が変化していく面白みやスピード感は感じ取りやすい規模感、事業フェーズかと思います。

Q.ここからはもう少し日々のルーティン業務にフォーカスしていければと思います。基本的な業務はどのようなスケジュールになっているのでしょうか。

いわゆるサポート業務（簡単な仕様変更、不具合改善）だと3日～1週間くらいで終わるものから、中には年単位で動くビッグプロジェクトもありますが、半月～1ヶ月のプロジェクトがボリューム感としては多い印象です。

今後、組織編成が変わったとしても改善業務、不具合対応など日々発生するスピーディーに動くべき業務と、ある程度腰を据えて効果検証しながら動くべき業務は分けていく予定なので、中長期的に動くものについては、プロジェクト型にするか、特定のスキルセットの人員を集めたチームを作って運営することを考えています。
あくまで日々の業務を共にするチームという意味では小さく保ちつつ、その小さなチーム同士をうまく連携させていくイメージです。

Q.チーム単位、プロジェクト単位でのコミュニケーションは現状どのように取っているのでしょうか？

現状はサービスごとに、毎朝の簡単なMTG、1週間の最初と最後に進捗確認のMTGをGILTチーム、GLADDチームでそれぞれ行っています。
それに加えて、プロジェクト単位や、もっと細かい担当領域で定例を組んでいることもあります。
あとはTS&I社員全体で実施しているMTGを月1回、フリーランスの方も含めたMTGを月1回実施しています。
方向性を決めるものとしてはリーダーMTGを週1回行っており、全体的な課題抽出、現状確認をおこない、決定事項をチームMTGまたは全体MTGで共有していく流れとなります。

Q.今の出社体制はどのようになっていますでしょうか？

コロナ禍においては会社の方針に従い、週2日出社が基本的な体制です。（※緊急事態宣言下においてはフルリモート）TS&Iの中でも分散出社をしていますが、もともとは業務の関連性を優先して同じチーム、同じ業務を行っている人同士の出社日を合わせるように調整していました。

ただ、弊害として同じエンジニア組織にいてもGILTチーム、GLADDチームで分かれていることもあり、業務の関連性が薄いメンバー同士のコミュニケーションが極端に薄くなってしまう事象も起き始めていたので、現在ではある意味ランダムにシフトを組んで出社日を設定するようにしています。

ランダム出社により、「なかなか業務上の関わりがなかったのでほとんど話したことがなかったけれど、出社が重なったタイミングで〇〇さんとフランクにコミュニケーションがとれた」という声や、「入社したときにはコロナ禍でリモートワークが導入されておりチーム外の方とほとんど話したことがなかったため、いろんな人と話せるいい機会になった」という話はちらほら聞こえてきており効果はあったと思います。今後も試行錯誤しながらの出社体制がしばらく続きそうですが、直接顔を合わせてコミュニケーションをとることで生まれる仲間意識の醸成はやはりすごく大事だと実感しました。

Ｑ.la belle vieに在籍しているエンジニアたちの特徴、またこれから必要となってくるポジションはどのような人でしょうか？

フットワークが軽く、「とりあえずやってみる」ということに前向きな点は共通している気がします。これからジョインしていただく方にも年次にとらわれず、自分のいいと思ったことをアウトプットして、周りをうまく巻き込みながら面白いアイデアを出してもらいたいなと思いますし、会社としてはその方のスキル向上、いい経験値になるような環境を提供できればと思っています。

ただ一方で、攻めの姿勢ばかりでなく固める部分はそろそろ形を定めていかなければならない事業フェーズですので、冷静に組織を束ねるような役割も必要になってくるかと思います。たとえば品質やコストの部分で改善の余地があることは会社として強く認識しているため、フットワークの軽さは保ちつつ、エンジニアとしての経験を駆使して、よりよいサービスへと舵をとれる方にアイデアを出してもらうことも必要になってくるのではと思います。

Ｑ.最後に、これから加わっていただく方にとってla belle vieで働く面白みとはどんなところでしょうか。

会社の特徴として、やはり面白いサービスをお客様にお届けする、まずは動かしてみるということを最優先する文化があるので、スピード感を重視した会社であることはこれからも変わらない部分であると思います。それ以外の部分だと大きな組織で動くよりも個々の能力への信用度が高いと思います。例えばメンバークラスのエンジニアから提案があった良いライブラリ/サービスを試してみる、良い技術やシステムはフットワーク軽く取り入れてみるなど、それぞれが持ち寄ったノウハウ、知識を活かしやすい環境ではあると思います。そういったところもある種、スピード感を支える一つの要因にはなっているのかなと思っています。

あとはディレクターがディレクターっぽくないと言いますか、ある意味、放任主義ではあります（笑）もちろん相談相手として、技術的なアドバイスをもらうことは多々ありますが、垣根なく１エンジニアとして同じような目線で手を動かしてくれるので、そういった意味では上下関係に縛られにくい環境かと思います。

サービスインから約10年経過し、会社としてもベンチャー企業という枠を抜け出し始めたタイミングですが、サービスとしては完成形という状態ではないので０→１で作り込んでいくべきところもまだまだたくさんあります。大変なこともありますが、その分自分がこのサービスを作っているという感覚は持ちやすい環境かと思いますので、そういう点に面白みを感じられる方に加わってもらえると嬉しいです。

以上、今回はGLADD、GILTサービスの要となるエンジニア組織について紹介させていただきました。

まずはカジュアルにお話できればと思いますので、la belle vieに興味をお持ちいただけましたら、ぜひwantedly上からのエントリー、またはla belle vieの採用サイトからのご応募をお待ちしております！

https://recruit.labellevie.jp/