はい えっと20名以上の参加者になりましたの でそろそろ始めたいと思い ます改めましてえ今日はライブオン サービスナウのえ8月のえウェビナー セッションになりますテーマはモダン チェンジマネジメントえサービス オペレーションワークスペースで変更管理 は近代化ということでえ新しい行管理に ついてえご説明したいと思っています よろしくお願いいたし ますはいで今日のスピーカーですけどもえ いつも私1人でやってきてましたがえっと 今日はですねあのオーストラリアから マイクランパードが えっとスケットで来てくれておりますで あの私はえが説明しますがマイクは日本語 が喋れるわけではないんですがえ変更管理 とかリリース管理のえ分野での エキスパートなので皆さんご質問がある 場合は是非あのじゃえっとQ&Aのところ にですねあの日本語で結構ですのでご質問 入れていただければマイクがあの機械翻訳 を使った形でえ回答してくれますのでえ 是非そちらをご活用くださいえというのも ですね今日はあのかなり参加者の人数が いつもより多いのでえっと本当は あのご質問を後頭で えしていただく機会も持てれたならなと 思ったんですけども今日はちょっと人数が 多いのでそういった形でえっとご質問はQ &に投げていただくような形でお願いし たいと思いますはいえっとチャットの方に もですねマイクからご挨拶が来てますので 皆さんよろしくお願いいたしますはいえと いう感じですねであの私も前君も同じえ アウトバウンドプロダクトマネージャー ITSmbuのアウトバウンドプロダクト マネージャーでえ同僚としてえ普段一緒に 働いているもになりますよろしくお願いし ますはいえであといつものセーフハーバー ですねで特に今日は あのお時間があればですねロードマップに ついてもう若干あのお話がありますのでえ そちらに関してはえっと 製品の購入えよとで判断していただかない ようなことをでお願いしますていう感じ ですねはいあとは えウェビナーえ今回申し込みいただいた皆 さんはこちらのサイトえコミュニティ サイトからえアクセスしていただいたかな と思いますであのこちらのコミュニティ サイトに今後も色々なえウェビナーですね アイムえサービスオペレーションズえオス とか色々えまあとはzanaDo新しい バージョンですね来月出ますけどもそちら のご紹介等もありますのでえお申し込み いただければと思いますまたあの今回です ねご質問が多くて時間内に回答できなかっ た場合につきましてはあのコミュニティの このウェビナーウェビナーのあのスレッド にですねあのご質問えをえ投げて いただく機能がございますのでそこでご 質問いただければええっとこちらからです ね回答させていただくようなことも考えて おりますのでえご活用いただければと思い ますはいえでリンクですねリンク の貼り付けをし ます あらうんと コミュニティサイトのリクを逆 にますはい えQRコードがこのリンクからえ行って いただければと思い ますはいではえあはですね ハウスキーピングですけどもえQA ちょっとお時間今日あの結構盛り沢さんな のでえ当で回答する時間が持てないと思い ますのでえ極の円のえボタンからえご質問 を投げていただければと思いますそれから えプレゼンテーションの様子はえ録録画さ れますなのでえっと先ほどお話ししたえ コミュニティサイトのこのええセッション のえスレッドでえご確認いただけますと いうのとえそれからえっと見られなかった 方はですね是非え活用してあのシェアして いただければと思います 終了後えアンケートいうのご回答もお願い いたしますこれはまあ大体いつもと同じ 感じ ですはいで早速ポールですね投票お願いし たいと思いますえっとまず1つ目の投票 ですけどもえあなたのイメージする皆さん のイメージするモダンチェンジ マネジメント新しい変更管理ってどんな ものなんですかということで えっと複数選択なので皆さんがイメージさ れてるものが当てはまる ものについて えとお買いといただければと思い ますあら ちょっと はいお願いしますえできれば30秒以内に お変えていただけると嬉しいです はーいありがとうございます大体出揃った かなという感じですがはいじゃあ示させて いただいてえシェアし ますはいえこんな感じですかねあ見えて ますか見えてない あはいはい自動化の促進が69あもっと 多いのがより正確なリスク管理リスク管理 にえ結構興味がある期待があるのかなそれ からえオートメーションですね自動化はい 変更タイプ今日はちょっと変更タイプのお 話もさせていただきますはいそれから大量 の変更を管理する迅速の変更可能にする はいえより良いえ経験とエクスペリエンス はい実はあのこちらの項目えっとその他と 全く分からない以外は全部当てはまります 今日お話しさせていただく内容になります はいええ ね是非えご確認いただければと思い ますはいじゃあえ共有を停止いたしまし てまた後 でもう1つコールがありますのでその時 またよろしくお願いしますはいでは早速え 新しい変更管理のテーマでお話ししたいと 思います はい今日のセッションは今までとちょっと 違ってですねデモはちょっと少なめ最後に あのデモしますのでそれまでなかなか イメージわかないかなっていうところも あるんですけどもちょっと今日は新しい 変更管理とはどういうものなのかえ従来 どっちが従来とどう違あってそれをえ サービスオペレーションズワークスペース を使ったサービスなの新しい変更管理で どのように実現していくのかについてお 話ししたいと思います特にえ変更管理の プロセスオーナーさんにお聞きいただき たい内容なので えともしもですねえ皆さんのえ組織戻られ てえ変更マネージャーさんとかがもしも見 慣れてない場合は是非ご紹介いただければ なと思いますはいあそうですねえ変更に 対するモデルベースのアプローチえについ て今日えちょっとお話ししますけれども今 従来の変更タイプを使ったものではなくて 変更モデルを活用した形のベースの アプローチで新しい作業方法に適用してえ 既存のえあアテルの変更アテルベースの 変更のやっぱり えっとあの良くないところていうのをえ 改善する乾燥化した形にできるそして自動 化を促進して変更の速度よ量安定性と ガバナンスを向上させるというものになり ますはいでえまちょっとこちら細かいので えと全部お話ししませんけれどもえ ジャーニーがありますというのはえっと 重大型のえっと変更管理を使われてるお客 様っていうのはやっぱりそこからですね 今回お話しする新しい変更管理え統合変更 管理っていう風にまええ英語だと ユニファイドえチェンジマネジメントて いう言い方をしたりとかするんですけども えに移すためのえ手順っていうかステップ がありますとでそれをちょっとお話しし たいんですけどもえっとまずエントリー ポイントとしてはえ複雑さと期間を減ら すって書いてありますけどもレガシー ワークフロー実はサービスなでえITの 変更管理を導入されるとえっと従来だと 通常の変更と緊急の変更と標準的な変更の 3つのえ変更タイプのいずれかでえっと 作業していくという形になりましたでそれ だとちょっとえっとなかなかいろんな ところにえと弊害が出てきてましたという ことで変更管理が実際えっと遠隔の足かせ になってるっていう部分があったのでそう いったところをえ新しい変更モデルを ベースにした変更管理するためのえっと こう基盤を作らなければいけないんですと いうことなんですねでそこ基盤を作 るっていうのがエントリーポイントですで ただしえ変更してですね従来のえ変更え プロセスを使いながら徐々にあの新しい 変更モデルにえ移行していっていただく ことができますよっていう話ですねえが エントリーポイントになりますまず基盤続 そうその後に今度はガバナンスの適正化 っていうことで えっと変更のポリシーだったりとか ステータスのえま部品化をすることによっ てえよりえ強固なガバナンスをしつつ メンテナンスも楽になるようなそんなえ形 でえガバナンスをえっと変更ポリシーと それからリスク管理といういた形でえ整備 して えいくという形ですねはいでえっと全てが だんだんこうえ整ってきましたらやっぱり そのどんどんデータドリブによる自動化 っていうのができるようになったらいいか なと思いますので例えばそのリスク評価を 自動化してとかえパフォーマンスをあえ あの結果の確認を えっとAIに任せるとかねいろんなことで えあらゆるところで自動化を進めていくと いうところそしてえまあの特にアプリ開発 になってくと3つ目のえっとステップとし てはトレーサビリティとベロシティを促進 するってことで変更の速度をもっともっと あ高めていこうっていうことでえっと devopsを導入されてるお客様は cicdツールと連携した形の devopsチェンジベロシティていう 変更え管理ツールがあるんですけどもそれ を活用した形でえっとdebOPSの変更 のえ自動化をえまガバナンスを聞かせた形 でやっていきたいといったようなえことが あるかなと思いですそのえステ3つの ステップでえできればなというえお話です はいでまなぜ新しいえ変更管理なのかって いうお話なんですけどもまずはあの変更に 関連して利用者が直面する課題っていうの をえお話ししたいと思いますま多くの利用 者にとって通常の変更っていうのはあの 過重な負荷となっていますですねビジネス をたくさんえ組み込んだりとか緊急時や 標準的な変更でできないえその他の変更 全て通常の変更でえ対応できるように あらゆる えっとなんて言うんですか条件をげ 継ぎ足ししていった形になるとそのなんか こうまるでえっとガラパゴスガラパゴスっ て言わないですかねねんなんて言うんです かねそのバベルの塔みたいなですかなんか そういった形で通常の変更カスタマイズを えせざるを得なかった状態から振り返って みるとじゃあこのななんかこう巨大化した えモンスターみたいなえ通常の変更どう どうするんだみたいな話だとかえそれから えっと使いきれないっていうような問題が あったりとかしますで神聖地のあの繁雑さ を回避するえしたいというえ一心でですね 通常の変更をえ使わないで無理やり標準的 な変更でえなんとかやろうとかですねそう いったものがあったりとかしますそれから 第2の課題としてはえっとレガシーの変更 プロセス先ほどもお話した通りあの巨大化 してブラックボックス化してしまったので えこれをこの今更この通常の変更 えとを いじる分割したりとかえいじるにはリスク が大きすぎるとインパクトが大きすぎるの で手をつけられないっていう問題があっ たりとかそれからえっと 3つ目の課題としてはチームが迅速に イノベーションを起こせるようにすると 同時にリスクを最小限に抑えたいという 名題が今あると思います皆さんのえっと ホールですね投票の誤解答にもありました けどリスクって結構重要なポイントですと でそこでえやっぱり気をつけなきゃいけ ないのが あのそのよ特にアプリケーション開発だと かまコーディングコードだとかデータとか それからえワークロードのえ調整だとか インフラの変更と言ったようなあらゆるも のっていうのが実はインシデント パフォーマンスに関連するインシデントの 85%えガトなーに言われてますっていう ことがありますねこのようなインシデント を迅速に取りしてえ取りしてえあるいは 未然に防ぐというようなことを考えた時に ちゃんと変更のトレーサビリティも意識し なければいけないですよっていうえ話 そして最後にリスク評価っていうのは手 作業え今までは手作業でえ主観的でその 結果実態と合わなかったりとか系外化して もう何も見ずにえっとチェックをしてえ 済ませるみたいなそんなこともあったりと かするでそんな課題があるかなと思います なでそれに対しての回答としてサービスな の新しい変更え管理というのはえ変更 タイプではなく変更目的にあった変更 モデルを作成してえ目的ごとにちゃんと えっと正しくガバナンスを聞かせられる ようにしましょうっていうのとそれから えっと承認ポリシーですね承認ポリシーっ ていうのもあのそれぞれのえタイプごとの ワークフローに埋め込まれてえよくわから ない条件で承認がされてるようなものでは なくってえっと部品化して使い回しできる 自動化できる承認ポリシーっていうのを 採用しましょうとそれからデブオプス インテグレーションに関して言うと先ほど もお話しましたけどもえっとデブス環境に おいては えっとCICあらゆるですねえっとジラと かジェンキンスとかえギットハブとか えっとあえっとアルデボとかそういった ツールと連携しながらパイプラインによる 変更作成の自動化とえトレーサビリティの え推進を図りましょうという話それからえ 動的リスク評価ということでえ先ほども皆 さんからえっと要望がえたくさんあったか と思いますけどもリスク評価を簡単に しかも正確にえやるにはやっぱり人間が やるには限界がありますよということでえ 自動的にまダイナミックにですねその時の えっと条件にあった方でリスク評価すると いうようなことがえま紹介されますですね はいでペルソナに関して言うとえっと今 までと変わらないですね変更要求者とそれ からえ評価承認を行うえとピアの レビューアーズ 政オーナていうのがこの新しい変更管理に おいてもえ関わっていくペルソナとして えご理解いただければいいと思います そしてやっぱり変更要求者っていうのは できるだけ気表時間気表にかかる時間を 短くしたいですっていうえニーズだとが あります えなるとねどうしても書く内容っていうの がえすごいこう簡素になってしまったりと か不足部分があったりとかしますそうする と今度はえレビューアの方たちが困りま すって形ですねえ自分の専門え知識を 生かした形でレビューをしてえやっぱり そのリスクのない形でえ評価承認したい ですけどもえどうしてもえリクエストええ レコードえ変更え変更要求レコードドって いうのがえ内容がえっと不足が多いのでえ ここで差し戻しが発生したりとかえより 追加な確認しなきゃいけないってすごいえ 手間な作業が発生するということそれから 変更プロプセオーナーにしてみるとえ 先ほどら話してる通りメンテナンスして皆 さんが都合のいいようなものにえプロセス をえ置換えたいんだけどなかなかえもう手 をつけられない状態になりますと言って ような問題がありますなのでそれをま解決 するにあたってえ先ほど4つご紹介 えタイトルをお話ししましたけども4つの え新しい機能ですねの考え方をえ今日はご 紹介させていただきたいと思いますはい まずはええ目的主導パーパスドリブンのえ 変更モデルについてのお話をさせて いただきますで変更モデルの概念っという のはITのバージョン3のえ2011年版 以降で提案されて新しい考え方になります えとはも10何年経ってますけれどもで 変更モデルにより従来の変更タイプの不便 さを解表して重大柔軟なガバナンスを使 せることができるようになってますという 話ですなのでちょっと変更モデルの浸透 具合について皆さんからちょっとえっと 投票いただきたいんですけどもえ2番目の 投票ですね変更モデル実際使い始めてます かというご質問させていただき ますはい え出て くなか いあ あし はい ああ間違ったも間違えましたもう1回 再開再開できるのか 再開すいませんもう1回投票お願いします ちょっとオペレーション見去ってしまい ます あ結構変更モデルお使いのお客様が思った よりいらっしゃるなといううんそう いう感じです ねはいえありがとうございます えっと投票終了し ますはいで結果を共有させていただきます がはいえっと始めた方ばかりの方ともう もうしばらく使ってますって方合わせると 9名ですね27名分のえ9名の方が いらっしゃって大体30え3%え1/3の 方がえ始めてますとでまだ計画してない方 が41それからえ聞いたことがないって いう方が 22その他が1名という形でしたはいでは えっとま結構ご存知の方いらっしゃるなっ ていうところもありますので えっと飛ばせるところは飛ばしてえお話し していきたいと思いますありがとうござい ますはいでえっと変更モデルのご紹介に なりますけどもま変更のタイプっていうの は聞いたことがあるかなと思いますITで 定義されてますねはいあの3つのタイプ です先ほどもお話しした標準的な変更と 緊急変更と通常の変更でこの丸の大きさ っていうのは皆さん多分平均的にですね えっとタイプことのボリュームのえ違いだ という風に理解いただければと思いますで 標準的な変更っていうのはえま頻繁に実施 してえ反反復可能なちゃんとしたえ実装 ステップがえあってその通りにやれば誰で も失敗しないリスクは低いえですね過去に いっぱい成功の実績があるえそして自前 承認されている前提なのでええ承認え許可 を取る必要なく実装できるものですねでえ 次に緊急変更真ん中ですけどもこちらはえ 大体が障害対応にありますね緊急にえ実施 しなければいけないこの変更を行わないと えインシデントが解決しないえビジネスに インパクトが大きいですみたいなものなの で本来であれば結構リスクの高い変更なの で通常の変更のえステップをこう踏みたい んですけどもえ緊急性が高いのでえ飛ば なきゃいけない部分を飛ばしますえそのえ 目に えっと専門家でえ構成されるえ緊急新聞 変更諮問委員会をでえ実施の許可を出すと かでもやっぱりどうしてもテストが不足し ていたりとか ええ評価項目が少なかったりとかでえどう してもやっぱりこうえ失敗が多いなので これはできるだけ数は減らしたいですと いうことですねそしてえ標準的な変更でも なくえ緊急変更でもなくえ 当てはまらないものっていうのは通常の 変更でえやってきましたっていうのが えっと皆さんえほぼ皆さんえタイプでやら れてる方のえやり方かなと思いますそう するとえあまりリスクがないものに関して もあの決められたことなので同じステープ を踏まなきゃいけないっていうそういう 問題がありましたでそういったものをです ね あの 解決しなければいけないんですけども実は サービスナウのえ中の構成ってこになって んですねえそれぞれのタイプの変更ごとに ワークフローがえ個別に用意されていてで それぞれで必要なビジネスルールが それぞれに作られていてサロ化した形です でタスクもえ1個1個に追加してるそして えステータスものせえ繊維もですね それぞれ個別にあっとえいうここんな形に なってるそうするとえとても メンテナンスがしづらいですね同じことが ビジネスルールがえっとそれぞれにえ用意 されていたりとか共有化しづらいような そんな構成になってましたでそれをえっと 改善しますっていう話なんですねでえっと 実はえ内訳見てみると あの通常の変更って何でもその標準的でも なく緊急でもないっていうえあらゆるもの が入ってますので全然性質の違う変更が このようににえっと混ざってるんですねで 実際これを1つの通常の変更のえとフロー でそしてえ条件で流そうとするとえすごく え無理があるんですということですね緊急 変更の特に無休化の変更ってありますけど もちゃんと承認を取ってえレコードを気表 して変更レコードを気表しなかったえ目許 の変更ってのはかなりの数あるんじゃない ですかっていうのありますはいなのでま こういった形でですねえっと実際にあそう ですねあるお客様は通常デブオプスの変更 っていうのは通常の変更じゃなくて標準的 な変更っていうのでや実現されてるお客様 もいるかもしれないですまとこんな形で えっと実際にえっと通常の変更特にですね 打ち分け見てみるとモデル化することに よってより効率的に作業ができるものって いうのがありますよっていう形なんですね なのでえっとここで初めてITのタイプ からえ変更モデ変更タイプから変更モデ ルっていう風にタイトルに変わりました けどもえ全部変更モデルとして定義し直し ましょうというのがえまずは最初の1歩 ですねなのでえ従来の変更の変更タイプ 標準的な変更通常の変更緊急変更もえ モデルの1つとして一応え定義し直して えっと従来のまま使いなえ使い続けること ができますで一方で数字の変更にあった けども実はえっといろんな別々のフローで 使いたいよっていうものについてはえっと 変更モデルていう方新しい変更モデルと いう形でえこういう風にえグループ分けし てそしてえっとですね行くという形になり ますねでそうするとどうなるかって言うと こういった形であのモデルの種類ごとに えっとステータスの変遷を定義しそしてえ もえっとあの実は個別にフローがあるわけ ではなくってえっとステータスがこの状態 からこの状態に移る時のフローはこれです みたいな形のえっと部品化されたフローを えっとそれぞれえっとトリガーを元に実施 していくっていうまそういうえ考え方に 変わってますそれがえ統合変更モデルのえ やり方ですねなっますでそれと同じ流れで このえっと従来の変更モデルだったものも あ変更タイプだったものも変更モデルに 置き換えられますそしてそれぞれのえっと 製品ていうか対象ですね対象の変更の対象 にえ見合った形の構造化データがえ アタッチメントされそしてえっと テンプレートですねえ例えば低リスクの 変更っていうのは1種類じゃないですよね えっとあのアプリもあのアプリもあの アプリも低ディスクでできますよねとか ですねデッスも何種類かあったりとかえ パッチ当てだったらこれとかですねま色々 あるのでそれぞれにテンプレートを用意 することによって余計な手入力を省いて この作業だったらこのえリスクがえ評価を しなきゃいけないですよということも含め てのえまテンプレートえ化されたものって いうのがえっとこの変更モデルごとにえ 作ることができるそんなイメージだと思っ ていただきたいと思いますはいで えっとこんな形ですよねえとそれぞれに 違ったステータス繊維がありワークフロー がありですね例えば低リスクだったらえ 評価許可をえあ評価を飛ばしていいですと かですねえスケジュールもえ飛ばしていい ですっていうものがあるかもしれないすぐ にやって自動化承認されるからとですねえ それからえここに登録ってあるのがあるん ですけどもこれは何かと言うとえ例えば サードパーティーの方にえ依頼している 定期的な変更だったりとかあるいはもう スケジュール化されていてあとは変更の 結果だけを確認すればいいよってものに ついていちいち人が気表するのではなくて 自動的に条件があったらレコードを作って えいきなりスケジュールされそして定義さ れたえルールに基づいてですねえ スケジュールされ実装が実施されてでその 結果をレビューすればクローズしていい ですよみたいなものもあるだろうしそれ からえ先ほどお話しした目許可の変更って いうのはアイテムを入れていればアイテム が えっと定期的にポーリングした構成情報の 情報に変化が発生した時はこれは無許可の 変更だということでえ自動的に変更 レコードを気表してえこれをちゃんと レビューしなさいよっってことを促して くれるそんなあのワークフローもあフロー もああると思いますということでこんな形 で変更モデルをいろんなタイプで作ると いうのがいいかなっていう風にえご紹介に なりますでちょっとここは上長なのでお話 を飛ばしますがえ従来の通常えの変更それ から標準的な変更って実はえっと メンテナンスがすごくめどくさくてえ 例えば標準的な変更も何でもかんでも えっと標準的な変更で作ろうとすると えっとカタログがいっぱい出来上がります 標準的な変更のリクエストのカタログが いっぱいできるでそれを1個1個個別に メンテナンスするえていう手間があるので えできるだけやっぱりそのえっと テンプレートを使った形でグループ化した 標準的な変更っていう考え方もありだよ ねっていうまそういったことも含めて えっと新しい変更モデルを使った形での えっと運用ですねプロセスのえ設計って いうのをこう基盤を構築し直す形で考えて いただければなと思いますで特にそこれ からお話しするのはその変更もモデルで低 リスクのカテゴリーに入ったものっていう のはあの実はえっとリスクが低い分え人間 が承認しなくてもいいようにえできる部分 がありますという話があるのでそこは承認 とかそれからリスク評価っていうところを で是非どんどん自動化していきましょうっ ていうのが対象がこの低ディスクの えっと変更モデルになりますなので ちょっとその話をこれからしていけたらな と思いますはいはいでえっと変更承認 ポリシーにえいきますで変更承認ポリシー では えっと承認フロっていうのを近代化し ましょうっていうえ考え方ですねであの 従来の左側にあります今までのえ変更の 承認ってどうだったかっていうとあの ワークフローの中に隠されててえっと実際 に例えばその えっとどんなえ と対象変更の対象だったらどんな承認え ルートを通るとかですねネットワーク系 だったらないみたいなえまそんないろんな カテゴリーえ対象のカテゴリーごとに グループ証人グループがいてとかてことを こう定義してたりとかしますけども実際 ちょっとあまり表に見えないでワーク フローに隠されたロジックがあるとそれ から えっと リス評価に関あ承認についてはえ完全にの 判断に任せるですね人にえっとま責任を 負わせるっていう言い方になっちゃいます けどもやっぱりその実際にいろんな条件を え評価してえ本当にえ承認していいかどう かっていうのはその担当者えの人たちの 能力にえかかってしまいますよみたいな とことかワークフローえは複雑化していて 本当はやらなくてえいいものえについても えやった手でえここでスキップします みたいなあとタスクをえっと実行したこと にしますみたいなえあの本当に本来やら なくていいことをえ縛られてやらなきゃ いけないからステータスモデルっていうの も柔軟性がないですみたいなことでえです でそれに対して新しい変更モデルをにおけ る承認ポリシーっていうのはえフローから 切り離した形でモジュール化っていうかえ 部品化していますとでえっとそれらのえ ポリシーを自由時代にこのポリシー使い たいですって言ったらえっとそのモデルに 組み込んでえ使うっていうようなえこと ですねであらかじめえ会社として定義され てこれは守もらなければいけないよこれは え承認する時には確認しなきゃいけないよ みたいなえコンプライアンスポリシーに 関する情報っていうのをえ取り込んでそれ を自動的に判断してえ誰がえやってもえ 自動的に同じ結果が出るような承認ポリ シーっていうのが えっと使えるようになりますでフローもえ ステータスベースでえっとステータスが これからこれに変わった時にはえこの えっと次にこれをやるみたいなえま定義が されているですねステータスモデルもえ 部品化した形で使えるようにいう形になり ますで例えばえっと平行商品ポリシーの 自動化ルールについてはこんな形になり ますえっと承認ポリシーですねええ前の ページでお話しした通り例えばえっとこの 変更の対象のサービスってどれだけ重要な のだですねインパクトがどれぐらいあるの かとかそれからえリスク評価の結果はどう だっただろうかとかそれから変更の フィールドの完成度えですね要は変更え リクエストの内容がちゃんと埋まってるか それからえっとスケジュールに コンフリクトがないかとかリードタイムえ に無駄えっと無理がないかとかえそれから 実際に実装するチームの えっとスキルですねえせ過去にどれだけ 成功してんのかとかそれからこのモデルっ て失敗がしたことないのかみたいなデータ とかあるいはデブオスだったらえっとデブ オスのツールとの連携でコードカバレージ どうかとかテキストテスト結果は何 パーセン以上クリアしてるかとか セキュリティスキャンは終わってんのか みたいなそんなような情報もえ変更管理の 方に取り込んででその承認をしていいか どうかの条件をこののようにですねえ コンディションビルダーで作ったあ状態で このクライテリアにえをパスしていれば 自動承認しちゃうていうえ形を取りますで それがえ全然ダメだったら否認しますし えっとグレーなところであったらえっと 人間によるマニュアルレビューを依頼する みたいなそんなような条件をあらかじめ 設定することにしますでこれがなぜうまく いくかって言うとサービスナウだからです ねやっぱりプラットフォーム上にあらゆる データが集約されて1つの上え プラットフォーム上にアクセス可能な状態 になってるんであらゆる えっと その変更対象のCIに関するえ情報がえ 承認のえ要素として使えるので自動的なえ 承認が可能になると承認判断を自動的にえ 行うことができるというものになります はいそしてえダイナミックリスクですね じゃあその先ほどえ自動承認することが できますよって話になりましたけどもえ リスク評価はどうするのって話です先ほど の自動承認のところでもリスクの えっと代償もえっとやっぱり自動承認のえ インプット情報になるべきですよねって ことじゃあリスクはどうやって評価するん ですすかっていう話ですけどもこれがえ ダイナミックリスク評価といってえ4つの タイプのリスクを組み合わせした形でえと 使えますでこの4つは全部使ってもいい ですしえどれか1つで適切なものその変更 モデルに適あの適正なえふさわしいえっと リスク評価のえツールとしてえどれか ふさわしいものを使っていただければいい と思いますはいでまずリスクアセスメント ですけどもこれは従来型のえっと アンケート形式でえリスクあすいません 変更えのオーナーさんがそのリスクを評価 をするでえ実際にいろんな えっと例えば変更の複雑性はどうですかと かそういったようなインタビューに答えて いってもらってその結果リスクを高いえ中 くらいえ低いみたいな形のえ検証をする今 までとあったものですねえそれからリスク 条件っていうのはえっと様々な えあらかじめいくつかの要素の組み合わせ でえ判断テーブルを作成しておいて条件に 合致したものを該当するリスクレベルに 振り分けるといったようなそんなえ考え方 ですねえやっぱ複雑製品の複雑作業の複雑 性とかも含めてえ先ほどインタビュー形式 だったんですけどこちらはえっと条件とし て組み込むこともできるかなと思います それから3つ目のえ計算されたリスクスコ アっていうのは えっと成功確率っていうあの先ほどえっと 成功スコアのお話をちょっとさせて いただきましたけども成功スコアていうの はえっと実施するチームが過去にどれだけ え成功したかスキルがどのぐらいある かっていうえま指標ですねそれとそれから えっと今え気表された変更のモデルが過去 にどれだけうまくいってるかどうかえ実施 した結果がどうかっていうそういった データを元に成功確率っていうのサービス ながえっと計算して成功確率が高くて インパクトですねが低いものはえっと リスクは低いえ逆に成功確率がえ低くてえ リえっとインパクトが高いものははいと いう形で3段階でえリスクの評価をえする というのが計算されたリスクスコアになり ますえそしてそのえっと成功スコアです けども音になって成功スコアっていうのは 過去にえ成功した変更が えいっぱい変更してたらえっと上すとして かえ数数か3とですね失敗してたら数 かけるえ-5とかでかまこんな形でえ パラメーターを用意してその結果その チームのえ変更スコア成功スコアっていう のはどうですかっていうことをえ数値化し ておきますでそれを確認する ダッシュボードにますえがえこんな形で これはパフォーマンスアナリティクスの 日時ジブでえ毎日え実施された変更のえ 結果が計算されてえっと記録されでそれを にリスクえを評価するというものですで えっと最後のえ4つ目のえリスク インテリジェンスですけどもこちらは えっと機械学習ですねえAIを利用して 過去の変更の情報をバーっと読み込んだ形 でこれってえ人の判断とかえそういった ものとは別にえAIがですねあの読み込ん だ情報から学習してこの変更はこんな リスクがあリスクある高いよねみたいなえ ことをえっと定義しててくれるものになり ますはいでいうことでこの4つタイプをえ 組み合わせしたりあれば1つ採用するでも いいんですけどもという形であのリスクえ 評価をしていただくとするとえどんな 仕組みかって言うとま4つ3つやりたいで すっていう形でリスク条件のとそれから リスクえアセスメントとリスク インテリジェンスを使って私このモデルは 評価しますて言うとこの3つのえ評価結果 をこうやって較しますえリスク条件につい ては中程度リスク評価は低いえ えっとリスクインテリジェンスは中程度あ こちらに3質も入ってますね4つの 組み合わせした中で1番高いものっていう のがリスク評価結果として採用されますと まこんなようなロジックになってますなの でえ万が一え低いリスクリスクの低いえ 変更だと思って始めたけどもえどうやら えっと評価された結果高いって言われまし たのでえっとマニュアルの承認をしなけれ ばいけないねみたいなそんな条件になり うるですねこんな形で先ほども出てきまし けどダイナミック承認エンジのところで えっとリスクがえ高かったっていう場合は えっとマニュアルデビューにえまこう ルーティングされるっていうそういった 変更管理の考え方になりますこれも自動的 にですねあのステータスが選しますのでえ 形ですはいでちょっと時間もえ押してき ましたけどもえっと簡単なデモをちょっと ご紹介したいと思います今までちょっと ずっと私が喋ってきたので多分イメージが 湧きませんっていうえまフィードバックが あるかもしれないなと思ったのではい えっとでもですねあこちらあの変更のえ 実務をやる方ですねえになります でこの方がですね例えばま インシデント自分が担当してる エスカレーションされたインシデントの 解決 をしますみたいな形でえっと解決策の実施 には変更 えしなきゃいけないってことでここから 変更要求を作成するていうあこれあの サービスオペレーションズワークスペース というですねエージェント向けの あの新しいインターフェイスの画面になり ますはいでここからそのインシデントの 開いた後に変更要求を作成ということで 変更のランディングページがありますで ここで変更モデルごとにこのえパネルがえ カードですかねえ表示されますのでえ自分 がやりたいえモデルを選びますですねで えっと今回はクラウド インフラストラクチャ コンフィギュレーションとことでえ クラウドサービスえ放射オンラインという クラウドサービスの えっと容量の拡張すえテンプレートを実行 するというえことをやりたいのでクラウド インフラストラクチャーの コンフィグレーションの多分これはえ リスクが低いんですねえ何回もえっと実施 できるものであらかじめ定義がされてる ものが使えるのでこれを えっと選んで次へと形ですねそうする と基本的にはですね変更エストが インシデントから気表されると簡単な説明 のところがインシデントのえ簡単な説明が コピーされてきますとでこれじゃあえっと 変更レコードとしてはですねあんまり ふさわしくないですねはいでま ちょっとそういう状態であるんですけども ここでテンプレートここに右側にいます テンプレートをえっと適用したいと思い ますはいでテンプレートえっとクラウド インフラストラクチャーのえっと変に関し てはテンプレートが今4つ用意されてます よということでえっと今回ポシャオン ラインというですねアプリケーション クラウドアプリーのえインフラのえ変更な んだということでテンプレートをこれを 当てていきます若干ちょっとワーニング出 ましたけどもえこういった形でえっと テンプレートを当てると詳細情報がこの ようにですねブランクだったのがえ あらかじめ えテンプレートに用意されている内容で えっと更新されあの埋め込めれましたと いうことでここでいちいちですね気表者が えっと変更の内容ですねえ詳細についてえ 1つ1つ書く必要がないというすごく便利 な機能になりますはいでさらにこのえっと 詳細の概要に戻っていただきますとあこれ じゃないこちらでしたえっとですね変更 レコードの外に戻っていただきますと えっとステータスごとにですねここのえ出 てくるよえ項目が違っててえっと今現在 新規なのでえまずはサマリーを入れ ましょうねとかスケジュールを確定し ましょうねって形でナビゲートされますの でえそちらえをに従ってやってくとで こちら今あの えっとクラウドインフラストラクチャーの モデ変更モデルだったのでこういった ステータスの繊維ニューオーソライズ インプリメントクローズドキャンセルでえ 若干何か足りないなって思われてる方 いらっしゃると思うんですけども例えば えっと通常の一般的な通常の変更の レコードを見てみる と新規評価フルスペックですね人気評価 許可スケジュール済み実装レビュークロー ズっていうえまキャンセルも入れると8つ のえステータスで遷移していくというもの ですけどもえこ今回のクラウド インフラストラクチャーの変更に関して 言うと えで言うとえ新規オーソライズ インプリメントクローズというよえっとま キャンセルも5つというステータスで 終わるとまこんなものですねで今現在 ニューなのでえっとアサインね自分に アサインでアサイン先グループえクラウド インフラスポサポートスタ タースを えっと用意してえスケジュール をセットしますでスケジュールは明日明日 やりたいですみたいな明日の今の時間から 1時間みたいな感じ で1時間と形で でリクエえ保存してみます あら影響を 受けるあと情報量が情報が 足り放射なですねすいませんはいで えっと保存します ねでえっとスケジュールの変更 に関して言うとえっとあちょっとうまく 動かないですねすいません別の新しい こすいませんちょっとうまくいかないので [音楽] うんと大丈夫 しました はいえっと新しく今作りましたで テンプレートを放射編オンラインクラウド インフラでえ設定しまし た設 てアサイ先グループで あうまくいかない し くださいでこ 行こ うん とあ すいませんちょっとライブでやってるので よ予想外の事態が発生しますがえっとどう しようか なはい えっともう1回 新しくえ よしじゃオンラインを実際えっとどうし たらかと言うとですね えっとかと変更のディスク評価のところも お見せしたかったんですねえっと 変更あオープン オープンこれでどうか なあそっか新規じゃないとできないんです ねああのちょっとあのお見せできなかった んですけどもここでえっとえリスクスコ アっていうのがありますよねであのリスク を入れていいいてそしてさらに変更の成功 スコアのところでこのチームですねえっと 放射オンラインのクラウドの えっとクラウドインフラストラクチャーの えサポートスターズのチームがどれだけの 能力を持っていて成功してるかでこのモデ ルと100%成功ですよっていうことで リスクのスコアのえ判断についてはえ評価 がこうなりますただえっと多分 アセスメントを入れたところでえっとこの システム放射オンラインシステムがえ ものすごく重要なえっとアプリケーション だということでえリスク作業のリスクは 少ないんだけど要注意のえインパクトが ある製品ですよということでえ中という風 な形でえリスクがえ評価されたという形に なってるかなと思いますはいちょっと 出来合いのものでえ補足説明させて いただきましたけれどもはいえこの形で 評価がえ自動的にされますと本当は ちょっとお見せしたかったんですけど えっとごめんなさい今っと環境がえうまく いかなくてですねえそんな形になってます はいで形でえ概要についてはえ オーソライズが終わるとえっともうえ今回 のえオーソライズが自動的に あオーソライズを要求すると自動的に実施 されたことが分かるんですねでそれも ちょっと本当はお見せしたかったんです けど適用された変更ポリシーっていうとこ を見ると今回はえっとリスクが少なかった ですということでオートアプルーブがえ ポリシーとして適用されましたということ で人を返さずにえ承認が置いたのでこれの ステータスですねがえオーソライズから インプリメントのところに移ってますで インプリメントに移った形でえじゃああは 作業するだけという形でえこですねクロー 作業した内容をえクローズコードに入れて クローズメモ って形でえま更新すると でクローズねそうするとインプリメントが 終了してクローズの状態に移りますという ことであのせっかくちょっといいところお 見せできなかったんですけどもえっと リスクの内容を判断してえと変更ポリシー がえっと承認ポリシーが自動承認をして インプリメントに移ってクローズといった ところがえま確認でしていただけたら 良かったかなと思いますはいということで えっとちょっとでもバタバタして申し訳 なかったんですけど えっとスライドの方に戻りまし てWebオスによる変更の自動化という ことでえっと最後のえデブオスに関してえ ちょっと駆け足でお話ししたいと思います でデボスっていうのはあの えっとアプリケーションサービスごとに 開発と運用チームっていうのが連携できて いればいいんですけどもやっぱり持ってる 技術スキルやえスキルセットやですね組織 構造上異なる部門が実践をせざるを得ない いっていう問題があって継続的な デリバリーを実現するのがやっぱり難しい え現実がありますでまデブオップスを標榜 するえ組織でもですね多くのチャレンジが ありますで1つ目はまず可視性とビリティ ですね運用のチームにしてみると開発側で えどんなえっと品質管理がされて開発がさ れて品質管理がされているかってで今どう いうステータスなのかってことが全く見え ないまんまブラックボックスのまんま えっとリリースされてしまって運用が始ま るっていうことはやっぱりそのえっとも 使ってるツールも全く違うしえま情報のえ 今えっと可視性をええ設定しようとすると なかなか難しいえあとコンプライアンスの 欠場ですねでえっと実際ちゃんと変更管理 を通さなければいけない変更なんですけど もボックスもですねとはいええっと従来の ITITのえ変更管理だととてもじゃない けどその承認を待ってられないですよだ からもう勝手にやっちゃえみたいな形でえ 要はそのある例では94%の変更が変更 管理に登録されてない無え未承認の変更 だったっていうことがあったりとかします でそうするとやっぱりちゃんとガバナンス が効かないコンプライアンス違反のものが いっぱいあってやっぱりえっと失敗のリス クっていうのがえいっぱいある インシデントもいっぱい出るっていうこと ですよねえだからやっぱりちゃんと ガバナンスを聞かせる変更管理をしなけれ ばいけないんだけどデブオップスもだけだ からと言ってやっぱり従来の変更管理をえ そのまま適用するとえ2週間3週間1ヶ月 っていうえリードタイムがかかってしまっ てい現実的なので全然デブオップスを入れ たけれども全あの効果がない開発スピード が上がらないっていうまそんな問題がある でそれなのでやっぱりえっと開発者えそれ からアプリ開発部門庁変更マネージャー オペレーションサポートガバナンス担当の 人たっていうのがそれぞれにえ満足度が 上がるようなツールを作りましょうって いうことでえ開発したのがレボックス チェンジベロシティという製品ですでえ この製品についてのご紹介はそのえっと会 のえっとえオンデマンドウェビナーが用意 されてますのでご興味ある方はそちらを見 ていただければと思いますはいでえま どんな構造になってるのかって言うと あらゆるえっと世の中にある有名な cicdツールとサービスNowがえ接続 しまWebフックで繋がりまして情報を サービスなのとこに集めますえ例えば ワークアイテムですねえストーリーとかえ それからえバックログとかの情報えっと 進捗状況のえだったりとかあるいは開発 内容の え構成だとかそれからテスト状況だとか あらゆるツールからの情報をサービスなに 集めましてそれを元にえ変更えレコードを 気表して自動気表してそしてえっと 自動承認していいかどうかの条件を判断し てえそしてデプロイを自動的に許すとえ そんな形で人を一切返さないでえデブスの 変更が承認されてえまリリースされると いう形になりますでそれのえ結果について はこのパフォーマンスについてはえドラ ですよねそのえっとえdevopsで有名 なGoogleCloudのdevops リサーチアアセスメントが定義した評価 指標もえ含めた形でパフォーマンスを確認 することができるますはいでえっと関連 機能の紹介最後にさせていただきました ちょっと1分なってしまいましたけども ちょっとのちょっとえっと時間あの伸ばし てさせていただきますえっとどうしてもお 話ししたいのがこのデジタルプロダクト リリースですねDPRと呼びますけども えっと従来のリリース管理えバージョン2 にのお着換えとしてこれがえリリースされ ましたでこれな何かと言うとあの バイモーダルでえ従来型のウォーター フール型の開発の製品にもそれからえっと モード2のえデブスえアジャイル開発の えっとまいは継続的デリバリー対象の製品 にもえっと対応できるような形でえっと リリース管理を実際にやります要はえっと 各フェーズですねプランニングビルド リリーステストリリース準備デプロイまで のそれぞれのえっとフェーズをちゃんと えっとコンプライアンス守るように ゲートキーパーの役割をえとしてえ サービスナウのリリース管理がえあ デジタルプロダクトリリースがえ対応し ますよというえそういったものですねえ それぞれでチェック項目えポリシーをです ね設定しておいてえただしそのポリシーっ ていうのは一般的なものっていうのは サービスなにデフォルトで用意されてるの でえそれにえ皆さんの環境で追加して いただくだけですぐに使えるようになる ようなものでやっぱりえっとさっきのえ チェンジベロdbxGMGベロシティと 同じようにえこういったえあらゆる外部 ツールとの情報をえ評価しながら えっとガバナンスを聞かせていくというえ ツールになりますはいあとはもう1つナウ アシストですねえナウアシストはえっと サービスナウが提供する えっと生成AIの機能でitsmの あらゆるところでえ作業の効率化だとかえ まと宣伝された形のえ作業にするためのえ 人間をサポートするえ生生の機能あらゆる とこにえ散りばめられてるんですけどもえ いよいよえ8月リリースからですね変更 管理に関するえっとナアシストの機能がえ 追加になってますということをえご紹介さ せていただきますえどんな特徴がある かっていうとえ変更の内容の要約ですね サマリーえ全部読まなくてもリクエストえ チェンジリクエストをえ全部読まなくても えどんな変更なのかが分かりやすいとそれ からえっとコンフリクトだとかがえこの 変更によって引き起こされたインシデント どんなものかってことの要約をしてくれ たりとかえチェンジアシストとしては影響 がどこにあるのかとかリスクの原因は何な のかみたいなことが分かったりとかですね それから2月になるとそのバージョン2と かが出てきますけれどもえまえっと重大な インシデントの情報のえレポートの作成だ とかちょっと変更管理に限らないしいます けどもあとバックアウトプラン切り戻し 計画を書くのを手伝ってくたりとか基本的 な基準と予測に基づいてのリスク評価って いうのを要約して説明してくれたりとかえ そんな機能がつってますはいということで すいませんちょっとお時間になってしまっ たのでご質問についてはえっと8つほど ですねはいあのマイクthank マアえっと 何かご解答いだいてないものとかありまし たでしょうかあればちょっとチャットで コメントいただきたいと思い ますはいであと はお願いですね最後にあの今今日ご説明し た内容ってあのすごく集約されてますので えっと5回のシリーズものウェビナーが ございますえっとそれそちらの方はより テクニカルな形でえどこの管理えテーブル をこうすればこれが実現されるんだみたい なことも含めてデモを中心とした5 シリーズのモナンチェンジマネージメント というウェビナーの画面がありあ録画が ありますのでそちらをご参照いただければ と思いますそちら英語なんですけどもデモ 中心なので大体え分かっていただけるか なっていうのがありますあとはですね コミュニティのブログがえこういった形で 用意されてますので是非参照していただい てあとフォーラムにもえご参加いただけれ ばと思いますはい えっとそうですかあとえ日に質問とか なければ今日はちょっと3分ほどオーバー しましたけれど も えと大丈夫ですか何かあればコメント [音楽] いただけオラワ えどのえどの5つをさえ指してるのか 分かりえっとこの5つって言ってるのはあ すいませんこのえっと録画の話ですか どなたかご質問いただいた方ちょっと細く 説明いただきたいんですけどもえっと チャットで大丈夫です どの5つをさしてるのか分かりませんと 言ってのこの最後のページのお願いの モナンチェンジマネージメントウェビナー の録画 の変更の画面の中に出て たあすいませんえありがとうござい ます5つというの変更のあデモの中にあっ たものですかねえっとデモの この 12345番目がキャンセルとなので えっと5つ目が キャンセルえっとステータスですね ステータスのえ今回のこのクラウド フォーメーションテンプレートの場合は えっと4つのステータスの編成になって 最後がクローズなんですけどキャンセルも 入れると5つ目ですということかなと思い ます はいはいあとお願いのページのえリンクに ついては後ほどですねPDFでえっとこの えウェビナーのえとペえっとスレッドの ところにえアップロードしますのでその PDFのリンクをえ辿っていただければと 思いますが今ちょっとリンクを貼り付け ますねえっとこと どれがまずウェビナーあごめんなさい ウェビナーについて は after はい はいはいYouTubeのえシリーズもの 1回目ねりますはいえっとそれではえ他に ご質問とかあればですね先ほどもご紹介し たえっとこのええっと今回のウェビナーの ページのスレッドにえっとコメント入れて いただくえところがありますのでご質問を そちらに入れていただければと思います はいすいませんちょっとえっとオーバーし てしまいましたけどもあのデモがえっと 予想外な形になっ