【エンジニア】Graciaの開発体制について

この記事は最終更新から時間が経過しているため、最新の情報と内容が異なる可能性があります。

こんにちは、GraciaのCTOの林です。

前回のブログでは去年の振り返りを行いました。今回のブログでは、今年に入ってから大きく変わったTANPのプロダクト開発組織について書こうかと思います。

現在の組織体制について

TANPの開発に関わるメンバーは、CTOが管轄するプロダクト部に所属しています。

また、プロダクト部には「開発」「デザイン」「PdM」の3つのグループが存在します。

f:id:gracia_tanp:20210218142804p:plain

※green（開発）、pink（デザイン）、blue（PdM）

もともと、PdMはビジネス部門(主にマーケや物流)のチームに置かれていましたが、

ビジネス部門が詳細な仕様書を書きエンジニアに開発を依頼するという社内受託になりつつあった
プロダクトに関わるロードマップの策定(=PdM)と実行責任(=エンジニア)が部を跨いでおり分断されていた

等の問題点があり、チームとして開発を進めやすいようPdMをビジネス側から独立させ、同じプロダクト部の中に属して開発を進める方針に転換しました。その結果、PdM、エンジニア、デザイナーが早い段階で協調して開発を進められるようになりました。

また、開発グループ内には「エンジニア」とは別に「アーキテクト」というポジションを設けています。これは事業・組織規模の拡大に伴い、これまでの「スピード重視・単独開発」的な体制から、よりチームに目を向け、開発者体験の向上や生産性の向上にコミットしていく必要があると考え、新設したポジションになります。アーキテクトには主にチームの効率化や技術負債解消へのコミットなど、事業・組織規模の拡大における品質担保に関わる業務をお任せしています。

2月にも新たに2名のエンジニアメンバーを迎えていますが、このアーキテクトチームが中心となり、様々なオンボーディングを進めています。詳細については、また後日ブログにて紹介させていただければと考えています。

開発体制について

Graciaで開発するギフトEC「TANP」は、ECサイトに加え、ロジスティクス（物流）に関わる管理システム等も含め全てフルスクラッチで開発を行っており、開発対象となるプロダクトドメインは多岐に渡ります。

f:id:gracia_tanp:20210115160039p:plain

具体的には、下記のようなドメインがあります。

お客様が実際に触るECシステム関連(プレゼント検索機能、会員機能など)
注文情報を整理し、出荷作業を行うための管理システム関連
適切なタイミングや仕分けで会計計上を行うための会計システム関連　等

これらはそれぞれ追うべき数値やミッションが異なり、特に倉庫に関わる管理システムの場合は現場との密接なやり取りが求められるため、物理的に拠点が離れているEC側のメンバーも包括した1チームでの開発は難しいと考えています。（Graciaでは、本社オフィスを五反田、倉庫を品川シーサイドに置いています）

そこで当社では、ロジスティクスに深く関わるメンバーをエンジニア内で切り分けた上で、さらに下記の3チームに分け、それぞれPdM・エンジニア・デザイナーをアサインしています。

UXチーム
WMS(倉庫管理システム)チーム
会計システムチーム

f:id:gracia_tanp:20210218142847p:plain

開発フローは基本的に各チームに任せており、チーム毎に異なるフローを採用していますが、UXチームであれば1週間、WMSチームや会計チームであれば2週間程度を目安に開発計画を立て、進捗確認を行っています。

実施頻度は下記のような目的に基づき調整しています。

UXチーム：起案と検証のサイクルを多く回し打ち手を増やす
WMSチーム・会計チーム：納期の順守や不確実性の排除等、安定性を担保する

チームを分けるメリットとデメリットについて

実際に3チームに分けて開発を進めていく中で、チームを分けて開発を進める体制のメリットとデメリットを感じているので、いくつか例を挙げたいと思います。

メリット

コミュニケーションラインが限定されるため開発スピードを出しやすい
担当ドメインの理解が深まる

特に「担当ドメインの理解が深まる」という点については、まだまだ属人性の高さが残るフェーズ、かつ一定の専門知識が求められミスが許されない業務では無視できない要素です。

例えば、Graciaで開発する倉庫管理システムでは下記のような知識が求められます。

在庫管理（入庫・検品状態の管理、棚卸し等）
オペレーション管理（ピッキング・ラッピング状態の管理、発送状態の管理等）
顧客情報管理（個別要望の社内伝達管理、個人情報との紐付け、決済状況の管理等）
パートナー企業との連携（発送情報の管理、商品ページ情報の登録管理等）
適切なタイミング、仕分けによる会計システムへの反映

これらは一般的な専門知識に加え、Gracia独自のオペレーションや現状を踏まえた上で、将来的なスケーラビリティを担保した対応が必要となるため、現場のメンバーとある程度物理的に業務を共にしなければ本質的な理解に辿り着くことが難しく、現場との連携が希薄であることは、細かな条件のキャッチアップ漏れや思惑の行き違いなど、思わぬコストが発生する要因にもなりかねません。

現場と同じ温度感でワンチームとなり、より確度の高いコミュニケーションを取るためにも、現状ではある程度ドメインや期間を区切り専門性を高めていただくという体制を重視しています。

デメリット

チームを横断した調整が難しい
使用する技術やドメインがある程度固定されてしまう

チームを横断した調整が難しい

例えば、新しいギフトオプションの追加開発を行う際は、下記のようなポイントでチームを横断したタスクが発生します。

ギフトオプション選択画面の設計 ⇒ UXチーム
選択されたギフトオプションを発送フローに組み込む ⇒ WMSチーム

チームを横断する場合、各チームで追うべき数値やミッションが異なるため、施策を実施するか否かについて摩擦を生じやすく、優先順位を策定するのが難しいという課題があります。Graciaでは可能な限りフラットに議論するため、期ごとに全社戦略とそれに紐づくチーム毎のプロダクトミッション、ロードマップを整理し、チーム間で共有した上で議論し、意思決定を行うようにしています。

使用する技術やドメインがある程度固定されてしまう

若いメンバーが多い中、業務で触れる技術がある程度固定されてしまうことで、メンバーの成長を阻害してしまう可能性があります。

f:id:gracia_tanp:20210218142913p:plain