プロジェクトオーガナイザの吉田聖書です。
プロジェクトの成果物にはドキュメントが必ず含まれます。
今回は久しぶりにドキュメントの話をしようと思います。
ソフトウェアのバージョン管理については
割とどこでも浸透してきていると感じますが、
一方でドキュメントの版管理（バージョン管理）
特にバージョン番号の付け方については
なかなかルール化できていない現場が多いと思います。
例えば、取引先から提示されるドキュメントが、
バージョン1.1、1.2と続いてたのに、
次は急に1.5になったとか。
バージョン0.9の次が0.91になったり、0.99の次が0.991になったり
それなりに苦心している様子が伺えます。
（もしかしたら何も考えてないだけかもしれませんが）
単純にバージョンが上がったということを伝えたいのであれば、
素直に連番にすればよいと思いますし、
実際そのようなルールも見かけます。
でも、細かく番号を付けようと決めたからには、
その「意味」を定義したいものです。
BOXなどのドキュメント共有基盤を利用すると、
同じ名前のファイルをアップロードすれば
自然にバージョン番号が上がっていきます。
しかし、番号は連番でありそれ自体に意味はありません。
ソフトウェアのバージョン番号体系に意味を持たせようという考え方を
セマンティック・バージョニング（Semantic Versioning）と言い、
その提唱された仕様についてWebで公開されています。
https://semver.org/lang/ja/
端的に言うと「x.y.z」という形式のバージョン番号を付与し、
- x. 互換性のない変更を行った場合にカウントアップ
- y. 互換性はあるが機能が追加された場合にカウントアップ（xが上がったら0にリセット）
- z. 互換性を伴うデバッグなどの場合にカウントアップ（xかyが上がったら0にリセット）
というルールで番号を付けます。
これをドキュメントの版番号にも応用してはどうかと考えています。
具体的なルールは各プロジェクトで決めるべきことですが、
実際に試したものも含めていくつかアイデアを紹介します。
前提として、何かしらの資源管理システムが導入され、
少なくとも履歴は管理されているものとします。
そのような仕組がない場合は、
まずそこから検討されることをお奨めします。
このルールを考える上で、
いくつか例を挙げてみたいと思います。
例えば、タイミングを基準にすると
こんなルールが考えられます。
- x. 組織外からの指摘による変更
- y. 組織内からの指摘による変更
- z. 自発的な変更
または、
- x. 顧客への納品
- y. 顧客からの指摘による変更
- z. 自発的な、または内部での指摘による変更
変更の影響度を基準とした場合は
こんなルールが考えられます。
- x. 要求事項の変更あるいは追加
- y. 要求は変わらないが、内容の改善
- z. 内容は変わらないが、誤字脱字や体裁の修正
このようなルールを決めることによって、
バージョン番号を見ただけで、
自分がどの程度その変更を気にしなければいけないかを
ある程度判断することができます。
番号に意味付けができれば、
後から履歴を辿る際にも
比較的すぐにバージョンを特定することができ
作業効率も上がります。
少し本題から外れますが、
仮にx.yという形式のバージョン番号を採用する場合、
これは小数だと考えない方が良いと思います。
小数の場合、例えば「0.8」「0.9」の次は「1.0」になりますが、
まだ「1.0」に上げたくないと考えると
「0.91」のような苦肉の策に出なければいけなくなります。
「0.1」上がるのに比べて「0.01」上がるのは
変更が小さいからではないかと誤認しがちです。
ここはx.y.z形式の応用で、
「0.9」の次は「0.10」「0.11」のように
小数ではなく文字列として扱えば
バージョン番号として全く違和感はないと思います。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。