システムのインフラ基盤を専用環境から既存の基盤へ統合、セキュリティ要件も満たしつつコスト削減を図る
・ID・ポイントを管理するシステムでは専用環境を使用しており、EOSL対応のコストが年々肥大化しているため、コスト削減の課題があった。
・社内におけるセキュリティ要件の見直しに合わせ、当該システムのインフラ基盤を専用環境から既存のインフラ基盤へ統合することでコスト削減を図り、セキュリティ要件も満たすようシステム及び開発・運用の見直しも行う大規模プロジェクト。
・開発基盤（インフラ・アプリ）の統合、開発・運用体制の見直し、EOSLスキームの見直しという3つのミッション・ユニット体制で行われた。
・複数の部署がかかわるプロジェクトにおいて、各部署の文化のギャップを埋めつつ柔軟かつ確実な大規模プロジェクトの運営が求められた。
体制図
・プロジェクト、各ユニット立ち上げ（各種ルール整備、開発環境整備等）
・会議運営（設計～運営）
・進捗、課題の管理（構築～運営）
・各種アカウント管理
・「スムーズなプロジェクト・ユニット立ち上げ」初期検討と並行してユニット・プロジェクトの立ち上げを行った。当初はそれぞれのユニットがプロジェクトとして動いていたので、ユニットとしての運営ルールは尊重しつつ、プロジェクトとして守るべきルールを最低限定めることにより、1つのプロジェクトとなったときの全体へのインパクトを最小化した。
・ユニット間をまたぐ課題やタスクは、各ユニット付PMO間で連携しながら進捗等を管理した。
大きな変化とワクワクするプロジェクト統合
個人的に大変だったことは、当初はセキュリティに関する知識が薄かったため、用語が分からず、会議運営や課題の管理に苦労した。
調査フェーズは有識者の集まりだったので規模が小さかったが、要件定義以降はメンバーがどんどん招集され容易に100名を超えてきたので全メンバーの権限管理やチームごとの会議運営、進捗や課題の管理が追いつかず、またスコープの見直しが頻発し、状況理解と課題・スコープの把握にも苦労した記憶がある。
ユニット再編と協業の複雑さ
ユニット再編が頻繁に行われていたので、どのユニットの方針に従うべきか、どれぐらい静観するべきか・（状況整理など）手を出すべきか、初めて協業するメンバーがほとんどだったので手探り状態だった。
行気に個人的に良かったことは、開発基盤を変える（統合する）というのは、顧客にとっても大きな変化の1つであったように思う。難易度は高かったがワクワクしながら完走できて良かった。
また、自分以外にも複数人（他社の）PMOが入っていたが、他社だから…他ユニットだから…という遠慮をせず、密にコミュニケーションを取れていたのでユニット間でのこぼれ球を発生させなかったのは良かったと思う。
日本人メンバーとオフショア協業の興味深い過程
オフショアとの協業が初めての日本人メンバーたちが、当初持っていた「安かろう・悪かろう」というイメージを、一緒に机を並べて設計について議論したりコミュニケーションを深めながら馴染んでいく過程を間近で見られたのはとても面白かった。
メンバー同士の結束が硬かったチーム（専用環境だったため他領域との交流がなかったという背景もあり）の人たちに気軽に声をかけてもらうにはどうしたらいいだろうかというのを常々考えており、ミーティングの冒頭で毎回アイスブレイクをやってみたり、Slackのリアクションで絡んでみたりと試行錯誤した結果、2,3ヶ月ぐらいで馴染むことができた。
これは本当に良い経験になったと思う。