何でも屋エンジニアのブログ

ソフトウェア関連技術、コミュニティ、日々の雑貨

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

はじめに

AWSSummit 2016の「【パネルディスカッション】Slack, Qiita, GitHub 利用者 & 提供者の視点で見る、クラウドとツールの使いどころ」の内容をまとめたレポートです。セッション動画が公開されると思いますが、さしあたり参考になれば嬉しいです。

注:ですます/である調が混在しているのでご了承下さい。大きく聞き逃したところもあり、その点は記載してあります。 内容に誤りがある場合は指摘して頂けると嬉しいです。

本編

登壇者紹介

パネリスト
【Slack 利用者】岩瀬 義昌様(エヌ・ティ・ティ・コミュニケーションズ株式会社 技術開発部 エンジニア
【Qiita 提供者】髙橋 侑久様(Increments 株式会社 CTO)
GitHub 提供者】藤田 純様 (ギットハブ・ジャパン合同会社 カントリーマネージャー)

モデレータ
吉羽 龍太郎様(Ryuzee.com)

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

岩: チャットは昔からよく使われていた。irc hipchatなどあるが、slackは開発者の相性が良い。integrationが豊富でapiが公開されていることが重要。

吉: apiの影響が大きいとうことでしたがその辺どうでしょう。
髙: qiitaチーム、slack、githubは連携ができるというのが大きい。親和性が重要。

藤: api連携をしており、ユーザーがどんな問題を解決したいかが明快で、特定のドメインの問題を解決するに集中できる。 ほかの分野は連携するという感覚で、これがスピード感に繋がり受け入れられたのでは。

岩: 議論がslackで盛り上がった場合、slackはフローの情報でqiitaはstockの情報だが、フローの情報の共有はどうしているか。

髙: slackでというよりは、オフラインの会話をオンラインに持っていくというのが大事だと思っていて、良い方法を模索中。

藤:半分がリモートなのでリモート前提。オフラインの情報は、オンラインに残すように習慣づけるようにすべき。

受け入れられた背景、ビジネス的側面

藤: スピードだと思う。PCDAがあるが、Pの部分がすごく重いので動きが遅くなってしまったり、また、Pが一度決まるとそれを100%守らなければいけなくなってしまう。どうせやってみなければわからないんだから、早くトライして速く失敗して学ぶことが重要で、それを許容する心が組織には必要。

岩: 研究職は早く失敗するというのを求められている。本来やるべきことに集中するためにツールが大事になってくる。

ツールとクラウドの親和性

藤: 本業に集中するという観点から、繰り返しの同じ作業に関してはツールに任せることが大事で、CIなども同じ考え方だが、スピードを上げるために本業に集中し、組織としても強みを発揮する。ツールとクラウドの親和性はスピード、本業への集中。

(筆者:この間の話は聞き逃してしまいました。)

髙: オンプレミスが必要な理由は、結局社内の事情で、スピード感がなくなる。

吉: 逆にクラウドだからこその辛みはあるか。

藤: どこに情報を置くかというのが企業によっては問題になるので辛い。

吉: セキュリティとかポリシーとかですかね。そのような障壁がある場合、どうやってクラウドを導入していけばよいのでしょうか。

岩: エンプラなので導入ハードル高い。社内に通す時、偉い人よりミドルマネジメント層で技術のわかる人を巻き込んで行動した方がいい。slackの時は導入して使えることがわかると偉い人も使い出した。

吉: ラインの偉い人はそれで通るかもしれないが、例えば専任のセキュリティ担当と折衝するケースではどうだったか。

岩: お客様情報など重要な情報に関してはオンプレミス。qiita:teamなどは漏れてもokな情報しか書かない。 お客様の名前など出ていないか最初はチェックしていた。

髙: 導入に関して、ミドルマネジメント層のわかる人を巻き込んでやった方がいいが、いない場合もある。 導入して勝手にそのツールが広まることはないので、率先して使い広める人が必要。

吉: 社内エバンジェリストのような人が必要かな。でも一人だけだと辛い。

岩: 折れてからが勝負!

藤: 導入に関しては、社内のスターを巻き込んで使ってもらう。基本的に組織を管理する人たちにとって、みんなんが幸せに仕事してもらえれば嬉しい。ある例だが、現場からgithubムーブメントが起こり社内に広まった。導入された後に、スターたちが偉い人にお礼のメールをしたら「あ、こういうのが嬉しいんだ」と偉い人が理解したというケースがある。コミュニケーション大事。

岩: 社外コンサルに頼るという手もある

藤: とりあえず試すことが大事。

吉: 評価する前にとりあえず使うことが大事なんですね。

髙: あるツールを使うというよりは、既存の導入しているツールと連携させるイメージで使うような感覚で使うと定着する。

岩: kpiを求められた場合は?

吉: 人件費が一番高いので、今あるリソースを本業にどれだけ避けるようになるかを説得する。

藤: 数字だけでは理解できないものがあるので、その部分をアピールすることが重要。

吉: 合宿みたいに集まって、偉い人も集めて、作っているところを見せて理解を得たことがある。

吉: 言い残したことは?

岩: 内製頑張りましょう!採用にも繋がるので、ブランディングが大事。

髙: 他のツールを敵視(ライバル視)していない。それよも、情報共有の重要性が浸透していない問題に対し一緒に解決を試みる仲間と思っている。 情報共有の重要性に関する世論を形成したい。

藤: 経営資源は遜色ないけど、なぜこんなに外国と差がつくのかという話を聞くことがあるが、失敗を許容するマインドがないというのが大きな違いではないかと考えている。髙橋さんが「ムーブメント」と言っていたが、失敗してもいいムーブメントを起こしたい。不確実性の中、一寸先は闇なので、失敗することは悪ではない。

最後に

登壇者の皆様、非常に興味深いお話ありがとうございました!

参考

プロフィールは以下の詳細ページから取得しました。
http://www.awssummit.tokyo/devcon/index.html