大手コンサルティング会社
人事評価システムの再構築

スケジュールに合わせて段階的にシステムを公開

――システムの再構築にはどのような経緯があったのでしょうか？

お客様はコンサルティングという事業の特性上、特に人材力を重視しており、毎年人事制度を更新するほど力を入れていました。そうしたことから、人事評価システムを抜本的に刷新する本プロジェクトが立ち上がりました。
本プロジェクトの特徴として、「段階リリース」という手法を採った点があります。仮にA・B・C・Dという機能があったとし、A機能、B機能のみ先にリリースし、その後C機能、D機能をリリースするというものです。全機能揃えてからの移行はスケジュール的に難しく、旧システムから一度に新システムへ移行できなかったため「段階リリース」を行うことになりました。

システムの運用、保守、構築の同時進行で複雑化する工程

――「段階リリース」を行うにあたり、どのような苦労がありましたか？

再構築自体がかなりタイトなスケジュールで進められていました。そのため、再構築作業期間で対応しきれなかった残課題については、保守チームが保守と並行で作業を行うことに。その際、A機能、B機能についてはリリース済み、C機能、D機能については未リリースという状況でしたが、残っている再構築作業に使用するソースは全機能が含まれたものでした。この段階ではC機能、D機能について保守の改修リリースと一緒にリリースするわけにはいかないため、運用でソースを分岐させて対応しなければならず、ソース管理にはとても神経を使いました。
新システムに完全移行するまでは旧システムの保守も行う必要があったため、最終的には「段階リリース」という工程に加えて、新システムの再構築作業と保守、旧システムの保守を同時並行で行うという複雑な状況が生じることとなりました。

――かなり複雑な状況で事故やトラブルはなかったのでしょうか？

一部の再構築対応ソースが混ざってリリースされてしまい、ある機能の画面が表示できなくなるトラブルが発生。急遽再リリースするという事態が起きました。トラブルが起きた際、旧システムの保守ではその都度改修するという対応を行っていました。しかし、新システムの保守に切り替わってからはリリース管理の効率化を図るため、各課題にバラバラと対応するのではなく、その月にやる改修課題をまとめ、リリース手順書を作り承認を取って、原則月に1回のリリースを行う方針に変更しました。突発的なトラブルについてはシステムの運用を優先するのか、リリース管理フローの順守を優先するか選択を迫られます。その場合、トラブルに関わる機能がお客様にとってどのくらい使用頻度の高いものか、また、不具合がどの程度クリティカルなものかを判断し、持ち越せるレベルであれば次月のリリースに回し、急を要するものであれば臨時のリリース日を設けるという形で対応しています。

業務横断的な情報共有により円滑なプロジェクト進行を実現

――プロジェクトを最後までやり遂げるうえで特に重要だったことは何でしょうか？

「段階リリース」という手法を取りながら、新旧システムそれぞれに対応しなければならない状況で、チームでの情報共有はとても重要なポイントでした。本件では、旧システムの保守、新システムの再構築と保守それぞれにフレックシステムズのスタッフがいたため、互いに担当業務の垣根を越えてコミュニケーションを取ることで、一人ひとりがプロジェクトの全体像を把握することができました。任された業務の中に閉じこもらず、横のつながりを意識しながら広い視野を持ってプロジェクトを進めることの大切さを改めて実感しました。
また、ただお客様の要望通りに対応するのではなく、より効率的な進め方や本当に必要な機能があれば積極的に提案しました。時に意見が衝突することもありますが、「より良いものを作り上げるためには何が必要か」と考える機会を作ることは大切だと感じています。