大規模運用プロジェクトでのWrike移行 ～Tips紹介～

目次

はじめに

はじめまして。サムザップでサーバーエンジニアをしています、若田部です。
今回は、私が現在所属しているプロジェクト「戦国炎舞 -KIZNA-」にてスケジュール・タスク管理ツールを Wrikeに移行した際に行った事例の中から、参考になると思われるものをいくつかTipsとしてお話ししたいと思います。

Wrikeとは

Wrikeとは、2007年にリリースされたクラウドで提供されるプロジェクト管理ツールです。
Googleをはじめ、世界中ですでに2万社以上が導入しているツールとなります。
2019年には日本法人Wrike Japan社も設立され日本語サポートも以前よりだいぶ厚くなっています。
最近ではWrikeについての紹介記事などもだいぶ増えてきましたので、気になる方は検索して頂くと良いかと思います。

私もQiitaの方にWrikeについての記事を書いていますので興味があれば下記も参照して頂ければと思います。

qiita.com

qiita.com

背景

そもそもWrikeは私が関わっていた前プロジェクト「リンクスリングス」にて良いプロジェクト管理ツールがないか？という事で探していた際にグループ会社で既にWrikeを使用されていた方より紹介されたのがWrikeを知るきっかけでした。
私がプロジェクト管理ツールに求めるポイントとしては下記のような点を重視していました。

• スケジュール作成・更新に時間がかからない
• タスク登録が簡単に行える
• ガントチャートは必須
• タスクの進捗が設定できる
• タスクにコメントができる
• ツールの導入・学習コストが低い（直観的に使える）

上記を満たしてくれるのがWrikeだった為、すぐに飛びつきサーバーチームでの導入を相談したのでした。
1プロジェクトの1チームでほそぼそと使い始めたWrikeですが、地道な啓蒙？もあってか今ではサムザップのほぼすべてのプロジェクトでWrikeが導入される事となりました。
各プロジェクトで使われつつあったWrikeですが、約1年ほど前に私が「戦国炎舞 -KIZNA-」に移動してきた際にはまだWrikeを導入できていませんでした。
「戦国炎舞 -KIZNA-」は既にリリースから7周年を迎え、メンバーも100名弱いる大規模運用プロジェクトとなりプロジェクト管理ツールを変えるとしてもかなりの労力が必要となります。
また、その当時の「戦国炎舞 -KIZNA-」では、スケジュール・タスク管理をチーム毎にバラバラなツールを併用していました。（スプレッドシート、Trello、Redmine、Asana、Instaganttなど）
複数のツールを使うということはそれだけメンバーの負担も増えますし（そもそも更新されない事も多く正常に使われていたとは言いづらい状態）そもそもツールが多すぎてどこを見ればいいか分からない、という意見もありました。
その為ほぼすべてのツールの利用を廃止しWrikeに一本化するといった基本方針を決めました。
ただ、前プロジェクト「リンクスリングス」では、1チームでの利用から割と早い段階でプロジェクト全体で利用するように変わっていったのですが、細かなルールを決めずに運用を開始してしまった為、権限を持つ人が自由にフォルダを作成したり独自のワークフローを設定したりした為、ルールが曖昧となり非常に分かりづらいものとなってしまいました。
そこで「戦国炎舞 -KIZNA-」では事前に細かなルールまで決めてから運用を開始する事としました。
Wrikeへの移行を進める上で具体的に決めたルールをいくつか紹介していきたいと思います。

スペース/プロジェクト/フォルダの階層構造

Wrikeでは、タスクをより管理しやすくする為にスペース/プロジェクト/フォルダという基本構成が存在します。
これらを利用し階層化することでタスクをより分かりやすい集合に整理することができます。
ただ、これらを各自の判断で乱立させてしまうと逆に後でよく分からない、といった事態となってしまいます。
そこで「戦国炎舞 -KIZNA-」では下記のような階層構成をルールとして制定しました。

スペース	大カテゴリ	中カテゴリ	説明
プロジェクト名で作成	タスク（フォルダ）	施策（プロジェクト）	ロードマップにて計画されている施策のタスクを作成する場所
ー	ー	改善（プロジェクト）	計画されていないがいずれ対応したいと思う施策のタスクを作成する場所
ー	セクション（フォルダ）	ー	このフォルダ配下はセクション（チーム）毎に自由に利用して良い
ー	マイルストーン（フォルダ）	アセバン（プロジェクト）	この配下にはAssetBundleのバージョン毎のプロジェクトを作成
ー	ー	パッケージ（プロジェクト）	この配下にはパッケージのバージョン毎のプロジェクトを作成
ー	本番不具合（プロジェクト）	ー	本番不具合が発生した場合はこの配下にタスクを登録する
ー	sandbox（フォルダ）	ー	砂場（自由にWrikeの機能を試してよい場所）

※スペース/プロジェクト/フォルダなどについては下記を参照 help.wrike.com

サムザップではほぼ全てのプロジェクトでWrikeを導入しているのでスペース（階層のトップ階層）はプロジェクト名で作成しています。
またスペースの直下には利用用途を決めたフォルダを作成しました（タスク、セクション、マイルストーンなど）。
そしてタスクを作成する際のルールとして
基本１つの施策についてその施策の担当プランナーが親タスク1件：その下にセクション（チーム）毎のサブタスクを切る（※１つの施策で複数の親タスクは切らないこと）
という事を徹底し、タスクを登録したい場合は大カテゴリのタスク配下でのみタスクを登録し（本番不具合、sandboxは例外）、セクションやマイルストーンに紐づける場合はタグ付けをするようにしています。

タスクの命名規約

上記階層構造の部分で触れましたが、タスクを作成する際には親タスク、サブタスクを施策担当プランナーが作成するのですが、その際の命名規約としては下記のようなルールとなっています。

親タスクの命名規約

フォーマット：【親タスク】[カテゴリ名]施策名
例）【親タスク】[クエスト]9月_●●●クエスト

サブタスクの命名規約

フォーマット：【セクション名】[カテゴリ名]施策名　※セクション名以外は親タスクと同じ
例）【PL】[クエスト]9月_●●●クエスト

※カテゴリ名には下記のようなものがあります。
合戦/クエスト/CP（キャンペーン）/ガチャなど

※セクション名には下記のようなものがあります。
PL（プランナー）/CE(クライアントエンジニア）/SE（サーバーエンジニア）/DE(デザイナー）など

ちなみに、長期間かかる施策の場合にはサブタスクの配下にさらに個人毎のサブタスクを切り、さらにその配下に作業ベースのタスクを切ることによってタスクの細分化を行うようにしています。

共通ワークフローの制定

Wrikeでは登録したタスクがライフサイクルの中で現在どのようなステータスにあるかを設定できます。設定できるステータスをまとめたものをワークフローと呼びます。
またステータスは自由にカスタマイズが可能でプロジェクトに適したワークフローを作成することも可能です。
「戦国炎舞 -KIZNA-」では下記のようなステータスが設定された共通なワークフローを用意しプロジェクト全体で使用しています。

ステータス	説明
新規	新規にタスクが作られた状態
着手中	対応を始めたら着手中に変更
レビュー中	作成した成果物（仕様書やプログラム）のレビューが必要であれば、レビュー中に変更
差し戻し	レビューし、修正事項があればレビュー者が差し戻しとする
マージ済み	gitの親ブランチにマージが完了したらマージ済みに変更
確認可能	開発環境で他者が動作確認できる状態になれば確認可能に変更
確認完了	開発環境で動作に問題がなければ確認完了に変更
完了	本番環境でリリースが完了し動作に問題がなければ完了に変更
保留	何らかの理由でタスクの進行が一時的に止まる場合、保留に変更
却下	対応が不要になった場合は却下に変更

なお、上記のワークフローですが各セクション（チーム）によっては使用しないステータスもある為、各セクション毎にステータスの変更のルールも決めていています。

タグの利用

スペース/プロジェクト/フォルダの階層構造で、タスクの作成は大カテゴリのタスク配下のみと記載しましたが、たとえばセクションフォルダの配下で自分の所属するセクションのフォルダがありセクションメンバーが担当するタスクをそこで一覧表示したい場合は新規にタスクを作成するのではなく既存のタスクにタグを設定する事により対応しています。

上記画像のようにそれぞれのタスクにタグを設定する事により、セクション毎にタスクを絞り込めるので管理しやすくなっています。
また、プロジェクト/フォルダには色を設定する事ができ、色が設定されるとタグにも色がつくようになるので見た目的にもタグを区別しやすくなります。

help.wrike.com

リクエストの利用

サムザップではWrikeのBusinessプランを現在利用しています。
Businessプランでは200アカウントまで作成が可能なのですがそれでも限りがある為、Wrikeをそれほど使用しない人には無料のコラボレーターというアカウントを渡すようにしています。
ただ、コラボレーターにはかなりの利用制限があります（タスクの作成ができない、日付の変更ができない、カスタムフィールドが使用できないなど）。
特にタスクの作成ができないというのが問題で、不具合報告などどうしても急ぎタスクを立てなくてはいけない状況などは少し困ってしまいます。
その為、リクエストを活用しコラボレーターでもタスクが作成できるようなリクエストフォームを準備してあります。（上記画像は不具合の報告フォーム）

※ちなみに、コラボレーターの作成数には制限があります。無料だからといって不用意に作成しすぎないようご注意ください。

help.wrike.com

仮運用の実施

ルールもある程度固まった頃プロジェクト全体で2か月ほど仮運用（2020年7月～8月）を実施しました。
仮運用に際して行った事としては、

• マニュアル作成（Confluenceにて）
• 全体勉強会実施（プロジェクトメンバー全員対象に1時間×4回ほど実施 ※Zoomにて）
• 施策毎に関係者を集めて実際の運用を見越したWrike操作手順説明会を実施（30分×19回実施）
• SlackでのWrike質問チェンネル開設（プロジェクトメンバー全員参加）
• プロジェクトメンバー全員のアカウント発行
• Wrike移行チームでフォローしながら、実際の施策のタスク管理をWrikeで実施

勉強会・説明会についてはかなり入念に実施しました。
事前にWrikeについての説明をしっかり行い仮運用としてサポートしながら進めた結果、実際に運用する段階になっても皆スムーズに利用してくれている状態になったのではないかと思います。
また、仮運用を準備していた同時期に他のプロジェクトのWrike運用責任者の方とプロジェクトをまたがる場合のアカウントの管理ルールや新規アカウント申請のフローなども整理しルールを決めています。
それにより現在はサムザップではほぼすべてのプロジェクトでWrikeが導入されておりプロジェクトを横断したタスク管理ができるようになっています。
例えば他のプロジェクトに移動する場合や複数プロジェクト兼務する場合でも移動先のグループを追加するだけですぐにスケジュールなど確認できるようになりサムザップ全体としてもだいぶ効率化できているのではないかと思います。

なお、現時点では既に本運用を開始していますが、まだまだ問題も多くあがってきた意見や要望についてはWrike移行チームで相談しつつ常に改善しながら進めていくように心がけています。

最後に

Wrikeには様々な機能があり自分もまだ網羅しきれていないですが、非常に直観的に使える良いツールだと思います。
プロジェクト管理においてツールの良し悪しで成功・失敗が決まる訳ではありませんが、少しでも効率化する事ができれば今までそこにかけていた時間を別の事に利用できるようになるのでそういった意味でも、Wrikeを使う意義はあるかと思います。
ただ、「戦国炎舞 -KIZNA-」のような大規模運用プロジェクトになるとどんなに良いツールでも導入にあたり大きな問題が散見すると思います。
それらを回避する為にも事前にルールを整備し、一人一人にツール導入の意味や利点を正しく伝えて日々改善して行くことが重要ではないかと思います。
今回の記事が何か新しいものをプロジェクトに取り込んでいきたいがなかなかハードルが高い……というケースに直面している方に対して何らかのヒントになってくれれば幸いです。