保育園をはじめとする顧客の給食注文と食数管理のためのシステムを構築しました。サービス開発と併せてクラウド環境、デプロイ経路、バックアップ基準を準備し、中核となる業務フローを検証しました。

給食注文システムで画面に入力される数量は、実際の運用で使う情報です。注文を受ける機能と食数を管理する機能は別々に見えることもありますが、利用者にとっては一つの業務としてつながっていなければなりません。

K社には、この業務を処理する新しいシステムが必要でした。何を作るかを決めることと、完成したシステムをどこで運用するかを決めることを、一緒に進める必要がありました。

IXCは開発とQA、クラウド環境を一つのプロジェクトとして引き受けました。この事例の出発点は、機能が完成してからサーバーを探すのではなく、実際の運用条件を開発と一緒に準備することでした。

給食注文と食数管理システムの匿名化画面
注文と食数を管理するサービスの中核画面。

業務の利用パターンがインフラ設計の基準になりました

サーバー構成を選ぶとき、機能一覧だけでは十分ではありません。利用が一日を通して均等に発生するのか、特定の時間に集中するのかによって、準備すべき条件が変わることがあります。

K社では、注文が集中する時間帯を考慮してサーバー構成を決めました。注文という機能があることだけでなく、実際に使われる状況を基盤環境に反映したのです。

インフラ設計では、サーバーの仕様よりも先にサービスが使われる条件を整理する必要があります。どの時間帯にリクエストが集まり、そのときにどんな処理が実行されるのかが分かって初めて、規模と運用基準を判断できます。

業務のリズムを知らなければ、平均的な利用量だけを見て環境を判断しがちです。構築段階から利用パターンを一緒に見ておくべき理由です。

給食注文が集中する時間と中核作業の関係を示した概念図
平均的なアクセスよりも、実際の業務が集中する条件を先に考慮しました。

開発の後にデプロイ準備を残しませんでした

クラウド環境を先に準備し、開発を同じスケジュールで進めました。コードの変更がデプロイにつながる経路を整え、機能を作ることと実際の環境に載せることがつながるようにしました。

開発環境で動く機能を運用に反映するには、また別の作業が必要です。環境が準備されていなければ、コードが完成しても利用者は使えません。

自動デプロイの意味も、ボタンを減らすことだけにあるわけではありません。変更を反映する経路を一貫して保てることが重要です。次の機能を追加するときも、以前のやり方を参照できます。

デプロイ経路を整えた後も、公開する機能の確認は必要です。環境を更新する過程と、注文・食数の動作を検証する過程を一緒に扱ってこそ、次の変更を運用に反映できます。

注文と食数管理がつながるフローを確認しました

開発と併せてQAを行い、注文と食数管理の中核フローを実行して検証しました。機能がそれぞれ存在するかよりも、業務として使えるかを確認する過程です。

業務システムでは、ボタンを押したときに反応することと、利用者が目的を達成することは別の場合があります。保存はされたのに次の段階で必要な情報がなければ、業務は画面の外で改めてつなぐことになります。

だからこそ、検証の単位を個々の画面だけに置くことはできません。前の動作が後で使う結果を残しているかまで考える必要があります。注文機能と食数管理機能を同じ業務フローとして見る理由です。

この事例のQA結果は、サービスが運用へ移る過程に含まれていました。システムを作ってから検証する主体を別に探すやり方とは異なり、構築の範囲の中で中核となる動作を確認しました。

バックアップと運用基準も一緒に整理しました

環境構成では、デプロイ経路だけでなくバックアップ周期と運用基準を文書に残しました。サービス公開後に繰り返すことになる作業を、構築段階で一緒に準備したのです。

バックアップ周期を定めることは、データを保護するための準備にあたります。ただし、バックアップの設定だけで、どんな障害からでもすぐに復旧できるとは言えません。復旧の水準を説明するには、実際の復元検証と運用条件を別途確認する必要があります。

この区別は、運用範囲を定めるときに重要です。何が設定されているか、何を試験したか、問題が起きたときに何ができるかは、それぞれ別の情報だからです。

K社では、開発成果物に基盤環境と運用文書を加え、次の変更を続けられるようにしました。

開発とQA、デプロイ、バックアップ準備の役割を示した概念図
デプロイ経路と機能検証、運用準備は、それぞれ固有の役割を持ちます。

顧客が注文するシステムとして運用を続けています

構築したプラットフォームでは、保育園をはじめとする顧客が給食を注文し、食数を管理しています。その後に機能を追加する際も、整えたデプロイ経路を使いながら運用を続けています。

このプロジェクトの成果は、注文画面を新しく作ったことより広いものです。業務機能、検証、サービスを載せる環境、その後の変更経路を一緒に整えました。

初めてシステムを構築する組織では、開発と運用を別々の段階としてだけ見てしまいがちです。しかし公開後も使い続けるサービスであれば、初日の機能と翌月の変更を一緒に準備する必要があります。

K社の事例は、業務に必要なソフトウェアを作ることと、そのソフトウェアを運用し続ける環境を整えることをつないだプロジェクトです。