イベント「Webクリエータに告ぐ！　……ツール紹介」

2015/03/15 　SHIBUYA★LABU　のイベントに参加。HDE社の会場＠渋谷、にて。正式名称「Webクリエイターに告ぐ！？ツールに頼って余った時間で◯◯しよう！～注目！制作現場で触っておきたいツール紹介～」

イベント概要：https://shibuya-labu-pt.doorkeeper.jp/events/21794
講師：オフショア開発PMとかやっている、株式会社ネクストの国際事業部、千葉　礼美氏 Twitter@rechiba3
講師は酒と女とらーめんが好きらしい。ラーメンブロガーだとか。Webディレクター。http://rechiba3.net/　後日スライドがUPされるらしい。

【ツールの選定眼を鍛える】

頼りになるツールをどう探すか。ツールを選ぶ際に「頼りになる」を選定の基準に。忙しいのを何とかするために頼りになるツールを探す。目的用途にマッチしており、使う気にさせ、信頼ができるものを。他の人に紹介できるものを。
ツールで置き換えられること：記録、整理、解析。（言った言ってない論。タスク。バグ報告数。誰のタスクか。バグ解析。）話し合いの材料に。人間はコレを外に出した分、頭の容量が減って他にリソースを回せる。人間は人間ができる仕事を。
→チャット、ファイル管理、タスク管理を使うことで、記録・整理・解析をツールで行うことができる。

【チャットツール】

選定基準：ログが残る。プロジェクトごとの部屋。サムネイル画像（部屋とかがすぐわかるように。可視性のあるアイコンを）。引用（内部外部。あのときの時間につぶやいたコレ、とか）の機能性。
運用ルール：チャット上でファイル受け渡ししない（ファイルの更新の保証がない。ローカルの中に古いものが入ってしまいどれが最新かわからなくなる。ファイル管理ストレージでやりとりするように）、関連タスクのID、URLの明記。話題ごとに決められたチャットルームで発言（未来のあなたのため。いつ死んでもいいように、自分が死んでもプロジェクトが回るように）。サムネ画像登録（すぐ判別できるように）、チャットルームが必要なくなっても消さない（ログを残すため。あるいはエクスポートする。過去のやりとりをさかのぼったり検索したり。）
ツールの例１：chatwork（http://www.chatwork.com/ja/）　いつのつぶやきへの返信かがよく分かるのが魅力的。ただ機能が多すぎて嫌われることも。
ツールの例２：slack（https://slack.com/）　スラックと読む。チャット情報の編集機能で固定のURLとかメモしておけるのが便利。（テストサーバについてとか。）外部引用が優れておりGitHub、Twitterと連携している。GitHubでのコミット情報を流したり、Twitterの特定IDを全部取っておいたり、とか。かなり快適らしい。

【ファイル管理ツール】

選定基準：容量の監視、増減ができる。バージョン管理システムとの連携。メンバーによるアクセス権限。所属組織全員が同じものを使える。
運用ルール：クライアントとのルールと現場とのルールを定義（クライアントは絶対ルール守らないことを前提として割り切った管理するのも手）、チーム内での命名規約。ディレクトリ構造がツリーになるようにフォルダを作る（社内全員が意識する）。バージョン管理システムが導入できる（Git等）。古いファイルルールを無視しない（できるだけ踏襲して現場感を伝えるように。ただ伝統の継ぎ足しは厳しいので提案してみる）。
皆がいろいろな状況の知識を持ち寄ってツールについて議論し、何を選ぶか皆で検討する。
ツールの例１：Bitbucket（びっとばけっと、と読む）。Version管理との親和性が良い。https://bitbucket.org/ コミットメッセージを記録できるのが便利。メッセージをWebで開くことで他の人がソース見なくても進捗を把握できる。
ツールの例：SourceTree（https://www.atlassian.com/ja/software/sourcetree/overview）。サーバがフランスにあるのでたまに遅いことがあるとか。（会社がフランス）

【バージョン管理システム】

SVN、Git（ぎっと、と読む）など。複数あるバージョンの差分を記録。ファイルの変更履歴の記録やバックアップ、修正内容や機能追加を復元、修正することができる。
分散型と集中型が存在。SVNとGitを使い分けすると良い。（目的に合わせた管理手段。）
SVN（Subversion）（http://subversion.apache.org/）：ファイルを同時に編集することがないリソースで使うのに向いている
Git（http://git-scm.com/）：同時に同じファイルを編集するリソースに向いている。

【タスク管理ツール】

選定基準：最低限の登録項目（名称、概要、期限、担当者、ベロシティ）が網羅されているか。作業量の見積もり、記録ができる。現状のステータス（タスクが終わったのか進捗中なのか）。全員が閲覧できる。
運用ルール：タスクには必ず担当者を作る。期限切れを放置しない（やりたいこととやることを一緒にしないようなタスクのきりかたをする）。見込み・実動向数の記録（見込みとどう違うかをあとで確認できる）。タスク粒度を細かく。詳細は後ほど、をしない（詳細欄を書くところにすぐ書かないと絶対やらない）。
TiDD（TicketDrivenDevelopment）：チケット駆動開発。TicketFirst。NoTicket,NoCommit。タスクが発行されることでリソースが動く。チケットが出てから仕事をする。チケットがなければコミットしなくて良い。無駄なリソースが発生しない。（チケットがないのになんか忙しそう……はダメ。）
ツール例１：Trello（https://trello.com/）　小規模なものに向く。運営の確認とかToDoにすべて発行して、メンバーどうしが何をやっているか等にも使える。アカウントがあればだれでも。背景変えたい場合は課金。個人的に「今日のタスクはコレ」が日報管理に良い。常にChromeにつけっぱなし、で使っている。
ツール例２：JIRA（有料）（https://www.atlassian.com/ja/software/jira）。インタフェースのラベルを変えられる。Backlog、ToDo、Doing、Done等。レポートの出力がすごい良い。いまどれだけ時間が費やされているか等。検索システムも優れている。公式の英語動画を見るべし。
ツール例３：producteev（https://www.producteev.com/）（ぷろだくてぃーぶ、と読む。）スピード感が優れている。インタフェースは英語。

【まとめ】

タスクの記録、整理、解析は道具に任せて、コミュニケーション、やるべき仕事に集中できるように。

【質疑応答】

SubversionとGitの使い分けは？　→　Gitは同じファイルを複数で、は向いているが、全員がソースコードを修正することは意外にない。Version管理を触ったことがない人にGitが説明しにくい　　→　講演者様からご指摘があり修正しました。「Gitは同じファイルを複数で編集するようなことに向いているので、ソースコードファイルの管理がベスト。しかし、稀なことが無い限りは同時に編集をしないデザインカンプやドキュメント等はSVNでいいのでは。」　　（……たしかにプログラムソースでも小規模だとよほどのことがないと同じファイルをほかの人と一緒に修正かけることはないですよね）
チケット管理をエンジニアが守らないんだけどｗ　できないものは見ないふりをするとか　→　次の次のリリースにはFixしたいからチケット発行する、等。誰かが管理するとか。（増えすぎたり消えない・期限切れの場合。）
会社で揃えられるの？　→　うちはばらばらだよ。でも揃えようとしている。チャットはchatwork一つ。