三年間の関わりから見る PR TIMES エンジニアリングの変化

2024年9月25日

URLをコピーしました！

Technical Advisor の @1000ch です。私がジョインしたのが 2021-09 なので、気付けば PR TIMES に関わって丸 3 年が経過していました。3 年間という月日は組織や事業を変化させるには十分な時間です。普段は気が付きにくいですが、改めて 3 年前と今を比較すると大きな前進を感じますので、その変化に主観を交えて記事を書きます。

今日現在までの 3 年間で起こった出来事

PR TIMES はプレスやニュースの配信サービスとして広く利用されています。今も昔も開発部が PR TIMES のプロダクト開発を支えていることに変わりはありませんが、昔は（3 年前時点では少なくとも）組織としてもシステムとしても、今よりずっと不安定な状況でした。

古くアップデートできていない PHP に jQuery を使った Frontend 実装、ホストしているオンプレミス環境へのデプロイは CI/CD が組まれておらず、とにかく機能追加もままならない状況に陥っていました。これらのシステム全般の課題は事業リスクそのものであり、エンジニアリングとして向き合い対処しなくてはなりません。@catatsuy さんが PR TIMES にジョインした直後の開発者ブログで大まかな方向性を示している通り、PR TIMES を支えるシステムのあるべき姿に向けての動きはじめたのがおよそ 3 年前でした。

レガシー PHP のバージョンアップと React の導入ではじまった一歩目

時々の出来事は開発者ブログで記録されている通り、小さなものから大きなものまで様々な改善が行われています。差し当たっての目標は 巨大なモノリス実装の責務が適切に減り、セキュアで素早い運用改善に耐えうるシステム にすること。その本丸は、古いバージョンの PHP を最新版まで更新しオンプレミス環境からクラウドに移設すること、そして jQuery で実装されている Frontend を React に置換することでした。

私が関わり始めたのは、ちょうど上記が現在進行系で動きはじめたタイミングだったと思います。React の導入は妥当な判断でありつつ、Frontend / Backend を含む古く大きなコードベースに新たな Frontend 実装が混在している状況でした。そこで、新たな Frontend 実装を別リポジトリとして切り出すことを決め、柳さんが 1-2 週間という素晴らしいスピードで実現してくれました。これがなくては現在の開発生産性はなかったかもしれない、大きな分岐点だったように思います。

継続的なコミュニケーションを通じた信頼関係の構築

2021-09 時点では、いわゆる Frontend を得意領域とするエンジニアは、新卒 1-2 年目の 3 人でした。まずは Frontend の組織力を向上させるために、この 3 人との伴走がフロントエンド定例という会議体ではじまりましたが、2024-09 時点で参加者は 10 人以上に増えています。数がいることが是というわけではありませんが、Frontend を専門とするエンジニアが増えているだけでなく、 Frontend が専門ではないエンジニアも自発的にフロントエンド定例へ参加して、PR TIMES Frontend の未来を議論している ことは、技術者同士が健全な良い関係を構築できている証拠とも言えるでしょう。

組織が大きくなればなるほど専門性やプロセスは分化するのがエンジニアリングに限らない傾向であり、良い面だけではなく悪い面もあることは周知の事実です。PR TIMES ではエンジニアリングの方針として、Frontend や Backend といった分断されがちな専門領域を区切りすぎず、別け隔てなく取り組むことを推奨しています。特に感心するのは、これが理想論に終わることなく多くのエンジニアが実際に近接領域に手を伸ばし、自己成長と活躍を両立させている点です。例えば、直近でもバックエンドエンジニアから見たフロントエンド開発の魅力と学びという記事が公開されていることから感じ取っていただけると思います。

実際のシステム改善の進捗

巨大なモノリスとなっていたシステムには、PHP のバージョンアップを中心に様々な変化が加わっています。以下は抜粋です。

古くなっていた PHP を、数回に分けて段階的にアップグレード
複数ステージング環境の実現による、QA プロセスの改善
オンプレミスで運用していたシステムを AWS へ引っ越し、Terraform と Ansible の活用を抜本的に見直し
CDN を CloudFront から Fastly へ切り替え

当然ながら機能開発を完全に止めることはできないため、システムの改善も同時並行で行われてきました。ご想像の通り PHP のアップグレードは 1 行に収まらない困難が伴いますが、実現してこれたのは uzulla さんのリードに依るところが大きいでしょう。今後は最新版へのアップグレードを控えており、困難だと思われたマイルストーンも手の届くところに来ています。

Frontend もリポジトリの分割を起点に、プロダクト開発の中で React 実装への置換を進めつつ、数多くの基盤改善を積み重ねて来ました。

これらの改善は、先のフロントエンド定例を通じて継続的に議論し、実行しています。現在進行系のトピックとしては、下火になりつつある CSS in JS からの脱却として、メンテナンスが鈍化している emotion から CSS Modules へ移行や、アップデートの止まりつつある Recoil からの脱却、またはアクセシビリティ改善のイチ要素として HTML 品質の改善などがあります。

個々の仕事への向き合い方や組織的な変化

前述の通り、主には「組織に人が増えてシステムの改善が着実に進んでいる」ことが結果としてあります。これだけではなく、個々の動き方や組織力の向上を様々な点から言及してみます。

「やりたい」で終わらない課題設定

これは特定の瞬間を切り取った話ではなく、繰り返し行ってきた議論の中で変化を感じる 1 つです。エンジニアの技術に対する好奇心は尊いものですが、株式会社という営利組織である以上、個々の「やりたい」を常に尊重できるわけではありません。エンジニアに限らず、チームや一人ひとりの業務には説明責任が伴い、誰しも「やりたい」と「事業における合理性」の両立を目指しているかと思います。

会議体の発足当初は、各自が考える「何をどうしたい」の、前提となる課題設定が非常に曖昧でした。無意味なソフトウェア改善というのは恐らくありませんが、実施には工数が必要であり、ROI がある以上は優先度に直面します。「なぜその状況に直面し（背景）、どうして改善が必要で（課題）、どのように実行すべきか（解決策）」を議論のフレームワークとし、イシューに向き合うことを徹底してきました。

その結果として議論の仕方が大きく変化しただけでなく、自然とソフトウェア改善そのものの質が高まり、「実施したものの効果を実感できない」「導入したがメンテナンスコストが嵩んでしまう」といった実施したことを後悔する場面が体感的に減っています。

先駆者や自身の成功体験による主体性の獲得

エンジニアリングチームのプロダクト開発やソフトウェア改善に対する姿勢にも変化を感じます。これには様々な要因があると思いますが、課題設定とそれに対するアクションという PDCA を繰り返してきたことが、成果に結実して成功体験となり、一人ひとりやチームの自信となっている部分もありそうです。

初期は「何を改善できるかを考えよう」と課題を募るところに始まり、その思考プロセスやアイデアそのものを修正しながら、提起した人が自ら行動してきました。今では、自発的に課題を設定し解決策を考案した上で、チームの協力を仰いで実行するという動きに変化しています。PR TIMES のアクセシビリティに関する記事も、夛田さんのイニシアティブを象徴するものです。

アクションの進め方は、xo を導入した前後で変化したという指摘が柳さんからありました。これは ESLint のルールや関連するパッケージの保守に時間がかかっていた状況を鑑みて私が提案したものですが、当然ながら影響範囲すべてを 1 人で修正することは難しいので、タスクの分担やサポートに重きを置き、チームで協力して完遂しました。単純な話ですが、これは「課題解決を主導することが重要なのであって、自分 1 人で何とかする必要は必ずしも無い」ということにチームが気付いた瞬間だったのかもしれません。

Frontend という領域の確立と組織的関心

人が増えてチームらしさが出てきたと同時に、PR TIMES における Frontend という領域が確立されてきたように思います。これは前述の通り PR TIMES でのエンジニアリングで Frontend / Backend といった専門性を分化する意味ではなく、そういった風潮もありません。

昨今の Frontend 領域の技術的な発展を見れば、片手間の仕事で Web エンジニアリングを持続することは困難です。また、PR TIMES のプロダクトとしても主戦場が Web であることは明らかであり、こうした状況下で プロダクトの主戦場となる Web の領域技術に組織が向き合い投資できている ことは大きな前進でしょう。