プロダクトの運用保守計画とは？システムは作るだけでは終わらない
皆さん、こんにちは。パーソルプロセス＆テクノロジーの髙梨です。
私が所属するエンタープライズソリューション統括部 Global Bridge部では、プライムSIerとして主にパーソルグループ外の顧客に対してWEBの業務システムやスマホアプリの提案・開発を行っています。
東京・沖縄・ベトナム（オフショア）と複数拠点で連携した開発を得意とする部署です。
今回は、プロジェクトマネジャーやプロジェクトリーダーの立場で開発に関わっている私の経験を踏まえて、プロダクト開発における運用保守計画についてお話ししたいと思います。
◆自己紹介
髙梨 雄作（タカナシ ユウサク）
エンタープライズソリューション統括部 Global Bridge部に所属。
プロジェクトマネジャー、プロジェクトリーダーとしてシステム開発を担当。
物事に対する理解力と適応能力を武器に、参画プロジェクト毎に顧客の業界や業務、必要な技術要素の洗い出しなど、新しい課題に取り組み、お客様やチームメンバーと向き合っている。
プライベートでは昨年生まれた1児の父。2021年秋から半年ほど育児休業を取得し、2022年5月から職場復帰を果たした。現在育児に注力しており、趣味のスポーツ（主に球技）やヨガはセーブしつつ、早朝ウォーキングは継続中。
◆システム運用・保守とは？
私たちエンジニアの仕事は、プログラミングを行って、システムそのものを作るというイメージが一般的に強いと思います。しかし、新しく開発されたシステムやアプリが世の中で機能するためには、システムの運用・保守が必須です。
システム運用とは、システム活用した業務を安定的に稼働し続けるために行う作業のこと。日次・月次など決まったタイミングでのオペレーションや一般利用者からの問い合わせ対応などがあります。
またシステム保守は、システムに異常が生じた際、原因を調査・分析して安定的に稼働できる状態に回復させる作業やバージョンアップ等に伴う、プログラムの変更作業なども含まれます。
◆運用保守計画の重要性
前章で説明した通り、開発したシステムの運用保守計画を適切に策定することは、安定的な継続利用にとても重要な要素となります。
運用保守がうまく機能していないと、システム利用時にサポートに問い合わせても回答が遅かったり、適切な回答でなかったり……。
極端な話では、異常が生じて利用できなくなったシステムがいつまでも復旧しない。といったことが起こる可能性があり、当然のことながら利用者が離れていきシステムが使われなくなることも有り得ます。
加えて、運用保守業務を行う担当者は開発に携わっていないエンジニアや、IT知識が高くない非エンジニア(主に運用担当)の方が行うことも多く、それを前提として安定的な稼働を保つための業務プロセスや手順などを整備しなければならないのです。
◆初めての運用保守計画。沢山の難関が。
私が初めて運用保守計画を担当したのは、タレントマネジメントシステムのSaaSプロダクト開発のプロジェクトでした。
過去に開発したシステムの保守業務を継続して担当することもあり、運用保守計画で決めるべき内容は概ねイメージがありました。しかし、プロダクトの運用保守は想像以上に様々な難関がありました。
運用設計時の検討スコープ
今回は既存プロダクトの大幅バージョンアップのため、顧客側の事業部内でも部門別の役割分担が大きく変わることになります。そこで、部門横断でプロダクトのライフサイクル毎の作業プロセスの整理も運用設計で行うことなりました。
具体的には「営業→契約→導入→運用・保守→契約終了」のライフサイクルにおいて、作業プロセスの洗い出しを行い、事業部全体で各プロセスの担当部門の合意を取る、というミッションです。
※運用設計の対応範囲はプロジェクト計画によって異なりますので、必ず今回の範囲を対応するものではありません。
ゼロベースから一人体制
本プロジェクトは運用準備要員として途中参画でしたが、全体スケジュール以外は全て白紙の状態からのスタート。どのような段取りで保守計画を策定していくのか、お客様へ相談、提案しながら進めていく必要がありました。
人生初めてのリモートワーク
コロナ禍でのプロジェクトだったため、お客様と一度だけ対面で顔合わせを行った後はフルリモートワークに切り替わりました。会社としても私個人としても人生初めてのリモートワークでした。
◆任務遂行にあたって工夫・意識したポイント
事業部全体の巻き込み
プロダクトとしてのライフサイクル全体のプロセスを精査するため、事業部全体を巻き込む必要があったのですが、開発主幹部門以外の方はプロジェクト関係者として含まれておらず、まずは事業部全体を巻き込むため、以下の流れで体制を構築していきました。
運用設計検討の進め方を定義
作業プロセスの洗い出し及び部門別の役割案策定
顧客側の運用設計担当、責任者への説明
ステアリングコミッティへの付議、事業部全体での体制構築
運用保守計画の検討
運用保守計画の検討では、開発部門はもちろん、営業部門や導入サポート部門など様々な領域の方を招集、検討会の日程調整＆ファシリテート、計画案準備など全般的に私が主導して検討を進めていました。
プロダクトはお客様の資産であるため、進行にあたっては各部門や立場からの考えや想いを最後まで吐き出してもらうよう意識し、拡散し過ぎないよう適度に意見集約を行うように注力しました。
運用テスト計画・実施
運用保守計画の策定後は、その計画に沿った運用・保守に必要な手順書等のドキュメントを作成し、運用テストを実施しました。
基本的にプロダクト開発チームやインフラチーム等が開発・構築した本番相当の環境化でテストは実施するため、運用保守計画検討と同様に多くの関係チームと連携しながらのテスト推進となります。
各チーム、別の開発タスクを並行した中での連携なので、リードタイムを考慮して早めの相談・依頼を徹底していきました。
◆まとめ
私個人としてはとてもチャレンジ要素が大きかったプロジェクトですが、運用保守計画は無事に完了し、プロジェクトの締め会ではお客様よりバイネームで御礼のお言葉をいただきました。
(※数十名規模のプロジェクトでしたが、バイネームは私含めて２名のみ)
今回私が行ってきたことは、運用保守計画の一例でしかなく、対象システムやお客様側の文化・環境が違えば、最適な運用保守の手法は変わってきます。
実運用が始まると計画時とのギャップは多々発生しますし、運用保守ルールはその都度最適化されていく必要があります。
実際に運用保守計画を担当して改めて実感したことは、どんなに便利で使いやすいシステム／アプリを開発しても、適切な運用保守計画無しではお客様の事業や業務に対して価値は提供できないということです。
残念ながら、実保守の担当にはならず、プロジェクトを離れることとなりましたが、このプロジェクトで得た経験やナレッジを今後の様々なプロジェクトで活かしていきたいと思います。
弊社のTechコミュニティにご登録頂いた方には、今後もこのようなエンジニアブログの情報や、イベント開催情報をいち早くお届けいたします。SNSをフォローする感覚でお気軽にご参加ください。