夏目 拓哉

## チーム編成 - PJM兼エンジニア 1名（自分） - エンジニア 3 名 - dept head（部長） ## 背景 - マイクロサービス化にあたり各サービスは独立したsystemになっていたが、認証・認可処理に使われるコアロジックはnpmパッケージにて共有されていた - 今後のサービス拡張や既存サービスのリファクタリングを考え、レガシー化している認証・認可処理を担うnpmパッケージに依存している状態を解消することで、より健全かつ柔軟なアーキテクチャを実現できると考えた ## 詳細 #### 課題 - マイクロサービス化している独立したsystem群であるにも関わらず共有packageを利用することが事実上必須になってしまうことから、ユーザーに価値を還元することを念頭に置いた適切な技術選定ができない - 複数systemに固有の関心事が共有packageに実装されており、処理が複雑になっていた - コアロジックにも関わらずテストが存在していなかったため、手を入れることが難しくレガシー化していた - 共有pakcageへの依存によって、security valunability対応やEOL対応に際するnodeのバージョンアップが困難になっていた #### ソリューション - 共有packageの認証・認可実装を元に事実上の処理要件を洗い出し、gateway serverに実装 - gateway serverはGEK上のpodにsidecarとしてinjectするアーキテクチャを採用し、golangで実装 - ユニットテストを丁寧に整備することで、事実上の認証・認可要件をテストコードとして仕様化 - systemごとのmiddleware設定機構の導入 - 複数systemへの導入を想定し、system毎に有効にしたいmiddlewareをyml形式で指定できる機構を設計・実装 - 対象systemへの導入・検証 - プロダクトチームを巻き込んで対象systemにgatewayを導入 - securityチームを巻き込んで、セキュリティホールがないかを検証する手順の作成・実行 #### 成果 - 導入systemにおいて、共有packageの依存を剥がすことに成功 - 該当systemは今後独自に技術選定やバージョンアップなどを実行できるため、ユーザーへの価値還元をスピード感を持って進められる - 現在各種プロダクトチームを巻き込む形で横展開を推進しており、今後は上記のようなケースがsystem横断的に増えてくる想定 - 組織スケールで継続的なユーザーへの価値提供にコミットしやすくなる環境へ #### 工夫 - PJMとしての貢献 - チームのロードマップを策定〜ステークホルダーとの調整まで一気通貫に行った - ソフトウェア開発とは進めていく中で想定していない課題が見つかるのが常なため、プロジェクトをマネジメントするといってもあくまでアジャイルに、つど柔軟に優先度を見直しながら進めていった - ステークホルダーとの調整を事前に行い、柔軟なプロジェクト管理ができるような体制をスタートから作っていき、健全な形でプロジェクトを遂行できるよう意識した