ロボトラでSlack＆Trello＆GitHubの開発体制を試してみた感想

結果も大切ですが，今回のロボトラではそのプロセス（開発体制）にも注目してみました．

といっても，単にいままで不満があったのを少しでも解消したかっただけなんですけどね．

何をしたかというと，最近話題のSlack，Trello，GitHubを使った開発体制の試験的な運用です．

それぞれの詳しい特徴や使い方の解説はWeb上に沢山の情報があるのでそちらを参照していただければと思いますが，ざっくり言えば，

• Slackで連絡（チャット）し合い
• Trelloでタスク管理を行い
• GitHubでソースコード共有・分散開発する

という流れす．

ネットで話題になっているだけあって素晴らしいツール群で，今までより格段にスムーズな情報共有を行うことができました．

ただ，運用するにあたって気をつけなければならない事があることもわかりました．いくら良いツールでも活かせるかどうかは使い方次第．使えば絶対にうまくいくわけではないようです．

導入の経緯からどのように使いその結果どうだったか，良かったところや今後使う上で考える必要のあることを主観的にダラダラと述べていきたいと思います．

結構長いです．

これまでの不満：ローテクな情報共有

サークルでは数人でプロジェクトを組んで何かを作るという機会が多々あります．

ロボトラはチーム開発を要するイベントの１つなんですが，過去４回出場してきて色んな不満がありました．

端的に言えば情報共有の問題です．

メンバーはバラバラの時間帯・場所で作業をしますし，そもそも時間がない．動き出すのが遅いだけ

トピックの混在により履歴を遡るのが手間

何が重要で何が重要じゃないか分かりにくい

誰が何をやっているのか，どこまで終わっているのか把握できない

などです．

進捗確認のためにわざわざメールで「今どこまで進んだ？」なんて聞くのは，手間でしかありません．

必要な情報を得ること自体に労力と時間を消費して，作業に集中できなくて発狂しそうです．

ここまでやりましたという報告を残し，必要な時に必要な人が見に行けばいいだけのはずなのに．

サークルの運営自体がメーリスしか全体連絡手段を持っておらず，何でもかんでもメーリスが流れてしまうローテクな情報共有が諸悪の根源なんだと思います．

なお，LINEは使ってる人と使ってない人が混在する世代なのでいまのところ連絡手段のインフラにはなってません．数年にはLINEはメールとは別のインフラとして活用されると思います．
Wikiはどうした・・・？

色々なツールを試す

そんな不満を持っていたので，何かいい方法ないかなーとチケット管理ソフトやグループウェアなどをここ数年個人的にor小規模グループで試してました．Trac・Redmine・サイボウズをピックアップして個人的な印象を載せておきましょう．

Trac

組込み開発系の某アルバイト先でTracを使ってましたが，これはマネジメントコストが高さと導入の敷居の高さがネックで，今ひとつでした．

定期的にマネジメントする人が必要であり，利用者が適切な使い方を分かってないとうまくいかない気がします．

Redmine

ひとりRedmineやってましたがTracと同様でした．

個人的にはTracよりも少し高機能で好きなんですが（ただしRedmine付属のWikiはダメ）．
そもそも一人という時点で使う意味が（ｒｙ

サイボウズ

別の団体でサイボウズを使ってましたが，何か惜しい，いまひとつな印象がありました．
ソースコード管理ツールなど他webサービス系との連携弱いのと，画面遷移が多い（UIがちょっと古い？）からでしょうか．

掲示板という形でトピックを立てていける点，カレンダー機能，タスク管理など機能はかなり程度揃っており，機能的には十分ですし，ある程度情報を集約していくマネジメント係は必要でしたが，過去にやったことの情報がトピックごとに整理されて残っているというのは，１年後とかに振り返った時に見やすくて良いと感じる場面も多々有りました．

これ１つで色々こなせるツールだとは感じてましたが，上記の点が気になってたので，コレで運用する決断はできませんでした．

その他

紙にガントチャート書いたり，ChatWork使う機会もありましたね．言い出したか切りが無さそうなのでここらへんでやめておきます．

Slack・Trelloに出会う

昨年，某アルバイト先の同期が，インターンシップ先で「Slack・Trello使っていて良かった」というを聞き，早速どんなツールなのかググってみました．

・・・

どうやらかなり評判が良いです．

コレは試してみたいと思い，そのアルバイト先の人と使ってみたり，ひとりで試しに使ってみたりしていました．

使ってる最中の心の中は　ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!　という感じでした．

とにかくUIが素晴らしく，使っていて心地よいです．
使いたいと思わせるデザイン・操作性は重要ですね．

本命である「チーム開発」での使い心地を試してみたくて，今回ロボトラで試しに使ってみた，というのが今回導入した経緯です．

バージョン管理・分散開発手法（Git）の導入は言わずもがな．

Slack

基本的に連絡はSlack（無料版）で行いました．
最初だけメールでSlack招待などの連絡をして，その後は一切メールを使わずに済みました．

メンバーからの評価

ロボトラ後，メンバーに使用感を聞いたところ，かなりポジティブな意見が多かったです．

チャット特有の気軽さを備えつつ，Channel単位でトピックごとに話題が固まりタイムラインがカオスにならないというのが好評でした．

ネガティブな意見は「Channelをうまく使い分けできていなかった」ということぐらいでしょうか．

個人的な感想

Slackは高機能版のLINEというポジションだと思います．
LINEと異なり，複数のタイムライン（Channel）を持てること・Channelに途中から参加しても過去ログを閲覧できるので新規加入者への情報再通知も不要という点がgoodです．

その反面，どんなChannelを作るべきか，どこに何を書き込むべきか，という点がやはり悩みどころです．Trelloと併用して使ってるとトピックが重複することもあり，チーム内からは使い分けに困ったという声が多々ありました．

Channel構成の定石でもあれば良いのですが，何が良いかは組織によって変わってきそうです．
使っていくうちに取捨選択していくことになるんでしょうかね．
（良いChannel構成例があったら教えて下さい．）

また，各個人で各Channelごとに通知レベルを細かく設定できるのは個人的にとても気に入ってます．

直感的にわかるツールですが，アカウントの作成・Channelの使い分け・通知レベルの設定のことを考えるとメール・LINEよりは導入の敷居高いです．比較的理解しやすいツールなので，一度使えば大丈夫だと思いますが．．．

受け容れられるか否かはココら辺が肝だと思います．

あと，あくまで組織内のツールなので外部のコミュニティと連絡はやはりメールになりそうです．

用意したChannel

参考までに，今回使用したchannelと使い勝手は以下の通りです．
使ってくうちにどのChannelが必要か，感覚的に身につきそうです．

channel	用途	使用感
#budget	購入物に関連したもの	Trelloで済んだので不要だった感
#general	雑談用	必須
#log_sw	GitHubログ＋たまにコメント	たまに見る程度． 人によってはプッシュ通知．横断検索に存在意義ありかも？
#log_trello	Trelloログ． リンク・横断検索用	必要な項目だけ通知するようにしないとログが激しくて危険
#poster	ポスター担当との連絡用	若干，Trelloと被ってた．TrelloよりはSlackの方が良さ気．
#random	デフォルトで存在	不要
#rule	チームでの決め事	ストック情報なので承認されたらpinしておくと良い感じ．
#schedule	メンバーの予定共有	必須． カレンダーでも良いが，対話的に気軽にできると「これから行く」「帰る」というのが気楽にやりとりできる．
#specification	マシンの仕様	微妙．Wikiの方が目的に沿っている． ほぼ直の会話で済ませてたけど，後々の事を考えるとこちらにログを残すべき．
#tools	開発ツールの使い方，Tips	少し役に立っていた． 初導入のツールが多いので，使い方や解説が載ったwebサイトのリンクを貼って勉強．

Trello

Trelloはタスク管理ツールとして使っていました．
大雑把な話はSlackで行い，タスクごとの話し・作業ログはTrelloに書き込むことにしてましたが，あまりこだわらず緩く使ってました．

最初に一般タスク用，ソフトウェア用，ハードウェア用のBoardを作っていましたが，最終的には一般タスク用とソフトウェア用のBoardの２つに落ち着きました．

目新しいツールながらも操作は直感的なのでメンバーはスムーズに使えていたようです．

メンバーからの評価

メンバーからの評価はSlackほどの満足感はないものの，普通～良好でした．

直感的・画像のアップロードが楽・タスクの状況を俯瞰できる・タスクの状態を手軽に更新できるといった点が好評でした．

ネガティブな意見としては，ラベルなど一部の機能が把握しきれなかった，使いこなせてなかった，更新が気づかないことがある，などがありました．

個人的な感想

細かいタスクごとに話題が集中されているのでほしい情報に辿り着きやすく，タスク管理ツールとしては有用性高いです．

欲を言えばタスクにツリー型の関連付けをできる機能が欲しいですね．（逆にないのが良いのかもしれません．）

チケット管理ツールに似た雰囲気がありますが，スピード感がある（手軽さ）・フラットな組織向けな印象が強いのがTrelloだと感じました．
手堅くやるならチケット管理の方が良さそうです．

先ほどBoardが２つに集約されたと書きましたが，Boardが分散すると画面遷移が必要となり見通しが悪くなってしまうので自然な流れですね．

とはいえ，あまりにカテゴリが混在するのも見辛いので，Boardの分配は難しいです．
どの程度のタスクを１つのカードにするのかも問題です．（チケットでも似たような悩みが．．．）
何か基準や方針でもあると良いのですが．

また，写真を簡単にアップロードできるのは非常に好印象でした．
スマートフォンで撮った画像はTwitter並の手軽さでスマートフォンから画像をupできますし，クリップボードにある画像も「Ctrl + V」系の貼り付け操作で一発です．
（Slackもなんですが）

作業のスクリーンショットや写真を撮ってアップロード，コメント一言加えておくというTwitter感覚での作業記録の残し方が個人的には気に入ってました．
この使い方が良かったかのかはもう少し先になって振り返る時がこないと分かりませんが．

反省すべき点は，チーム内からもあったように，SlackとTrelloの用途が重複してうまく使い分けできなかったことです．

タスクという観点でいえばTrello上でログを残すべきことでも，そこで複数人が議論すると見辛いのでどっちに書き込むか迷うんですよね．

（Slackに比べれば）意見を交わすには向いていないインターフェースなところもあり，意見を出し合う場面ではチャットに近いSlackの方が向いている気がします．

今回の反省を踏まえると

• 話し合いはSlackで，進捗ログはTrelloに残す
• ある程度タスク（カード）の方向性が見えてからTrelloで管理
• 作業状況を確認する時にカードの場所・カードの内容を確認

といった使い方に落ち着くのでしょうか．

未だ明確な使い方を見いだせてません．
他の人達がどのように使っているのか気になります．

使用した機能

こちらも，参考までに使用した機能

機能	用意した項目	使用感
Board	General SW HW SandBox	SWはソフトウェア開発担当者のみで使用． HW, SandBoxは出番なし．
List	info, TODO, Doing, Done マイルストーン, マイルストーン用Done 保留	ちょっと多めで運用． infoはストック情報用．マイルストーンは統合カードを見習って． 保留はあると便利です．
Label	SW, HW, Arm, ポスター, 買い物	Generalに混在してたのでラベルでカテゴライズしてたが，不要だった． 買い物が関わるものに色付け

GitHub

ソフトウェアを扱う人達でのみ使用してました．
全員svnやgitは軽く触ったことある人達なので，バージョン管理の有用性は認識した上での運用です．
多少準備が大変でも，恩恵が大きいことを知っている人達なので使用を諦めることはしませんでした．

某メンバーのGitHubにリポジトリを作り，git-flowで開発を進めていく流れをとりました．

お互いに助け合えるようにツールはGitHub+SourceTreeで統一してました．
ただし，Windows/Mac混在．

GitHubのコミット情報はSlackに流れるように連携し，
開発のタスク自体はTrelloを併用していました．

これまで使ってたマシンのソフトウェア再開発になるので，以前使ってたソースコードのリファクタリングがソフトウェア担当者の主な作業でした．
その以前使ってたソースコードは本当にゴミみたいなコードだったので大変だったと思います

実はサークルで一度もバージョン管理というのを真面目にやったことがなく，試すにはとても良い機会でした．
というより，時期的にもこれが最初で最後のチャンスでした．

メンバーからの評価

好評だったというよりは，GUIツールへの感動や分散開発の実践できたことが嬉しかったという意見がほとんど．

自分はSourceTreeでGitを学んだのでやっぱり便利だなーという程度の印象でしたが，他のメンバーはSouceTreeに感激・絶賛してました．

全員，ある程度の知識は持っていたものの実践的な分散開発は初めてだったこともあり，ソースコードのファイル分割・git-flowの使い方に苦戦したという意見がありました．

他には，issue全く活用していなかった，Slack/Trelloとの連系は薄かったという意見も．

個人的な感想

自分はソフトウェア担当の主力メンバーではなかったのですが，終盤は少しコーディングしてました．
（featureブランチで作業していたとはいえ，コミットログを汚しまくってゴメンナサイ）

正直，難しかったです．
gitを使ったことがあっても一人でcommit，checkoutしてるのと，他の人と共同で行うのでは次元が違うことを実感する日々でした（といっても２，３日間）．

でも，gitが無いと分散開発が成り立たないぐらい導入の影響は大きいかったです．

加えて，奇跡的にソフト開発の主力メンバーであるI氏とK氏のおかげでなんとか使うことができたという状況で，彼らのようなセンスのあるメンバーがいなければ，そもそも分散開発やこの体制は夢のまま終わっていたのですが．

gitの使い方だけでなく，
Windows/Mac混在環境に対応するMakeファイルを作ってくれたり，
適度にソースコードのファイルを分割した構成を設計してくれたり，
本当に今回はあの２人居てこそという感じでしたね．

いろいろ偉そうなこと言ってる自分ですが，存在と何となくの機能しか知らない中途半端な知識しか持ってないダメ人間ですのでぇ．．．

開発期間が２週間というの時点でそもそもデスマーチ確定な案件の中，本当に感謝です．
出場の決断遅くてゴメンナサイ．．．

分散開発のノウハウはまだまだ蓄積していく必要がありそうです．
git-flowの開発に慣れてる人が一人以上いて，下準備してもらったり，使い方に迷った時に頼れる人がいるのが理想的ですが，そんな都合のいい話は周囲では聞きません．．．
学び，練習しながら，慣れて感覚掴んでいくしかないんでしょうかね．
分散開発バリバリやってるプロジェクトに巻き込まれたい．

まとめ

ここ数年の悩みあった「情報共有」「チーム開発体制」の改善に向け，「Slack＋Trello＋GitHub」を試験的実践し，多くの知見を得ることができました．
長年の夢（？）が，最後に参加するロボトラで実現できて嬉しい限りです．

情報共有は永遠の課題とも言われてましたが，今回は比較的うまく情報共有できた思えるのは

• 気軽さ，手軽さ
• 話題ごとに整理されていて，欲しい情報を見つけやすい
• メンバーが不要な情報を受け取らずに済んだ（通知設定）

というを，これらをマネジメントする人間無しで自然とできていたからだと思います．

直感的なUIのおかげで皆がツールの基本的な使用方法で迷わなかったのも，その助けになっていることに違いありません．
もちろんメンバーがロボトラ経験者だったからこそ新しい開発手法に力を振ることが出来たという要素も大きいです．

Slack+Trelloを使えば万事解決とまではいきませんが，
この組み合わせは十分にそれを実現できるポテンシャルを持っていると思います．
Slackの連携の豊富なので足りない部分を他のツールで容易に補うという選択もありです．
（そういう意味ではメールも使い方次第だと思いますが）

もっと早くに実践したかったとは思いますが，このタイミングだから実現できたのも事実です．

GitHubは随分前からありますが，Slack，Trelloが流行り始めたのはここ数年の最近の話ですし，殆どの人がスマートフォンを持ちPCからだけでなくスマートフォンからアクセスできるようなインフラが整っているからこその話しです．5年前だったらスマートフォン持ってない人も多くいましたし，携帯端末で閲覧できるのは基本的にメールだけですからね．

ただ，いずれも新しい手法・新しく使うツールであるがゆえに
誰かが音頭とって「やりましょう」と主張し，
メンバーが「やりましょう」と同意しないと始まりません．

ツールの使い方をある程度知ってる人がいないとすぐに導入するのは難しく，
導入したとしてもその組織にあった使い方の模索に時間を要するので，
良いツールと分かっていても導入コストの高いツール群であることに違いありません．

個人的には使い心地良かったのでこれを機に，サークル全体でもメーリスonlyの体制から脱却・モダンな開発体制に向けた勉強会を開いたり布教活動をしたいと思ってます．
研究室でも（ｒｙ

あ，分散開発手法のgit/git-flowは引き続きお勉強です．
これは誰かが使いこなせるようになるまで，全体で使うのは厳しそうです（笑）．

思ったことをダラダラ書いていたら，とても長い記事になってしまいました．
上手くまとめられませんでしたが，とりあえずこんな感じで．
（後で画像追加予定）

運用方法があったまた書こうと思います．