はいでは お時間 1分ほど経ちましたので今日も始めたいと 思います皆さんこんにちはいつもライブ音 サービスNowに参加していただいて ありがとうございます今日のテーマは devops Changeworkspace概要と いうことで リボフチェンジベロシティという製品が サービスナウのitsmPROの機能で あるんですけどもそれのでの インターフェースとして用意されている evxchangeworkspaceを 中心にですねご説明していきたいと思って いますよろしくお願いいたします はいいつもの通りですねセーフハーバーの 通知があります今日のテーマは特にそう ですね新しい バンクーバーリリースもリリースされた ばかりになりますけども今日はそのあたり のですね新しい機能って特に もうリリースされてる機能を中心にお話し しますので特にですね政府ハーバーに気に していただく必要はないかと思いますが 万が一ですね 将来の見通しに関する 説明があった場合はそれをもとにご購入の 意思決定をされたということのないように ですね お願いしたいですというまあそういう 通知になります はいはいあといつもの通りですねまあ今日 参加されてる皆さんはすでにサイトの ページはご存知かと思いますがこれ今後 ですね今日のも 含めて 過去の オンデマンド配信のYouTubeでご 確認いただくことができるものがあります がこちらのサイトにアクセスしていただい て今後のミートアップとかウェビナーに ついて こちらから 参照していただいて参加いただければと 思います ハウスキーピングですねいつもと同じなん でですが最後にQ&Aの時間を 設けていますが 途中でですねご質問とかありましたら Q&Aボタンを使ってですね 投稿していただければと思いますあとは 途中でですねご質問とかチャットに入れて いただいてもいいですしコメントとかあれ ばですねあとあの 手を挙げていただければミュートオフにし ますんでそちらで発言していただくことも できるかなと思いますあと プレゼンテーションの様子は 録画されまして後ほどサービスな コミュニティで共有されますのでもしも 見逃した方がいらっしゃいましたらここの そこの サイトをご紹介いただければと思います それからイベント終了後簡単なアンケート へのご協力をお願いしていますぜひご意見 をお寄せていただいて今後のセミナーの 運営にですね役立たせていただきたいと 思ってますのでよろしくお願いいたします はいいつもの通りですねもうあの日本語の ウェビナーといえば私しか今やってない 状態なんでいつもの ご紹介になりますけど私小林と申しまして ITsmbuサービスナウのですね itsmbudでアウトバウンド プロダクトマネージャーやってます今年で 6年目ですねもうすぐ7年になります よろしくお願いいたします はいでは早速ですけど皆さんにいつもの 通りですねちょっとポール 投票お願いしたいと思います今日の質問1 回目の質問は 現在ご自身の組織でデブオープスチェンジ ワークスペースを使用されていますかと いう 質問ですね ありがとうございますあと2名の方もあ はいそうですね どこ頂いて東和 4名様参加されてますが ありがとうございます あ使われてる方が今日いらっしゃるんです ねはいえーと使われてる方特にですね なんかあの こういうところがちょっとよくわからない んですけどとかあればチャットに入れて いただいてですね この機会にですねお話ができればなと思い ますのでもしもあればですね 積極的に こういう使い方してますよでもいいですし そういったことをお話しいただければ他の 方のご参考にもなるしちょっといいかなと 思いますのでぜひよろしくお願いします はいではちょっと投稿終了して結果を共有 しますがこんな感じですねよく聞いたこと ないですって方が2名それからしてるけど もっと知りたいですっていう方が1名で まあまあ使われるということで こんな構成で今日はお話ししていきたいと 思いますありがとうございました はいでは続けてですね早速お話し始めたい と思います 製品の紹介に入る前にですねなぜサービス なのがこのエリアにフォーカスしたのかに ついてご理解いただきたいと思います devopsに関してはですねどんなもの かっていうのは今日はちょっとお話しし ないんですね 実際その話をすると結構長くなってしまう ので 簡単にお話し するか何かご存じない方がいらっしゃると すればちょっと情報 量としては少ないかなと思うんですけども 開発と運用ってだいたい組織が分かれてて 今まで ウォーターホール型で開発をしてきて そして 運用に引き渡してあとは運用が一生懸命 サービス提供するとだけど何か不具合が あったりとかですね 障害が発生した時の 原因がもしアプリケーションとかにあっ たらまたそのアプリケーションに対しての フィードバックをして不具合の 解決をしてもらうためにまた開発して もらってみたいなそういった フィードバックがあるんですけどもその 最近はですねやっぱりそのアジャイル開発 だとかそれからCICDツールとかを使っ ての継続的デリバリーっていう考え方に よって小さい単位でのアプリケーションの 開発とリリースっていうのは結構頻繁に 行われるような傾向になってきてそれが デジタルトランスフォーメーションを促進 するみたいなところがありますのでそこを 開発と運用を 理想的には一つのチームが全部賄えるよう な体制を組んでデブオブ数をやりたい みたいなところなんですけどもまあそう いうことも含めてだんだん開発と 運用が近しいと立場でですねやっていく ようになってきてるという 背景からですねdevopsの中で今まで の体制でやっているとデボックスのところ にこんな落とし穴があるんですよだから そこを埋めるためにサービスナウが アプリケーションを作りましたっていう風 に思っていただければなと思いますじゃあ どんな落とし穴があったかというお話なん ですけども 今まで多くのお客様がデブオックスを実践 してみて感じ直面してきた共通の課題って いうのがいくつかありますとそのお話を まずさせていただきます一つ目がですね 可視性トレーサビリティの欠如って書かれ てますけども先ほどお話しした通り開発と ですね運用の間 チームが別だっていうところがお客さん 多いんですよねweboxと言いつつ ちょっとやっぱり運用 開発の運用も 独特のスキルはですねが 求められるところもあるので 専門性を考えるとやっぱり別々のチームで やってしまったりとかすることが多い チームというか人がですね同じ人が開発の 運用もっていうのがなかなか 難しかったですそうするとやっぱりどうし てもこの サイロ化というかですね壁がなくならない で開発の人はそれぞれが自分に必要な ツールを使ってますね例えばプロジェクト 管理 ジーラーとかですかね代表的にやれるとだ からコーディングをするための開発の ツールですねそれからテストツール コミットデプロイをするみたいな感じで パイプライン管理をするようなそんな ツールがそれぞれ用意されていて自分たち が今まで使い慣れているものっていうのを どうしてもいろんなツールを使ってます 一方で運用側っていうのは開発で起きて いることを知る 術がないんですねそれぞれどんな ツールを使ってどんな開発をしていて今どういう状態なのかみたいなで品質はどうなのか みたいなことも テスト結果とか シェアされることもあんまりなくですね なんかこう 可視性がないまま引き渡されてきて 変更の影響とリスクが出てみたらこんなだったみたいな感じですねで運用部門は デプロイされるまで リリース 変更の内容を把握できないし 開発側は インシデントが発生しない限り 逆に本番環境の実際のデプロイメントに関する情報っていうのはもう引き渡してしまったら ですね 無関心です それは双方のデータがやっぱりこう ツールが違うので例えばサービス内で 他のモニタリングツールからの監視データ を持ってきてインシデントが 紐付けてとかってことをやっててもその インシデントが開発の何に関連するのか みたいなところってなかなか 紐付けが難しくて 分析調査分析それから 根本原因の解決っていうのがなかなかこう 一直線で回らないと変なところがあります ねなので そんな結果ですねどうなるかっていうと 真ん中でコンプライアンスの欠如なんです けども本当は開発の人たちに状況を 逐次ですね情報をシェアしてもらいたいと 言いつつが変更の情報も 把握したいですと言いながらも変更の情報 っていうのは開発側がアウトプットしない とですね プッシュしてくれないとなかなかわから ないということになると開発がやっぱり 面倒くさいんですよねわざわざサービスな のにログインして変更リてあげてとかって いうことがインドが上がれば上がること ですねデブオックスアジャイル開発 divopsの状況になればなるほど 面倒くさくて後回しになってしまうそう するとですねまあ 過去のうちのお客様の 報告例では94%の変更が登録されてな いっていう結果になったりとかしてるとお 客様からの 報告では開発側から変更リクエスト マニュアルで報告しなければならないって ことに対してものすごく抵抗があるという ことでそうすると コンプライアンスに 違反した状態で変更が行われていることが 多いですよということですねそれは例えば そのやっぱガバナンスの 観点から考えてもなかなか厳しいですよね でその結果ですねやっぱり 最終的にはですね 品質が低下したりとかやっぱ変更の 失敗だったりとかが 減らなかったりとかすると timetomarketですねまあ本番 リリースまでの時間がアジャイル開発して デブオプス体制にしたにも関わらず 期待通りに回ってないですね高速の開発と デプロイメントというのが実現されづら いっていうような状態になっているという ことですねはいそうすると 期待 ほどじゃなかったってお金をかけていろんな体制 ツールを作った割には オーバーヘッドが多くてですね スケールアップがしづらいなみたいなそんな問題があります 次にじゃあ実際にですねDevOP に関わる人たちの個別の課題ってどんなものなのかなってことももう少し [音楽] 掘り下げてみたいと思います これからdevops の実践を検討中の皆さんは 特にこんなところに課題が出てくるんだな ってことですね 理解していただければと思いますはいまず開発者の本音としては開発に専念したように変更管理に関わる時間が煩わしいなと思ってますということが本音かな と思いますね それから エンジニアリングマネージャーですねについては分断した ツールを横串で見渡すことが難しいので どの段階にボトルネックがあるかっていうの 特定できないで パフォーマンスを改善するのがなかなか難しいです 開発 それから プロジェクト管理 開発それから テストから デプロイメントみたいな流れになっていく と思うんですけどもそれぞれのところに ボトルネックがあるかもしれないけど 下手すると全部のツールがバラバラでどこ がリソース不足だったり品質が悪かったり みたいなところを全体的に見渡すのが なかなか大変ですということはまあ想像し やすいかなと思いますそれから変更 マネージャーにしてみるとすべての変更を 成功させたいんですけども増え続ける変更 リクエストの数ですねやっぱりマイクロ サービスのリリースとかが増えてきますと ものすごい頻度で変更が発生しますそれ一 つ一つを今まで通りのペースでですね変更 の評価をして承認をしてっていうのを1個 1個やっていくとはですねものすごく手間 になってここがボトルネックになって しまうというところがありますでそんな中 でもちゃんとコンプライアンス 守らなきゃいけないよとかセキュリティは みたいなことを言われてしまうとやっぱり ここではもう手一杯でオーバーフローして しまっているという いうのがあります 運用サポートチームっていうのは増え続ける変更のスピードに追いつかないですね インシデントとの関係 関連付け も難しくて 状況把握できなくなってしまっていうそんな状況ですね そして ガバナンス 担当者ですねGRCとかですねrrm の担当の人たちにしてみると 監査対象のデータを複数のツールから確認しなければならないですね プロジェクト管理の観点はとか 開発 セキュリティはとかいろんな あとは運用環境はとかっていういろんなことを考えた時にそれぞれの ツールからの情報を見つけなければいけないって ものすごい 途方もない 調査 監査がをしなければならないとそうする そしてまた どこに リスクが潜んでいるかってことを評価しなければいけないところでもなかなか辛いところがありますということが言える かと思いますでそれを 解決するためのに考えられたのが開発され たのがサービスナウのdevops チェンジベロシティという製品になります それはどのように解決するかをちょっと見 ていきたいと思いますが 重要なことはまずサービスナウは devopsの 各ツールですねCICDツールのどれにも とって変わるものではないということをお 伝えしたいと思います開発者は今まで通り 自分のツールを使い続けることができると いうことを前提としてまして例えばその 開発ベンダーによっていろんなツールで 開発されていますけれどもそのそれぞれの ツールとサービスナウをつなげることに よってですね 全情報をサービスなどに集約するという ことを考えています 全てのデータをサービスなのでボックスの データモデルに 取り込んで バーディーチェーンのパフォーマンスに 関するインサイトを提供するとですね プランから計画からですねデプロイまでの アプリケーションを軸とした アプリケーションの傘の下につながる あらゆるステージの情報を全部つなげて サービスなどで見れるようにしますよって いう話ですねでさらにそれらの中での品質 評価結果っていうのを全てサービスなのが 自動的にですね変更レコードを作った後で 評価します自動で 評価するようなことができますデプロイを する前に変更リクエストを作ってっていう のを全部自動でしてやってそしてこの アプリケーションに関してはこういう暗い エリアで変更リクエストを評価してもしも このクライエリアに 合格したものは自動的に 承認をします いうところまでをやるんですねこの真ん中 のところがそうなんですけども自動生成 リクエストしてで例えばビルドが成功して ますよとかユニットテストの合格しました とかテストカバレッジは80%以上クリア してますよとかセキュリティのテストにも 合格しています現在 稼働中のものに 未解決のインシデントはないですよとか それからデプロイメントフリーズが発生し たことはないですみたいなまあ過去の実績 と現在のステータスですね状況を評価して であればこれは自動承認自動的にデプロイ していいですよみたいなことを今度 デプロイメントツールに自動的にお伝え するので人人間を介すること一切なくです ね変更が実行されるそういうような流れに なりますもしもここの暗いエリアを通ら なくなって通らない場合はですね人間に よるマニュアル評価をリクエストして人が アサインされた 承認者がその内容を確認して実際に承認 するのか 拒否するのかを決めるという流れに分岐 するというような形になりますそしてこれ らのすべての活動っていうのはインサイト ですねdevopsのインサイトを使って ですねパフォーマンスを測定することが できるのでどのアプリケーションのどの 段階でどんな品質だったのか 流れるフローのですね 品質はどうなのか テスト品質はどうだったのかとかですね いろんなことがサービス側で全て パフォーマンスを評価することができるの で 管理者にしてみてもあるいはその監査書籍 という意味でもサービスなどで確認して いただくことができるというそういう メリットがあります でこのボックスチェンジベローシティが どんなことをしてくれるかっていうのが 分かっていただけたかなと思いますけども これによって先ほどの方たちにですねの 課題を一つ一つ解決することができますで コラボレーション向上させて 効率性も上がってそしてより味わえるん ですね早い 承認をすることによってくるくるくるくる ですねどんどん加速した変更が実施できる ということになりますで開発者にとって みるとまず開発に専念できます1歳ですね サービスなのにログインすることなくただ ひたすら自分のやるべきことをやっていく ことができるようになりますそれから エンジニアリングエンジニアリング マネージャーにとってはインサイトが見れ ますのでどの段階にあるいはあるいはどの チームにボトルネックがあるかを 特定してリソースの適正配分を改善する ことができるようになりますそれから変更 マネージャーにしてみると多くの変更の 書籍を記録する煩から 解放されますねそしてリスクの多い変更や 緊急の変更要は 従来通りのですね モード1って言われてるような ウォーターフォール型の開発の 評価だったりとかあるいはより複雑なです ねハイブリッドの ディスクの高い 変更の評価に時間を割くことができるよう に余裕ができてくるということですねそれ から運用サポートにしてみると高い成功率 の変更のおかげでインシデントが 劇的に減りますですね 減る一方で発生時のトレーサビリティの 向上により解決時間を 短縮できますというのはどの変更によって 発生したインシデントなのかっていう ところから どのその変更のどのコンポーネントに問題 があったのかみたいなことをさかのぼって 評価することができるのででもあの 解決時間も短くなりますということですね まずインシデント自体が減りますそれから 解決時間が短くなりますと言ったメリット がありますそしてガバナンス担当者にして みるとサービスなどを確認するだけで リスク評価ができるようになって 監査の時間が 激減しますね 効率が上がりますというようなメリットが あります はいでとてもChange velocityの導入というのは簡単に 皆さんのペースで進めていただくことが できます要はそのいつからですね今まで 開発していたツールとの連携をするか みたいな話だとかどこまで進めましょうか 自動変更 リクエストの自動生成までしますかとか ですねそういったところも含めて 一気にやる必要はないかなというところに なりますで4段階で 導入しますがまずCICツールをサービス などとつなげるというところがあります ジーラーとかですねgithubだとか Azuredayboxとかってその それぞれ使ってるツールをまずサービス ナウとつなぐそして その後でプロセスを変更することなく アプリケーション開発指標 っていうのを使ってどんな 指標を評価するのかみたいなところを 定義してで活性を向上させていきます変更 の登録についてはプロセスでパイプライン の デプロイメントの前で変更 要求をするのかとかあるいはテストの前で しますかみたいなところで自分が 適切だと思うタイミングで変更レコードを 自動的に寄付するっていう設定をすること ができます自動的に生成させるんですね そして その時にですね オーソライゼーションプロセスってことで 変更の 暗いエリア変更の自動実施の暗いエリアを 適用させてでこのリスクがクリアされて いれば自動的にデプロイしましょうとか この評価指標だと難しいねだから マニュアルでの 承認にさせましょうとかですねあるいは 拒否するっていう選択肢もあるかと思い ますけども チェンジが できるだけリスクを 持たないまま 持たない状態で実施されるというような ことができるそれぞれの 段階についてはインサイトですね KPIがちゃんと用意されていてそれぞれ うまくいってるかどうかってことを確認し ていただくことができます はいということで 製品紹介の早速させていただきますけれど もほとんどの機能っていうのは デブオプスはチェンジワークスペースと いう専用のワークスペースで 提供されますのでこれからのデモをさせて いただきますでこのページ以降はですね あの 紙芝居があるんですけどもこちらを読んで いただいてもきっとピンとこないなと思い ますのでこれは後からですねあの見て いただくあの 提供されるPDFを確認いただくのがいい かなと思ってましてまずはデモをご紹介し たいなと思いますはい これらの機能があるんですってことはこれ からご紹介させていただきますでは早速 デモをしたいと思いますが 準備してる間にご質問とかあります でしょうか 今のところないですかね ちょっとお待ちください はいえーとこれがデブオプス チェンジワークスペースの画面になります 表示の仕方としては ワークスペースからデーボックス変更 ワークススペースちょっと 翻訳が中途半端な感じですけども を選んでいただくかあるいはこの全ての ところで 入れていただいてここから開く形になり ますはいでえっとこれがホーム画面になり ましてでホームページではですねホーム 画面ではちょっとログインした方の名前で パーソナライズされてますけどもまず初め にっていうところですねこれ gettingstartedで 設定をここから行えますっていうものに なりますそれから現在の ツール連携の状況ですねどんなツールと CICDツールと連携しているかとかです ね イベントがどれだけ発生webook イベントの発生状況だとかですねが イベントがどんな種類のイベントが発生し ているのかみたいなことがわかったりとか それからちょっとそうですねこちら 別のインスタンスで出しますけど こんな形で自分が担当してるオープン タスクがどれだけあってとかですねだから ツールの 接続状態ですねどうですかみたいな話から 見れます 過去のアプリケーション アクティビティをどんなものがあるかとかっていうの 確認できる トップページです であのはじめにのところをちょっと詳細説明させていただきたいと思いますけども ここではまずプレイブックが用意されてまして 全く初めての方もここの初めにのところから設定を始めていただくことで簡単に ですね CICD との接続から変更の自動化のところまでを進めていくことができるようになります [音楽] アカウントとユーザーのところではまずはすでにちょっとですね ここには出てこなくなっちゃったんですけども まずは 接続するツールと接続するアカウントのパスワードを設定したりとかすることができます こちらからも こちらの方からもできるんですけども このアドミンストレーションですね からもできるんですがちょっと時間かかってます ちょっとこちらで続きの話ですねそれから 他のdevopsユーザーですねこの画面 を使って状況を確認したりとか設定アプリ を追加したりとかですねいろんなことが できるユーザーについてのロールアサイン したりとかそれからタスクアサインって 言ってるのは 開発チームに対して新しく ジェラート連携したいのでこちらのURL とかですね クレデンシャル情報っていうのを用意して くださいねみたいなタスクを アサインするようなそんなことがここで できますねそれからツールと アプリケーションのところではまずまあ ドールがセットアップされて接続情報も手 に入ったとなるとじゃあツールを接続し ましょうねっていう話になると思いますな のでここで見ていただくと プランですね プランコードイラストレーション アーティファクトソフトウェア 品質セキュリティというなそれぞれのです ねまあweboxでCICDツールと言わ れている 各種のツールのどれと 接続しますかってことここで選べます 例えば計画プランニングだったらサービス ナウのアジャイルエベロップメントも 接続できますしこちらだったりとか AzureBOXに関しては全てのこの ライフサイクル全体をカバーしてたりとか するのでAzureBOXを選べたりとか あとはラリーだったりとかありますし コーディングについては ラブとかですねgithubだったりとか それから ビットバケットとかもありますよねとか あとオーケストレーションツールを接続 するんだったらこれのですね前金ス選ん だりとかですねすることができるかと思い ますこのようにですねあのいろんなツール との接続が同時にできますのでここで設定 をしていくようなそんな感じになります ちょっと一つ進めていくと簡単にできるの がちょっとAzureBOXを 接続しましょうみたいな感じで プロジェクト 単位で 接続しますよ Azuredevelopsの プロジェクトのURLをちょっと コピーしていきますね で Azuredeboxの 接続しますよみたいな感じですね そうするとここにあの プレイブックという形で 1ステップずつですねあの手順が 進捗状況に合わせて出てきますので これに従って作業を進めていただくような 形になります すごくわかりやすいです 最初にweboxのアプリケーションが出 てきた時はやっぱり設定の仕方がすごく 煩雑で行ったり来たりでわかりづらかった んですけどもやっぱり 充実されてきましてこの段階になるとです ね 順番にこんなことしてくださいねみたいな 形で 言われてます 接続できますですね はいでちょっと全部やると時間がかかって しまうので 接続ができたもの後でご紹介しますが こんな形でツールを接続していきますで ツールがつながりましたら アプリケーションを作成しますということ で 要は開発アプリケーションの開発チームと の連携なのでアプリケーション単位で サービス内も管理していきますよという ことなんで新しいアプリケーションをここ で 接続情報と結びつけるための アプリケーションを作るかそれから既存に あるですねアプリケーションモデルを使っ てそこから 登録していくようなそんなことができたり とかします すいませんちょっと今メッセージがこれ バグなんですけど エラーになってますがアプリが正常に作成 されましたっていう状態になるんですね これで正常に作成するんです アプリケーションが作成されたらじゃあ そのアプリケーションはどの変更 ワークフローどんな ワークフローでどのタイミングで変更要求 をリクエストを作りますかみたいなところ を ここでですね作ってきます はいで例えば この コープスーパーツァンリミテッドを選んで みますと このパーツアンリミテッドは ビルドテスト デプロイアプリケーションレコンディション デプロイみたいな形ちょっと 順番が変になってますがこういった ステップを踏んで ワークフロー流してきますよね パイプラインの流れをですで デプロイアプリケーション のところ前でリクエストを作りたいですっ ていうことになるとここでですね ここで変更 コントロールを設定して で変更モデルはデブボックスで通常の変更 タイプでレコードを作りますみたいな ところをここで用意してあげますはいで これはですね Azuredevops側に対してこの ステップを追加してくださいねってこと ですねこれは要はサービス 側で 変更リクエストができたかできないかを ちゃんと 返してあげて変更が成功したかと変更 リクエストすいません変更リクエストが ちゃんと作られたかどうかとかそしてそこ が承認されたら デプロイをしていいですよみたいなところ まで持っていけるようなそんな スクリプトを追加してあげましょうみたい なところですねこれが出来上がるとこの パイプラインの方にですねうまく回って いきまして 過去ですね ビルドテストデプロイの段階が西欧に 終わりましたそしてその ステータスですねここにAzureで ボックスがでもサービスのデブオプス サーバー チェンジ の 成功が確認できましたよということが わかります 結局その サービス側でも シェアシリーズ側でも特にですね人が何か をするってわけでなくここまで自動的に 変更レコードを作って 承認することができるようになる設定が ここで出来上がりましたことですねただ その先ほど前半でご紹介した変更承認ポリ シーっていうのがあります要はその自動 承認をするできるのができないのかな判断 をするためのクライテリアが自動的に評価 されなきゃいけないということになります のでそれはここで 選べますね デフォルトはこんな 条件になってますねコミットリンク ワークアイテムですねがカラーじゃない こと要は ワークアイテムにリンクしたコミットが ちゃんとありますよとかですねそれから リグレーションテストの失敗が一つもない ですとかインテグレーションテストの失敗 もないですとかですねそれからトータル チェンジのコメントが50以上とかですね ロードテストも失敗してないですユニット テストの壁で70%以上ですコード カバレッジも70%ですよとかで セキュリティに関しても一見もないですね セキュリティのリスクが一件もないですか それから 過去7 週間前ですね過去1週間で会うページが1 回もないですとか現在もアウトにしてませ んとかそれから クローズしてないインシデントが一件も ないですこういったそのCICツールだけ じゃなくても運用側のリスクに関しても ちゃんと評価してじゃあこの 条件に 合致したんであれば自動的に承認します よってことでサービスの方が自動承認を するって今そんな流れになります はいで アプリケーションですねこれあの登録され た先ほどの手順で登録された アプリケーションがこのような形で一覧で 出てきますここからも新規登録できます けどもアプリケーション実際どういう風に 見えるかを見てみたいと思いますパーツ アンリミテッドですねに関して 見ると アプリケーションがいつ作成されたか作成 者は誰かっていう情報とそれから 詳細ですね 今ちょっと ブランクが多いですけども アプリケーションの名前とそれからその アプリケーションてビジネスアプリのどれ に紐付いてこれはそのcsdmとか cmdbの中でサービスと コンポーネントの関係性をちゃんと 結びつくためのビジネスアプリケーション とのどのアプリケーションの下のビジネス アプリの下のアプリケーションですよ みたいなところを 紐付けていますから記録ログレベルはどの ぐらいですみたいなところもいいかなと 思いますそれから 概要としては保守担当者が誰ですかみたい なところも設定していけるかと思いますで その後はですねプランリポジトリ パイプラインアーティファクトリポジトリ 要求をインポートっていう感じでその CICDツールの 中の情報を 出して 持ってきてですねWebフックとかですね 問い合わせした情報をごそっと持ってきて 過去の情報持ってきたりとかして 情報確認できますじゃあプランについては このパーツアンリミテッドよりもですね コープサイトだと 違う 情報量として このプラン IT サービスマネジメントというアプリケーション CAのアプリケーションについてプランが 同期されました このプランにいると計画ですねプロジェクトですよね のプロジェクトにワーク アイテムが98個あります これは そのジラーとかですね これ何でストーリー 情報だとか それから バックログとかをこのようにインポートしてきてですね 今どういうステータスなんだということがわかるようになってます ワークアイテムごとにこのストーリーは今 開発対応中ですよみたいな情報が このように見れますね誰に 浅い情報をちょっと来てないですけども そういったふうに確認できます からリリースバージョンですね過去に どんなリリースがされたのかみたいな話と か 今作成中の機能はみたいな話だとかこう いう情報が プランニングツールから同期されます それから [音楽] リポジトリ情報ですね リポジトリート情報も同期されますこの 実際にdevoxAzuredevops のリポジトリ情報からにリンクを飛ぶ 飛ばすこともできますがパイプラインです ね 情報 パイプラインは パイプラインの進捗状況から webooks チェンジが チェンジリクエストが作成されますという ことでこうやって確認してみますと 先ほど こちらで成功した ビルドバリデートなどでデプロイ アプリケーション の中で自動的に変更リクエストを作成して ましたよねってことがここで変更 リクエストが 出来上がってるということがビルドテスト デプロイですね はいでここはこのページなんですけども 過去のこのパイプラインの 状況ですねを履歴取ってますので失敗した 時って何が悪かったんだっけみたいな話を 確認できますしあとは アーティファクトとかもサービス 側に情報機器ますのでアーティファクトや コミット情報だったりとかそれからどの 作業でコミットされたんだとかですね学校 性アイテム情報があれば構成相手もここで 見れますしそれからテスト結果として ソフトウェア 品質の チェック結果だったりとかこれはないん ですねだからセキュリティツールからの 情報の の共有がされている場合はここで確認して いただくことができます変更レコードに ついては チェンジの40167っていうのが見て みるとこんな形で自動的に生成された 変更レコードが確認できます この辺の簡単な説明ですね何に対するの 変更リクエストですデプロイですねパーツ アンリミテッドのこのアプリケーションの プロダクション本番関係のデプロイですで 計画段階で評価しましたということで正当 性実装計画だとかこの辺は プリセットされますね あらかじめこのアプリケーションはこんな 形でディスク 影響の分析をして切り戻し計画もあります よとかですねそういう情報を登録しておく ことによって自動的にレコードに追加され ますそして 変更のポリシーですね変更のポリシーが 自動 承認された のかどうかみたいなところがここで確認 できますしあらゆるそのそうですね ワークアイテムからコミット情報からです ねテストサマリーテストの結果だったりと かも リンク先に飛んだりすることができるよう にではここの変更レコードを見ればこの パイプラインに関する過去の開発 計画から開発のすべての情報がここで確認 できるようになりますということですね なりますはいで アプリケーション がツールですねツールに関して言うと今 計画立案ツールだとAzuredevox と私は今サービス マークのAzure開発 アジャイルマネジメント2.0 アジャイルデベロップメント2.0を つなげてますけどもここでプランニング ツールを 接続ってことでここからやるとさっきの 先ほどの ツールに接続のところで例えばこちらを 接続するみたいなことでここで追加でき ますあとコーディングそれから オーケストレーション アーティファクト テストツールとかですねそんな形で 接続を追加していったり確認したり いただけるんですね今ここのadoテスト ツールに行くと 2つの プロジェクトアプリケーションが 繋がってますよみたいな [音楽] プロジェクトですねはいでえっとイン サイトですけども 非常に多くの情報がここで確認して いただくことができます これあのドッグスにですね 各 KPIの説明がしっかり書かれていますの でそちらも見ていただけるんですけども このインサイトのところ開きますと サマリーとかフロー 測定基準とかってありますとですね それぞれ カプセルがここにありますけども アプリケーション 単位で絞り込んでみたりとかそれから リポジトリ で見たりとか サービスの種類ですよねこれ今ちょっと サービス 紐付けてないので出てきませんがあとは ビジネスアプリケーションこれも 紐付けてない出てきた 関係ありそうな デモデータでありますね カスタマーポータルとかクーパーとか アプリケーションビジネスアプリがこんな のが動いててそれごとにでちょっと開発で 実績とかがあるかどうかちょっと別として 登録されてるビジネスアプリごとに 抽出できますそれから これも製品ごとですねプロダクトごとに 確認できます作業アイテムタイプって言っ てるのはその ワークアイテムで連携されたそのエピック 単位の作業とかストーリー単位だったりと かあるいはテストの作業とかですねその ワークアイテムがいろんなツールから作業 として 提供されていれば連携されていればその 単位ごとに情報が確認できますそして サマリーで見れるものと言ったら例えば 平均 ウィープ作業中のサイクル時間ですね だいたい作業が 平均してどのぐらいで終わっ作業が終わっ てるのかとかですね 平均リートタイムがどのぐらいなのかが 展開頻度は1ヶ月に何回デプロイされて いるのかとかそれからテストのちょっと 低いですけどもこのデータだと 平均テスト合格率だったりとか 完了した作業アイテムの 種類はどんなものなのかみたいな話ですね アプリケーションごとに 各アプリケーションでどんな アクティビティがあったのかみたいな コミットがどのぐらいですとかですね 合格率がどうですかみたいなことは一覧 できたりとかそれから 測定基準に関して言うと ですね平均風呂36.7日かかってます とか 仕掛かり サイクル時間は一つの作業については 1.02日で終わって平均で終わってますよ とかですね 1日でカットした時に平均仕掛かり数って何日かかる 件数が何件ぐらいあるんですね みたいなところとか今月完了した この期間ですね この期間に完了した作業 アイテムってどのぐらいあったんですかみたいなところがあと 過去の履歴からアイテムのサイクル機関が最近増えてますね みたいなことが 傾向であったとしたら じゃあそれってどの 理由で 作業アイテムが伸びているのかな みたいなことだとかそれから スループットに関しても今 こうやって確認していただくことができますね この数字がホバーオーバーすると どの理由によって スループットが悪くなってんですね みたいなことが こうやって見ていただけたりとかします 展開フロー時間 だったりとかですね入れますそれから 変更の 促進のインサイトにおいては変更に関する devopsに関する変更のボリューム ってどういう感じで増えてるのか 平均していつも一定数で 提供されているのかみたいな形だったりと かこれそうですね自動変更自動変更と手動 変更がどのぐらいの割合になってきてるの かみたいな最近は手動が少なくなってます ねみたいなことが 傾向でわかったりとかですねそれから変更 のクローズに要する時間がどんどん減って いますよとかですね特にこの承認待ちの 変更がだんだん減ってきてるといい傾向 ですよね要は 変更マネージャーにしてみると仕事が かなり自動変更によって 楽になってきてるかっていうことがわかる かなと思います それから ポリシーでに適用した形で自動承認がどれ だけの割合を行われたのかどれくらい たくさん行われたのか 却下されたのがどのぐらいあったのか みたいな話だとかそれから特にやっぱり マネージャーそれから リーダーの人たちにしてみると 興味あるのが変更 このdevoxによってですねどれだけ コストが削減されたのかでこのコストの 計算してみるとその1時間あたりの作業者 のコストですね人件費が分かっていれば それをインプットとしてどのぐらいの作業 時間で作業が終わってるかみたいなところ でどれだけ 削減できたのかっていうことがわかります この工数かけるこちらで単価みたいな形で このこちらに結果が出てきますねそれから 測定基準の属性 促進ですがこちらはそのデブオプスって いう観点で4つのですねドラという組織が あるんですけどもそこの 定義した レヴォオックスがうまくいってるかどう かっていうのはこの4つの指標で確認でき ますよっていうのがあるんですけども 平均リードタイムとそれから平均展開頻度 ですねやっぱり 頻度リードタイムが短ければ短いほどいい ですし 展開頻度がたくさんあればあるほどうまく ですね 早いタイミングでの 展開が進んでいるということは DXも加速しますよねみたいなそういう 流れだなと思いますねそれから 平均mttrこれも 解決時間これはインシデントの解決時間 ですけどもやっぱりそのデブオックスが ちゃんとうまく流れていて全てその インシデントの発生を 抑えるかつ 解決時間が 短いなぜならば開発情報とも紐付いてる から問題点特定しやすいみたいな理由から mttrが短くなるとことがDボックス うまくいってますよねっていう話だったり とかから平均失敗 率ですね変更の失敗がどれだけあったのか みたいなところも 指針になります がいかにうまくいってるかのページだと 思っていただければと思いますそれから もう品質に特化した形でこれはその コーディングのツールだったりとかテスト ツールだったりとかそれからセキュリティ がバグの発見するツールとかあればですね そういった バグについて言うとサービス側で不具合と 判断したものっていうのを 追加してあげたりとかっていうレポート 作ってあげるっていう事ができるかなと 思います要はそのそれぞれのツールで必要 な評価指標として品質に関するものという のはここでまとめて行動 カバレッジが悪いのかじゃあ開発者どうな のみたいながテスト 合格率が低いんだったらやっぱりそのもう 少し単体テストちゃんとしなきゃダメだよ ねとかセキュリティに関する所っていうの は何が問題なんですかみたいな感じでより 掘り下げてですね 解決していくことができるかなと思います じゃあ今度は開発に特化したんですね指標 があります ですね全部説明しませんがこんな感じです ね世界運用の安定性ですねこちらはもう サービスのお得意のところでインシデント の発生状況だとか会うページがどういう 状況だったのかとか サービスの可用性に関する情報もサービス なのかで把握できてますのでそうですね アイテムと連携した形であればある程度 こういったものも集約して確認することが できます日付は自分の好きな過去の情報 から引っ張ってきて確認していただくこと ができるそんなものになりますで最後に アドミンストレーションツールですけども こちらはこのdevoxChange velocityに関してのシステムの 健全性ですね要はその cicdツールとの 連携のところでどれだけの数のやり取りが 発生しているのかとかですねそれから それがどういうステータスで終わったのか みたいな実行されたのかみたいなところと かそれから 思考が発生してるんだったら再試行って どのぐらい リトライして 終わってるのかとかですねが処理済み数が 減らすとか 待機数とかですね どちらかに問題があって待たなきゃいけ なかった状況があったんだなみたいな ところですねクリックしてみていただい たりとかそれからイベントの傾向みたいな のが 確認できます ツールの接続性に関して言うとはちょっと こちらデータがないですけどもこっちの インスタンスで見ると 出てくるかと思うんですが はい どのツールとどういう 接続時間で 終わってますよみたいな最後に 接続したのはいつですみたいな情報とかが 確認できたりとかですねそれからエラー ログ見たり できますしパイプライン実行とかですね システムプロパティの変更もここからでき ます からオンボーディングのところはホームの ところでユーザーロールを設定とかでき ましたけどもそのユーザーグルーピングし てグループのロール設定したりとかですね ユーザーにタスクを割り当てたりとかする ところはここでもできますこんな感じで devopsの チェンジワークスペースというのがあり ますのでぜひ 活用していただければというちょっと時間 になってしまいましたご質問とかですね あはいえーと途中で抜けられた方がいるか なと思います j2Thankyouforyour coment はいちょっとお時間になりましたのでご 質問とかあればと思いましたが クロージングに行きたいと思います ちょっと話しすぎたかなっていう感じです がでも ポールですねこれちょっとすいません時間 ちょっとオーバーしちゃうかもしれない ですぜひポールを お願いしたいなと思ってまして はい ちゃちゃっとお願いできればと思います これからステップボックス チェンジベロシティ使いたいなって思っ たらどのレベルかなっていうところをお 伺いしたいと思います はい えーといかがですかねもう1名様 計画がないあそうですかわかりました ありがとうございます計画を結果を共有さ せていただきましたぜひですねこんなこと ができればdevopsもうまく 促進できるなってことを 理解していただければ いただけたんであれば よかったなと思いますはいでリソースに ついてはですねこちらで紹介されてますの でぜひPDFでですね見てください カスタマーサクセスセンターで 導入の 仕方とかですねそれからランニング ポータルに自己学習それからコミュニティ でいろんな情報が提供されてますが YouTube動画もたくさんありますの でこちらから見ていただければと思います はいちょっと長くなってしまいましたが 今日はこれで終わりたいと思いますどうも ありがとうございました