運用フェーズの体制: 社内と開発会社の役割分担

システムが無事にリリースされ、大きなトラブルもなく数週間が過ぎた。開発会社との定例ミーティングも終わり、プロジェクトチームは解散し、あとは「運用」というフェーズに入った——はずだった。ところが、いざ日々の業務が回り始めると、妙な違和感がつきまとうようになる。ちょっとした操作ミスでエラーが出たとき、自分で直せばいいのか、開発会社に連絡すべきなのか判断がつかない。半年後に法改正で仕様変更が必要になったとき、それは保守費の範囲内で対応してもらえるのか、追加見積もりになるのか分からない。何かあったときに「まず誰に連絡すればいいか」を書いたメモすら、社内のどこにも存在しない。

これは、システム開発プロジェクトが「作る」フェーズから「動かし続ける」フェーズに切り替わるタイミングで、非常に多くの担当者が直面する問題です。開発フェーズでは、要件定義・設計・実装・検収という明確な工程があり、その都度「今何をすべきか」が比較的はっきりしています。ところが運用フェーズに入った途端、その明確さが失われます。日常的な操作は社内で完結できるのか、障害が起きたら誰が一次対応するのか、法改正やOSアップデートへの追随は誰の責任なのか——こうした問いに答える「役割分担表」を、リリース前に作っていなかったプロジェクトは驚くほど多いのが実情です。

この記事では、運用フェーズに入ったシステムについて、社内(自分)と開発会社の間でどこまでを誰が担当すべきかを整理する考え方と、実際に役割分担を明文化する具体的な手順を解説します。すでに運用が始まってしまっていて役割分担が曖昧なまま進んでいる方にも、これから運用フェーズを迎える方にも、両方に使える内容です。

この記事で分かること

運用フェーズの役割分担を考える際に押さえておくべき視点と、実務での整理手順をまとめます。具体的には、なぜ運用フェーズで役割分担が曖昧になりやすいのか、社内で担うべき業務と開発会社に委ねるべき業務をどう線引きするか、障害発生時の一次対応と窓口をどう決めるか、そして役割分担を「口約束」で終わらせず文書として残す方法までを扱います。すでに保守契約を結んでいる方は、契約書に書かれている内容と実際の運用実態にズレがないかを確認する材料としても活用できます。

なぜ運用フェーズで役割分担が曖昧になるのか

結論から言うと、開発プロジェクトの多くは「作ること」に最適化されて進行するため、「作り終えたあとどう動かすか」の設計が後回しになりがちです。要件定義や設計のフェーズでは、発注者と開発会社が密にコミュニケーションを取り、仕様書やドキュメントも整備されます。しかし、リリースが近づくにつれてプロジェクトの関心は「予定通りに動くものが出来上がるか」に集中し、「出来上がったあと、誰がどう維持していくか」という論点は優先順位が下がっていきます。

さらに厄介なのは、開発フェーズと運用フェーズでは、発注者と開発会社の間に必要なコミュニケーションの質がまったく異なるという点です。開発フェーズでは、要件定義の段階で決めた仕様に沿って進捗を確認する定例ミーティングが機能します。ところが運用フェーズに入ると、日々発生するのは「ちょっとした操作方法の確認」「エラーメッセージの意味が分からない」「特定のデータだけ表示がおかしい」といった、細切れで頻度の高い問い合わせです。この性質の違うコミュニケーションに、開発フェーズの延長線上の体制のまま臨もうとすると、どこかで齟齬が生まれます。

運用フェーズとは、システムが本稼働を開始し、日常的な利用・保守・改善が継続的に行われる段階を指します。開発フェーズが「決められた期間内に完成させる」プロジェクト型の活動であるのに対し、運用フェーズは終わりの定まらない継続的な活動である点が本質的に異なります。

この「終わりが定まらない」という性質こそが、役割分担を曖昧にする最大の要因です。開発プロジェクトには納期があり、検収という明確な区切りがあります。しかし運用には区切りがありません。区切りのない継続的な関係だからこそ、誰が何をするかを最初に決めておかないと、なし崩し的に「困ったときは開発会社に何でも聞く」という状態に流れ着きやすくなります。それ自体が即座に問題になるわけではありませんが、依頼が積み重なるにつれて、本来は保守費の範囲外だったはずの作業まで無償で対応してもらう関係が常態化し、ある日突然「その対応は追加費用になります」と言われて驚く、という展開につながりやすいのです。

役割分担が曖昧なまま進むとどうなるか

役割分担が明文化されないまま運用が続くと、具体的にどのような問題が起きるのでしょうか。よくあるパターンを整理すると、次のようなものが挙げられます。

• 依頼のたびに「これは保守範囲内か」を確認する手間が発生する: 都度確認が必要になり、対応スピードが落ちる
• 社内でできることまで開発会社に依頼してしまう: 本来は自社で対応可能な設定変更やデータ修正まで依頼し、余計な待ち時間とコストが発生する
• 障害発生時に誰が一次対応するか決まっておらず、初動が遅れる: 「まず自分たちで確認すべきか、すぐ連絡すべきか」の判断に時間を取られる
• 開発会社の担当者が変わったときに、暗黙の役割分担が引き継がれない: 属人的に成立していた合意が、担当者交代を機に失われる
• 法改正やOSアップデートなど「誰も気づかない責任の隙間」が放置される: 誰の担当か決まっていない作業は、誰も着手しないまま時間だけが過ぎる

これらの問題に共通するのは、個々の事象は小さくても、積み重なると「開発会社との関係がなんとなくギクシャクする」「毎回のやり取りに消耗する」という慢性的な状態につながっていく点です。役割分担の曖昧さは、一度に大きな損害をもたらすというより、じわじわと関係の質を下げていくタイプの問題だと理解しておくとよいでしょう。

なお、担当者の異動や退職で属人化した引き継ぎが崩れるリスクについては、社内側の体制整備として別の観点からも整理しておく必要があります。この記事では開発会社との役割分担に焦点を当てますが、社内での情報整理も並行して進めることをおすすめします。

社内が担うべき業務、開発会社に委ねるべき業務

役割分担を考えるときにまず整理したいのは、業務を「誰が実行できるか」ではなく「誰が実行すべきか」という基準で分類することです。技術的には開発会社にしかできない作業もあれば、技術的には可能でも社内で対応した方が効率的な作業もあります。この2軸を混同すると、線引きがぶれやすくなります。

一般的に、社内側で担うのが妥当とされやすい業務には次のようなものがあります。

一方、開発会社に委ねるのが妥当な業務には次のようなものがあります。

このように整理すると、線引きの基準は「業務知識が必要か、技術知識が必要か」という点にあることが見えてきます。業務知識が主に必要な作業は社内側、技術知識・システム内部構造の知識が主に必要な作業は開発会社側、というのが大まかな原則です。ただし、この原則はあくまで出発点であり、実際には契約内容やSOW（作業範囲記述書）に明記された範囲によって最終的な線引きが決まります。原則と契約内容にズレがある場合は、契約内容が優先されると考えておくのが安全です。

障害発生時の一次対応と窓口をどう決めるか

平時の役割分担以上に重要なのが、障害発生時の対応フローです。システムが止まった、あるいは異常な挙動をしている、というのは業務への影響が最も大きい場面であり、ここで「誰にどう連絡すればいいか分からない」という状態が最も避けたい事態です。

障害対応の役割分担を考える際は、次の3つの問いに答えられる状態を目指してください。

1. 誰が最初に気づき、誰が一次判断するか: 利用者からの報告を受けた社内担当者が、まず自分たちで確認できる範囲(ネットワーク障害、単純な操作ミスなど)を切り分けられるようにしておく
2. どの窓口に、どのような情報を添えて連絡するか: 開発会社の連絡先が複数ある場合、緊急時にどの窓口を使うべきかを明確にしておく。発生日時・症状・影響範囲・再現手順をあらかじめテンプレート化しておくと、連絡のたびに情報が抜け落ちるのを防げる
3. 対応時間の目安はどの程度か: 開発会社の保守契約にSLA（サービス品質保証）が定められている場合、平日日中と休日夜間で対応時間が異なることが一般的です。契約書に明記された対応時間の目安を、社内の関係者にも共有しておく

障害対応で特に注意したいのは、「単一障害点」の存在です。特定のサーバーやサービスが停止すると業務全体が止まってしまうような構成になっていないか、平時のうちに把握しておくことは、障害発生時にどこまでの範囲を確認すべきかを判断する材料になります。単一障害点の洗い出し自体は開発会社に依頼できる作業ですが、「洗い出した結果、どこまでのリスクを許容するか」は経営判断を伴うため、社内側が主体的に関わるべき領域です。

エスカレーションとは、現場レベルでの対応では解決が難しい問題について、より上位の権限を持つ担当者や責任者に判断や対応を引き上げることを指します。障害対応においては、一次対応で解決しない場合に、いつ・誰に・どのようにエスカレーションするかをあらかじめ決めておくことが重要です。

エスカレーションという言葉は大げさに聞こえるかもしれませんが、要は「現場の窓口担当者同士のやり取りで解決しない場合に、次にどう動くか」を事前に決めておくというだけのことです。障害の影響範囲が大きい、対応が長時間止まっている、説明に一貫性がないといったサインが重なった場合は、早めに双方の上位者を交えた場を設定する方が、結果的にスムーズに解決に向かいやすくなります。

実際の運用の中では、次のような場面でエスカレーションの判断を迫られることがあります。

• 障害発生から数時間経っても復旧の見込みが示されない
• 「原因調査中です」という説明が数日にわたって変わらない
• 同じ不具合が短期間のうちに繰り返し発生している
• 一次対応の窓口担当者では判断できない、契約範囲や追加費用に関わる論点が絡んでいる

これらのサインが1つ単独で出ているだけであれば、まずは窓口レベルでのやり取りを続けても構いません。しかし複数のサインが重なっている場合は、社内側から「そろそろ双方の責任者を交えて状況を整理させてください」と切り出すことを避ける理由はありません。エスカレーションは、開発会社との関係を壊す行為ではなく、プロジェクトを正常な軌道に戻すための正当な手段だと捉えておくとよいでしょう。

法改正・OSアップデートなど「定期的に発生する対応」の担当を決めておく

運用フェーズの役割分担で見落とされやすいのが、障害のような突発的な事象ではなく、あらかじめ発生することが分かっている定期的な対応です。代表的なものとしては、次のようなものが挙げられます。

• 法改正に伴う仕様変更(インボイス制度対応、税率変更、個人情報保護関連の制度変更など)
• OSやミドルウェアのサポート終了に伴うアップデート対応
• 利用しているクラウドサービスやライブラリの仕様変更への追随
• セキュリティ上の脆弱性が発見された際のパッチマネジメント

これらは、障害のように「起きてから慌てて対応する」性質のものではなく、事前に予測できるという点で通常の障害対応とは異なります。しかし実務上は、「誰かが気づいて動き出さない限り、何も起こらない」という点で、放置されるリスクは障害以上に高いとも言えます。障害であれば利用者からの報告という形で強制的に顕在化しますが、法改正やOSアップデートは、誰も気にかけていなければ、対応期限が過ぎるまで静かに放置されてしまいます。

この種の対応については、次の2点を役割分担表に明記しておくことをおすすめします。

1. 情報収集の担当: 法改正やサポート終了の情報を、誰が(社内か開発会社か)キャッチアップする責任を持つか。多くの場合、技術的な情報(OSやミドルウェアのサポート終了時期など)は開発会社が把握しやすく、業務に関わる制度変更(税制や労務関連など)は社内側が把握しやすい傾向があります
2. 対応要否の判断と実施の担当: 情報を把握したあと、実際に対応が必要かどうかの判断、そして対応作業そのものを誰が行うか

特に、情報収集の担当を決めずに運用を続けると、「開発会社は言われれば対応するが、自分たちから能動的に教えてくれるとは限らない」という状況に陥りがちです。これは開発会社の怠慢というより、契約上「言われた作業を行う」という前提で保守契約が結ばれているケースが多いためです。能動的な情報提供まで期待するのであれば、その旨を契約時に明記しておくか、運用フェーズに入ったタイミングで改めて開発会社と合意しておく必要があります。

運用フェーズの定例(振り返り)をどう設計するか

開発フェーズには進捗確認のための定例ミーティングがありますが、運用フェーズに入るとこの定例が自然消滅してしまうケースが少なくありません。しかし、役割分担を「作って終わり」にせず機能させ続けるためには、運用フェーズにおいても一定の頻度で振り返りの場を持つことが有効です。

運用フェーズの定例は、開発フェーズの定例とは目的が異なります。開発フェーズの定例が「予定通りに進んでいるかの確認」であるのに対し、運用フェーズの定例は「役割分担が実態に合っているかの確認」が主な目的になります。頻度は月1回から四半期に1回程度で十分な場合が多く、議題としては次のようなものが考えられます。

このような定例を設けておくと、役割分担表が「作った時点で終わり」の静的な文書ではなく、運用の実態に合わせて継続的に更新されていく生きた文書として機能するようになります。逆に、この振り返りの場がまったくないまま数年が経過すると、役割分担表そのものの存在が忘れ去られ、結局は個々のやり取りの中でその都度判断するという、当初の曖昧な状態に逆戻りしてしまいます。

役割分担が崩れやすい典型的な場面

役割分担をきちんと決めていても、特定のタイミングで実態とのズレが生じやすいことが知られています。あらかじめ知っておくと、注意すべきタイミングを予測しやすくなります。

• 開発会社の担当者交代のタイミング: 前任の担当者との間にあった暗黙の了解が、新しい担当者には伝わっていないことがある。担当者交代の連絡を受けたら、役割分担表を改めて共有し、認識をすり合わせる機会を作ることをおすすめします
• 社内の担当者交代のタイミング: 逆に社内側の担当者が交代する場合も同様で、後任者が役割分担の経緯を知らないまま引き継ぐと、開発会社に対して過剰に遠慮した対応になったり、逆に契約範囲を超えた依頼を無自覚に行ってしまったりすることがあります
• 大規模な改修が入ったタイミング: 追加開発やリニューアルが行われると、システムの構成そのものが変わり、従来の役割分担表が実態と合わなくなることがあります。大きな改修が完了したタイミングでは、役割分担表も合わせて見直す習慣をつけておくとよいでしょう
• 保守契約の更新タイミング: 保守契約の内容が更新される際、対応範囲やSLA(サービス品質保証)の内容が変わることがあります。契約更新時には、役割分担表の内容が新しい契約内容と整合しているかを必ず確認してください

役割分担を文書として残す

ここまで整理してきた役割分担の考え方は、口頭やその場の合意だけで済ませてしまうと、時間の経過とともに形骸化していきます。特に、開発会社側の担当者が異動・退職で交代した場合、「以前の担当者とはこういう暗黙の了解があった」という情報は引き継がれないことが少なくありません。役割分担は、必ず文書として残すことをおすすめします。

文書化する際に最低限盛り込みたい項目は次の通りです。

• 業務カテゴリごとの担当区分: 前述の表のように、業務を分類し、社内担当か開発会社担当かを一覧化する
• 保守契約でカバーされる範囲との対応関係: 保守契約書や保守契約に記載された対応範囲と、実際の役割分担表が矛盾していないかを確認する
• 障害発生時の連絡フロー: 誰が、どの窓口に、どのような情報を添えて連絡するかのフローチャートまたは手順書
• エスカレーションの基準と連絡先: どのような状態になったら上位者を交えるか、その際の連絡先
• 見直しのタイミング: 半年に一度、あるいはシステムに大きな変更があったタイミングで役割分担表を見直す旨をあらかじめ決めておく

この文書は、凝った形式である必要はありません。1枚のスプレッドシートや簡単なドキュメントで十分です。重要なのは、内容の精緻さよりも「実際に存在し、関係者が参照できる状態になっていること」です。せっかく作っても、担当者のパソコンの中に埋もれたままでは意味がありません。社内の誰もがアクセスできる場所に置き、開発会社とも共有しておくことで、双方が同じ前提に立って日々のやり取りができるようになります。

マルチベンダー体制の場合の追加の注意点

システムによっては、開発を担当する会社とインフラを管理する会社が別、あるいはアプリケーションごとに異なる開発会社が関わっているというケースもあります。このようなマルチベンダー体制の場合、役割分担の整理はさらに重要度が増します。

単一の開発会社と付き合う場合は、「社内 対 開発会社」という単純な二項対立で役割分担を考えられます。しかし複数のベンダーが関わる場合、「このシステムの不具合は、A社の担当かB社の担当か」という問題が新たに発生します。障害発生時に、まず社内側が一次切り分けを行い、どのベンダーに連絡すべきかを判断する役割を担わなければならない場面が増えるため、平時からシステム構成とベンダーの担当範囲の対応関係を整理しておく必要性が高まります。

マルチベンダー体制における役割分担の整理は、単一ベンダーの場合よりも手間がかかりますが、その分、特定の1社に依存しすぎない体制を作れるという利点もあります。マルチベンダー体制そのもののメリット・デメリットについては、別記事で詳しく扱っていますので、体制そのものを見直す検討をしている方はあわせて参考にしてください。

内製化を進める場合の役割分担の変化

運用フェーズが長く続くと、「この作業は毎回開発会社に依頼するより、社内で対応できるようにした方がよいのではないか」と感じる場面も出てきます。これは内製化とアウトソースの境界線をどこに引くかという、より大きな経営判断につながる論点です。

内製化を検討する際の判断材料としては、次のような観点が参考になります。

• 頻度: 頻繁に発生する作業ほど、社内対応のメリットが大きい
• 難易度: 専門的な技術知識を必要としない作業ほど、社内対応に切り替えやすい
• リスク: 誤操作時の影響範囲が小さい作業ほど、社内対応に切り替えやすい
• コスト: 開発会社への都度依頼のコストと、社内で対応できる体制を整えるコストを比較する

ただし、内製化はあくまで選択肢の一つであり、すべての作業を内製化することが目指すべきゴールというわけではありません。むしろ重要なのは、「今この作業は社内と開発会社のどちらが担っているか」を常に把握できている状態を保つことです。役割分担が明文化されていれば、内製化を検討する際にも、どの業務から着手すべきかを判断しやすくなります。

小規模組織ならではの制約とどう向き合うか

ここまで紹介してきた考え方は、専任の情報システム部門がある大企業であれば、比較的取り入れやすい内容です。しかし、ひとり情シスや総務・経理の兼任担当者としてシステムを見ている立場からすると、「役割分担表を作る時間も、定例の振り返りを毎月行う余裕もない」というのが正直なところかもしれません。

その場合は、すべてを一度に完璧に整えようとせず、優先順位をつけて着手することをおすすめします。特に優先度が高いのは、次の2点です。

1. 障害発生時の連絡フローだけは先に決める: 役割分担全体を整理する時間がなくても、「システムが止まったとき、誰に、どうやって連絡するか」だけは最低限決めておくと、いざというときの被害を大きく減らせます
2. 保守契約書に記載された対応範囲を、一度だけでも読み込む: 日々の業務の中で契約書を読み返す機会は少ないものですが、運用フェーズに入った直後に一度目を通しておくだけでも、「これは範囲内か範囲外か」を都度確認する手間が減ります

すべてを一度に整備する必要はありません。まずは最も影響の大きいリスク(障害発生時の初動の遅れ)から手をつけ、余裕ができたタイミングで平時の役割分担表や定例の振り返りへと範囲を広げていく、という段階的なアプローチでも十分に効果があります。完璧な体制を最初から目指すよりも、「何もない状態」から「最低限のフローがある状態」へと一歩進めることの方が、実務上のリスク低減としては大きな意味を持ちます。

まとめ

運用フェーズにおける社内と開発会社の役割分担は、開発フェーズが終わった時点で自動的に決まるものではなく、意図的に整理し、文書として残さなければ曖昧なまま放置されがちな論点です。この記事で紹介した考え方を振り返ると、次のようになります。

• 運用フェーズは開発フェーズと違い「終わりが定まらない」性質を持つため、役割分担を最初に決めておかないと、なし崩し的な依頼の積み重ねにつながりやすい
• 業務知識が主に必要な作業は社内、技術知識・システム内部構造の知識が主に必要な作業は開発会社、という原則を出発点にしつつ、最終的には契約内容に基づいて線引きする
• 障害発生時は、誰が一次判断するか、どの窓口にどう連絡するか、対応時間の目安はどの程度かをあらかじめ明確にしておく
• 役割分担は口約束ではなく文書として残し、社内・開発会社の双方が参照できる状態にしておく
• マルチベンダー体制や内製化の検討など、体制が複雑になるほど役割分担の明文化の重要性は増す

すでに運用が始まっていて、役割分担が曖昧なまま進んでしまっているという方は、まず今かかえている保守契約書を開き、記載されている対応範囲と、実際の日々のやり取りにズレがないかを確認するところから始めてみてください。次の記事では、月額保守費で実際にどこまでの作業をカバーしてもらえるのかを、契約書の読み解き方も含めて詳しく解説していますので、あわせてご覧ください。