受託開発×クラウドで保守負荷を下げた設計

受託開発とクラウドの相性は良いです。ただし、クラウドに置けば保守が軽くなる、という単純な話ではありません。保守負荷を下げるには、要件定義と設計の段階で、何を作り込み、何をクラウドの標準機能に任せ、リリース後に誰が何を見るかまで決めておく必要があります。

中小企業の業務システムでは、初回リリースよりも、その後の保守で苦労することがあります。担当者の異動、業務ルールの変更、サーバー更新、セキュリティ対応、バックアップ確認、月額費用の確認。ひとつずつは小さく見えても、何年も続くと重くなります。

受託開発でクラウドを使う価値は、サーバーを買わなくてよいことだけではありません。標準化された部品を使い、監視やバックアップを最初から組み込み、変更しやすい範囲を分けることで、運用後の手戻りを減らせるところにあります。逆に、クラウド上に古い考え方のシステムをそのまま載せると、費用構造だけがクラウド化し、保守の苦労は残ります。

お問い合わせはこちら

受託開発とクラウドの相性

受託開発とは、会社ごとの業務に合わせてシステムを作る開発です。既製品で合わない業務、既存システムとの連携が必要な業務、現場独自の入力や承認がある業務では、受託開発が選ばれます。

一方、クラウドは、ネットワーク経由でサーバー、データベース、ストレージ、アプリケーション基盤などを必要に応じて使う形です。NISTの定義でも、クラウドは共有された計算資源を必要に応じて使い、少ない管理作業で提供や解放ができるモデルとして整理されています。

この2つは、うまく組み合わせると相性が良いです。受託開発は業務に合わせて作る部分に集中し、サーバーの物理保守、バックアップ基盤、ログ保存、監視、認証の一部はクラウドの標準機能に任せられます。開発会社は、すべてを一から作るのではなく、クラウドの部品を選び、業務に必要な部分だけを丁寧に作る形にできます。

保守負荷を下げる受託開発では、作れるものを全部作らない判断が効きます。独自実装が必要な業務ロジックと、クラウド側に任せる共通機能を分けるほど、リリース後の面倒を見る範囲を減らせます。

相性が良い業務システム

• 複数拠点や外出先から利用する受発注管理、顧客管理、案件管理
• 月ごとに利用量が変わる予約管理、キャンペーン受付、問い合わせ管理
• 紙やExcelで回している申請、承認、報告をWeb化したい業務
• 既存の会計、販売管理、チャット、メール、ファイル共有と連携する業務
• 小さく始めて、使いながら機能を増やしたい社内システム

このようなシステムでは、最初から大きなサーバーを用意するより、クラウド上で必要な分だけ始め、利用状況を見ながら増やすほうが扱いやすいです。特に中小企業では、専任のインフラ担当者を置けないことが多く、保守の範囲を小さく保つ設計が効きます。

保守負荷が増える典型

保守負荷は、リリース後に突然増えるわけではありません。多くは、開発前の決め方や初期設計の中に埋まっています。仕様が曖昧なまま作る。個別機能を増やしすぎる。サーバー構成を担当者しか知らない。バックアップの戻し方を試していない。こうした小さな未整理が、半年後、一年後に効いてきます。

受託開発でありがちなのは、初期費用を抑えるために運用まわりを後回しにすることです。画面と機能はできた。ログインできる。帳票も出る。ここまでは良いのですが、障害通知、バックアップ、権限の棚卸し、費用の監視、データ復旧手順が薄いままだと、保守が始まってから困ります。

ここを最初に決めておくと、保守の仕事はかなり読みやすくなります。全部を完璧にする必要はありません。まず、止まったら困る場所、戻せないと困るデータ、社外へ見えてはいけない情報を決める。そこから設計します。

設計で先に決めたこと

保守負荷を下げる設計では、画面や機能の前に、運用の境界を決めます。誰がアカウントを持つのか。どこまでを開発会社が見るのか。クラウドの管理権限は顧客側と委託先でどう分けるのか。障害時は、利用者、顧客担当者、開発会社のどの順番で連絡するのか。

この話を後回しにすると、リリース直後は動いても、半年後にだんだん重くなります。新しい社員を追加するたびに開発会社へ依頼する。軽微な設定変更でも作業費が発生する。障害時に誰がログを見るのか決まっていない。地味ですが、こういうところで保守費用と不満が増えます。

マネージドサービスを使う範囲

クラウド上でも、すべてを仮想サーバーに載せる構成は避けたいところです。データベース、ファイル保存、メール送信、監視、バックアップ、認証などは、クラウドのマネージドサービスを使える場合があります。マネージドサービスとは、クラウド事業者が基盤の運用をかなり見てくれるサービスです。

もちろん、使えば何でも楽になるわけではありません。費用、制約、既存システムとの相性は見ます。ただ、独自に作った仕組みを長く保守するより、標準機能に寄せたほうが、担当者交代や外部委託先変更に耐えやすくなります。

変更しやすい場所と変えにくい場所

受託開発では、業務に合わせた変更が後から出ます。承認ルートを変えたい。帳票の項目を増やしたい。取引先別に入力ルールを変えたい。これらは自然な要望です。

だからこそ、変わる場所と変わりにくい場所を分けます。業務ルールや通知文面は変わりやすい。認証、監査ログ、バックアップ、権限管理は安定しているほうがよい。変わりやすい部分を設定やマスタで扱えるようにし、基盤部分はなるべく標準機能に寄せる。これだけで、軽微改修のたびに全体へ手を入れる回数を減らせます。

運用資料を納品物に含める

ソースコードと画面だけを納品しても、保守は回りません。クラウド構成図、アカウント一覧、権限の考え方、バックアップ設定、監視通知先、障害時の一次切り分け、月次確認項目。このあたりを納品物に含めます。

資料は立派な冊子である必要はありません。むしろ、毎月見直せる表や簡単な手順書のほうが使われます。保守で困るのは、資料がないことだけではありません。古くて信用できない資料も、かなり厄介です。

運用負荷が下がった理由

クラウドを使って運用負荷が下がるのは、人が見なくてよい作業を減らせたときです。サーバーの物理交換、ディスク容量の心配、バックアップ装置の管理、保守期限の確認を自社だけで抱えない。ここに効果があります。

もう一つは、作業の標準化です。監視アラートを決める。ログの保存場所を決める。変更作業はチケットや記録に残す。検証環境で確認してから本番へ反映する。こうした運用はオンプレでもできますが、クラウドでは仕組みに乗せやすいです。AWS Well-Architected FrameworkやAzure Well-Architected Frameworkでも、信頼性、セキュリティ、コスト、運用の観点で継続的に見直す考え方が示されています。

保守負荷が下がったと感じる現場では、クラウドの機能そのものより、面倒を見る範囲が整理されています。開発会社が見る範囲、顧客企業が見る範囲、クラウド事業者に任せる範囲。この3つが曖昧なままでは、クラウドでも問い合わせは減りません。

成功の考え方

受託開発とクラウドの組み合わせで成功したと言えるのは、リリース直後に問題なく動いたときだけではありません。半年後、一年後に、変更依頼、障害対応、費用確認、権限追加、担当者交代が落ち着いて回っているか。そこまで見ます。

成功の判断は、機能数よりも保守の予測しやすさです。毎月どの作業が発生するか。障害時に誰が何を見るか。バックアップから戻せるか。費用が増えたときに気づけるか。委託先が変わってもクラウド環境を引き継げるか。このあたりが説明できるなら、かなり良い状態です。

最初に合意したい基準

• 障害時の許容停止時間と、復旧したいデータの時点
• 管理者権限を持つ人と、外部委託先に渡す権限
• 月額クラウド費用の上限と、予算超過時の連絡先
• バックアップ、ログ、監視通知を確認する頻度
• 軽微改修、設定変更、障害対応をどこまで保守契約に含めるか
• リリース後に見直す日付と、改善要望の扱い方

この基準を契約前後で共有しておくと、開発会社と顧客企業の認識がずれにくくなります。顧客側は、どこまでが月額保守に含まれるのかを理解できます。開発会社側も、無制限に問い合わせを受ける状態を避けられます。お互いにとって悪くない形です。

向いている企業と向いていない企業

受託開発とクラウドの組み合わせは、すべての会社に同じように合うわけではありません。向いているのは、業務に合わせたシステムを作りたいが、サーバー保守を社内だけで抱えたくない会社です。

向いている企業

• 専任のインフラ担当者が少なく、外部パートナーと運用を分担したい会社
• 拠点追加、在宅勤務、外部取引先との連携など、利用場所が変わりやすい会社
• 最初は小さく始め、利用状況を見ながら機能を増やしたい会社
• サーバー更新や保守期限に追われる状態を減らしたい会社
• セキュリティやバックアップを、個人の頑張りではなく仕組みに寄せたい会社

向いていない、または準備が必要な企業

• 工場設備や専用機器との接続が多く、クラウド接続の検証が必要な会社
• 通信回線が不安定な場所で、常時接続を前提にできない会社
• 社内規程や取引条件で、データ保管場所に強い制約がある会社
• 月額費用の確認や権限管理を誰も担当できない会社
• 既存システムが古く、OSやデータベースの制約でそのまま移せない会社

向いていないケースでも、クラウドを諦める必要はありません。まずはバックアップ、監視、ファイル共有、検証環境など、切り出しやすいところから始める方法があります。いきなり基幹業務を移すより、保守効果を確認しやすいです。

具体例：受発注システムの再構築

たとえば、社員80名ほどの卸売業で、古い受発注システムを再構築するケースを考えます。これは架空の例です。現場では、営業担当が外出先から注文状況を確認したい。事務担当は在庫と納期をまとめて見たい。管理者は月次の取引データを出したい。既製品だけでは細かい業務に合わず、受託開発を選ぶ場面です。

このとき、すべてを一つのサーバーに載せると、後の保守が重くなります。アプリ、データベース、ファイル、帳票、バックアップ、ログが同じ場所に寄り、障害時の切り分けが難しくなります。担当者が変わると、どこを見ればよいか分からない。

クラウドを使う場合は、アプリ部分、データベース、ファイル保存、バックアップ、監視を分けます。営業担当のアクセス権と事務担当のアクセス権も分けます。検証環境を用意し、帳票変更は検証してから本番へ反映します。費用通知を設定し、月次で利用状況を確認します。

これだけで万能になるわけではありません。業務ルールが変われば改修は必要です。ただ、改修のたびにサーバー全体へ手を入れる状態は避けられます。障害時も、アプリの問題なのか、データベースの問題なのか、外部連携の問題なのかを追いやすくなります。保守の時間がゼロになるのではなく、読める時間になります。

よくある失敗

一番多い失敗は、クラウド化をサーバー移転として扱うことです。古い構成をそのまま仮想サーバーへ移し、監視もバックアップも権限管理も後回しにする。これでは、オンプレで困っていたことがクラウド上に場所を変えるだけです。

見積もりで運用を削りすぎる

初期費用を下げるために、監視、バックアップ、復旧テスト、運用資料を削ると、後から費用が出ます。トラブルが起きてから整えるほうが高くつくこともあります。最低限で始めるのは良いですが、最低限に何を含めるかは慎重に決めたいところです。

独自機能を増やしすぎる

受託開発では、要望を聞きすぎると、細かい例外処理が増えます。最初は親切に見えますが、保守では効いてきます。例外が多いほどテストが増え、改修の影響範囲も読みにくくなります。業務上どうしても必要な例外と、運用で吸収できる例外を分けてください。

管理者アカウントを軽く扱う

クラウドでは、管理者権限の扱いを間違えると影響が大きいです。開発会社の個人アカウントだけで管理する。退職者の権限が残る。多要素認証を使わない。こうした運用は避けます。IPAの中小企業向け情報セキュリティ資料でも、経営者が認識すべき方針と社内で実践する手順の両方が扱われています。クラウド利用でも、ルールを会社側に残すことが欠かせません。

発注時に確認したいこと

受託開発を依頼するときは、機能一覧だけでなく、保守の前提を聞いてください。見積書にある保守費が何を含むのか。クラウド費用は誰の契約で支払うのか。障害時の一次対応は誰か。バックアップから戻す作業は契約に含まれるのか。ここが曖昧だと、リリース後に揉めやすくなります。

発注前の確認項目

• クラウド契約の名義、支払い、管理者権限は誰が持つか
• 本番環境、検証環境、開発環境をどう分けるか
• バックアップはどの頻度で取り、どの時点まで戻せるか
• 監視アラートは誰に届き、何時間以内に確認するか
• 保守契約に含まれる作業と、別見積もりになる作業は何か
• 運用資料、構成図、権限一覧、復旧手順を納品物に含めるか
• リリース後の改善要望を、どの頻度で整理するか

この確認を嫌がる開発会社なら、少し立ち止まったほうがよいです。保守の話は地味ですが、受託開発ではここが長く効きます。良い開発会社ほど、作る前に運用の線引きを確認します。

まとめ

受託開発とクラウドを組み合わせると、保守負荷を下げやすくなります。理由は、クラウドが何でも代わりにやってくれるからではありません。物理基盤、バックアップ、監視、ログ、認証などを標準機能に寄せ、独自に作る範囲を絞れるからです。

保守が楽なシステムは、リリース後に人が頑張り続けるシステムではありません。障害時に見る場所が決まっている。バックアップから戻せる。費用を毎月確認できる。権限を棚卸しできる。改修の影響範囲を追える。こうした地味な条件がそろっているシステムです。

受託開発を検討するなら、要件定義の段階でクラウド構成、保守範囲、運用資料、費用確認、権限管理まで話しておくことをおすすめします。クラウドを使うかどうかより、クラウドを使って何を持たないか、何を自社で管理するかを決めるほうが、長い目では効きます。

受託開発とクラウド活用で迷ったら

業務に合わせたシステムを作りたい一方で、保守やサーバー運用を重くしたくない場合は、開発前の設計整理が大事です。現在の業務、既存システム、利用者数、データ量、障害時の許容時間、社内で持てる運用範囲を確認すると、クラウドに任せるべき部分と作り込む部分が見えてきます。

新規システムの受託開発、既存システムのクラウド移行、保守負荷の見直しを検討している場合は、まずは現状の棚卸しからご相談ください。運用後まで見据えた構成を一緒に整理します。

参考情報

• NIST「The NIST Definition of Cloud Computing」
• AWS Well-Architected Framework
• Azure Well-Architected Framework
• IPA「中小企業の情報セキュリティ対策ガイドライン」