概要設計工程でRedmine導入してみた事例
やっぱり事例だよねということで、自分とこの事例をまとめてみる。
お仕事の概要
- 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。
- 期間 => 2ヶ月
- メンバー => 3~4名。自分込み。
- 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。
- 概要設計に先立ち、要件定義は完了。30項目ほど。
- 滝。
Redmineの設定など
- 「概要設計」をバージョンとして作成。
- 30項目の要件をチケットとして登録。
- ターゲットバージョン => 「概要設計」
- 開始日 => 登録したその日
- 期限日 => 概要設計完了予定日の2w前
- 予定工数 => それぞれの見積もり値を設定
- 担当者 => 設定しない
- ユーザの権限は全て「管理者」。
- 5名程度なら問題ないんじゃないの？
- チケットのフロー
- 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了
運用方法
- タスクの割り振り
- それぞれが、自分がやりたい要件を自分で選ぶルールにした。
- ただ、「これは一緒にした方がいいだろー」的な要件の組み合わせは口頭で伝えて調整した。
- Subversionレポジトリと連携
- 進捗の管理
- チケットの進捗率は 0% or 100% で管理。つまり、完了するまではどんだけ時間掛けても0%。
- 少なくとも完了した時点で、経過時間を大雑把に入れるルールとした。
- 全体の進捗率は見積もり時間基準で。「全体の見積もり時間 / 完了分の見積もり時間」
- 経過時間は社内向けの進捗報告に使った。チケットのCSV出力機能で、経過時間を出力するようプチ改造。
雑感
事前にタスクを割り振らないことについて
見積もり工数は、あくまでも個人的にざっくりベース（SI用語）で出した数字なので、ズレがあるわけで。事前にタスクを割り振る場合は見積もり時間を基準にする必要があると思うけど、見積もりのズレや個々人の状態によってかなりブレるのが普通で、途中でタスクの振り直しが発生する。絶対に。ということで、全体を事前に決めず、「今からどれをやろうか」を決めながら進めるようにした。
当初、メンバーさんは「え？決めないの？」って戸惑ったようだけど、直ぐに慣れた。直ぐに、というか2日目には普通になった。
計画を作る場面でパズルを組むように線を引く労力がなくなり、状況によってタスクを切り替える労力もなくなった。
ある程度のプレッシャーがあった方が早く終わるんじゃないか、日付的なプレッシャーがないと遅れ放題じゃないかという心配もあったが（いや本当はそんな心配してないんだけど、そういうことにしておく）、少なくとも不自然に遅れることはなかった。他のプロジェクトに時間を取られたメンバーもいたが、それは仕方がない。
進捗を管理する場面でも、個人に対して「なぜ計画より遅れているのか？」なんて尋問する必要がなくなった（「どこで悩んでいるのか」と尋ねるようになった）。ついでに「なぜ遅れてるって、見積もりが腐ってるからですよ」などと問い詰められる心配もなくなったw。進捗管理は完了タスクの確認と全体の完了率、そして「次に何をやるべきか」に集中でき、15分程度の打ち合わせで十分だった。通常のプロジェクトなら90分は掛けてるね。
結果として、全体的に遅れなく、負担なく、かつ好評のなかで進めることができた。……はず。
RedmineとSVNとの連携について
当初、Redmine側の設定の不備により、Redmineからレポジトリが見えないという状態になっていた。が、それはいずれ解消されるだろうという楽観的予測の元、SVN側にはIssueIDを登録していった。
結果、レビューや成果物の確認の際にIssueIDで検索することができて、事後の確認がかなり簡単になった。効果としてはこれだけでも十分ありがたい。かなり後でRedmineの設定に成功したが、Redmine上からはあまり見ていない。TortoiseSVNだけで十分かなーという感じ。
見積もり時間基準の進捗率について
要件にして30項目だけど、数時間〜100時間超えまで、粒度がバラバラだったので、チケット数基準の進捗率は全く無意味。ということで、見積もり時間をベースに全体の進捗率を計測していった。ってか、バーンダウンチャートを作った。見積もり「時間」を見積もり「ポイント」に読み替えた、という認識です。
全体の進捗率がいつでも直ぐに計算できたのが最大の利点だった。「今どれくらい？」「えっと、65%終わってます」みたいな。チケットをCSVで出力してExcelで開き、手で出していたので、Redmine上で確認できるように改造しても良かったかもしれない。バージョンの画面だと、全体の予定時間と経過時間しかでないんだよね。完了分の予定時間を出すだけの簡単なお仕事。
もう一つ良くない点を挙げるとすると、100時間越えのタスクを後半に抱えてしまったので、安定性に欠く面があった。各人がタスクを決める場面に、もう少し工夫の余地はあるといえばある。
チケットのフローについて
レビュアーとして、各担当者が「作成済」としたチケットをチェックしてレビューすればよい。ということで、チケット画面で「概要設計で作成済みのもの」という検索条件を保存した。TODOリストのような感覚で使えたので、これはよかった。
ついでに、
- 「概要設計で担当者未定」
- 「概要設計で未完了」
- 「概要設計で今週完了した」
- 「概要設計の全て」
などの検索条件を公開状態で保存した。名前は上の通り、決めやすくて読みやすいので、今後もこうすると思う。
レビューは、基本的には作成したドキュメントの確認のみ、意図が分かりづらいときに直接聞くスタイルにした。だって、オフショアさんはドキュメントしか読まないしね。指摘事項や不明点は、チケットのコメントとして箇条書き記法で残しておくことで、レビュー済みの通知を兼ねることができた。チケットの更新通知としてメール送るでしょ、あれ便利。
対外的な品質管理報告用として、チケットの属性に「レビュー指摘件数」を追加し、レビューコメントのうち明確な指摘事項のみ件数を数え、記録した。ちなみに、レビュー観点として「誤字・脱字」は重視してないです。意図が伝わるか、設計としてシンプルか、既存機能と分離できているか等が主な観点なので、いわゆる品質管理とは相性は悪いです。結果、品質基準の200%超の指摘事項が出て、観点は違うわ件数は尋常じゃないわ、ありゃ正直困った。けど所詮は数値上のことなので、何故か問題なしで報告できます。魔法の力。
欠点は、再レビューが明示的ではない点。作成済 -> レビュー済 -> 完了の流れは、口頭で「あー、完了でいいよ」みたいな感じだった。ただ、再レビューまでフローに組み込むと無駄に複雑化しそうな気がする。この辺は今後の課題かも。まぁ実際は、複雑な要件ほど細かく内容を確認していったので、この辺の流れはそんなに厳格には管理していなかった。簡単な要件に対してTODOリストとして機能しただけで十分に使えたので、良しとしていいかも知れない。
まとめ
けっこう役に立ったよ、というお話でした。
ただ、インタフェースとしてもっさりしてる上に（プラグインとか入れない限り）一括登録・更新できないので、これ以上ガチガチに管理しようとする場合にはお勧めできない。入力の手間が増えて、何のお仕事をしてるかわからなくなると思う。そんなのやりたくないw
結果的に遅れなく期限内に終わったわけだけど、これは仕事自体が大きく減ったお陰でもあるわけで、 Redmine 導入の効果とすぐに結びつけられるというわけじゃない点は注意が必要ではある。締め切りまでに終わるか終わらんかは、プロセスに直接関係しないよな。
あと、この記事は10月の情報処理技術者試験の練習にもなるなーということを途中から思い付いたので、こんな記事になってます。ご了承ください。って、こんなんじゃ受からねぇなw
