PR TIMESでCTOをやっている金子 (@catatsuy) です。
昨年は私がCTOとして入社してから半年ほどで、まず戦える組織にすること、その基盤を作ることが中心でした。
この時はまだ新機能リリースが少なく、本当に戦える組織になり、基盤ができてきたのかが社外からは分からなかったと思います。今年はその疑問を払拭できた年になったのではないかと思っています。
年始から企業ページのプレスキット機能／サムネイル画像の高画質化／個人ユーザー・フォロワー統合／いいねボタンなどがリリースされました。開発者ブログでも発信をしているので一部紹介します。
これらのリリースにより、PR TIMESで機能追加・改善が行えることが明確に示されました。
機能追加も進めつつ、そもそも機能が変更できるようにバックエンドはPHPのバージョンアップ・ミドルウェアのバージョンアップ・コードのリファクタリングが進んでいます。フロントエンドは機能ごとにReactでフルリプレイスを行う方針で進んでいます。フロントエンドは今後のSSR利用まで見据えて、開発基盤構築やリファクタリングも進んでいます。
これらの改善が進めば新機能追加や機能改善も更に進むようになりますし、実際大きく進みました。更に様々な方に安心してお使いいただけるサービスにするためにはまだまだ道半ばですが、そのために今年進んだことを開発者ブログで公開されている記事を元に簡単に振り返ってみようと思います。
数値で見る変化
Findy Team+
可視化されていた方がわかりやすいと思うので、開発者ブログでも度々紹介しているエンジニア組織のパフォーマンス向上を支援するサービスであるFindy Team+のグラフで昨年と比較してみます。Findy Team+の詳細比較の機能を使ってみます。縦軸はプルリク作成数・マージ済みプルリク数・コミット数・レビュー数がそれぞれ色分けされています。
改めて見ると同じ会社とは思えないくらいの変化です。それもあってFindyさん主催のFindy Team+ Award 2022で
- 【 Medium Div. 】（対象：エンジニア組織が50〜100人未満の企業）
- 【 グロース部門 】過去半年間で生産性指標が大きく向上した企業が対象
の2項目で受賞することができました。
このように弊社開発本部は日々進化しているので来年にも期待してもらえればと思っています。
開発者ブログ記事数
昨年の2021/4より開始したこの開発者ブログですが、この記事を含めて現在95記事が公開されています。そのうち2022年に公開されたのが59記事です。
このようにコンスタントに記事が公開されており、情報発信ができていると思っています。
来年もコンスタントに記事が公開できるようにしていきたいと思っているので、気になる記事があれば見てもらえればうれしいです。
カンファレンス登壇
数値を追っているわけではありませんが、メンバーのカンファレンス登壇も増えています。
今後もカンファレンスの登壇者に選んでもらえるメンバーを増やしていきたいと思っています。
進んだこと
今年進んだことを開発者ブログに公開されている内容を中心にいくつか紹介していきます。
AWS移行・PHPバージョンアップ
インフラとしては一番大きい変更でした。
開発者ブログの内容だけではここまで来る過程などが発信できていないので、紹介します。
データセンターではPR TIMESのデータベースの運用を社内で行うことが困難になって来ていましたし、ストレージサーバーのディスク枯渇では長時間のメンテナンス時間を入れる必要がありました。PR TIMESは社会的な情報インフラを目指しているサービスです。安定して運用が行えること、長時間のダウンタイムが発生しないこと、は会社として極めて重要です。
そのためにもAWS移行をデータベースサーバーのディスクが枯渇する前に終わらせる必要がありましたが、間に合いそうになかったため、延命措置を行いました。
しかしAWS移行はPR TIMESの場合、一筋縄ではいきませんでした。理由としてはPR TIMESの場合、アプリケーションサーバーなどの各種サーバーのセットアップスクリプトが存在せず、アプリケーションサーバーが故障などにより失われた場合、再セットアップすることができませんでした。当然AWS上に新しく構築するなどできるはずもありません。
幸い数年前に作られて、メンテナンスが放置されていたAnsibleのファイルがあったため、まずAnsibleを復活させることから始まりました。しかしAnsibleを復活させても、当然メンテナンスが放置されていた間にされた変更の設定はないので調査して取り込む必要がありますし、Ansibleを運用に乗せる必要もありました。
Ansibleを復活させるタスクと並行にPHPバージョンアッププロジェクトも進行しており、新しいPHPで動くアプリケーションサーバーを構築する必要も出てきました。社内のリソースを集中させるために、新しいPHPで構築するアプリケーションサーバー用のAnsibleを作成することに注力し、データセンターの時点で新しいPHPへの移行を済ませておき、そのAnsibleをAWSのEC2でも利用してAWS上のアプリケーションサーバーを新しいPHPのバージョンで構築することが決まりました。
これによりPHPバージョンアッププロジェクトの進捗がAWS移行の成否を握るようになりました。結果として余裕はほぼなかったですが、データベースサーバーのディスク枯渇までにAWSへの移行を完了させることができました。
データベースのPostgreSQLの移行についてはそーだいさんに相談しながら、方針を決めて進めていきました。
PHPバージョンアッププロジェクト自体はまだ第一段階が完了したところで、まだまだやることがあります。しかし大規模なリファクタリングを複数件行ったので、来年前半にはかなり進むだろうと考えています。
これらの多くの変更が進められた理由はいくつかありますが、デプロイスクリプト改善が一番大きかったと思っています。
デプロイ数の増加にも耐えられるインフラを構築することで、開発を支えることも重要なことです。これによりデプロイスクリプトにも変更を入れやすくなり、自由度が上がったこともAWS移行ができた理由の1つです。
またAWS移行したことでインフラ構成をterraformで管理することが可能になりました。このterraformはmizzyさんにCI/CDパイプラインを整備してもらったことで、非常に使いやすい環境で管理ができています。
AWS移行とは直接関係ありませんが、AWS Lambdaからデータベースに直接アクセスするシステムも稼働しており、AWSのサービスを活用して業務を効率化する取り組みも始まっています。
今後も運用しやすい柔軟なインフラを構築することで、サービスを改善していき、PR TIMESを社会的な情報インフラにしていきます。
OpenSearch移行
PR TIMESでは検索エンジンにElastic Searchを利用しています。
このElastic Searchはかなり古いバージョンを利用しており、ほぼ放置された状況で動き続けていました。
しかしPR TIMESのアクセス増加やプレスリリース数の増加に伴い、いつ動かなくなるか分からないという状況でした。そこでAWSのマネージドサービスのOpenSearchへ移行することにしました。
先程AWS移行をしたと書きましたが、先程のAWS移行で移行したのはデータベースやアプリケーションサーバーのみです。それ以外にも利用しているサーバーは複数存在しており、それぞれ別々に移行する計画でした。
移行前はRabbitMQなど、他のミドルウェアを利用していたり、なぜかここだけRubyのスクリプトで実装されていたりしましたが、仕組みの見直しを行い、シンプルな仕組みに完全リプレイスを行いました。
これにより検索機能も安定して提供できるようになりましたし、依存するミドルウェア・システムも減りました。今後の機能追加についても道筋が見えてきました。
Webクリッピングβ版
PR TIMESの管理画面上でWebクリッピングが利用できるようになりました。
開発では様々なことが起こりましたが、新機能としてユーザーの皆様に提供できることになりました。
この裏では技術的な問題を起こしていたクローラーの改善だったり、裏側の仕組みの改善も進めました。一部の試みについては開発者ブログでも発信しています。
やらなければならない改善はまだまだありますし、サービスも現在正式版リリースに向けて開発が進行中です。
またWebクリッピングβ版もフロントエンドはReactを利用しているため、Componentなどの社内リソースをどう共有するか議論をしていきました。それについては後ほど触れていきます。
企業ページ改善
PR TIMESのフロントエンドは大半がjQueryで実装されており、新機能追加が困難でした。そこで昨年2021年に社内で初めてReactにリプレイスされたのが企業ページです。その時の話は昨年の開発者ブログでも紹介しています。
そして今年の初めに新機能のプレスキットをリリースしました。そちらの話も開発者ブログで紹介しています。
プレスキット機能はその後も機能リリース・改善を続けています。
私が入社した昨年は社内でPR TIMESに新機能追加を行うことは不可能だと言われていました。しかしPR TIMESにも機能追加が行えて、かつ継続的な改善が行えることを社内外に初めて示したのが企業ページだと考えています。
またAWSのサービスを活用することで開発工数を下げることができることを社内で示したことも大きかったです。現在の開発本部の方向性を決定づけたプロジェクトでした。
SSRまで見据えたフロントエンド開発基盤構築
PR TIMESのフロントエンドのコードをReactにリプレイスしている話は先程紹介した通りです。Reactのソースコードは元々バックエンドと同じリポジトリで管理していました。これは別リポジトリで構築するとデプロイフローやインフラについて考える必要があり、当時はまだデプロイ改善やインフラの整備が途上で考えられる状況ではなかったことと、まずはReactにリプレイスをすることで開発が前に進められることを示すために最短工数で進めたかったからです。
またWebクリッピングβ版のフロントエンドもReactで構築していましたが、当初はComponentもコピペで共有を行う判断をしました。これは当時の状況ではリポジトリ構成を考えられる状況ではなかったためです。
しかしその後にサムネイル画像の高画質化でFastlyが導入され、デプロイ改善も進み、社内でできることが増えました。そこでReactのソースコードを別リポジトリに分離し、S3とFastlyを使ったインフラと別のデプロイフローを用意することにしました。
この後にWebクリッピングβ版のReactのソースコードもこのリポジトリと統合され、Componentの共有が行えるようになりました。
そしてこのリポジトリ上で使用ツールの変更やディレクトリ構成変更を伴うリファクタリングやStorybookの導入など、数多くの変更が行われるようになりました。またCI/CDの整備も進んでいます。
このようにフロントエンドの開発基盤構築を行っており、開発者ブログでもいくつか発信をしております。開発基盤の構築を行っているのは、近い将来にSSRを導入することでリプレイスを行える機能を増やす計画があるからです。
PR TIMESの状況でSSRを導入するにはフロントエンドだけでなく、バックエンドやインフラ側にも多くの変更が必要です。それらの変更も現在進行中なので、来年開発者ブログで発信できればと考えています。
またこれらの改善はフロントエンド定例などで1000chさんからアドバイスをもらいながら、メンバー内で活発に議論しながら進めています。
料金ページ改善
PR TIMESは企業ユーザーとして利用している企業の皆様から利用料金をいただいています。しかし管理画面上の料金周りの機能が足りず、ずっと不便をかけてきました。
こういったサービスの確実な改善も会社として重要視しています。そこで料金ページの改善プロジェクトを立ち上げて、機能追加・改善を進めました。
変更の1つである当日のプラン変更をできるようにしたことは先日紹介しました。
開発側では既存のレガシーコードのリファクタリングやUnit Testの充実化が重要なテーマになっていきました。そこについてはこの後紹介します。
リリース増加によるQA業務過多、Unit Testの充実
先程紹介したFindy Team+のグラフから分かる通り、今年もPull Requests作成数が増加しており、それに伴いデプロイ数も増加しています。当然それらの確認作業も増えているため、QAの業務が過多になる状況が昨年より継続しています。
その状況を打開する1つの試みとしてAutifyによるQAの自動化も行っています。
実際にリファクタリングデーなどで活用されており、事前にバグを見つけることも一部できています。リファクタリングデーについては昨年の開発者ブログで紹介しました。
またこれまでほとんどなかったUnit Testをしっかり追加していくことで、QAの確認項目を減らせないかという試みも始まりました。テストについて経験が少ないメンバーも多かったため、t-wadaさんをお呼びしてTDD研修を開催してもらいました。
これによりUnit Testの議論や、CI構築が進みました。まだまだ途上ですが、今後も様々な取り組みを行っていく予定です。開発者ブログでも随時発信できればと思います。
ECS開発環境改善
昨年PR TIMESでは開発やQAで確認するためにマルチステージング環境と社内で呼んでいる環境を構築しました。これによりステージング環境を複数作って各自で確認することが可能になりました。
この環境をECSを利用したPR TIMES STORYでも利用したいということでECSの開発環境改善が始まり、改善が進みました。
社内ではWebクリッピングβ版もECSを利用しており、現在ではPR TIMES STORYと同様の仕組みを導入してマルチステージング環境を利用できるようになっています。PR TIMES STORYの技術的な改善が他のプロジェクトの改善も促す流れができてきました。
PR TIMES STORYは初期設計の問題で新規サービスにも関わらず、開発速度が出しにくいという課題を抱えていました。しかしこの課題も改善し、PR TIMES STORYが技術や開発速度で会社の先頭を走れる体制に近づいてきていると思います。
弊社は複数のサービスを運営しているため、それぞれのサービスが行った技術的な改善をお互い参考にしながら改善を進めています。そういった情報共有のために技術共有定例を毎週水曜日に行っています。詳しくは以下の記事で紹介しています。
社内IT改善
社内IT改善を進める開発本部コーポレートチームは昨年の2021/6より始動し、1年半ほど経過しました。今年やったことはこちらの記事にまとめています。
今年はコーポレートチーム発足時からやりたいと思いつつ、やり残していたことを確実にやりきり、次のフェーズに進めたと考えています。
今年の2月にオフィス移転がありましたが、昨年の時点で社内の物理サーバーを完全廃止していたこともあり、無事完了することができました。現在のオフィスには物理サーバーは1台もなく、ネットワーク機器などが置かれているのみとなっています。
昨年はまず社内ITの土台を作ることに専念してきましたが、土台ができてきたことで、コーポレートチームのあり方も様々な部署の人達が働きやすい社内IT構築へシフトしてきています。
全従業員がセキュリティのことなどを気にせずに、自分たちの業務に集中できる環境を社内ITの観点から提供することを引き続き目指していきます。
最後に
来年リリース予定のプロジェクトも進行中ですが、今回は開発者ブログに公開されている内容をザックリまとめてみました。
来年は影響が大きい変更も予定しています。PR TIMESを社会的な情報インフラにするために開発を続けていきます。
今後もPR TIMESの開発本部が技術でサービスを前に進める組織であることを示していきます。
