ソフトウェア保守には何が含まれる？

合意した要件と異なる問題を直す

例えば、要件が明確なのに予約が別のタイムゾーンで表示される場合です。担当チームは原因を確認し、修正方法を決め、関連する部分を再検証します。

版、データ、発生条件を照合します。すべてがコードの問題ではなく、設定、入力、外部サービスが関係する場合もあります。

環境の変化に対応する

ライブラリ、ブラウザー、OS、連携サービスは時間とともに変わります。どの変更が影響し、いつ対応すべきかを評価します。

NIST SP 800-40は、パッチ管理に更新の特定、優先順位付け、適用、検証を含めています。具体的なシステムでは、リスクと互換性を確認し、適切に検証してから利用環境へ反映します。

使いやすさと運用を改善する

通知を分かりやすくする、検索処理を最適化する、状況把握を改善するといった要望もあります。必ずしも不具合修正や大規模な新機能とは限りません。

期待結果を説明し、影響を確認します。画面上の短い変更でも、複数の役割やデータに関わる場合があります。

新しい要望に合わせて開発する

事業者がサービスを増やし、予約ルールを変えたい場合は、追加開発に当たる可能性があります。合意した進め方で分析、見積もり、範囲確認を行います。

公開後の要望がすべて保守内とは考えません。反対に、根拠を調べず、利用者の依頼をすべて追加扱いにするのも避けます。

これらの用語は契約ごとに意味が異なります。名称だけでなく、具体的な条件を読みましょう。

保証は、定めた期間と範囲での不適合対応として説明されることが多く、保守には定期作業や利用中の支援が含まれる場合があります。追加開発は、承認された新規・変更要件への対応です。

例えば、規定条件下の予約不具合は、約束した対応範囲に入るかもしれません。一方、従来なかった種類のサービスの予約は別途評価します。

開始時点、期間、適用条件、対象外を明記します。費用を判断するときは、導入費と運用費に合わせて確認します。

開発費用が想定を超える五つの原因

システム開発の見積書、何を確認する？

顧客が予約を完了できないとします。受付担当者には、報告窓口、必要な情報、調整責任者の把握が必要です。

最初の情報には、時刻、影響範囲、エラー表示、情報漏えいを防ぐよう処理した参照番号などがあります。パスワードや顧客データ全体をメッセージで送るよう求めないことが大切です。

優先度は実際の影響で判断します。全予約を止める不具合と、利用頻度の低い画面の配置ずれは異なります。ただし、区分と目標時間は発生後に決めず、事前に合意します。

受付連絡、暫定対応、原因解消は区別します。提供側の受領確認は、システム復旧と同じではありません。

対応中は、代替手段があれば業務責任者が継続方法を案内します。復旧後は、新規データ、保留取引、手入力分を確認し、漏れと重複を防ぎます。

まず対象資産です。ソフト、環境、接続、第三者サービスのどこまでを扱うかを決めます。外部サービスは、アカウント所有者と支援を依頼できる人も確認します。

次に、対応時間、連絡方法、窓口です。常時稼働するシステムを支えることを、合意なしに「すべての依頼へいつでも即対応」と解釈しないようにします。

三つ目は変更管理です。更新のテスト、反映時点の承認、影響が出た場合の対応を決めます。重要なシステムと少人数の社内ツールでは、必要な確認が異なる場合があります。

監視の方法も明確にします。報告時だけ調査するのか、能動的に監視するのか。警告があるなら、誰が、どの時間帯に受け、どう対応するのでしょうか。

最後に資料と権限です。支援チームに適切な権限を与え、変更を記録し、担当者や会社が変わる際は回収できるようにします。これは修正だけでなく、引き継ぎと運用管理の課題でもあります。

システムの引き継ぎで受け取るもの

修正件数に加えて、影響、停止時間、再発、実施した予防作業も確認します。

利用者が報告方法を知らないため件数が少ないだけなら、安定しているとは限りません。対象範囲が広がって依頼が増えた場合も、件数だけで品質低下とはいえません。

業務、技術、関連サービスの変化を定期的に見直します。長年同じひな型を使っているからと維持せず、実際に動いているシステムに合わせて計画を更新します。

明確な計画は、誰が監視し、誰が対応し、何をもって復旧と確認するかに答えられるものです。利用範囲や関連サービスが変わったとき、これらの答えを見直しましょう。

公開後の支援についてFenixに相談する