coach4pm-プロジェクト管理をコーチングで支援-

Web業界で戦うプロジェクトマネージャーやディレクターのためのノウハウ

非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで

f:id:chitoseweb:20160211201842p:plain

 

皆さんはどんなツールを使ってプロジェクト管理してますか?

僕は10年近くWeb業界、特にウェブサービスの開発プロジェクトに関わってきて、その多くでRedmineを利用してきました。

色んなプロジェクト管理ツールはあるし、それぞれ得意な場面は異なりますが、Redmineは比較的どんなプロジェクトでも活用しやすいんじゃないかと思っています。

そして、開発チームでRedmineを導入しているケースはかなり多いと思うのですが、僕は非開発チーム、あるいは非開発プロジェクトにこそRedmineを導入して生産性の向上が図れるんじゃないかと考えています。

(記事の最後にRedmineの導入手順書を公開していますのでよろしければご活用ください。)

f:id:chitoseweb:20160429131147j:plain

 

そもそもRedmineってなに?おいしいの?

開発系の方でしたら当たり前すぎることかもしれませんが、開発系以外で はRedmineの名前は聞いたことはあるけど実際に使ったことはないという方が多いと思うので、簡単に概要をご紹介します。

 

Redmineは無料で使えるプロジェクト管理ツールです。

タスク管理、進捗管理はもちろん、日々のコミュニケーションにも活用できます。

(コミュニケーションにも使えますが、そこの部分はChatworkなどとの併用がオススメなのでそれについては後述します)

 

元々はシステム開発の不具合修正を目的としたBTS(Bug Tracking System)だった のですが、どんどんバージョンアップされ、今ではプロジェクトのタスク全般を管理するITS(Issue Tracking System)へと進化したツールです。

Redmineでは、必要な作業を「チケット」という単位で登録し、各チケットのカテゴリや期限、ステータスを登録して、ガントチャートを表示したり進捗状況を把握したりできます。

カテゴリやステータスは組織やプロジェクトにあわせて自由にカスタマイズできるため、色々なシーンで活用できるとても汎用性の高いツールです。

 

Redmineの設定の柔軟さが、非開発部門の業務に適用できる最大の理由

Redmineを上手に使うと、以下の3つが実現できます。

 

  • 現状と予定が可視化される
  • 業務プロセスが体系化される(ワークフローが設計できる)
  • 作業履歴が残るため、担当者が変わった際のタスク移行や、あとからの振り返りがしやすい

 

これは開発部門に限らず、どんな組織にも求められるものではないでしょうか。

Redmineは設定が非常に柔軟にできて、また様々な拡張機能も提供されているため色々な状況に対応できます。

僕が知っている限りでも、Webサービスのカスタマーサポートや、編集部の原稿管理などで活用している例があります。

裏を返せば、自由にできる設定をうまく活かしきれないと無用の長物になってしまうということです。

以下を参考に、組織にあった設定を検討してみてください♪

 

Redmineを適切に設定するために、まずは構造を理解しよう

Redmineは以下のような構造になっています。

 

プロジェクト

 ┗サブプロジェクト

  ┗バージョン

   ┗親チケット

    ┗子チケット

     ┗トラッカー

      ┗カテゴリ

 

一つずつ見てみましょう。

 

プロジェクト

プロジェクトというのが、Redmineの中でもっとも大きな分類となるものです。

すべての作業は、あらかじめ作成されたプロジェクトの中で行われることになります。

 

サブプロジェクト

Redmineはプロジェクトを無制限に階層化できます。

複数のチームで動く大規模なプロジェクトでは、チームごとにサブプロジェクトを作成して進めるとよい場合があります。

 

バージョン

特定の期日までに完了させなければいけないタスクをまとめたものを「バージョン」として管理します。

ソフトウェア開発では特定の日にリリースするチケット一式を管理するために使いますが、「納品日」や「目標達成期日」などをバージョンとして、細かいタスクを管理する等の使い方ができます。

 

親チケット・子チケット

前述の通り、Redmineではタスクを「チケット」として登録して管理します。

プロジェクト>サブプロジェクトの仕組みと同じように、チケットも無制限に階層化することができます。

タスクを細分化して管理する際に便利なのですが、子チケットに連動して親チケットが自動で更新される仕様になっているため、その点を把握しておくことが必要です。

 

トラッカー

トラッカーはチケットを分類するもので、チケットは必ず1つのトラッカーに関連付けられます。

あとからトラッカー単位で作業を集計できるので、作業分類をトラッカーに設定すると管理しやすいです。

トラッカーごとにワークフローを設定できるので、承認フローを作りたいときに威力を発揮します。

 

カテゴリ

カテゴリはイメージが湧きやすいですね。

これもトラッカーと同様にチケットを分類するものですが、チケットに必ず関連づくものではなく、必要に応じて設定することができます。

 

Redmineを無用の産物にしないための運用ルールの作り方

Redmineを初めて導入するに当たっては、最低限の運用ルールを定める必要があります。

そうしないと、使われないか、カオスになるかのどちらかです。

導入時の運用ルールとしてオススメなのが以下の4つです。

 

  • 作業はとにかくチケットに起票。起票されていないものはやらない
  • 必ず、ボールを持っている人を担当者に設定する
  • 完了基準を決める
  • その他細かい設定は最初からしない

 

作業はとにかくチケットに起票。起票されていないものはやらない

Redmineにないタスクがあると、抜け漏れが発生したり、差し込みタスクが入ってきた際に優先度の判断を誤ったりする可能性があります。

Redmineから見えないタスクは作らないようにしましょう。

 

必ず、ボールを持っている人を担当者に設定する

ひとつのチケットに対して、複数の担当者が関わることがありますが、必ず「次に作業をする人」を担当者に設定するようにしましょう。

これを、チケットの主担当者を設定してずっと変更しないような運用は失敗の元です。

Remineは担当者でチケットを絞り込むことができるので、「次に作業をする人」が担当者に設定されていれば、作業者は「自分が担当者に設定されているチケットさえ見ていれば他のチケットは見る必要がない」という状態になります。

そうすれば、タスクの確認に余計な時間をとられたり、抜け漏れが発生したり、誰が何をすべきかわからない状態の放置タスクが生まれたりすることを防げます。

 

完了基準を決める

チケットがどのような状態になったら完了なのかを決めておきましょう。

責任者の確認をもって完了とするのか、作業者の判断で完了とするのか、チケット起票者の確認をもって完了とするのか等です。

これが決まっていないと、いつまでも消えない放置タスクが生まれたり、完全にタスクが終わっていないにも関わらず作業者の判断で完了にされてリストから消えてしまったりします。

 

その他細かい設定は最初からしない

Redmineは自由に色々な設定ができる分、つい組織に合わせた厳密なルールを設定してしまいがちです。

ですが、まずは全員がRedmineに慣れてもらう、親しんでもらうことが最優先。

デザインが無骨で馴染みにくいというRedmine最大の欠点も手伝って、最初の1ヶ月程度はなかなかツールに馴染めないメンバーも出てくるはずです。

そんなときに厳密で細かいルールがあると、面倒なだけで何も生み出さないツールに見えてしまい、結局元のやり方にもどってしまいます。

特に、ワークフローの設定を最初にしてはいけません。

 

もしワークフローを設定していたら、ただでさえ慣れていないメンバーが完全について来れなくなり、そっとブラウザを閉じてしまう状況に陥ることでしょう。

前述の3つのルールだけ決めて、あとは運用しながら設定を追加していくのがスムーズな導入の秘訣です。

 

コミュニケーションはChatworkやSkype等との併用がオススメ

各チケットは掲示板のようなインターフェースになっており、Redmine上でコミュニケーションをとることも可能です。

しかし冒頭でも書いた通り、コミュニケーションはChatworkやSkypeと併用するのがオススメです。

コミュニケーションもすべてRedmine上で取ろうとすると、余計なコメントで埋め尽くされ、あとから探したい情報が出てきたときに探しにくくなってしまうからです。

 

「少し話がそれますが、先ほどの打ち合わせの内容について確認です。」

 

のような会話が始まったらそのチケットはもう崩壊。

作業の中でそういったコミュニケーションが必要になるので、その場で書きたくなる気持ちはよくわかります。

しかし、チケットのコメントはあくまで作業履歴を残すために使い、その他のコミュニケーションは別のツールを併用するのがよいでしょう。

 

プロジェクトの粒度、チケットの粒度はどうする?

最低限の運用ルールを定めて導入が進んできたら、次に問題になるのがプロジェクトやチケットの粒度の問題 です。

大きすぎる粒度では管理が行き届かなくなりますし、細かすぎる粒度では手間がかかりすぎてしまって、効率化するために導入したRedmineの操作で工数が奪われてしまうという本末転倒な状態になってしまいます。

この点については、色々な人が色々な意見をもっているようで、組織によって最適な形があると思います。 ここではcoach4pmのお勧めスタイルを書いておきます。

 

プロジェクト=チーム

有期性のあるプロジェクトの場合は、そのプロジェクトをRedmine上の「プロジェクト」とすればよいのですが、自社サービス開発のような期限のないプロジェクト(それをプロジェクトと呼ぶかどうかはここでは置いておいて)の場合、プロジェクトの立て方に迷います。

プロジェクトを分けすぎるとチケットの起票に迷ったり、一覧で表示したいはずのものが分散してしまったりしますので、あまり細かくするのはNG。

そこでおすすめしたいのが、1チーム1プロジェクトでの管理です。

ひとつのチームをひとつのプロジェクトとして登録しておけば、現実世界とRedmineの世界がおおよそ一致することになり、適切なプロジェクト粒度で運用しやくなることが多いです。

 

タスク=確認者が確認する単位

この考え方はあまり言及している人がいないようなのですが、作業者の視点ではなく確認者の視点でチケットの粒度を考えると、自然に適切なチケット粒度になると考えています。

完了条件を明確にしようという内容を先ほど書きましたが、多くの場合は誰かが最終確認をすることでチケットが完了します。

確認者の確認単位でチケットを起票しておけば、完了条件とチケットの粒度が合致して上手に運用できます。

 

で、使い始めるにはどうしたらいいの・・・?

ここまで書いておいて、最後に期待を裏切るようで恐縮なのですが、Redmineはインストールの難易度が非エンジニアにとってはかなり高いです。

RedmineはRuby on railsという言語で作られており、Rubyが利用可能なサーバ上に構築する必要があります。

一度インストールしてしまえばあとのメンテナンスはそれほど手間ではないのですが、社内に1人もエンジニアがいないような組織の場合は自社で構築するのは難しいかもしれません。

 

それでも頑張って入れてみたい!

という方のために導入手順書を公開しておきますので、よろしければご活用ください。

 

Redmineインストール手順書(さくらVPS 標準OSの場合)

※今後のさらに役に立つ情報提供のために、簡単なアンケートにご協力いただけますと幸いです。なお以前アンケートにお答えいただいた方は、直接メールいただければお送りします。

 

ちなみに、ちょっと高いのでオススメかと言われると悩ましいところではあるのですが、MyRedmineというホスティングサービスもありますのでそういったサービスを検討するのもよいでしょう。

 

▼プロジェクト管理に課題を抱える非開発系プロジェクトマネージャーにはこちらの記事もオススメです▼

文系ディレクターのためのエンジニアとの仕事術

coach4pmのコーチングとは

PMBOKの活用方法

 

f:id:chitoseweb:20160211201842p:plain