株式会社GIGのSales事業部で、商品企画チームのマネージャーをしている福田です。

プロダクト開発を進めるにあたって、組織やプロセスも並行して改善していくことは重要な取り組みだと思います。

今回は、商品企画チームが主に行っている『LeadGrid』プロダクト開発において、過去の遍歴を踏まえながら、どのような開発組織や開発プロセスを遷移していったのかをご紹介します。

商品企画チーム（≒LeadGridプロダクト開発チーム）の遍歴

立ち上げ期から現在に至るまで、3つのフェーズに分けてお伝えします。

①立ち上げ期

この時期は、LeadGridに関するメンバーはすべて1チームに所属していました。

また、LeadGridはノーコードだけではなく、ローコードによるカスタマイズ機能もあるため、エンジニアメンバーはSaaSとしての本体機能の開発（以降、プロダクト開発と呼ぶ）をしながら、自身で開発した機能を用いての個別案件導入対応（以降、クライアントワークと呼ぶ）も並行して行っていました。

課題管理はカンバン形式を採用し、クライアントワーク側のタスクとプロダクト開発のタスクを混ぜた形式で実施していました。

この時期のGoodな面として、エンジニアメンバーの顧客理解度や課題解像度は非常に高い状態を維持できていたことです。しかし、どうしてもクライアントワークが優先されてしまうため、プロダクト開発スケジュールの優先度が下がってしまうというBadな面も見えてきました。

そのため、プロダクト開発をメイン業務とするエンジニアメンバーと、クライアントワークをメイン業務とするビジネスメンバーで二分化して、上記の課題感の解消を図ってきました。

②エンジニアチーム期

立ち上げ期の課題感から、プロダクト開発をメインとするメンバー（ほぼエンジニア）でチームを構成しました。職種としては、フロントエンドエンジニア、バックエンドエンジニア、インフラエンジニア、デザイナーが所属しており、マネージャーの自分がEM/PMを兼任していく構成となっています。

当時のメンバー構成　※実際の人数とは異なりますまた各メンバーが素早い意思決定をしつつ、適切なリリースができるように、

・チーム内で小チームを3つ定義し、それぞれの小チームの担当領域やミッションの定義
・上流〜下流までの開発プロセスと、それぞれのプロセスにおいて誰が主導するべきかの図式化

を実施していました。

小チームの担当領域と、それぞれのミッション

当時の開発フロー

Goodな面としては、

・プロダクト開発メンバーを独立チームとしたことで、開発スケジュールがクライアントワーク状況に左右されるケースを縮小化できた
・PdMや選定フェーズを取り入れ、課題に対しての優先順位を明確化したので、インパクトが少ない課題解決に取り組んでしまうケースを縮小化できた
・小チーム化とリリースまでの流れの可視化によって、課題発見〜リリースまでの不必要なコミュニケーションコストを縮小できた

などがありました。

逆にBadだったかなと思う面としては、

・まだまだ顧客課題の解像度が必要なフェーズにおいて、「UI・UXチーム」と「システム・アプリケーションチーム」という分け方をしてしまったため、ドメイン知識や顧客解像度がシステムアプリケーションチームに溜まりづらい状態を引き起こしてしまった
・プロダクト全体の機能数が増えていくなかで、小チームすべてが全機能の理解をする必要が出てきたため、チーム全体の認知負荷は高くなってしまった

などが発生していました。

これらの課題感の解消のために、チーム/プロダクト構成の調整と、それに伴う人的リソースの追加を行ってきました。

③プロダクト開発チーム（現在）

現在のチーム構成やフローなどは下記となります。

現在のチーム構成（横軸がプロジェクト、縦軸はファンクション）

まず、前述した

プロダクト全体の機能数が増えていくなかで、小チーム全てが全機能の理解をする必要が出てきたため、チーム全体の認知負荷は高くなってしまった

という課題感を解くために、プロダクト全体の粒度を分けていくことを目指しました。

プロダクト全体の機能群を見直した結果、LeadGridにおいては、

1.コンテンツ管理やページ管理などのサイト運営のための機能群
2.リードの獲得や獲得したリードの適切な管理のための機能群

の2つにグループ分けをし、前者を「CMS」、後者を「Lead」と呼称するようにしたうえで、それぞれの機能群を担当する「プロジェクト」という粒度をチーム内に導入しました。
（参考：画像「現在のチーム構成」の横軸のグルーピング）

それぞれのプロジェクトにおいて、「ディスカバリー」「デリバリー」「QA・CS」チームから職種ごとにメンバーがアサインされており、それぞれのプロジェクトがそれぞれ開発プロセスを実行するようになっています。

これらが実行できるように、

・管理画面UIの変更（機能群ごとにタブ分けを実施）
・コードベースの設計変更（モジュラモノリス構成にし、影響範囲の分離化を実施）
・KPI測定範囲の変更（プロジェクトごとに各種KPIが管理できるように調整）

なども並行して行うことで、それぞれのメンバーが意識すべき領域が明確になり、その領域においてのドメイン知識が深ぼれるようになったと感じています。

同時に、

まだまだ顧客課題の解像度が必要なフェーズにおいて、「UI・UXチーム」と「システム・アプリケーションチーム」という分け方をしてしまったため、ドメイン知識や顧客解像度がシステムアプリケーションチームに溜まりづらい状態を引き起こしてしまった

という観点に関しても、フロントエンド/バックエンドという枠組みは一旦廃止し、プロダクトエンジニアとしたうえで、機能単位でアサインされるようになったことで、改善傾向にあると感じています（もちろんエンジニアによって、フロント/バックに対して得意不得意はあるため、そこのカバーなどはデリバリーチームという粒度でカバーしあっています）。

また、エンジニア以外の職種のメンバーが増加したことにより、職種定義や開発全体のフローも調整を行いました。

職種ごとの責務定義

現在の開発全体フロー

それぞれの職種が背中を合わせながらミッション達成を目指せるよう、職種ごとに求められる責務を言語化したうえで、全体フローは分かりやすいように、フェーズを「ディスカバリー」と「デリバリー」の2つにまとめました。

現在の課題と今後の展望

現在も、商品企画チーム（≒LeadGridプロダクト開発チーム）では、「より良いものをより早くユーザーに届ける」ことを達成するために、日々さまざまな取り組みと改善を行っています。

そのなかでも、現在は開発速度（消化ストーリーポイント）の増加を目指しています。

現在、商品企画チームでは、

1.タスク種別ごとの消化ストーリーポイントの可視化
・ストーリー：ユーザーに新たな価値を提供するための対応
・バグ：元々提供できていた機能が提供できなくなっており、その再提供のための対応
・リファクタ：ユーザーへの提供価値は変わらないが、将来の開発速度向上などを目的としたコードベースの変更などの対応

2.プロジェクトごとの消化ストーリーポイント
・前述したCMSとLeadごとの消化ストーリーポイントをそれぞれ可視化

をKPIとして、改善を目指しています。

タスク種別ごとの消化ストーリーポイント　※実際の数値とは異なります。

方針としては「バグの割合を減らし、その分のリソースをストーリーの消化にあてる」ことで開発速度の向上を目指しています。そのために、ユニットテストのカバレッジ率の向上や自動テストの拡充、デグレーションチェック体制の強化などを実施しています。

これらを達成することで、LeadGridをご利用中のお客さまからのさまざまな要望に対して、より早く価値提供をしたいと考えています。　　

株式会社GIGは、Web制作やマーケティング支援に強みをもつデジタルコンサルティング企業です。LeadGridを始めとしたさまざまな技術を活用し、ご要望を叶えるWebサイト・システムを実現します。Webやシステム、DX支援のご相談はいつでもご連絡ください。

また、株式会社GIGでは一緒に働くメンバーも募集中です！技術が好きなエンジニアも多く、モダンな技術に関しても常に情報交換しながら切磋琢磨しています。挑戦したいことにはどんどん挑戦できる環境なので、LeadGridの開発に少しでもご興味を持っていただいた方は、ぜひカジュアル面談でお話しましょう。

■株式会社GIG
お問い合わせはこちら
採用応募はこちら（GIG採用サイト）
採用応募はこちら（Wantedly）

福田 拓実

新卒でWEB広告代理店に入社し、アカウントプランナーとして従事。その後起業経験を経て、2019年6月に株式会社GIGにエンジニアとして入社。WorkshipやLeadGridなどのソフトフェアエンジニアを担当後、LeadGrid開発チームにおいてPdMやEMを牽引。現在は商品企画チームのマネージャーとして、主にLeadGridの企画・開発に従事。