同人プロジェクトマネジメント入門の目次はこちら

はじめに

ツール導入のジレンマ

仕様書作成ツールと同様に、計画ツールにもジレンマが存在しています。

「コストを減らすためのツールだが、ツール自体のコストがある」
「しっかり計画を管理したいが、ちゃんと運用しない人がいるとツールの運用自体が無意味になる」

この2点を把握することがツールの導入の第1歩だと思います。

ツールの候補と評価

LineやSlackなどのチャットツール

特徴

手軽さを求めると最終的にここにたどり着くと思います。ただ、絶対にやめるべきだと書いた仕様書の場合に比べれば、計画がTLに流れるのは多少はアリだと思います。きっちり合意をとってデータで残しておくべき仕様書データと比べれば、「今何をやってるか」は短時間で有効性を失うデータだからです。

おすすめの運用方法

やること自体を仕様書にしておけば、あとはSlackに「xxやります」「○○できました」と書けばいい感じに運営できるでしょう。もちろん「進捗どうですか」という恐怖のDMを頻繁に送ることになるでしょう。

評価：3人まで、かつ、仲がいいチームなら適している

自然とだれが何をやってる情報が流れていくような人数と会話の頻度であれば、明確なツールを用いなくてもだれが何をやっているかはわかると思います。逆に、人数が増えると、その二乗に比例して1:1の連絡路は増えていきます。つまり、進捗どうですかDM方式だと4人を超えると簡単にだれが何をやっているか分からない状況が生まれてきてしまいます。

Trello

特徴

シンプルなカンバン方式のタスク管理ツールです。
学習コストが非常に低いので、はじめやすいです。プロジェクトのメンバーに勉強してもらう時間は少なくてすむでしょう。
「誰が」「何を」「どのぐらい」やるかが目に見えるような運用が可能です。

おすすめの運用方法

手順

リストには「仕様リスト」「開発メンバー名_doing」「開発メンバー名_done」「開発メンバー名_todo」を用意します。
仕様リストには、大まかな仕様と締切が記載された「仕様カード」を配置します
仕様リストから開発メンバーのtodoリストに仕様カードを割り当てます
開発メンバーはtodoに割り当てられた仕様カードを8時間ぐらいでおわる程度のタスクを表す「タスクカード」に分割します(8時間の根拠は1人日でキリがいいことです)
開発メンバーは分割したタスクカードを自分のdoingリストに割り当ててから作業を開始します
タスクが完成次第doneリストにタスクカードを配置します
すべてのタスクカードが消化出来たら、仕様カードをdoneリストに配置します

注意点

仕様カードは、仕様書から作成します。仕様カードの締め切りは、出来るだけ短く・小さくなるようにします。(やむなく大きくなる場合は、有能なメンバーに割り当てをする)
仕様カードの割り当ては、全体がいる場で行います
タスクカードがdoingに入ったり出たりすると、Slackに通知が送られるようにします。その他必要があればSlackに通知を送る設定をします
タスクカードと仕様カードの切り替えは、ラベルを付けて視覚化します
タスクの分類があれば、ラベルを付けるとよいでしょう

評価：4,5人のプロジェクトに最適

Trelloには基本的なタスク管理ツールとしての役割を熟すのに必要十分な機能があると思います。
「タスクを整理する」ためにはうってつけのツールですが、「特定の人物がやった仕事を承認する」などの複雑なプロセスには対応していません。「タスクごとの依存関係を管理する」「各メンバーの作業負荷を確認する」などの作業にも対応していません。ただ、同人プロジェクトにおいて、このような管理機能がいるのはごくまれだと思います。管理ツールがない状況のプロジェクトは、まずはタスク管理をTrelloに移行させてみることをお勧めします。

Github Projects

特徴

めちゃくちゃ雑に言うと、TrelloのボードにGithubの機能を関連付けたものです。「pull requestがマージされれば自動的にdoneへ行く」などのインテグレーションが便利です。

おすすめの運用方法

この辺りの記事様を参考にすればなんとなくわかると思います。

評価：Githubの各種機能がうまく運用されるならよい

Github Projectsのタスクカードには、issueやpull requestが紐づけられているので、Githubの機能をうまく利用できる場合にはぴったりです。例えば、仕様管理をissueで行っている場合には、その仕様がそのままカードになるので、統一的で便利に使えます。プロジェクトの人数としては4,5人以上が適していると思います。
もちろん、これをやってしまうと、あまりGitに親しみのないデザイナーに対して、Gitの学習コストがかかってしまうという問題があります。Trelloに比べて一長一短といったところです。

AsanaやJiraなど、本格的なプロジェクト管理ツール

使ったことがないので評価が出来ないのですが、おそらく同人プロジェクトであれだけの高機能ツールを運用しようとしても、ツールが強すぎて使いこなせないと思われます。(偏見です)

タスク管理ツール運用ガイド

必ず運用させよう

全てのツールで一番大事なのが、運用させることです。運用が難しければ、より雑な運用に切り替えてもいいので、とにかく全員に適正な運用を覚えさせましょう。
Trelloを使っている場合を想定します。

日々の声かけ：「(Slackで進捗報告したら)お疲れ！後から分かるようにTrello動かしておいて」とか「(Trelloに記入せずに仕事をしてしまった場合)最近仕事してる？Trelloしか見てないから分からないよ～」とか
適切なSlackとの連携を設定する
締め切り情報などを定期的にTrello側で確実にまとめる(SlackになくてTrelloにある重要情報を増やす)

進んでない場所には積極的な声かけをしよう

社会人だと報告(事後の連絡)、連絡、相談(事前の連絡)は基本だと言われますが、同人プロジェクトだとほとんど守られません。むしろ、こまめな連絡が必要な人ほど連絡してきません。なぜなら、進捗が出ている人ほどその報告をするのは楽しくなるのに対して、出ていない人ほどその報告は絶望と気まずさに支配されたものになるからです。しんどい。
そこで、これらのタスク管理ツールを有効活用しましょう。「連絡はできたらする」になってしまいがちなSlackなどの運用に対して、TrelloやGithub Projectsは、「細かい粒度の完成一つ一つで通知が飛ぶのが普通」という状況を簡単に生み出せるので、あまり進んでいない人が炙り出せるのです。
進みが悪い人には、早めにDMで呼びかけておきましょう。返信が極端に遅い場合には、おそらく「モチベーションが尽きているけど、やれないというのも自尊心が辛い。見なかったことにしよう」というパターンです。もうそのメンバーは居なくてもまわるように計画を立て直すしかありません。
逆に、早めに「○○でダメでした」という連絡が来た場合には希望があります。単純に実力が足りていないパターンなら、簡単なタスクを渡して大量に単純作業をしてもらい、ゲームの身を詰めてもらいましょう。

どの仕事が遅れているかを早めに把握しておけば、連絡・計画の再構成といった仕事を早めに行えます。

おわりに

仕様書管理ツールに比べれば、タスク管理ツールは比較的大人数のメンバー全体で使いこなしていかないと恩恵が得られにくいです。支障が出るまではSlackから始めて、個人でTrelloを運用するなどの形がいいと思います。