ニフティ株式会社にモダンな開発・運用環境を導入するために奮闘した(している)話

完全に忘れていて投稿が遅れてしまいましたorz

この記事は[NIFTY Advent Calendar 2016](http://qiita.com/advent-calendar/2016/nifty)の23日目の記事です。
昨日は[@tsubasaogawa](http://qiita.com/tsubasaogawa)さんの[「おかえり彼女」で今日も寂しくない](http://qiita.com/tsubasaogawa/items/3830e4889cccbbb0cffa)という記事でした。
タイトルとは裏腹に至極まっとうに音声認識をする話でしたね。

# はじめに

仕事では、ITインフラストラクチャサービスの企画・設計・開発・運用を担当している @ysaotome です。
[NIFTY Advent Calendar 2016](http://qiita.com/advent-calendar/2016/nifty)に参加するにあたり「何を書こうかな？」と思った時に、いつも通り技術ネタを書いたのではおもしろくない。と言うことで、今回はタイトル通り「ニフティ株式会社にモダンな開発・運用環境を導入するために奮闘した(している)話」を書きたいと思います。

幾つかの取り組みを同時に進めているのですが、この記事では「開発・運用環境としてSlackを導入した話」をしようと思います。

# 「モダンな開発・運用環境」 is 何?

![image](https://qiita-image-store.s3.amazonaws.com/0/10852/c4a1eb6b-1ba0-982c-a132-65392d5bf99b.png)

当時、Slackを社内展開するプロジェクト立ち上げた時に書いた資料から抜粋

## 危機感

このプロジェクトは危機感からはじまりました。

* ISP、Web、クラウドサービスといったテクノロジーを売り物にしている企業なのに、社内の技術力が低下しているんじゃないか？

見渡してみるとこんな状況だった。

* 社内を聞いて回れば技術を持っている人はいる
    * もの凄くユーザー管理に詳しい人
    * ハードウエア設計して、ファームウエア書いて、工場発注して独自ハードウエアを作り上げられる人
    * 物資の倉庫から配送まで在庫管理をつつがなく出来る人
    * サポートワークフローの神様みたいな人
    * インターネットバックボーン事情にメチャクチャ詳しい人
    * セキュリティのプロフェッショナルとして政府機関へ出向してる人
    * 「Web上で課金する」という仕組みを考えた人

**「こんなスゲー技術持ってる人がいるのか！」** で、 **「その技術持ってる人って何処にいるの？」** っていう状態

* 後から存在に気づく、本当に必要な時に見つけられない
    * 「このサービス立ち上げ時に、この人に聞いておけばなー」っていう事象
* 技術が会社組織では無く属人的となっている
    * 伝統工芸の一子相伝みたいな技術の維持
* プロジェクト/部/事業部が違うエンジニア同士の技術交流不足
    * 「隣の部のやってるあのプロジェクト、こうすると良いと思うんだけどな」

同じ社内なのに **エンジニア同士の横のつながりが希薄** で、技術のありかに到達出来ない。。。
このままじゃダメだ。っていう危機感から二つの目標を立てました

* **社内の研究開発を活性化する** 
    * エンジニア同士、切磋琢磨して技術を共有しながら獲得していけるハズ
* **サービス開発速度・運用改善速度をスピードアップさせる**
    * エンジニア同士で技術を活用すれば、もっと素早いサービス開発や運用改善が出来る様になるハズ

何はともあれ、「もっともっと社員同士和気あいあいと楽しく仕事出来る環境にしていこう」と思って始めました。

## 状況

状況を整理していく中で感じた課題の一つが **「コミュニケーションコストの高さ」** でした。
特に対人コミュニケーションについては、エンジニア同士なのに取り得る主な連絡手段が、メール、内線、会議となってしまっている事が多く、まずもって連絡を取るのが億劫。
コミュニケーションを売り物にして立ち上がった会社のハズなんだけどなー
Microsoft Office365が導入されているので、Skype for Bisinessやyammerといったツールは使えましたが、

* Skype for Bisiness
    * 相手がオフラインだとメッセージ送信出来ない、なによりログの取り方が酷くて会話履歴とまともに読み返せない、ツール連係しづらい
* yammer
    * サイトが重い、当然ツール連係もしづらい

等の理由でエンジニアには全く受け入れられていませんでした。
また、内容を伝達するために会話内容のドキュメンテーション化や、作業を定常化するための手順書の作成、開発・運用内容の履歴共有といった事のコミュケーションにかかるコストの自動化がしづらい点も敬遠される理由でした。

## はじめた事

同じ事って他社でも起こってるんじゃないのかな？って事で、調べて言った所、西海岸のスタートアップ中心に導入が進んでいた[「Slack」](https://slack.com/)を中心としたChatOpsにたどり付き、 **これだ!!** という事で会社へ導入すべく動き始めました。

検討当時はいくつかのツールを実際に触って見て、特徴や使い勝手の確認をしました。

特にこの分野は盛り上がっていて、Slack以外にも、ChatWork、HipChat等無数に候補がありましたが

* この分野の実質デファクトスタンダードになりつつあった
* 事例豊富で容易なインテグレーション
* 後述する要件面でクリア出来そうなのがこれくらいだった

という事でSlackにきめました。

# 奮闘した事

導入にあたり最も苦労した事は、 **セキュリティ規定を満たす事** と **運用で不幸な人を作らない事** でした。
セキュリティ規定についての詳細は記載しませんが、会社で利用する以上、外部監査に対応出来る必要がありますし、規定されているセキュリティ規定をクリアする必要があったので、必死に調べて対応しました。
この辺については、社内のセキュリティ担当部門の人へ本当に何度も資料を持ってアタックしにいきましたが、アタックしに行く度に前向きな回答をもらえたのは助かりました。

最終的に大事なポイントは下記3点でした。

* 認証
* 認可
* ログ（トレーサビリティ）

この3点については、運用面でも大きな課題があって、結局「アカウント管理者」「ログ管理者」という不幸な運用者を無くす事が出来るかどうかが大事でした。
Slack単体ではクリア出来ない部分が出てしまったのと、Slack以外にもツール導入を進めていた事から、社内アカウントシステムと完全連係した[OneLogin](https://www.onelogin.com/jp)を組み合わせる事でクリアさせました。

※Slack単体だと、毎日アカウントや権限棚卸ししてログを確認する。といった不幸な運用者が出てしまう事が避けられなかったでしょう。
※認証・認可とログ（トレーサビリティ）の補完のために、OneLoginを導入した理由はまた別の機会に書ければと思います。

SlackとOneLoginの組み合わせによって、Slackへのアカウント作成から権限付与、退社時の権限剥奪、ログ収集やアラート対応といった基本的な運用事項はほぼ自動化出来たので、 `利用者へのルールで縛る` という不毛な対応を極力少なく出来ました。
また、利用者にもOneLoginを用いたシングルサインオンや簡単に使える2要素認証機能の提供によって利便性も向上できました。
コミュニケーションコストの低下が主目的なので、出来るだけルールで縛る事をせずに進めたかったので助かりました。
一部のルールも `Slackの使い方` という事でドキュメントの一部としてルールを規定して利用者に周知しています。

![image](https://qiita-image-store.s3.amazonaws.com/0/10852/e74c4c3f-4c5b-9954-ff0a-fd75872fcb1a.png)
ルールの記載例

## これまでに出来た事

始まったばかりですが、社内や社外と連係したSlackを中心としたChatOps環境を提供し始めた事で、コミュニケーションの敷居は下がったんじゃないかな？と感じています。

![image](https://qiita-image-store.s3.amazonaws.com/0/10852/9319b75c-a519-03a1-c5fb-706343c1f2d9.png)
現時点のSlack利用画面のチラ見せ

![image](https://qiita-image-store.s3.amazonaws.com/0/10852/f555f993-176f-03cb-bf64-157b9ec168be.png)
平均的に5000メッセージ/日くらいのやりとりが発生している。内インテグレーションによるシステム連携が2000メッセージ/日くらい。


## 今頑張っている事

「Slackを導入して良くなったな。」という状況を定量的に表したいと思っています。
例えばOffice365から、月間レベルでメール送受信回数や会議の開催件数を取得してSlack導入前後での差を分析する事で、コミュニケーションに用いた時間や質の差を示せないかなーと模索しています。
この辺は @tily さんや @muddydixon さんに助けてもらわないとなー（ﾁﾗｯ
感覚的には確実に良くなっているので、定量的に効果を示してエンジニアだけでなく全社的に導入できたらなと思っています。

その他ツールとして[GitLab Enterprise Edition](https://gitlab.com)の導入も進めています。
この分野だと、世の中的にはGitHubがデファクトツールとなりつつありますが、独自の進化を続けているGitLabはGitHubの良い所を取り込みつつ、さらに使い勝手の良い所が沢山あります。

# おわりに

最初は一人で妄想しているだけの活動でしたが、社内で沢山の人達の助けてもらってなんとかここまでたどり付きました。
特にセキュリティ担当者、情報システム担当者の方々には、無茶難題を振りまくったなーと思い返しつつ、沢山協力頂きました。
始めた当初は「なぜそんな事やるの？」とか「既に出来てる会社へ移れば良いじゃ無い？」という声も聞き、
大変ではありましたが、社内で仲間を見つけて活動出来て良かったです。

自分は[座右の銘](http://www.nifty.co.jp/cs/catalog/nifcorp_2014-member/catalog_141022004369_1.htm)として、「隣の芝も青くする！（他人をうらやむより、自分で変える）」という気持ちを持っていますが、一人じゃ諦めてただろうなー

社外の方が書かれている記事にも勇気づけられました。特に記憶している2つの記事をピックアップしておきます。

* [Slackが「安全」な理由](https://blog.animereview.jp/slack-safety/)
    * この記事に限らず、しんじさんのSlackに関する記事は、同じく監査対応が必要な企業への導入という点でくじけそうになった時に勇気づけられました
* [Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう](http://c16e.com/1511101558/)
    * この記事がバズった時のはてブコメントやTwitter上のコメントを見て、進んでいる道は間違ってないだろう。と感じました

この場を借りて感謝です。

まだまだ理想する環境には道半ばです。機会を見てまた進捗を書きたいと思います。

明日は@okataitai さんの記事です。
お楽しみに。


# 補足

@tnaoto さんが[Fujitsu Advent Calendar 2016](http://qiita.com/advent-calendar/2016/fujitsu)の2日目記事「[富士通がAdvent Calendarに参加することになった理由](http://tnaoto.hatenablog.com/entry/2016/12/02/114611)」の記事の中で

>現在の富士通グループでは、社内規定によりSlackの単体導入はNGとなっていますが、 今回のような話をきっかけに、世の中のスタンダードをどんどん取り入れていきたいと思います。

って書いてますが、富士通グループ企業でも、要件を満たせば入れられますヽ(・∀・)ノ
※@tnaoto さんには突っ込み済み