こんにちは。

bravesoftの自社事業eventosの開発部門である、PD事業部で事業部長をやっている丹羽と言います。趣味は筋トレとバスケとPJマネジメントです。

先日の第29回東京ノービスボディビル選手権大会でのなかやまきんに君の６年越しの優勝は感動しました。（参考）パワー！

さて、そんな私ですが、約半年前に他事業からeventos事業に参画しました。
その際、最初に関係者に聞いたのは「PJ管理って何を使ってどんなことやってるの？」でした。

そこで返ってきた返事は「Wrikeだよ。」という言葉。
また、そのツールでPJ進捗管理やエンジニアのタスク管理も行っていると言うではないですか。

ということで、この半年間、私がどんな風にWrike使っていたかを良かった点、悪かった点、そして改善点についてまとめて記載してみようと思います。

非常に良く出来たツールだなと思いますので、Wrikeを検討中の方はもちろん、PJ管理ツールでお悩みの方、ご覧頂けると幸いです。

それではいってみましょう。

 

■最初に

Wrikeは無料でも使えますが、弊社では有償のBusinessプラン（月額$24/1ライセンス）を使用しています。

なので、本紹介はそちらを前提としています。（ついでに追加有償アドオンであるResources機能も利用しています。）

価格表はこちら

 

■弊社の使い方

弊社は大きく分けると以下の用途でWrikeを利用しています。それぞれサクッと説明します。

(1) エンジニアのタスク/山積み管理
(2) 開発案件のボリューム把握
(3) 営業からの要望・問い合わせ管理
(4) 時期開発案件の優先度付け

 

■(1) エンジニアのタスク/山積み管理

新規の機能を開発したり、既存機能改修を加えたりする際にはこんな感じでタスクを追加します。

親タスク（実現したい機能）
┗子タスク(各機能の構成する作業要素)

こうすることで、子タスクごとにメンバにタスクを分解し、それぞれスケジュールを設定することが可能です。

また前述のResources機能を使うことで、どのエンジニアの稼働がいつ頃、どの程度空くのか？と言った事もわかるようになります。(来週は稼働が空いてますね。。。。)

 

■(2) 開発案件のボリューム把握
上記の様なタスクに弊社ではカスタムフィールド機能でストーリーポイントと言う枠を作成し、数字を入力しています。
これは開発ボリュームを図るのに利用しています。1pt=1時間で換算し、3時間かかる作業なら3ptと言ったように各タスクごとに設定していきます。

これを１つのPJの各要素に行うことで案件のボリューム感がおおよそ掴めてきます。

弊社は１日のエンジニアの消化Ptを5Pt~7Pt程度で置いているので、例えば1開発PJのPtが300Ptであれば
300/5=60人日の作業ボリュームだと換算することが出来ます。

それを元にPJ内でスケジュールやタスクの調整を行います。（定量的な情報なので、開発メンバ以外とスケジュールの会話をする際に非常に便利です。）

 

■(3) 営業からの要望・問い合わせ管理
社内の営業やCS(カスタマーサクセス)からの問い合わせもWrikeのフォーム機能を使って実現しています。
管理者権限があればこんな感じの登録フォームがサクッと作成できます。

 

チームメンバーは上記のフォームから新規タスクが発生した場合、投稿するだけでWrikeにタスク登録する事ができます。

私のチームでは起票すると担当者が私になるように設定してあり、内容見合いでメンバーにタスクを振っています。

（ちなみにWrikeはアプリも有るので起票のたびにPUSH通知が届くので私の携帯はPUSH通知がたくさん飛びます。）

 

■(4) 次期開発案件の優先度付け
こちらも問い合わせと同様にフォームで管理しています。
各部署から「こうだったらいいな」「こうあるべきだ」と言ったニーズをフォームから引き出し、ストックすることが出来ます。

これを担当者が取捨選別し、次期開発機能とするかの検討を行います。
過去ブログ「【初公開】eventosの新機能はこうやって生まれる！！」ではここで開発すると決まった事項の後工程について書かれています。

 

■良かった点

・PJの残タスクが分かりやすい。

Wrikeはフィルタ機能も充実しているので、正しくステータスを更新していれば、その時点でどのタスクが完了しているのか？残タスクは何が残っているのか？がひと目で分かります。

また、弊社で運用しているストーリーポイントも自動で集計してくれるので、１日の消化Ptをモニタリングして、案件の進行状況を把握したり、期限内に消化できるか？PJはオンスケなのか？の判断軸の１つになります。

 

・ツールをWrikeに1本化できた
思い返すと、これが１番良かったかもしれません。

半年前まではWrikeで開発タスクの管理をしつつ、Backlogで問い合わせ・要望管理、次期開発案件の選別を行っていました。

ですので、Backlogで開発案件が決まったあと、手動でWrikeに登録し、進捗をWrikeとBacklog両方で管理するという、非生産的な管理を行っておりました。

複数のツールを使うということはそれだけメンバーの負担も増えますし、知りたい情報はどこの何を見ればいいかもわからないといった混沌とした状態でした。

それらをすべてWrikeに一本化した事で、非常に楽になったという声をほうぼうから聞くことが出来ました。

 

■反省点

Wrikeは多機能で色んな使い方が出来るのですが、きちんとルールを決めて利用しないと、様々なローカルルールや使い方が生まれ、ちょくちょく問題も発生していました。（Wrikeの問題というよりは管理の問題だと思いますが）

フォームを作成する際、きちんとタイトルや問い合わせ内容の記載ルールを決めずに運用していため、人によって情報の記載粒度にばらつきが生まれ、チケットを見ただけで内容がわからなかったりと十分に機能を使うことが出来ませんでした。このあたりは使用前にルールをちゃんと整備し、全体周知してから導入するべきだったと反省しました。

幸いフォーム機能だったので、徐々にフォームの内容を改善し、今では誰が起票しても一定のクオリティで問い合わせができる状態になったんじゃないかなと思います。

 

■今後の改善点

・ルール制定について
自由に使えるが故に利用者はそれぞれ思うがまま、このツールを使ってしまいます。やはりPJオーナーがきちんと起票ルールを定め、メンバに周知し、文化にしていくといった活動は不可欠だと感じています。

ステータスの定義やPt付けのルールあたりを今後、適正化し、PJコントロールに活かしていきたいなと思います。

 

■最後に

Wrikeのカスタム属性(弊社ではストーリーポイント)を使うことで非エンジニアにもタスクの難易度やPJのボリューム感を感じて貰うことが出来ます。

それを、スケジュール及びタスク管理と併せてツールを分けずに管理出来るので非常に楽だと私は思います。

ここまでお読みいただきありがとうございました。

また次の記事でお会いしましょう。