【IT知識ゼロからOK】開発から運用までの流れ ― 生成AI時代のアーキテクチャ超入門・基礎編

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ITの基礎知識」編・第6弾（最終回）として、開発から運用までの流れを解説する記事です。

ここまでの基礎編では、Webサービスというお店の建物や設備、防犯の話をしてきました。最終回の今回は、「そのお店を作って、開店して、毎日営業し続ける」という時間の流れの話です。開発、テスト、リリース、運用、監視、障害対応。本編のあちこちに出てくるこれらの言葉が、それぞれ何をすることなのかを押さえていきます。

作って終わり、ではない

まず大前提の話からです。Webサービスというのは、作って公開したら終わり、ではありません。

レストランで考えると分かりやすいと思います。開店日はゴールではなくスタートで、そこから毎日の営業が始まりますよね。食材の仕入れ、設備の点検、新メニューの追加、クレーム対応・・・お店の仕事の大半は、実は開店後に有ります。

Webサービスも全く同じで、公開後も新機能の追加、不具合の修正、サーバーの面倒見といった仕事が延々と続きます。むしろサービスの一生で見ると、作っている期間より営業している期間の方がずっと長いのです。本編で運用という言葉が重たく扱われているのは、これが理由です。

開発とテスト ― 新メニュー作りと味見

開発とは、プログラム（手順書）を書いてサービスの機能を作る仕事です。お店で言えば、新メニューのレシピを考えて試作する工程ですね。

そして開発とセットで必ず出てくるのがテストです。テストとは、作った機能が「ちゃんと動くか、変な動きをしないか」を確認する工程で、お店で言えば味見です。

味見と侮るなかれ、で、これがなかなか奥深い工程です。新メニュー一品の味見だけでは足りなくて、「新メニューを追加したせいで、既存メニューの調理がおかしくなっていないか」も確認する必要が有ります。キッチンの動線を変えたら、今まで問題なかった料理の提供が遅れるようになった、みたいなことがプログラムの世界では本当によく起きるのです。なので本編では、この確認を人手ではなくプログラムで自動化する自動テストという考え方が繰り返し出てきます。

リリース ― 新メニューをお客さんに出す

テストで問題がなければ、いよいよお客さんに提供を開始します。これがリリース（デプロイとも言います）です。新メニューを正式にメニュー表に載せる瞬間ですね。

ここで一つ、飲食店と違う面白いポイントが有ります。Webサービスのお店は営業を止めずに改装するのが基本だということです。24時間営業のお店なので、「新メニュー準備のため本日休業」がなかなか出来ません。お客さんが食事をしている横で、気付かれないようにキッチンを入れ替えるような芸当が求められるわけです（考えただけでも大変そうですよね・・・）。

本編に出てくるCI/CDという言葉は、この「味見からメニュー表更新までの一連の流れを自動化する仕組み」のことです。人手でやると手順ミスが起きるので、テストに合格したら自動でリリースまで進む流れ作業のラインを組んでしまう、という発想です。

運用と監視 ― 毎日の営業と健康チェック

リリースが済んだら、あとは運用です。毎日の営業ですね。

運用の中でも特に大事なのが監視（モニタリング）です。監視とは、お店が健康に営業出来ているかを常にチェックし続けることです。注文から提供までに何秒かかっているか、キッチンは忙しすぎないか、倉庫の空き容量は足りているか。こうした数値を計器で常時測って、おかしくなり始めたら人間に知らせる仕組みを整えておきます。

なぜこれが大事かというと、Webサービスの不調は「お客さんからの見た目では分かりにくい」からです。実店舗なら行列や店員の焦りが目に見えますが、Webのお店は中の様子が見えません。監視の計器がなければ、「お客さんからのクレームで初めて障害に気付く」という一番恥ずかしい事態になってしまいます。

障害対応 ― 起きない前提ではなく、起きる前提で

そして避けて通れないのが障害対応です。障害とは、サービスが正常に使えなくなるトラブル全般のことです。

ここで本編を読む上で大事な心構えを一つ。プロの世界では、障害は「起きないように頑張る」ものではなく「必ず起きる前提で備える」ものとされています。どんな一流レストランでも、停電や設備の故障をゼロには出来ませんよね。なので、火が止まったらどう営業を続けるか、復旧を何分でやるか、という「起きた後の段取り」を先に決めておくのです。

本編に出てくる冗長化（設備を二重に持っておくこと）やバックアップ（台帳の写しを別の場所に保管しておくこと）は、全部この「起きる前提の備え」の道具です。障害対応の記事で妙に手順が細かく決められているのも、火事の最中に避難経路を考えるのでは遅いから、と考えると納得しやすいと思います。

リハーサル用のお店 ― 本番環境とステージング環境

もう一つ、本編を読む前に知っておくと便利な言葉が環境です。「本番環境」「ステージング環境」「開発環境」といった形で頻出します。

環境というのは、ざっくり言えば「サービス一式が動いているお店の建物」のことです。そして実際のサービス運営では、お客さんが来る本物のお店（本番環境）とは別に、そっくり同じ作りのリハーサル用のお店を用意します。これがステージング環境です。

なぜそんな贅沢をするかというと、先ほどの「営業を止めずに改装する」と繋がっています。新メニューをいきなり本物のお店で試して失敗したら、目の前のお客さんに被害が出てしまいますよね。なので、まず自分の手元の練習台（開発環境）で作り、次にリハーサル用のお店（ステージング環境）で本番同然の最終確認をして、それから本物のお店（本番環境）に出す、という三段構えにするのです。本編で「ステージングで検証してから本番に出す」という表現が出てきたら、このリハーサルの話だと読み替えてください。

開発と運用のよくある勘違い

ここで、初心者の方が持ちやすい勘違いをいくつか整理しておきます。

まず「テストは開発の後に付いてくるオマケの工程」という見方です。実際の開発では、テストにかける労力は本体を書く労力と同じくらいか、それ以上になることも珍しく有りません。しかも近年は、自動テストが充実しているかどうかが開発スピードそのものを決めるようになっています。味見の体制が整っているキッチンほど、新メニューを安心してどんどん出せる、というわけです。

次に「リリースの回数は少ない方が安全」という直感です。これは気持ちとしてはよく分かるのですが、実は業界の調査では逆の傾向が知られています。半年分の変更をまとめて一度に出すと、何かおかしくなったときにどの変更が原因か分からなくなってしまいます。小さな変更をこまめに出すお店の方が、1回あたりの失敗が小さく、原因もすぐ特定出来て、結果的に安全なのです。本編で「デプロイ頻度」が優秀さの指標として出てくるのは、この理屈によるものです。

そして「障害ゼロが優秀な運用チーム」という評価軸です。もちろん障害は少ない方が良いのですが、プロの世界で本当に見られているのは、障害の数よりも起きたときにどれだけ早く復旧できるかと、同じ失敗を繰り返さない仕組みを作れるかです。本編に出てくる「ポストモーテム」（障害の振り返り記録）は、犯人探しではなく再発防止のための反省会の議事録だと思ってください。

本編用語との対応表

今回のレストラン営業の例えと、本編で実際に使われる用語の対応を一覧にしておきます。

本編との繋がり

今回の話は、本編では「開発運用アーキテクチャ」カテゴリで詳しく扱っています。リリースの仕組み作りから毎日の営業、障害への備えまで、まさに今回のループを速く安全に回すための工夫が主題です。

概要 ― 作って届けて動かし続ける一本の流れ ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-devops-overview/

この記事に関連する記事

【IT知識ゼロからOK】Webサービスが動く仕組み ― 生成AI時代のアーキテクチャ超入門・基礎編senkohome.com/arch-intro-basics-web/【IT知識ゼロからOK】サーバーとクラウドの基本 ― 生成AI時代のアーキテクチャ超入門・基礎編senkohome.com/arch-intro-basics-server/【IT知識ゼロからOK】セキュリティと認証の基本 ― 生成AI時代のアーキテクチャ超入門・基礎編senkohome.com/arch-intro-basics-security/

まとめ

本記事は基礎編の最終回として、開発から運用までの流れをレストランの営業に例えて解説しました。如何だったでしょうか。

開発は新メニュー作り、テストは味見、リリースは提供開始、運用は毎日の営業、監視は健康チェック、そして障害は起きる前提で備える。この対応関係が頭に有れば、本編の後半カテゴリはかなり読みやすくなるはずです。

これで基礎編の全6記事は完結です。ここまで読んでいただいた方は、本編を読み始める準備が十分に出来ていると思います。まずはシリーズの歩き方から、興味のあるカテゴリに進んでみてください。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。