システムは作って終わりではありません。むしろ運用保守フェーズこそが、システムの本当の価値を発揮する場面です。しかし多くのプロジェクトで、この運用保守フェーズで深刻な問題が発生します。私はPMOとして10年以上、複数の運用保守プロジェクトを見てきましたが、どのプロジェクトでも同じような落とし穴に陥る姿を目の当たりにしてきました。
開発が終わってホッとしたのも束の間、気づけば特定のメンバーに依存した状態になり、ドキュメントは実態と乖離し、顧客要求は際限なく増え続ける。現場は疲弊し、品質は低下し、コストは膨らんでいく。この悪循環を、私は何度も見てきました。
今回は、運用保守フェーズでよくある3つの落とし穴について、私の実体験をベースにお話しします。現在も自動車保険システムの運用保守PMOとして現場に立っている経験から、これらの問題がなぜ起きるのか、そしてどう防ぐべきかを具体的に語ります。
運用保守フェーズで見た3つの地獄
運用保守フェーズに入ると、開発時には見えなかった問題が次々と表面化します。私が10年以上PMOとして見てきた中で、特に深刻な3つの落とし穴があります。それは属人化、ドキュメントの陳腐化、そして顧客要求の際限ない増加です。
落とし穴その1:属人化という名の時限爆弾
運用保守で最も怖いのは属人化です。特定のメンバーにしか分からない状態が続くと、その人が抜けた瞬間にプロジェクトが崩壊します。
私はPMOとして10年以上、複数プロジェクトの運用保守フェーズを見てきました。よくある3つの落とし穴があります。第1は属人化、特定のベテランメンバーだけがシステムの詳細を知っている状態です。このメンバーが休むと業務が止まる、退職すると全てが分からなくなる。第2はドキュメントの陳腐化、初期の設計書やマニュアルが更新されず、実態と乖離していく状態です。第3はクライアント要件の際限ない増加、断らずに全部対応してリリース済み機能が肥大化する状態です。現在の自動車保険案件でも、この3つの落とし穴を意識しながら、ナレッジ共有の仕組み、ドキュメント更新のルール、要件のトリアージ会議を運用しています。運用保守は3年5年と続く長期戦だからこそ、この基本を最初に整えることが重要だと痛感しています。
この経験から学んだのは、属人化は突然起きるのではなく、日々の小さな判断の積み重ねで進行していくということです。忙しいから、急いでいるから、この人なら早いから。そうした理由で同じ人に仕事が集中し、気づいたときには手遅れになっているんですよね。
落とし穴その2:ドキュメントが死んでいく瞬間
開発時に作成したドキュメントは、運用保守フェーズで急速に陳腐化します。小さな改修のたびに更新されるべきドキュメントが、実際には更新されない。その結果、ドキュメントと実態が乖離していきます。
私が担当している自動車保険システムでは、年間100件以上の小規模改修が発生します。その一つひとつでドキュメント更新を徹底しなければ、半年後にはドキュメントが使い物にならなくなります。実際、前任者から引き継いだ当初、設計書と実装が30%近く違っている状態でした。
ドキュメントが死ぬと、何が起きるか。新しいメンバーが参画しても戦力化できない、障害対応に時間がかかる、影響範囲が読めずリリースリスクが高まる。結局、実装を読むしかなくなり、さらに属人化が進むという悪循環に陥ります。
落とし穴その3:際限なく増える顧客要求
運用保守フェーズに入ると、顧客からの要求が加速度的に増えていきます。小さな改善要求、使い勝手の変更、新機能の追加。開発時には見えなかった課題が次々と浮上するのは自然なことですが、それをすべて受け入れていては現場が持ちません。
私が経験した金融系システムでは、運用保守開始から2年で当初契約の2倍の工数が必要になりました。原因は明確でした。顧客要求に対する判断基準がなく、すべてを受け入れてしまったのです。本来は別契約とすべき機能追加まで、運用保守の範囲として処理していました。
最も深刻だったのは、現場メンバーが疲弊していったことです。終わりの見えない要求対応に追われ、本来やるべき予防保全やリファクタリングに時間を割けない。技術的負債が積み上がり、さらに改修コストが増大するという負のスパイラルでした。
なぜ運用保守は同じ穴に落ちるのか
私が10年以上見てきた経験から言えるのは、これらの落とし穴は構造的な原因があるということです。個人の能力不足や努力不足ではなく、運用保守フェーズ特有の環境が生み出す必然的な問題なんですよね。
開発と運用保守のインセンティブ設計の違い
開発フェーズと運用保守フェーズでは、評価軸がまったく異なります。開発は納期とスコープが明確で、ゴールが見えます。しかし運用保守は終わりがなく、トラブルが起きなければ評価されにくい。この構造的な違いが、さまざまな問題を引き起こします。
属人化が進むのは、運用保守では即座に対応できることが評価されるからです。丁寧にナレッジを共有するより、自分で素早く対処したほうが感謝される。ドキュメント更新は直接的な成果として見えにくく、後回しにされます。顧客要求を断ることは、担当者レベルでは判断しづらく、結果的にすべて受け入れてしまいます。
私が見てきた多くのプロジェクトで、運用保守フェーズの評価基準が曖昧でした。何をもって良い運用保守とするのか、KPIをどう設定するのか。この議論が不十分なまま運用保守に入ると、現場は目の前の火消しに追われるだけになります。
予算とリソースの構造的不足
運用保守の予算は、往々にして不足しています。これは私が30年のキャリアで見てきた普遍的な課題です。開発時は潤沢な予算がついても、運用保守では大幅に削減される。経営層から見れば、新規開発は投資ですが運用保守はコストだからです。
| リソース不足のパターン | 典型的な状況 | 結果として起きること |
|---|---|---|
| 人員の量的不足 | 開発時の半分以下の体制で運用 | 属人化の加速、オーバーワーク |
| 人員の質的低下 | ベテランは次のプロジェクトへ異動 | 技術力不足、判断ミス増加 |
| 時間的余裕の欠如 | 日次対応に追われ改善時間なし | ドキュメント陳腐化、技術的負債蓄積 |
| ツール・環境への投資不足 | 開発時のツールがそのまま | 効率低下、ヒューマンエラー増加 |
この表が示すように、リソース不足は単なる量の問題ではありません。質的な低下、時間的余裕の欠如、環境整備の遅れなど、多層的に問題が発生します。そして最も厄介なのは、これらが相互に影響し合って悪化していくことです。
暗黙知の蓄積と移転の困難さ
システム運用で本当に重要な知識は、マニュアルには書かれていません。どの順序で作業すれば安全か、どこに地雷が埋まっているか、この顧客にはどう説明すればいいか。こうした暗黙知が、運用保守の現場には大量に蓄積されています。
私が金融系システムのPMOをしていたとき、ベテラン運用担当者の退職に直面しました。彼は15年間そのシステムを守ってきた人物で、引き継ぎ期間は3カ月設けました。しかし実際に引き継げたのは、彼が持っていた知識の30%程度だったと思います。残りの70%は、彼自身も言語化できない暗黙知だったんですよね。
運用保守では、この暗黙知の比率が開発フェーズより圧倒的に高くなります。なぜなら、実際に動いているシステムとユーザーの日常業務が密接に絡み合っているからです。その暗黙知を形式知化する作業は、想像以上に時間とコストがかかります。そして予算が限られた運用保守フェーズでは、その投資が後回しにされるのです。
現場で効く3つの実践的対策
理論的な解決策は誰でも語れます。しかし現場で本当に機能する対策は限られています。私が10年以上PMOとして試行錯誤してきた中で、実際に効果があった方法を紹介します。予算が潤沢でない中小企業でも実践できる、現実的なアプローチです。
属人化を防ぐ:ペアオペレーションの徹底
属人化を防ぐ最も効果的な方法は、ペアオペレーションです。すべての作業を2人体制で行うというシンプルなルールですが、これを徹底できているプロジェクトは驚くほど少ないんですよね。
私が現在担当している自動車保険システムでは、障害対応から定期メンテナンスまで、すべてをペアで実施するルールにしています。一方が作業し、もう一方が確認とドキュメント記録を担当する。最初は効率が悪いと反発もありましたが、3カ月後には明らかな効果が出ました。
作業時間は確かに1.5倍程度かかります。しかしミスが激減し、ナレッジが自然と共有され、誰かが休んでも業務が回るようになりました。長期的に見れば、圧倒的にコストパフォーマンスが高いアプローチだと確信しています。
ただし、ペアオペレーションを形骸化させないためには、明確なルール化が必要です。私たちのチームでは、ペアの組み合わせを週単位でローテーションし、必ずベテランと若手を組ませています。また、作業後には簡単な振り返りミーティングを5分だけ実施し、気づいた点を記録に残すようにしています。
生きたドキュメントを維持する:ノーコード化と自動生成
ドキュメントの陳腐化を防ぐには、更新コストを劇的に下げる必要があります。そのために私が推奨するのが、ドキュメント生成の自動化と、ノーコード化です。
具体的には、NotionやConfluenceのようなツールで、システム構成情報や運用手順を一元管理します。重要なのは、これらのツールとシステムの監視ツールやCI/CDパイプラインを連携させることです。例えば、システム構成が変更されたら自動的にドキュメントのテンプレートが更新される仕組みを作ります。
私のチームでは、AWS環境の構成情報をTerraformで管理し、その情報から自動的にNotionのシステム構成図を更新する仕組みを構築しました。完全自動ではありませんが、手動更新が必要な箇所を80%削減できました。残りの20%も、テンプレート化することで更新時間を大幅に短縮しています。
ドキュメント管理ツールの選定では、以下の観点が重要です。
| ツール名 | 特徴 | 向いているケース | コスト感 |
|---|---|---|---|
| Notion | 柔軟性が高く、APIで外部連携可能。検索性も良好 | 中小企業、スタートアップ。カスタマイズ重視 | 月額8ドル/人〜(無料プランあり) |
| Confluence | Jiraとの連携が強力。大規模組織での実績豊富 | 既にAtlassian製品を使っている組織 | 月額600円/人〜(10人以上) |
| Kibela | 日本製で日本語に強い。個人メモと共有メモを統合管理 | 日本企業。暗黙知の形式知化を重視 | 月額550円/人〜(5人以上) |
| GitHub Wiki | コードと同じリポジトリで管理。バージョン管理が強力 | 開発チーム主導の運用。技術ドキュメント中心 | 無料(GitHubの契約に含まれる) |
私が30年の経験から言えるのは、ツール選びより運用ルールの方が100倍重要だということです。どんなに高機能なツールでも、更新する文化がなければ死にます。逆に、シンプルなツールでも、チーム全員が更新する習慣があれば生き続けます。
顧客要求をコントロールする:3段階トリアージの実践
顧客要求の際限ない増加を防ぐには、明確な判断基準が必要です。私が実践しているのは、3段階トリアージという方法です。
まず、すべての要求を3つのカテゴリに分類します。第1段階は緊急対応が必要な障害や法令対応。第2段階は契約範囲内の改善要求。第3段階は契約範囲外の新機能追加や大規模改修です。
この分類を顧客と事前に合意しておくことが重要です。私のプロジェクトでは、運用保守契約の開始時に、この判断基準を含めたサービスレベル合意書を作成します。どこまでが運用保守の範囲で、どこからが別契約になるか。これを明文化しておかないと、後から必ず揉めます。
具体的には、工数ベースで判断基準を設けています。8時間以内で対応できる改修は運用保守の範囲、それを超える場合は別途見積もりという明確なラインです。ただし、この基準も柔軟に運用する必要があります。顧客の業務への影響度や、システムの重要度によって優先順位は変わるからです。
この3段階トリアージを実施してから、私のチームでは契約範囲外の作業が80%削減されました。顧客との関係も、むしろ良好になりました。なぜなら、何を優先すべきかが明確になり、期待値のコントロールができるようになったからです。曖昧な対応を続けるより、明確な基準で誠実に対応する方が、長期的には信頼関係が築けるんですよね。
30年現場にいた私が思うこと
運用保守フェーズは、プロジェクトの真価が問われる場面です。私は30年のキャリアで、華やかな新規開発よりも、地道な運用保守の方がはるかに難しいと痛感してきました。
開発は終わりが見えます。しかし運用保守は終わりがありません。その中で品質を維持し、コストをコントロールし、顧客満足を保ち続けるのは、想像以上に高度なマネジメントスキルが必要です。にもかかわらず、運用保守は軽視されがちです。予算は削られ、人員は減らされ、評価も低い。この業界の構造的な問題だと思います。
しかし、だからこそ運用保守で価値を出せる人材は貴重です。私自身、PMOとして運用保守フェーズに注力するようになってから、自分の市場価値が上がったと感じています。運用保守を極めることは、キャリアとしても正しい選択だと確信しています。
今回紹介した3つの落とし穴は、どのプロジェクトでも必ず現れます。しかし、それを予見し、事前に対策を打つことができれば、運用保守フェーズは恐れるものではありません。むしろ、システムの本当の価値を発揮できる、やりがいのあるフェーズになります。
もしあなたが今、運用保守で疲弊しているなら、まずペアオペレーションから始めてみてください。たった1つの作業からでもいいんです。2人体制で実施し、その効果を実感してください。小さな成功体験が、チーム全体の文化を変えていきます。私も最初は半信半疑でしたが、今ではペアオペレーションなしの運用保守は考えられません。
運用保守は地味ですが、確実に価値を生み出す仕事です。その価値を正しく評価し、適切に投資する組織が、長期的には強いシステムを持つことができます。30年の現場経験から、私はそう信じています。
コメント