クラウドとツールの賢い使い方を解説
吉羽龍太郎氏（以下、吉羽）：みなさま、本日はお忙しいなかお集まりいただきまして、ありがとうございます。
これから40分間、「Slack、Qiita、GitHub利用者＆提供者の視点で見る、クラウドとツールの使いどころ」ということで、本日3人の方にお越しいただいております。
Slackの利用者ということで岩瀬様。それからQiita:Teamをご提供されているIncrementsの髙橋様。それからGitHubの提供者ということで、ギットハブ・ジャパン合同会社の藤田様にお越しいただいております。
ちょっと時間が短いので駆け足になると思いますけれども、お付き合いいただければと思います。
今日これだけたくさんの方に集まりいただいていますが、我々としても、どういう方がお越しになられているのかというところをぜひ知りたいと思っていますので、会場の調査をしたいと思います。
その前に、我々この1,000人規模の方の前でパネルディスカッションする機会はなかなかないので。せっかくなので、みなさんをバックにして記念撮影の1枚でもしちゃおうかなと。いいですかね、みなさん？ 大丈夫ですか（笑）。
（会場拍手）
ありがとうございます。
私欲のためにみなさまにお付き合いいただきまして、ありがとうございます。ちょっと場は温まりましたでしょうかね。
実際の利用者はどれくらい？
では、会場の方にお聞きしたいと思うんですけれども、実際にSlackを使われているという方、挙手いただけますか。
（会場挙手）
けっこう多いですね。半分超えてる感じですかね。ありがとうございます。次、Qiita、それからQiita:Teamをお使いになられてる方、どれぐらいいらっしゃいますか？
（会場挙手）
すごいですね。けっこうたくさんいらっしゃいます。なるほど。では、次GitHub。GitHub Enterpriseを使われている方？
（会場挙手）
おお。すごいですね。今日、私はAWSの方に依頼されてモデレーターをやっているわけですけれど、これでAWSを使っている方が一番少ないと、ちょっと悲しい気もしなくはないですね。AWSを使っている方？
（会場挙手）
すごいですね。今日の会場の方は、みなさんツールをかなり使われているということですね。我々の事前の想定と違うような気も若干いたしますけれど、次、別の観点で聞かせてください。開発者の方はどれぐらいいらっしゃいますか？
（会場挙手）
7割から8割ぐらいが開発者のイメージですかね。じゃあ次、Ops、運用をされている方は？
（会場挙手）
なるほど。これで我々が話す内容がだいぶ変わりそうな感じもいたします。
岩瀬義昌氏（以下、岩瀬）：ちょっと聞いてもいいですか？ SIerとかベンダーの方はいらっしゃいますか？
（会場挙手）
それなりにいらっしゃいますね。
吉羽：割合的には3割ぐらいですかね。なるほど。
「思いついたらすぐ作れる」というサービスを提供
では、これから本題に入っていくにあたりまして、まず3人の方に来ていただいていますので、ご存知の方も多いとは思うんですけれど、製品についてご紹介いただきます。
製品はいろいろなビジョンやミッションがあって作られて、提供されていると思いますので、主にそのあたりとパネリストの方の役割について、簡単に岩瀬さんから自己紹介をいただきたいと思います。
岩瀬：岩瀬と申します。
NTTコミュニケーションズという、どちらかというとエンタープライズ寄りな会社に属しています。なかでは約10名の内製チームのTech Leadというものをやっています。
私は少しみなさんと視点が違っていて、Slackをヘビーユースはしているんですが、作っているものはちょっとだけ違います。紹介すると、SkyWayというWebRTCのプラットフォームを作っています。
これはなにをするものか、すごく簡単にいうと、LINEやSkypeを簡単に作れるような基盤です。思いついたらすぐ作れるという、そういうレベルのサービスを今、私たちは提供しています。
AWSは技術評価の一環で使っているイメージですね。以上です。
Qiitaを提供する立場から
吉羽：ありがとうございます。じゃあ次ですね、髙橋さん、お願いいたします。
髙橋侑久氏（以下、髙橋）：IncrementsでCTOをやっております、髙橋侑久と申します。
Incrementsは主に先ほど紹介にあったQiitaとQiita:Teamという2つのプロダクトを提供しているんですけれども、今日は主にQiita:Teamから来た人という立場でお話をさせていただければと思っています。好きなAWSサービスはS3です。
先ほどけっこう手が挙がったので、必要ないかとも思うんですけれど、Qiita:Teamは「“書きやすさ”にこだわった社内向け情報共有サービス」ということで、社内で情報共有するためのツールを提供しています。
なぜ「書きやすさ」にわざわざフォーカスしているかということについては、今日の話のなかで触れられればと考えています。よろしくお願いします。
吉羽：ありがとうございます。じゃあ、次はGitHubの藤田さん、よろしくお願いします。
ディベロッパーの仕事が楽しくなるツールを
藤田純氏（以下、藤田）：みなさま、こんにちは。私、ギットハブ・ジャパンの藤田と申します。
我々のミッションは、プロダクトと密接に関係してくるところかなと思っています。我々のプロダクトは、ディベロッパーの、ディベロッパーによる、ディバロッパーのためのツールという位置づけだと思っているんですね。
プロダクトとしてはネット上でサービス提供しているGitHub.comというものと、お客さんの環境に実際にインストールして使っていただくGitHub Enterpriseという2つのプロダクトを持っています。
どちらが大事だとかそういうのはありません。あくまでも、「ディベロッパーの方々が日々、生産性高く」という観点もあるんですけれども、もっと強く押し出したいのは、「仕事が楽しくなるように」。
そんなコミュニケーションやコラボレーションといったツール、サービスを提供しております。
日本法人としては、今日こんなにたくさんの方々がいらしゃっているんですけれども、日本の開発者の方々にきちんと情報提供したりということをやっていきたいと考えています。
吉羽：ありがとうございます。
そして、私、モデレータを務めさせていただく吉羽と申します。実は昨年の10月までAWSの中の人でした。元・中の人ということで、今回、外から登壇させていただいて、不思議な気分を味わっております。
ツール登場から10年経たずに受け入れられたのはなぜか
さて、さっそく本題に入っていきたいと思います。先ほど会場の調査をしたところ、すごくたくさんの方から手が挙がって、我々が、事前に想定していた数よりもかなり多かったと思います。
改めて、なぜこういったツールやAWSのクラウドが受け入れられたのか。いろいろ理由があると思うんです。
AWSが2006年にサービスが開始されて、それからGitHubが2008年ですね。それからQiitaが2011年。それからQiita:Teamが2013年。それからSlackが2014年と。
まだ登場して10年も経ってないなかで、なぜこんな速度で世の中に受け入れられたのかというあたりを、振り返っておきたいと思います。
いかがですか、岩瀬さん？
岩瀬：Slackの例でいえば、エンジニアって昔からけっこうチャットを使ってるんですよね。例えば、IRCってかなり昔からありましたし、そのあともたくさん出てきています。例えば、HipChatとか。最後に出たのがSlackだと思います。
いろんなサービスを使ってみて、だいたいわかるのは、このSlackとかって開発者との相性が抜群にいいんですよね。ほかのツール、GitHubさんもそうですし、Qiitaさんもそうです。
なにかしようと思ったら、だいたいインテグレーションが用意されていますし、細かいユーザーエクスペリエンスも最高に高められていて、もし物足りなかったら、APIも全部公開されてるので、もう開発者はなんでもできちゃうんですよね。キーの1つはAPIですね。
吉羽：API。なるほど。今、APIという話が出ましたけれども、たぶんQiitaもそうですし、GitHubもそういう連携機能ってたくさんあると思うんですけど、やはりそういう、APIエコシステムっていうんですかね、それによる影響が大きいですか？ 髙橋さん。
3つのプロダクトの共通点
髙橋：そうですね。Qiita:Teamは、社内での情報共有のためのツールとなっているんですけど、すべてがQiita:Teamに集まるということは考えていません。
GitHubで開発ソースコードは管理していて、細かいチャットみたいなものはSlackでやっているということが多いので。Qiita:Teamそのものも、GitHubなりSlackなどとそういう連携をしています。
なので、Qiita:Team単体で受けられたというか、そういうほかのツールとの親和性のなかで受け入れられていったというのがやはり大きいと思っています。
吉羽：なるほど。藤田さん、いかがですか？ とくにAPIや連携という観点で。
藤田：そうですね。API連携というところは大きいと思っています。
じゃあ、なぜAPI連携なのかという話になると、やはりSlackも、Qiita:Teamも、GitHubもそうだと思うんですけれども、ユーザーさんが誰で、どんな問題を解決しようとしているのかというのがすごく明確で。そこにすごく特化しているんだと思うんですよね。
手を広げ過ぎないようにしてるというか。特定のドメインの問題をきちんと解決するというところに、プロダクトとして、会社として、集中してやっている。
それ以外のところは、餅は餅屋ではないですけれども、ほかの優れたサービスと閉じた世界を作らずに連携していくという。そういうアプローチが、早いスピードで受け入れられた理由の1つなんじゃないかとは思ってます。
吉羽：そういう意味では、1つのことをしっかりちゃんとやるというのが、3つのプロダクトに共通している考え方という感じなんですかね。
藤田：そうですね。似てると思います。いかがですか？
吉羽：いかがですかね。もし違う意見があれば、ここで暴れていただいてもぜんぜん大丈夫なんですけれども。
Slackの情報をQiitaに移したいという悩み
岩瀬：これUNIX的な思想に近いと思うんですけど、1つのことを綺麗にそれだけやってほしいんですよね。そうすると、組み合わせるのは、パイプをつなげるのがすごい簡単になるので。ぜひその思想で進んでいってもらいたいなと思っています（笑）。
ちょっとQiitaの髙橋さんに聞きたいことがあるんですけれど、Slackを使っている人は絶対にぶつかる問題があって。議論がSlackで盛り上がっちゃうんですよね。
そのSlackで盛り上がった情報はフロー情報なのでストックしたいです。ストックといえばQiitaです。でもめんどくさいです、と。「どうしてますか？」という。
我々はけっこうbotなんかで自動的にやっているんですけれども、QiitaさんもSlack使ってますよね。どうしてますか？（笑）。
髙橋：少し話はズレてしまうんですけど、弊社はつい最近、会社としてリモートワークを完全に導入したんです。今までは全員オフィスに集まってたんですけど、最近オフィスに来ない人も出てくるようになってきたんですよね。
それまでは近くにいたので、Slackでオフラインで共有されていなかったとしても、なんとかなっていたところはあったんですけど、最近はもう人がいないということになってきている。
なので、「Slackに書いてあるものをどうやって保存するの？」というより、「たまに発生するオフラインの会話をどうやって保存するんだ」ということがすごく重要だなと思っています。
そういう、オフラインで話したことをオンラインに持っていくということに、すごく最近は興味というか関心を持っています。
オフラインの会話をオンラインに持っていく重要性
吉羽：具体的になにか、「こういう活動をしてる」みたいなものってありますか？
髙橋：それはなかなか難しいんですけど、活動というか、「さっきオフラインでこんなことを話しました」ということはよく書くようにしています。
ユーザーさんを見ていても、そういうオフラインで会話したことをオンラインに持っていく活動を、率先してやっている人が1人いるかいないかで、そういうツールがちゃんと定着するかどうかにかなり影響していると感じています。
吉羽：なるほど。ありがとうございます。岩瀬さん、だいたい聞きたいことは聞けましたか？ たぶん会場のみなさんも同じような悩みをたぶん抱えていたと思うんですけれど。
岩瀬：ちなみにGitHubさんはフルリモートですよね。これまた違いますよね。
藤田：そうですね。弊社の場合は、会社の方針としてリモートワークを推奨しています。今ワールドワイドで570数名の従業員がいるんですけれども、その約半分がリモートワークなんですね。
なので、物事の考え方や社内のプロセスはリモートワーク前提で。先ほどおっしゃっていたように、オフラインで発生した、消えていってしまう情報をどう残していくかというのは大事なポイントです。
そこはシルバーブレットはないのかなと思っていて、やっぱり、ちょっとかっこ悪いですけれども、きちんと自分たちの仕事のやり方として習慣づけていく。
とか偉そうなこと、言っていますけれど、私もよく会社のメンバーに「藤田、お前が言ってることちゃんとGitHubにあげておけ」と怒られているので（笑）。
今後、自分を戒める意味でもちゃんとやっていきたいなと思って。そこはすごく大事なポイントだと思っています。
ツールが受け入れられた背景
吉羽：今、みなさんにお話いただいた側面って、とくにAPIエコシステムや定着にあたって、みんながちゃんとやらないといけないというところだと思います。
一方で、ツールが受け入れられた時代背景とか、ビジネス的な側面でなにか特筆すべきことってありますか？ このへん、ビジネスはたぶん藤田さんが一番経験おありだと思うんですけど。例えば、ビジネスだとスピードなんですか？
藤田：そうですね。確かに。そこはすごくポイントだと思っています。
よくPDCAって、デミングサイクルってあると思うんですけれども。やっぱりプランニングのところがあまりにもヘビーになっていて、動きが遅くなっている組織って多いと思うんですよね。
1回そのプランニングを精緻にまとめると、今度はそれがハンムラビ法典みたいになって、組織の人たちはそれを絶対ずらさないように、がんばってしまう。
でも、外に目を向けると、これはたぶん2,000回くらい世の中で言われてますけど、Uberが出てきたり、Airbnbが出てきたり、スピード感がすごく大事で。失敗するんだったら、早くトライして、早く転ぶ。それで、綺麗に言えば、学ぶという。
成功するものと失敗するものが、精緻なプランニングというスタンスからは、見分けがつきにくくなってきていると思うんですよね。
研究開発で求められるのは「早く失敗する」こと
吉羽：やってみなきゃわからないという感じですかね。
藤田：そうだと思うんです。だから、さっさとやって、さっさとコケて。それで、うまくいくことを早く見極めるというような進め方。
それを許容するおおらかさというか、その遊び心というか、懐の深さというか。そういうのが組織に必要なんじゃないかなとは思っています。
吉羽：なるほど。それがツールとどういうふうに絡んできますか？ 岩瀬さんでも、髙橋さんでも、例えばこういうツールを使うと、どうしてそういう対応ができるんですかね？
岩瀬：私の立場からいうと、研究開発的な部門に属していまして。求められてるミッションって「早く失敗する」ということなんですね。それで、ツールとか、AWSも同じで、APIが公開されてるものを使いまくると、ものすごく失敗が早くできるんですよね。
AWSを使えばすぐ、CloudFormationを使ってもいいですし、一瞬で環境が作れます。とくにSlackとかQiitaを使っていますと、情報共有とか開発のプロセス自体もだいたいもう標準化させたものがすぐ作れてしまうと。
そうなると、アイデアを試すのは簡単な時代になってきている。そのへんと親和性がめちゃめちゃいいかなと思っています。
吉羽：なるほど。そうするとあれですかね。本来やるべきことに集中するためにツールを活用したほうがいいという感じなんですかね。
岩瀬：まさにそうです。SIの人はわかると思うんですけど、100ページを超えたパワポ資料って書いたことありますか？
吉羽：あります（笑）。
岩瀬：たぶんありますよね（笑）。SIとかそういう人はあると思うんですけど。
なかなかないことをやってしまうのがよくないアンチパターンなので、そうしないように、我々は早くするということを今、気をつけてますね。
個々人の強みに集中するためにクラウドとツールを利用
吉羽：髙橋さん、実際にプロダクトを作っている現場で、気をつけていることってあります？ 本業に集中という観点で。
髙橋：やっぱり自分たち自身で、自分たちが作っているプロダクトを使って、とにかく早く自分たちで問題に気づいて、どんどん改良していくということは気をつけています。
吉羽：いわゆるドッグフーディングという感じですかね？
髙橋：そうですね。
吉羽：なるほど。ありがとうございます。
今、岩瀬さんのほうからクラウドの話も出てきましたので、テーマを先に進めて。こういったツールとクラウド、AWSとの親和性について。
みなさん、なかにはAWSをお使いいただいてるパネリストの方もいらっしゃると思うんですけど、クラウドとの親和性というあたりはいかがですか？
藤田：ちょっと先ほどの話の繰り返しになっちゃうんですけれど、本業に集中するというか。例えば、インフラご担当の方であれば、環境をクラウドに持っていくことでやらなくて済む仕事ってけっこう増えてくると思っています。別にサボれってわけじゃないですけれども。
とにかく機械に任せられるところとか、繰り返し行われる、同じような作業。紙と鉛筆で書けることで、繰り返し再現性があることということは、たぶんツールに任せたほうがいいと思うので。
それって、プラットフォームしかり、今、言われている継続的インテグレーションというのも、考え方としては同じだと思っているんですね。
なので、全体のスピードを上げるために自分たちのやるべき本業というか、個々人の強みに集中して、ひいては組織としての強みをさらに磨き上げていく。
ごめんなさい、話がモワ～ンとしてきちゃいましたけれども（笑）、そんなスタンスなのかなと思っています。
生活をすべてSlack上で完結させる作りに
吉羽：なるほど。そういう意味ではクラウドって、ボタンをポチポチクリックすれば数分で調達できて。今まではデータセンターに行ってなんとかしていたところが大幅になくなる。
あと髙橋さんは、自分のところでビジネスをされていると、当然のことながらオンプレミスで事業計画に合わせて調達するというつらさというところですかね。たぶん実感されてるんじゃないのかなと思うんですけれども、そのあたりはいかがですか？
髙橋：Qiita、Qiita:Team両方とも全部AWSの上で動いているんですけれども、やっぱり、ある日突然バズってトラフィックが増えましたとか、どこかですごい有名な人が「Qiita:Team、すごいいいんですよ」って紹介してくれた瞬間に、ワーってトライアルが始まるということもあったりします。
そういうときに、オンプレ環境だとそういうのにはなかなか対応するのは難しいというか、そういうのを事前に見積もって多めにやっていくとコストかかりすぎるというところで、やっぱりAWSの柔軟さというのは助かっています。
吉羽：岩瀬さん、そういう観点でいうといかがですか？
岩瀬：Slackという観点から話をすると、クラウドと親和性めちゃめちゃよくて。なぜかというと、たぶんSlackを使い始めるとわかるんですけど、複数のチームにも簡単に入れるので、いつの間にかSlackが生活の基盤になるんですよね。会社に来たら、まずSlackを開くという感じで。
そうすると、すべてSlackでやりたくなってくるんです。ChatOpsって有名な言葉がありますけど、当たり前のように障害情報などをまずSlackに通知するというふうにしていく。
SlackのAPIを叩くように、我々のEC2インスタンスとかも実験用に立てたりするんですけど、そういうものからも普通にAPIを叩いて、生活をすべてその上で完結させるような作りにはしています。
吉羽：じゃあ、もういろんなAPIを呼んで、どんどん統合してChatOpsにしていくみたいな、そういう感じですか？
岩瀬：そうですね。
今の時代、自分たちでいちいち立ち上げるのは遅い
吉羽：髙橋さんもそういう運用なんですか？
髙橋：そうですね。あと先ほどのオンプレミスの話をすると、「Qiita:Teamそのものをオンプレで提供してほしい」みたいな要求がやっぱりすごく多いんですけど、今のところ提供してないんですよね。
それは結局、「なんでオンプレミスで必要なんですか？」と聞いていくと、運用する人は「本当はオンプレじゃなくてSaaSのほうがいいんだけど、会社の規則的に外に出せないんですよ」ということがある。話していくと、「それがないんだったら、本当はSaaSのほうがうれしいんですけどね」というところに行き着くんです。
やっぱり自分たちでいちいち立ち上げて、というやり方は今の時代だと遅すぎるのかなという気はしています。
吉羽：あと困るのはバージョンアップですかね。このあたりは藤田さん、実際にGitHub Enterpriseというところで、どうやってバージョンアップされるのか、ちょっと気になっているんですけれども。
藤田：弊社の場合、緊急のセキュリティパッチなんかが出た場合以外は、だいたい3ヵ月に1回新しいバージョンをリリースさせていただいています。
そのときにどういうかたちでやっているかというと、実際にお客様がインストール・デプロイしていただくハイパーバイザーにすぐ乗せられるような、プリパッケージされたものをご提供差し上げています。
なので、実際に使う側のお客様からすると、ご自分でフルスタックを、OS設定してデータベースうんぬんというのはやらなくて済みます。
SaaSに比べるとやっぱり手間はかかるんですけれど、さほどそこの手間は大きくないのかなとは思っています。
吉羽：逆にいうと、そういうモデルにしようと思うと、作り込みをしなきゃいけないということなんですかね。
藤田：そうですね。ある意味ブラックボックス化してしまって、お客様が使いやすいようなかたちで、幕の内弁当みたいな感じでお届けする、そんなイメージですかね。
吉羽：なるほど。ありがとうございます。みなさんクラウドとの親和性はやっぱりすごくいいという感じですね。
