こんにちは、PR TIMES サービス開発本部の責任者を務める大谷と申します。

今日、私たちPR TIMESは新たなサービス「PR TIMES STORY」を公開させていただきました。詳細についてはプレスリリースをご一読いただくとして、本稿ではなぜストーリーが必要なのか、そしてそれを開発者がどうして語る必要があるのか、私たちPR TIMES開発チームが辿った道のりをふまえ、その狙いについて記したいと思います。

新サービス「PR TIMES STORY」のトップページ

ストーリーが必要な理由

企業が社会とコミュニケーションする手法に「広報活動」というものがあります。特にメディアを対象に企業活動を伝える「プレス（向け）リリース」はご存知の通り、広報活動における重要なアクティビティのひとつになっています。

一方、このプレスリリースは”何をしたか”のwhatが主となることが多数です。製品を生み出す苦労話や、そこに賭ける社運があったとしても、発表される情報は「製品ができた」事実に終始して、その背景や意図を伝える情報が不足する、勿体ないケースもよく目にします。

情報が溢れる現代において、真意が伝わらないことのデメリットは日々大きくなっています。

このことに気がつき始めた企業は、プレスリリースの表現をリッチにし、”なぜそれをしたのか”、”どうやって成し遂げたか”のwhyやhowを散りばめるようになってきました。さらに手軽に情報発信できるプラットフォームを活用し、一次情報を企業や個人が自ら発信するという「文化」も浸透しはじめている状況です。

「行動者発の情報が、人の心を揺さぶる時代へ」。

私たちのミッションを振り返った時、企業がステークホルダーと関係構築するための「whyやhow」をわかりやすく発信できる場所を新たに創り、企業のPRに貢献することは必然なのだと考えるようになったのです。

3.8万社(※)にご利用いただくプラットフォームでの急ピッチ開発

プレスリリースとストーリーは表裏一体である。ーーそう考えるようになった私たちは、この価値の提供をどう実現すべきか、議論を重ねました。

「なるべく早くストーリーが語られる場を作り出し、一つでも多くのストーリーが世の中に出ることを実現したい」と、私たちはこの開発を急ピッチで進める意思決定をします。

出てきた時間はおよそ半年。確かにPR TIMESは2007年からサービスを開始しており、これまでにも様々な開発・改善を積み上げてきています。一方で、3.8万社という多くの方々に利用いただいているプラットフォームなので、品質を落とすわけにはいきません。

結果、必要最小限の価値提供を前提に考え、2019年12月に着手し、予定通り約5カ月という短期間で仕上げることになりました。

当初に作成したPR TIMES STORYのデザイン

また時を経て、社会は新型コロナウィルスによる混乱で、経済も厳しい局面に立たされている状況です。情報が混迷している今だからこそ、社会は正しい情報を必要としている。ということも私たちを後押ししました。

私たちが開発スピードを優先する中で意識した意思決定は次のようなものです。

※2020年4月時点の利用社数

①ストーリー（コンテンツ）をサービスの主体とすること

1つ目に「行動者の情報価値を高める社会の公器」として、行動を起こした当事者のストーリーそれぞれがサービスの主体となるよう開発することを大事にしました。

具体的には、

（１）エディタは使いやすく、また豊富なビジュアルを表現できるように

（２）フロントはシンプルに（バックグラウンドは白ベースで、1つ1つのストーリーにフォーカスが当たるように）する

という2点が挙げられます。

特にエディタは、技術的にも難しい問題をクリアしなければなりませんでした。PR TIMESのプレスリリース配信機能は、長年継ぎ足し継ぎ足しで機能をリッチ化させてきたので、技術は古いものの、ユーザーの方々ができることは非常に幅広くなった状態になっています。

私たちはPR TIMES STORYでも、現在のプレスリリースのエディタと同水準（数年で作り上げた高い水準の）まで近づけたものを用意しなければならないと考えました。また今後、スピーディーに追加の機能開発をしていくためには、技術的なアップデートも必要でした。

そのため、「現在のユーザービリティを損ねないような幅広い機能を担保」しながら「技術的にもアップデートすること」を「4-5ヵ月」で実現しなければならない、というチャレンジに開発チームにとして挑んだのです。

なぜ私たちが、このような様々なハードルがある中でも、品質の高いエディタを実現しようとしたかというと、「外側の箱（WEBサイト自体）はなるべくシンプルに、ただしお客様が作るコンテンツはできる限りリッチにできるようにする」というPR TIMESのデザインへのこだわりが挙げられます。

このこだわりの背景には、プレスリリース配信サービスを運営する中で、PR TIMESで配信されるプレスリリースをお客様自身がこれまで変えてきてくださったという経験があります。

PR TIMESを開始した当初に掲載されていたプレスリリースと近年のプレスリリースを見比べると、文章の語り口や画像・動画などのビジュアル、配信していただく内容など、非常にバリエーションに富むものに大きく変容してきました。

運営者の私たち自身が「あっ」と驚き、こんなプレスリリースがあるんだ、こんな表現方法があるのか、と思わずPR TIMES社内でもシェアしてしまうようなプレスリリースも少なくありません。

このような変化は、私たちがもたらしたものでなく、PR TIMESをご利用いただいているお客様の創意工夫によって徐々にもたらされたものでした。

そのような経験から私たちは、「自分たちで見通せる範囲の将来的なサービスの在り方や、活用方法は限られており、お客様が表現したいものを最大限引き出せるようなサービスを作ることが、私たちにとって何よりも大事なのだ」と感じるようになりました。

そのため、今回のPR TIMES STORYにおいてもお客様が表現したいものを最大限引き出すことを目的に、短い時間の中で最大限エディタの機能を実装するという意思決定をしました。

これが、私たちが今回エディタにこだわった理由です。もちろん、まだまだ改善の余地が存分にあると思っています。ぜひ、今後のアップデートにもご期待いただけると嬉しいです。

左：2007年配信のプレスリリース

右：2020年配信のプレスリリース

▼

いずれもPR TIMES上で配信されたものだが、文章量や画像の数、動画の有無など、内容・ビジュアルともに大きく変化してきた。

②サービスの継続的な改善ができる環境づくり

また2点目は、今後も継続的に機能改善をできるようにする環境づくりが挙げられます。

そのために、

　(1)認証基盤サービスのスクラッチ開発

　(2)マイクロサービス化

の2点を実施しました。

PR TIMESは歴史があるサービスであるゆえに、古くなってしまった技術・コードなどの技術的負債が多く存在しています。そのため、表からはPR TIMESとSTORYはシームレスに使えるように見えますが、実はSTORYはPR TIMES本体とは別管理のものとして作っています。別管理にするために認証基盤サービスも新たに作りました。

また、これまでPR TIMESはモノリス（サービスを１つの大きな塊として提供すること）で開発してきましたが、STORYからはマイクロサービス化（独立した小さなサービスの集合体）に舵を切っています。

一見ユーザーの皆様からはたった1つの機能が追加されたように見えるかと思いますが、実は裏側では2つの新しいサービスを作っていたのです。

短期間での開発スケジュールに対して大きな方針変更なので、チーム全体にはどうしても経験が不足してしまいます。ローンチの1ヵ月前に250のBUGに対処するなど、なかなかのハードシングスであったのは確かですが、それぞれのメンバーが一つひとつ丁寧に解決していくことでこのハードルをクリアしました。

私たちがなぜこのような、一見面倒で大変そうなことに踏み切ったかというと、ここまで私たちの良い面ばかりお話してきましたが、実はPR TIMESの開発チームではこれまで「〇〇機能を作りたいが、技術的負債の関係ですぐには着手できない」ということが数多くありました。

お客様のために、メディアの方、生活者の方のためにこのような機能改善をしたい、新しいサービスを作りたいという思いを抱えながらも、過去の技術的負債によってそれが実現できない。また、多くの方にご利用いただいているサービスを運営している以上、日々の保守運用も行わなくてはならない…と、とても歯がゆい思いをしていました。

今回のマイクロサービス化は、そのようなこれまでの反省を踏まえて、今後継続的な改善が実施できる環境を整えるために進めたものでした。

この取り組みは、何か外から目に見えるサービスになるわけでもなく、派手さも無いものなので、限られたリソースでこの作業に着手することは、なかなか理解されづらいことだったと思います。

しかし、今回の認証基盤サービスの開発により、PR TIMESとしてマイクロサービス化の実現への第一歩を踏み出すことができました。今回作った基盤の上に開発を重ねていくことで、今後はさらに高品質でスピーディな機能改善ができるような環境を整えることができました。

ストーリー開発チームの会議の様子

プロダクトの開発秘話はなぜ必要なのか

では最後に開発者が直接、製品の裏側を語る理由とポイントについて少し書いてみたいと思います。

開発されている方であれば理解いただけると思いますが、全ての工程には「理由」があります。ボタンひとつ、パッケージのフォントひとつでもそうです。この微妙な差を当事者として語ることのできる最前線にいるのが「開発者」であると考えています。

確かにテクニックの情報は随分と増えました。

技術要素（〜技術を使った、〜言語で実装したetc）、業務上の経験（障害対応、組織ビルディングetc）、リリースノート（〜がリリースされましたなどwhatに絞った説明etc）など、サービスの一部を切り取ったドキュメントはすでに豊富に存在しているからです。

一方、ステークホルダーに向けた、共感を生み出すメッセージはあまり多くありません。

どのような意思決定をし、どのような苦難を乗り越え、この価値を提供するに至ったのか。これからどのようなサービス改善を重ねていきたいのか。モノが溢れる今、なぜそれを使わなければならないのか。人々はサービスにビジョンを強く求めていると感じています。

もう一つが成長です。SaaSに代表されるように、製品は顧客と共に成長することが理想です。

製品においてのナラティブは顧客に選ばれる大きな一手となるはずで、「〜をリリースしました」、というファクトに終始せず、「〜という背景から〜を作り、これからは〜のような価値を提供できるように～のような改善をしていきます」、と製品開発者が発信することがそれを顧客と共に成長することを支えるのではないかと考えています。

私たちも急ピッチな開発の裏側で、顧客のみなさんと一緒にこのSTORYを良くしていきたい、そういう願いがありました。前述した通り、大変はハードではありましたが開発スタイルを変えてまで臨んだのはそのような意図がありました。

製品を担当する開発者が最前線を可視化して世に届ける。これこそが、「開発ストーリー」を書く意味だと私たちは考えています。

PR TIMES サービス開発本部　大谷 真史　長門いずみ