オンプレからクラウドへの大規模移行と業務アプリ刷新を同時実現したプロジェクト
私がJQで担当したプロジェクトの中で、特に「やって良かった」と感じているのは、直近まで携わっていた生命保険会社の資産運用業務システム基盤更改プロジェクトです。
このプロジェクトの背景には、既存システムが稼働から7年を経過し、OSサポート期限が終了するという技術的な課題がありました。期限が終わってしまうとシステムを使い続けることができないため、期限前に新しいOSとハードウェアに載せ替える必要性が生じていました。
同時に、7年間の運用でデータが大幅に増加し、業務アプリケーションのパフォーマンスが著しく低下していました。ユーザーインターフェースも古く、利用者からの不満が多く寄せられている状況でした。
そこでプロジェクトの目標として、まずスケジュール通りにオンプレミスからクラウド（AWS）へインフラとデータを確実に移行すること、次に業務アプリをパフォーマンスと操作性を改善した新しいものに切り替えること、そして資産運用の根幹を担うシステムということで、止まらない品質を維持するということと、コスト・納期の予定内に収めることを目指しました。
私の役割は、システム開発部門全体の統括チームにおいて、プロマネとペアで動きながらプロジェクト全体を推進していく立ち位置でした。プロジェクトの体制は、システムを実際に使用している業務部門、情報システム部門、パッケージソフトウェア開発部隊、そして外部の開発協力会社が含まれるという大規模なものでした。
結果として、正味3年をかけたこのプロジェクトは、スケジュール・コスト・品質すべてを計画通りに達成し、オンタイムでリリースできました。性能面でも当初の目標を上回る改善効果が得られ、利用者からも非常に高い評価をいただいています。
複雑なステークホルダー環境下で、大規模プロジェクトを完遂させた方法
このプロジェクトには様々な困難がありました。それは、移行対象のシステムが、資産運用という業務の性質上、営業日は常に稼働させる必要があり、かつ金融機関として外部への情報開示責任も担うような、ミッションクリティカルなものであったからです。
失敗が許されないプロジェクトであるにも関わらず、サポート切れの期限も決まっているため、期間内に確実に移行を完了させる必要がありました。そのため社内での注目度も非常に高く、様々な役職の方々が意思決定会議に参加される緊張感のあるプロジェクトでした。
第一の困難は、ステークホルダーの期待値コントロールでした。大型プロジェクトでは様々な役職の方が企画構想段階から意思決定会議に登場してきますが、クラウドに対する理解にばらつきがありました。
具体的には、クラウドに対する漠然とした不安（「AWSが止まったらどうするのか」「ニュースでクラウドが止まったと聞くが大丈夫なのか」）がある一方で、現実とかけ離れた過度な期待も存在していました。「7年ぶりの作り替えだから絶対に何倍も早くなるよね」「クラウドは機械が故障しないから絶対止まらない」「サーバーをデータセンターに持たなくていいから安くなる」といった、根拠のない期待が多く聞かれました。
これに対しては、現実と期待のギャップを一つ一つ丁寧に整理し、根拠に基づいた期待値コントロールを継続的に行いました。技術的な制約や費用対効果について、具体的なデータと事例を示しながら説明を重ね、計画中では特にこの期待値コントロールに苦労しました。
第二の困難は、お客様側の高いサービスレベル要求と、開発ベンダー側の守りの姿勢との調整でした。稼働率に関する契約条件については、3年プロジェクトの最後の3ヶ月まで調整が続きました。
この課題は、どんなリスクがあるかを事前に整理し、どのような対応策が取れるかをしっかり検討し、契約関係も含めて、調整をはかることで解決ができました。
第三の困難は、品質の管理でした。開発ベンダーには不都合な情報を隠したがる傾向や、報告を簡略化したいという姿勢がありました。
これに対しては、お客様側の品質管理基準に合わせるよう、報告レベル・管理レベル・品質要求レベルのギャップを一つ一つ埋めていきました。上がってくるレポートも詳細にチェックし、疑問点や懸念点があれば随時申し入れをして回避策を講じてもらうよう、かなり強い調整を行いました。
第四の困難は、システム構成の技術的課題でした。今回のプロジェクトでは、大規模災害時でも安定的に業務を止めないことがミッションだったため、本番環境と災害対策環境を東日本と西日本に分けて構成する必要がありました。
特に重要だったのは、いかに短時間で切り替えを実現するかという点で、そのためのデータ同期の仕組み設計が非常に大変でした。この大きなシステム構成を決めるところが要件定義の終盤まで続き、要件定義終了2ヶ月前という非常にギリギリのタイミングでようやく着地できました。
元々要件定義は半年くらいの予定でしたが、この技術的課題の解決が最もリスキーな部分でした。ここが着地していなければ、全体のスケジュールが守れず、稼働率などの品質要件も満たせなかったはずです。
この解決には、私たち自身が徹底的に調査しお客様ともディスカッションを重ね、有識者の意見も聞き、ベンダー側の提案を鵜呑みにしないというアプローチを取りました。実際にプロトタイプ構成を作って性能評価を実施し、数字で検証した結果、ベンダーの元々の提案では性能要件を満たせず、かつ非常にコストの高い提案だったことが判明しました。
私たちとお客様とで協力して考案した方式の方が、性能面でも問題なく、コスト的にもリーズナブルだったため、確信を持って選択することができました。この技術的判断が、プロジェクト全体の成功における重要なポイントだったと考えています。
醍醐味は、仲間と一緒に大きなことを成し遂げ、物事をしっかりコントロールすること
私にとってのプロジェクトマネジメントの醍醐味とは、「自分一人ではできないことを仲間と一緒になって、仲間を率いながら実現させられる」ことにあります。
特に大規模なプロジェクトでは、自分の経験上想像が及ばないレベルの大きなことを、たくさんのメンバーと一緒に形にしていくことができます。この規模感での達成は、前職での比較的小さな案件では味わえなかった新鮮な充実感があります。
また、難しい問題に対して情報を集め、分析し、方向性を示していく過程で、その方向性に対してチームの合意を得て前に進めることに大きなやりがいを感じています。問題には必ず原因があり、課題となっている部分の解決策を考え、みんなで導いて前進させていく、この「役に立っている」実感が非常に良いと思っています。
そして何より、リスクをコントロールできることに面白さを感じています。リスクがそのまま顕在化すれば問題になるからこそリスクなのですが、それを顕在化させないために適切な対策を講じることで、実際に顕在化を抑止できたり、万が一発生しても最小限の損失で留めることができます。
プロマネとしての醍醐味は、このような「物事をしっかりコントロールする」ことにあると考えています。プロジェクトで得たフレームワークや検討資料を他のプロジェクトでも活用できるよう資産として残し、他のプロマネの参考にもなるように展開していく、こうした「役に立っている感」も大きな充実感につながっています。
プロジェクトマネージャーが、多様なジャンルで継続的に成長を実感できる場所
私が感じているような醍醐味を追求するために、JQは最適な環境だと考えています。
事業会社では、どうしてもジャンル・メンバー・規模感のバリエーションに限界があります。私も前職で色々やらせてもらいましたが、特に事業ジャンルが決まってしまうため、時にマンネリを感じることもありました。
JQでは、様々なジャンル・規模の案件に対して支援していることから、多様な案件を経験できる機会があります。毎回新鮮な気持ちで案件に臨むことができ、もし新しい分野で悩んだとしても、JQ内には経験豊富な人たちがいてアドバイスをもらえる環境が整っています。
実際に私もJQに入ってから、某大手SIerの新規サービス系DX案件、生命保険会社の基幹システム、業務システムの基盤更改という全く異なるジャンルの案件を、それぞれ違うメンバーと経験してきました。そのたびに一つの環境では得られなかった発見や学びがあり、大きなやりがいを感じています。
また、JQのメンバーは皆協調性があり、良いチームメンバーとして働ける人が揃っています。本当にお手本にしたいような人や、切磋琢磨できる仲間と一緒に働けることも、この環境の大きな魅力です。ライバルというよりは、一緒に働いていく仲間というタイプの人が多く、仲間と一緒に成長したいという思いを持つ人には理想的な環境です。
さらに、新しいことを学習し吸収していくことに魅力を感じる人、タフさを持ちながらも冷静に判断できる人、相手を信じて前向きに取り組める人にとって、JQは最適な場所だと思います。基本的には相手を信じられる人、文句ばかりではなく、成長意欲がある人と一緒に働きたいというのが、私の実感です。
転職せずに一つの会社の中でこれだけ多様な経験ができるのは、JQの素晴らしい特徴だと思っています。一つのジャンルにこだわるよりも色々なジャンルを経験してリードしたいというチャレンジングな人、仲間と一緒に成長したい人、リーダーになりたいという思いを持っている人、困り事を解決して人の助けになりたいホスピタリティのある人には、特に適した環境だと考えています。
