ファイルサーバにゴミファイルを溜めさせない Part3
▪️ゴミファイルを作らせないアプローチ
ファイルサーバに溜まるゴミファイルへの対策として、 ファイルサーバに溜まりに溜まったゴミファイルを肥やしにしよう Part2 で、ファイルを作成する時の用途を明確にして、定期的にチェックするのが有効だと書いた。
だが、どのように用途を明確にするのか、何を基準にチェックするのだろうか。いろいろなケースがあるため、これといった基準を定めにくい。だが、基本的に押さえておくべきポイントはある。
▪️データ管理の5W1H
情報伝達のポイントとして「5W1H」(ご・だぶりゅー・いち・えいち)とし「六何の法則」と呼ばれる慣習がある。5W1Hとは、
- Who(誰が)
- What(何を)
- When(いつ)
- Where(どこで)
- Why(なぜ)
- How(どのように)
の6つだ。データを整理する際にも、この5W1Hを考慮する必要がある。ファイルの整理での5W1Hの考え方は、
- Who(誰が作ったファイルか)
- What(何のために作ったファイルか)
- When(いつ作ったファイルか)
- Where(どこに保存されているか)
- Why(作成した意図)
- How(ファイルをどのように管理しているか)
の6つだ。
▪️5W1Hをどう明確にしていくか
ファイルの5W1Hを明確にするにあたり、Gitのようなバージョン管理システムを使いこなせるならベストだ。しかし、学習コストやルールの徹底等、そう簡単にはいかない。そこまでしなくても、手短にあるツールでもできるアプローチはある。
例えばUnix系のOSであれば、tree や find のコマンドを使うことでファイルの作成日や保存パス、フォルダの構造を簡単に知ることができる。Windowsでも、コマンドプロンプトやPowerShellを利用することで、多くの情報を得ることができる。
コマンドで得た情報をテキストに出力して、作業エビデンスにすることもできるし、ファイル整理で情報一覧として活用出来る。闇雲にエクスプローラでフォルダ間を行き来するより、効率良くファイルの確認作業ができる。
また、MSのOfficeやLibreOfficeでも、ファイルのプロパティにコメントを残すことができる。更新履歴の機能を使えば、更新者のデータを埋め込むこともできる。ちょっとした機能だが、使い方次第で大幅にファイルの管理が捗る。
▪️ソフトウェアの力を借りる
SIerの間でよく見かけるが、納品用のドキュメントに更新履歴という欄を作っている。あれは無意味だ。どこをどう更新したか、更新箇所があったか、なぜ更新をおこなったか。一回のメンテナンスでも一つの表が作れるくらいの情報量は発生する。まず、そのことを認識していない。これを小さな表で作られた更新履歴で管理しようとしているのだ。書類を作るのが仕事のSIerだが、その割に書類に対する認識は激甘ではなかろうか。
ファイルの更新は作業毎に行うとまとまりやすい。更新履歴を人の手で書いてはいけない。正確にできる訳が無いからだ。差分抽出できる仕組みを使って、更新前のファイルとの差分を出力しよう。作業内容を記録したファイルと差分のリストと旧ファイル、この三つを保存しておくと、後々読み直した時にとても分かりやすい。
SIerに限らず、大半の人がコンピュータを使っているのに人力に頼り過ぎている。人力で抽出した不確かな情報を元に判断するから、情報が錯綜したり作業効率が落ちる。素直にソフトウェアの力を借りよう。
結局、スキルを鍛える手間や、何かを試すリスクを避けていると、どうしても人手にたよってしまう方向にいく。よく分からないままに人手で解決すると、悪習が生まれる。ファイルサーバに増えたゴミファイルは、この悪習の象徴だ。
ちなみに今回のコラムは、私が二年前に書いた手記を再利用したものだ。過去、自分の残した情報を元にして、コラム一本分のネタが捻出できるのだ。プロジェクトでも過去データを上手く再利用することで、大きな利益を得ることができると思う。
コメント
ksiroi
・What(何のために作ったファイルか)
これは
・What(どういった内容のファイルか)
じゃないかなー。Whyとかぶるかもしめじ。
僕はwhereとwhen重視かな。
その日しか使わないであろう一時ファイルはwork以下の日付フォルダに。
資料として完成させるものは共有ドライブのプロジェクトごとに。
gitで完結できれば一番楽だよねー。まだもうほんの少し機能が一味足らない。