開発プロジェクトの教材としてTracを使ってみた
新人君が配属されたので、ソフトウェア開発現場でどのような形で作業を行っているのか説明するために、昨年の開発プロジェクトで実際に使用したTracを使ってみた。普通はプロジェクト完了報告書などの資料を参照するのかも知れないけれど、これはあくまでも結果論なので、開発当時の雰囲気などがなかなか分かりにくい。代わりに仕様書の山や打合せの議事録を見せても断片情報でしかないので、それらが相互にどう結びついているのか、これも理解しにくい。
今回、Tracを使ったのは、これらの情報が時系列で記載されており、しかも互いにリンクされているので相互関係が明確になっているからだ。例えば「一つの障害（チケット）を発端にして、打合せを行って方針の検討を行い（議事録）、ソースコードの修正を行った（コミットログ）」という一連の流れを辿ることが容易で、非常に分かりやすい。仕様書や障害管理と言った縦割りな情報も必要だけど、このような実作業的に基づく横断的な流れとして捉えると、プロジェクトの中身がより理解しやすいように思う。
そのために、色々な視点でプロジェクトを捉えることが出来て、しかもそれらが相互に関係している点を説明。具体的にはこんなものがある。
- マイルストーン
問題点だけではなく、チケット駆動開発として作業項目を割り振っているので、いつ誰がどのような作業を行っていたのか、プロジェクト全体の流れが理解出来る。全体像の把握には欠かせない。 - 議事録
開発の進捗状況や問題点の検討、仕様変更や開発体制の見直しなど、いつどのような項目を検討し、何を決定したのか意志決定の経緯が分かる。 - 仕様書
完成した仕様書だけではなく、仕様変更や追加の理由として打合せ議事録やチケットへのリンクが付記されているので、仕様の背景や最終的な形に至るまでの変遷が分かる。 - チケット
開発時にどのような障害が発生し、どう対処したのか（或いはしなかったのか）、そこから得られる教訓は何だったのか失敗事例として参考になる。 - コミットログ
何を目的としてどのようなコードをどの位追加、変更していったのか、時系列やファイル単位で追っていくと、実は障害は偏在することが一目瞭然だったりする。
様々な視点で開発プロジェクトを捉え、それらを縦横無尽に辿っていくことにより、教科書に載っているような「綺麗ごと」の開発ではなく、より現場に近い形での疑似体験が出来る。開発当時の裏話も交えつつ、「この仕様変更は結局失敗で...」等と説明すると、居眠りする人もなく研修は盛り上がるようようだ
関連
