レガシー環境があるプロダクトの要件定義で意識することは？　「なるほどな」で終わらせない、PMの3つの心構え

自己紹介

鈴木碩子氏（以下、鈴木）：PR TIMESの鈴木です。よろしくお願いします。私からは「レガシー＆機能開発を要件定義で叶えるには？」という、ちょっと大きめな題材にしました。「PR TIMES」は、10年以上運営しているサービスです。さらに他にもプロダクトがたくさんあり、「こういった時に機能開発をしたいんだけど、今はちょっと難しいかも」みたいな課題が出てきたりします。

私が着任してからもうすぐ1年経ちますが、そういう時にどうやって乗り越えていくとよさそうかという、さまざまな奮闘の結果を、今日お伝えできれば勇気になるかなと思って持ってきました。

簡単に私の紹介です。もともとPR TIMESでプロダクト本部の本部長をしていて、今は開発本部と統合したので、プロダクトチームの責任者をしています。（スライドを指して）略歴はこんな感じです。

私はもともとメディアや広報PRというところをやってました。（株式会社ismという会社を創業し）2年前ぐらいには、「PR TIMES MAGAZINE」の開発と企画を発起人として全部立ち上げることもしていました。、まるっとメディアもしながらメディアも作っちゃうようなこともしていました。あとはSEOやコンテンツマーケティング、あとはブランディング、企画みたいなところをけっこう得意としていました。2020年にPR TIMESにグループインをして、プロダクトの開発をしています。「BRIDGE」というスタートアップのメディアで書かせてもらったりしています。旦那さんはデザイナーです。一応、お母さんをしています。

PR TIMESのプロダクトとミッション

まずPR TIMESのプロダクト開発チームで携わっているのが、「PR TIMES」、「PR TIMES STORY」、「Webクリッピング」。その他「PR TIMES TV」というサービスや新しいプロジェクトを実施しています。

「PR TIMES」は企業の方、メディアの方、生活者と呼ばれる個人ユーザーの方など、いろいろな属性の方にご利用いただいているサービスになっています。

PR TIMESは「行動者発の情報が、人の心を揺さぶる時代へ」をミッションに掲げています。私たちがプロダクト開発において、「こういうミッションを掲げてやっています」ということを、簡単に説明させていただきたいです。

今目指しているところでいうと、「PR TIMES」を社会的な情報インフラにするということ。グローバル展開や、「PR TIMES」を超えるサービスを作れる人材が台頭していくことを、組織全体で目指しています。

PR TIMESのプロダクトチームの状況

こんなことをガッと話してきましたが、ではプロダクトチームが今どういう状況かというと、（スライドを指して）プロダクトが城みたいに、10年以上運営されてきていますと。比較的新しいものもあれば、10年選手のものもあります。フェーズも0→1、1→10、100以上のインフラを目指すというのもあります。

一方で、開発チームに関しては、軸は新しく、私を含めて2021年に入ってきたメンバーと新卒のメンバーとのスタートアップチームで、ビルを建てているような感じでイチから作っている経緯があります。そのため、プロダクトに対して、開発チームが今がんばっているようなところです。

経緯から言いますと、2021年1月のプロダクト開発は、実はサービス開発本部というエンジニア主体の開発体制でした。そこに対して、2月に新たにプロダクト本部というものが誕生して、4月にCTOが入って、PMMみたいなポジションが増えて、今はPdM、デザイナー、PMMがプロダクトのチームにいます。開発本部とプロダクトの統合をして開発組織みたいなかたちになっています。

やはり大きなサービスで（ありながらも）人数でいうとまぁまぁ少なかったり、開発フローを整える必要があったり、コンポーネントなどがない状態だったりしたので、デザインコンポーネントを整理したり、デザインシステムみたいに対応してきました。

当社に限らずどんなプロダクトでも、メンテナンスと改修を続けないとどんどんレガシーがたまってしまいます。例えば“仕様のレガシー”とよく言っているのですが、技術の発展による仕様の変化だったり、あとはシステムのバージョンアップ。これについては当社でいうと、PHPのバージョンアップをがんばっていたりします。

デザインに関しても、今まで当たり前だったUIや体験がどんどん刷新されていくので、そういったところにも階段を上るようにどんどんアップしていかないと、一気に一っ飛びに進めさせることが必要になってしまいます。

今、数年一っ飛びさせているのが現在の状況です。そのために武器が必要なので、デザインのコンポーネント化・デザインシステムの導入。Jiraを導入したり、スクラムを改善したり、あとはQAを自動化して指摘の進行をしています。

レガシーと要件定義の付き合い方

チームの状況ですが、今日せっかく時間をもらったので、要件定義をどのようにしていったらいいのかを考えてみます。この状況で要件定義をがんばるとクリアできると思えるものがあるのかわかりませんが。まず「この機能を作りたい」「こういうのがいいと思います」という時に、まず機能追加できるかを調査に行くような状況になります。

今はけっこうドキュメンテーションがない状態、事業のグロースを（とにかく）目指して機能開発してきたので、まず調査をして、ソースコードを読んでいけるかを確認します。「調査タスクをスプリントに入れて、がんばればいけそう」みたいな感じだと（回答を）もらいました。

「どれぐらいでいけますか？」みたいなコミュニケーションをすると、「変えるなら1回テーブル構造を変えないといけないのと、システムはちょっと古いから、全部で1年くらいかかるね」みたいになる。

そうすると「この機能を作りたいです」というフェーズからはけっこう離れてくるんですよね。「なるほど」というスタンプを押すんですけど。要件定義はそもそもそういう状況をわかって、少し工夫すると「なるほど」で終わらずに済むと思っていたりします。

もう1個が「この機能を作りたいです！」ということがまた同じように始まって、「でもここは他にも同じ仕様があるよね。ここだけ変えたらズレちゃうかも」みたいなのがあって。そうすると、次に他の人が「ちなみにあれもこれもそれも似てるけど、よく見たら全部ちょっとずつ違うかも」みたいなのがあって、「確かに！　考え方から始める？」みたいなこともけっこうあります。

例えば、当社だとログインステータスで、1人の人がいろいろなユーザーとしてお使いになったりするので、よく議論されますと。こういったものに関しても、意思決定や要件定義を工夫をすることで、建設的にプランに移せることはできるんじゃないかなといつも意識しています。これは実際に当社でもよく起こる話です。

レガシーとともに生きるPMの心意気

そんな時に、PMの心意気はどうしたらいいのかを3つ挙げました。1個目が新たなレガシーを生み出さない、息の長い要件定義。とにかくレガシーがあっても“生み出さない”ことをがんばる感じです。2個目はできなくても夢は大きくしておいて、リリースを小さくすることを意識しています。

3個目がたくさんの協力者を早めに巻き込むことで、今の自分のチームが持っていない情報や、まとまっていない情報をインプットできるので、とにかくタレこむことをよくやっています。

新たなレガシーを生み出さないための要件定義

1個目の「新たなレガシーを生み出さないための要件定義」で意識していることです。構想という単位のものがあるとすごく遠いけれど、なんとなく雰囲気がわかるみたいなことで。まず、ビジネスオーナーと会話をしながら、世界観や構想みたいなものを練ります。これは3〜5年程度先なので、基本的には数値というものよりも、「こういう世界観になったらいいよね」みたいなものを言語化して、置いておけるものは置いておきます。

もちろんタスク毎の改修もあるので全部は置いておくことにはなりませんが、プロジェクト化するものに関しては置いています。それ以下に、目的や価値・抽象の具体化、ロードマップをするためのプロジェクトの構想を何分割かにして、プロジェクト化していきます。それを1、2、3みたいなかたちで、（ひとつずつ）解消にしていくかを決めます。

開発速度にもよりますが、1年をマックスくらいとして組みます。そのあとに、そのためにやる小ゴールとして、1つのプロジェクトの中から分解して、要件定義を1個ずつ、1を解決する、2を解決する、3を解決する、と進めます。そして、プロジェクト1が解決できるかたちにします。

最後のDesign Docはエンジニアが作ってくれますが、要件定義とプロジェクトを見て、だいたい適当な単位でDesign Docを書いてくれるようなかたちになります。

Design DocなどはNotionを使っています。やはり開発している人もいろいろとあるので、Notionの言語化みたいなものを少しずつ溜めていくことで、構想がDesign Docに反映できる。そうすることで、設計まで一貫性が持てるので、手戻りが少なくなった印象がありました。

あとは、1つの要件定義で数字達成にすごくこだわってしまうと作るのがすごく苦しくなってしまうので、頭の認識をチーム内で合わせることが優先で、とにかく書く、というようなことをしています。

夢は大きく・リリースは小さく

2個目は夢は大きく・リリースは小さくということで。やりたいことが多い派のPMで、いろいろなことをしたいんです。ただ、それをやろうとオーバーに入れてしまうとスプリントが回り切らないので、1つの要件定義で解決することはなるべく1つにすることを意識しています。

これは開発チームに本当に大感謝という案件ですが、本番環境で新機能と旧機能を自由に切り替えられるように開発チームがしてくれて。そのおかげで「出すならここまで出ていないとユーザーさんに価値を提供できない」みたいな気持ちにならず、本番には出しつつも、試験機能として運営して、みんなで確認できるようになって。段階で出せる意思が、けっこう強化されたと感じています。

どうやってやったかは開発ブログに書いてあるので、よかったら見てください。

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

あとは常にたくさんの協力者を早めに巻き込むということで、私が着任した当初でいうと、そもそもプロダクトマネージャーがいなかったので、開発フローが今のように回っているわけではなく、違う体制でした。

当社で知っている人がたぶん全部で200人ぐらいいるんですが、（プロダクトでわからないことがあった時に）誰かしらいるのでとにかく聞くということ、あとは体感値。電話を受けている人の体感値みたいなことをちょっと横にいって聞いてみたり、デザインをパッと見せたりして、何も説明していなかったりということを大事にしてやっていました。「ふむふむ」となって持って帰るということです。

もちろん定量も大事ですが、定量と定性みたいなところを両方できるといいなと思って、意識的にやっています。デザイナーに関してはどちらかというと一緒に相談して解決していくことが多く、ビジネスオーナーだったり、CR・営業・経理・エンジニアみたいなところに「ねぇねぇ、どう思いますか？」みたいに話をして聞いています。

あとは、複雑な仕様をやらなきゃいけない時がけっこうあります。（スライドを指して）今日のミーティングのスクショを貼りましたが、エンジニアとデザイナーのメンバーとで、デザインをなめながら処理を確認するようなことをけっこうしています。

わからないことが別になくても「大丈夫？　わからなくなってない？」みたいなことを確認しながら（やることで）穴に気づけるので、1週間に1回ぐらいやることをおすすめしています。

けっこう作り込んでからの手戻りだったり、「ここを変えたほうがよかったね」みたいなところが、少しずつ減ってきたのではないかと思います。あとは大きめのリリースに対応していけるようになったかなと思っています。