Atlassian Summit 2016 DAY 2 基調講演レポート

こんにちは。週末には、先週米国サンノゼで行われたAtlassian Summit 参加から帰国しました朝岡です。少し遅くなりましたが本日は、2日目の基調講演の内容をお伝えします。

ご参考: カンファレンス初日の基調講演では、あらゆるチームを支援する様々なアトラシアン製品に関する新しい情報が、それぞれの製品担当より発表されました。初日に関する詳細はこちらの投稿をご覧ください。

2日目は、共同創業者及びCEOのひとりScott Farquhar が、相方の Mike が昨夜のパーティーで楽しんでいる様子を残したFacebook メッセージを見たのを最後に行方不明になっているという事で、会場のみんなに捜索願を出すところから始まりました。

img_0200
我々は、人類の歴史におけるどの時代よりも早い速度で世界が変わっていく驚異的な時代に生き、20年前はSFの世界だけだったことが、日々当たり前になっている。「製品の購入」から「サービスの利用」へと変わった経済状況は、それらを作る側の組織やチームにとって広範囲にわたって様々な影響を及ぼすとし、これまでのやり方が通用しない中、どう適応していく必要があるのか。その変化への適応を支えるアトラシアンの製品や取組に関する話がありました。

では早速その内容を紹介していきたいと思います。

サービスファーストの時代におけるチームワーク

何年のもの間、多くの企業は長く利用する物理的なグッズを作ってきました。製品開発のペースはゆっくりで、新しいモデルが市場に出る頻度は低い一方で、サービスは人への依存度が高く、拡張性がないものでした。ブロードバンドとモバイル、インターネットの登場がその全てを変え、以前では不可能であったスケールでサービスを提供することが可能になり、現代の最も大きく、急速に成長している企業のほとんどは、製品ではなくサービスを提供している企業だとしてUberやSpotifyに触れ、GoogleのPixelを例に、もはや現代の「製品」は「サービス」へのアクセス手段に過ぎないとし、サービスの時代への変化を説明しました。

img_0198
その変化に伴い、1年に1度のリリースとそれに対して行われるフィードバックは、毎月、毎週のリリースと恒常的なフィードバックとなり、企業のオペレーションに求められるスピードは劇的に変わりました。個別の部署の最適化が効率化につながった時代に対して、チーム間のバリアを取り壊し、俊敏な機能横断型チームを作る必要性が生じます。

アトラシアンは10年以上この問題を解決する支援をしてきた事に言及しながら、話は開発プロセスの変化へ。

ウォーターフォールと呼ばれた世界では、ビジネスと開発チームの間に高い壁が存在し、数千ページのビジネス要件ドキュメントが壁の向こう側へと渡されていたところ、時代の変化へ対応するために生まれたビジネスと開発チームのコラボレーションを、私たちはAgileと呼びました。
また、開発と運用チームの間にも高い壁がありました。1年に1回のリリースがあった世界で通用していた100万行のバイナリーファイルを壁の向こうに投げるというやり方は、毎月毎週リリースする世界では通用しません。結果として生まれた開発と運用チーム間のコラボレーションを、DevOpsと呼びました。

アトラシアンは、すでに長いこと組織間のバリアを取り壊すことを支援してきましたが、組織を横断したコラボレーションの実施を支援しようとしている企業は他にないとして、サービスの構築と運用という世界への適応を、どうアトラシアンが支援できるかという話へ。以下の3つの視点からの説明が続きます。

  • どう開発者がコードをビルドし、デプロイするか
  • より良い体験を顧客に提供するために、どのようにサイロ化された組織の壁を取り壊すか
  • どのようにパフォーマンスの高いチームを作り上げるか

3bullet

マイクロサービス時代のBitbucket Pipelines

まずはサービスの世界が開発チームに与えた影響から。

製品をリリースしていた時代の開発は、何百ものプログラマーが調和をとって1つ巨大な製品を作るために、非常に高度で複雑なプロセスが必要でした。そのような時代に最適なツールとして開発されたBambooに対して、マイクロサービス、コンテナリゼーション、新言語、クラウドなどのテクノロジーによって、個々のチームが独立して、それぞれのペースで仕事が出来るようになった現代の状況に合わせたビルド&デプロイツールとして新たにクラウド上に直接作ったのがButbucket Pipelineであると説明し、より迅速な開発を可能にした、旧来の方法と異なる4つの機能を説明しました。

  • Configuration as Code
  • Bitbucket ネイティブ
  • 無限の拡張性
  • エコシステム

Configuration as Code

多くのビルドシステムでは、コードと、そのコードをどうビルドするかを指示する設定ファイルは、別の場所にあったため、コードの変更に伴ってそのビルド方法を変えるには、別のシステムにアクセスする必要がありました。Pipelinesでは、これを一緒にしたことにより、多くのメリットを提供します。
まず、簡単に始められる。シンプルな設定ファイルをソースコードリポジトリにコミットすれば良いだけ。コマンドラインからもコミット可能。業界標準のDockerコンテナ上に構築されているため、どんな言語や環境で運用していても、標準ですぐに始められる環境が揃っています。ビルドは完全に独立したプロセスで実行するため、ビルド環境を開発環境と同じように設定でき、その差を懸念することもありません。
ビルド設定をリポジトリで管理するもう一つのメリットは、コードと共にバージョン管理することができることです。また、コードと同じようにブランチを作成、バージョン管理することができます。

Bitbucket ネイティブ

2つ目は、Bitbucketネイティブであるという点だと伝え、ビルドシステムとコードリポジトリが別々の存在する一般的なケースに比べ、時間の節約が可能な事。さらに、ブランチを作成する前にビルドの状況を確認することができるため、瑕疵があるコードに着手してしまう心配、または壊したのは自分ではないかと心配する事態も防げるとする。そこで、アトラシアンではコードを壊してしまった人がかぶる帽子があったが、Pipelineを使い始めてからその帽子は部屋の片隅で埃をかぶっているというエピソードを紹介し、会場の笑いを取っていました。

無限の拡張性

3つ目は、無限の拡張性を備えている点です。一般的なビルドシステムでは、予め必要なキャパシティを設定しなければならないため、必要と予想される分をプロビショニングしますが、実際にはリソースが足りなかったり、稀に多く設定し過ぎたりすると、他の機能開発に使えた時間やお金を無駄に費やしてしまいかねません。Bitbucket Pipelineは、クラウドに構築されているため、状況に応じてスケールアップやダウンが可能。開発者を待たせる事がないというのは、他のビルドシステムでは得られない大きなメリットだと強調します。

エコシステム

最後に、エコシステムです。Pipelineは業界標準のコンテナマネージメントシステムであるDockerに構築されている事は既に触れられていましたが、それはつまり、予め用意された100,000以上の環境があるという事に加え、既存の環境を拡張して、カスタマイズすることも可能だと説明します。また、メジャーなクラウドプロバイダーと提携しているため、パブリッククラウドへのシームレスな統合も実現。テストプロバイダや依存関係の管理システムとの統合も可能であると話しました。

ecosystem

この優れたPipelineを皆に使ってもらいたいという思いから、価格設定を1分あたり1セントにした事を発表したところで会場から拍手が沸き起こります。コーヒー1杯より安い値段で1日中ビルドとデプロイをすることができるのは、従来のやり方を一変します。マイクロサービスの世界にいる方々は勿論、まだ一枚岩の「製品」の世界にいる方々も含めてすべての方にPipelineを試して頂きたい為、さらに年内一杯はPipelineの使用を無料にしたことを発表。もう使わない言い訳はないし、基調講演終了前に初めてのビルドを走らせることができるくらいの簡単さであるとして、コミカルにPipelineの使用開始を呼びかけたところで、ステージ上にDidier Morettiを迎え、アトラシアンがいかにして組織間の壁を取り去ることに貢献できるかに話しは移ります。

Connected Teams

img_0202

マイクロサービスの世界では、継続的に変更を繰り返すが故に間違いも起こりやすく、サービスに依存する顧客への影響も大きなものになります。複雑なシステムや組織は、つまり問題点も見つけにくくなることを意味し、チームが必死にシステムや組織にまたがって原因を探っている間、顧客はすぐれない体験で待たされます。お天気情報提供サービスなら良いのですが、ミッションクリティカルな場合はそうはいかない事を、自分の娘がJustin Bieber のコンサートチケットを予約する時のWebサイトがダウンし、結果的にチケットが入手できずに悲しみに暮れていたエピソードで伝えます。

しかし現実問題として、サービスを運用するために共同作業をしなければならないチームは、サイロ化されたシステムや組織にわたって存在するため、悲しみにくれるJustinファンにすぐに解決策を提示する事は簡単ではない。運用チームはアラートの嵐に飲み込まれ、開発チームへの対応依頼に、問題そのものの対応よりも多くの時間を費やします。一方で開発チームは運用チームからの問い合わせをかわすことに躍起で、実際の問題追及に至りません。もっと酷いのはカスタマーサポートチームで、答えがない中顧客からの問い合わせ攻めにあいます。高度なカスタマーサポートアプリケーションがあるにもかかわらず、必要なデータを持つ離れた開発チームにメールや電話で問い合わせている間、顧客は何が起こっているか知る術がありません。このような開発、運用、カスタマーサービスチーム間の調整は、痛みと時間を伴い、解決までの時間は好ましいものではありません。

サイロサイロが問題になるのは、障害対応チームだけではなく、組織のあらゆるチームが運用している様々なサービスに一緒に対応できなければなりません。サービスの世界では、最も必要とされる時に適切な人間が一緒に早いペースで対応できるよう、摩擦を生む壁を作り、劇的に物事のスピードを遅くするサイロは取り除く必要があります。
開発と運用チーム間の壁を取り壊すことは、皆さんがよく知るDevOpsムーブメントの要です。DevOpsには色々な側面がありますが、コアコンセプトとしては、開発と運用が一緒になってゴールやプロセス、ツールを共有し、より良いサービス提供のために迅速に動くこと。

そのDevOpsは勿論とても重要だが、それだけでは足りない。カスタマーサービスも、開発や運用チームとゴール、プロセス、ツールを共有し、顧客に優れたサービスを提供するエンドツーエンドアプローチの一部でなければならないと訴求します。これらのチームをまとめることは、まさにアトラシアンの目指すところに他なりません。
ここで、アトラシアン製品にまたがって使用されているメディアサービスに起こった障害を例に、アトラシアン自身が何を学び、どのように日々この問題に対処したかが共有されました。

ある日突然、今まで経験したこともないような数のエラーが発生し、運用チームが対応に追われる。アトラシアンではそんな状況に対処するために3ステップに整理されたプロセスを紹介。問題の検知、顧客やステークホルダーへのコミュニケーション、最後に適切な人間が集まって解決することです。
まずは問題の検知。様々な人から、様々な方法で、異なる情報が寄せられるのを、一つの事実にまとめるのは難しいことですが、JIRA Service Deskなら可能です。主要なモニタリングツールと統合し、顧客からのチケットと一緒に管理できるため、運用チームとカスタマーサービスは同じ情報を、信頼できる唯一の情報源(Single Source of Truth )として共有し、事態を把握することができます。

次に、コミュニケーション。StatusPageは、サービスが落ちている場合も含めて、常にサービスのステータスをお知らせします。StatusPageを利用する前のアトラシアンでも、各所からの問い合わせに対処することが困難であったことに触れながら、StatusPageによって、カスタマーサービスチームは障害が発生した瞬時に適切なチャネルを使って利用者に通知することができ、問題の対処により時間を費やすことが可能になったと話します。適切な通知により利用者の心象が良くなるだけでなく、問い合わせ件数も劇的に減少します。障害発生のケースでは、状況のアップデートが必要なのは利用者だけではありません。StatusPageの優れている点は、外部の顧客向けのパブリックなページだけでなく、内部用のプライベートなページで、より詳細な情報を提供することができる事です。この事により、顧客からの質問攻めにあう事は防止し、解決策に取り組む時間を確保できます。

問題を検知し、状況を周囲にアップデートする方法があれば、次にすべきは迅速な対応です。ここを間違うと、問題解決までに膨大な時間を費やしてしまうことになり兼ねないのですが、組織にいる離れたチームが瞬時に集まり、高いプレッシャーの中で高い水準の仕事を成し遂げなければなりません。サイロ化された組織ではそれは難しいですが、アトラシアンは違いました。

運用チームは、Confluenceにまとめられた障害対応マニュアルを元に、適切な人間をアサイン。各チームの共有情報参照先であり、顧客や関係者とのコミュニケーションチャネルともなるJIRA Service Deskの障害チケットに呼び込みます。加えて、リアルタイムで迅速にコミュニケーションできるツールを2つ、HipChatのライブインシデントルームと、Confluenceでのライブインシデントドキュメントも使います。HipChatのライブインシデントルームは司令室として、組織中の誰もが入って情報を確認したり、発言することによって、一緒になって解決策を探ります。このようなフリーフローのコミュニケーションは、情報や人が多く、障害が複雑だとメッセージを見逃してしまうため、ここでConfluenceのライブインシデントドキュメントが役立ちます。共同編集機能を使い、関係者みんながそれぞれの見解や見通し、コミュニケーションのドラフト、対応策の提案などをまとめる場です。自由に流れる会話よりもまとまって整理されているため、人々が状況をより理解しやすくなります。

このように、アトラシアンの障害対応チームは、問題を検知、関係者に共有、問対対応に当たり、解決しました。ですが、これで終わりではありません。このままでは、問題を解決するのは早いかも知れませんが、次から次へと問題へ対峙する、モグラ叩きゲームをやっているような状況が続きます。障害というのは、システムやサービスの欠陥を浮き彫りにし、それを改善する機会を与えてくれるのです。マイクロサービスを使った複雑なシステムにおいて、耐障害性のあるサービスを作るには、学習と改善を標準プロセスにしなければなりません。例えば99.99%の稼働率ということは、一月に4分、一曲も聞き終わらないかもしれないくらいの短いダウンタイムしか許されないという事。このレベルに到達するためには、学習と継続的な改善をシステマティックにやる他ありません。

そこで、プロセスに最も重要とも言える4つ目のステップです。障害を振り返り、いつ何がどこで起きて、どういう判断のもと、どんな対策をいつとったか。また、そこから根本原因を探り、適切な人に対策をアサインします。

ここまではいいのですが、多くの場合、障害対策チームが解散してしまうと、このようなドキュメントはメール、チャット、ドキュメントフォルダなど、見つからない場所に埋もれてしまい、二度と見られなくなります。
JIRAなら違います。インシデントの振り返りから発生したタスクは、デリバリーチームの対応が必要なバックログとして直接JIRAに記録され、開発チームの中でどのように優先順位がつけられているか、いつでも確認することができます。

しかしこれだけではなく、情報を共有することが大事だと、再びメディアサービスチームの障害を例に続けます。メディアサービスの障害から程なくして、BitbucketやHipChatにも幾つか障害が発生しました。現象や技術的解決策はそれぞれ違いましたが、根底にある原因は似たようなもの、つまりインフラにおける予想できないスパイクや障害をより上手く扱う方法が必要だということでした。この事は、障害対応の振り返りで発見した事、学習した事などを組織横断で共有した事によって、マイクロサービスにおいて共通で強化しなくてはいけない部分が分かったのです。アトラシアンでは、常にチームや個人の見識を共有する事を強く推奨する文化があり、それがDidierがアトラシアンに入社理由の一つでもあると明かしつつ、Confluenceなら重要な見識は失われたり、サイロ化もされない事。たくさんのチームが関わるサービスの世界では、共有はオプションではなくクリティカルである事。耐性のあるサービスを構築するには、学習した事を広める事が重要だと再度強調。

アトラシアンは、あらゆるチームが壁を取りさらって一緒に作業をすることを夢に見るほど真剣に考え、あらゆることがサービスとなっていく世界に於いて、皆さんのチームの働き方を変えていく支援ができることにワクワクしていると熱弁したところで、スピーカーは再びScottに戻ります。

Team Playbook

これまで優れたチームワークをどう作るかについて、アトラシアン製品がどのようにチームを支援できるかについて話されましたが、最後は、高いパフォーマンスを出すチームを作るためにアトラシアンが行っていることについてです。

まずは昨年のサミットでも紹介されたTeam Health Monitor(THM)です。THMとは、1時間以内で実施でき、チームに影響を及ぼしている課題を浮き彫りにすることができる健康診断のようなものですが、アトラシアン社内で500以上のチームで走らせたこのTHMについて話したセッションは昨年のサミットで一番評価が高かったセッションであり、外部の方々からリクエストが殺到し、フィードバックも素晴らしいものだったとして、幾つかのフィードバックを紹介。その後、外部で数百のTHMを実施した結果、チームによって評価すべき属性や要件が異なることに気づいたため、THMをリリースした当初は1種類しかなかったものが、現在ではプロジェクトチーム、リーダシップチーム、サービスチーム用の3種類を観測していると伝えました。

thm
さらに、課題の発見は勿論重要だが、それをどう治すかはもっと重要だとして、新たにTeam Play をリリースしたと公表します。Team Playとは、THMでチームに特定された共通の課題を修復するために1時間以内に実施できる演習だとして、具体的な例で説明します。例えば、プロジェクトチームが抱える最も大きな課題は共通の認識を持つことである事が分かった場合、幾つか実施できる"Play"があります。例えば1-2行でチームが何を達成しようとしているかを説明するElevator Pitch。さらに、プロジェクトで解決しようとしている問題やそのインパクトなどをチームに聞いて回って作るProject Poster。またはチームが利害関係者と今やっている事について共有する定期的なミーティングを実施して、達成しようとしているソリューションに対して共通の理解があるか確認するDemo Trustなど。 これら3つの例は、アトラシアンがTeam Playbookにて公開する20あるPlayの一部です。

これらすべての使い方について、アトラシアンで比較的最近作られたJIRA Server チームを例に説明しました。今まで一緒に働いた事がないメンバーが集まって最初に実施したのはTHMです。最初の評価結果は黄色や赤ばかりでしたが、順次適切なPlayを実施し続けた結果、ひと月後のモニター結果に劇的に改善が見られ、さらに一ヶ月後にはほぼ全てがグリーンの状態になりました。THMとPlayがなくてもいつかは優れたチームになったかも知れませんが、これらによってチームの改善が簡単に行え、皆さんにも採用をお勧めする手法だとし、これらすべてを含むTeam Playを外部にもリリースする事を発表しました。Team Playbookには、3つのTHMと20のPlayが含まれる他、これらをConfluence クラウドのブループリントとして提供します。

playbook
詳細は、Dr.DomのセッションやBoothがある他、Webサイト www.atlassian.com/team-playbook で確認できる事を紹介し、Team Playbookの活用を推奨しました。

優れたチームと「あなた」に感謝

最後に、アトラシアンがサービスの世界でどのように開発チームを支援するか、全てのチーム間のサイロをどう取り壊すか、そしてTeam Play bookで高パフォーマンスチームを作る方法について話たことを振り返り、「優れたチーム」がアトラシアンにおいて重大な意味を持つ事を再度強調しながら、アトラシアンを活用して世の中に影響を与えている様々なチームの事例を紹介し、最後に会場にいる参加者ひとりひとりがいなければ出来なかった事だとして、日々素晴らしい事を続けて欲しいと願いながら、MikeとScottの二人からの感謝の気持ちを表現して基調講演を終わりました。

img_0208


今回のサミット期間中、個人的に米国の某大企業と話をする機会がありましたが、アジャイルなチームを作るのに一番重要なことは?という問いに対して、瞬時に「文化を変えること」と答えていたのが印象的でした。日本企業は諸外国よりも働き方やそのプロセスが前時代的で致命的にスピードが遅く、現行の文化を変えていくのは並大抵の事ではないと思っていましたが、現在弊社製品を大規模に活用されている米国企業でさえ、そこが問題だと思っていることに、意表を突かれた思いがしました。

ツールは何かを便利にすることはできるものの、その導入だけでは競争社会の中で生き抜き、さらに言えば牽引する力を持った強い組織が完成するわけではありません。いかにして強い組織を作るのか、製品だけではなく多面的な支援策を惜しみなく公開しようとし続ける弊社の姿勢に、改めて共感した基調講演でした。

見逃した方は、ぜひ録画をご覧ください。

また、基調講演中に紹介のあったTeam PlaybookのWebサイトは日本語化を予定しております。ぜひご活用下さい。