📝
【プロジェクト体験談】RHBK & Angular バージョンアップ
0.はじめに
Red Hat Single Sign-On（RH-SSO）とAngularのバージョンアップを同時に進めた今回のプロジェクト。
認証システム（RH-SSO → RHBK）とフロントエンドフレームワーク（Angular 17 → 19）の両方を対象にしたことで、技術的な難易度はもちろん、スケジュールや品質管理の観点でも多くのチャレンジがありました。
本記事では、プロジェクトマネジャーとして「どう進めたか」「どこで詰まったか」「何を学んだか」を整理しています。
今後、同様のバージョンアップやプロダクト移行に取り組む方の参考になれば幸いです。
1.要点
- 成果：RH-SSO（v7.4）→ RHBK（v26）、Angular（v17 → v19）へのバージョンアップを完遂
- 工夫したこと：計画の文書化、スケジュール調整、関係者との丁寧な合意形成
- 教訓：余裕あるスケジュール設計、コミュニケーション手段の使い分け、「精度」と「品質」の違いを意識した対応
2.背景と目的
- RH-SSOおよびAngularは、ともにサポート終了が迫っており、システム維持の観点から移行は必須でした。
- 特にRH-SSOはバックオフィス業務の認証を担っており、トラブルが発生すれば業務全体に大きな影響が及ぶ可能性がありました。
- 今回のRHBKへの移行は、組織としても初の事例であり、製品移行そのもののハードルが高かった点も背景にあります。
3.スコープと制約
- 予算や人員についての大きな制約はなかったものの、スケジュール面ではタイトな状況でした。
- 対象システムは他案件（テスト等）とも並行していたため、品質面でのトラブルが多く、チームメンバーがそちらに時間を割かれる場面もありました。
4.進め方の工夫・戦略
- RHBKおよびAngularについて、事前に基本知識をインプットした上で、「なぜこの方針で問題ないのか？」をBPと議論。
- RH-SSO → RHBK移行において、基本設計段階で構築とテストに時間がかかると予想。リリース日を2週間延期し、スケジュールに余裕を持たせました。
- 文書と対面のハイブリッドで合意形成を進行。QAや計画書をしっかりと資料化しつつ、フェイストゥフェイスでの擦り合わせも重視しました。
5.うまくいった点・工夫した点
- 計画段階で、「誰が・いつ・何をすべきか」を紙に落とし明確化。これが混乱防止に寄与。
- プロジェクト前後でRHBK・Angular双方について基礎知識を学び、BPとの意思疎通が円滑に。
- リリース資源やテスト計画のレビューを強化し、BP側の品質に対しても牽制を効かせた。
- リリーススケジュールを意図的に後ろ倒しし、「構築」「有事対応検証」「性能テスト」に十分な時間を確保。
- トラブルが発生した際は、即座に「集まる → 共有 → プラン策定」という対応を徹底。
6.詰まった点と対処法
- Angularでは、画面リグレッションテストの範囲を決めかねたため、手動で全画面チェックを実施。次回はテストの自動化を目指す。
- 一部クライアント端末では、WebViewの更新が自動で走らず、バリエーションテストやユーザー合意が必要に。将来的には自動リフレッシュ機能の搭載を検討中。
- RHBK移行では、Ita上でリフレッシュトークン発行時にエラー。OIDC仕様の変更により、発行元確認プロセスが必要になっていた。BFF側でHTTPリクエストのロジック修正により解決。公式ドキュメントには記載がなく、Itaでの検証で発見。
7.振り返っての教訓
- 「精度」と「品質」は別物。BPは「仕様通り動作するか」を見るが、ユーザーが感じる体験品質には別の視点が必要。ここをPMが補完すべき。
- 対面・非対面のコミュニケーションのバランスが極めて重要。資料化だけでなく、「腹落ちするまで話す」文化が必要。これは泥臭いが、極めて効果的。
- 品質を気にするあまり、手動テストが肥大化した面もある。次回以降はテスト自動化など、テスト効率化に取り組みたい。
8.まとめ & 次に活かすこと
まとめ
今回のバージョンアッププロジェクトは、ただの「技術対応」に留まらず、
- 計画力
- 関係者調整力
- 品質に対する洞察
といった、PMとしてのスキル全般を問われるチャレンジでした。
次に活かすポイント
- 計画・レビュー・意思決定プロセスをしっかりと文書化し、今後の類似案件に再利用可能な形でナレッジを蓄積。
- 品質と精度の違いに敏感になることで、ユーザー目線の価値提供がより一層意識できるように。
- テスト自動化などの技術的改善も並行して推進することで、より少ない負荷で高品質なリリースを目指していきたい。
おわりっ！
Discussion