こんにちは、開発チーム・バックエンドエンジニアのSongです。
最近、プレスリリースを受信したいメディア関係者（メディアユーザー）向けのマイページを PHP + Smarty + jQuery から PHP + React にリプレイスしました。
このプロジェクトではリーダーとして挑戦しました。今回は、プロジェクトをどのように進行したか、そして初めてリーダーとして挑戦してうまくできたことや悔しかったことについてシェアしたいと思います。
ちなみに、PR TIMESのメディアユーザーにについて詳しく知りたい場合は、以下を参考にしていただければと思います。
背景と目的
プレスリリースはメディアに向けて発表するというのが目的の一つです。メディアがPR TIMESを業務の一部として活用し、記事を執筆するようになると企業の取り組みがより多くの企業や生活者の目に留まります。
従って、プレスリリースを配信したときの価値をより高めるためには、メディアによるプレスリリースの利活用を促進することが必要です。そのためには、メディアユーザーのマイページにおける機能の改善・追加が求められます。
ただし、現在、このマイページのレガシーコードはメンテナンスされておらず、各機能の仕様に関わるドキュメントもなくて、機能の改善・追加を困難にしています。機能の改善・追加の準備のために、まずはコードのリプレイスを行うことになりました。
プロジェクトをどのように進行したのか
マイページにおける機能を調査、仕様書を作成する
このプロジェクトの目標は、ソースコードをリプレイスすることであり、新機能を追加したり既存の機能を改修することではありません。従って、リプレイス前とリプレイス後で、既存の機能が維持され、その動作に何も変更がないことを確保する必要があります。これを達成するために、現在のマイページにおける各機能やその動作、それに対応するコードを調査しました。
さらに、調査と併せて、PdM、QA、エンジニアのチームメンバー全員が既存の機能を明確に理解できるように、仕様書を作成しました。これにより、開発プロセス中の混乱を避け、テスト中に発生するリスクやエラーを最小限に抑えることができました。また、最初から仕様書があることで、将来の機能追加・改善にかかる時間とコストを削減することができます。
リプレイスのロードマップを作成する
各機能のリプレイス順番やそれぞれに実装時間を定めるために、ロードマップを作成する必要があります。
私たちは、マイページにおけるページごとに基づいてエピックに分け、それぞれのエピックの目標、実装時間、優先順位を明確にするために議論しました。ここで、PdMから「各エピックごとに早く終わらせるのではなく全てのエピックが早く終わらせられるようにする」というゴール設定を明確に共有してくれていて、それをメンバー全員が理解して優先順位を調整していたのがすごく良かったです。
議論と調整を行った後、ロードマップが作成されました。全てのエピックをできるだけ早く完了させるために、エピックを順番に実装するのではなく、2つから3つのエピックを並行に実装することもありました。
APIスキーマを作成する
各機能のリプレイスに新規作成する必要があるAPIを定めるために、APIスキーマについて議論しました。ここで、APIが存在しない処理、レガシーなAPI、リプレイス済みのAPIをまとめました。そのおかげで、実装する必要があるAPIを網羅し、それに基づいてAPIスキーマを作成することができました。また、実装すべきのAPIの漏れを防ぐことができて良かったです。
さらに、リプレイス作業を早く終わらせるように、可能な場合は既存のAPIも再利用することにしました。具体的には、今回のプロジェクトではフォロー機能とフォローをやめる機能のAPIを再利用しました。
APIスキーマがあることで、フロントエンドとバックエンドが各エンドポイント、リクエストやレスポンスのパラメーター、データ型などを統一することができました。
また、このAPIスキーマの議論を通じて、フロントエンドがどのコンポーネントを作成し、そのコンポーネントではどのAPIが必要かを丁寧にコミュニケーションできました。その結果、早い段階でAPIの繋ぎ込みが可能な状態を作り、APIの繋ぎ込みコストも大幅に削減できました。
開発に着手する時にタスクを細分化し、ガントチャートを作成する
各エピックの開発に着手する時に、チームミーティングを行いながら、タスクの作成と調整を行いました。ここで、作業量を減らすために、タスクを細分化し、それぞれに実装内容や実装時間を明確にしました。
例えば、APIの実装という一つのタスクを作成する代わりに、その範囲が広すぎるため、Repo層の実装、Service層の実装、Action層の実装およびAPIが動作するものにするという3つのタスクに分割しました。
さらに、プロジェクトにかかるタスクを可視化し、簡単にスケジュールを組み立て共有できるように、ガントチャートも作成しました。
今回のプロジェクトでは、タスクを細分化し、ガントチャートを作成することで、以下のようなことが得られました：
- すべてのタスクを可視化できるため、業務の割り振りが最適化しやすかった
- タスクを細分化することで、簡単に完了できるようになり、チームは目標を迅速に達成し、高いモチベーションを維持できた
- タスク間の依存関係を明確にし、効率的なプロジェクト運営が可能になった
- チームメンバーの作業状況やプロジェクトの進捗状況がひと目で分かった
- プロジェクトに遅延があった場合、どのタスクに遅れがあるのかすぐに分かった
初めてリーダとして挑戦してうまくできたことや悔しかったこと
今回のプロジェクトを通じて、RESTful APIの設定・実装やPHPなど技術を高めました。その上、初めてリーダとして挑戦してうまくできたことや悔しかったことがあるので、それについて話したいと思います。
うまくできたこと
日本語でのコミュニケーションの障壁を乗り越えた
自分の日本語能力が不十分だという恐怖を乗り越えて、日本語でチームと積極的にコミュニケーションを取ることができました。これにより、自分の日本語力が向上しただけでなく、チームメンバーとの関係もより一層強化されました。
チームメンバー間のコミュニケーションがスムーズに行えた
チームメンバーの進捗状況を把握し、直面している問題を解決するために、デイリーミーティングを効果的に行えました。これにより、チームの協力関係が向上し、問題が早くに解決できるようになりました。その結果、プロジェクトの円滑な進行と目標の達成を確保することができました。
プロジェクトの進捗管理を効果的に行えた
大きなタスクを細分化し、それぞれに優先順位をつけ、適切のチームメンバーに分担することで、効率的に作業を進めることができました。また、ガントチャートやJira タイムラインなどのプロジェクト管理ツールを活用することで、メンバーが現在の進捗状況を簡単に把握することができました。
リスクを早期発見や解決できた
開発工程を通じて、データの一貫性の欠如や一部の機能が既存のバグである可能性などのリスクを早期に発見し、解決することができました。これにより、将来の機能の追加・改善の際のコストを削減することができました。
悔しかったこと
リーダーシップの経験がまだ浅い
初めてリーダープロジェクトリーダーの役割を担当するため、リーダーシップの経験がまだ浅いです。そのため、ある問題を解決するためにどうすれば良いか時々悩んでいたことがありました。
幸いなことに、チームの一部のメンバーは豊富なリーダー経験を持っており、そのメンバーに提案してもらった解決方法を参考にし、学ぶことができました。
プロジェクトが時々期待通りに進められないことがあった
プロジェクト全体は期限内に完了しましたが、実際には、いくつかのエピックの実行中に予期しない問題が発生し、これらのエピックの完了が計画よりも延長されることがありました。そのため、全体の進捗を確保するために、他のエピックの順番や実装時間を再調整しないといけないことがありました。
最後に
今回のプロジェクトの実装で、メディアユーザーのマイページに関する機能の仕様書が作成され、コードもメンテナンスしやすくなりました。これにより、機能改善・追加が容易になりました。
将来、機能が改善・追加された後、メディアがメディアユーザーとして登録し、よりPR TIMESを活用できるようになることを楽しみにしています。
その上、このプロジェクトを通じて、リーダーシップ経験やプロジェクト管理経験を学ぶことができました。将来、他のプロジェクトでこれらを活かし、さらに貢献できればと思っています。
