ラクスル事業部エンタープライズ開発グループの宮田です。
今回はエンタープライズ開発グループの最近のチーム運用についてご紹介したいと思います。
エンタープライズ事業は、ラクスル印刷事業の大企業向けの EC プラットフォームです。
安い・早い・ラクといったラクスルの強みを活かした上で、大企業のユースケースに合わせてデザイン管理・承認ワークフローなど、業務効率化に繋がる機能を提供しています。
近年はラクスル EC サイトの横軸展開を行い、クロスセルの増加を狙うなど、顧客価値にフォーカスした開発が多いのが特徴です。
多様な業界の顧客要望に応えるため、新機能のデリバリーにもスピードが求められるエンタープライズ開発グループですが、発足以来約 3 年間で導入企業 1300 社、事業部として過去 1 年間で 2 度の月次社長賞受賞、1 度の全社四半期社長賞受賞と、幸いなことに事業インパクトに繋がる結果を残せているのではないかと感じています。
そこで今回は、その原因についてチーム運用の視点から分析し、チームを端的に表す特徴として「悩まないチーム」という観点でご紹介したいと思います。
悩まないチーム
エンタープライズ向けプロダクトの特徴として、
- 市場投入時間を短くしたい：早く新機能をリリースしたい
- 顧客要望が多岐に渡る：業界によってペインポイントが異なる。コアとなる機能とオプションとなる機能の取捨選別が重要
という特徴が挙げられます。
開発工程は細かい意思決定の連続ですが、そのスピードを高める上でのボトルネックを以下の三段階に分け、それらとどう向き合ってきたかを考えてみたいと思います。
- 開発案件の悩み
- 機能要件の悩み
- コード品質の悩み
1. 開発案件の悩み - What
一つ目は、多岐に渡る顧客要望を踏まえた上で、何を開発するかという悩みです。
当チームではラクスル社内の他のチームと同様、スクラム開発の開発サイクルに従っていますが、特筆すべき点として Product Backlog の管理と、スプリントゴール の設定についてご紹介します。
Product Backlog の管理
開発アイテムは、プロダクトオーナーである PdM による要件定義があり、それをまとめた Minispec というドキュメントを元に、エンジニア側との相談を経て決定されます。エンジニア側もこの段階から議論に加わるため、やること・やらないことの決定に関わることで、開発をする上での納得感が醸成されます。
エンジニア側の指摘を PdM が持ち帰ってセールスメンバーに顧客側の意向について確認する場合もしばしばあり、プロダクト作りに参加していると感じられる瞬間です。
開発アイテム間の優先順位付けは、Product Backlog により管理され、以下の観点を考慮して行われます。
- 開発のリターン（ROI）
- いくつの顧客の導入に繋がる見込みか（ブロッカー数）
- 開発メンバーのリソース
- フィーチャー間の依存関係
また、後ほどご紹介しますが、エンジニア側の開発オーナー（Function Owner）のアサインもこのタイミングで行います。
スプリントゴールの設定
週次のスプリントではバックログを元に、スプリントゴールと呼ばれる達成目標を決定し、その実現に向けて行動します。開発オーナーは、開発そのものを進めつつ、実現に向けたリソースの調整など、PdM に近い視点でデリバリーに向けて動きます。
毎週デリバリーできた価値を確認できる点は、エンジニアとしてモチベーション向上に繋がる実感があります。また、高頻度のリリースは顧客からのフィードバックを受けやすい点もメリットです。
また、開発体制の健全性のモニタリングをベロシティの数値ではなく、ゴールの達成・未達成にフォーカスしているのも特徴です。未達成の場合にその原因を振り返ることで、単純にベロシティ低下の原因を探すよりも、よりメンバーの行動をベースとした振り返りを行うことができ、ロジカルで再現性のある教訓を得ることができると感じています。
2. 機能要件の悩み - How
開発アイテムの Minispec が作成された段階で、やること・やらないことは整理されていますが、実際に開発を進める上では、ローンチカスタマーの顧客を対象に考えて、さらに不要な要件を削ることもあります。
その理由は、前述の通りエンタープライズ向け開発ではリリース時期を意識して開発をすることが多いことから、初期リリース時点でのミニマムな要件を常に意識する必要があるからです。機能要件を巡る、こうした会話を通じて、機能要件が洗練されていき、結果として顧客にとってコアな価値となる機能に集中できるといったメリットがあります。ソフトウェア設計では YAGNI の原則を意識すること、すなわち必要になったタイミングで実装をすることが重要だと言われますが、機能要件定義の段階でこうした原則に基づいた行動ができていると感じています。
また、不要な要件を削るためには顧客理解を深め、機能要望の背景を理解することが前提ですが、週次のビジネス・プロダクトの定例ミーティングで、セールス・Ops・事業開発といった顧客の一次情報に近いメンバーからインプットを得られている点も、そうした顧客の理解の深掘りに繋がっています。
3. コード品質の悩み - Why & Why not
要件を実装に落とし込む上で、実装案の選択、なぜこう実装するのか、なぜこう実装しないのかの取捨選択を行う際の悩みです。具体的には、新規開発のドメインモデル設計や、アーキテクチャの決定、将来の拡張性の担保と YAGNI 原則のトレードオフなどです。こういった悩みには Development Policy を設定することで対応しています。
市場投入までの時間を早めるのが重要なエンタープライズ向け開発では、リリース速度が重要ですが、そのためにはプロダクトのアジリティを高めることが重要だとされています。
アジリティとは、ソフトウェアの変更に対する対応能力を指し、具合的には
- 可読性
- 変更容易性
- テスト容易性
といったコード品質が関わっています。
コード品質には複数の観点がありますが、開発スピードの向上の点で特に重視しているのは認知負荷を下げ、実装速度とレビュー速度を上げることです。
Development Policy
そこで、Development Policy という開発方針の取り決めを作り、迷わないように努めています。
また、日頃からレビュー時に感じた実装の違和感は積極的に言語化し、メンバー間で方針のすり合わせを行うようにしています。場合によってはそれが新たな Policy としてメンテナンスされることもあります。
一般的にエンジニアに求められる観点はコード品質に関する点だと思いますが、当チームでは開発案件や、機能要件の詳細を詰める点でもエンジニアが積極的に関わっており、それが大きな特徴です。
チームを支える取り組み
この節では、チームメンバーの関わり方を通じて、前節でお話しした三つの悩みを解決し、開発スピードを上げるための取り組みをご紹介します。
1. Function Owner (FO) - 自律的な小チーム
まずご紹介するのが Function Owner (FO) 制です。
前述の通り、プロダクトロードマップからブレイクダウンした開発アイテムは、PdM と開発メンバー間で管理されています。
開発アイテムにはそれぞれ 1-3 名程度の Function Owner と呼ばれる開発オーナーがアサインされ、機能要件の決定から実装・レビューを経てリリースまでを担当します。ここでのファクション (Function) とはアジャイルにおけるエピック (Epic) に近い概念です。
開発に際してビジネスメンバーや、他のチームとの相談や調整ごとは全て FO が担当します。これにより、チームの対外的な窓口を多く取ることができ、 Engineering Manager や Tech Lead といったリーダー陣に調整タスクが集中するのが避けられます。
他のチームとの調整が属人的になることは、チームの単一障害点の増加にも繋がるため、そうした事態を避ける FO 制は、チームの柔軟性を高めていると言えます。
もちろん、チームの窓口となるためには他のメンバーから信頼感があることが必要です。その点に関しては、FO を担当することで、その開発アイテムについてチーム内で最も熟知している状態になるのがポイントと言えそうです。
ジョインしてから日が浅いメンバーも、FO を担当した機能のドメインでは自分が一番詳しく、他のメンバーから頼られる存在となっています。
このように、FO を担当することで個人がオーナーシップを持つようになり、周囲のメンバーからの信頼感が醸成され、よりチームにフィットするという効果があります。そういった意味で FO 制はチームの柔軟性を高め、相互の信頼感の醸成に寄与していると言えそうです。
また、FO はメンバー個人のモチベーション向上にも繋がっていると感じています。
一般的に、モチベーション高く業務に当たる上では内発的動機付けが重要だと言われ、その要素として「自律」「熟練」「目的」が挙げられます。*1
FO は自律的に行動し、プロジェクト内の特定の開発エリアに熟練し、リリースという目的に向かって行動するという点で、この動機付けとうまく結びついていそうです。
FO と似た事例として、 DRI (Directly Responsible Individual) が挙げられます。DRI は開発に限らず、プロジェクトについて完全な決定権をもつ個人で、その完遂に向けて周囲の人を巻き込みながら進めていくロールです。
ただ DRI は完全に決定権を持ち、その決定に他のメンバーは従うのに対し、FO はチームに関わる議題（開発上のポリシー、運用ルール）については合意を取るという点が異なっています。
Directly Responsible Individuals (DRI)
2. Slack, Notion, Discord - コミュニケーションパスの整理
開発案件・機能案件についての項で言及したように、当チームでは開発メンバー同士はもちろん、セールス・Ops・事業開発といったメンバーとも密に連携する機会が多いです。
開発メンバー同士の設計や実装に関する議論や、Ops から開発側への問い合わせ・調査・運用タスクの依頼、顧客要望があった機能についてのセールスへの確認など、その内容も多岐に渡ります。そのため、コミュニケーションが全て同じプラットフォームで行われ、エンジニア全員がそれらの情報に触れる状態が続けば、混乱の元になると考えられます。
ツールの使い分け
そこで、チーム内では適切なメンバーが、適切なタイミングでコミュニケーションするためのインターフェースが整備されています。
具体的には Slack, Notion, Discord といったお馴染みのコミュニケーションツールですが、目的に応じて細かく使い分けているのが特徴です。
通常の Slack によるやり取りはもちろんですが、より開発メンバー同士のペアレビューやモブレビューなど、より同期的に作業を進めたい場合は Discord や Huddle によるリアルタイムの会話を随時行います。このときはサーバーサイド・フロントエンドや FO 単位で分かれて作業をすることが多く、必要なメンバーのみが作業に参加するようになっています。
また、新規開発の実装案の共有は Notion に Developer Note と呼ばれる頭出し用のノートを用意し、それらを同期的・非同期的に参照しながら行っています。 いわゆる Design Doc に似ていますが、試行錯誤の段階から書き始め、議論を元にブラッシュアップされるのが特徴です。
問い合わせ窓口の整備
また、開発側への調査・問い合わせは Slack Workflow を用い、内容のサマリー・期日・アサインが行えるようになっています。こうした窓口を通じて担当者が速やかに決まることで、緊急性の高い調査でも初動が早いことがメリットです。また、担当者が決まることで調査等で割り込みタスクが発生した際にも、通常の開発案件がストップすることを防ぐことができます。
他チームとの MTG でも、全員が出席するのではなく前述の FO がチームの窓口として出席し、議事や決定事項は後ほどチームに共有、という場合が多く、他のメンバーの作業を妨げないようになっています。
不必要なコミュニケーションパスを減らすためのこうした取り組みは、各自の開発時間の確保と、チームのリソースの冗長化に繋がっていると感じています。
3. 向き合う日 - コード品質に向き合う時間
開発工程が進むにつれ、速度のために品質をおざなりにした箇所や、今の Development Policy で判断すると適切でない記述の箇所がプロジェクト内に蓄積されてきます。
そういった問題に向き合うため、月に一度「向き合う日」と称して、コードのリファクタやデプロイメントラインの改善、ドキュメント整備などを行なっています。コード品質を向上させ、システムのアジリティを高める時間として有益です。
取り組むタスクについては通常のバックログとは別のリストで管理されています。通常の開発で、短期的に改善することにそこまでメリットが感じられないが（リリース期日を守ることとのトレードオフで見劣りする場合など）、長期的には改善したい点が見つかったときに、一旦問題をフリーズさせ、後で対応するために追加されます。
「後回しにする」という選択肢は一般的にネガティブな印象が付きまといますが、向き合う日を確保することで、判断の保留を正当化できるため、思わぬ問題が発覚したときにも開発スピードを落とさず進めることができます。そのため、この「後回しにする」という判断ができることは一種のメリットだと感じています。
最後に
開発スピードを確保するためのチーム運用の取り組みについてご紹介しました。
最後に、今後の展望として事業部内での位置付けと他のチームとの関わり方についてお伝えしたいと思います。
繰り返しになりますが、我々が提供する EC サイトは印刷商品のみならず、ポスティング、DM、ノベルティなどラクスルの提供する様々なサービスに拡張しています。そのため、他のサービスのチームとも関わる機会が多く、エンタープライズ側の都合で必要な機能に関しては、エンタープライズ側で実装することも多いです。
そのため、多くのチームのコードベースを触る機会が増えてきており、今後、それらのコードの運用タスクが増加する可能性があります。これまでは、同じ印刷 EC サイトであり、EC サイトの注文フローのメンタルモデルが共通であることからドメイン理解が比較的容易で、また、アプリケーションの FW も社内でスタンダードである Ruby on Rails であることからメンテナンス負荷も小さい状態でした。ですが今後、サービス拡張が増えるにつれ、多くのコードベースの変更を監視する必要が生じるなど、運用面での負荷を小さくする必要があると感じています。
これからも開発スピードを落とさず、ユーザーに価値を提供してくためには、全てのコードベースの管理を自分たちで抱え込まず、連携先のチームに適切に委譲するのが重要なのではないかと個人的には感じており、今後ますます他チームとの連携が重要になりそうです。
そうした局面での運用についてもいずれお伝えできればと思っています。
最後までお読みいただきありがとうございました。
*1:「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳) より
