[レポート] 【パネルディスカッション】Slack, Qiita, GitHub 利用者 ＆ 提供者の視点で見る、クラウドとツールの使いどころ #AWSSummit

皆様、開発時はどのツールを使っていますか？

どうも。大村です。初AWS Summitです。

開発を行っている中で、昔も今も欠かせないのが作業を効率化するツールの数々です。 私も前職の組み込み系の頃から、VisualStudioのような統合開発ツールといった開発に必要なツールから、VisualSourceSafeといったバージョン管理プログラムなど、様々なツールを使って仕事をしています。 そういったツールと、クラウドの関わり方を、今回のセッションでは話し合うことになります。

今回のセッションで扱われるツールは、Slack、Qiita、Githubとなります。 弊社でもこれらのツールは全て導入してまずが、実際にすべてを使いこなせているわけではありません。 このセッションでなにか掴めると嬉しいと思い参加しています。

以下、セッション紹介文です。

今や国内でも開発者の多くが必須のツールや環境として利用している Slack、Qiita、GitHub。こうしたツールの活用が開発スピードの向上をもたらし、それを加速するクラウドを使った開発プロジェクトも多くなってきています。本パネルディスカッションでは、これらのツール利用者や提供者をお招きし、AWS の内外で多くの開発プロジェクトを見てきたモデレーターとともに、これからの開発者が知るべきツールとクラウドの関係と使いどころについて切り込んだ議論を行います。

モデレータ、スピーカーとツール紹介

今回のレポートするのは、パネルセッション形式となります。 登壇されたモデレータと、ゲストパネリストの方の紹介から始まりました。

【Slack 利用者】岩瀬 義昌 氏（エヌ・ティ・ティ・コミュニケーションズ株式会社　技術開発部 エンジニア）

Slackは、チームや特定のメンバーだけで使えるチャットサービスです。弊社でも、プロジェクトごとにSlackのチームを作成しています。また、社内では似たようなChatworkを利用しています。Slackのチーム間の連携はほぼないので、お客様を含めた形でのやり取りをするのにSlackは重宝しております。 岩瀬氏は、Slackの提供者ではないけれど、Slackを始めとしたツールを使うユーザーの立場だそうです。

【Qiita 提供者】髙橋 侑久 氏（Increments 株式会社　CTO）

Qiitaは、技術情報（ナレッジ）を共有するサービスです。オープンな場で個人として技術を共有するQiitaと、チームメンバー間での技術共有を行うQiita:Teamがあります。弊社でもここ数か月前に試験導入し、日報や議事録を共有し始めたばかりで、まだ手探りで使っています。同様のサービスとしては、WikipediaやConfluenceといったものがあります。

【GitHub 提供者】藤田 純 氏 （ギットハブ・ジャパン合同会社　カントリーマネージャー）

GitHubはバージョン管理ソフトGitのホスティングサービスです。弊社でもGitHubを利用しております。また他にもStashを併用しており、プロジェクトによって使い分けている形です。以下Wikiからの説明文です。

GitHub（ギットハブ）はソフトウェア開発プロジェクトのための共有ウェブサービスであり、Gitバージョン管理システムを使用する。 Ruby on RailsおよびErlangで記述されており、GitHub社によって保守されている。 主な開発者はChris Wanstrath、PJ Hyett、Tom Preston-Wernerである。 GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供している。 2009年のユーザー調査によると、GitHubは最もポピュラーなGitホスティングサイトとなった。

【モデレーター】吉羽 龍太郎 氏（Ryuzee.com）

元AWSJシニアコンサルタントで、現在はアジャイルコーチやDevOps導入支援を行っておられます。 「クラウド」からみたツールという立ち位置でモデレーターを行われていました。

会場内利用調査

約1000人程が入場したと思われるパネルセッション会場でのそれぞれのツールの利用者を挙手方式にて調査しました。 結果として以下の感じになりました(あくまで個人的な目算になります)。

Slack利用者：半数以上

Qiita利用者：半数程度

Github利用者：7割程度

AWS利用者：ほぼ全員

開発者：8割程度

運用者：2割程度

このことからも分かる通り、今回のセッションの参加者はツールを利用している人が割と多い事がわかります。 「この後に話すトークの中身を変えなきゃいけないですかね？（笑）」と吉羽氏はいいますが、トークテーマパネルをめくると、この結果が予め想定していたようです。

なぜこれらのツールやクラウドが受け入れられたのか

岩瀬氏

チャット自体は昔からあります。IRC(Internet Relay Chat)とか。 実は、チャットは技術者と相性がとてもいい。 そして、今はAPIを使って、他のシステムと提供しやすい。

高橋氏

すべてがすべて、Qiitaだけで収まるとは思っていません。 SlackやGithubがそうであるように、これ単体で完結していません。

藤田氏

なぜAPIなのかというところに触れなければなりません。 ツールは単体で、特定のドメインの問題を解決します。餅は餅屋ではないけれど、APIは閉じた世界で完結しないためのものだと思います。 それで受け入れられらたのではないでしょうか。

岩瀬氏

ちなみにうちでは、Slackで議論が白熱した際のまとめをQiitaに投稿するとかを自動化していますが、Qiitaではどうやっているのでしょうか。

高橋氏

最近はリモートワークの導入が完了しており、オフラインで話したことをオンラインに持って行くというところに関心があります。 さっきオフラインでこんなことを話しました、といったことを書きます。 そういう（まめな）人が一人でも居るかどうかが、ツールが定着するかを決めると思います。

藤田氏

弊社Githubも社員の半分がリモートワークです。 オフラインで発生したトピックをいかにしてオンラインにして残せるかが課題となります。 （メモ：Githubさんはそういう内容をGithubに投稿しているっぽいです）

ビジネスのスピードが変わりました。PDCAってよく言われるけれど、Planningが重くなって遅くなる企業が多いのが現状です。 企業はそれをずらさないように頑張るけれど、外に目を向けるとどんどんスピードが上がっています。 でも実は、失敗するなら早く失敗して早く転んだほうがいい。早く次へ行くことを見極めることが重要です。 そういうのを許容する懐の深さがいまの企業には必要ではないか、とおもいます。

岩瀬氏

実は、自分たちのツールを導入する側からすると、ミッションは早く失敗することだったりします。 AWSだと、試して、失敗してが、すごく早くできる。 そして、本来やるべきことに注力するために、ツールを導入します。

高橋氏

（提供する側としては）自分たち自身で、自分たちのプロダクトを使って、早く問題に気がついて、どんどん改善していくことを気をつけています。

これらのツールとクラウドの親和性は？

藤田氏

インフラの担当であれば、環境をクラウドに持っていくことで、やらなくても良いことが増えました。 同じような作業、繰り返しになるような作業は自動化したほうが良いです。 継続的インテグレーションと同じだと思います。

高橋氏

QiitaもQiita:teamもAWSに構築していますが、オンプレミス環境だとスパイクアクセスに耐えられません。

岩瀬氏

Slackはクラウドとの親和性がむちゃくちゃいいです。 Slackは複数のチームに入れる、のが便利すぎる。 どんどんChatOpsになっていきます。

高橋氏

Qiitaをオンプレミスにして欲しいという意見も結構多いのですけれど、よくよくそういう会社さんに聞いたら、社内から持ち出せないとかそういった意見が本当に多いです。 ただ、自分たちで新しく立ち上げる、オンプレミス対応のようなことはしていません。

藤田氏

オンプレにも対応すると、使う側からすると、Saasに比べると手間はかからないと思うけれど、作りこみが必要になります。 でも、Githubはソースコードを預かるサービスなので、それを何処に(物理的に)置かれるかというのを気にするお客さんはむちゃくちゃ多いです。

岩瀬氏

導入に当たり、一部のミドルマネージメント層に、そういったツールの知識ある人が必ずいます。 そう行ったところから攻めて、導入へと導きます。 既成事実的なやり方です。

ただ、セキュリティというのはキーワードです。 ちなみに弊社では、お客様の情報はオンプレ環境にしか置かないようにしています。 Qiitaには「バレてもいいよねー」ということしか書かないようにしています。 どこまでがOKでどこからがNGかは、情報共有ミーティングで使い方の共有を行っています。

高橋氏

組織ごとにいろいろあるので、ボトムアップが良いかトップダウンが良いかは一概にいえません。 ぽんと導入してみんなが使ってくれるなんていうのは、奇跡に近いとおもいます。 旗振り役が居るというのはツールを成長させる一番の成功例なんじゃないでしょうか。

藤田氏

組織の中には、ロックスターのような人やチームが居ると思います。そういう人たちをうまく巻き込んで良さを実感してもらいます。 あと、組織の上の人（決定権を持つ層）は、皆が楽しく仕事してることは嬉しいことだと思ってるはずです。 一つの例えなのですが、ロックスターチームの人たちがありがとうございますというメールを上の人に送信しました。 それで組織の上の人が気がつきました。こういう導入方法もあります。

岩瀬氏

あと、著名なコンサルタントに上の人を殴ってもらうというのも一つの手ですよ（笑

吉羽氏

割と皆さん、人間系っぽいやり方をしているのですね。

藤田氏

人間系かつ緻密に計画を立てて〜〜ってのはある時点で必要かもしれないけれど、まずは試してみないとわからない。

吉羽氏

お客さんによっては◯×票をつけたりするんですね。

高橋氏

いきなりQiitaチームを使うというよりも、APIの話になりますけれど、今現在はSlackを使ってて、そこと連携すると便利だから導入しようというのは多いですね。

藤田氏

よくあるのがROIというマジックワードです。このワードに対しては言いたいことはいっぱいありますが（笑 「竹を割ったように世間がスパっと見えたら苦労しないんだよ」、と（笑

企業トップの方はすごく優秀な方が多くて、数字だけでは見えないということを知ってる人が多い。 現場の生々しい声をしっかり見せることが重要だと思います。

さいごに

岩瀬氏

エンプラとかに近い割りには、かなり内製頑張ってる側だと思っています。 こういう場に来てる人で内製頑張ってる人、いると思うんですけれども、一緒に頑張っていきましょう。 いろんなセッションに出て喋ったり、勉強会開いたりして、社内で内製してるってことをアピールしてます（笑

高橋氏

Qiita:Teamって社内情報共有ツールですけれど、同じようなツールはライバルだと思っていません。 社内共有していない会社のほうが、まだまだ圧倒的に多いので、一緒に広めていきましょう。

藤田氏

Githubに入社してから、日本の大企業の方と話する機会があって、よく聞く声としては、ヒト・モノ・カネ・情報は海外企業と差がないはずなのに海外と差が出てしまうのはなぜだろうと聞かれます。 私は、コケる勇気、失敗を許す勇気、度量が足りないのかなと、思います。不確実性の中で生きてるわけですから。 そういうのが許されるムーブメントを起こしたいなと思っています。

まとめ

• ツールを使うことで業務効率がアップできるなら、失敗でもいいから試してみよう
• そういうのに理解のある上司や社内でも声が大きい人を巻き込もう
• ツールを一つ使うのではなく、他と連携してどんどん便利に使いこなしていこう

宣伝になりますが、弊社では他社様でどのようなツールを使っているのかを紹介する「突撃！隣の開発環境シリーズ」を連載しております。 こちらで、他社ではどのようなツールを使って実際の開発業務を行っているのかを参考にしてみるのも一興だと思います。

それでは。