6-1保守の考え方
焼き上がり通知が動き始めて3か月がたった水曜の朝、常連さんがカウンタにスマートフォンを置きました。「月曜から、メロンパンの知らせが来なくなったんです」。ミナトが自分のスマートフォンで試すと、通知はいつもどおり届きます。違いは、常連さんのスマートフォンだけが週末にOSを新しい版へ更新していたことでした。同じ日の午後には別の常連さんから「予約したパンも、焼けたら知らせてほしい」と頼まれ、夕方には店長が、紙のスタンプとレジ横の古い端末で続けてきたポイントカードを、通知の会員登録にまとめたいと言い出します。直す、足す、移し替える、片付ける。どれも、店を開けたままやらなければなりません。ミナトは相棒に打ち込みました。「作り終わったはずなのに、仕事が増えてない？」
相棒の返事は短いものでした。「増えたのではなく、ここからが長いんです」。システムは、本番で動き始めた日に完成するわけではありません。動き始めたあとも、使う人の要望や、周りの機器・OSは変わり続けます。
本番で稼働しているソフトウェアに対して、不具合を直したり、機能を改良・変更したりする作業をまとめてソフトウェア保守と呼びます。目的は二つあります。一つは、いま動いているシステムを安定して動かし続けること。もう一つは、ITの進歩や、店や会社の方針の変化に合わせて、システムを変えていくことです。通知が届かない件は前者、予約の知らせを足す件は後者にあたります。
システムが使われる年数は、作っていた期間よりずっと長いのがふつうです。そのため、システムにかかる費用の合計を考えると、作る費用よりも、動かし続けて直し続ける費用のほうが大きくなることも珍しくありません。保守は開発の「おまけ」ではなく、システムの一生のうちでいちばん長い工程です。
ここから基本情報！保守を引き受ける前に決めること
保守を続けるには、誰が、どの順で作業するかを先に決めておきます。問い合わせを受けてから、原因を調べ、直し、確かめ、本番に反映するまでの進め方と手続きが保守手順です。担当者、連絡の窓口、対応する時間帯といった、保守を行うための人と組織の仕組みを保守体制と呼びます。こむぎ堂なら、問い合わせを受けるのはミナト、原因を調べて直すのは開発会社、本番への反映を許すのは店長、という分け方です。
決める前に確かめることもあります。保守を受ける側の望み（「通知が止まったら1時間以内に直してほしい」）を、保守を提供する側が、手持ちの人数・技術・費用で本当に引き受けられるかです。この見込みを保守の実現可能性といいます。開発会社の担当者は2人で、土日は休みです。「土曜の朝でも1時間以内」は、いまの体制では約束できません。受ける側の要求と、提供する側の実現性・費用のつり合いをとって、保守で何を約束するかを決めます。
直したあとの確かめ方も、開発のときとは少し違います。保守で加えた修正が正しく働くか、そして修正していない部分に悪い影響が出ていないかを確かめるテストを保守テストと呼びます。後半の「ほかが壊れていないか」を、前と同じテストをもう一度流して確かめるのが、第5章で扱った回帰テストです。動きを変えずにプログラムの中身を読みやすく整理するリファクタリングをしたときも、外から見た動きが変わっていないことを回帰テストで確かめます。
基本情報の範囲ここまで
ポイントカードの件は、別の壁にぶつかりました。レジ横の端末のプログラムは、10年ほど前に、いまはもう無い業者が作ったものです。設計書も説明書も残っていません。会員番号が何けたで、スタンプが何個たまると何が起きるのか。新しい会員登録へまとめるには、まずそれを知る必要があります。
完成しているプログラムや製品を調べて、そこから仕様や設計の情報を逆向きに取り出すことをリバースエンジニアリングといいます。ふつうの開発は「設計してから作る」順に進みますが、これは「出来上がったものから設計を読み取る」向きに進みます。ミナトと開発会社の担当者は、端末に残っていたデータの並びと、画面での動きを照らし合わせて、「会員番号は6けた」「スタンプ20個で食パン1斤と交換」という仕様を書き出しました。なお、他社のソフトウェアを解析することは、利用許諾契約で禁じられている場合があります。こむぎ堂の場合は、店が買い取った自分たちのプログラムだったので問題になりませんでした。
取り出した仕様をもとに、要らない部分を整理して、新しい仕組みとして作り直すこともできます。既存のシステムを解析し、その結果をもとにシステムを再構築することをリエンジニアリングといいます。開発の進め方の型としてリエンジニアリングモデルと呼ぶ資料もあります。ゼロから要件を集め直すのではなく、いま動いているものの仕様を出発点にするので、古いシステムを置き換えるときに使われます。呼び名や、どこまでを含めるかは、資料によって少しずつ違います。
ここから基本情報！逆向きと順向き
リバースエンジニアリングと対になるのがフォワードエンジニアリングです。要件を決め、設計し、その設計からプログラムを作るという、ふつうの開発の向きの作業を指します。古いシステムをリバースエンジニアリングで解析して仕様を取り出し、その仕様からフォワードエンジニアリングで作り直す。この二つをつないだ流れを、一般にリエンジニアリングと呼びます。
基本情報の範囲ここまで
6-2保守のタイプと形態
通知の不具合を開発会社に伝えると、担当者から1枚の見積書が届きました。「月額の保守費用：通知の仕組み一式」。その下に、対応するもの・しないものが細かく並んでいます。「OSの更新への対応」は入っているのに、「予約の通知の追加」は別料金でした。店長は見積書を指でたどりながら、「直すのと足すのは、違う仕事なんだね」とつぶやきました。
同じ「保守」でも、何がきっかけで、何のために手を入れるのかによって、仕事の中身は変わります。動いていたものが壊れたのを元に戻すのか、周りが変わったのに合わせるのか、もっと使いやすくするのか。見積書の「対応する・しない」も、この違いで分けられていました。
ここから基本情報！保守の契約と保守のタイプ
保守を外の事業者に任せるときは、対象の範囲、対応する時間、費用などを取り決めて保守契約を結びます。その前に、こちらが保守に何を求めるのか、どんな方法と体制で保守するのか、保守しやすい作りになっているかといった要件をはっきりさせておく作業が保守要件の定義です。要件が書かれていなければ、見積書の「対応する・しない」の線を、こちらから確かめようがありません。
手を入れる理由で分けたものが、保守のタイプです。ソフトウェア保守の規格 JIS X 0161:2008 は、次の四つに分けています。この規格は2026年8月に JIS X 0161:2026 へ改正されましたが、シラバスの用語例はこの四つの名前に沿っています。
| タイプ | 何のための修正か | こむぎ堂の例 |
|---|---|---|
| 是正保守 | 引き渡したあとに見つかった問題を、起きてから直す | 売り切れの知らせが、次の焼き上がりのあとも残ってしまう不具合を直す |
| 予防保守 | 潜んでいる欠陥を、運用中の障害になる前に見つけて直す | 登録者が千人を超えると処理があふれる箇所を、超える前に直す |
| 適応保守 | OSや機器など、変わった環境でも使い続けられるようにする | 新しい版のOSに通知を届けられるようにする |
| 完全化保守 | 性能や保守性などを高める。潜んでいる欠陥を、故障として現れる前に見つけて直すことも含む | 通知の送信を速くし、プログラムを直しやすく整理する |
四つは二つの組にまとまります。是正保守と予防保守は、欠陥を直す「訂正」の組です。適応保守と完全化保守は、新しい要求に応える「改良」の組で、この二つをまとめて改良保守と呼びます。JIS X 0161:2008 は改良保守を「新しい要求を満たすための既存のソフトウェア製品への修正」とし、ソフトウェアの訂正ではないと注記しています。資料によっては、改良保守を機能の追加や変更をする保守として、四つと並べて扱うこともあります。
基本情報の範囲ここまで
保守の相手はプログラムだけではありません。オーブン横の「焼き上がりボタン」も、毎日何十回と押される機械です。木曜の朝、ボタンを押しても反応しないことが2回続きました。
ここから基本情報！機械の保守と、保守のやり方
サーバやパソコン、ボタンのような機器を対象に、故障の修理、部品の交換、点検などを行うのがハードウェア保守です。毎朝の開店前に、ボタンを押して通知のテストが届くか、サーバのランプに異常がないかを見て回るような、日々の確認を日常点検といいます。異常を早く見つけるための作業です。これに対して、月に1回ボタンの接点を掃除する、年に1回サーバの冷却ファンを替える、のように決めた日程で計画的に行うものが定期保守です。壊れる前に手を打つので、予防保守の考え方を機器に当てはめた形といえます。
保守をどこで行うかでも、形が分かれます。保守の担当者が機器のある現場まで出向き、その場で修理や点検をする形がオンサイト保守です。現場へ行かずに、ネットワーク越しにシステムに接続して状態を調べたり、設定を直したりする形が遠隔保守です。ボタンが壊れたなら誰かが来て取り替えるしかありませんが、サーバの設定の誤りなら、開発会社は事務所から直せます。遠隔保守は早く安く済む一方で、外からシステムに接続できる手段を用意することになるので、接続できる人と方法を絞っておく必要があります。
個々の保守を重ねていくと、システムの一生を全体として見直す時期が来ます。企画から開発、運用、保守、そして廃棄までの一連の過程を通して、費用や効果、問題点を振り返って評価することをライフサイクルの評価と呼びます。直し続けるのか、作り替えるのかを判断する材料になります。
基本情報の範囲ここまで
6-3保守を始める準備
翌週、開発会社から連絡が来ました。焼き上がり通知を作った担当者が別の仕事に移り、これからは新しい担当者が保守を受け持つそうです。初めて店に来た新しい担当者は、ミナトに聞きました。「通知の時間を朝7時台に送らないようにしたのは、どういう理由でしたっけ」。その答えは、前の担当者の頭の中にしかありませんでした。
開発の間は、作った人がすぐそばにいるので、疑問はその場で聞けば解けます。保守は違います。作った人が離れたあとも何年も続き、担当者は入れ替わります。そこで、保守を始める前に、作った人が知っていることを、紙やファイルに移しておく準備が要ります。
ここから基本情報！保守プロセス開始の準備
準備の一つめは、開発で作った要件定義書・設計書・プログラム・テストの結果などを、保守を受け持つ側へ渡すことです。これを成果物の引継ぎ（開発プロセスからの成果物の引継ぎ）といいます。シラバスでは「開発プロセスからの保守に必要な成果物の引継ぎ」と書かれています。「朝7時台は送らない」の理由も、要件定義書に常連さんの聞き取りの結果として残っていれば、新しい担当者は自分で読んで分かります。
二つめは、保守をどう進めるかの計画と手続きを整える計画及び手続の作成です。保守プロセスの最初の活動（保守プロセス開始の準備）の中心にあたり、先に見た保守手順や保守体制を、文書として決めておく作業です。その中でも、問題が見つかったときに、誰が受け付け、どこに記録し、どう報告して、どう対応を決めるかの流れを決めておくことを問題管理手続の確立といいます。これと並んで、変更や修正の作業を、決まった手順で行えるように整えておくことを修正手続の確立と呼ぶことがあります。誰の許可で直し、どのテストを通したら本番に反映してよいか、を決めておきます。
三つめが、保守の記録を残す保守のための文書作成（保守文書作成）です。どんな問題があって、どこをどう直し、どのテストで確かめたか。その経緯を書き残しておけば、次の担当者が同じ所で迷わずに済みます。引き継いだ成果物も、直すたびに更新しなければ、やがて実物と食い違っていきます。
基本情報の範囲ここまで
6-4問題の分析と修正
通知が届かない件の連絡は、その週のうちに3人から来ていました。開発会社の新しい担当者は、すぐにプログラムを開こうとはしませんでした。「まず、同じことが起きるか確かめましょう」。店の予備のスマートフォンを新しい版のOSに更新して試すと、焼き上がりボタンを押しても、やはり何も届きません。
報告を受けてすぐに直し始めると、思い込みで別の所を直してしまうことがあります。報告された問題が本当に起きているのか、何が原因なのかを確かめてから、直し方を選びます。直したあとも、本番に出す前に確かめて、同じことが二度と起きないようにする所までが、保守の一回分です。
ここから基本情報！問題を確かめて、直し方を選ぶ
最初に行うのが問題報告・修正依頼の分析です。利用者からの不具合の報告や、機能を変えてほしいという依頼の中身を調べ、原因の見当、影響する範囲、対応する必要があるかを明らかにします。3人の報告を並べると、3人とも同じ版のOSに更新したばかりだと分かりました。影響するのは、その版を使う人全員です。
次に、報告された問題が実際に起きるかを確かめるのが問題の再現又は検証です。予備のスマートフォンで同じ状況を作り、通知が届かないことを自分たちの目で確かめました。再現できない問題は、直ったかどうかも確かめられません。再現の手順そのものが、直したあとのテストの手順になります。
原因は、新しい版のOSが通知を受け取る前に、利用者に改めて許可を求めるようになったことでした。直し方は一つではありません。アプリの側で許可を求め直す画面を出すか、許可されていない人にはメールで知らせるか、両方を組み合わせるか。こうして複数の対応案を、費用・手間・影響の大きさとともに並べることを修正実施の選択肢の用意といいます。店長が選んだのは、許可を求め直す画面を出し、それでも許可されなければメールで知らせる組み合わせでした。
基本情報の範囲ここまで
直し方が決まれば、修正の作業に移ります。この日に開発会社が引き受けたのは、通知が届かない件だけではありませんでした。常連さんの「予約したパンも知らせてほしい」と、前から気になっていた「土曜の朝に通知が遅れる」件も、同じ時期にまとめて手を入れることにしたのです。
ここから基本情報！修正の実施から再発防止まで
修正の実施には、中身の違う三つの作業があります。動いているシステムに新しい働きを加える機能追加は、予約したパンの通知がそれにあたります。処理の速さや応答の時間をよくするための修正が性能改良です。土曜の朝、注文が集中する時間に通知が5分遅れていた件は、知らせを1通ずつ順に送っていた処理を、まとめて送る形に変えて1分以内に収めました。そして、特定した問題の原因を取り除き、正しく動く状態に戻すのが問題の是正です。許可を求め直す画面を足したのが、これにあたります。修正の対象には、プログラムだけでなく、利用者向けの説明書のような関連する文書も含めます。
直したら、動きを確かめて完了を承認します。シラバスでは「保守レビュー及び／又は受入れ」と呼ばれる段階です。予備のスマートフォンで通知が届くこと、予約の通知が出ること、ほかの通知が前と同じに届くことを確かめて、店長が本番への反映を承認しました。
最後が再発防止です。同じ種類の問題を繰り返さないように、根本の原因を探し、似たことが起きそうな所がないかを調べます。原因を魚の骨の形に並べて整理する特性要因分析を使うと、「OSの新しい版を事前に試していなかった」ことが根本にあると分かりました。それ以来、新しい版のOSが出ると、開発会社が公開前の版で通知を試してから知らせてくれるようになりました。
基本情報の範囲ここまで
6-5移行
いよいよポイントカードの番です。レジ横の古い端末には、412人ぶんの会員番号とスタンプの数が入っています。店長は言いました。「明日から新しい会員登録に切り替えて、古い端末は捨てよう」。ミナトは手を止めました。もし切り替えた朝に、スタンプが全員0個になっていたら、どうなるでしょう。
古いシステムから新しいシステムへ、データや業務を移し替えることを移行といいます。移行の難しさは、店を止めずに行わなければならない点にあります。移す途中でデータが欠けたり、切り替えた日に新しい仕組みが動かなかったりすれば、お客さんに迷惑がかかります。だから、いつ、何を、どの順で移し、うまくいかなかったらどうするかを、移す前に決めておきます。
移したデータの件数や中身が元と一致しているかを、移したあとに確かめることも欠かせません。ポイントカードなら、会員の人数と、スタンプの合計が新旧で同じかを数えます。
ここから基本情報！移行の手順
移行は、計画を書くところから始まります。移す手順、日程、方法、うまくいかなかったときの戻し方を文書にまとめ、その計画で本当に移せるかを確かめることを移行計画の文書化といいます。シラバスでは「移行計画の文書化と検証」と、確かめる所までが一組になっています。計画ができたら、店長、店員、開発会社、そしてお客さんまで、関係する全員に移行の日程や影響を前もって知らせます。これが移行計画の通知です。店頭には「11月から、ポイントは会員登録でためられます」という貼り紙を出しました。
移し方には大きく二つあります。ある日を境に、全部を一度に新しいシステムへ切り替えるのが一斉移行方式です。手間は少なくて済みますが、新しいシステムに問題があると、逃げ道がありません。もう一つは、しばらくの間、新旧の両方を動かしておき、新しい側が問題なく動くことを確かめてから、古い側を止めるやり方です。シラバスではこれを新旧環境の並行運用と旧環境の停止と呼んでいます。両方を動かす間は手間が倍になりますが、新しい側で問題が出ても古い側で商売を続けられます。業務や店舗ごとに少しずつ移す段階的なやり方もあります。
本番の移行の前には、データを移す手順や切り替えの手順が正しく行えるかを、試しの環境で通してみます。これが移行テストです。作ったプログラムを確かめるテストとは違い、移行の作業そのものが計画どおりにできるかを確かめます。こむぎ堂では、古い端末のデータの写しを新しい会員登録へ読み込み、どこまで時間がかかるかも測りました。
移したあとは、データや機能が新しい環境へ正しく移ったかを確かめます。これが移行結果の検証です。こむぎ堂では、次の三つを数えて照らし合わせました。
| 数えたもの | 古い端末 | 新しい会員登録 | 差 |
|---|---|---|---|
| 会員の人数 | 412人 | 410人 | 2人 |
| スタンプの合計 | 3,068個 | 3,047個 | 21個 |
| スタンプ20個以上の人 | 37人 | 37人 | 0人 |
人数が2人足りません。消えた2人ぶんを調べると、会員番号の先頭が0の人でした。6けたの会員番号を数として読み込んだため、「012345」が「12345」になり、5けたの番号として読み込みの段階ではじかれていたのです。2人のスタンプは13個と8個で、合わせて21個。スタンプの差とも合います。合計の数を見るだけでは、どこが欠けたのかは分かりません。それでも、差が出たことで、調べる所が分かりました。会員番号を文字として読み込むように直してやり直すと、三つとも一致しました。
移行が終わったら、計画どおりにできたか、どこで手間取ったかを振り返ります。これが移行評価で、次に移行するときの計画に生かします。そして、古い環境にあったデータは、移行が終わってもすぐには消しません。あとで「移行前は何個だったか」を確かめる必要が出るかもしれないからです。一定の期間、漏れたり書き換えられたりしないように安全に保管しておくことを旧環境関連データの保持といいます。シラバスでは「旧環境関連データの保持と安全性確保」と書かれています。
基本情報の範囲ここまで
6-6廃棄
新しい会員登録が動き始めて2週間。古い端末を使う人は、もう誰もいなくなりました。店長が電源のコードを抜こうとすると、相棒が画面に一行出しました。「その端末の中には、412人の電話番号が残っています」。抜けば終わり、ではありませんでした。
役目を終えたシステムを止めて片付けることを、廃棄といいます。ただ電源を切るだけでは足りません。中に残っているデータを、必要な分は保管し、要らない分は読み出せないように消す必要があります。その仕組みに頼っていた仕事が、片付けたあとも困らずに回るようにしておくことも要ります。
ここから基本情報！廃棄の手順
廃棄で守るものを、シラバスは組織の運用の完整性（integrity）という語で示しています。システムを止めたり取り除いたりしても、組織の業務がほころびなく回り続ける状態を保つ、という意味でとらえるとよいでしょう。シラバスの本文は、廃棄しても運用に支障のない状態にしてから、起動できないようにしたり、取り除いたりする、と述べています。
廃棄も移行と同じく、計画から始めます。いつ、どの順で止め、データをどう扱い、機器をどう処分するかを決めておくのが廃棄計画の立案です。決めた計画は、そのシステムを使っている人に前もって知らせます。これを廃棄計画の利用者への通知といい、こむぎ堂では「古いポイントカードは11月末で使えなくなります」とレジに書きました。
止める前の一定の期間は、新旧両方の仕組みを並べて動かし、その間に利用者が新しい仕組みを使えるように教えます。これが新旧環境の並行運用と教育訓練です。シラバスでは「新旧環境の並行運用と利用者の教育訓練」と書かれています。店員は、会員登録の画面の見せ方を練習し、スマートフォンを持たないお客さんには紙の会員証を渡す手順を覚えました。
廃棄を実際に行う前には、関係者全員にそのことを知らせます。これが廃棄の通知です。利用者への通知が計画を早めに伝えるものなのに対して、こちらは「いよいよ止める」ことを関係者全員へ伝えるものです。こむぎ堂では、開発会社と、古い端末の回線を契約していた会社にも伝えました。
止めたシステムのデータは、廃棄したあとも一定の期間残し、必要になったときに取り出せるようにしておきます。これが廃棄関連データの保持です。シラバスでは「廃棄関連データの保持とアクセス可能性の確保」と書かれています。保管していても、読み出す機械がなければ取り出せません。こむぎ堂は、古い端末のデータを一般的な形式の表に書き出してから保管しました。端末の中の記憶装置は、データを読み出せないように消去してから処分しました。
基本情報の範囲ここまで
11月の最後の日、店長は古い端末の電源コードを抜き、書き出した会員の記録を鍵のかかる引き出しへしまいました。その朝も、焼き上がり通知はメロンパンの知らせを届けていました。届かなかった常連さんのスマートフォンにも、予約した食パンの知らせが並んでいます。ミナトは相棒に、3か月前の問いへの答えを打ち込みました。「作り終わったんじゃなくて、作り続けてるんだね」。返事を待つ間に、次の連絡が入りました。今度は、来年の春に出るOSの新しい版について、開発会社からの知らせでした。