差分

バージョン管理についての考察。」

開発中のシステムに、バージョン管理の機能を追加することは、最初からアイデアとして持っていたのだが、人によってバージョン管理に期待するものが違ったりするため、どんな仕様にするべきか決めかねている。

実際のプロジェクトを振り返った時、バージョン管理ツールを導入しているからと言って、バージョン管理をしていることにはならないと思うのだが、改まってバージョン管理とは何か? いったい何を目的としているのか? を明確にしようとすると、けっこう難しい。

  1. バージョンの復元
    1. 古いバージョンのものを取り出したい。
  2. 変更内容の確認
    1. 変更前と変更後を見比べて確認したい。
  3. 変更理由の把握
    1. 障害対応なのか、追加要求への対応なのかを把握したい。
  4. 変更の通知
    1. 他の誰かが変更したとか、どのファイルを変更したなど、変更された事実を把握したい。
  5. 実装までのトレース
    1. 例えば、要件の変更があった時に、設計、実装、テストまでの変更が実施されたかどうかを確認したい。
  6. 影響範囲の把握
    1. A の機能を変えたら、B の結果が変わるなど、多機能への影響を事前に知りたい。
  7. 対応バージョンの把握
    1. 機能 A のバージョン 1.2 は、機能 B のバージョン 2.4 を前提にしているなど。
  8. 実績把握
    1. 昨日と今日でどれだけ変わったのか? 担当者 A の昨日の作業量は? などを知りたい。

思いつくのはこんなところか…。トラッキングや構成管理など、別の名前が付いているものもあるけれども、厳密に責任分解点を意識している人は少なく、一般的にはなんでもかんでもバージョン管理に含められているのが実情だと実感している。もしかしたら、いろいろ含めた集合名詞と考えるのが妥当なのかもしれないが、そのあたりが明確になるには、もう少し時代の流れが必要なようだ。

それはともかく、問題は自分が実現する機能だ。ところが、初っぱなから躓いている。本当に必要なものが何か? あるいは必要なものの優先順位はどうなるのかが、なかなか思考がまとまらない。実現できるところから実現する手もあるのだが、どこから実現して行くかは別の話として概念をまとめたいと思っている。バージョン管理の名の下に、残す必要のないものまでとにかくすべて残して、情報の混乱を招く人もいたから、「そうぢゃなくって、バージョン管理ってゆーのは…」と説明できることが大切だと思うからだ。

"サルでも分かるバージョン管理"、"バージョン管理の本質" なんてゆー文章があれば、楽なんだが…。