ビジネスサイドとの連携の改善

はじめに

株式会社クライドでTPM兼POをしている陶山大輝と申します。

この記事では、以前にDevOpsエンジニアとして牽引したプロジェクトのうち、ビジネスサイドとの連携改善について紹介します。このプロジェクトは、開発生産性の向上に向けた取り組みの一環で、特にビジネスサイドとの連携を改善することを目的としました。実施期間としては、2022年12月から2023年2月まででした。

プロジェクトの概要

チーム構成

自分達のチームは自社サービスの開発チームで、以下のようなチーム構成でした。各チームは自律的に活動し、日々のミーティングを通じて進捗をPOに共有する形で開発を進めていました。また、様々な事情から、チーム構成を変更せずに連携を改善する必要がありました。

PO
  - 1名
FEチーム1
  - マネージャー 1名 (FEチーム2と兼任)
  - リーダー 1名
  - メンバー 1名 （自分）
FFチーム2
  - マネージャー 1名 (FEチーム1と兼任)
  - リーダー 1名
  - メンバー 1名
BEチーム
  - マネージャー 1名
  - リーダー 1名
  - メンバー 2名

進め方

このプロジェクトでは、POと開発チームが隔週で約1時間のミーティングを行いました。ミーティング内の中で、POと開発チームの認識している課題を共有し、それぞれの解決策を立案しました。以下に、その過程で浮かび上がった課題とその解決策について紹介します。

解決すべき課題

「エンジニアの視点を活かしきれない仕様作成」

従来の開発の手順は以下の通りでした。

1. ビジネスサイドから要望が出され、POが優先順位を確定する。
2. POが仕様を確定し、エンジニアに開発を依頼する。
3. エンジニアが工数を算出し、開発に取り組む。

しかし、この手順には2つの主要な問題がありました。1つ目は、工数の算出前に優先順位が確定するため、工数に基づいて決まるべき優先順位が実際には工数から独立して決まるという問題です。2つ目は、エンジニアが仕様の決定の段階に関与していないため、開発工数の増加や手戻りのリスクが高まるという問題です。

これらの課題を解決するために、以下のように手順を修正しました。これにより、先に述べた問題点が解消されました。

1. ビジネスサイドから要望が出され、POがエンジニアに共有する。
2. POがエンジニアと協力して実現方法と工数を検討し、優先順位を確定する。
3. POが仕様をエンジニアと確定し、エンジニアに開発を依頼する。
4. エンジニアが開発に取り組む。

「ビジネス要件のエンジニアへの伝達不足」

従来の開発スタイルでは、エンジニアに開発を依頼するという受託開発に近い形式でした。しかし、ビジネスサイドとエンジニアサイドが分断された状況とも言え、プロダクト開発の観点からは好ましくありませんでした。

そこで、仕様書にユーザーストーリーや仮説・検証の流れなどのビジネス的な要件を含めるルールを定めました。これにより、エンジニアもビジネス要件を理解し、それに基づいた開発が可能になりました。

「進捗管理の不備による開発遅延」

開発チームではスクラム開発を採用し、スプリントプランニングやデイリーミーティング、スプリントレトロスペクティブなどを実施していました。しかし、これらのイベントでの進捗管理がプロダクトロードマップに適切に反映されず、リリースの延期やメンバーの負荷過多などの問題が発生していました。

これに対処するために、スクラムイベントの他にPOと開発チームの間で相談の場を設けました。しかし、POからの技術的な質問の場となり、課題の解決には繋がりませんでした。

そこで、リソース調整やバックログの優先順位の調整を目的として相談の場を再定義しました。これにより、ミーティングの目的が明確になり、効果的な進捗管理が可能になりました。

プロジェクトの結果

当初の予定では2023年4月に別のチームに移動する予定であり、その前に効果検証と引き継ぎを含めてプロジェクトを完了させることを目指していました。しかし、直前に予定が変更となり、2023年4月以降もプロダクト開発を改善する役割として現在のチームに残ることとなりました。

そのため、このプロジェクトの単体での成果を出すことはできませんでした。ただし、この改善によりプロダクトオーナーとの関係性を築けたことや改善する必要がある認識を共有できたことが、2023年4月以降に進めるプロダクト開発改善への大きな布石となりました。（参考：事業とプロダクト間のインターフェース作り）

まとめ

この記事で述べた解決策はチームに大きく依存し、任意のチームに適用可能でありません。また、プロジェクトの期間が短かったため、多くの解決策は妥協的なものです。ただ、従来のアプローチを見直すことで、プロダクト開発によりユーザーに価値を迅速かつ正確に提供できる可能性があることがこの記事を通して伝えられれば幸いです。