この記事はドワンゴ Advent Calendar 2017 10日目の記事です。

dwangoアドベントカレンダー 12/10担当の@regtanです。現在はドワンゴの所属以外にもGzブレインというグループ会社に籍を置いています。¹今年は新規チーム立ち上げという場に立ち会うことが多く、そこでは主に開発を始めるための環境づくりを行ってきました。開発ツールは人により好みがある上に生産性を左右するファクターとなるため慎重に選ばなければいけません。

2017年現在導入するならこんなツールということで紹介していきます。

前提

チーム構成
- 社内企画チーム・エンジニアチーム・デザイナーチームに加え、別拠点に外注チームがいる
作るもの
- スマートフォンアプリ・PC向けサイト・スマートフォン向けサイトを展開するサービス
メンバーの特性
- エンジニアは多くのwebツールに適応するが、MS系のWord/Excelは大嫌い
- 企画メンバーは高度なツールよりかはWord/Excelライクなツールが好き
全ての端末はインターネットに接続可能
- 繋げないこともあるので。

コミュニケーションツール

安定性と拡張性でslack優勢

日常的なやりとりするにはSlackが良いでしょう。カスタマイズがしやすいことや各種integrationが充実していることも含めて便利なツールです。Mac版アプリで一時期backspaceを入力すると豆腐っぽい文字が出てしまうことがありましたが、最近は解消しました。chatworkという声も聞きますが、残念ながら信頼性の不安は払拭できません。
各種スマートフォンむけクライアントもありますが、BYODに関するポリシーや無限に連絡が来ることによる若者のslack離れ²には十分注意しましょう。

別拠点との会議はgoogle hangoutを利用しています。slackにintegrationを導入すると /hangout　コマンドですぐにルームを作成してurlがslack上で共有されます。国外とのやりとりだと不具合が多いという話を聞きますが、国内でのやりとりに関しては問題ないかと思います。awsを利用している場合はamazon chimeという選択肢も検討して良いかと思います。

まとめ

やはりslack安定。音声だとhangoutが誰でも使えるのでちょうどいい。

ドキュメンテーション・ナレッジベース

markdownを書くかどうかで選びたい

エンジニアはmarkdownが一番馴染みがあるけど、企画メンバーはmarkdownを書くのはハードルが高い。とはいえ、主にドキュメントを書くことが多いのは企画メンバーが多いのでそちらに寄せる。ということで、お値段的にも、confluenceがちょうどいい感じです。オンプレミス版もありますが、運用が煉獄なのでクラウド版がおすすめですが、聞くところユーザー数が増えるとかなり重たくなるとのこと。あと、プラグイン沼にハマると費用は想定以上にかかることがあります。
メンバーがみんなmarkdownｻｲｺｰという気持ちでやっていくのならばesaやQiita Teamの導入も良いかと思います。また、レポジトリをgitに寄せるならgithub wikiの利用でも良いでしょう。
他の選択肢としてはevernote bussinessやMS onenoteなどもあります。
記述形式以外にも検索機能、ツリー構造の辿りやすさなども考えて導入するツールを選定しましょう。

まとめ

チームメンバーの特性に合わせて選びたい。markdownを書く覚悟があると選択の幅は広がる。ツリー構造や閲覧制限設定などを考えるとconfluenceが機能が多くて幅広いニーズにあう。ただし、プラグイン沼にはまると費用は高くなる。

issueトラッカー

一昔前なら自前ホスティングが多かったが

issueトラッカーもホスティングサービスが増えているので自前で立てて運用というかんじではなく外のものを選びたい。³上のドキュメンテーションツールでconfluenceを選択すると同じatlassian製品のJIRAがプラグインで使うことができる。ただし、設定がとても複雑なので慣れてる人がいないのであれば避けましょう。⁴レポジトリをgitによせるならgithub issuesを利用することも選択肢にいれてよい。最近だとBacklogが人気。みんな大好きMicrosoft Projectも根強い人気があるが、issueトラッカーというよりプランナーなので利用時には注意したい。自前でホスティングするならTrackかredmineになるでしょう。

##まとめ
Backlogかgithub issuesの二択。JIRAはなれているひとがいれば選択肢に入るが、積極的に選ぶ理由があまりない。JIRA使うならredmineのほうが運用は楽。Backlogさんにおかれましては、公式slack integration作ってください。おねがいします。⁵

レポジトリ・ソースコード管理

やはり分散型レポジトリ以外の選択肢はない

レポジトリはやはりGitあるいはMercurial SCMになるだろう。それをベースにgithub.comやGitHub Enterprise、Bitbucketを利用するのがよいでしょう。

まとめ

拠点またぎでの開発を行う場合は、インターネット上のサービスをprivateで利用するのが便利。また、エンジニアの実績としても、オンプレのものよりインターネットに出ているものを利用することで草を生やせるので色々と捗る。

ファイル共有

他のツールについていることが多い

ナレッジベースやトラッカーについて来ているものがほとんどなので、改めて何かを選ぶということは少ないかと思います。よくあるのはdropbox bussinessかと思います。最近だとAWS WorkDocsを選択肢に入れても良いでしょう。

まとめ

他のツールについてるものを使うのが良い。

その他のツール

プロトタイピング

Prottを利用。作られたものが手元でそれっぽく動かしながら確認できるので便利

ベータテスト

メンバーのスマートフォンにベータ版アプリを配布するには、iOSの場合はtestflightもあるが、Fabricを利用。⁶

フィードバック

テストのフィードバックなどを収集するためのツールとして、当初Baltoの導入を予定していたがサービス終了してしまいつらい気持ちです

アセットデザイン・管理

スマフォアプリ内のアセットをデザイン・管理するためにSketchを利用。ネーミングルールをそろえることでスクリプトで素材の切り出しを行っている

最後に

今回はさまざまな開発を助けてくれるツールを紹介しました。この手のツールは最近数多くありますし、営業を受けることも多いです。以前は自前でホスティングして利用していたものも、webサービスとして展開されていたりします。導入するツールに迷ったときは、多くのツールにおいて無料での試用期間があるので、その間に乗り換えるというやり方もありです。プロジェクトに合わせて選んでいきましょう。
また、これらのツールの導入には費用がかかりますので、マネージャーの皆さんは予算の確保もお忘れなく。安かろう悪かろうではこまるので、ある程度バッファを持った予算確保をお勧めします。

いわゆる出向というやつです。ドワンゴのお仕事もあるので完全に出向ってわけではない。 ↩
色々問題をはらむのでインストールの強制などは慎重に。slack疲れてくるとスマートフォンを投げ捨てたくなります。 ↩
NDAやらなんやらの問題があるなら自前ホスティングしかない。 ↩
本当に地雷多い。設定が複雑すぎるかつ適用範囲がわからなくて他のプロジェクトのワークフローエンジンがぶっ壊れたりする ↩
いまはwebhookつかって別サービス経由で送ってる ↩
firebaseと一緒になるって書いてあるけど一緒になってる感が薄い ↩