マルチプラットフォームなリスクヘッジ。Web2.0の命のために

心得其の百四十

数年ぶりに大魔神に変身

会社員時代、「後継者」と見初めた者には厳しく叱ったものです。ものの例えとして「叱る方が辛い」というのは本当で、きれい事ではなく自分で処理した方が何倍も「楽」です。叱るとは一方的に説明することでも感情をぶつけることでもありません。理由や原因を考えさせる入り口です。しかし、入り口に誘導するには時間もエネルギーも必要です。ならば自分でやった方がと……ここが辛いところで、それでは成長はありません。一方で「怒る」とは似て非なるもの、こちらは「感情」を先にぶつけます。

久しぶりに「怒り」ました。スタッフに対して。血液が逆流し怒髪天を衝く勢いです。直後に反省しました。叱るではなく「怒り」にしてしまった自分の未熟さに。スタッフを雇ったのも教育したのも自分。つまりは自分が悪いのです。人は完璧ではなくミスを犯すもの。だから備えが必要で、備えを教えるのは上司の仕事です。

そしてコンピュータが今よりもっと不完全だった時代に使われていた保険の技法を伝えたのです。

重複更新防止のために

複数のスタッフで作業する際、「重複更新（作業）」に注意しなければなりませ。A、B、Cと3人の「Web担当者」がいる企業でこんなことがありました。Aがサーバーのデータを直接修正した後、自分のパソコンにダウンロードして作業していたBが完成ファイルをアップロードします。外出先でサイトを確認したAは異常が起きたと、会社にいたCに「復旧」を指示します。トラブルに慌てたCは自分のパソコン内にあった「一番古いデータ」をアップしました。Cの人件費を使って、AとBの仕事を無駄にします。

典型的な「ヒューマンエラー」です。さらに心理的な面からアプローチすれば「データ」を軽んじているからこそ起こったミスです。Aはサーバーデータという、いわば「オリジナル」を直接操作し、BとCはそのオリジナルの「日付」をアップロード前に確認していなかったのです。「FTP（アップロードするソフト）」のなかには上書きを警告してくれるものもありますが、日付確認はデータ管理の基本であり、コンピュータが不完全だった20世紀には鉄則でした。

Web 2.0の定義でもある

弊社のスタッフは各自での保存を義務づけてあるデータを「削除」し「ゴミ箱を空」にしました。理由を問うと「いつでもオリジナルからコピーできる」と答えます。これが私の逆鱗を刺激しました。

データは財産であり命です。極論すればスタッフ全員が総辞職し、パソコンは壊れ関東大震災が襲ったとしても、データさえあれば復旧は容易いでしょう。IT業界だけのことではありません。DTPなら版下データはそのまま「商品」ですし、企業にとっての顧客名簿は預金通帳と等価です。Web 2.0の定義にある“データは次世代の「インテル・インサイド」”も同じです。もっとも、データの重要性はWeb 2.0をどこかの会社が商標登録出願する前から商売の世界では常識でしたが。

オールドテクノロジーですがなにか

セキュリティの関係から詳細は明かせませんが、実際は複数で管理しており、1つや2つ消してもまったく問題はありません。しかし、ルールを軽んじて削除したことに、またデータを軽く扱うその態度が私の血液を逆流させたのです。「ヒヤリ・ハット」というようにこうした態度がいつ重大トラブルを招くかわからず、それは経営者視点でみれば「恐怖」です。

在宅スタッフも緊急招集して、データの取り扱いを再指導します。

「まず、別名保存」

写真、イラスト、文章、動画。すべての「データ」を別名保存してから作業にかかり、完了時に「オリジナル」と差し替えるルールの徹底です。これには2つの理由があります。第一が「オリジナル」の保護で、作業中のデータ破損時に即応するためのリスクヘッジです。

ミスを繰り返さないためのヒューマンチェック

もう1つが「世代管理」。別名保存するファイル名に「日付」を織りこみます。たとえば「datafile.txt」を作業する前に「datafile091021.txt」と日付をいれ、プログラムファイルなら「test-v2-091021.php」と「v」の後にバージョンナンバーを配します。作成日付はプロパティをみればわかりますが、ファイル名で「いつ作業した、どのバージョンか」を明示し意識付けするのはヒューマンエラー対策です。

また、トラブル発生時にはファイルを遡ることで迅速に「過去」へ戻ることができます。日時や営業日報などと照合して、当時の作業工程をたどり、能力に帰結するミスか、偶発的なトラブルが原因となっているのかを特定しやすくなるのです。そしてこれが叱られた相手の考える材料となります。

上書き保存で残るのは「結果」だけです。しかし、こうして世代ごとにファイルを残すことで、思考過程から「因果」を明らかにできます。これにより再発確率を下げていくのです。

必要に迫られていた時代

かつて、ファイルを作成した直後の「別名保存」は欠かせない「保険」でした。FDの品質にバラツキがあり、保存したファイルが「読み込み不可」になることは珍しいことではなく、バックアップからいつでも必ず取り出せるとは限らなかった時代、何度パソコン内に「放置」してあったデータに救われたことでしょうか。また、ソフトウェアの「アンドゥ機能（元に戻す）」は脆弱で、途中で「はじめ」に戻ることなど不可能でした。そしてよく飛び、よく凍り付き、ゼロで除算はコーヒーブレイクの合図でした。スタッフに怒った時、こまめな保存が作業効率を上げた時代を思い出しました。

パソコンが飛ぶことをやめ、ある朝、不機嫌になるハードディスクも少なくなりました。しかし、デジタルデータを襲う突然死という病はいまだ根絶されていません。だから備えとして「別名保存」を徹底させます。

パソコンが不便だった時代のオールドテクニックは機種依存ではなく人依存。つまりは「マルチプラットフォーム（笑）」。XPでもVISTAでも7でも雪豹でも使えます。