ALM Advent Calendar 2012 ツールを使わなかった、あるシステムのライフサイクル
ALM Advent Calendar 2012 #TFSUG : ATND 6日目のエントリです。
@kaji_3 こと、かじです。SIerでエンジニアしてます。
いつもは技術系ですがALMということで今回は趣向を変えて、ツールを使わなかったとあるシステムのライフサイクルを振り返りつつ、どうあるべきだったか考えてみようと思います。
誕生
とある業務システム。本番運用開始と同時に新規開発での多発する仕様変更と品質の問題に疲弊したメンバーがリタイヤした現場。
稼働直後にプロジェクトへアサインされた訳ですが色々な課題がありました。
バージョン管理されていないソース、設計書
VSSが存在していましたがテストが完了したものから管理台帳に記載してVSSにチェックインするという謎ルールでした。
ビルドサーバがない
「yy.dll」「xx.exe」が50個。常に最新のソースでビルドしなくては危険極まりないのにビルドサーバが存在せず、うっかり古いソースでビルドしてデグレ発生という事故を防ぎたい所ですが専用機がありません。
要望、課題、不具合の管理台帳がない。
バックログは大小100近くありました。一つのバックログはテキストファイルや変更要望書という形で単独で存在しており、まとまったものはありませんでした。
新規開発直後は人員も多く人力で品質、ミスを防いでいるかもしれませんが人数が減るとどうしても手薄になるのですぐに自動化、ツールの導入をした方がいいです。私は知識と権限の不足からどの課題にも何も対応せず運用していましたが、どの課題についても一度は障害を伴った事故を発生させ、ビルドサーバ、管理台帳を顧客と調整し作ることになりました。
青年期
3年が経過しました。大規模な改修を半年に一回。計6回実施。顧客も保守メンバーも慣れてきました。そしてシステムも安定稼働し、顧客にも余裕が産まれて改善が始まりました。
過去バックログの「実績工数」
過去の保守開発のどのバックログにどの程度の規模対応したかを参照し、新しい保守開発の工数見積をするよう顧客から要望がでました。過去の保守案件は「参考」程度にはしていましたが、トータルでどれだけのコストだったかのみしか記録していない事、個々のバックログに対してどの程度コストがかかったかが記録されていなかった事から実績からの見積はできませんでした。
（TFS2012ではタスクに実績時間をつける項目はないのでカスタマイズする必要があります）
バックログと改修範囲のトレーサビリティ
業務のルールも満遍なく改修される事はなく、集中的に改修が入る箇所は決まってきます。そしてバックログの種類によって影響範囲も決まってきます。この影響範囲をベンダーの調査工数削減のため、過去保守案件の実績から見える化をする要望が出てきました。
各種台帳の肥大化
課題管理台帳のレコード件数が1000を越え、インシデントを管理していた別の台帳も2000件ぐらいになってました。Excelで1000件を越える行数ファイルではとても作業になりません。
実績工数は概算になり、トレーサビリティは記録しておらず、台帳だけはAccessにツールに変更しました。この時点でTFSを知っていたらコストがかかっていても移行しましょう！と顧客に提案していたかもしれませんが運用手順も固まっていて移行コストは大きかったのではないかと思っています。
晩年期の課題
更に年月が経ちついに再構築の話が出てきました。初期メンバーは全て抜けて再構築時の事を知らないメンバーのみとなりました。
長年運用しての課題が人の記憶にしか残っていない
課題台帳はレコードが大きすぎるという事から、顧客リーダー変更時に一度破棄されました。その結果長年付き合ってくれたメンバーの中だけにシステム運用時の課題、設計上の歪みが残る事になり新システムには反映されませんでした。
時間の経過で発生する課題に対応するために
正直ツールではなくプロジェクトの運用がよろしくなかったと思っています。しかし、TFSを入れていたら変わっていた「かも」しれません。目的があってのツールですが未熟なプロジェクトならツールの背景にある思想を学ぶことで良いプロセスになる事もあるのではないのでしょうか。TFSやALMの思想について聞いて「いいかも」と思ったら勉強しつつ導入してみてはいかがでしょう。
