アカウント名:
パスワード:
状況がよく分からないのですが。
雛形を使って上書きが怖いならMS-Officeであればテンプレートありましたよね?テンプレートで保存するときに任意のファイル名付けられるんでMessageIDぽくしたら?これで人と時系列は何とかなるので基のファイル名をどうするかですが、これは一義的に決まると思うので。ユーザー名や日時が面倒ならVBAで補助して行けるのでは?
皆が文書の上書きを恐れ、変更結果を「念のために」少し異なる名前で保存するため同じ文書の複数のバージョンができてしまい、どれが最新バージョンなのか、どれがクライアントに送られたバージョンなのかといったことが誰にもわからない状態だ。
元がテンプレートではなく、設計書などを改版→提出する流れでそれを特定のメンバーがやらない(初版作成者ではなく手の空いた人間に作業をあてがうなど)うえ、レビューで「(不適切な修正などが原因で)元に戻せ」という指摘を受けることが多いとか、そんな感じじゃないかなーと。
主業務として文書管理をする人を置かないとツールだけでは回らないのではないでしょうか。管理者もレビューに参加してもらってOKになったらその版をブランチしてもらう、みたいに。
分岐するのならその時点で分かるように連番や命名規約を決めればよいと思います。バージョン管理システムを利用していますがソフトに全部任せるのは難しい場合も過去ありました。文書管理者の準備は予算等で難しいでしょうし、たとえ人がいても結局解決しない場合もありました。開発チームのソースやインフラチームの設定ファイル、自動化シェル等はCVSやVSS等で管理していますが設計書、パラメータシートなどのドキュメント類は結局ファイル名、ディレクトリの命名規約で回すことも検討したほうがよいかも。
昔、変愚蛮怒のセーブファイルのバックアップをとるやつ作ったっけな。rogueならともかく、規模が大きくなると、死んだらやり直しが面倒なんだよな。
分岐するのならその時点で分かるように連番や命名規約を決めればよいと思います。
まさに正論。しかし、正論で上手く行くケースばかりなら、こういうストーリーは立たないわけで。
たとえば、命名規約を守らないやつがいるとか、新規に加入したメンバーへの教育をしなければならないとか、意図的でないミスを防ぐ仕組みがないとか。
正論以前の問題として、首から上が飾りにしかならない人々の存在も無視できない。たとえば、こう言ったファイル名に基づくバージョン管理では、十分な長さのバージョン識別子が必要になる。よく見るのは、「 ○○-20150228.xlsx」とか。これが十分と言えるのは、更新頻度が1回/日を上回らないと言い切れるときのみ。こんなことは、十秒も考えれば判ることなのに、日に数回更新されるファイルに適用して破綻しているケースをよく見る。こんなのは、可読性も考慮して、「 ○○-2015-02-28-00.xlsx」くらいにしとけば、日に十回以上更新されても問題ない。しかし、彼らの思考がそういう方向に向くことはなく、同じ破綻を何度も繰り返している。
そういう人々を無視できないから、こういうストーリーが立つ、ってわけだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
勝手に… (スコア:0)
状況がよく分からないのですが。
雛形を使って上書きが怖いならMS-Officeであればテンプレートありましたよね?
テンプレートで保存するときに任意のファイル名付けられるんでMessageIDぽくしたら?
これで人と時系列は何とかなるので基のファイル名をどうするかですが、これは一義的
に決まると思うので。
ユーザー名や日時が面倒ならVBAで補助して行けるのでは?
Re: (スコア:0)
皆が文書の上書きを恐れ、変更結果を「念のために」少し異なる名前で保存するため同じ文書の複数のバージョンができてしまい、どれが最新バージョンなのか、どれがクライアントに送られたバージョンなのかといったことが誰にもわからない状態だ。
元がテンプレートではなく、設計書などを改版→提出する流れでそれを特定のメンバーがやらない(初版作成者ではなく手の空いた人間に作業をあてがうなど)うえ、レビューで「(不適切な修正などが原因で)元に戻せ」という指摘を受けることが多いとか、そんな感じじゃないかなーと。
主業務として文書管理をする人を置かないとツールだけでは回らないのではないでしょうか。
管理者もレビューに参加してもらってOKになったらその版をブランチしてもらう、みたいに。
Re:勝手に… (スコア:0)
分岐するのならその時点で分かるように連番や命名規約を決めればよいと思います。
バージョン管理システムを利用していますがソフトに全部任せるのは難しい場合も過去ありました。
文書管理者の準備は予算等で難しいでしょうし、たとえ人がいても結局解決しない場合もありました。
開発チームのソースやインフラチームの設定ファイル、自動化シェル等はCVSやVSS等で管理していますが設計書、パラメータシートなどのドキュメント類は結局ファイル名、ディレクトリの命名規約で回すことも検討したほうがよいかも。
Re:勝手に… (スコア:2)
とりあえず、どこそこのフォルダに書け!とだけ教えた。
見た目大事。
Re: (スコア:0)
昔、変愚蛮怒のセーブファイルのバックアップをとるやつ作ったっけな。
rogueならともかく、規模が大きくなると、死んだらやり直しが面倒なんだよな。
Re:勝手に… (スコア:1)
分岐するのならその時点で分かるように連番や命名規約を決めればよいと思います。
まさに正論。
しかし、正論で上手く行くケースばかりなら、こういうストーリーは立たないわけで。
たとえば、命名規約を守らないやつがいるとか、新規に加入したメンバーへの教育をしなければならないとか、意図的でないミスを防ぐ仕組みがないとか。
正論以前の問題として、首から上が飾りにしかならない人々の存在も無視できない。
たとえば、こう言ったファイル名に基づくバージョン管理では、十分な長さのバージョン識別子が必要になる。
よく見るのは、「 ○○-20150228.xlsx」とか。
これが十分と言えるのは、更新頻度が1回/日を上回らないと言い切れるときのみ。
こんなことは、十秒も考えれば判ることなのに、日に数回更新されるファイルに適用して破綻しているケースをよく見る。
こんなのは、可読性も考慮して、「 ○○-2015-02-28-00.xlsx」くらいにしとけば、日に十回以上更新されても問題ない。
しかし、彼らの思考がそういう方向に向くことはなく、同じ破綻を何度も繰り返している。
そういう人々を無視できないから、こういうストーリーが立つ、ってわけだ。