プロジェクト管理ツールを導入させるためのあてつけがましいアプローチ

# はじめに
プロジェクトの遂行には、もはやプロジェクト管理ツールは欠かせないものだと個人的には考えています。
しかしながら、Excelによる管理が未だに行われている現場も少なくない印象です。
そういった現場では、さまざまな理由(サーバーが立てられない、絶対Excelマンの存在など)により、ツールの導入をあきらめざるを得ないことも多いかと思います。

でも考えてみてください、人生は一度きりです。酷な作業環境に甘んじるより、なんとかして快適な環境にしたほうが建設的ですし、メンバーの幸せの総計は増えるはずです。

この記事では、困難な現場でプロジェクト管理ツールを導入させるための手段として、ステークホルダに対してあてつけがましいドキュメントを突き付けるアプローチを提案してみます。

## どんなドキュメントか
今抱えている問題と、それを放置することのリスク、そしてどうすれば解消できるのかを示したものが良いでしょう。
以下はポイントになります。

### 体裁の整った手間の掛かっている風のドキュメントにする
簡単なものでは読んでもらえない可能性があります。内容の良し悪しより、まずは見た目を良くして手間が掛かっていることを印象付けましょう。そうすれば無下にはできないはずです。~~Excelで作るとポイント高いです。~~

### 現状を褒める
ステークホルダはツールがなくても何とかなっていると信じていますし、ある意味それは正しいです。ひとまずは現状を褒めましょう。より良い状態を知らないのですから、今が良くない状態だと気づくことはできません。

### 危険を煽る
あまり良いことではないかもしれませんが、この際、手段を選んではいけません。ツールがない場合に起こりうる、思いつく限りのリスクを列挙しましょう。危機感の醸成は重要です。~~ステークホルダが最も嫌がる事柄を挙げるとポイント高いです。~~

### 巨人の肩に乗る
自分の意見だけでは押しが弱いです。ツールを導入することのメリット/導入しない場合のデメリットなどを説いた、先人の知見を引用して権威付けしましょう。誰しも権威には弱いものです。

### 誰でも見られる場所に置く
多くの人の目に晒される場所に置きましょう。第三者の目に触れるような状況におけば、無視することは難しくなるはずです。場合によって協力者が獲得できるかもしれません。

このような点を盛り込んだドキュメントを用意し、ステークホルダに叩きつけましょう。

## 言うは易し、行うは難し
あおるだけあおって具体例を示さないのは無責任なので、過去に私が叩きつけたドキュメントを、内容がしょぼくて恥ずかしいですが、参考までにさらします。

以下は注意点になります。

* 効果の程は実際のところ不明
* 数年前の取り組みなので情報が古い
* 後半に行くほど気力が減って尻すぼみ
* 最初からRedmineにする気なので他のツールはかませ犬

# 参考

## 背景・目的
200X年初頭からスタートしたhogehoge保守開発は、X/Xに第一弾リリースを終え、軽微な不具合は発生したものの概ね良好な結果となった。
X月に第二弾リリースを未だ控えてはいるが、進捗・課題消化共に遅れはなく、順当な結果が得られる見通しとなっている。
しかし、プロジェクトをここまで進めていく上で幾つかの問題が発生しており、今後の保守開発も滞りなく遂行していく為には、それら問題の解消は不可避であると考えます。
そこで、現在抱えている問題点を洗い出し、それらの解決に必要十分な機能を備えたプロジェクト管理ツールを選定・導入することにより、品質・管理・生産性の向上を目指したい。

## 現状の問題点
現在抱えている問題点、あるいは理想などを以下に列挙する。

* 顧客からの仕様提示が遅く、期限もあまり守られないため要件がなかなか固まらない  
→いつしか忘れて放置される危険がある
* 仕様変更の頻度が高く作業が巻き戻ってしまい、現在の進捗具合を加味した新たに必要となる工数を容易に把握できない
* 仕様の確定に明確な期限がないため、実現すべき要件の全体像を捉えがたい
* 顧客からの問い合わせが多く、その応対に関する情報を記録するすべがない
* 作業進捗の記載方法がまちまちで、定まったフォーマットがない
* 正確な進捗状況を把握するためには、各担当者にヒアリングするほかなく、担当者不在の場合は把握できないこともある
* 顧客への進捗報告を簡単にしたい
* さまざまな情報がファイルサーバ上に分散しており、情報が散逸気味
* 「何がどこにある」などの連絡事項の掲載場所がグループウェアの電子掲示板しかなく、開発向けとしては機能が貧弱で実用性に乏しい。分類機能もなく、検索も不便
* 誰が何をしているなどの情報がなく、開発者間の連携が捗らない
* プロジェクトの現状を把握できる人間がリーダー1人に限定され、トラックナンバーが常に1  
→リーダーが休みを取れない
* 全体の進捗度合いをほどよい粒度で把握するすべがなく、休暇の計画が立て難い

その他、一般的なプロジェクトにおいてありがちな事象が良くまとまったページがありますので、例として掲載します。
参考ページ:[プロジェクト管理ツールの必要性](http://gihyo.jp/dev/serial/01/redmine/0001)

以下引用します。
> みなさんのプロジェクトは上手に運営できていますか？プロジェクトメンバーのタスクの進捗管理はできていますか？問題・課題管理はスムーズに行えていますか？　ExcelやWord，紙資料を用いた管理で，作業が煩雑になっていませんか？ 進捗報告ミーティング用の会議資料作成やチームメンバとの情報共有のために，大きく時間を取られていませんか？ファイルサーバには必要かどうか判断できない無駄な資料があふれかえっていませんか？ソースコードはきちんと管理されていますか？ リリース用のソースコードに，どんな機能が盛り込まれ，どんな不具合が解決したのか，ちゃんと把握できてますか？
> プロジェクトが混沌としてくると，ドキュメントやソースコードの構成管理がぼろぼろになり，プロジェクトメンバの作業の進捗具合をリーダが見通せなくなります。その結果，上記のような問いかけに対して「できている」と返事ができない状況に陥りがちです。
> プロジェクト管理ツールは，これらの問題を解決する手助けをしてくれるものです。プロジェクト管理ツールを導入すると，アプリケーションの問題・課題や不具合，プロジェクト上の問題・課題，ヘルプデスクへの問い合わせや各メンバのタスクなどを「問題」（Isuue）という単位で一元的に管理し，その解決状況を追跡（Tracking）することができます。
> また，CVSやSubversionといったバージョン管理システムと連携することで，ソースコードと，それらの問題・課題・不具合・タスクに簡単に紐付けることができます。さらに，wikiによるドキュメント管理や，掲示板（フォーラム）を用いたコミュニケーション機能など，プロジェクト運営を円滑に行うための機能が盛り込まれています。
> 「そんなの導入しなくても，ExcelやWordできるよ」と言われる方もいるかもしれません。実際，これまでの開発の現場では，これらの管理はExcelやWord，紙資料で行われてきました。しかし，先も述べたように，そういった媒体での管理は作業の煩雑さから管理が破綻しがちです。
> 例えば，Excelを用いた不具合管理。Excelの資料を開いて，担当者欄に自分の名前がある部分を抜き出してから作業に取りかかるだけでもちょっとしたストレスですし，作業が完了したことを記載しようとして，ファイルを他の誰かが開いていて編集できなかったら，もしかするとその作業報告は最後までなされないかもしれません。
> 開発に関わる人間が多くなればなるほど，こうした事象は多くなると思います。
> ・・・

## 必要な対策と該当する機能
現状の問題点から、必要となる対策とその実現に対応する機能を以下にまとめる。

| No | 問題点 | 対策 | 機能 |
|---:|--------|------|------|
|  1 | 顧客からの仕様提示が遅く、期限もあまり守られないため要件がなかなか固まらない <br> →いつしか忘れて放置される危険がある | 要件、ステータス、対応者、期限を記録・更新する | タスク登録・閲覧機能 <br> ステータス管理機能 |
|  2 | 仕様変更の頻度が高く作業が巻き戻ってしまい、現在の進捗具合を加味した新たに必要となる工数を容易に把握できない | 進捗の把握を容易にする、工数の実績値を記録する | ステータス管理機能 |
|  3 | 仕様の確定に明確な期限がないため、実現すべき要件の全体像が捉えがたい | 課題も含めた要件単位のWBSを作る | タスク登録・閲覧機能 <br> ステータス管理機能 |
|  4 | 顧客からの問い合わせが多く、その応対に関する情報を記録するすべがない | 問い合わせ内容を必要に応じて記録し、ステータス管理する | ステータス管理機能 <br> メールインポート機能 |
|  5 | 作業進捗の記載方法がまちまちで、定まったフォーマットがない | 簡便に進捗を記録する方法の整備 | ステータス管理機能 |
|  6 | 正確な進捗状況を把握するためには、各担当者にヒアリングするほかなく、担当者不在の場合は把握できないこともある | 簡便に進捗を記録する方法の整備 | ステータス管理機能 |
|  7 | 顧客への進捗報告を簡単にしたい | 簡便な進捗集計方法の整備 | ステータス管理機能 <br> 集計機能 |
|  8 | さまざまな情報がファイルサーバ上に分散しており、情報が散逸気味 | 情報周知ルールの整備、簡便で高機能なコミュニケーションツールの整備 | wiki、掲示板機能 |
|  9 | 「何がどこにある」などの連絡事項の掲載場所がグループウェアの電子掲示板しかなく、開発向けとしては機能が貧弱で実用性に乏しい <br> 分類機能もなく、検索も不便 | 簡便で高機能なコミュニケーションツールの整備 | wiki、掲示板機能 |
| 10 | 誰が何をしているなどの情報がなく、開発者間の連携が捗らない | プロジェクトの状態を誰でも容易に把握できる環境の整備 | タスク登録・閲覧機能 <br> ステータス管理機能 |
| 11 | プロジェクトの現状を把握できる人間がリーダー1人に限定され、トラックナンバーが常に1 <br> →リーダーが休みを取れない | プロジェクトの状態を誰でも容易に把握できる環境の整備 | タスク登録・閲覧機能 <br> 集計機能 <br> ステータス管理機能 |
| 12 | 全体の進捗度合いを程好い粒度で把握するすべがなく、休暇の計画が立て難い | 課題も含めた要件単位のWBSを作る <br> 簡便な進捗集計方法の整備 | タスク登録・閲覧機能 <br> 集計機能 <br> ステータス管理機能 |


## 導入候補となるソフトウェア
現在、広く利用されており、導入候補と成り得るプロジェクト管理ツールを以下に示す。
※選定基準は、導入事例、情報の多さ、価格など

| 名称    | 読み方 | 有償/無償 |
|:--------|:-------------|:----:|
| Trac    | とらっく     | 無償 |
| Redmine | れっどまいん | 無償 |
| JIRA    | じら         | 有償 |


## 導入候補の比較
導入候補を機能別に比較した結果を以下に示す。

| 機能                 | Trac | Redmine | JIRA |
|:---------------------|:----:|:-------:|:----:|
| タスク登録・閲覧機能 | ○ | ○ | ○ |
| ステータス管理機能   | ○ | ○ | ○ |
| 集計機能             | △ | ○ | ○ |
| メールインポート機能 | △ | △ | ○ |
| wiki、掲示板機能     | ○ | ○ | △ |
※「△」はプラグインやアドオンにて実現可能

## 簡単な評価
導入候補毎に、デモサイトを用いて簡単に評価した結果を以下に示す。

| ソフトウェア | デモサイト | 使用感 | 機能性 | 導入コスト |
|:-------------|:---------------------------------------------------|:--:|:--:|:--:|
| Trac         | [Trac 0.10.4 にようこそ](http://trac.hln.co.jp/demo) | △ | ○ | ◎ |
| Redmine      | [Redmine デモサイト](https://my.redmine.jp/demo/) | ○ | ○ | ◎ |
| JIRA         | [Welcome to Ricksoft Sandbox JIRA!](https://www.ricksoft.jp/demo/secure/Dashboard.jspa) | △ | ○ | △ |


## 総評
ここまでの検討結果から総合的に判断し、Redmineの導入を目標として評価を継続する。

# おわりに
ここまで色々述べてきましたが、正直なところ参考で紹介している「[プロジェクト管理ツールの必要性](http://gihyo.jp/dev/serial/01/redmine/0001)」という記事の完成度が極めて高いので、これを読ませることが一番効果的かもしれません。
※書いた方、はてなの社長さんなんですね。クオリティの高さに納得です。

今は無償のツールも多く、昔にくらべ導入のハードルは下がっています。便利なものをじゃんじゃん使い、くじけることなく快適な開発を目指しましょー！