大規模Confluence管理者のノウハウ
高橋邦洋氏：では、今回評価していただいた発表はどんな内容だったのか、お話ししていきたいと思います。ここからが登壇内容です。スライド自体は英語ですが、簡単な英語なのでそこはご容赦ください。
この中でConfluenceの管理者の方はいらっしゃいますか？
（会場挙手）
ありがとうございます。Yahoo! JAPANでは、現在約1万4,000人でConfluenceを使っているんですが、その上での管理者ノウハウをお話させていただきます。
自己紹介で「三つ子です！」みたいな感じでやったんですけど、すごくスベりまして、もう最初に緊張感バッて上がってしまいました。
先ほどAUG（注：Atlassian User Group）は世界各国でやっているとお話しましたが、何人かのリーダーはJira QueenとかJira Genieeなどニックネームを持っています。せっかくなので自分も持とうと思い、やはり日本人ですしConfluenceにガンガン切り込んでいってるところもあるのでConfluence Samuraiと名乗っています。
2.4.3、これは何だかわかりますか？
これは私が最初に触ったConfluenceのバージョンです。このバージョンを知ってる方？ いない。じゃあ私が一番長いですね。ちなみに、ラスベガスで話したときには1人いらっしゃって、もう「お前は親友だよ」みたいなことをがんばって言いました。
次、11です。これは何の数でしょうか。私は11年間、Confluenceを運用しています。なので、昔のConfluenceや今のConfluenceについてご質問があれば、ある程度はお答えできるかなと思います。
次に7です。7回ぐらいアップグレードしています。このあと話すんですが、大規模なアップグレードというのは基本的にはすごく大変な作業なので、このぐらい痛い目を見ています。
次、34です。これ何でしょうか？ Tシャツです。
（会場笑）
今日も受付でゲットした方もいると思いますが、AtlassianさんのイベントではTシャツがたくさんもらえて、12年もやっているとこれぐらいたまります。
今日はお気に入りのTシャツを着てきました。
これですね。「JUST DO GIT.」と書いてあります。
（会場笑）
ちょっとおもしろい感じで作ったものですね。以上このような感じで自己紹介をしました。普段はあまり自己紹介を長くするのは好きではないのですが、こういう登壇においては効果的だということでやってみました。
Yahoo! JAPANとConfluenceの関係性
ということで、アジェンダは4つです。
Yahoo! JAPANのConfluenceの紹介と心構え、どのようにConfluenceのことに取り組んでいるか、最後にAtlassianに向けてのメッセージという構成です。
Yahoo! JAPANがどれぐらい使っているかというと、ConfluenceはYahoo! JAPANではすでに情報インフラになっております。その例を2つ挙げます。
先日もこちらの写真のように自然災害がありました。Yahoo! JAPANのサービスは災害の際に使われることも多いので、常に動いていることを求められます。
「Confluenceに運用手順をまとめているので、Confluenceが落ちていると自分たちもできなくなる」というところで、ConfluenceのBCPはYahoo! JAPANのサービスと同じぐらいのものをやってくださいと、会社内で求められます。
2つ目は「今夜、Confluenceをメンテナンスで落としますよ」と言うと、社員はチャット上で「Confluence、今夜使えないんだ。じゃあ今日は帰ろうよ」みたいなやり取りが行われます。 これがメンテナンスだったらいいんですが、トラブルだったりするときもありますよね。「今日はConfluenceが使えないから帰ろう」と。これは何を言いたいかというと、Confluenceが動いてないと仕事にならないということの現れです。
ということで、ConfluenceはYahoo! JAPANにとって、ミッションクリティカルツールです。
Yahoo! JAPANが運用するConfluenceの規模
では、そんなConfluenceをどのぐらいの規模で動かしているのかを説明していきます。現在、1万4,000人で動かしています。Confluenceのスペースの数ですね。1万スペースあります。
300万、これはコンテンツ、ページですね。ページだけでも300万あります。
今度は桁が増えて3,000万です。これはpage historyも入った状態だと、これぐらいのデータでYahoo! JAPANのコンテンツは動いております。
1。突然少なくなりましたが、これはインスタンスの数です。部署ごとにConfluenceを立てているわけではなく、全社で1つのConfluenceを運用しています。
これ、しゃべったときは5だったんですが、最近状況が変わりまして3になりました。これは管理者ですね。3人でやっています。これからお話しするような運用を3人で回しています。
といったところで、Confluenceのデータをほかのところをまとめるとこうなります。
こういうスライドを作ると、会場で写真を撮られるので、いいかなと思います。
赤いところだけ特徴的で、1日にだいたい4万〜5万回ぐらいのページ更新が行われます。先ほど1万4,000ユーザーと言いましたが、1人あたり2回以上はConfluenceを更新している、なにかしら保存しているという感じです。
Yahoo! JAPANで運用されるConfluenceのパフォーマンス
そんなConfluenceがどれぐらいのパフォーマンスで動いているのか、1分弱のビデオを作りました。
これを今から再生するんですが、ラスベガスではこれが再生しないというありがちなトラブルに見舞われました。YouTubeに私がしゃべった動画があるんですが、日本語でめっちゃ焦っている様子が写っています。今日はどうでしょうか。あっ、動きました。
（動画が流れる）
これはYahoo! JAPANのConfluenceなんですが、ちょっとページを見てみます。
ページはこのように表示されます。
今、編集画面を開いて、文字を適当に入れて、保存しました。そうすると、これぐらいのスピードで返ってきます。
次に、新規ページの作成です。空のページだとどのくらいかかるのか、適当に文字を打って保存しました。すると、これぐらいのスピード感。どうでしょうか。
最後にダッシュボードに戻ります。ダッシュモードはこれぐらいのスピード感ですね。どうですか？ ありがとうございます。一実は、（動画を）編集したときにAtlassian社員の人に「このコンフル速いですね」と言われました。
（会場笑）
これは深夜の社員が誰も使ってない時間帯とかではなくて、包み隠さず、ちゃんと最も使われている時間帯にこれくらいで動いています。
1万数千人で使っていてもこのくらいのスピードで動くことが証明できました。「同じようなものにするためにはどうしたらいいの？」ということをこういう場で積極的に情報公開をしていければと思っていますので、今日は再生できてよかったです。
1日4〜5万回ページ更新されるデータ量と速さを実現するシステム構成
では、そんなConfluenceを運用するための心構え、マインドセットについてお話したいと思います。
みなさん、インフラに求めることって何ですか？ たくさんの機能ですか？ 私は違うと思っています。一番重要なのはパフォーマンスと可用性です。Availabilityですね。
ただし、ユーザーからの要望は日々たくさん出てくると思います。これは運営している方、みなさんそうだと思います。
先ほど最新機能の紹介でもありましたが、日々新しい機能がついていきますし、たくさんのアドオンやプラグインなど、サードパーティーのベンダーさんが提供しているいろんな拡張機能もあります。「これをやりたいんだけど、これ入れてくれない？」みたいな要望が来ると思います。
あとは、ぜんぜん違った要望が来るケースもありますよね。
ただ、すべての人が絶対求めているのはパフォーマンスと可用性です。遅いほうがいいという人はなかなかいないと思うんですよね。基本的に、PerformanceとAvailabilityは絶対に必要です。
それはもう誰も否定しないだろうということで、そのことを心に強く持って日々来る要望に応えています。この気持ちを強く持って、これを忘れないように、すべての判断、すべての決定をしています。
では、その心構えを持ってどんなことをやっているのか、4つ紹介していきたいと思います。
客観的なシステムアーキテクチャとアップグレード、先ほど申し上げたアプリ、最後はユーザーのリクエストをどうマネージしているかです。
ここは単純な客観的技術なのでみなさんも参考にいただければと思いますが、先ほどのデータ量とパフォーマンスをどのようなシステム構成で実現しているかです。
現在、Confluence Data Center 6.5.2というバージョンで動かしています。Data Centerをご利用いただいている方はわかると思いますけど、2ノードで動かしております。
しゃべった当時はMySQLのバージョンは5.6だったんですが、先日アップグレードをして5.7になりました。ちなみに5.7になるとすごくいいことがあったので、もしMySQLを使われている方がいて、まだ5.7にしていない方は、5.7、おすすめです。
Javaのヒープメモリは18GBですね。これぐらいで動かしています。
右側が構成図です。Webがあって、APサーバがあって、DBサーバがあって、Data Centerなのでストレージがあります。WebサーバはApache Traffic ServerとApacheを組み合わせています。これは社内の事情があって、この組み合わせて使っております。Confluenceは2ノードで動かしています。
ここで言いたいのは、とくに難しい構成にはしていないということです。シンプルな感じで動かしていることがわかるかなと思います。なので、先ほどのようなデータ量でも、何十台も並べなければいけないということはありません。
アップグレードでは、新機能はどうやったらオフれるのか必ず調査する
続いて、アップグレードについてです。先ほども7回やったみたいなことを言ってましたが、アップグレードはConfluenceを運用する上で最も重要なタスクなので、気をつけてやらなければいけません。
たくさんのルールを自分たちで決めてやってるんですが、アップグレードでの4つのTipsについてセッションで紹介しました。ここからは細かい話になりますが、1つずつ見ていきたいと思います。
1つ目は管理者画面で何が変更されているか、チェックしましょう。
1.4.3のときの管理画面なんて本当に簡素なもので、なにか変更したかったらサーバに入って設定ファイルを書いて再起動しなければいけませんでしたが、バージョンを追うごとにいろんなことができるようになっています。ですので、次のバージョンになったときに、管理者は「どういうことができるんだろう？」ということをチェックしていただくのがいいかなと思います。
私はパフォーマンスと可用性を重視しておりますので、2番目に重要視しているのがこのバッチジョブです。Confluenceの中で動いているスケジュールジョブやキャッシュの設定に変更があるのかを見ていただくといいかなと思います。
これが内部的に動いていて「なんかこの時間になると遅くない？」「こんなのが追加されてたよ」みたいなことがあるかもしれないので、ここを確認することをおすすめします。
次は当然ながら「新機能のチェック」です。新機能って「どういう機能がつくんだろう？」と気になって試してみますよね。それは当然です。「どういうものがついて、どういう振る舞いなんだろう？」ということを見るのは当たり前だと思います。
我々Yahoo! JAPANは赤字の部分を気にしてやっています。「その機能はどうやったらオフれるんだろう？」と。新機能は確かに魅力的なんですが、時としてそれが問題になることも多いのが事実です。なので、その機能はどうやったら画面からオフにできるのか、ちょっと消極的かもしれませんが、常にパフォーマンスと可用性に基っているのでこういうことを調べるようにしています。
仮にオフにせず、オンにしてリリースした状態であっても、「あっ、これやばい」ってなったら「いや、そこをオフにすればいいよね」と冷静に対処することができます。
経験上、多くの場合、Confluenceの追加機能はアプリ、プラグイン、アドオンとして提供されていることが多いので、そのアドオンを無効にすれば新機能もオフになることが多いです。アップグレードするときはそこに注意してみてください。
パフォーマンステストと事前のバグチェック
3つ目のTipsは「パフォーマンステスト」ですね。性能テストです。2種類やってます。
Before/After Performance Test。これはもちろん古いバージョンと新しいバージョンでやっています。
次はVolume Testですね。Performance Testは自分たちが動かしているバージョンと新しいバージョンでやることを想像しやすいかと思いますが、Volume Testは何をやっているのか。
新しいバージョンにすると、先ほどのように1日4万〜5万回更新されていきます。もうすごい量でデータが増えているわけです。それが今の性能で3ヶ月後、半年後も動いているのか。やはりそこまでわかっていると管理者としてはすごく楽ですよね。いきなり遅くなるということがありません。
ということで、次のアップグレードまでの性能を担保するために、検証環境でデータを増やして、今のデータと、だいたい1年後ぐらいのデータにして、それを比較するようなことをやっております。
過去にこれで（問題を）見つけたこともありますね。
最近はConfluenceさんがんばってくれているところもあるので、「問題ないね」ということや「ちょっとしか変化しないね」ということのほうが多い気がしますが、これをやっておくとやっぱり安心です。
4つ目。これがAtlassian製品運用の1つの特徴的なところかもしれませんが「事前にバグを調べておく」。
残念ながら「バグのないソフトウェアはない」とよく語られますが、Atlassianの場合、「jira.atlassian.com」というサイトでバグ報告を受け付けたり、そこでユーザーとやりとりをしています。
これから自分が上げようとしているバージョンをターゲットバージョンにして、ここはJiraの書式っぽいですが、検索をすると、これから上げようとしているバージョンのバグが何かを事前に把握することができます。例えばそこがクリティカルだったらしっかり見る必要があると思いますし、ひととおり見ていただくのがいいかなと思います。
仮にそれが次のバージョンで直るであったり、workaroundがどうとか、Jiraでコメントされていることが多いので、仮に起きたとしてもworkaroundで凌げばいいやとか、事前に回避することが可能です。Atlassianはこういう情報を公開していて、セルフサービスでいろんな解決案を自分たちで求められるので、我々Yahoo! JAPANでは上げようとしているバージョンでどんなバグが報告されているかを見るようにしています。
アプリを選ぶ3つのポイント
次に、アプリです。先ほど言った拡張機能、問題があるかもしれないアプリにどう取り組んでいるのかです。アプリって、当然便利ですよね。例えばGliffyとかで図を描けるよね、みたいな。でも、それをやるにはとても注意が必要です。
最初は「Confluenceやろう！」となって「あっ、こんな拡張機能がある」ということで導入しても数人で使っているから問題になることがなく、「うわ、便利便利！」ってパカパカ入れてしまい、使う人が増えたときに「うわー」ってなることが多いです。経験のある方もいらっしゃると思います。
その上で、大規模で運用する場合にどこに気をつけてプラグインを見ているのかをお話していきたいと思います。
1つ目。これはConfluenceが得意なやつですね。Confluenceの場合、やはり拡張がマクロで提供されることが多いです。そのマクロの特徴的なところで、処理の範囲を示すようなものがあるオプションは気をつける必要があると思います。
例えば、画面にあるとおり、スペースの範囲を指定するもの。「このスペースのこういうページの情報を拾ってきて、なにか表示しますよ」みたいなものがあったときに、「@all」とやると、先ほど数字を出しましたが、弊社の場合は1万スペースあるんですよね。ですので、「@all」をやった時点で処理が1万倍になってしまいます。
やはりアプリやプラグインは機能拡張や便利さを追い求めているところが多いので、今回はスペースですが、例えばページツリーの深さやページの範囲、例えばページのタイトルで正規表現で引っかけてくるものですとか、そういったものは気をつけていただいたほうがいいと思います。
2つ目、サポートがどうなっているか。これは当たり前のことなんですが、Atlassian Marketplaceというスライドがありますが、そこのどこを見ればいいのか、3つ書いています。
1つ目はサポートされているか・されていないか。「Supported」となっているものを選びましょう。ノーサポートのものはサポートしてもらえないですから、問題が起きても自己責任です。なので、サポートしてもらえるものを選びましょう。
2つ目がVersionsです。ここでプラグインの更新頻度がわかります。やはりたくさん更新しているものは改善が早いと思っていただいていいのかなと思います。Confluenceのバージョンが上がっていくので、ちゃん追従していることや、バグフィックスをしっかりしているというのはやっぱり見るところかなと思います。
Atlassian製品がバグを公開しているのにならって、アプリのベンダーさんも情報公開していることが多いので、そこを見ていただけるといいかなと思います。
3つ目がDocumentsです。ここにドキュメントのリンクがあることが多いです。アプリの使い方や問題について書いてあるので、Supportからドキュメントをたどっていただければいいのかなと思います。アプリは機能のほうに目が行きがちですが、選ぶ際にはこの3点に気をつけていただけるといいのかなと思います。
3つ目、これも細かいところですが、Confluenceの場合、画面をきれいにするとか表示をするなど、いろいろなタイプのアドオンがあります。ブラウザ上だけで動くような、スタイルを決めるとか、JavaScriptだけで構成されているとか、そういったものがあったりします。
逆に言えば、Confluenceのアプリケーションサーバの処理が及ばないもの。及んでいるものはたくさんの人が使うと問題になることが多いですが、ブラウザだけで完結しているものは仮に起きてもその人だけだったりすることが多いので、クライアントサイドだけで動いているようなアプリがあれば、問題になりにくいかなと思います。
それこそサミットにはたくさんのアプリのベンダーさんいますが、「このプラグイン、便利そうだけれどサーバまで処理してる？」とか、「クライアントで処理してる？」と聞いていただいて、「クライアントだけで動くよ」って言ったら「ありかも」と思っていただくのがいいかなと思います。
ということでアプリを選ぶ3つのポイントでした。 これも「写真撮ってねコーナー」なんですが、Yahoo! JAPANで導入しているアプリの一覧になります。
なので、ここに並んでいるものは1万4,000人で使っても問題ないと言ってしまっていいと思います。こうした客観的な事実を散りばめておくといいかなと思います。ちょっといっぱいありますが、こんな感じですね。
個人的におすすめなのは下から2番目です。「Table Filter and Charts for Confluence」はサポートの頻度もバージョンの更新も多いですし、「そこを直してほしかったんだよ」というところを直してくれます。かつ、クライアントだけで動くような機能があるので、以前AUGの場で紹介したことがありますが、Confluenceの表をよりExcelに近づけて使いたいと思ったら見ていただくといいのかなと思います。
1万人以上のユーザーとの向き合い方
最後に、Manage User Requestsです。ユーザーとどう向き合っているのかをお話したいと思います。
サービスを、外向けのサービスをやるときにはよく聞くと思いますが、ユーザーの声は非常に重要ですね。でも、ユーザーの声というのは、1万人以上にもなればコンフリクトを起こすこともあるというのが私の感想です。
1つ、代表的な例を出したいと思います。Editorです。
左側の人が「マークダウン使いたい」と言っています。ConfluenceでTwitterを検索するとこれは定期的に見ます。
でも、別の部署からは「もっとWordっぽく使いたい。なんで文字のサイズを変えられないの？」みたいな要望が来たとします。今は変えられないと思うのですが、Word・ExcelからConfluenceに移行してといったとき、それ使いたいとなると、こうした要望は相反するようなものですよね。
ConfluenceやAtlassianの製品は「すべてのチームを」とすごくかっこいいことを言っていますが、求めるものが違う人たちに提供しているツールでもあるとは思うので、こうした相反するものが出てきてしまいます。
なので、すべて人を満足させるのは難しいと思います。ですので、管理者としてはユーザーをカテゴライズしてどう対応していけばいいのかを考えて、ユーザーの声を一緒くたに考えず、カテゴライズして対応しています。
ということで、今回は2つ、ヘビーユーザーとライトユーザーについて話していきたいと思います。
ヘビーユーザーの要求は「こういう機能を使いたい」です。勝手にAtlassianのサイト見たりMarketplaceを見て「これを入れてほしい」と。「なんでそれ見ちゃったの？」って感じがあると思うんですよ。
（会場笑）
彼らは自分たちが何をしたいか理解しているわけですよね。何が欲しくてどういうことをしたいかを理解しているから、そういう要望をするわけです。こういう人たちとは、わかり合うしかないですよね。もしくは頭を下げるしかありません。
一方のライトユーザーです。Confluenceを全社員で使っていくと、この人たちは「使い方を知りたい」となります。「Confluenceで議事録書けと言われたけど、どうしたらいいかわからない」みたいな。彼らはConfluenceで何ができるかわからないわけです。なので、何を尋ねればいいかもわからないんですね。もうポカーンとしちゃうんですよ。
ヘビーユーザーたちは勝手にガンガンやるわけですね。言わなくてもいろんなことをするのですが、ライトユーザーたちはなにもできません。どちらが悪いとかではなくて、そういう特徴があるという話です。
ライトユーザーをバッサリ切らない
今回は、私たちがやっているライトユーザーに向けたソリューションを紹介したいと思います。この人たちは、継続的な助けが必要です。「リテラシーないからな（バッサリ）」ではなくて、継続的な助けが必要です。
Yahoo! JAPANでやっている取り組みとしては、ライトユーザー向けのオンデマンドセミナーを3人で運用しています。
テーマはこんな感じで、10個ぐらいセッションを作って、「要請があったらいつでもやるよ」みたいな感じで準備しています。
この中で一番おすすめなのが、スペースの権限管理です。Confluenceで12年間でやってて一番お問い合わせあるのが、「ページが見れなくなっちゃいました」という問題です。 スペースの権限とページの権限の構成を理解できていなくてこういうお問い合わせが来ることが多いので、セミナーの運用を始めるきっかけも、これを正しく理解してほしいというところでした。そこから広がって、ページの作り方や編集の仕方、マクロの使い方をやるようにしました。
ポイントはいろいろ悩みました。集合研修で定期的にやるということも考えたのですが、やるほうも大変なので、受けやすくするために1対1でやったりと比較的少人数でやっています。 Yahoo! JAPANに入ってきて2日目ぐらいでいきなり「Confluence使え」みたいになってしまうので、そういう方が「Confluenceってどうすればいいですか？」と1対1でも対応できるようにしています。
1つのセミナーはだいたい15分前後でやっています。例えば1時間びっちりやったり、半日コースにしてしまうと、みなさん忙しいですからそう簡単に受け入れられません。ですので、15分ぐらいで終わる。下手したらお昼ごはんを食べながら聞いてもらってもいいです、みたいな感じでやっています。なので、受けやすくすることを重視してやっています。
やってみてどうなったかというと、ページを作る人と発信する人が増えたかなと思います。
あとは、ユーザーたちが我々に問い合わせに来るようになりました。セミナーという教材があって、そこについて質問をできるようになるので、質問が来るようになりました。
また、新人さんや中途で来た人に対していいトレーニングになるなと感じました。例えば新人研修でダイジェスト版でしゃべる依頼が人事さんから来たりしました。
では「Confluenceをやっていて一番悩ましい問い合わせって何だろう？」と。何だと思いますか？ 「なにかイイ感じで使い方教えて」みたいのが一番難しいですよね。「とりあえずイイ感じで使えるようになりたいんだけど、教えてくれない？」みたいな。
これをアドリブで答えるのってすごく難しいですよね。「いったい何ができないんですか？」から始まるんですが、先ほどのような教材を用意していると、自分の中でも体系立ててどんなふうにConfluenceについて教えてほしいのか考えてやっていますし、教材があればこれをもとに社員さんとお話ができるので、「ここがわからない」であるとか「これがわからない」であるとか、自分たちのアドリブではなくて体系立てて説明できるようになりました。
システム運用に加えてこういう教育も担当するようになると、チームメンバーも大変なんですが、やっていくことで使える人が増えるという事実はあるので、とくにユーザーを拡大させたい計画がある方は、こういうようなのを考えていただくのもいいかなと思います。
突然の「never fail tip」、これは「鉄板ネタ」を英語で言ったらこう言うらしんですが、セミナーでどのレイヤーの人に話しても絶対に喜ばれる鉄板ネタがあるので、これをぜひ現場でもやってもらえればなと思いますショートカットキーの「GR」。知っている人？ ご存じの方？
（会場挙手）
あんまりいないですね。では、知らなかったら今日覚えて帰ってください。これまでの話は全部忘れて、これだけでも覚えていただければいいかなと思います。GRです。
（会場笑）
GRとやると、直近の自分が見ていたページが出てきます。リストで出てくるので、「さっき見てたやつ何だっけな？」「重要なページは全部ブラウザのお気に入りに入ってます。でも、PCを変えたら見れません」みたいなこともありますし、「さっきまで編集してたのってどれだっけな？」みたいなことは全部ここからたどることができるので、おすすめです。
これは誰に紹介しても喜ばれますので、「ありがとう」と言っていただけると思います。ぜひやってみてください。
ということで、Manage User Requestsの話でした。
大規模なConfluenceをマネージするために必要なこと
ということで、4つのTipsを紹介しました。最後にAtlassianに向けてメッセージを発信させていただきます。Atlassianさんの人、聞いてください（笑）。
なぜ、私が11年間Confluenceを運用してこれたのか。それは、私がスーパーマンだからかというと、そんなことはないです。私は普通のしがないエンジニアです。
では、なぜConfluenceを運用してこれたのか。それは、Atlassianがオープンだからです。Atlassianさんのところへ行くと、いたるところで「Open, Open」と言ってるんですが、具体的に何がオープンなのかを紹介したいと思います。
彼らのリソースは2つオープンなんです。先ほどもjira.atlassian.comの話をしましたが、個人的に重要なのはこの2つです。
左がプロダクトソースコードですね。クラウド版についてはこれは言えないんですが、オンプレ版については、ライセンスを買った方にはソースコードが配布されています。
なので、技術力があれば、直接ソースコードを見たり触ったりできます。仮にAtlassianのサポートと見解が違っても、「こうなってますよ」と言ったり、改変も認められているので、自分でいじったりすることもできます。やっぱりこれがあるおかげで自分たちは運用できているところがあります。
もう1つは、jira.atlassian.comです。ここでいろいろな情報を引っ張ってこれるのがすごく重要です。チームでも再三噛み締めているんですが、運用している途中にもユーザーさんからお問い合わせが来て、とりあえずエラーメッセージを検索したら、jira.atlassian.comさんにつながるんですよ。
要するに誰かが報告してくれているからなんですよね。いろんなユーザーさんとそこで共有できているので、一般的なJavaのエラーメッセージでもjira.atlassian.comで引っかかることが多いです。
なので、そこからパートナーさんやAtlassianさんに問い合わせるまでもなく、自分たちでworkaroundにたどり着く事ができます。非常に地味なのでなかなか実感しづらいところなんですが、運用に非常に寄与しているところだと思います。
答えを言ってしまいましたが、私たちは常にソリューション、解決方法やworkaroundをそれらから見つけることができているところがすごく重要です。なので、Atlassianにはこのオープンさを忘れないでいただきたいな思っています。ソースコードを公開しているのはわりとリスキーというか難しい部分もあるとは思いますが、ぜひオープンなままでいてほしいなと思います。
そういうことで、すべてのセッションが終わったのでちょっとwrap upですね。「wrap upするといいよ」とコーチングで言われたので、wrap upを足しています。
大規模なConfluenceをマネージするためには、Atlassianがオープンでい続けることが重要です。管理者は常に強い心を持ってパフォーマンスと可用性にフォーカスしていくと、大規模なConfluenceでも運用していけるかな、というところで結ばさせていただきます。
私の発表は以上になります。ありがとうございました。
（会場拍手）
こんな感じで、今の内容をがんばって英語で話してきました。冒頭で登壇までの道のりについてお話しましたが、ぜひしゃべってみたいという方がいれば、11月4日までに応募できますので、ぜひチャレンジしてみてください（注：現在は終了）。
もし次回でもチャレンジしようと考えていらっしゃるのであれば、個人的にもうちょっと深い話をお答えできるかと思いますので、ぜひチャレンジしてみてはいかがでしょうか。
ということで、ありがとうございました。
