2008年01月08日
ソフトウェア開発の制作進行ツール
わたしはソフトウェア開発会社に勤めています。
立場は制作進行となります。
そこで使っている管理ツールについての不満と解決策と
ちょっとの絶望とでもあきらめないのとを紹介します。
制作進行係の作業内容:
1. お客さまのご要望とバグ報告と新機能の要求とをまとめる
2. 作業の優先順位をつける
3. エンジニアに上記を報告
4. エンジニアから終了報告を受けたタスクの内容確認
5. お客様へ新しいバージョンをリリース
このために職場では以下の管理ツールを使っています。
* スケジュール管理 ( 例: Microsoft Project )
* バグ管理 ( 例: Bugzilla )
うちの会社では上記目的にそれぞれ商用の製品を使っています。
社内事項なので詳細は省きますが、とにかく使っていて楽しくない。
記入必須の項目が多くて、そのために情報の一覧性が低い。
タスクやバグの一件一件に細かい情報を詰め込めるのですが、
全体としてどういう状況にあるのかがわかりにくい。
バグが 100 件残っていて、それぞれに優先度がつけられて、
それぞれに期日がつけられているけど、それらがどういう
意味をもつのか、把握しづらい。
もっと嫌なことは、バグの修正予定を別のソフト、
スケジュール管理ソフトにも記入しなければならないこと。
良いエンジニアは重複した作業を嫌うものです。
他人に管理されるために自分のスケジュールを逐一記入するなど、
ギークなひとにはがまんできないでしょう。
プロジェクト管理ソフトへの不満は様々なエンジニアのひとたちから
聞かされました。
もっとうまい方法はないのだろうかと調査して、
Redmine を試すことにしました。
* Remine
* Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう！
このソフトの良いところはスケジュール管理と
バグ管理との両方をいちどにできること。
バグを記入した日がそのタスクの開始日となります。
終了予定日を記入すれば、プロジェクトの全体俯瞰図である
ガントチャートとカレンダーとに自動で表示されます。
これを見れば、何件ほどのバグが残っていて、締め切りが
近いものがどれか、図でわかります。
とくにガントチャートがありがたい。
バグのリストが左側へ縦に並び、右側が各月を示すタイムラインに
なっています。先に記した開始日と終了予定日とをつなぐ棒が
バグごとに表示され、進展を示す青色と未遂を示す赤色とで
各バグの進捗を表示できます。
Redmine: Main Feature: Gantt Chart
締め切りが近いのに真っ赤な棒が並んでいれば戦慄しますし、
おなじ時期に締め切りが集中していれば前後にずらす
ことも検討できます。
ガントチャートがなくても、バグの表だけでもおなじ情報は
得られるのですが、見やすい図を使ったほうが思考が
はかどります。
さらに Redmine のすばらしいところは、エンジニア側の
管理ツールとも連携できること。
* バージョン管理 ( 例: Subversion, CVS )
バグを修正したソースコードをサーバへコミットするとき、
特定のキーワードとバグ番号とをつけておけば、
Redmine サーバが自動でバグの状態を「完了」に
変えてくれます。
さきほどエンジニアは重複作業が嫌いと書きました。
バグ対策の報告もめんどくさいのです。
コミットするときにログを残すなら、バグ報告は
二度手間です。
文芸プログラミング的に言えば、
ドキュメントはソースに近いところに置くほうが良い。
よって、バグ管理ツールに記入するより、
コミットログに詳細を記述するほうがましです。
エンジニアにとってコミットは誇らしき成果ですが、
修正レポートは余分な作業です。レポートせずに
済むなら、それにこしたことはありません。
Redmine と Subversion とを連携させれば、
エンジニアの余計な作業をさらに削減できます。
この環境が整備できれば、エンジニアのしごとの流れは
以下のようになります。
1. バグ報告から優先度が最高のものを解決
2. コミットログにバグ番号と修正内容とを記述
3. つぎに優先度が高いものを手がける
4. バグがむずかしく、終了予定日に間に合わないときは
制作進行に連絡
5. 後回しで良いなら、つぎの優先度のバグに対応
6. 後回しできないなら
6a. 締め切り日の延長
6b. 回避策を提案
6c. ほかのエンジニアに助けてもらう
制作進行側のしごとの流れ:
1. お客様の報告をタスクに分割してリストに登録
2. 各タスクの優先度と終了希望日とを設定
3. エンジニア側のマネージャに報告
4. エンジニアから間に合わないと連絡を受けたときの対応
4a. 後回しにできるか
4b. 回避策が受け入れ可能か
4c. 他のエンジニアに助けを求めるか
( そのエンジニアが担当するタスクのスケジュール変更も必要 )
5. タスク終了や新しい依頼を受けるたびにタスクリスト更新
このようにエンジニアと製作進行とで役割を切り分け、
エンジニアの雑用を減らすことを目標にしたツールを導入したい
ものです。ここまでシンプルにできればエンジニアは、
テトリスで次々と降ってくるブロックを退治するように、
ひたすらバグを潰したり新しい機能を作ったりすることに
専念できます。
制作進行としては、エンジニアが成果を上げてくれれば
自分のしごともそれだけ楽になります。お客さまとの折衝や
タスク優先度の設定も楽しくなってきます。
みんなが楽しくはたらければ、生産性も高まります。
しごとは毎日のことですから、気持ちよくはたらけることは
それだけで資産ですね。
そのために Redmine と Subversion とを組み合わせた
システムを構築できないかと試しています。
と、ここまでが理想物語。
とは言え、なのですね。
仮に理想的なシステムをインストールできたとしても、
簡単には導入できません。
* 人は変化を嫌う
* 新しいことを覚えるには体力と時間とが必要
* あたらしいことは誤解される可能性が高い
* 導入前に最善の策はわからない
* 修正せずにそのまま使えるツールは少ない
* ツールの機能を覚えることと日常の業務になじませることとは別段階
やってみないとわからないことは多いが、
わからないならやりたくないというひとが多い。
新しい方法を試行する労力より今の不便を受け入れるひとが多い。
こういった管理ツールはひとりだけ使っても無意味で、
みなが共有しなければ価値がない。
ひとりを説得することはかんたんでも、
50 人の説得はむずかしい。
という具合に、ツールの調査や調整よりも、
人間を動かすほうがたいへんなのですね。
でも道はあります。
50 人を説得することは長い道のりでしょうが、
49 人が味方になれば最後の 1 人の説得は簡単です。
影響力のあるひとを味方につければ、
どっちつかずのひとをたやすく引き込めます。
この場合は上司や技術リーダーですね。
わたしはまだ入社して日が浅いので、
まずは、だれが影響力があって、
だれが話を聞いてくれるかを
見極めていこうと思います。
立場は制作進行となります。
そこで使っている管理ツールについての不満と解決策と
ちょっとの絶望とでもあきらめないのとを紹介します。
制作進行係の作業内容:
1. お客さまのご要望とバグ報告と新機能の要求とをまとめる
2. 作業の優先順位をつける
3. エンジニアに上記を報告
4. エンジニアから終了報告を受けたタスクの内容確認
5. お客様へ新しいバージョンをリリース
このために職場では以下の管理ツールを使っています。
* スケジュール管理 ( 例: Microsoft Project )
* バグ管理 ( 例: Bugzilla )
うちの会社では上記目的にそれぞれ商用の製品を使っています。
社内事項なので詳細は省きますが、とにかく使っていて楽しくない。
記入必須の項目が多くて、そのために情報の一覧性が低い。
タスクやバグの一件一件に細かい情報を詰め込めるのですが、
全体としてどういう状況にあるのかがわかりにくい。
バグが 100 件残っていて、それぞれに優先度がつけられて、
それぞれに期日がつけられているけど、それらがどういう
意味をもつのか、把握しづらい。
もっと嫌なことは、バグの修正予定を別のソフト、
スケジュール管理ソフトにも記入しなければならないこと。
良いエンジニアは重複した作業を嫌うものです。
他人に管理されるために自分のスケジュールを逐一記入するなど、
ギークなひとにはがまんできないでしょう。
プロジェクト管理ソフトへの不満は様々なエンジニアのひとたちから
聞かされました。
もっとうまい方法はないのだろうかと調査して、
Redmine を試すことにしました。
* Remine
* Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう！
このソフトの良いところはスケジュール管理と
バグ管理との両方をいちどにできること。
バグを記入した日がそのタスクの開始日となります。
終了予定日を記入すれば、プロジェクトの全体俯瞰図である
ガントチャートとカレンダーとに自動で表示されます。
これを見れば、何件ほどのバグが残っていて、締め切りが
近いものがどれか、図でわかります。
とくにガントチャートがありがたい。
バグのリストが左側へ縦に並び、右側が各月を示すタイムラインに
なっています。先に記した開始日と終了予定日とをつなぐ棒が
バグごとに表示され、進展を示す青色と未遂を示す赤色とで
各バグの進捗を表示できます。
締め切りが近いのに真っ赤な棒が並んでいれば戦慄しますし、
おなじ時期に締め切りが集中していれば前後にずらす
ことも検討できます。
ガントチャートがなくても、バグの表だけでもおなじ情報は
得られるのですが、見やすい図を使ったほうが思考が
はかどります。
さらに Redmine のすばらしいところは、エンジニア側の
管理ツールとも連携できること。
* バージョン管理 ( 例: Subversion, CVS )
バグを修正したソースコードをサーバへコミットするとき、
特定のキーワードとバグ番号とをつけておけば、
Redmine サーバが自動でバグの状態を「完了」に
変えてくれます。
さきほどエンジニアは重複作業が嫌いと書きました。
バグ対策の報告もめんどくさいのです。
コミットするときにログを残すなら、バグ報告は
二度手間です。
文芸プログラミング的に言えば、
ドキュメントはソースに近いところに置くほうが良い。
よって、バグ管理ツールに記入するより、
コミットログに詳細を記述するほうがましです。
エンジニアにとってコミットは誇らしき成果ですが、
修正レポートは余分な作業です。レポートせずに
済むなら、それにこしたことはありません。
Redmine と Subversion とを連携させれば、
エンジニアの余計な作業をさらに削減できます。
この環境が整備できれば、エンジニアのしごとの流れは
以下のようになります。
1. バグ報告から優先度が最高のものを解決
2. コミットログにバグ番号と修正内容とを記述
3. つぎに優先度が高いものを手がける
4. バグがむずかしく、終了予定日に間に合わないときは
制作進行に連絡
5. 後回しで良いなら、つぎの優先度のバグに対応
6. 後回しできないなら
6a. 締め切り日の延長
6b. 回避策を提案
6c. ほかのエンジニアに助けてもらう
制作進行側のしごとの流れ:
1. お客様の報告をタスクに分割してリストに登録
2. 各タスクの優先度と終了希望日とを設定
3. エンジニア側のマネージャに報告
4. エンジニアから間に合わないと連絡を受けたときの対応
4a. 後回しにできるか
4b. 回避策が受け入れ可能か
4c. 他のエンジニアに助けを求めるか
( そのエンジニアが担当するタスクのスケジュール変更も必要 )
5. タスク終了や新しい依頼を受けるたびにタスクリスト更新
このようにエンジニアと製作進行とで役割を切り分け、
エンジニアの雑用を減らすことを目標にしたツールを導入したい
ものです。ここまでシンプルにできればエンジニアは、
テトリスで次々と降ってくるブロックを退治するように、
ひたすらバグを潰したり新しい機能を作ったりすることに
専念できます。
制作進行としては、エンジニアが成果を上げてくれれば
自分のしごともそれだけ楽になります。お客さまとの折衝や
タスク優先度の設定も楽しくなってきます。
みんなが楽しくはたらければ、生産性も高まります。
しごとは毎日のことですから、気持ちよくはたらけることは
それだけで資産ですね。
そのために Redmine と Subversion とを組み合わせた
システムを構築できないかと試しています。
と、ここまでが理想物語。
とは言え、なのですね。
仮に理想的なシステムをインストールできたとしても、
簡単には導入できません。
* 人は変化を嫌う
* 新しいことを覚えるには体力と時間とが必要
* あたらしいことは誤解される可能性が高い
* 導入前に最善の策はわからない
* 修正せずにそのまま使えるツールは少ない
* ツールの機能を覚えることと日常の業務になじませることとは別段階
やってみないとわからないことは多いが、
わからないならやりたくないというひとが多い。
新しい方法を試行する労力より今の不便を受け入れるひとが多い。
こういった管理ツールはひとりだけ使っても無意味で、
みなが共有しなければ価値がない。
ひとりを説得することはかんたんでも、
50 人の説得はむずかしい。
という具合に、ツールの調査や調整よりも、
人間を動かすほうがたいへんなのですね。
でも道はあります。
50 人を説得することは長い道のりでしょうが、
49 人が味方になれば最後の 1 人の説得は簡単です。
影響力のあるひとを味方につければ、
どっちつかずのひとをたやすく引き込めます。
この場合は上司や技術リーダーですね。
わたしはまだ入社して日が浅いので、
まずは、だれが影響力があって、
だれが話を聞いてくれるかを
見極めていこうと思います。
