PR TIMESでCTOをやっている金子 (@catatsuy) です。
たまに「なぜPR TIMESはPHPなんですか？ 今後もPHPを利用するんですか？」と聞かれることがあります。開発者ブログの記事として、考え方を明文化しておきます。
なお、先日以下の記事も公開しました。本記事はその補足として、技術選定（特にバックエンドの言語）について、判断軸をまとめます。
言語は目的ではなく手段
まず大前提として、なぜ私達がPR TIMESの開発をしているのかというと、私達のミッションである「行動者発の情報が、人の心を揺さぶる時代へ」を実現するためです。そのためのプロダクトとしてPR TIMESを運営しており、利用企業の方に継続して使ってもらえるように便利にしたり、新しい機能を追加して、価値を届け続けています。言語はその目的を達成するための手段です。
とはいえ開発としては、機能を追加するにあたって、どの言語でどうやって実装するかを決める必要があります。現在、PR TIMESの多くはPHPで実装されています。既存コードを拡張できるなら、システムとしても単純で工数が小さく、将来の変更も加えやすいはずです。
PHPは5系の頃にリリース間隔が空いた時期もありますが、現在はリリースサイクルやサポート方針が明確になり、継続的にメンテナンスされている言語です。加えてバージョンアップごとの進化も大きく、新機能の追加やパフォーマンス改善が継続的に行われています。
また開発コミュニティも非常に活発で、多くのライブラリやフレームワークが整備され、コミュニティイベントも継続的に開催されています。当社でも、こうしたコミュニティ活動の一部をスポンサーとして協賛しています。
もちろん部分的には得手不得手はあります。しかし現状動いている仕組みを多大なコストをかけてまで全面的に変更するメリットがあるとは思えませんし、採用・運用の観点でも現実的な選択肢です。
将来的に、他言語へ低コストかつ高精度に自動移植できるようになれば、状況は変わるかもしれません。ただし当面はその段階に至らないと見ており、少なくとも当面の方針は変わりません。
PHP以外を選ぶ条件と、移行の進め方
一方で、技術選定の話をすると「PHP以外は使ってはいけないのか」という話になりがちですが、そうではありません。大事なのは「古い／新しい」ではなく、「今後も拡張し続けられる前提を満たしているか」です。例えば、Web開発としてのコミュニティがほぼなく、新規採用の選択肢も乏しく、運用・保守の実績も少ない状態で動いているシステムであれば、別言語・別スタックへの移行が合理的になるケースもあります。
ただし移行も現実には一気にできないので、新旧共存を前提に段階的に置き換えていくことになります。そのとき最初に問題になるのは認証やセッションなどの横断部分です。横断部分を共有できる仕組みを作ってから、少しずつ新システムに寄せていくのが一般的で、Strangler Figパターンのような進め方をすることになります。
また、ミドルウェアやライブラリが実質メンテナンスされていないなど、既存のシステムを拡張するという手段が現実的に取れない場合は、その仕組みは基本的に捨てるしかありません。そのときに、全部捨てて作り直すのか、既存のシステムを活かしながら部分的に置き換えるのかは、コスト・リスク・スケジュールを比較して判断します。そういう議論をするためにDesign Docを利用しています。
PR TIMESの現在地と、最近の方針
PR TIMESのPHPは、一般的なフレームワークを採用しておらず、独自フレームワークの上で長く運用されてきました。一方で、古いコードをそのまま延命し続けるのではなく、少しずつ撤退を進めています。具体的には、新規の実装やリニューアルについては、新しい薄いフレームワークの上に載せていく方針で進めています。結果として、同じPHPであっても「古いコードを増やさない」「新しいコードを増やす」方向に寄せています。
PR TIMESでも、周辺機能や一部領域は別の技術スタックを採用しています。詳細は割愛しますが、一部の機能はGoとLambdaを活用して別のシステムで動かしていますし、一部のページはNext.jsからレスポンスを返しています。セッションの共有が行える土台を作っているので、このように必要に応じて一部を別言語で実装できる状態にはしています。つまり「PHPしか選べない」状態ではありません。
ここまでを踏まえて、最近の開発はざっくり以下の方針で進めています。
- バックエンドは、現行システムへの変更点が少なく開発速度も出せるため、基本はPHPで実装する。ただし古い書き方を温存するのではなく、新しいコードベースに寄せていき、Unit Testを追加できる状態に持っていく。
- リニューアルや機能追加のタイミングで、影響範囲を見ながら随時移行する。
- 変更コストと不具合リスクが高く、改善で追いつかない領域は、置き換えも選択肢に入れて判断する。
- 先日の記事で触れた社内管理画面の移行は、この判断が必要でした。
- フロントエンドは、ページごと・機能ごとに分けやすいので、Reactベースの新しいコードベースへ順次移行していく。
- ただし「すべてをReactにする」こと自体は目的にしない。必要な単位でリニューアルしていく。
- SSRが必要な場合はNext.jsを使うなど、要件に合わせて柔軟に技術選定をする。
ただし既存のシステムとは切り分けたほうが良いなど、特別な理由がある場合は、PHPにはこだわらず、そのときのベストな言語や構成を選択したいと考えています。
最後に改めて、言語選定の目的は「言語を揃えること」ではなく、価値を継続的に届け続けることです。PR TIMESでは既存資産を活かして改善し続けるためにPHPを基本としつつ、必要に応じて部分的に別スタックも選びます。今後も判断軸は変わらないと考えています。
