コーヒーでも飲んでから待ち合わせの場所に

約束の時間

打ち合わせのために、約束の時間に相手の方の事務所に訪問することは、システムエンジニアの業界でも頻繁に発生します。事務所でパソコン相手に、朝から晩までキーボードをたたいているわけではありません。天気のいい日などは、散歩がてら気分よく待ち合わせの場所に向かうことができます。

でも、約束に時間とはいったい「何時」を指しているのでしょうか。

5分前

ビジネスマナーでは、「約束の時間の5分前には訪問しましょう」が一般的な正解なんでしょうか。いや、10分前でしょうか。とにかく、遅刻しないことが大原則だったりします。待ち合わせの時間に遅刻していくくらい恥ずかしいことはありません。でも、早めに訪問することが本当に相手の方のためになることなのでしょうか。

意外とせわしい

あれっ？もう来ちゃったの

こんな言葉、聞いたことはありませんか。こんなこともありませんでしたか。

あっ、もうそんあ時間かぁ。やっベー、会議室とっておいたっけなぁ～。ちょっと、待ってください。

入社式や、イベントなどで大々的に行う行事と違って、日常的な打ち合わせなどは以外と対応する相手の方は”せわしい”状況であることがほとんどです。午後3:00からの打ち合わせのために、30分も前から準備して待っていてくださるなんて皆無に等しいと感じています。毎日、突発的な事件も発生します。この時期、暇な人なんているはずもありません。

ちょっと、遅れる

ビジネスマナーには反していますが、”ちょっと遅刻する”なんてことはいけないことでしょうか。約束の時間に2分遅刻する。1分遅刻する。約束の時間に少しだけ遅れることで、訪問する相手の方が、時間にゆとりを持つことができるとは思いませんか。「なんでもかんでも遅刻する」というのは、さずがにどうかと思いますが、相手の方の性格やその場の状況、打ち合わせの規模、内容などを考えて、自由に発想することも大切だと思っています。

自分なら、もし「約束の10分前」に訪問されたら、「えっ、もう来ちゃったの～？」って返事になってしまうはずです。言葉には出しませんが、その場合の状況は、やりかけの仕事が「乗ってきた」ところだったりするんです。訪問する方は全然悪くないんですよ。

コーヒーでも飲んでから

理想的には、約束の20、30分前には訪問先の近くに到着し、ドトールあたりでコーヒーでも飲んで、打ち合わせの内容を再確認し、30秒遅れで訪問することじゃないかと。。。

トイレもすませ、鏡を見て、汗を拭いて、ココロにゆとりをもって訪問する。「そういえば、別件で忙しい最中だって言ってたっけ。ちょっと電話で状況を確認してから訪問しようかな？」なんてことも考えることもできます。

こんなことを常にできるビジネスマンであれば、待ち合わせの時間の問題なんて発生しないんでしょうね。

杓子定規にはいかない

待ち合わせの時間一つとっても、仕事の現場というのは杓子定規にはいかないもんです。ちょっとした仮説を立てて、些細なことも自分で考える。

ようは、訪問する相手の都合に合わせること。これがベストな方法と思っています。

はじめて名刺を渡す緊張感

お客様先へ

今日、はじめて新人がお客様先にやってきた。わたしは今、お客様先で仕事をしている。この日の訪問は予期せぬ出来事だった。この時期に新人が客先を訪問することはまずない。研修も終ったばかりだし、客先に顔をだすことは非常に勇気のいる行為である。

逆に新人にいろいろなことを経験してもらうためには、緊張感のある「お客様先への訪問」はとてもいい経験になることもたしかだ。何をどうすればいいのかわからない状態で、機転を利かせて、考えを実行に移さねばならない。マニュアルはない。すべてが研修の応用である。

名刺は？

「今日、名刺を持ってきた？」と何気なく聞いてみると、「すみません、持ってきてません。。。」とすまなそうな返事。どうした？会社を一歩出たら、どこで名刺を渡すことになるのか、わからないぞ。机の中に名刺を入れたままじゃ、使うことはできないぞ。

はじめて名刺を渡す瞬間はものすご～く緊張する。私もそうだった。両手で？それとも片手でいいの？自分から先に渡していいの？それとも、相手から？もらった名刺は机に並べるって、じゃ、立ったままの場合はどうすれば？

はやく、その緊張感を味わって欲しいなぁ～。

新人は今日からOJT

新人研修が終る

2ヶ月の新人研修が終了し、今日から新人2名が配属された。2ヶ月の新人研修の成果が、どんなものか楽しみです。社会人としてのマナーからはじまり、プログラミング言語の研修、システム構築の研修など本来なら2ヶ月でできるような内容ではありませんが、駆け足で勉強してきたはずです。毎年講師になる先輩方、ほんとうにご苦労さまです。

新人にとっては右も左もわからない状態で入社し、まず先輩講師のあたたかい助言、指導に触れることができる。生まれたばかりの雛鳥が最初に目にした「もの」を親と認知するのと同じように、これから何年も先輩、後輩の良い関係を築いてくれれば、新人研修を手作りで実施していることの意義が理解できると思います。

OJTの期間

OJT(Job On the Job Training)は、この言葉のままです。仕事をしながら訓練を重ねることです。よく、OJTは3ヶ月などといいますが、この業界、とくにシステム構築やプログラミングによる開発などの特殊な能力を必要とする職業では、OJTの期間がそんなに短くすむとは誰も考えていないでしょう。その人の能力、向上心など個人によって差はあると思いますが、1年未満のOJTを実施したからといって、それで一人前になれるような業界ではありません。

担当する仕事にもよりますが、3年、5年、10年と長いスパンで考える必要があると思います。

OJTで先輩になる

OJTは、それを受ける側もそうですが、先輩として指導することにもっとも意味があるんじゃないかと思います。今まで、OJTのマニュアルを作成したとはありません。マニュアル通りに目の前の仕事が進むはずもありません。イレギュラーな事態が発生した場合でも、指導する先輩には的確なアドバイスが求められます。どんな事態が発生しても、過去の経験や他の先輩の助言などを求めながら、先輩自身が考えていくことが一番大切だと思っています。1年、2年と後輩に助言することを経験することで、自分の仕事に対する姿勢、考え方などをもう一度整理する機会として、OJTはとっても有効な教育と思っています。

ゴールを決める

OJTで一番大切なことは、新人ができることを「ゴール」を設定して実行していくことです。今週中にはここまで仕上げよう。明日までに書き上げよう。今日中にここまで試験しよう。常に「何をいつまでに」ということを約束しなえれば意味がありません。できた、できないなどの結果ではありません。約束した小さな「ゴール」に対して、どのように仕事を進めていったのかをチェックすることが大切です。OJTでは新人にできないことを任せたりしません。できることを十分に余裕をもって、「やってごらん」と指示するはずです。

システムエンジニアを目指して。。。

OJTでは、まず仕事の進めかたを学びます。仕事の進め方を身につけることが、一人前のエンジニアになるためのはじめの一歩です。コンピュータの技術は10年経てば、まったく新しいものになってしまいます。今の技術を一生懸命身に着けても、明日には古い技術として見向きもされないかもしれません。システムエンジニアにとって、これから毎日が勉強になります。

大切なことは、仕事として作業を進めていく力です。技術を身につけるだけでは仕事はできません。誰に許可を得るのか、誰に質問したらいいのか。そんな人間関係をつくっていくことのほうが必要なんです。

OJTを通して、それぞれのチームの仕事の進めた方、考え方をすこしでも体験して、どんな仕事でも臨機応変に対応できる能力を身につけていただきたいと思います。

特定電子メールの送信の適正化等に関する法律

迷惑メールに法規制

こんな法律があったなんて全然知らなかった。インターネットの世界は自由な国境のない世界、なんてもう過去の話。こんな法律がどんどん出てきて、どんどん国会で可決されていたなんて。。。

第一条

この法律は、一時に多数の者に対してされる特定電子メールの送信等による電子メールの送受信上の支障を防止する必要性が生じていることにかんがみ、特定電子メールの送信の適正化のための措置等を定めることにより、電子メールの利用についての良好な環境の整備を図り、もって高度情報通信社会の健全な発展に寄与することを目的とする。

電子政府の総合窓口
法令の詳細な検索＞法令データ提供システム
特定電子メールの送信の適正化等に関する法律
（平成十四年四月十七日法律第二十六号）

この第一条の最後の部分、「電子メールの利用について。。。」は、自分の業務のテーマであったりします。今後も電子メールのシステムに携わっていく身としては、迷惑メール対策は一番の感心ごとです。

こんなが本当にできるのか

法律の条文をそのまま読んで、一般人の私が理解するのは少々骨が折れます。法律の文章は特定の人しか理解できないように、わざとこうしているんでしょうか。普通の言葉で書かれているサイトを探してみると、な～んだ、あるじゃない。総務省のサイトに。ショッピングのサイトなどでも、この概要をリンクしているようです。概要だけでも多少の理解はできるかなぁ。。。

読んでいるうちに、「こんなこと、本当にできるのかなぁ」と疑問に感じる部分も。ここに書かれている通りであれば、迷惑メール対策は警察の仕事なのかな？

総務省の情報通信政策に関するポータルサイト
特定電子メールの送信の適正化等に関する法律の概要

特定電子メールの定義

その送信をすることに同意する旨の通知をした者等一定の者以外の個人に対し、電子メールの送信をする者（営利を目的とする団体及び営業を営む場合における個人に限る。以下「送信者」という。）が自己又は他人の営業につき広告又は宣伝を行うための手段として送信をする電子メールをいう。

さすが職人。迷惑メールをすぱっと定義してくれています。この通りです。でも、「私の個人的な趣味ですから」なんて言い訳されちゃうんだろうか。。。

表示義務

特定電子メールの送信について、次の事項の表示を送信者に対し義務づける。

1. 特定電子メールである旨
2. 当該送信者の氏名又は名称及び住所
3. 当該特定電子メールの送信に用いた電子メールアドレス
4. 当該送信者の受信用の電子メールアドレス等

いくら表示を義務付けたとしても、電子メールアドレスにどれだけの「信憑性」があるというのか。携帯の電話番号は、キャリアが管理し、個人が勝手につくることはできない。でも、電子メールのアドレスなんか個人が勝手にいくらでも作成することができる。そんな電子メールアドレスを表示しているからといって、なんの規制になるんだろうか。

拒否者に対する送信の禁止

送信拒否の通知をした者に対して送信者が特定電子メールの送信をすることを禁止する。

こんなことを条文に書くから、迷惑メールには、「拒否する場合はこちらへ」なんて怪しげなアドレスを本文の最に書くようになったのかなぁ。。。で、そこにメールを送信すると、自分のメールアドレスを通知することになる。また、普段からメールを見ている「活動的な」ユーザであることを相手に知らせることになる。このアドレスを別の業者に引き渡すことで目的は達成できる。送信拒否は、電話で連絡したり、内容証明の郵便で送付することを考えて条文を考えたのかな？簡単に拒否できないから困っているのに。。。

架空電子メールアドレスによる送信の禁止

自己又は他人の営業につき広告又は宣伝を行うための手段として送信者がプログラムを用いて作成した架空電子メールアドレスに宛てた電子メールの送信をすることを禁止する。

たとえば、ニフティの@nifty ID（英字３文字＋数字５文字）であれば、プログラムであっという間にすべてのメールアドレスを作ることができます。これを順番に送信していって、拒否されなければ「生きている」メールアドレスということで、迷惑メールを送信する側に送信先アドレスリストを作成できます。このような行為を禁止するものですが、この行為をどうやって特定するのかが頭の痛いところじゃないでしょうか。

通信の秘密、検閲の禁止との関係

電気通信事業法の通信の秘密と、検閲の禁止を守りながら、この特定電子メールを排除することは本当に可能なんでしょうか。プロバイダでメールの中身をチェックして、この法律に違反するかどうかをチェックすることはできるんでしょうか。ただ「作ってみました」なんて法律なんでしょうか。

専門家の方に教えていただきたいくらいです。

PostgreSQLにセキュリティホール

また入れ換えか。。。

PostgreSQLにセキュリティホールが見つかったらしい。でも、即日修正モジュールがリリースされたということ。ここ2ヶ月ばかり、PostgreSQL 8.1.3 でWebシステムの検証を実施してきたのに、一部またやり直しだなぁ。なってこった。。。

でも、Webシステムリリース前でよかった。サービスがはじまれば、それはそれで面倒なものだから。

明日、若い人にたのんで、さっそく入れ換え & 再試験の実施をお願いしよっ～と。

PostgreSQL Global Development Groupは5月22日，オープンソースのデータベース管理システム（DBMS）「PostgreSQL 7.x／8.x」にセキュリティ・ホールが見つかったことを明らかにされた。不正なSQL文を送り込まれる「SQLインジェクション」攻撃を許して，データベース内の情報を操作される恐れなどがある。対策は，同日リリースされたバージョン 8.1.4／8.0.8／7.4.13／7.3.15にアップグレードすること。
。。。

ITpro オープンソース/Linux ニュース記事[2006/05/25]より 「PostgreSQL」にセキュリティ・ホール，SQLインジェクション攻撃を許す

「匿名希望」がなくなる日

送信ドメイン認証

迷惑メール対策として、プロバイダのメールサーバから外部に発信するメールには、次のような電子署名のようなヘッダがついています(DomainKey-Signature部分)。大手プロバイダでは迷惑メール対策の一つの試みとして、送信ドメイン認証という仕組みを模索しているようです。

Received: from unknown (HELO aps509) (172.22.106.153)
  by smb511.nifty.com with SMTP; Tue, 23 May 2006 23:21:40 +0900
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=pxy2nd-default; d=nifty.com;
  b=iGr2xxVhZNoEEvU2Hxm2suMpmQFppy7K2zCaB9y7TJc8wsZKAFLVNU7ycSnWXE0cQXIQ7nEMRyLZj+fh+cCyng==  ;

DomainKeys方式の概要

送信ドメイン認証という方式にはいくつか種類がありますが、大きくIPベースの認証方式と暗号化ベースの認証方式があるようです。ニフティのメールヘッダについている DomainKey-Signatureヘッダは暗号化ベースの認証方式で、Yahoo、AOLなどのプロバイダが提唱している方式です。

詳しくしりたい方は、@ITのレポートが参考になるかもしれません。また、ちょっと古いんですが、Sendmailのサイトにも詳しいレポートが公開されています。

Sendmail社は、実環境への適用シナリオをもとにした長時間にわたる試験を実施し、昨年来話題になっている新しい電子メールの送信者認証技術のインターネット電子メールサイトへの導入方法についてのレコメンデーションを作成しました。

Sendmail 2004年 11月
送信者認証技術の導入におけるレコメンデーション

今回は電子署名を利用した送信ドメイン認証技術「DomainKeys」について解説する。Sender IDやSPFなどのIPアドレスベースの送信ドメイン認証に比べて、本質的にメール転送に強いという利点があり、長期的には電子署名方式の送信ドメイン認証を利用していくべきであるといわれている。

2006/1/12
電子署名を使うDomainKeysの設定方法

簡単に説明すると、

メールを送信するプロバイダ側

• DNSサーバにプロバイダドメインの公開キーを登録する。
• メールを外部に送信する場合、そのメールヘッダ部のハッシュ値を計算し、
• その値を公開キーに対応した秘密キーで暗号化し、
• Base64でテキストコードとし、
• その情報をメールヘッダに追加する（DomainKey-Signature)。

メール受信するプロバイダ側

• 受信したメールにDomainKey-Signatureヘッダがあれば、
• ヘッダ情報のドメイン(d=nifty.com)のDNSサーバからの公開キーを取得し、
• Base64でエンコードした情報(b=iGr2xx....==)を元の値にデコードし、
• DNSサーバから取得した公開キーで複合する。
• メールを送信したサーバが計算した方法と同じ方法で、ヘッダ部のハッシュ値を計算し、
• その結果が一致するかどうかチェックする。
• 認証結果をメールのヘッダ(Authentication-Results)に追加する。

ニフティの送信ドメイン認証

メールの受信者は、Authentication-Resultsヘッダによって、そのメールの電子署名の「認証結果」を参照できるようになります。これを元に怪しいメールは受信しないなどの「対策」をメール受信者が行うことができます。ただし、ニフティの受信メールで、そんなヘッダを見たことありません（たぶん。。。）次の説明にも「ニフティから送信するメール」とあり、受信したときの認証まではやっていないのかもしれませんね。

@nifty会員のメールアドレスを詐称する迷惑メールの抑止に向けて

@niftyのメールアドレスで送信されるメールに対して、「SPF（Sender Policy Framwork）」と「Domain Keys」を適用し、送信ドメイン認証によるメールアドレスの詐称の防止に着手しています。

迷惑メール対策@niftyより
送信ドメイン認証

「秘密の保護」に触れる？

しかし、これらの措置が、電気通信事業法の通信の「秘密の保護」「検閲の禁止」に触れるのではないかと報じされています。メールのヘッダは、郵便局で手紙の切手に「スタンプ」を押すのと同じ感覚でいたんですが、それは「違う」という話です。

インターネット協会が開催した「第3回迷惑メール対策カンファレンス」で、ニフティの木村孝氏と、電気通信事業者を所管する総務省消費者行政課の今泉宣親氏が、特に送信ドメイン認証の導入に焦点を当てて法的な留意点をまとめた。
... なお、メールは送信者と受信者の双方が当事者(利用者)であり、「利用者の同意」というと、双方が同意しなければならないように思われるが、送信ドメイン認証は、基本的に受信側の同意のみで提供でき、送信側の同意は不要、というのが総務省の考え方である。

これは、送信者が「送信行為を完了した時点」、つまりメールソフトなどでの送信が終了した時点で、メールは送信者の手を離れると解釈されているためで、送信者が送信を完了して以降の対策である送信ドメイン認証は、送信側の同意が必要ない、というわけだ。 ...

MYCOM 2006/5/17のレポート
送信ドメイン認証による迷惑メールの排除、法的に認められるのか

この記事の内容はとっても重いし、難しい。法的な解釈みたいな部分とは無縁の世界に生きてきたと思っていたのに、Winny以後、「法律」の一番神経質な部分と隣り合わせの状態になっている。

消印の認証

でも、待てよ。送信ドメイン認証は、そもそも郵便局の消印が正しいものかどうかを認証しているだけで、別に差出人が正しいと証明しているわけではない。送信ドメイン認証の方式では、メールヘッダの From や、エンベローブ From のドメイン部分を認証する方式もあるが、これも差出人の住所が正しいものかどうかをチェックしているだけで、その住所(ドメイン）に、その人（メールアドレスのローカルパート部分、＠マークの左側）が、確かに住んでいるかまでを証明しているわけではない。

いい加減な差出人で、はがきをテレビ局やラジオ局に出せなくなる日。「横浜市にお住まいの匿名希望さん」からのトリビアがなくなってしまう世界。電子技術で簡単に「認証」方法を生み出してしまっては、現実社会のような匿名性はなくなってしまうのか。

悪いのは迷惑メール。でも、ダイレクトメールを郵便局が勝手に止めることもない。1通のメールを1000人でも10000人でも簡単に、そしてただ同然で送信できるメールシステムだからこそ、迷惑メールが後を絶たない。メールの一番の特徴が、一番の問題点になっているというのか。。。

プロバイダは電気通信事業者

電気通信事業法

まじめに電気通信事業法をちょっと見ておかないと、まずいんじゃないかと思うようなニュースが発生しはじめている。ぷららのWinny通信遮断なども、この電気通信事業法が関係している。でも、総務省もいつの間に、こんなサイトを立ち上げていたんだ。。。

「電気通信事業法」は、電気通信の健全な発達と国民の利便の確保を図るために制定された法律で、電気通信事業に関する詳細な規定が盛り込まれています。 特に、第四条では、何人も電気通信事業者の取扱中の通信を侵してはならない旨の条文があり、通信の秘密が保護されています。

総務省
国民のための情報セキュリティサイト
基礎知識　電気通信事業法より

そして、問題の「検閲の禁止」と「秘密の保護」は総則の最初に書かれています。

（目的）
第１条　この法律は、電気通信事業の公共性にかんがみ、その運営を適正かつ合理的なものとするとともに、その公正な競争を促進することにより、電気通信役務の円滑な提供を確保するとともにその利用者の利益を保護し、もつて電気通信の健全な発達及び国民の利便の確保を図り、公共の福祉を増進することを目的とする。

（検閲の禁止）
第３条　電気通信事業者の取扱中に係る通信は、検閲してはならない。

（秘密の保護）
第４条　電気通信事業者の取扱中に係る通信の秘密は、侵してはならない。
２　電気通信事業に従事する者は、在職中電気通信事業者の取扱中に係る通信に関して知り得た他人の秘密を守らなければならない。その職を退いた後においても、同様とする。

第179条　電気通信事業者の取扱中に係る通信（第164条第２項に規定する通信を含む。）の秘密を侵した者は、２年以下の懲役又は100万円以下の罰金に処する。
２　電気通信事業に従事する者が前項の行為をしたときは、３年以下の懲役又は200万円以下の罰金に処する。
３　前２項の未遂罪は、罰する

法庫(http://www.houko.com/)
電気通信事業法より

電話、ラジオ、テレビ、CATVなどの事業者が電気通信事業者ということになっています。インターネットのプロバイダが世に出る前から、この法律は存在していましたが、プロバイダも「電気通信事業者」です。したがて、この法律の適用を受けることになります。

検閲の禁止

日本国憲法にもこうあります。

第21条　集会、結社及び言論、出版その他一切の表現の自由は、これを保障する。
２　検閲は、これをしてはならない。通信の秘密は、これを侵してはならない。

国民は自由な「思想」を持つことを許され、その思想、表現の自由を奪う「検閲」をやっちゃだめだってことのはず。「こんな本を読んじゃだめだ！」とか、「こんなビデオ見ちゃだめだ！」とか、人の部屋に勝手に入って、机の中や、本棚を漁っちゃならんってことではないか。

ウィルスメールをプロバイダが削除するのは、検閲にはならないんだよなぁ～。。。どっちなんだ？

秘密の保護

集会、結社を規制するために、関係者の電話を傍受する。そんなことを電話会社はやってはならない。どんなに悪企みを携帯電話で話していても、気を利かせた docomo の社員が勝手に会話を録音すれば、録音したほうが罰せられる。表現の自由、思想の自由を守るために。

カミソリのはいった手紙が送られてきたとしても、しろい粉がはいった手紙が投函されたとしても、相手の手元に届くまでに、郵便局の人が勝手に中身を見ていいことにはなっていない。「カミソリが入っていたんで、抜いておきましたよ」なんてメモと差し替えることもできない。

「ダイレクトメールお断り」なんてサービスは郵便局にはないよなぁ～。「迷惑メールお断り」は、通信の「秘密の保護」に抵触するのか。。。

インターネットの世界は日本だけではない。戦前にあった技術でもない。プロバイダは、「電気通信事業者」ってことをもっと認識しておかなきゃ。。。

罠をしかける

永遠のテーマ

社内のメーリングリスト宛に迷惑メールがひっきりなしにやってくる。人妻からの極秘情報や、応募してもいないサイトから「当選しました」なるメールが毎日のようにやってくる。会社でおやけにしているメールアドレスなだけに、アドレスを変更することもできない。いったい、どんな対策を講じればよいのか頭を抱えてしまっていた。

会社にとっては迷惑この上ないメールであるが、そのメールが私にとって迷惑であるか、有益な情報なのかは、やはり人間の目で確認して、仕分けするしか方法がないのだろうか。

メールシステムが今後も進化すると仮定すると、大量の数のメール、ウィルスを受信することは、どうしても避けられない問題である。でも、やはりスパムメールは受信したくない。当たり前の対策が求められているにも関わらず、どうしても対策が後手、後手に回ってしまっている。

迷惑メール、スパムメールを撃沈することは、メールシステムの運用に携わっているシステムエンジニアにとっては永遠のテーマになってしまっている。

試験用として利用する

メールシステムを構築する際にもっとも注意しなければならないことは、インターネットでの運用実績があるか ないかに関わっている。

どんなに知恵を絞って、試験項目を考えたとしても、やはりすべてのメールを試験できるわけではない。必ず、検証パターンになかったメールで、システムの不具合が発生することになる。

たとえば、メールのヘッダ情報としてついてくる「Date:」ヘッダの文字列形式でさえも、大きく影響する場合がある。1桁の日を　"01" のようにゼロをつけて表記するのか、"1" のようにゼロをつけないで表記するのかは、メールを送信した｢メーラ」や、それを中継する MTA (メールを中継するプログラム。sendmail や　Postfix などがある）によっても異なってくる。すべてが同じになる、なんてことはありえない話だ。

迷惑でしかないメールでも、使い方を考えればとっても有効に利用することができる。メールシステムの試験である。構築したばかりのシステムにネット上を流れるさまざまメールを、試験対象のシステムに流し込んでやることだ。24時間、365日、試験は着実に進んでいく。中には、ウィルスに感染しているメールを受信することもあるだろう。想定していないメールを受信して、システムの不具合を発見できるかもしれない。囮のメールアドレスが欲しかったので、今日、ニフティのお手軽コースに入会を申請した。

罠（わな）

敵を知る。そのために小さな罠を仕掛けることにした。スパムメール、迷惑メール、ウィルス感染メール。いったいどこから情報を入手して、私のメールアドレスにメールをおくりつけてくるのだろうか。

メールは毎日チェックするもの。受信したメールの実に 90%以上 がスパムメール、迷惑メールの類だったとしたら、きっと毎朝憂鬱な気分で仕事をはじめなくてはならない。誰でも、憂鬱な気分で朝から仕事をはじめたくない。仕分けするためにお給料をいただいてはいない。

メールの宛名、殿か？様か？

不安が募る。。。

メールの宛名の敬称に、「殿」を付けるのか、「様」を付けるのか。今更この歳で悩んでしまいました。若い方に今までどうやって説明してきたのか。いい加減なことを言ってきたんじゃないのか。何の根拠があるんだっけ。

恥ずかしながら、不安になって、ちょっと調べてみた。それにしても、今更だな～。。。

周りは殿派

いくら探しても、「これだ！」という答えはなかなか見つからない。｢無知」と言われるかもしれない。。。つい、慎重になってしまう。

現在では事務的・公的な書面等では、目上・目下を問わず敬称として用いられているのが実状ですが、目上の人への私信などにおいてこれを用いることはできません。

日本語Q&A：スペースアルク
ことばの使い方（社会言語学・敬語）より
「殿」と「様」はどう違う？

たぶん、この辺の説からだと思うが、私の周りでは「社内では”殿”を使う」というケースが圧倒的に多い。また、会社は異なっても、同じ仕事をしているチームの中でも「殿」を使っていることが多い。現場では、目上や目下などの「関係」をあえて、メールの中に持ち込まないように配慮している感がある。「事務的」というのがこの場合に、もっともぴったりする表現である。毎日書く報告書や指示書などのメールで、堅苦しい表現にならないように工夫しているんだと信じたい。

部長殿

役職宛の場合は｢殿」を付ける。でも、次の説明では　名前＋役職名＋”殿”ではなく、「システム部長殿」のように、個人名が入らない場合に「殿」を付けるように説明している。○○の部分が役職名なのか、個人名なのかはっきりしないものだから、”山田部長殿”でもよし、という論理が展開されてしまう。

• 「○○先生様」「○○先生殿」は二重敬語となるため避ける。
• 役職あての場合には「○○部長殿」「○○課長殿」とする。

ビジネス道場 ｢初級」より
読売新聞社のWebサイト：ジョブサーチ

正しい表現、「様」

識者の方々によると、｢様」の表現は次のようになるのが理想的らしい。この表現だけは、どの記事も一致している意見のようだ。でも、毎日発生する社内のメールを毎回このように書いていては、肩がこってしまう。。。/p>

株式会社　山田商事
　　営業本部長　田中様

正しい表現、「殿」

相手の名称がわからない場合、またあえて個人宛のメールとしたく無い場合は役職名に殿を付けることになる。でも、絶対の付け方ではない。あくまでも例である。役職名のみでOKという方もいる。

株式会社　山田商事
　　営業本部長殿

誤った表現、「殿」

名前＋役職名で終ると、呼び付けしているような感じもするし、ちょっとさびしいような感じもする。で、私は名前＋役職名＋殿をよく使ってしまいます。「間違っている！」といわれてしまえば、それまでの話です。

株式会社　山田商事
　　営業本部　田中部長殿

普段のメールや、目上、目下にあまり気を配る必要が無い場合なら、次のようにしてしまう。連絡メールなんかは、ほとんどこれです。

山田商事 田中殿

相手が満足すること

大切なことは、相手に不愉快な思いをさせないことだ。「これが正しい」と主張することではない。答えがバシッと出ているわけでもない。手紙と電子メールでは、その利便性も利用シーンも大きく異なる。

でも、これからはもう少し、「様」を使ってみようかと思う。探してみると、実に多くの方が異なる感覚でこの｢様」「殿」を気にしていることがよく理解できた。事務的を嫌う人もいるんだろうなぁ。

なんか消化不良なエントリ。これからもちょっと「様」、「殿」は気にしてよっ～と。

メールの作法を改めて考える

いまさら。。。

今日、サポートの業務のなかで、改めて｢お客様に送信するメール」について考えてみた。ネットでちょっと調べてみると実に様々な「作法」を発見することができる。いろいろ考えている人がいるんだ。それに比べると自分は、随分適当な文章を書いてきた。手紙の作法も十分理解していない自分が、今までよく生きてこれたもんだ。反省。

手紙のマナー

手紙を送るときの「作法」には、実にたくさんの常識がある。たとえば宛名。「様」をつけたほうがいいのか、それとも｢殿」を使うのか。｢御中」はどのように使うのか。署名はつけたほうがいいのか。書き出しは拝啓なのか、それとも前略なのか。

日本の手紙の文化に比べたら、まだはじまったばかりの電子メールという文化。だが、すでにメールはビジネスマナーの一部にもなっている。もう、コンピュータ業界だけの常識では通用しない。

メールの制約

ネットサーフィン（古っ）が雑誌で取り上げられるよりもはるか昔、UUCPによるバケツリレー方式によってメールを利用していた。当時は、2400bps、9600bpsや14400bpsなど、現在の100Mpbsのインターネットの世界では到底考えられない通信速度の遅さのなかでメール文化に触れてきた。

すでに時代遅れのボケ親父と化してしまているのかもしれないが、そのころの｢制約」がメールの作法に色濃く反映されている。電子メールを１通送信するのにも、受信するにも電話代がかかっていた時代。すこしでも無駄な通信費を節約するために工夫していた時代。

日本の文化

電子メールの｢作法」は、日本の手紙の文化と微妙にからみあって、進化している。もう一度、電子メールの作法について見直してみようと思う。

ご無沙汰です、LinuxWorld Expo/Tokyo

社内の掲示板

今日、ふと社内の掲示板を見ていたら、若い方から「LinuxWorld Expo」の開催についての案内がアップされていました。そっか、もうそんな時期なんだなぁ。若いころは、こんなイベントには「まめ」に通っていたもんですが、最近は年度始まりのバタバタ月間ということもあり、とんとご無沙汰でした。

はて、今年の内容はどんなだろうか？・・・

オープンソースソフトウエアの無限の可能性

なぜか誘われます、このテーマ。無限の可能性はちょっと「大きい」かもしれませんが、これからの時代、限りなくソフトウェアはオープンソースの方向に流れてしまうような気がしています。

ところで、他の業種には、インターネットの世界にある、オープンソースのような概念はあるんでしょうか。

インセンティブ

携帯電話の端末を定価で購入する人はまずいないでしょう。

今でも最新の端末をただ同然の値段で売っている販売店もあるようです。これは、携帯電話会社（いわゆるキャリア）から端末の販売台数に応じて報奨金が販売店に支払われるから成り立つ仕組みです。

報奨金の原資は、携帯電話に加入している全てのユーザの毎月の料金から捻出しているはずです。古い機種で我慢している私にとっては「その分、料金を安くしてよ～」っていいたくなるような話です。

抽選で1名様

「キャンペーン期間中に応募いただいた中から、抽選で1名様に、最高級クラスの外壁塗装の料金を、当社通常価格の半額でご提供します」。

こんな誘いに、住所、氏名、年齢を書いて応募すれば、「今、家の外壁を塗り替えることを検討している世帯情報」が立派にできあがってしまいます。１件を半額にしても、いや、無料にしても、営業マンが、のどから手が出るくらい欲しい名簿が完成するはずです。

進化すつづけるソフトウェア

いわゆるオープンソースというものは、一握りの天才プログラマー達の「作品」を、利用することも、改造することも自由に行うことができるソフトウェアです。天才の「作品」を手にとって、あるいは解剖しながら、その足跡をたどることができます。

また、ソフトウェアをオープンにすることで、世界中の天才達がこぞって、その作品を「改良」し、「派生」させ、あるいは他の作品と「融合」したり、インターネット上のオープンな会議室でその「仕事」を推進していきます。

オープンソースの世界に「完成」した作品はありません。常に改良し、常によりよい作品を目指して、天才たちの仕事は続けられます。

作品の対価

ライセンスにもよるでしょうが、この「作品」の「対価」をどのようにして得ているのか、私にはよく理解できません。テレビやポータルサイトのような広告収入が、オープンソースの作者達に直結しているとは聞いていません。

今、私はIEではなく、FFを使って、Webサイトにアクセスしています。FFの作者は、どうやって私から収入を料金を徴収しているんでしょうか。指定の口座に振込みを依頼されたことはありません。

答えを探しに。。。

オープンソースの無限の可能性なんて大きなテーマ、今年はちょっと期待できるかもしれない。オープンソースの「作者」と「企業」の関係はこれから先、どうなっていくのだろう。その”ヒント”でも足がかりでも、何かを見つけるためにも、ぜひ、今年は、ビックサイトまで足を運ぼうと思っています。

会期

2006年5月31日(水)～6月2日(金)

時間

09:45～17:30

場所

東京ビックサイト（東京国際展示場）

全世界的そして日本国内でも導入が加速をしており、時代はまさに「Linux/オープンソースソフトウエアの全盛期」です。すでに導入されている企業の方々、これから導入を考えている方々の問題解決につなげていただき、さらなる「無限の可能性！」を来場者に訴求するイベントとして「LinuxWorld Expo/Tokyo2006 」を展開致します。

今回のイベントテーマは、「Linux/オープンソースソフトウエアの無限の可能性！」とし、Linux/オープンソースソフトウエア業界の祭典として「無限の可能性！」を展示やセミナーを通じ、幅広い層の来場者の方々に訴求・探求・体感していただきます。 ・・・

LinuxWorld Expo/Tokyo2006
開催概要より引用

お客様との約束を監視する目

変わらないお知らせ

ココログのユーザのブログサイトには、「ココログからのお知らせ」がもれなくついてきます。必要なお知らせがタイムリーに表示されているのであれば、気にすることもないのですが、ここ1ヶ月ほど、「新アクセス解析導入スケジュールに関しまして」というお知らせがずーっと表示されたままの状態になっています。5月も中盤を過ぎて、未だに何の変化もないのは、いったいどういうことでしょう。

新アクセス解析の導入スケジュールの詳細についてのご案内は、今しばらくお待ちいただけますようお願いいたします。4月中にはご案内できるよう進めていきたいと考えております。

引用：新アクセス解析導入スケジュールに関しまして

1ヶ月前

この文章を最初に読んだ時は、他のサポートの状況説明とは、どこか違った印象を受けました。短い文章に必要事項をきちんと配置して、「できるだけ早く対応します」のように期限があいまいな文章ではく、「4月中には案内します」と期限を明確にされていました。具体的にどのような問題が発生していて、どのような状況なのかはわかりませんが、「4月中」と報告した以上、現在の状況なり、今後のスケジュールの変更なりを掲載するのが普通の感覚では無いでしょうか。

最初は「4月中(4がつなか)」と読んでいたので、4月15日前後かと思ったのですが、「4月中(４がつじゅう）」つまり、4月30日までのことだったんだと、自分自身を勝手に納得させていました。でも、流石にここまでくると、「平成19年の4月？」と機転をきかすことはできません。

世間の常識

この時期、自分が勤める会社の新人教育もすでに終盤にさしかかっています。この中で、「お客様との約束はきちんと守りましょう」ということは、毎年、誰かが、必ず説明する内容です。特に会社で説明しなくても、世の中の一般常識です。商売をする身にとっては、お客様との「約束」は絶対であり、何がなんでも守ることが、お客様から信頼を得る第一歩のはずです。

どんな仕事であっても、必ず期限を設定します。約束した期日に間に合うように、毎日仕事を進めているはずです。期限のない仕事はありません。また、期日の当日になって、はめじて「がんばったけど、できませんでした」というのは、とっても失礼な話です。前もってわかっているのであれば、早めに報告するだろうし、できなければ、侘びをいれると、昔から先輩方に教えられてきました。

サポートの先生

私にとって　ニフティは、サポート業務における、大先輩であり、先生でもあります。どこかに書いてあるような、奇麗ごとではありません。実際の運用の現場で、実際の担当者が発するメッセージは、一字一句、見逃すことができない「教科書」です。そのニフティでも。。。。

監視する目

どんなに小さなトラブルでも、それをお客様と約束した瞬間から「大きな仕事」となります。管理対象のイベントです。ニフティ社員の方にとっては、どこのブログを参照しても、毎日のように目に入っているはずです。

どれだけの「監視の目」があるかはわかりませんが、少なくとも私のように感じている人は大勢いるのではないでしょうか。

食べられない饅頭

帰宅

いつもより、随分とはやい帰宅。男も40を過ぎると体のあちこちに｢がた」がくるようだ。会社でのノリも悪く、Webアプリの開発もなかなか進まない。

「1日あれば十分にできちゃう」。そう、思っていたのに、残念ながら1つ、機能が残ってしまった。

若いころなら、この状態で帰宅することはあまりなかったのだが、今日は帰ることにした。1日中、だるい感じだった。

おかえり

｢ガチャガチャ」。ドアを開けると、そこには一番下の子が驚いた様子で、「あっ、お父さん！お帰り～。ねぇ、ねぇ、お父さんが帰ってきたよ～？」。うれしいんだか、かなしいんだか、よくわかない状況になってしまった。長男の帰宅よりも早いらしい。食事の支度が、手際よくはじまった。

饅頭

「あっ、これは食べないでね。早く帰ってくるとは思わなかったから、４人分しかないのよ。残りの一つはお兄ちゃんが帰ってきてから、食べるんだからね。」

ビールも好き。でも、饅頭も好きなんだけど。

ほっと。。。

いつも騒がしい家であるが、どんなに疲れて帰ってきても、やっぱりほっとする。怒鳴ったり、笑ったり、ふてくされたり、毎日いろんなことが起こる。

今日みたいに、饅頭が足りないこともある。売る側の理屈は家族の人数は、平均4人なんだろうな。5人家族のことはきっと後回しなんだろうな～。でも、早く帰ってきたから、こんな｢事件」にも、遭遇することができたんだ。

路頭に迷うマニュアルは出現するのか

マニュアルだけを信じるな

ユーザサポートの業務をはじめるにあたり、チームのリーダーにマニュアルの整備をお願いしています。コンピュータシステムの運用現場では、「マニュアル」や「手順書」などの文書がとても重要視されます。コンピュータにアクセスするための方法や、プログラムの起動の仕方から、お客様から電話を受けたときの対応まで、なんでも「マニュアル」にしてしまいます。

では、マニュアルに書いてある通りに仕事をすれば、すべて上手くいくのでしょうか。中学生でも理解できるような操作マニュアルを作ることが出来上がれば、高いお金をはらってシステムエンジニアを雇う必要もなくなるのでしょうか。もし、そんなマニュアルが存在すれば、たちまち私たちはエンジニアは、路頭に迷ってしまいます。

ここでは、電気製品の使い方のようなマニュアルを指しているのではありません。システム構築や運用を経験された方なら理解できると思いますが、世の中に一つしか存在しないそんなシステムのさまざなな手順書などのことを「マニュアル」といっています。

記憶の案内人

では、なぜマニュアルや手順書を整理するのでしょうか？私の基本は自分のための記録です。自分が理解できる文章と、自分が考えた記憶たどることができれば、合格点なんです。マニュアルや手順書を書くことで、論理的に、ものごとを整理することができます。漠然と頭に描いていたことを、脳の中から、絵や文章にアウトプットすることで、もういちど再確認することが目的なんです。

ヒントは答えではない

マニュアルに書いてある通りのことができるだけの”能力”を持った人に、「この通りにやってください」と、ポンと書類を引き渡したことはありません。マニュアルや手順書で引継ぎができるとも思っていません。何かをやろうとしたときに、マニュアルを「参考」にはするけれども、書いてある通りに何かをするわけではありません。その時々の状況によって、発生した問題解決の糸口でしかありません。

マニュアルが書かれた時の状況や、執筆者が考えた「状況」とぴったり一致する問題が発生することはまれで、書いたときには予想もしなかったことが発生することの方が多いはずです。

復旧手順書は書けない

データベースがからんだシステムを開発すると、「バックアップ」と「リストア」は必ず書くことを要求される「手順書」の"たぐい"ですが、いつも書くことをためらってしまいます。特に、「復旧手順書」なんて、恐ろしくて書くことはできません。こんなときは、大抵前もってお客様に、こんなお断りを入れることにしています。

ある日、突然システムに障害が発生して、データベースを復旧しなければならない状況が発生したとします。その時、「このマニュアル通りにバックアップからデータをリストアしておいて」なんてとてもいえません。

昨日の時点のデータに戻ることで、いったいどれだけの影響があるのか。このマニュアルに誤りはないのか。関係部署との連絡は十分とれているのか。その復旧で二次災害は発生しないのか。

絶対に関係者が一同に会して、対策会議を開くはずです。その時、「構築時のマニュアル通り」に仕事が進むことなんて、だれも想像していないはずです。システムは日々更新されており、その時、その会議で決定したことが「復旧」の手順です。今書けることは、コマンドの使い方や、データの保管場所を記録することであり、「復旧手順」なんてものは絶対に作ることはできません。

それでも書きますか？

応用力

マニュアルは応用することができなければ価値がありません。自分が書いたあの時の記憶と、今の問題を見比べて、何をすべきか考えることができる。

マニュアルを書くことで、来るべき将来の問題を「今」想像する。発生するであろうさまざまな問題に対応できるように、一度脳の中を整理してみる。マニュアル通りにコトは進ません。でも、マニュアルを書くことでいろんなできことをイメージすることができます。そのイメージこそ、マニュアルを書くほんとうの価値ではないでしょうか。

フェアプライス

この言葉

成功のセオリーは、買い手の心を動かす価値の開発とフェアプライス

引用：鈴木敏文 考える原則

適正価格

フェアプライス、つまり適正な価格のこと。ここ数年の私のテーマでもあります。何気なく文庫本を読んでいて、考えていたことと、同じことが活字として目に飛び込んできました。なぜか、うれしい。

適正な価格でお客様によろこんでもらいたい。お客様が、「このサービス、このシステムならこの価格に納得できる」といっていただけるものを目指しているいます。安いだけでは長続きしませんし、かといって、他にはない商品を不当に高い値段を設定しても、だれも買ってくれません。

あいまいな価格

サービスの価格を決めるうえでの、注意していることはこんな程度のことです。

• 赤字にしない。
• 同じようなサービスの価格帯を日頃から確認、予想しておく。
• お客様が予定している価格を知る。
• 他にできないことなら、以外と高い値段。胸をはって価格に納得していただく。値引きはしない。
• 誰でもできるようなことなら、かなり安い値段。恥ずかしくて、「そんな値段は取れない」って感じ。

価格

サービスを買っていただき、満足していただいた時に、はじめてそのサービス、商品の適正な価格が決まるのかもしれない。

同じ価格でも次の機会には、今よりもっと内容を充実させることも大切だ。

システムエンジニアのサービスの価格は、いつも変動している。価格を下げることは絶対にしない。同じ価格でも、機能より効率の良い仕事をしていけば、お客様はきっと納得してくださるはずだ。納得してくださる価格こそが、適正価格。これからも肝にめいじて、フェアプライス。

新たな可能性を目指して

世田谷の事務所

川崎から世田谷の事務所まで、約1時間。待ち合わせの時間は午後2:00 だったが、電車の乗り継ぎが上手くいがず、10分ほど遅れてしまった。商談の内容は今までにない、新しい仕事の内容だったが、その場で即断することができなかったので、持ち帰り検討することにした。

お客様からは、プロの仕事を求められた。私のこれまでの業務経験にはない、大人の話だ。会話の内容についていくのがやっとの状態だった。話の半分も理解できただろうか。はじめて聞く仕事の内容。こんな話を聞けただけでも、世田谷の事務所に出向いた価値がある。

川崎の事務所

約1時間ほどの会話の後、急いで次の商談に向かう。約束の時間は 午後4:00。i-modeの乗り換え案内では、30分以上も遅刻することになる。ここは、タクシーを飛ばすしかない。どれくらい時間がかかるか皆目検討もつかないが、とにかくタクシーを捕まえて約束の事務所の場所を告げた。「40分くらいはかかりますよ。」と運転手さんの予想。これなら、5分前でぎりぎりセーフ。祈る気持ちでタクシーをとばしてもらった。

結局、事務所には約15分ほど遅れて到着。事前に連絡は入れていたが、初対面での遅刻は非常に罰がわるい。ここは気合をいれて、「笑顔」と「トーク」でなんとか挽回せねば。。。

大和の居酒屋

2つの商談ともにすぐに結果がでるものではない。はじめての方と、「お話」ができただけでも「ありがたい」ことである。仕事場に戻る気力もないので、大和の居酒屋に同僚と向かうことにした。

同僚のおすすめの店、これがまたよかった。ビールがすすむ。いかの塩辛、うますぎ。

鮮魚店を経営している会社の魚介料理店。新鮮さがウリのこの店のメニューは、丼、定食、にぎりまで約60種類と豊富にそろう。毎(水)は15種類の海の幸がのった魚貝亭どんぶり（1280円）が1000円に、毎(木)には、魚貝亭にぎり（1500円）が1200円になるサービスを実施しているから要チェック。

参照：[グルメウォーカー] 魚貝亭　大和店

本当の価値

私にとって、商談は一番の勉強の場である。お客さまの言葉を直接伺うことができる。知らないことを聞かれるかもしれない。難しいことを「わかりやすく」説明しなければないこともある。
商談で話をした数の分だけ、新たな可能性が増えていく。

でも、やっぱり話だけではなく、それを身のある姿に変えてこそ、価値があるんだろうな。

念ずれば花ひらくっかも

GW明けからが勝負

長～い5月のGW休みも終わり、昨日は休みぼけの状態で仕事に集中することができない状態だったが、いつのまにか今日、明日と立て続けに「商談」話が5件も入ってしまった。やっと年度のはじまりという感じである。例年通り、新しい商談に関するお話は、5月のGW明けからである。3月に立てた年度の計画はここから修正を余儀なくされる。

携帯電話にこだわる

2月ごろから、会社の中で、あることをずーっと言い続けてきたことがある。

なぜ、携帯がドコモなのかって？
決まってるじゃない。いつどこで、エヌ社に関する商談の話が舞い込むか、わからないじゃん。
そのとき、携帯電話が A社やB社のものじゃぁ～かっこ悪いじゃん。
だから、ドコモの携帯を使ってるんじゃん。しかも家族全員で。
子供たちの携帯電話も、できれば新しい機種を使ってくれってお願いもしてるんだぁ。
妻には「これも仕事上の投資なんだ」とちょっと苦しい説明までしてさぁ。

1本の電話

今日、会社に1本の電話がかかってきた。相手の方は、会社のWebサイトを見て電話かけてこられたらしいのだが、もしかしたら、「携帯電話を使い続けてきて」よかったと思えるような”きっかけ”の話になるかもしれない。

機会損失

会社にかかってくる仕事の電話は、よくよく確認してみると見当違いな話が、「まま」よくある。私の技術力の無さもあるが、ソフトウェア、コンピュータ関連の商談は話を持ち込んでくる方の思いと、私の持っている技術力がなかなか、うまく一致してくれない。他の業種のようにきちんと分業も進んでいないし、町の工務店のような会社間の組織のつながりも明確ではない。

機会を逃さず、仕事をばりばりこなしていければ。。。そんな思いは何年も続いている。でも、打開策はなかなか見つからない。今の技術で10年食っていける業界ではない。日々進歩する新しい技術を原理原則を見誤らないように適度に取り込み、取り込んだ技術は確実に自分のものにしていく作業と、お客様の思い、商談はなかなか一致しない。先に行ってもいけないし、かといって、今の技術にしがみついても先がない。

ネクタイとワイシャツ

明日は、白地に、緑、茶の縦縞のシャツに、赤のネクタイで出社することにしよう。春物のスーツも箪笥から引っ張り出して。普段はよれよれのスーツでも、こんな日は若返った気分で出社しよう。
出がけには、玄関の鏡の前で「笑顔」の練習も。。。

久しぶりに、わくわくする気持ち(^o^)

UNIX:ファイルを更新する

ガミガミ

UNIXのファイルを更新することは、システムを運用している方なら毎日のように行っていると思います。
ところが、ファイルを更新する「やりかた」は人によってまちまちで、あまり「こうしなさい」とガミガミいわれていないようです。

私の周りのSEの方々で、一番多いのは「vi コマンドでファイルを直接更新する」方法です。

しかし、この方法には問題があると思っています。私は、周りの人には毎年のように「○○のようにしなさい」と言っています。

可変長ファイルの更新

UNIXのviコマンドなどで編集するファイルは通常、可変長レコードのテキストファイルです。1行を１つの1レコードと考えると、各行の長さはまちまちで決まっていません。

空白や改行コードなどで、自由にレイアウトを決めることができる、便利なファイルですが、データ更新には全然向いていません。

途中のデータを1バイト削除することは、残りのデータ部分をすべて1バイト前に複写することになり、逆に1バイト挿入する場合はその逆に1バイト後に複写する必要があります。
結局、データを更新するということは、ごっそり新しいファイルを作成することと等しい結果になります。

元のデータ

 0  1  2  3  4  5  6  7  8  9
+--+--+--+--+--+--+--+--+--+--+
|# |t |e |s |t |f |i |l |e |LF|
+--+--+--+--+--+--+--+--+--+--+

1バイトを削除したデータ

 0  1  2  3  4  5  6  7  8  
+--+--+--+--+--+--+--+--+--+
|t |e |s |t |f |i |l |e |LF|
+--+--+--+--+--+--+--+--+--+

ファイルの更新

私は必ず、プログラムが参照するようなUNIXファイルの更新を、次のように行うように推奨しています。

• ファイルの存在するディレクトリに２つのファイルを作成する。
• １つはバックアップ用のファイル
• もう1つは更新用のファイル
• 更新用のファイルを vi でも emacs でも適当なエディタで更新する。
• 元のファイルの owner/group属性、パーミッションが同じことを確認する。
• 更新ファイルを mv コマンドで入れ替える。
• （同ファイルを参照しているプログラムを再起動する。起動のたびに読み込むようなプログラムなら次回起動から変更した内容が有効になる）

更新するファイルを /etc/hosts とすると、次のようなコマンド処理になります。

# cd /etc
# SUFFIX=`date +'%Y%m%d'`
# cp -p hosts hosts.$SUFFIX.new
# cp -p hosts hosts.$SUFFIX.old
# vi hosts.$SUFFIX.new    ←このファイルを更新
# ls -l hosts hosts.$SUFFIX.*
# (rm hosts)              ← この処理を行ってはなりません！！
#                            行った場合は、次のmvを行うまでの時間、
                             ファイルが存在しない空白の時間帯が
                             発生してしまいます。
# mv hosts.$SUFFIX.new hosts ← リネーム処理

なぜ、こんな更新をするのか

viコマンドで直接ファイルを更新しないで、わざわざこんな更新を行う理由は次のとおりです。

• viコマンドで一度ファイルを更新(write)してしまえば、ファイルのinode番号は変わってしまいます。後戻りはできません。
• 更新したファイルの inode番号は変わります。
• ファイルが存在しない時間はありません。リネーム(rename)処理で「旧ファイルの削除」と「ファイル名の変更」はOS内部で一気に行います。
• バックアップが存在します。

Linuxに付属する vi コマンドには、これよりもっと高度な機能が実装されており、わざわざこんな更新を行う必要はないのかもしれません。

ただ、ファイルの更新がどのように行われ、プログラムはどのようにデータにアクセスするのかを十分に理解した上で、毎日の運用業務を実践していかなければならないでしょうね。