Excelのプロジェクト管理は何故良くないのか

XP祭り関西2010のTiDDセッションの感想を読んでメモ。

【元ネタ】
[TiDD] BTSがチケット駆動開発に向いている理由: ソフトウェアさかば

2010-02-07 - winplusの日記

XP祭り関西2010に参加してきた - Basic

XP祭り関西2010でアジャイルとチケット駆動開発について考えてきた #xpjugkansai - Pragmatic Style

【1】2010-02-07 - winplusの日記の感想について、倉貫さんの事情は色々あると思うけど、僕の意見を一言。

(前略)
それと、倉貫さんが「Redmine でも重い」「Googleのスプレッドシートでタスク管理している」という発言に、あきぴーさんが「僕は納得していない」と。
この日に目撃したほとんど唯一の衝突だったのですが、それ以上の展開がなかったので、すごく残念でした。
倉貫さんの　Excelならダメだが Googleスプレッドシートならいいという判断の根拠と、あきぴーさんのExcelでの管理を実施したときの問題点をぶつけていただけると、興味深いお話がうかがえたのではないかと妄想。
(後略)

Excelでのプロジェクト管理は今まで随分痛い目に遭ってきた(笑)

数年前まで、障害報告票をExcelで書いて、担当者が変わるたびに印刷しては判子で承認してもらい、エビデンスを印刷してホッチキスで止めていた。
フィードバックがあるたびに、障害報告票はどんどんかさばっていくし、余白に書ききれなくなる。
それら障害報告票は、共有サーバー上で一意の障害管理IDを発行して作られる。
更に、毎朝、リーダーがExcelマクロを使って、それら障害報告票の状態を集計して、進捗管理していた。
当然、更新漏れがあったり、共有ファイルの書き込みでロックがかかったり、壊れたりする場合、それだけで進捗が分からなくなる。
現在の進捗や課題を洗い出すだけで、たくさんの開発者の労力を消耗してしまう。

又つい最近まで、仕様の不明点はExcelの課題一覧で管理していた。
それら課題を洗い出した後、顧客に回答してもらい、課題一覧に書き込む。
しかし、回答してもらったからと言って、その回答を精査すると矛盾が出たりする。
過去の回答と矛盾が無いか、今上がっている課題は誰がボールを持っているのか、Excelでは把握しづらかった。
そもそもExcelでは全文検索しづらいし、仕様が多数のExcelファイルに散在していると、逐一目で追いかけないといけない。

Excelの仕様書もそう。
つい最近までExcelの仕様書も上記の管理ファイルも構成管理していなかったため、更新されるたびに「課題一覧_yyMMdd.xls」のようなファイルがどんどん増える。
誤って更新するとどのファイルが最新なのか、自分も分からなくなる。

【2】上記の経験を通じて、Excelのプロジェクト管理には下記の問題点があると思う。
一つは、作業のステータスが把握しづらいこと。そのために、最新化や集計が難しい事。

障害報告票の内容をBTSチケットに登録すれば、いつでもBTS上で作業状態を確認できる。
TiDDの運用ルールさえ徹底できれば、いつでもチケットは最新化されているから、形式上の進捗報告は必要ない。
そして、BTSの自動集計機能を使えば、進捗だけでなく工数や品質に関するメトリクスをいくらでも出力できる。
そのメトリクスを上手に使えば、プロジェクトの意思決定をサポートできる。

BTSチケットは障害だけでなく、SW開発の一般のタスクも登録すれば、その恩恵が受けられる。
この特徴がIssue Trackingと呼ばれるものだ。
そして、問合せもチケットに登録してしまえばいい。
問合せもその状態(ステータス)が重要であり、溜まった問合せチケットを集計すれば、傾向分析にも使える。
もう一つ嬉しい利点は、RedmineやTracには全文検索機能が付属しているので、過去の問合せの履歴を簡単に検索できる点もある。

もう一つは、Excelファイルがバージョンアップしていくものか、そのプロジェクト1回限りのものなのか、区別していない事。

ファイル名に日付を入れて更新するものは基本は、構成管理の対象であるべきだ。
特にExcelの仕様書は、たとえバイナリファイルであろうとも、SVNの配下に入れれば、過去の履歴をさかのぼる事ができる。又、TortoiseSVNの差分比較機能を使えば、Excelでも差分比較できる。
つまり、Excelの仕様書はソースと同じく、システムが生きている限りバージョンアップしていくべきなのだ。

逆に、そのプロジェクト1回限りのExcelファイルはBTSのチケットやWikiなどでWeb化すればいい。
例えば、Excelの課題一覧は、BTSチケットで管理すべき対象なのだ。
そうすれば、BTSの優れたプロジェクト管理機能のおかげで、進捗情報や作業履歴を簡単に管理できる。

そして、SCMにコミットする時にチケットNoを必ず書き込むルールを徹底すれば、仕様書もソースと同じく、成果物の変更をチケットと紐づけることができる。
これはまちゅさんは「No Ticket, No Commit!」と呼んでいる運用ルール。
このルールのおかげで、要件からビルドモジュールまでのトレーサビリティが実現でき、運用保守フェーズでリバースエンジニアリングする時に大いに役立つ。

上記の経験を通じて、Excelで管理しているプロセスは全てIT化できると確信している。
実際、我々が受託開発で顧客に提供しているWebシステムは、顧客がExcelを使っている業務を狙い打ちにしているからだ。

TiDDセッションでは、インパクトを与えられたと思うけど、聴衆からのフィードバックや議論ができる環境にすれば良かったなと思う。
今後の反省として生かしたい。