保守運用が「無法地帯」になる4つの構造
なぜ保守運用はこんなに散らかるのか。現場で何度も同じパターンを見てきたので、構造として書きます。
一番の元凶は、問い合わせの入口がバラバラなことです。あるクライアントは担当者の個人メールに直接送ってくる。別のクライアントはSlackの共有チャンネルに書く。急ぎのときは電話が鳴る。社内では「あの件どうなった?」が口頭で飛んでくる。入口が散らばっていると、まず「いま何件の対応が走っているか」すら誰も正確に言えません。受けた本人が忘れたら、その問い合わせはこの世から消えます。実際、私が見てきた取りこぼしの大半は、技術的に難しかったからではなく、単に「誰かの受信トレイで埋もれた」だけでした。
次に、障害対応と新規開発が同じ人に積み上がる問題です。本番で障害が起きたら、当然そっちが最優先になります。でも、その人はたいてい別の新規案件の主力でもある。障害が長引けば新規のスケジュールが後ろにずれて、そっちのクライアントにも迷惑がかかる。一人のエンジニアの中で、緊急の保守と締め切りのある開発が殴り合いをしている状態です。これを「気合いで両方やる」で乗り切ろうとすると、その人が倒れた瞬間に両方止まります。
三つ目が、対応履歴が個人の頭の中にしか残らないことです。「この前のあのエラー、どう直したっけ」を、対応した本人に聞かないと分からない。本人が休みだと、誰も手が出せない。半年前に一度直した不具合が再発したとき、過去のやりとりがどこにも残っていなくて、ゼロから調査し直す——これ、保守の現場ではあるあるすぎて、もはや風物詩です。
最後に、契約の中身が現場に共有されていない、という地味だけど効いてくる問題があります。保守契約でどこまでを無償の範囲にしたのか、SLA（サービス品質の約束）で「障害は何時間以内に一次回答」と決めたのか。これを営業や経営が握っているだけで、実際に手を動かすエンジニアが知らないと、約束より遅れて怒られたり、契約外の改修をうっかりタダで引き受けたりします。保守の赤字は、たいていこの「契約と現場の断絶」から生まれます。
まず、問い合わせの入口を一本にする
散らかりを直す順番として、最初にやるべきは入口の一本化です。これをやらずに他の工夫をしても、そもそも何件あるか分からないので効果が測れません。
理想は、どのクライアントからどの経路で来た問い合わせも、最終的に一つの場所に集まることです。クライアントが送るのはこれまで通りメールでもチャットでもいい。ただ、受けた側で「すべて同じ受け皿に起票する」というルールだけは徹底する。電話で受けたものも、その場でメモして起票する。ここをサボると、電話案件だけが記録から消えます。
開発をやっている人なら、これはissueを立てる感覚に近いと言えば伝わると思います。バグ報告が口頭で来ても、まずissueを立ててから着手しますよね。それと同じことを、クライアントからの問い合わせでもやるだけです。「起票してから対応する」を文化にできるかどうかで、保守の見通しは大きく変わります。
入口を一本化すると、副産物として「どのクライアントから、どんな種類の問い合わせが、月に何件来ているか」が見えるようになります。これが見えると、「このクライアントは問い合わせが多すぎるので保守費用を見直すべき」とか、「この種類の不具合が頻発しているので根本対応したほうが安い」といった判断ができる。入口がバラバラだと、この経営判断の材料すら手に入りません。
障害・改修・問い合わせを、種類で分けて回す
入口を一本にしたら、次はそこに集まったものを種類で分けます。保守運用に来るものを全部「タスク」とひとくくりにすると、緊急の障害と「いつか直せばいい改修」が同じ列に並んで、優先順位がつけられなくなります。
ざっくり分けると、止まると困る障害、約束した期日のある改修、急がない問い合わせや要望、の三種類くらいになります。障害は今すぐ。改修は期日から逆算。要望は手が空いたとき。この区別を、頭の中ではなくボードの上でやるのが大事です。カンバンのようなボードで「未対応／調査中／対応中／確認待ち／完了」と並べておいて、それぞれのカードに種類のラベルを付ける。そうすると、朝ボードを見た瞬間に「今日は障害が一件あるから新規開発は午後に回そう」という判断が、一目でできます。
ここで効いてくるのが「確認待ち」という状態です。保守運用の対応は、こちらの作業が終わっても、クライアントの確認や本番反映のタイミング待ちで止まることが多い。これを「対応中」のまま放置すると、自分が抱えているように見えて精神的に重いし、逆に「完了」にしてしまうと反映漏れが起きます。手は離れているけど終わってもいない、というボールの所在をはっきりさせる列を作っておくと、「自分は動かしていないのに、なぜか自分の名前で止まっている」案件がなくなります。
新規開発と保守を、できれば同じボードの上で見られるようにしておくのも個人的におすすめです。別々のツールで管理していると、「保守で半日取られている」という事実が新規側のスケジュールに反映されません。同じ人が両方を抱えているなら、両方が同じ場所に並んでいたほうが、無理なアサインに気づけます。
属人化は「記録」で薄める
保守運用の属人化は、根性では絶対に解決しません。「ちゃんと引き継ぎましょう」と言っても、忙しい現場で引き継ぎ資料を別途作る余裕なんてない。属人化を薄める唯一の現実的な方法は、対応そのものを記録として残すことです。
具体的には二つあります。一つは、よくある障害や問い合わせへの対応手順を、ランブック（対応の手引き）としてまとめておくこと。「このエラーが出たら、まずこのログを見て、この設定を確認する」という、いつもやっている切り分けを文章にしておく。これがあると、対応した本人が休みでも、別のメンバーが一次対応に入れます。最初に書くのは面倒ですが、二回目以降の調査時間がまるごと浮くので、二、三回起きる不具合なら確実に元が取れます。
もう一つが、個別の対応で「なぜそう判断したか」を残すことです。単に「直しました」ではなく、「本番のデータがこうなっていたので、こう対処した。根本原因はおそらくこれで、別途改修が必要」という判断のログ。これを問い合わせの起票に紐づけて残しておくと、半年後に再発したときに、当時の自分（あるいは別の誰か）が文脈ごと思い出せます。コードのコミットログだけでは、「なぜそうしたか」までは追えないことが多いので、対応の記録は別に残す価値があります。
記録を残す文化は、書く人にメリットがないと続きません。だから「未来の自分の調査時間を減らすために書く」と捉え直すのがいいと思います。他人のためではなく、三カ月後に同じ問い合わせを受けて頭を抱える自分のために書く。そう考えると、ランブックを書く手が少し軽くなります。
ツールの率直な整理と、保守運用で起きる「分断」
保守運用をどう回すかは、使う道具にもよります。開発チームがよく使うものを、保守の観点で正直に並べます。
Backlogは、課題管理とGit連携、Wikiがバランスよく揃っていて、スタンダードプランが月13,000円ほど。人数が増えても料金が固定なのが中小チームには嬉しいところです。UIが素直で、非エンジニアのクライアントや営業も触りやすいので、「クライアントにも課題を見てもらう」運用がしやすい。保守の問い合わせを課題として起票して回すだけなら、Backlogでかなりのことができます。弱点を挙げるなら、本格的なインシデント管理やSLA管理の専用機能は薄いので、そこはルールでカバーする前提になります。
Jiraは、複数のスクラムチームが並行して動くような規模で本領を発揮します。保守運用に関して言えば、Jira Service ManagementとAI機能のRovoを組み合わせると、関連するアラートのグルーピング、重大インシデントの強調、対応に入った人向けの状況要約、ポストインシデントレビューの自動生成までやれる。ここまで来ると本格的なインシデント対応の道具です。ただ、Rovoの一部のAIエージェント機能はPremiumやEnterpriseが前提で、小さな受託チームには機能も料金も過剰になりがちです。10人で受託をやっているチームがJiraのフル装備を入れると、たいてい使いこなせずに持て余します。
Redmineは、オープンソースなので自前のサーバーで動かせば無料です。カスタマイズ性が高く、自社の保守フローに合わせて細かく作り込める。コストをかけずに自由度がほしい開発チームには根強い人気があります。ただ、無料なのはソフトウェアだけで、サーバーの構築と運用、アップデート、バックアップは全部自分たちの仕事です。保守運用の手間を減らしたくてツールを入れるのに、そのツール自体の保守運用が増える、という本末転倒が起きることもあるので、そこは正直に天秤にかけたほうがいいです。
問い合わせ対応に寄せると、ZendeskやFreshdeskのようなヘルプデスク専用ツールがあります。Zendeskはユーザーあたり月19,800円程度からで、AIによる自動回答まで含む上位プランはさらに上がります。メール・チャット・電話を一つの窓口に集約して、顧客チケットとして回すのは、これらの専用ツールが一番うまい。エンドユーザーが多いサービスの保守なら、検討の価値があります。
ここで保守運用ならではの分断が見えてきます。課題管理（Backlog・Jira・Redmine）は「開発タスクを回す」のが得意で、ヘルプデスク（Zendesk・Freshdesk）は「顧客の問い合わせを受ける」のが得意。でも保守運用では、その両方が地続きで起きます。クライアントから来た問い合わせ（ヘルプデスク側）が、調べてみたらバグで、改修タスク（課題管理側）になる。この受け渡しが別ツールをまたぐと、転記の手間が増え、どちらかで状態が止まる。問い合わせは「クローズ」になっているのに、紐づく改修タスクが放置されている、みたいなことが起きます。
AIに任せていい部分、任せると痛い目を見る部分
保守運用にもAIは入ってきています。これは開発側として日々触っていて、線引きがはっきりしている領域です。
任せていいのは、問い合わせの一次仕分けと要約です。長文のメールで「あれもこれも」と書かれた問い合わせを、論点ごとに分解して要約する。過去の似たような問い合わせを引っ張ってきて「これと同じ可能性があります」と示す。新しく対応に入る人向けに、これまでの経緯を三行でまとめる。こういう、人間がやると面倒だけど判断は要らない作業は、AIに任せて困りません。前述のJiraのRovoがやっているのも基本はこの線で、アラートをまとめたり、状況を要約したり、というところです。ここは素直に効率が上がります。
任せると痛い目を見るのは、原因の切り分けと、顧客への約束です。「このエラーの原因はこれです」とAIがそれらしく言っても、本番環境の固有の事情や、過去の改修の経緯まで踏まえた切り分けは、まだ人間がやらないと事故ります。AIの推測を検証せずに「原因はこれでした」とクライアントに報告して、後で全然違ったときの信頼の失い方は、効率化で浮いた時間では取り返せません。そして「いつまでに直します」という約束は、絶対にAIに代弁させてはいけない。それはこちらの責任とリソースの問題で、AIには判断できない領域です。
私の感覚だと、AIは保守運用において「一次受けと整理を速くする道具」であって、「対応を決める当事者」ではありません。問い合わせを仕分けて要約させるのはどんどんやればいい。でも、原因を断定して顧客に伝える最後の一歩は、人間が握っておく。ここを譲ると、効率化したつもりが、火消しのための謝罪対応で時間が倍に膨らみます。
LOGLIKEで保守運用フェーズを回すなら
ここで少しLOGLIKEの話を書きます。LOGLIKEは「案件も、校正も、請求も。すべてが一つに!」をコンセプトにしたプロジェクト管理ツールで、案件を主軸にして、その下にタスク・課題・コメント・請求がぶら下がる構造を持っています。保守運用の文脈で見ると、「問い合わせから対応、記録、月次請求までが同じ案件の上に集まる」のが効いてきます。
まず、クライアントから来た問い合わせを課題として起票して、ステータスを進めながら管理できます。カンバンボードは担当者別に表示してドラッグ&ドロップで動かせるので、「いま誰が、どの保守案件を、どれだけ抱えているか」がボードの上で見えます。障害も改修も要望も同じ課題として起票しておけば、新規開発の課題と保守の課題を同じ案件管理の中で並べられるので、「あの人は保守で手が埋まっている」という状況が新規側のアサインにも見えるようになります。
対応のやりとりは、課題に紐づくコメント・メンションで残せます。チャットと違うのは、「このエラー、本番のデータがこうだったのでこう対処した」という判断のログが、該当の課題に紐づいて消えずに残る点です。半年後に再発しても、その課題を開けば当時の経緯が文脈ごと出てくる。属人化を薄めるための「判断の記録」が、対応の流れの中で自然に溜まる構造です。さらにその知見をナレッジベースにまとめておけば、ランブックの置き場所になります。
長文の問い合わせや、保守の定例で話した内容は、AIと会議で議事録を整理し、AI課題生成で「次にやること」を課題として起こすところまで繋げられます。問い合わせの一次整理をAIに任せて、最後の判断は人間がやる、という線引きを保ったまま使えるわけです。対応の期日が近づいているのに止まっている課題は、AI予告通知が拾ってくれるので、SLAの一次回答期限を人力で見張らずに済みます。今すぐ手を付けられない要望はあとで対応に逃がしておけば、新規開発の集中を切らさずに受け止められます。
クライアントごとの保守契約や窓口の情報は顧客管理（CRM）に紐づけておけて、毎月の保守費用の請求書ファイルは請求書管理で案件の配下にまとめておけます。「どのクライアントの、いつの保守の請求か」が案件に紐づくので、月次の請求漏れが起きにくくなります。
正直に書いておくと、LOGLIKEは死活監視やインシデントの自動検知をする監視ツールではないし、メールを統合して顧客チケットを捌くヘルプデスク専用ツールでもありません。「障害をシステムが自動で検知する」「エンドユーザーからの大量の問い合わせを自動応答で捌く」といった用途は、Zabbixのような監視ツールやZendeskのような専用ツールの領域です。LOGLIKEの立ち位置は、検知やチケット化はそうした専用ツールに任せて、そこから先の「対応を案件として回し、記録を残し、月次の請求まで束ねる」ところ。検知と回す場所を分けて考えるのが、たぶん一番現実的です。あわせて補足すると、請求書管理は請求書を発行する機能ではなく、完了した課題に紐づく請求書ファイルを案件配下で管理する機能です。ここは誤解されやすいので書いておきます。
まとめ：保守は「片手間」ではなく、設計して回すもの
保守運用が消耗戦になるのは、エンジニアの能力が足りないからではありません。問い合わせの入口が散らばり、障害と新規開発が同じ人に積み上がり、対応履歴が個人の頭にしか残っていない——この構造を放置したまま、気合いで回そうとするからです。
直す順番ははっきりしています。まず問い合わせの入口を一本にして、何件走っているかを見えるようにする。次に、来たものを障害・改修・要望に分けて、ボードの上で優先順位をつける。そして、対応の手順と判断をランブックや課題のログとして残し、属人化を薄める。AIには一次仕分けと要約を任せて、原因の断定と顧客への約束は人間が握る。この四つをやるだけで、保守運用はかなり回るようになります。
新規開発の華やかさに比べて、保守運用は地味です。でも、受託でも自社開発でも、リリース後のほうが付き合いは長い。その長い時間を片手間で削られ続けるか、設計して回すかで、チームの消耗はまるで変わります。保守を「ちゃんとした案件」として扱うこと。それが、開発チームを長持ちさせる一番地味で効く投資だと、現場にいて思います。
保守の問い合わせがメールとチャットに散らかっている、というチームは、まず一つのクライアントの保守だけでいいので、問い合わせを課題として起票してボードに乗せるところから始めてみてください。「いま何件走っているか」が見えるだけで、保守の見え方は変わります。