新時代のITサービスマネジメント
皆川宜宏氏：それでは、よろしくお願いいたします。Atlassianという会社でソリューションエンジニアをやっております、皆川と申します。
みなさま、Atlassianという会社はご存じでしょうか？ ご存じの方、ちょっと手を挙げてみていただけますか？
（会場挙手）
すごい。思ったよりも多かったような気がします。Atlassianは少し特徴がある会社ですので、こちらのITIL 4とDevOpsを皮切りにお話しさせていただきますが、こういった内容に入る前に少しだけAtlassianの会社の紹介をさせていただきます。
Atlassianは2002年にオーストラリアで創業されたテックカンパニーになります。製品で言えば「Jira」という製品が一番有名だと思います。これらが、欧米を中心にいま全世界で15万社以上のお客様に使っていただいております。
こちらは株価のティッカーシンボルなんですが、「TEAM」となっています。ご覧いただくように、いろいろな企業のロゴが入っております。「Fortune 100」に掲載されている企業の80パーセントにAtlassian製品を使ってもらっています。日本でもどんどんAtlassianの製品をお使いいただき始めていて、お客様数が増えております。
これがAtlassianの会社としてのミッションのキーワードになります。Atlassianのミッションは、あらゆるチームの潜在能力を解き放つこと。英語で言うと「Unleash the potential of every team」という言い方をしております。
Atlassianの製品についてです。企業にはいろいろな部署があり、いろいろなチームがあります。それらの活動をAtlassianの製品でつなげていくこと。そのためのコラボレーションをテーマにした製品が数多くあります。
一番有名なところではJira。それから最近ですとTrelloという製品もポピュラーになってきています。それからConfluence、Bitbucket。こういった製品がございます。Jiraはアジャイルやスクラム開発などの開発チームのツールとして今一番使われています。
アジャイルの隆盛とDevOpsの台頭
アジャイルやスクラムは欧米を中心に今日本でもどんどん増えておりますが、そもそもなぜアジャイルが必要とされてきたのか？
簡単に言いますと、おそらく時代がデジタルトランスフォーメーションを迎えつつあると。これから各企業に当てはまる課題になっていきます。
ここで問われるのが速さです。それから、それに対応したチームの働き方をどう変えていくのかが重要なんじゃないか。それがまずは開発のチームを皮切りにテーマになってきました。
そして2011年頃、アジャイルという開発チームの考え方や、スクラムという手法が広まって、その次のステップとして出てきたのがこのDevOpsになります。
たとえ開発自体が速くなったとしても、そこからどうデプロイするか、どうリリースするか。そこで例えば部署がまたがってしまって、結局「運用チームのほうに渡したんだけど、ぜんぜんリリースされないよ」という話になってくると、じゃあ総体としてお客様に価値を届けるという活動が速くなったのか？ そういった疑問が出てきたのがこのDevOpsのはじまりです。
開発と運用（DevとOps）がシームレスに流れるような働き方が求めてられているのが、いわばこれが開発側から見た視点だったわけですね。
一方でIT運用なんですが、ITサービスマネージメント、ITSMと呼ばれる分野はご存じのとおりのITILが、こういった変遷を経てきました。
v1が1989年なので、当時だとサッチャー時代のイギリスを主導にまとめられたようです。その後改定された、「ITIL 2011 Edition」が一番ポピュラーに世界に広まっていきました。
ここで先ほどDevOpsが台頭し始めたのが2011年頃と言ったのは意図的です。ITILの最新だったもの、2011EditionはDevOpsの前だったんですね。今年2月にITIL 4が発表されたときに、ここまでにいろいろな開発側の批判もありました。
DevOps的な考え方、速さをどうITILがやっていくのかという批判を受けて生まれたのが、このITIL 4と言えます。ですので、このITIL 4、多分にこのアジャイルとかDevOpsなどの概念が取り入れられています。
協働・繰り返し・顧客中心がカギになる
アジャイルを推進するうえでの働き方については、Atlassianがいろいろなところでお話しさせていただいてますが、この3つがポイントです。まず、協働すること、コラボレーションすること。それから、小さな単位で繰り返して、仕事を完遂させていくこと。そして、お客様中心であると。この3つが常にキーワードになります。
これらは、開発チームがアジャイルになったのと同じ意味で、IT運用チームのほうもアジャイルになれるとAtlassianは信じております。
ITIL 4の原則を見てみますと、「価値にフォーカスする」「今いるところから始める」。このあたりはかなり重要ですね。こういった原則が掲げられています。
こうやって並べてみますと、やはり「アジャイル開発宣言」で話されていたこととかなり近しいことが見て取れます。
このITSMのアプローチをAtlassianの視点で見ると、モジュール化しすぎた、あるいはモジュール化によって組織がサイロ化したようなところが今までのITILの流れのなかで少し特徴的で、いわゆるアジリティを損ねる一番の原因だったのではないのかとAtlassianでは考えています。
モジュール化され、サイロ化されて、プロセスを重視して、それが中央集権化され、それが厳密に守られることをよしとする。それが今後は、チームを中心にした仕事のやり方に変わっていくのではないか。これがデジタルトランスフォーメーションの時代に求められる速さのキーになる。
なぜかというとチームは一番現場に近い。チームが速く動ける。そこをどううまくコラボレーションしていくかがポイントになると。
こういったことは野中郁次郎先生という方がいらっしゃるのですが、実は「スクラム」という言葉を使って一番はじめに提唱されました。この方が最近の日本企業が抱える3つの過剰という分析をされています。
とりわけ開発のほうのアジャイルで言われてきたのがこの「計画過多」です。「がっちりとすべてを計画しなきゃ開発できない」というところを、アジャイルはどうにか「小さい単位で繰り返しやろう」というところに持っていったわけです。
IT運用のほうでアジャイルという働き方を考えると、こちらの「コンプライアンス過多」になるのかなと。どうバランスをつけていくか。おそらく部署ごとにそれぞれのコンプライアンスを徹底的に守ることをやっているかぎりは、全体としてお客様にサービス、付加価値を届けるところが疎かになりがちです。これをどう打破するかがポイントになってくると思っております。
明日からの「ITSM」で重要になる考え方
Atlassianは開発チームのソフトウェアの開発から、現在IT運用チームにも使える製品をたくさん提供しております。ただ、ポイントになるのはやはりアジャイルやアジリティという話になってきます。
開発チームにとってはアジャイルとDevOpsという概念がとても重要になり、今後IT運用チームにとっては、アジャイルなITIL、アジャイルなITSMなどの概念が非常に大事になってきます。
ビジネスチームもひっくるめて、組織全体や企業全体で、どうやってユーザーに価値を届け、価値をつくっていくのか。そこを第一に持っていくか。こういう意味で組織全体のアジャイルが今後のテーマになっていくのだと、Atlassianは考えております。
昨日までのITSMが、モジュール化およびサイロ化、プロセス重視であったのに対して、今後はリーンでアジャイルな働き方、そして顧客中心、チームを中心に考えていくわけです。
Atlassianはいくつか製品、ツールを提供しておりますが、やはりツールだけではダメで、そういったアジャイルなチームをつくる上でのポイントとなるのは次の3つになります。
適切な「実践」。プラクティスですね。それから「文化」。マインドセット、考え方。先ほど顧客中心もまさしく考え方の問題になります。そして、この「パフォーマンス」も同じですね。どうやってチームを超えて組織の全体としてのパフォーマンスを上げていくことに注力するか。こういった捉え方が非常に大事になります。
そういったチームの文化・マインドのセットを醸成する上での有用な情報になる「Atlassian Team Playbook」があります。ノウハウが詰まったワークショップを提供していますので、ぜひご覧いただければと思います。
そして、Atlassian自身も行っているプラクティスには、いくつかポイントがございますので、今日はそれを紹介させていただきたいと思います。デリバリ、運用、サービスの中から、とりわけデリバリに関してはプロジェクトマネージメントなどはJiraを弊社では使っております。
サービス管理へのアプローチ
本日はこの運用やサービスの話をメインに絞りたいと思っております。そして、サービスデスクとナレッジ管理から実践をみなさまと共有したいと思います。
まずはセルフサービスの話ですね。セルフサービス、サービスリクエスト管理の話になります。あえて「セルフ」とつけたのは、2年ほど前にForresterが研究調査をしまして、ユーザーの90パーセントぐらいは「もしセルフサービスが使えるんだったら、自分でやりたい」という声をあげております。
例えば今で言うと……我々が飛行機のチケットを買うのは、おそらくもう窓口はほぼなくて、セルフでやっております。ATMもそうですね。だから、ほとんど多くのサービスはセルフサービスが可能であると。これはIT運用でのサービスリクエスト管理も同等だと思います。そのメリットが非常に大きいんですね。
シフトレフトという考え方があります。このサポートもレベルで分かれていて、レベル3になっていくとコストや時間もどんどんかかるんですね。これをなるべく左側で済ませるようにします。
そして最終的にはこのレベル0。要はお客様がなにか問題を抱えたときにそれをご自身で解決すると、一気にコストが削減される。こういうところを目指すのがこのセルフサービスの考え方です。
構成としては、もちろんリクエストが全部なくなることはまずないですが、大半の問い合わせに対しては、お客様にナレッジベースの提供をキーにしてセルフ解決に持っていければ、多くのことが解決されるんじゃないかと思っております。
こういったポイントになりますね。ナレッジベースを中心にお客様がセルフで解決する。そして、それでも発生する問い合わせは、今までマニュアルをベースにポチポチやらなければいけなかった作業はとことん自動化する。Streamlinedという定義です。
このオートメーションをどう利かせるか。この両輪がかなりサービスリクエスト管理をITIL 4の世界に近づけるわけです。
チームを横断してサービスマネジメントを広げていく
まず1つ目は弊社の製品の画面をお見せしますが、例えばこのポータル画面やお客様の問い合わせの画面については、ひたすらわかりやすくすること。そして、サービスカタログでは、なにができるのかを明確にすることがポイントになります。
一番上のほうに検索の窓口を全面に押して出してしまう。ともすると、Webページがあって「リクエスト」というボタンがあるとだいたい押しちゃうんです。それをユーザー様がまずはじめに入力していただけるようにすることは、ある意味これは慣れてもらうようなつくりにしていくしかないわけです。
キーワードで検索することによって、ナレッジベースからサジェスト、「こういった解決策があるんじゃないですか？」というのを出していきます。こういったつくりのツール、こういったつくりのやり方が一番効くんじゃないかと思います。
チケット対応する人間がナレッジを蓄積していき、ナレッジ記事がどんどんたまっていけばそれだけお客様が新たに問題が発生したときにセルフで解決することができると。
それでも上がってくるリクエストに関しては、お客様が簡単にサポートチケットを作成できるようにする。これは実際にAtlassianでも実践しているやり方です。
そして、このチケットを受ける側・対応する側は、なるべくあらゆることを自動化していくことが大事になってきます。
そしてポイントのもう1つは、対応する側もナレッジベースにアクセスできるようにすること。往々にして「この人の頭の中にしか解決策がない」ということがやはりどこかにある。それをなるべくナレッジベース化していくこと。ここが大事な作業になります。
まとめますと、サービスリクエスト管理は顧客中心であること。ナレッジ中心であること。効率的に応答すること。それから「サービスマネージメントをスケール」と最後に書いてありますのは……実はAtlassian、製品としても、昨年Forresterの「Enterprise Service Management Wave Report」で高い評価をいただいています。
ITサービスリクエストだけでなく、先ほどの問い合わせ管理はITだけじゃなくていろいろな部署で使えます。カスタマーサポート、それから人事、マーケティング。こういったことの問い合わせをなるべくセルフサービスで解決できるようなつくりで社内外に提供することで究極的にはかなりのコスト削減が狙えます。
このサービスマネージメントという概念をどんどん広げる。そのお手伝いができるようにAtlassianも考えております。
チームのためのインシデントプレイブックを用意
そして、次の実践。IT運用はインシデント管理と問題管理の2つの軸で考えております。
インシデントのMTTRという概念があります。平均復旧時間ですね。こちらの研究もForresterが数年前に確認したところ、インシデントが発生してそれが復帰・解決されるまでに、解決に至るまでに、実はこの中の70パーセントは応答と調査に時間がかかっています。こういった研究結果が出ています。
それをどうAtlassianではやっているかというと、ここはやはりナレッジが肝になります。インシデントプレイブックを数多く作っております。
こういったような内容でインシデントプレイブックを定義し、執筆し、それらをチームを超えてシェアしています。
最後の8番目の「重大インシデントシミュレーションドリル」は、事前にインシデントが発生したケースを練習するようなイメージですね。こういうことができれば、かなり未然にインシデントを抑えることができます。
ただし、ポイントはどれだけ準備してもインシデントは発生するんだと思っているところですかね。Atlassianはやはりそれも思っていまして、この検知をするところにもひと工夫しております。
とりわけこのアラート管理をするようなチームは、たぶんいろいろなモニタリングツールが台頭してきて、本当にさまざまなアラートが来て、結局何が重要なのかわからなくなっています。そして関係ない通知もたくさん来るような状態に陥っていると思います。
これらのアラートをどう一元的に集約して管理していくか。そして、それを適切な人に適切なタイミングで渡せるようにするか。これはツールの力を借りて行っている次第です。
管理画面の1つです。例えばNew RelicやSplunkなども弊社は使っているんですが、それで弊社のシステムをアラート監視しておいて、それらをこちらのツールに一元管理しています。
そして、ここのツールで大事なポイントは、どういう条件のアラートだったらどういうチームにエスカレーションしていくか。また、そのチーム内でも、ローテーション組んだりしてますよね。どういう人にアラートを送るかが大事ですね。
これは、チーム全体にいつもいつも送ってしまうと、結局気をつける人にしか仕事が回ってこない。そうすると、ほかのチームメンバーの責任感もどんどん薄れていく。そういったことが起こります。なので、適切なタイミング・適切なポイントで適切な人間に送ることを自動化できるのが大事なポイントになります。
そして同様に、インシデント発生時、お客様のほうにどうインシデントを伝えるか。例えばWebサイトがダウンしてしまったら、そのウェブサイトはもうコミュニケーション手段として使えない。そういったツールの考え方もございます。
こちらは弊社のStatusPageというツールなんですが、なにかしら自社のWebシステムがダウンしたときに、こちらをお客様が見ていただければ、「今こういう状態なんだね」ということをコミュニケーション手段として使える。
インシデントが起きても黙って直すのが一番悪い。それをどうにか避けて、「インシデントが発生しましたよ。どれぐらいで復旧する見込みですよ」というのを常にオープンにお見せすることのほうが、インシデントを通じてお客様と信頼関係を築けるとAtlassianでは考えております。
さらに言えば、これをやるとサポートチケットが上がらなくなるんですね。「今はインシデント中で止まってるんだったらしょうがない」とお客様が思っていただければ、「なんか止まってるよ」というサポートチケットが大幅にカットできます。こういったメリットもあります。
そして、いざインシデントが起きたときにはメジャーインシデントにどう対応していくかというプレイブックですね。これらをちゃんと整備することです。
そして、関連ドキュメントをいろいろなサーバに置いてしまうと、たぶん探せません。それは弊社ではConfluenceというデータの一元的な管理をするツールを使って、そこにIT関連ドキュメントとナレッジベースをすべて集約するようにしています。これによって、IT運用チームもそうですし、開発チームも同時に必要なデータにアクセスできるようになっています。
さらに、弊社はメジャーインシデントが発生すると、そのインシデントごとにチャットツールでチャンネルを作って、関係者が一斉に集まって捌きます。そういうことをIncident Swarmingと言います。「この部署でまずチェックして、わからないならこの部署」とやっていくと時間がかかります。一斉にやる。
そのための人事的な仕組みもそうですが、このChatOpsはかなり効きます。弊社ではSlackを使ってこういったことをやっております。
自動化でコラボレーションを活性化
そして最後はオートメーションを駆使することです。マニュアルがあってそれに沿って人が作業するのはもちろん可能ですが、マニュアル化されているぐらいだったら、それをどうオートメーションするかという考え方に持っていくのが大事なところです。
そして、とくにインシデントや問題管理に関しては、ソフトウェアチームのほうでの変更があります。ただ、それがどう関連しているのかが往々にして情報が遮断されがちです。それをどう解決するか。
弊社では、Jiraを使っておりますので、それをどうリンクするかが日常的に行われております。どんなツールを使うにせよ、この課題がリンクしていること、情報がつながっていること、トレーサビリティを確保することが非常に大事になります。
これらは、同じく問題管理のほうでも適用できる話なのだと思います。
そして、最終的に一番大事なのは学びですね。どうレトロスペクティブ、振り返りをしていくか。とくにこれはメジャーインシデントに関しては毎回やっております。
そして、これを部署を超えてシェアすることで、同じようなことが起きたときに対処したことがわかる。そういったポイントがわかる。こういったことをシェアすることは非常に大事です。
Atlassianではこれらを内部でも実践していますし、それに沿ったツールの提供もしております。とくにこのオープンにコラボレーションをして知識をシェアする。
これはインシデント管理なんかはそうですけど、1回設定したら終わりではないんですね。継続的にどう改善していくかがポイントになります。
インフラ変更の流れが意味すること
最後にインフラ変更の話ですね。ここが一番大きく、DevOpsやアジャイルの実践が入り込んできたところが一番大きく変わった点になります。副題ということで「ビジネスの要求とリスクのバランス」をつけております。
これはインフラ変更そのものの風景が変わったという表現をしています。おそらく50年前と比べても、ITインフラそのものが大きく変わっています。もちろんクラウドの台頭が一番のポイントになりますね。
そして、それを変更・コントロールすること。リリース＆デプロイすること。こういった流れの運用のプラクティスになります。
それをどのようにコントロールしているんだろうと振り返ると、おそらく今までのITIL 3、ITIL 2011のあたりでの変更管理のプロセスを見てると、だいたい承認が多く絡んできました。
確かに変更してプロダクションが壊れてしまうのは一番最悪なケースですね。それを避けるために仕方なかったプロセスの重視だったのかもしれませんが、やはり今スピード感が求められていると、どうしたものかとAtlassianも悩んでいます。
そこで考えられるのが、変更において「ノーマル」「スタンダード」「エマージェンシー」の区分けをすることです。例えばこの「スタンダード」という定義は、「ほぼ低いリスクのもの」というような位置づけになります。こういったものをどう自動化していくかがAtlassianでも1つ課題となりました。
ビジネスのスピード感にどう応えるか。そして、そのために承認をなるべく意味がないんだったら自動化してしまう。効率的にする。それらの価値判断はリスクと価値をどうバランスづけるかになります。
こちらも同じく変更のPIR、Post Incident Retrospectiveの振り返りをどう継続してやっていくかがポイントです。実はJira Service Deskというツールを使って、この変更リクエストの対応をすごくシンプルにやっております。
それにあたって、スライドの構成管理ツールを使っております。どの変更がどのサービスおよびアセットに影響があるかをまとめる。これはすごく大事ですね。逆に言えば、この構成管理と変更管理をきちんとつなげることが非常に大事になってくるわけです。
変更管理は「バランス&リーン」が重要に
そして、インシデントプレイブックのように、変更計画をきちんとドキュメント化することが非常に重要です。そして、どう自動化を駆使するか。
スタンダードの場合は、一番はじめの承認を自動化してしまうフローを組んでいるようなイメージ図になります。どのようにオートで承認可して次のステップに移行するか。こういったことで一段階スピードを速くしていくわけです。
実際に弊社のお客様が、ヨーロッパの企業になりますが、昔ながらのITSMツールから移行して70パーセントのスタンダード変更を自動化しました。これで一気に時間の短縮が可能になったという事例も出ております。
そして、変更管理のその先はかなりDevOpsで行われてきて、成功してきたベストプラクティスを採用するのがいいと思います。どのようにデプロイをしてさらにリリースをするか。
そして、これに関しては今日はそこまで多く触れませんが、Atlassianでは例えばフィーチャーフラグを採用して、デプロイをするけどリリースはあとの工程で、トリガーを別に用意するやり方もあります。これによって一連の流れを自動化することが可能になってきています。このあたりのリリースの実践もプラクティスを多く見ていくのがいいかと思います。
変更管理のまとめですね。ポイントになるのはやはりこのバランスという感覚です。変更管理に関してはとくにこのバランスが非常に大事になります。すべての承認フローを回すことも、もちろん大事と言えば大事です。ただ、スピードが求められているなかでは取捨選択すること。Atlassianではスタンダードな変更をどれだけ自動化するかでいま実験をしている段階になります。
このような話は、AtlassianとITIL 4の実践や取り組みについて、ホワイトペーパーを実は出しております。日本語化もされております。これからもAtlassianの日本法人は、がんばって日本のお客様にソフトウェア開発およびIT運用、それぞれにお役立ちできるような製品提供を続けていきますので、ぜひお気軽にお声がけいただければなと思います。
以上になります。本日はありがとうございました。
（会場拍手）
