運用保守PMOが語る、クライアント要件を制御する3つの視点

運用保守フェーズで起きる要件対応の現実

運用保守フェーズに入ると、開発時には想定していなかった要件が次々と舞い込んできます。クライアントからの要望は尽きることがなく、対応すればするほど新しい要件が生まれる。これは運用保守を担当する方なら誰もが経験する現実です。

私は現在も自動車保険システムの運用保守PMOとして、この課題に日々向き合っています。PJM-A資格を持つ実務家として30年間、多くの現場を見てきましたが、運用保守フェーズの要件対応ほど難しいものはありません。全てを受け入れるとチームが疲弊し、断ってばかりだとクライアントとの信頼関係が崩れる。このバランスをどう取るかが、運用保守PMOの腕の見せ所なんですよね。

私は現役PMOとして、自動車保険の運用保守現場でクライアント要件の制御に日々向き合っています。運用保守フェーズでは、クライアントから継続的に要件が発生します。業務効率化のための小さな改善要望から、法規制対応のための大きな改修まで、内容も規模もさまざまです。全て対応するとチームが疲弊し、断ってばかりだと信頼を失う。制御する3つの視点は、業務インパクト(対応しないとどうなるか)、システム影響(既存機能への影響度)、リソース制約(対応可能な工数)。この3つを整理してクライアントに提示することで、要件の優先順位を一緒に決められます。要件を断るのではなく、優先順位を一緒に決めるという姿勢が、長期的な信頼関係を作ると実感しています。

このような状況は、中小企業のIT担当者にとっても他人事ではありません。社内システムの運用を任されている方は、各部署から毎日のように要望を受けます。営業部からは顧客管理の機能追加、経理部からは帳票の変更、管理部からはセキュリティ強化の要請。どれも重要そうに見えるし、断れば社内の評価に響くかもしれない。そんな不安を抱えながら、限られたリソースで対応を続けているのが実情でしょう。

運用保守フェーズで発生する要件には、開発フェーズとは異なる特徴があります。開発時は要件定義という明確な工程があり、要件の全体像を把握してから作業に入れます。しかし運用保守では、日常業務の中で突発的に要件が発生し、しかもそれが途切れることがありません。朝のメールチェックで3件の要望、昼休み明けに緊急対応の依頼、夕方には次月対応の相談。これが毎日続くわけです。

さらに厄介なのは、クライアント側も自分たちの要望が全体の工数にどう影響するか理解していないことが多い点です。彼らにとっては、ちょっとした変更に見える。でも実際には、データベース構造の変更が必要だったり、複数の関連システムへの影響を調査しなければならなかったり、予想以上の工数がかかるケースは珍しくありません。

要件対応で現場が疲弊する3つのパターン

私が30年間で見てきた現場では、要件対応による疲弊が主に3つのパターンで現れます。

1つ目は、優先順位がつけられないまま全ての要件を受け入れてしまうパターンです。クライアントの機嫌を損ねたくない、社内評価を下げたくないという心理が働き、どんな要件も断れなくなる。結果として、開発チームのキャパシティを超えた作業が積み上がり、品質低下や納期遅延が常態化します。最悪の場合、チームメンバーが疲弊して離職につながることもあります。

2つ目は、逆に断りすぎて信頼を失うパターンです。工数やリソースの制約を理由に要件を断り続けると、クライアントは徐々に要望を出さなくなります。これは一見すると楽になったように見えますが、実際にはコミュニケーションが断絶し、本当に重要な問題が共有されなくなるという危険な状態です。運用保守は長期的な関係性の中で成り立つものですから、この状態は非常にまずい。

3つ目は、判断基準が属人化してしまうパターンです。ベテラン担当者の経験と勘で要件の可否を判断している状態。その人がいる間はうまく回りますが、異動や退職で判断できる人がいなくなった途端、現場は混乱します。中小企業では特にこのパターンが多く、IT担当者が1人しかいないような状況では深刻な問題になります。

制御できない状態が生み出す悪循環

要件を制御できない状態が続くと、現場には悪循環が生まれます。対応が遅れると催促が増え、催促が増えると焦って品質が落ち、品質が落ちると障害が増え、障害対応に時間を取られて要件対応がさらに遅れる。この負のスパイラルに一度入ると、抜け出すのは容易ではありません。

私自身、過去に金融系システムの運用保守で、この悪循環を経験したことがあります。当時は若手PMとして現場を任されていたのですが、クライアントからの要件を断る判断基準を持っていませんでした。結果として、チームのキャパシティを大きく超える作業を抱え込み、納期遅延と品質問題を同時に発生させてしまいました。その経験から学んだのは、要件を制御する明確な判断軸が必要だということです。

制御できない状態のもう一つの問題は、本来優先すべき重要な要件が埋もれてしまうことです。声の大きいクライアントの要望や、単に依頼が早かった要件が優先され、システム全体の安定性やセキュリティといった本質的に重要な課題が後回しになる。これは長期的に見ると、システムの技術的負債を増やし、将来の大規模障害リスクを高めることにつながります。

要件が制御できなくなる構造的な原因

なぜ運用保守フェーズで要件が制御できなくなるのか。これには構造的な原因があります。30年間、多様な現場を見てきた経験から、その本質を整理してみます。

判断基準の不在という根本問題

最も大きな原因は、要件を評価・判断する明確な基準が組織に存在しないことです。開発フェーズでは要件定義書という形で要件の範囲が明文化されますが、運用保守フェーズではそういった文書がないケースが多い。あったとしても、運用保守の業務範囲を定義しているだけで、個別の要件をどう判断するかの基準までは書かれていません。

判断基準がないと、結局は担当者の主観や、その時の気分で判断が変わります。今日は時間があるから受け入れる、明日は忙しいから断る。そんな一貫性のない対応は、クライアントからの信頼を失うだけでなく、社内でも混乱を招きます。同じような要件なのに、Aさんは通してBさんは断る。そうなると、誰に相談すればいいのか分からなくなるわけです。

私が現在の自動車保険システムで実践しているのは、判断基準を言語化し、クライアントと共有することです。後ほど詳しく説明しますが、業務インパクト、システム影響、リソース制約という3つの視点で要件を評価し、その結果をクライアントに説明します。この基準があることで、私自身も判断に迷わなくなりましたし、クライアントも納得感を持って結果を受け入れてくれるようになりました。

見えないコストと見えるコストのギャップ

要件を出す側と受ける側で、コストの見え方が大きく異なることも問題を複雑にします。クライアントにとって、要件を出すコストはゼロです。メール1本、電話1本で要望を伝えられる。しかし、それを実現するためには、要件の調査、設計、開発、テスト、リリース作業という一連のプロセスが必要になります。

この見えないコストを可視化できていないことが、要件が際限なく発生する原因の一つです。クライアントは自分の要望がどれだけの工数を消費するか知らないまま、次々と要件を出します。悪気があるわけではなく、単に知らないだけなんですよね。

私が金融系システムで経験した事例では、クライアントから帳票に項目を1つ追加してほしいという要望がありました。彼らにとっては単純な追加に見えたのでしょう。しかし実際には、データベースの改修、帳票生成ロジックの変更、既存データとの整合性確認、関連する5つの帳票への影響調査が必要で、結果的に80人時の工数がかかりました。要件を出した担当者は、まさかそんなに大変だとは思っていなかったと後で言っていました。

運用保守特有の制約条件

運用保守フェーズには、開発フェーズにはない特有の制約条件があります。これを理解していないと、要件対応で無理が生じます。

制約条件	内容	要件対応への影響
稼働システムへの変更	本番環境で動いているシステムに手を入れる必要がある	影響範囲の調査に時間がかかり、テストも慎重に行う必要がある
限られたリリース機会	月次や四半期ごとなど、リリースタイミングが決まっている	緊急性の高い要件でも、次のリリース時期まで待つ必要がある
障害対応との競合	予定外の障害対応が優先される	計画していた要件対応が後回しになり、スケジュールが遅延する
固定化されたチーム体制	運用保守のチームは少人数で固定されていることが多い	開発のように一時的にメンバーを増やすことができない

この表が示すように、運用保守では様々な制約の中で要件対応を行わなければなりません。開発時のように、要件が増えたからチームを拡大するという選択肢は基本的にありません。決められたリソースの中で、どう優先順位をつけて対応するかが全てなのです。

さらに、運用保守フェーズでは品質に対する要求水準が開発時より高くなります。既に多くのユーザーが使っているシステムですから、変更によって障害を起こすわけにはいきません。テストやレビューに十分な時間を確保する必要があり、これが要件対応のリードタイムを長くする要因にもなっています。

クライアントとの関係性が判断を難しくする

運用保守で厄介なのは、クライアントとの長期的な関係性の中で要件対応を判断しなければならない点です。開発プロジェクトなら、契約で定義された範囲外の要件は追加費用を請求すればいい。しかし運用保守では、契約の範囲内なのか範囲外なのか曖昧なケースが多く、しかも長期的な関係を考えると強硬な態度も取りづらい。

私が自動車保険システムで対応しているクライアントとは、もう5年以上の付き合いになります。その中で、多少無理な要件でも対応してきたこともあれば、丁重にお断りしたこともあります。大切なのは、その判断が一貫した基準に基づいていて、クライアントが納得できる説明ができることです。関係性に甘えて判断を曖昧にすると、後々大きな問題になります。

要件を制御する3つの視点と実践手法

ここからは、私が現場で実践している要件制御の具体的な手法を紹介します。業務インパクト、システム影響、リソース制約という3つの視点で要件を評価し、優先順位を判断する方法です。

視点1:業務インパクトで本質的な重要度を測る

最初の視点は業務インパクトです。その要件が実現されないことで、クライアントの業務にどんな影響があるのかを評価します。ここで重要なのは、クライアントが言う重要度をそのまま受け入れるのではなく、客観的な業務影響を確認することです。

私が使っている評価の観点は次のようなものです。影響を受けるユーザー数、業務停止時間、金銭的損失、法令遵守への影響、顧客サービスへの影響。これらを具体的な数字や事実で確認していきます。例えば、帳票の見栄えを変更したいという要件があったとします。クライアントは重要だと言いますが、実際に業務が止まるわけではありません。こういった要件は優先度を下げて判断します。

一方で、データ集計の計算ロジックに誤りがあるという指摘は、たとえ小さな修正でも最優先で対応します。なぜなら、誤ったデータで業務判断が行われると、金銭的損失や顧客トラブルにつながる可能性があるからです。業務インパクトの本質は、システムが業務をどう支えているかを理解することにあります。

現在の自動車保険システムでは、保険料計算に関わる要件は必ず最優先で対応します。これは金銭に直結し、誤りがあれば顧客からの信頼を失うからです。一方、管理画面の操作性改善は、利用者が限られた社内ユーザーであり、業務停止にもつながらないため、優先度を下げて計画的に対応しています。

視点2:システム影響で技術的リスクを評価する

2つ目の視点はシステム影響です。要件を実現するために、システムのどの部分に変更が及ぶのか、それが他の機能にどう影響するのかを評価します。これは技術的な視点であり、システムアーキテクチャの理解が必要になります。

システム影響の評価では、変更箇所の数、影響を受ける関連機能、既存データへの影響、外部システムとの連携への影響、セキュリティへの影響といった観点で確認します。同じ機能追加でも、独立したモジュールで実現できるものと、基幹機能の改修が必要なものでは、リスクが全く違います。

私が金融系システムで経験した事例では、顧客情報の表示順序を変更するという要件がありました。画面上の見た目の変更なので簡単そうに見えましたが、調査したところ、この順序は複数の画面と帳票で共通的に使われているマスタデータの並び順に依存していました。変更すると15の画面と20の帳票に影響が及ぶことが分かり、結局120人時の工数がかかることが判明しました。

システム影響を正しく評価できないと、小さな変更のつもりが大規模な改修になったり、予期しない障害を引き起こしたりします。運用保守では稼働中のシステムに手を入れるわけですから、この評価を怠ると取り返しのつかないことになります。私自身、過去に影響範囲の評価を甘く見て、本番障害を起こした苦い経験があります。それ以来、システム影響の評価は必ず複数人でレビューするようにしています。

視点3:リソース制約で実現可能性を判断する

3つ目の視点はリソース制約です。どんなに重要で技術的に実現可能な要件でも、対応するリソースがなければ実現できません。チームのキャパシティ、スキル、スケジュール、予算といった制約条件の中で、本当に対応できるのかを判断します。

リソース制約で特に重要なのは、単純な工数だけでなく、対応できる人のスキルとタイミングです。例えば、データベースの構造変更が必要な要件の場合、その作業ができるメンバーが限られていることがあります。そのメンバーが別の作業で埋まっていれば、いくら工数的に余裕があっても対応できません。

私が現在の運用保守で実践しているのは、チームのキャパシティを可視化することです。月単位で、各メンバーの稼働予定、障害対応の予備工数、計画メンテナンスの工数を差し引いて、新規要件に割ける工数を算出します。この数字を基に、要件の優先順位をつけてスケジュールに組み込んでいきます。

リソース制約は、クライアントに要件の延期や見送りを説明する際の重要な根拠にもなります。単に忙しいからできないと言うのではなく、現在のリソース状況を具体的に示し、どのタイミングなら対応できるかを提案する。これができると、クライアントも納得して待ってくれることが多いです。

3つの視点を組み合わせた判断マトリクス

実際の要件対応では、この3つの視点を組み合わせて総合的に判断します。私が使っている判断マトリクスを紹介します。

業務インパクト	システム影響	リソース制約	判断の方向性	対応方針
高(業務停止リスク)	低(限定的な変更)	低(対応可能)	最優先で対応	即座にスケジュールに組み込み、次回リリースで対応
高(業務停止リスク)	高(広範囲な変更)	高(リソース不足)	段階的対応を検討	暫定対応と恒久対応に分け、まず業務を止めない措置を優先
中(業務効率化)	低(限定的な変更)	低(対応可能)	計画的に対応	優先順位をつけて、2〜3ヶ月先のリリースで対応
中(業務効率化)	高(広範囲な変更)	高(リソース不足)	費用対効果を再検討	本当に必要か、別の解決策はないかをクライアントと協議
低(要望レベル)	低(限定的な変更)	低(対応可能)	積極的に対応	小さな改善の積み重ねは信頼関係構築に有効
低(要望レベル)	高(広範囲な変更)	高(リソース不足)	丁重にお断り	コストとリスクに見合わないことを説明し、代替案を提示

このマトリクスはあくまで判断の方向性を示すものであり、実際には個別の状況を考慮して判断します。重要なのは、判断の軸を持ち、それをクライアントと共有することです。クライアントに対して、なぜその判断をしたのか、どういう基準で評価したのかを説明できることが、信頼関係を維持する上で非常に重要です。

要件管理を支援するツールの選び方

要件を制御するためには、判断の視点だけでなく、要件を記録・追跡・管理するツールも必要です。ここでは私が実際に使ってきた、または検討したツールを紹介します。ツール選びで重要なのは、多機能さではなく、チームが継続的に使い続けられるシンプルさです。

まず、中小企業で最も導入しやすいのはBacklogです。私が以前のプロジェクトで使った経験では、課題管理の機能がシンプルで、ITに詳しくない人でもすぐに使えました。要件ごとに優先度、期限、担当者を設定でき、ガントチャートでスケジュール管理もできます。月額数千円から使えるので、予算が限られた中小企業でも導入しやすい。クライアントにもアカウントを発行して、要件の進捗を共有することで、無用な問い合わせが減りました。

より本格的な要件管理が必要なら、Jiraをお勧めします。私が現在の自動車保険システムで使っているのがこのツールです。カスタムフィールドで独自の評価項目を追加でき、先ほど説明した業務インパクト、システム影響、リソース制約といった評価結果を記録できます。ワークフローも柔軟に設定できるため、要件の承認プロセスをシステム化できます。ただし、設定が複雑で、使いこなすには学習コストがかかるのが難点です。専任のIT担当者がいる企業向けですね。

もっとシンプルに始めたいなら、Trelloでも十分です。カンバン方式で要件を管理でき、視覚的に分かりやすい。要件受付、評価中、対応中、完了といったステータスをボードで管理できます。無料プランでも基本機能は使えるので、まず要件管理の仕組みを作ってみたいという企業には良い選択肢だと思います。私の経験では、5人以下のチームならTrelloで十分運用できました。

ツール名	主な特徴	向いている企業	月額コスト目安
Backlog	日本製でシンプル、課題管理とガントチャートが一体	ITに詳しくないメンバーがいるチーム	2,970円〜
Jira	高度なカスタマイズ可能、大規模プロジェクト対応	専任IT担当者がいる中堅企業以上	900円/ユーザー〜
Trello	カンバン方式で直感的、無料プランあり	小規模チーム、要件管理を始めたい企業	0円〜(有料は5ドル/ユーザー)
Notion	データベース機能で柔軟な管理、ドキュメントと統合	要件管理と文書管理を一元化したい企業	0円〜(有料は8ドル/ユーザー)

ツール選びで私が重視するのは、継続性です。どんなに高機能でも、入力が面倒で誰も使わなくなったら意味がありません。チームの習熟度、運用に割ける時間、予算を考慮して、現実的に使い続けられるツールを選ぶことが大切です。私の経験では、最初はシンプルなツールから始めて、運用が定着してから高機能なツールに移行するのが成功パターンです。

30年現場にいた私が思うこと

要件を制御するというテーマで記事を書いてきましたが、最後に私の本音を書きたいと思います。30年間、様々な現場で要件対応に向き合ってきて、最近強く感じるのは、要件管理は技術の問題ではなく、人間関係の問題だということです。

どんなに優れた判断基準を作っても、どんなに便利なツールを導入しても、クライアントと信頼関係がなければうまくいきません。要件を断るという行為は、相手の期待に応えないということですから、そこには必ず感情的な摩擦が生じます。その摩擦を乗り越えられるのは、日頃からの信頼関係だけです。

私が自動車保険システムで5年以上クライアントと良好な関係を維持できているのは、要件対応の技術が優れているからではなく、正直にコミュニケーションを続けてきたからだと思っています。できないことはできないと伝え、その代わりにできることを提案する。約束したことは必ず守る。そういった基本的なことの積み重ねが、信頼を作るのです。

もう一つ、現場にいて感じるのは、完璧な制御を目指す必要はないということです。全ての要件を理想的に判断し、完璧なスケジュールで対応するなんて、現実には不可能です。時には間違った判断もするし、予期しない障害で計画が崩れることもあります。大切なのは、そういう時にどう立て直すか、どうクライアントに説明するかです。

私がPJM-A資格を取得したのも、完璧なマネジメントを目指したからではなく、自分の判断に理論的な裏付けが欲しかったからです。資格の勉強を通じて、自分が経験的にやってきたことが、理論的にも正しかったと確認できました。同時に、理論だけでは現場は動かないことも再認識しました。

中小企業のIT担当者の方に伝えたいのは、まず小さく始めてくださいということです。いきなり完璧な要件管理の仕組みを作ろうとしても、たぶん続きません。まずは、次に来る要件を1つ、今日紹介した3つの視点で評価してみてください。業務インパクトはどうか、システム影響はどうか、リソース的に対応できるか。この3つを確認するだけで、判断の精度は格段に上がります。

そして、その判断理由を要件を出した人に説明してください。なぜ優先度が高いのか、なぜ今は対応できないのか、いつなら対応できるのか。この説明を丁寧に続けることで、相手はあなたの判断を信頼するようになります。信頼ができれば、無理な要件を出されることも減りますし、本当に重要な要件に集中できるようになります。

運用保守の要件対応は、終わりのないマラソンです。完璧なゴールはありません。でも、走り続けるための工夫はできます。私が30年走り続けてこられたのは、完璧を目指さず、改善を続けてきたからです。あなたも、今日から始められる小さな改善を見つけて、実践してみてください。その積み重ねが、1年後、3年後の現場を大きく変えるはずです。