10年選手プロダクトに、メスを入れる。その時、PMは何に気をつけたか？PR TIMES 鈴木碩子

※2021年12月14日に開催された【みんな要件定義どうしてる？共有LT【開発PM勉強会vol.7】より、株式会社PR TIMES 鈴木碩子さんのLTを書き起こし形式でお届けします。

【プロフィール】鈴木 碩子｜株式会社PR TIMES 開発本部プロダクトチームMgr
2017年4月に株式会社ismを創業後、2020年10月にPR TIMESへグループイン。2021年2月よりPdM、PMM、デザイナーと共にプロダクトチームを立ち上げています。メディアと広報の仕事に携わって8年目のPRパーソン。

10年以上続いているプロダクトの開発現場

今回、「レガシー＆機能開発を要件定義で叶えるには？」をテーマにお話させていただきます。

最初に私たちが開発しているプロダクトについてご紹介させてください。PR TIMESは10年以上運営しているサービスです。当社は「行動者発の情報が、人の心を揺さぶる時代へ」というミッションを掲げており、企業の方、メディアの方、生活者と呼ばれる個人ユーザーの方など、さまざまな方にご利用いただいています。

現在、プロダクト開発をする上で目指していることは、PR TIMESを社会的な情報インフラにすること、グローバル展開などです。

私がプロダクトマネージャーに着任したのは、今からおよそ1年前。これまで、さまざまな奮闘をしてきましたので、今回はそのなかでの学びをお伝えできればと思います。

開発チームでは、PR TIMESの他にも、PR TIMES STORY、Webクリッピング、PR TIMES
TVなど、さまざまなプロダクトの開発に取り組んでいます。比較的新しいプロダクトもあれば、リリースから10年以上経っているプロダクトもあります。フェーズも0→1、1→10、100以上とバラバラです。

一方、チームメンバーは、私も含め1年以内に入社したメンバーがほとんどの「スタートアップチーム」。イチからビルを建てるようなイメージで、プロダクト開発を進めています。

じつは、開発チームはこの1年で大きく変わりました。もともと、2021年1月まではエンジニア主体の開発組織でしたが、2月から新たな部署が立ち上がり、新しいCTOやPMMがジョインしています。まだまだ新しい開発組織なので、体制は模索中です。

この1年間で取り組んできたのは仕様、システム、デザイン、この三領域におけるメンテナンスと改修です。当社に限らず、どんなプロダクトもメンテナンスと改修を続ける必要があります。技術の発展による仕様の変化、各システムのバージョンアップ、時代に合わせた人々の認識・体験...どんどん周りの環境は刷新されているにも関わらず、手つかずのものがたくさんあります。

本来であればひとつひとつ階段を上るようにアップデートしていくことが望ましいですが、この数年を一足飛びするように開発を進めているのが現状です。具体的には、デザインのコンポーネント化、デザインシステムやJIRAの導入、スクラムの改善などに取り組んでいます。

新たなレガシーを生み出さない、息の長い要件定義を。

ここからは、私たちが実践している要件定義についてお話できればと思います。

そもそも、「新しい機能をつくろう！」となったとき、当社では開発チームで議論を進めていると、こんなことがよく発生します。

「システムの構造から変える必要があり、時間が掛かりすぎてしまう...」
「似たような機能が複数存在しているものの、仕様が少しずつ違う...」

レガシーなプロダクトの開発においては、もしかすると「あるある」なのかもしれません。

より建設的に議論を前に進めるために、PMはどんな心意気を持つといいのか。私が日々意識している3つをご紹介していきます。

一つ目は、「新たなレガシーを生み出さない、息の長い要件定義」です。とにかく重要なのは、すでにレガシーがあったとしても、新たに生み出さないために努力することです。私たちは要件定義する際、「構想」「プロジェクト」「要件定義」「Design Doc」の4つのレイヤーで検討するようにしています。

■ 構想
3～5年程度先を見据えたときに、「こんな世界観になれたらいいよね」を言語化しています。タスク内の改修については構想を置かず、プロジェクト化するようなものに関しては適宜置くようにしています。

■ プロジェクト
目的や価値・抽象の具体化・ロードマップを設定し、プロジェクト化していきます。

■ 要件定義
プロジェクトを小ゴールに分解し、ひとつひとつ要件定義していきます。

■ Design Doc
小ゴールを達成するための技術面での具体的な実現方法を言語化します。弊社ではエンジニアが要件定義やプロジェクトを見て、Design Docを作成しています。

構想がDesign Docに反映されると、技術設計まで一貫性を持たせることができ、手戻りが少なくなりました。

また、作成のポイントは「チーム内の認識を揃えることを目的する」ことです。1つの要件定義で数字達成にこだわってしまうと、作成すること自体が大変になってしまうので、チーム内の認識を揃えることを優先して言語化をしています。

夢は大きく、リリースは小さく。

2つ目のポイントは、「夢は大きく、リリースは小さく」です。やりたいことがたくさんあったとしても、それらを一度に叶えることは不可能。1つの要件定義に詰め込むのではなく、「1つの要件定義で解決することは1つにする」ことを大事にしています。

とはいえ、ユーザーに価値を感じてもらいたいがために、リリース時はどうしても機能を盛り込みたくなってしまうもの。仕組みで解決するために、開発チームが、本番環境で新機能と旧機能を自由に切り替えられるように実装してくれました。試験機能としてリリースできる状態になったことで、「お披露目時に盛り込まなきゃ...!」という意識が薄れました。どうやって実装したかについては弊社の開発ブログでもご紹介しているので、よかったらぜひ見てください。

たくさんの協力者を早めに巻き込む

最後に3つ目は、「たくさんの協力者を早めに巻き込む」ことです。

私がプロダクトマネージャーに着任するまでは、プロダクトマネージャーが存在しないエンジニア主体の開発組織でした。最初は現状の開発組織を知ること、そして関係者と関係構築をすることが重要だと考え、オフィスを練り歩き、関係者を見つけたら席の近くにいって話を聞いていました。よく話を聞きに行っていたのは、ビジネスオーナー、CR、営業、経理、エンジニアです。意識的にコミュニケーション量を増やし、協力者を増やすことができました。

とくに複雑な仕様を検討するときは、エンジニアとデザイナーと一緒にミーティングで共有しながら、デザインや処理を確認しています。明確に分からないこと、気になることがなかったとしても、一緒に確認することで、穴に気づけるので、私たちは週に一回ぐらいの頻度で実施しています。最初は制作後の手戻りやリリース後に「こうしたほうがよかった」と気づくことが多かったのですが、各メンバーと連携していくことで、少しずつ減ってきました。

こんな感じでPR TIMESでは開発をやっています。開発の仲間を探してますので、プロダクトマネージャー、デザイナー、エンジニアを全方位積極採用中です。ぜひご興味を持っていただきましたら、お気軽にお話できると嬉しいです。

（おわり）

編集 ＝ 野村愛