1年以上プロジェクトのスケジュール管理で使ってきたWrikeについて振り返る

本記事は[サムザップ #2 Advent Calendar 2019](https://qiita.com/advent-calendar/2019/sumzap2) の12/15の記事となります。

##はじめに
Sumzapでサーバエンジニアをしています@chrno001です。

[1年前の記事](https://qiita.com/chrno001/items/81067677cfdb62919cd2)で、[Wrike](https://www.wrike.com/ja/)についての紹介を書きましたが、サムザップでも複数のプロジェクトでWrikeが導入される事となり啓蒙の甲斐があったかなと思います。

そこで、Wrikeを実際のプロジェクトで1年以上使ってきた中で感じた、良かった点、反省点、そしてこの先どう改善していこうか、という点について挙げていきたいと思います。

なお、自分のプロジェクトではBusinessプラン（月額$24.80/1ライセンス）を使用しているのでそれを前提としたお話となります。

## 良かった点
**タスク登録・ステータス更新が楽**
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104363/8edab49e-19ec-6aee-dde9-0194814a6cc6.png)
今まで色々なツールを使ってきましたが、Wrikeほどタスク登録が簡単なツールはないかなと思います。
自分の場合は雑談からの相談だったり口頭での依頼などがあればすぐに上記の新規タスクからメモ代わりにタスクを登録してしまいます。
担当割りやそのタスクの詳細などは後からでも追記すればいいので躊躇せずにタスクを作成できるというのは大きなポイントだったかと思います。
なお、メンバーの中にはコラボレーター（無料ユーザー）でWrikeを使う人もいるのですが、その場合タスクの登録はできない為WrikeとSlackを連携させSlack上からタスク登録できるようにしたりもしていました（当時はWrikeの機能が十分ではなかった為、GASでそのあたりを対応していましたが今ならWrikeのリクエスト機能で十分対応できそうな位までバージョンアップしていますね）

![ボード.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104363/2631eb44-51b2-2e4b-82eb-0a460c188a10.png)
また作ったタスクはボード（かんばん）形式でも表示できるのでドラック＆ドロップでステータスが変更できて直観的で良かったです（このあたりはTrelloと同様ですね）

**ガントチャートが使いやすい**
![ガント.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104363/1facfea3-2513-af1a-d164-482f2577a3e6.png)

自分がWrikeを推す一番のポイントはガントチャートではないかなと考えています。
特にゲーム開発の場合はスケジュールの変更（仕様変更なり、他セクションの影響でリスケが必要になったりと）が日常茶飯事でかなりの頻度でスケジュールを更新していかなくてはならないのですが、そのような対応もガント上から簡単に対応できる為スケジュール調整もそれほど苦ではありませんでした。
他のツールだとガントチャートだけ対応してない、ガントチャートが使いづらいなどがよくあるのでWrikeが優れている点の1つですね。
あとよく質問で他のツールだとタスクが増えてくるとガントチャートが重くなって使いづらいという話を聞くのですが、少なくとも1000程度のタスクでは全然重さを感じませんでした（Wrike社に聞いた所1万タスク位になってくると流石に重くなってくるらしいので、その場合は階層分けするなどすれば良いのであまり問題にはならないかと思います）

**ツールをWrikeに1本化できた**
これもWrike導入の利点だったかと思います。
Wrike導入前は、Excel、Trello、JIRAなど複数のツールを使ってタスク・スケジュール管理を行っていましたが、複数のツールを使うということはそれだけメンバーの負担も増えますしそもそもツールが多すぎてどこを見ればいいか分からない、という意見もありました。
それらをすべてWrikeに一本化した事で、非常に楽になったという声を多く聞くことができました。

**サポート対応がいい！！**
Wrikeを使い始めた際の問い合わせなどは公式サイトのチャットで割と親身に質問に答えてくれるので困った時など非常に助かりました（ただし、英語対応となりましたがGoogleの翻訳で全然対応できるレベルですね！）
なお、今年Wrike Japanができサポートがより良くなりました。
1年前は色々日本語対応的な部分で多少不満があったのですが、今ではそれらもかなり改善され日本語でのサポート対応も行ってくれるのでホント助かっています。

##反省点
Wrikeの良かった点をあげてきましたが、反省点もあったのでそれも書いていきたいと思います（ただ、Wrikeの問題というよりはマネジメントの問題ではありますが）

**ルールを決めずに運用を開始した為、フォルダ構造がカオスとなってしまった**
Wrikeをプロジェクト全体で使うとなった際に、詳細なルールはあまり決めずに簡単な使い方を説明しただけで各セクション毎に使用を始めてもらった所、フォルダを管理者権限の人の判断でどんどん作成してしまい、フォルダ構造が非常に分かりづらいものとなってしまいました（またワークフローも各セクション毎で決めてしまった為、ステータスも複雑になってしまいました）
このあたりは使用前にルールをちゃんと整備し、全体周知してから導入するべきだったと反省しました。

**進捗確認が密に行えていなかった**
進捗確認は定期的には実施していましたが、忙しくなってしまうとその頻度も減少してしまう場合もあり、チームによっては出来ている所と出来ていない所の差もあり、それにより連携がうまくいかなかったという部分でWrikeをちゃんと有効活用しきれてなかったのではないかなと思います。
このあたりもちゃんとルールを設け、定期的な現状報告、チーム間におけるコミュニケーション不足解消などに取り組んでいかないといけなかったなぁと感じました。（あくまでもWrikeはツールの１つであり銀の弾丸ではなく、[PMBOK](https://ja.wikipedia.org/wiki/PMBOK)などもっと意識的に行っていかないといけない部分ですね）

##今後の改善点
今、自分の方でまだWrikeを導入していなかったプロジェクトの方でWrike導入する動きをしていますが、その際に反省点を生かして取り組んでいる事や今後実施してみたいことを書きたいと思います。

###ルール制定について
Wrikeをプロジェクト導入する前に責任者がある程度ルールを決めておいた方がいいと思います。1プロジェクトのみでWrikeを使うのであればまだ良いですが、複数のプロジェクトを管理しようとした場合にルールがあいまいだと非常に使いづらい状態になってしまうかと思います。
そこであくまでも1例ですが今後の改善として制定しようと考えているルールをいくつか紹介したいと思います。

**階層構造**
階層構造については、プロジェクト毎の特性にあわせてルールを決める必要があるかと思いますが、直近のプロジェクトでは下記のようなルールで作成しようと考えています。

|    スペース    |   大カテゴリ   |   中カテゴリ   |                           説明                           |
|:--------------:|:--------------:|:--------------:|:--------------------------------------------------------:|
| プロジェクト名 | タスク         | 施策           | プランナー主導の機能（親チケットを作る場所）             |
|       ー       | ー         | 改善           | プランナー主導でない機能（いずれやる必要があるもの）     |
|       ー       | ー         | 要望           | 実施予定はないもののやりたい内容                         |
|       ー       | セクション     | サーバ         | サーバ用（このフォルダ配下はセクション毎に自由に利用）   |
|       ー       | ー     | クライアント   | クライアント用                                           |
|       ー       | ー     | フロント       | フロントエンジニア用                                     |
|       ー       | ー     | プランナー     | プランナー用                                             |
|       ー       | ー     | クリエイター   | クリエイター用                                           |
|       ー       | マイルストーン | アセバン       | この配下にはアセバンのバージョン毎のプロジェクトを作成   |
|       ー       | ー | サーバデプロイ | この配下にはサーバデプロイ予定日のプロジェクトを作成     |
|       ー       | ー | パッケージ     | この配下にはパッケージのバージョン毎のプロジェクトを作成 |
|       ー       | 本番不具合     |       ー       | 本番不具合が発生した場合はこの配下にタスクを登録する       |

またルールとして
**基本１つの施策に親タスク1件：その下にセクション毎のサブタスクをきってさらにその下に対応内容のタスクを切る（※１つの施策では複数の親タスクは切らないこと）**
という事を徹底し、タスクを登録したい場合は大カテゴリのタスク配下でのみタスクを登録し（本番不具合は例外）、セクションやマイルストーンに紐づける場合はタグ付けをするという運用を考えています。

**タスクのタイトル**
タスクのタイトルは、それだけで何の作業が分かるようにしておく必要があるかと思います。
よくありがちなのが「結合テスト」というようなタイトルをつけてしまうと検索時に非常に探しにくくなってしまう為、「●●機能結合テスト」などのようになるべくユニークな名称にする方が後で検索する際に探しやすいかと思います。
サブタスクとして切ったタスクを後から検索しようとした際に割と後悔した事があるのでこのあたりもちゃんと命名ルールを設けたいと思います。

###今後使っていこうと考えている機能
**カスタムフィールド**
![カスタムフィールド.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104363/ec237152-a5bd-4431-ce0a-151ff056d83e.png)
こういうフィールドがホントは欲しいんだけどなぁ、という時に自分専用のフィールドが作成できるのがカスタムフィールド。こちらはBusinessプラン以上であれば使用できます。（自分、前から存在は知っていたのですが使い方がよく分からず使っていませんでした）
例えば、優先度（S,A,B,C）みたいなフィールドが必要であればこのカスタムフィールドを使うことにより作成できます。
（ドロップダウンやチェックボックスみたいなものだけでなく、簡単な計算式のあるフィールドも作成できるようです）
これを作成する事によってより細かなタスク作成もできると思うので、こんなフィールドが欲しいというものがあればどんどん作っていきたいと思います。
ちなみにカスタムフィールドはViewがテーブルの時にしか作成できないのでご注意を（利用はほかのView、さらにはリクエストでも使用できます）


**日刊ダイジェスト**
![メール.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104363/c66ac89e-be97-4d1e-7a92-fd92f05200ef.png)
Wrikeは様々な通知設定がありますが、最近見つけたのが日刊ダイジェスト。（プロフィール設定→Eメール設定で確認できるかと思います）
ToDOリストはデフォルトでチェックされていると思うのでWrikeを触った事のある人は知っているかとは思いますが、その下に日刊ダイジェストというものがあります。
こちらをチェックすると、指定の時間に今日更新したタスクの内容などがダイジェストとして送られてきます。また、自分がタスクを登録し誰かに割り振ってその人がそのタスクを更新した場合もリマインドしてくれます。
よって1日どんな作業を行ったかの記録にもなりますので日報の代わりとしても使えるのではないかなと思いますので皆に薦めていきたいなと思います。


## さいごに
タスク・スケジュール管理は面倒で大変な作業で好んでやる人は少ないでしょうが（特にエンジニアだとマネジメントをやってくれる人が殆どいないのが実情かと）、Wrikeはその手間を大きく削減してくれる非常に良いツールかと思います。
現在タスク・スケジュール管理で困っていてWrikeを導入すれば解決するような事象なのであれば、助けになれるように今後も取り組んでいきたいと思います。

明日は[@shintsu_takamasa](https://qiita.com/shintsu_takamasa)さんの記事です。