こんにちは。フィックスポイントの冨です。

「サービス・イン」という言葉は「リリース」「ローンチ」などとも呼ばれますが、新しいサービスが正式に開始される意味で使われています。

開発者目線では、この「サービス・イン」に向けて作業を進めていくわけでして、非常に重要なマイルストーンです。
一方、運用担当やサポート担当の目線では、「サービス・イン」の日からが本番です。監視を含めた運用業務やユーザー対応は「サービスイン」の日から正式に始まります。

ひと昔であれば開発終了後、運用担当にシステムを引き渡して終了というプロジェクトも多かったわけですが、最近ではそのようなプロジェクトの考え方は古いものになっています。
「サービス・イン」後も開発者の手を離れないシステムも多くなりました。

分かりやすい所であれば、スマートフォンのアプリの更新頻度を見てください。
ストアアプリを見てみると、ほぼ毎日、数アプリが更新されているかと思います。
更新リリースの頻度が上がっている背景には、いわゆるバグ改修の他に細かいUI改善やパフォーマンス改善、ゲームであれば新しいシナリオ／キャラクターの投入など、継続して使い続けてもらおうと、リリース後も継続的に開発が進められています。

つまり「サービス・イン」や「納品」は開発チームにとってもゴールではなく、一つのマイルストーンに過ぎなかったわけですが、その傾向が更に顕著になってきています。

開発の考え方にしてもCI/CD（継続的インテグレーション／デリバリー）といった手法・考え方が広まってきており、それらをサポートするシステムも増えてきました。

極端な話、以前は「保守フェーズ」と称され、何か問題が発生したら対応するといったスタンスから、サービス終了時までひたすら開発・改修が続いていくといった考え方に変わりつつあります。特にB2Cのアプリは「リリースしたらおしまい」ではビジネスが成り立たなくなるでしょう。

アジャイル開発にも言える事ですが、小さい粒度の変更をテスト～リリースをするような作業は手動でも出来ますが、その頻度が上がるに連れて、自動化することで品質向上、効率化が見込めます。

言い換えれば、開発の初期の段階からサービス・イン後の継続的な改善リリースに向けて、開発の方法論、インフラの在り方、リリースや運用の自動化などを考慮して準備を進める必要があるわけです。

ひと昔のような開発担当と運用担当が分業し、完成したら運用チームに引き渡しておしまいといったITプロジェクト自体が、もはやDX時代には通用しなくなってきています。
また、システム運用自体も高頻度リリースかつ安定稼働を求められるとなれば、デプロイ、テスト、変更管理 etcと、もはや人力での対応は困難です。

昨今、話題の「DX」となると利用者接点での操作感やビジネスモデルにフォーカスがあたりがちですが、それらを安定して支えるインフラ運用の方法論も合わせて起動修正する必要があります。