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

 

そのため、社内では

  • エンジニア全体での勉強会
  • 適正を考慮した異動
  • 部内で制定している改善プロジェクト

等をうまく活用し、可能な限り幅広い領域に触れられる工夫をしています。

特に開発チームでは、「通常業務とは別に、勤務時間の20%程度を利用してチーム・サービス開発における課題に取り組む」というルールを設けており、自分の担当ドメイン以外にもバランスよく触れられる機会をつくっています。

 

 

まとめ

今年に入ってからも開発組織は大きく変化していますが、まだまだやりたいことに対して開発メンバーが圧倒的に足りていません。プロダクトも組織も大きな転換点にあるので、これからの開発をさらにリードしていただける方を絶賛募集中です!

少しでも興味を持っていただけた方は僕のTwitterDM等に気軽にご連絡ください!

 

Twitterhttps://twitter.com/takumin513

 

Gracia公式Twitterhttps://twitter.com/gracia_tanp
サービスグロースエンジニア:https://herp.careers/v1/gracia/8iShxaRK1ofK
基幹業務システムエンジニアhttps://herp.careers/v1/gracia/okAApFG9c48Q
募集職種一覧:https://gra-cia.co.jp/careers

エンジニア採用:https://gra-cia.co.jp/engineer

 

twitter.com