この記事はWHITEPLUS Advent Calendar 2023の1日目の記事です。
はじめに
こんにちは、ホワイトプラスでテックリードをしている仲見川です。 今回はホワイトプラスが運営する宅配クリーニングサービス「リネット」のエンジニアチームがどんな雰囲気なのかご紹介出来ればと思います。
昨年も同じような記事を書いており、この一年変わったり、よく聞かれるなーという部分をアップデートしました。
対象としている事業
今回ご紹介するリネットのエンジニアチームは
- 自宅から出せる宅配クリーニングリネット
- コートなどの冬服などを着用しないシーズンにクリーニングした後、保管するPremiumCloak
- 家で洗いにくい布団や靴の宅配クリーニングふとんリネット、くつリネット
の4サービスの開発を担っています。
リネットのエンジニアチームについて
リネットの運営においてエンジニアのチームは5つあります。
CX開発G（4名）
主にリネットでクリーニングを利用されるお客様が触れるシステムに携わっています。 Webの申込フォームやLP、マイページといった部分やカスタマーサービスのチームが使用するシステムなどが守備範囲です。
コアシステム開発G（4名）
主にクリーニングを行う工場で使用するシステムに携わっています。 注文を受け付ける際に最適な工場の割り当てを行ったり、クリーニング・保管工程の管理を行うシステムが守備範囲です。
アプリ開発G（2名）
モバイルアプリ開発に携わっています。 クリーニングをご利用するお客様が使うアプリや生産工程で使用されているアプリが守備範囲です。
インフラチーム（1名）
クラウド上にK8sでサーバー環境を構築したり我々が使うMac上で動く開発環境の開発に携わっています。 CI/CDなどの継続的デプロイに関しても守備範囲です。
情報システム（1名）
開発チームの紹介とはちょっと違うかも知れませんが、今年から専任の情シス担当が入社しCTOやエンジニアが担当していたタスクも巻き取ってもらう事でより開発に集中しやすい体制となりました。
開発スタイル
CX開発G、コアシステム開発Gでは1スプリント1週間サイクルのスクラムで開発を行っています。 スプリントバックログアイテムとしてタスク分解やストーリーポイントを用いた見積もりを行っており、計画したタスクがスプリント内に完了できるように進めています。
振り返りはGKPTやKPTで行っており、出たProblemに対して深掘りして解決策をチームで考えています。
コードレビューも盛んで「コト」に向かう姿勢で、ポジティブなレビューが飛び交っています。 若手エンジニアも積極的にレビューに参加して、日々成長しています。
CX開発GではADR（アーキテクチャデシジョンレコード）を採用してレビューの過程で議論し決定したことは資料として残すことでソースコードの品質を高めつつ手戻りを少なくしています。
技術スタック
Webサービス
CX開発G、コアシステム開発GといったWebシステムを担当するチームは基本的にPHPにてシステム開発を行い、一部でGoが使われています。
使い分けとしては現状では、計算量が多い処理を速く返したい一部のAPIや集配連携などの独立性が高い部分の他、基盤系の開発やCloudFunction、CloudRunといったクラウドのインフラを活用して開発を行う部分でGoを採用しています。
PHPはPHPStanを用いた静的解析をモジュール単位で行っており新しいモジュールはPHPStanの静的解析Lv8で記述出来ています。このあたりの話は以下で詳しく解説されています。
注文フォームであったりレスポンスが求められ入力要素の多い画面などはReactでフロントエンドを実装しています。 サーバーサイドエンジニアがフロントエンドも開発しており現在はフロントエンド専任のエンジニアはいません。
昨年と変化が大きい点としては生成AIの導入でしょうか、GitHub CopilotやChatGPTを使用しながら開発を行っています。
アプリ
インフラ、コラボレーションの部分はWebと同じなので省略しています。
アプリは今年大きく変化があった年で、元々ネイティブで開発しつつ一部ページをFlutterで開発していましたが、ホーム画面のリプレイスを機にアプリ全体をFlutterで作り直しました。iOS、Androidの開発がシングルソースとなり、開発を加速していける土台が整いました。
設計手法
全社的にDDD（ドメイン駆動設計）を採用しています。
モデリングの手法はSUDOモデリング（システム関連図、ユースケース図、ドメインモデル図、オブジェクト図）やRDRA・クラス図などをチーム、施策規模に合わせて選択しています。
ビジネスの変化に追従出来るよう変化に強い設計を心がけており、実際にソースコードとして実装する際のアーキテクチャも整ってきています。
2年前の記事なので変わっている部分もありますがこちらの「DDDのチーム理解度をレベルMAXにする方法（アーキテクチャ編）」にてアーキテクチャを紹介しています。
CI/CD
Webサービス
GithubへPushする度にCircleCIにて静的解析、テストが実行されるようになっています。
本番へのデプロイはGithubのmainブランチにマージされるとGoogle Cloud BuildにてDockerイメージがビルドされます。ビルドが完了している状態でリリースコマンドを実行するとK8sのクラスタに対し該当のDockerイメージを使用するようコンフィグを設定しコンテナが起動したらルーティングが切り替わる仕組みを構築しています。
今年はインフラチームにて高速化の取り組みが行われ、masterマージから5分程度でリリースが可能となりました。
iOS/Android
Bitriseを使用しておりGithubへPushすると静的解析、テストが実行されエラーが無ければApp Distributionでのテスト版配信まで行われます。
ストアへのリリースもmainブランチへマージするとBitriseからAppStore/Google playにそれぞれアップロードされるようにしています。 TestFlightや内部テスト版で実機確認後リリースを行っています。
働き方
スクラムを採用してタスクを細かく分解していることもあり、休暇は比較的取りやすくなっています。 エンジニアの有休消化率は9割程度。
残業時間は繁忙期閑散期で波もありますが平均20時間となっています。
男性含め育休の取得も盛んで、22年8〜9月で2ヶ月間コアシステム開発Gの男性EMが育休を取得しています。
環境面で言うと週5で在宅勤務の体制を今後も続けていく方針を定めたので原則フルリモートです。オフィスにエンジニア向けのフリーアドレス席があるので必要に応じて出社しての業務も可能です。 ホワイトプラスのリモートワークはセキュリティの観点から原則自宅での業務を前提としている事と、求めに応じて出社可能である事が条件となっています。
求める場合は全社のイベントをオフラインで行う際や規模の大きいプロジェクトのキックオフMTG等です。
業務時間としてはコアタイム無しのフレックスとなっています。現実的にはスクラムイベントや各種MTGなどがある為完全に自由な時間でとは行かないのですが、各自都合に合わせて早めに始業して早めに終わりにしたり、用事で中抜けしたりなどは自由に行っています。 10時〜19時で業務をしているメンバーが多いです。
雰囲気
ホワイトプラスの3つのバリューに合ったメンバーが多いです。
- のびしろで戦う
- 挑戦しよう。そして挑戦を賞賛しよう
- 心遣いで仲間を笑顔にする
- だれかが困ったとき一緒になって進んでいこう。そしてそういった行動を賞賛しよう
- 気づいたらすぐ行動
- 誰かがやるでしょ、は誰もやらない。気づいたら放置せず行動しよう。そしてそういった行動を賞賛しよう
エンジニアの気風としては技術的な好奇心と事業を成長させる想い両方を持ったメンバーが多いです。
勉強会・座談会・読書会
開発において技術のレベルを揃えることと、開発手法などの認識を揃えることを目的として勉強会などを実施しています。 こういった目的なこともあり勉強会等の参加率は高いです。
最近のテーマだとLaravelの勉強会を行いORMの使い方やEvent、Commandの実装方法などの勉強会を実施しました。 主な目的としてはLaravelの経験が浅いメンバーへの教育ですが、ベテランであっても改めて学び直すと気付きが得られる場となっています。
座談会はもう少し緩くテーマに対しての意見を交換する場で、例えばアジャイルのプラクティスをおさらいしながら意見を交わす等を行っています。
読書会は輪読や黙読などスタイルがありますが全員で本を読み、書籍のプラクティスと自分たちの違いについて取り入れていくかどうかなど意見を交わしています。
具体的には昨年末から今年にかけてドメイン駆動設計についての輪読会を行い全社でのDDDへの知識アップや認識を揃えることができました。
これらの勉強会などは主催者が決まっておらずやりたいと思った人が主催するか、チームの振り返りで出たアクションとして実施する2つのパターンがあります。 どちらもリネットの開発において課題だったり、より良くできそうなことに対して行っている事が多いです。
このあたりの勉強会については以下の記事にも詳しく書かれています。
グレード（等級）制度・評価
昨年、「専門職特化した等級制度の策定」で紹介したエンジニア向けの等級制度について、ここでご紹介します。社内ではこの制度を「グレード」と呼んでおり、以降もこの記事では「グレード」と記載します。
このグレード制度は、共通の基準から始まります。一定のグレード以上では、マネジメント職（EM*1）とテクニカル職（TL*2）として別々の要件が設定されています。
EMとTLの違いは、エンジニアとして関わるProduct、People、Project、Technologyに対する優先度にあります。EMでは優先度は「Product > People > Technology > Project」、一方TLでは「Product > Technology > Project > People」となっています。それぞれの役割には、この優先度に基づくミッションがあります。
どちらの役割でもProductが最優先されており、EMは主にPeopleの側面からチーム運営や育成にアプローチし、TLはTechnologyの側面からチームの開発力向上や保守性向上に注力します。
マネージャー職以外の全エンジニアはTLラインのグレードを適用しています。また、EMからTLへ、TLからEMへの移行も可能な設計となっており、EMラインに乗ったからといってTLラインに移れないわけではありません。
評価制度は半年に一度、目標設定とその評価の形で行われます。業務目標を達成する過程で、グレード要件に基づいてどの点で成長を目指すかを設定し、その成長を評価します。技術的な要素だけでなく、社会人としてのソフトスキルやバリュー行動もグレードの要件に含まれており、評価制度に組み込まれています。
さいごに
ホワイトプラスでは技術で事業に貢献したいエンジニアを募集しております。
