やっとわかった

今週は

障害が2件、月末納品など、久しぶりにてんてこ忙しい1週間でした。特にシステムで発生した障害の原因、対策、検証には頭を抱えてしまいました。が、昨日、ひょうんなことから何とか目処が立ちました。ほっ

状況は

こんな感じでした。。。

• 水曜日：午後　システムトラブル(A)の連絡が入る。あわててセンター入り。運用対策はできたが、根本的な原因は解明できず。長丁場の予感。徹夜は年齢制限もあり、帰宅することに。
• 木曜日：午前　別件システムでトラブル発生(B)。自宅近くでの連絡だったので、そのまま自宅にUターン。自宅で対応することにする。いつも早く出社する方に関連資料をメールしてくれ～とお願い。なんとか解決した。
• 木曜日：午後　トラブル(A)の状況を関係者に説明。担当リーダのおかげで資料もなんとか用意。久々に3分で昼食という始末。そのまま深夜まで作業。
• 金曜日：午前　月末の納品作業。事務方も昼休みをつぶしての協力。いつもありがとう。
• 金曜日：午後　納品をすませ、すぐさまトラブル(A)の現場に。原因判明。改修を済ませ、検証試験を開始でした。あとは週明けの結果を待つだけ。。。

きっかけは

新人に言ったこの言葉です。

壊れたデータ、ダンプしてみた？データのダンプを見てみれば、何かわかるんじゃない？

そうなんです。幸にも、問題が発生したときのデータが壊れたまま残っていたんです。壊れたデータさえあれば、問題は解決できる。昔っから勝手にそう思い込んで育ってきました。野球選手は「ホームランを打ったときのあのバットのしなる感じ」とか、「三振を取ったときのあの中指の引っかかり」など言葉にできない微妙な感覚を頭の中で何度も「なぞって」います。スポーツ選手の間では、イメージトレーニングは今や常識です。良かったときのイメージを思い出し、体の反応にまかせるだけです。

そういえば「医龍」でも、手術前には、夜霧の中に、たった一人でメスを入れ、イメージトレーニングをやっていました。ね、坂口さん。

問題は解決できる。以前はこうして解決した。システムエンジニアでもイメージ（いわゆる第六感）で問題を解決するんです。マニュアルでは解決できません。想像力はすべてです。

6時間

、新人に言った手前、壊れたデータのダンプと「ニラメッコ」をしてみました。ジーっと見ているわけではありません。いろいろな見方をして、データの並び方に何か規則めいたものはないか、体の反応にゆだねてみました。

データを見るときは od コマンドを使います。以前は自分で作ったものを使っていましたが、最近は od コマンドにお世話になりっぱなしです。まず、"od -tx1"からはじめます。次に "od -tc"。ここまでは定番です。"od -td4"、"od -tx2"、"od -to4"、"od -tu4" 。。。。 何度も何度もデータの出力形式を変えて表示してみます。何度も何度も見ることで、頭の中の「記憶」を引っ張り出します。以前、このデータ見たことない？必死に自分に語りかけます。

データはじーっと見ていても何にもなりません。加工したり、ずらしたり、どんどん手を代えて、自分が(頭が）飽きないように工夫しなければなりません。久しぶりの、6時間あまりの「ニラメッコ」はちょっと快感でした。

発見した

ことは、"od -xd1" のときです。

このデータ IPアドレスっぽくない?
あっ、そっか～。だったら、ここがこうして、こうなって。ねっ？

IPアドレスとして考えれると、問題の原因がぼんやりと浮かんできました。

そこからは、「なだれ」のようにアイデアがわいてきます。あそこはこうしよう。ここは、こうしよう。"od" コマンドの出力結果に反応して、そして理屈に間違いがないことを確認します。

1人では解決できない

今週は本当に大勢の方の協力をいただきました。予定をすべてキャンセルして、トラブル(A)の対応に専念することができました。周りの協力がなければこれだけ早く、問題の解決への道筋を見つけることもできなかったでしょう。感謝。々々。

何か起きたときに1人で解決できることなんかたかが知れています。周りの方が協力してくれる環境があるからこそ、自分も仕事ができるんだと身にしみて感じた1週間でした。

1人でできることには限界がある。限界を超えるには協力が必要なんだ。もう一度しっかり頭に叩き込んで、前に進んでいきます。

ご迷惑をおかけします

すぐに行動

システムに問題が発生した場合、担当エンジニアはすばやく行動しなければならない。お客様への連絡、上司への連絡、そして状況の把握を最優先する。現場に移動できる場合はできるだけすみやかに現場に急行する。問題が発生したときに、その現場にいることが何より大切なこと。電話ではなく、関係者の顔が見える場所で作業をすすめることが、問題の解決を早めてくれる。

現場では刻一刻と状況が変化する。トイレに行くことだって、姿が見えない場所で作業をしていると大きな問題になったりする。その現場に「いること」で、さまざまな情報を入手し、的確な判断を瞬時に行うことができるはずた。

周りで飛び交う声を聞きながら、人の動きを見ながら、今起きている事との関連を整理しながら、最善の解決策を模索していかねばならない。

問題が大きければ大きいほど、電話だけでは解決できないことが多い。電話だけでは判断を誤ってしまう。

計画を説明する

作業にあたっては、2名以上で実施することが鉄則である。2人で別々の作業を分担して行うためではない。作業を実施している最中の、話し手と聞き手の関係で作業をすすめるためである。

作業は常にその計画を口頭で説明して行う。

・今から電源切るよ～
・サーバのログからエラーメッセージをカウントするね。
・アプリケーションを再起動するけど、いい？

人間は問題が発生するとあせってしまう。勘違いも起こしやすい。だから作業ミスをなくすためには「作業すること」を「話しながら」行う。計画に誤りがあることを、話し手本人が気がつくこともある。聞き手が気がつくこともある。計画、レビュー、実施、検証。このサイクルを繰り返して前にすすむ。どんな小さなことも、この繰り返しである。レビューを効率よく行うために、会話のできる環境で作業を行う。黙々と1人で行った作業の結果にはミスが付きもの。トラブルにさらに輪をかけて、トラブルを引き起こしてしまっては何にもならない。「石橋をたたいてそれでも渡らない」覚悟がなければ、問題は解決できない。

検証計画を立案する

原因が特定できれば、その改修を行う必要があるが、改修がすべて完了するまでの暫定措置、改修計画、検証計画、改修後の運用など大きな流れをまず確認する。小さな改修でも、大きな改修でも、まず全体像を関係者全員が頭の中にイメージして、それぞれの担当業務を遂行する必要がある。

特に大切なのが、「検証計画」である。改修した内容を検証することが確実にできなければ、「GO」を出すことはできない。「GO」を判断する方は、論理的な検証から導き出された「結果」を見て判断するしかないはずだ。自信を持って、「GO」と言える「結果」を出さなければならない。いくら口で「直しました」と説明しても、証拠がなければ何にもならない。

妥協しない

改修も検証も最後まで妥協しないで行う。解決できない問題はない。でも、解決できないトラブルは発生する。システムに問題が発生した時は、もっともエンジニアの真価が問われる時だ。小さなことにも妥協せず、精一杯お客様のため、自分が納得するまであきらめたりしない。

心の中に「ご迷惑をおかけします」の言葉を刻んで。。。

パスワードに悩む

rootのパスワードに悩む

UINIX管理者になった方が最初に悩むのは root のパスワードではないでしょうか？簡単には見破られず、かといって難しすぎて覚えられないようなパスワードでは困ります。覚えられないパスワードは結局、メモすることになるでしょうから。。。

簡単に覚えられて、しかも見破られない、そんなパスワードを設定する必要があります。

やってはいけない

ルートのパスワードに限らず、UNIXのパスワードでは次のような文字を設定することは絶対に避けるようにと、先輩から教わったものです。

• ログインユーザ名と同じ
• ログインユーザ名+123 など、数字を追加したもの
• 商品名
• 自分、家族、友達、恋人などの名前
• 生年月日

ようするに、意味のある（辞書に載っているような）単語、数字はパスワードに設定しないということです。でも、意味のない数字や文字なら覚えることができなくなり、結局メモすることになってしまいそうです。

パスワードも暗号化

では、どうすれば。。。私はパスワードは最初から暗号化して設定しています。UNIXのサーバ管理などで root のパスワードを関係者で共有する場合、意味のないランダムな数字や文字だと絶対にノートにメモする人がでてきます。こんなときでも、関係者だけが知っているルールで簡単な文字を暗号化して、パスワードにしています。

暗号化といっても、そんなに小難しい理屈は必要ありません。「クイズ」に答える程度の文字の変換規則を自分たちで工夫するだけです。

たとえば

週刊文春を元ネタに、パスワードを考えて見ます。まず、文を構成する単語をそれぞれ英語に変換してみます。週刊=weekly、文=sentence、春=spring。そして各単語の先頭、最後の文字、文字の長さを組み合わせてみます。

• 週刊=weekly -- "Wy6"
• 文=sentence -- "Se8"
• 春=spring　-- "Sg6"

あまりかっこいいパスワードではありませんが、週刊文春から "Wy6Se8Sg8" の文字列を作成することができました。

パスワードはちょっとした工夫

この方法なら、キーワードとルールだけ覚えて、パスワードそのものをメモする必要はありません。みんなが覚えやすいキーワードから独自のルールを通して、ランダムな文字列を作成する。パスワードにもちょっとした工夫を普段から心がけたいものです。

でも、キーワードやルールをメモしてしまうと、まったく意味がなくなってしまいますので、ご注意を

そのパスワード、見えてるよ

パスワードを忘れる

Windows のログインパスワードや、USBメモリにアクセスするためのパスワードを皆さんはどのように設定していますか。「パスワード」なんだから他人には絶対に推測できないパスワードになっていますか？

私が新人のころは、初めてUNIXのログインパスワードを設定するだけで、「ウゥ～ン」と頭をひねって「これなら」というパスワードを考えたものです。気に入らなくなるパスワードを変更したり、いくつもの候補を用意していました。

で、パスワードを使い回しているうちに、「今のパスワードってなんだたっけ？」なんてことになっていました。どのパスワードをどこで登録したのかわからなくなってしまうんです。私が設定したUNIXのrootのパスワードを忘れたときには、先輩にひどく怒られたものです。当たり前です。。。

パスワード盛り

今の時代、インターネットでユーザ登録する機会が本当に増えてしまいました。メルマガ、インターネットバンキング、Amazonのアカウントであっても、とにかく会員登録するサイトでは必ずパスワードを設定することになります。それぞれ違うパスワードを設定するなんて暴挙にでれば、頭の中はそぐにオーバーフローしてしまいます。サイト毎に異なるパスワードを設定するなんて絶対に無理なことです。最初の1、2サイトまではいいんですが、登録するサイトが増えるにしたがって、「なんて馬鹿なことをしたんだ」と悔やむこと、間違いありません。

UNIXでの原理原則

そもそも、MS-DOSのころは、パスワードを入力する操作なんて必要ありませんでした。UNIXのようにマルチユーザ環境ではなかったため、電源を入れればすぐに使うことができました。今のXPにしても設定すればユーザ名、パスワードの入力操作を省略することができます。パスワードに関してあまり神経を使っていないOSのようです。

でも、UNIXはマルチユーザ環境を提供するＯＳです。作業をするためにはユーザ名とパスワードを入力してログインする必要があります。このログイン時に入力したパスワードは画面に出力しません。Windows などのように '*' を表示することもありません。パスワード入力時はキーボードで何を入力しても応答がありません。最後のリターンだけに反応します。

パスワードの取り扱いについて、UNIXというOSはとにかく神経を使っています。

• 入力するパスワードは画面に出力（エコー）しない。覗き見防止です。
• パスワードを元のまま保存しません。保存している情報はハッシュ値です。
• パスワード長、文字の組み合わせも制限できます（設定すれば）。

不用意なUNIX管理者

ところが、UNIXシステムを管理するエンジニアの中には、そこまで気を使っているパスワードをいとも簡単に公開してくれたります。本人に悪気はないと思いますが。。。

UNIXはマルチユーザ環境であり、マルチプロセスなOSでもあります。誰かが gcc をソースプログラムから丸2日かけてコンパイルしている最中でも、ｆｔｐ でファイルをダウンロードすることができます。

ここでもし、「mysql -uroot -pRootPass 」などのコマンドを入力して、データベースの保守を行っているエンジニアがいたら、どうなるでしょうか。そうです。ログイン中の一般ユーザであれば、誰でも　データベースの管理者のパスワードを拝見することができるんです。もう、気付かれましたか？

正解は ps コマンド。UNIXで処理中のプロセスは ps コマンドで確認することができます。起動時に入力したパラメータ情報もです。つまり、だれかが mysql -uroot -pRootPass と入力して作業をしている最中に、他の誰かが ps -efwww とでも入力すれば、たちどころに RootPass は無防備に画面に表示されるはずです。

「パスワード入力っていちいち面倒くさいなぁ。コマンドラインでパスワードが入力できれば、一連の処理をバッチファイルにかけるのになぁ～。」そんなふうに思っている方も多いことでしょう。でも、コマンドラインでパスワードを絶対に入力してはいけません。大事なパスワードを裸にしてどうするんです。

パスワードの取り扱い

ここ数年、機会あるごとに、パスワードの管理についてお願いしてきました。

• パスワードをノートに絶対にメモしない。
• パスワードを声に相手に出して伝えない。
• メールでパスワードを送信しない。
• パスワードを構築手順書に書かない（お客様から要求された場合は別ですが）。
• コマンドラインでパスワードを入力しない。

私がパスワードを伝えるときは、キーボードに指を置きながら「ここ、ここ、それにここ。。。」なんて感じで伝えています。パスワードの取り扱いにはくれぐれもご注意を。

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

約束の時間

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

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

5分前

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

意外とせわしい

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

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

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

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

ちょっと、遅れる

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

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

コーヒーでも飲んでから

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

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

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

杓子定規にはいかない

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

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

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

迷惑メールに法規制

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

第一条

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

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

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

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

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

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

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

特定電子メールの定義

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

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

表示義務

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

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

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

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

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

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

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

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

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

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

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

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

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

送信ドメイン認証

迷惑メール対策として、プロバイダのメールサーバから外部に発信するメールには、次のような電子署名のようなヘッダがついています(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 の社員が勝手に会話を録音すれば、録音したほうが罰せられる。表現の自由、思想の自由を守るために。

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

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

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

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

不安が募る。。。

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

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

周りは殿派

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

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

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

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

部長殿

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

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

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

正しい表現、「様」

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

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

正しい表現、「殿」

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

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

誤った表現、「殿」

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

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

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

山田商事 田中殿

相手が満足すること

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

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

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

ご無沙汰です、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月？」と機転をきかすことはできません。

世間の常識

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

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

サポートの先生

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

監視する目

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

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

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

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

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

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

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

記憶の案内人

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

ヒントは答えではない

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

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

復旧手順書は書けない

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

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

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

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

それでも書きますか？

応用力

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

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

新たな可能性を目指して

世田谷の事務所

川崎から世田谷の事務所まで、約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^)

お客様のこの言葉を聞きたくて

アンケートなのか

顧客満足度(CS: Custmer Satisfaction)をアンケートをとって、分析する。最近は、品質マネージメントシステムを導入している企業も多くなり、取引先の企業にアンケートをお願いする営業の方もいらっしゃる。

アンケートのとり方、分析の仕方など、「顧客満足度」を数値化して、評価する手法もたくさん存在するようだ。

顧客満足度を数字で表現するということは、すごく簡単に言えば、「近所のヨークマートに私が不満なのか、満足しているのか」ということを、私ではない、どこかのだれかが、「たぶんこうじゃないかな」と推理して、顧客満足度 100%とか、50%とか評価することなんだろう。「度」というからには、分母には私がヨークマートに期待する思いのすべての項目数があって、分子は満足した項目数ということになる。

式にするとこんな感じかな？

   　　　　　　そのうち、私が満足した項目数
　 ----------------------------------------   ×  100 (%)
   私がヨークマートに期待するすべての項目数

どこで分析するの？

私が近所のヨークマートに期待することは、「安い」、「安全」、「商品を手にとって確認できる」、「試食ができる」、「レジで待たない」、「明るい」、「キレイ」、「楽しい」。。。。そして、隣のイトーヨーカ堂に負けるな。でも、きりがない。求めていることは毎日変わるし、そもそも私は近所のヨークマートに何を求めて商品を買いにいっているのか、いちいち気にしたこともない。大きな問題がないから、近いから、イトーヨーカ堂より空いているから、など大げさな理由があるわけでもない。だからといって、100%満足しているわけでもないのに、どこかの調査会社は私の気持ちを分析できるらしい。すごい！

お客様の立場

私でない、どこかのだれかが、私の満足度合いを知るためには、私に代わって買い物をしてみないとわからないことだ。

妻と買い物をするときは、私はメインの肉だ、魚だをまず決めてから、それに合わせて食材を探して歩く。入り口近くの野菜、果物を通り過ぎて、奥の生肉、生鮮魚のコーナーから物色する。そんな行動をして買い物をする私の満足度をどうやって評価しているのだろう。

結局のところ、私になったつもりのどこかのだれかが、「こんなシチュエーションで買い物をしてみよう」と考え、実際に買い物をしてみて、何かに気がつき、そして私の思いに近いことを、予想するしかないんじゃないか。

私の気持ちを理解しようなんて無理なことは考えず、顧客満足度を分析、評価する人が、私になったふりをして、自分の気持ちで判断するんじゃないだろうか。

さらに先を

もっと賢い人ならば、「あなたはこれが欲しかったんじゃないですか」とさりげなく気づかせてくれるだろう。「あっ、そうか。俺はこれが欲しかったんだ」と、気がついたとき、そのお店にはまた何かを期待する。不満はないけど、満足しているかどうかもよくわからないけど、何かを期待して、そのお店に足を運ぶようになる。

「お客様が満足してくれているだろうか？」と考えることではなく、「お客様はこんなものが欲しいのかもしれない。それにお客様自身が気がついていないだけなんじゃないだろうか。要求仕様書には書いていないけれど、こんな形で実装してあげれば喜んでもらえるかもしれない。こんど相談してみよう。」という行動が、一番大切なことではないか。

そうそう。そうなんだ。私が欲しかったものは、こういうものだったんだ。

この言葉の一つ一つの積み重ねこそが、システムエンジニアが目指すべき、顧客満足の姿だと思っています。

春は運だめしの季節

春

景気が上向いているらしい。でも、ここ最近は新しい仕事がなかなか決まらない。工数削減、予算削減など大合唱のなか、今使っているシステムをあららしいものに変える（リプレース）だけの気力にみなぎる方が少なくなってきた。3月から続いていたシステムの開発業務が、4月に入ったら一段落するばずだった。「そしたら休みがとれる」。家族にはそういっていたが、4月も半ばを過ぎてしまった。

仕事が決まらなくてもあせってはいけない。いつも「あせる」気持ちが先にたってしまうが、「落ち着け」と言い聞かせている。あせって入れた仕事は長続きしない。

舞

この時期は仕事の変わり目。今日も「こんなことできない？」と、その方は私の机にほおづえをついて、しばしの間の世間話。私の仕事が落ち着きそうになると、新しい仕事の話が舞い込んでくる。まるで、スケジュールを理解しているかのように。

違うよな。私がばたばたしていると、別の仕事の話はしずらいんだろうなぁ～。ばたばたしていても、冷静に仕事をしている。そんな演出ができていれば、もっとたくさんの仕事をこなしているかもな。

そんなこんなで、ここ最近、仕事がなくて、困り果てたことはあまり記憶にない。仕事の話が聞けることはありがたいことだ。感謝。

キャリア

自分のキャリアは仕事とともに勝手に形成されてきた。恥ずかしい話、お客さんのほうが私なんかよりよっぽど勉強している。新しい技術も、新しいシステムの設計方法も、最近の業界の話題も、お客さんの「商談」のなかから得ていることが多い。

• 今度のphp5のPDOなんだけど、結構使えるかもよ。
• Xenは意外ときてるかもよ～
• PostgreSQLも性能がずいぶんと改善されているようだよ。

そして、私も勉強する。相談されれば勉強せざるを得ない。受注できれば設計する。開発する。試験する。仕様書も書く。障害が発生すれば、とことん調べる。気がつくと、好むと、好まざるにかかわらず、私のキャリアになっていく。「キャリアパス」は考える時間も、余裕もなかった。

運だめし

自分が「こうしたい。」、「ああしたい。」と思っていても、お金をはらってくださるお客さんと考えが一致しなければ商談は成立しない。キャリアも仕事も、実は運まかせである。

自分ができることは、新しい商談の話を聞くことができる準備をしておくことである。今の仕事を楽しく行い、経験と知恵を身につける。こうしたい、ああしたいと思って日々を過ごす。次の難題に応えるための、知識や、応用力、発想を鍛えるために今の仕事がある。

すると不思議なことに、仕事の話がやってくる。

春先の商談は面白い。自分の思うこと、考えてきたことと、お客さんが思っていることが「たまたま」一致したとき、新しい仕事が動き出す。筋道は何本もあって、この道を行けば正解なんてあるはずもない。

だから、春は運だめしの季節

一周遅れのトップランナー

はっ！

本音をいわせていただければ、僕は出遅れてしまったと思っています。

はっとしました。私が20年前からずーっと感じてきた言葉、そのまんまです。面接の最後のあたりで、相手の方は少し、ためらいがちにそんな言葉を口にされました。
そう、会社勤めももうそんなになります。会社で面接する機会も多くなりました。。。

負い目

わたしが在学中のころ、教授が推薦してくださった企業の内定をあっさり断りました。「推薦状は返しておいてください」と教授も少々ご立腹。卒業はしましたが、その後、教授とはお会いしていません。多少の負い目もあります。

内定を断った理由は、本当に個人的な理由です。「もう一度、チャレンジしたい」との”ある”思いから就職拒否。そして、そのまま３月に卒業しました。フリーターです。当時は、「プー○○ー」と言われました。

甘い誘い

しかし、その夢も敗れ、半年後の10月に就職。短いプー○○ー生活でした。週刊就職情報がタウンページくらい厚みがあったころです。就職先に不安はありませんでした。なかでも目を引いたのが「ソフトウェアハウス」です。聞きなれない業種でしたが、圧倒的な数（求人数）を誇っていました。

• 初心者でも歓迎します
• はじめての方でも大丈夫です
• もっと気楽に考えてみませんか

横浜勤務で、気楽に働ける？
ソフトハウスってそんにいいのか？

そんな程度の思いで小さなソフトハウスに就職。そして、１ヶ月後には派遣先での勤務がはじまりました。(T-T)

それからは、「出遅れてきたんだ」といつも心のどこかで感じてきました。この20年間。夢敗れて、何も知らない業界、ソフトハウスに就職し、すぐに１人で派遣先へ。あのとき就職していたら。。。出遅れたとの思いは私も同じです。

パラダイムシフト

一周遅れのトップランナーってわかりますか。たとえば、□□□銀行。バブル時代に他の銀行が不動産投資に目がくらんでいたろ、頑なにそれをしなかった。
できなかったのか、しなかったのかそれはわからないが、気がついたら不良債権を持っていない。そしてトップになってしまった。

○○コンピュータ。あそこは、頑なにCOBOLにこだわった。
汎用系からオープン系へ人が流れたときでも、COBOLにこだわった。そして今。オープン系への流れは変わっていないが、汎用機の世界はいまだ大きく存在しています。
COBOLのエンジニアは実は不足しているんです。まわりに「いない」となれば。。。

着実に仕事をしてきたことに何も負い目を感じる必要はありません。経験はあなたの財産であり、時代が追いついていないだけなのかもしれない。何かを「やりたい」と思ったとき、それがあなたにとっての新しい「スタートライン」なんです。

【記注】私の会社の社長の言葉です。こんなこと書いていたら怒られそう。。。(^^ゞ

この言葉の意味は「時代遅れ」という悪い意味と、「パラダイムシフト」的な良い意味に使われるようです。社長が言っていることは、もちろん「パラダイムシフト」のほうです。

真面目に着実に仕事をすることに、「出遅れ」なんて感じる必要はないんですね。 (^o^)

サポートの信頼はきっと文章から

何気なく。。。

ブログの右隅に、いつも表示される｢ココログからのお知らせ」。何気に読んでみるとなぜか、「すっきり」、「丁寧」な文章がそこにあります。文章も短く、きちんと構造化され、言いたいことが伝わってきます。普段、ニフティとは別のサポートの方からメールをいただくことも多いのですが、だいたい「もやもや」した印象を受けています。

3月20日の「3月28日 ココログベーシック／プラス／プロ機能概要」において、新アクセス解析の導入スケジュールについて4月3日の週にご案内させていただく旨をご連絡いたしました。

。。。

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

この度はご迷惑をおかけしております。
何とぞご理解のほどよろしくお願い申し上げます。

ココログスタッフからのお知らせルーム
新アクセス解析導入スケジュールに関しまして

何がいけないのか

自分の文章は長くて、わかりずらい。言葉を選んで、わかりやすい文章を書くことを心がけてはいても、やっぱりうまくできない。いつも、「これで伝わるのか」と、悩んでしまう。すらすら思ったこと、イメージしたことを文章にすることが「なかなか」できない。文章を書く才能には恵まれなかった。。。

でも、自分にも「お客さま」がいる。できなければ、できるようにならなくては。相手に「トラブル状況」を報告することは、本当に難しい仕事です。誤解が誤解を呼ぶ事もあります。書いた本人の気持ちが伝わらないことも。冷静に書こうとしても、どうしても「言い訳」っぽくなってしまいがちです。

身勝手な感想

そんな思いのなかで、「新アクセス解析導入スケジュールに関しまして」というお知らせを見ました。何がどういいのか、きっちり説明できません。ただ、普段、他のサポートからいただいているメールとは明らかに違う印象を持ちました。

「お客様にご迷惑をおかけしているのが現状です」

トラブルの原因を長々書くのではなく、｢現状です」と一言。｢非常に残念です」とも読めます。なぜか、真剣さが伝わってくる感じです。

「トラブルの一刻も早い解決が我々の最優先」

取り組むべき最大の課題を最初に明確にし、問題に対する決意みたいなものを感じてしまう。

「スケジュールをご案内することが厳しい状況」

丁寧な文章。自分なら、「スケジュールを検討していますので、もうしばらくお待ちください」となってしまうだろうな～。

「4月中にはご案内できるよう」

最後にきちんと｢期日」を明記している。｢もうしばらくお待ちください」で終っていない。よく「期日」を明記しないで、”がんばっていますので”的な文章を見かけますが、期日がないと「いつまで待てばいいの？」とすぐに疑問を抱いてしまいます。待つ側にとっての目安として、期日はとっても重要だと思っていました。

文章力

サポートへの信頼も誤解も、文章の力で決まってしまう。
自分もこんな文章が書けるように、もう少し勉強しなくては。。。

注意事項

この記事は、ニフティのサポートやトラブルとは一切、関係ありません。あくまで、サポートの文章を読んでの感想文です。ニフティのサポートがいいとか、悪いとか、そのような意図はまったくありません。

左手にいる相棒

腕時計

システムエンジニアにとって、時計は必需品です。しかも、秒単位で時刻があっていなければなりません。

電車の時間に乗り遅れないように、会議の開始時刻に遅れないように、といったことではありません。
保守作業時に「アプリケーション」の起動や停止時刻をメモしたり、 ntpで時間があっているはずの、サーバやパソコンの時計が合っていることを確認したり、 システム運用における「時計」としての機能を自分の腕につけておく必要があります。

昔から、時計にはお金をかけたことがない私です。
高価な時計は左手に必要ないと思いますが、月に何度か秒単位まで針をあわせるように心がけたいものです。

目覚まし時計

「目覚まし時計」はデジタル表示の電波時計のものを使っています。正確な時刻に大きな「音」が鳴ってくれることと、その時の時刻をデジタルで頭で判断するためです。

デジタルであれば、朝、起きたときに、07:05 など数字を見て、目覚ましをかけた時間どうか、予定よりも過ぎているのかを瞬時に判断できます。

ただ、私は頭の回転は鈍いのか、「あと何分で家を出る」ということを考える場合には、デジタルだと困ります。瞬間にイメージできないのです。時計の数字の足算、引算を瞬時にできないので、この時計は起きるためだけに使っています。

掛け時計

家のリビング？には、もう25年以上も前に実家で購入した、振り子時計があります。この前、電池を変えたばかりなんで、しっかり動いています。（ずごい！）私はこの時計で、「あとどのくらい」という時間を判断しています。私にとっての「時計」はこれです。子供たちには相手にされていない時計です。

昔っから見慣れた、針が3つ。動いているか、止まっているのか、はっきりしない動きをしていますが、その針が指している絵を見て、あとどのくらいかを判断します。この時計、ずいぶん昔の時計ですが、カチッ、カチッとは秒針は動きません。微妙に、すーーっと動いています。こいつが家に来たとき(25年以上前です)、じーっと眺めて、秒針が動いていることを確認して、妙にうれしく思ったことを記憶しています。いまでも、ときとぎ、その時計の10cm以内に顔を近づけ、じーっと秒針とにらめっこするときがあります。やはり、針が微妙に動いていることを確認できると、"ほっ"と安心しています。へんなクセです。

アナログ派

私にとっては、時計はイメージを瞬時に思い浮かべることができるアナログでなければなりません。デジタルだとどうしても、計算してしまいます。
だから。。。

私の左手にあるのは、カシオのデジタル時計、G-SHOCKではなく、新聞広告のチラシを見て買った「ELGIN」の安い時計です。安い時計ですが、太陽光で充電でき、電池も必要ありません。デザインも、非常にシンプルです。文字盤の数字も"1"から"12"まで大きく、はっきり見えます（近頃、目も歳をとってきました。。。とほほっ）。チタンだから(?)、ほどよい重さで、重くたくも、軽くもありません。
しかも、3つの針のアナログ時計です。もちろん、毎月、秒単位まで針を合わせています。

「もっと、いい時計しろよ！」。お叱りの言葉が聞こえてきそうです。。。

卵を割らなければ、オムレツは作れない

やってみて

自分は新しい仕事をするときに、まず、やってしまう。若い方に頼むべき仕事もやってしまう。別に若い方の仕事が好きなわけでも、やることがないわけでもない。やってみないことには、指示も出せないし、どの辺が難しいか判断できないからだ。ひとしきり、自分が満足いくまで、足を踏み込んでしまう。いやな上司！
いっしょに仕事をする若い方にとってはいい迷惑だろうな。任せてもらっていない、信頼してもらってないのではないか、きっとそんな疑念もよぎっていることだろう。

いろんなことを総合して判断するためには、自分なりの｢ものさし」がどうしても必要になってくる。今の仕事で一番大切なことは、お客様と約束した期日に仕事を終らせること。新しい技術を使った現場では、スケジュール通りに作業が進捗しないことは多々発生する。「がんばります」と言っても、お客様は納得しない。どれだけの労力をかければ、期日までに仕事が終るのか、経験がなければ判断もできない。
「どれだけ時間をかけてくれても、かまわないよ」など、神様みたいなお客様は存在しない。

技術者として、新しい技術も使ってみたいし、でも、期日までには仕事を終らせなければならない。何が必要で、何が余計なのか、この目で見て判断するために、この歳になっても「まず、やってしまう」。いかん！

いってきかせて

おおよその判断ができるようになって、初めて若い方に仕事を割り振ります。でも、質問はなかなか来ない。できているかといえば、できていない場合もある。「わからなければ早くいってくれればいいのに。。。」。お客様は技術者の勉強のためにお金は払ってくれません。そんなお金はどこからもでてきません。

話してくれなければこちからから話しに行きます。問題があれば、「なぜ」なのか、「どうしたい」のか延々に話をします。長い話になることが多いので、いやがられているでしょうね。

作ったものを見せて、同じ話を何度でもします。しばらくすると話の内容が変わっていることもあります。設計、開発が進むにつれ、どうしても気に入らないことがでてきます。そんな時、迷わず「きれい」な方法に切り替えちゃいます。「昨日と話がちがうんじゃ？」。そう感じる方もとっても多いと思います。

私が新人のころ、「今、やることないんだよな～。さばちゃん、適当に遊んでていいよ。」って。えーーーっ。その後は、仕事が決まるまで（正確には上司の方からお話があるまで）、本当にそのまま、半年が過ぎていきました。6ヶ月です。その間、本当に遊んじゃいました。vt100の端末制御コードで遊んだり、BSDの通信プログラムを移植したり、emacsにもこのころ出会いました。lispも見よう見真似で書きました。みんなでCの勉強、UNIXの勉強だと大号令がかかっていた時代です。今のようにすぐれた書籍もありませんし、ネットで情報を検索することもできません。頼りになるのは、ソースコードだけ。周りの人も知らないことだらけ。勉強することにお金をかけていただけた、神様のようなお客様があちこちに、いらっしゃいました。感謝しています。

させてみて

で、やってもらうことの大半が試験ということになります。コーディングも設計書の作成も最終的にはやってもらうことになりますが、特に試験には大きな比重をかけています。試験をすることでやっと全体の設計を理解できるようになると思っています。何が足りなくて、何が問題なのか、試験を通して学ぶことができます。

また試験は、自分の勉強のために時間を有効に使うこともできます。私は、手作業でまる5日かかる試験であれば、4日間、試験プログラムの作成に知恵を絞り、あとの1日で試験を何度も行うようにしています。このプログラムは自分の労力を軽減すればそれでかまわないので、自分が使いやすいことに重点を起き作成します。あちこちに、a.sh、 b.pl 、c,php、d.c などのファイルが散乱します。

試験の中から自分なりのスタイルを見つけてきました。

ほめる！

最後のこれがなかなかできない。結果を褒めてあげることが上手にできないことが、私の最大の欠点です。だれでも、褒めてもらえば悪い気はしなだろうし、次の仕事に繋がる活力にもなる。マラソンの小出監督のように褒めること。みんなの前で褒めてあげる。気持ちよく聞き入れてくれる「言葉」で褒める。できないな～、なかなか。 毎日、小さなことでも1つ褒める。ありがとうという気持ちで。これこそ、率先して「やってみて」にしなければならないことなんだろうな。

卵

仕事の結果を褒めるのか、その人を褒めた結果が仕事に繋がるのか、そんなことはわからない。卵を割らないことには、オムレツは作れない。「やってみて」も大切なことだと思うが、｢褒める」ことも大切なこと。書いているうちに、自分の頭の整理がすこしできてきたぞ。「褒めて」みないことには、はじまらないんだ。

選手との絆

怒涛の攻撃

７回、日本は怒涛の攻撃
0対0で迎えた、7回表。
先頭4番、ソフトバンクの松中がライト線のツーベース。執念のヘッドスライディング。クッションボールも味方した。セカンドベースをこぶしでたたきつけ、雄たけびをあげる松中。重圧のなか、技術論やその日の調子なんて関係ない。
続く横浜多村は送りバント失敗。あっー、やな雰囲気。でも。。。。
ここで、ロッテ今江に代わって、代打福留。不振にあえいでいた中日の福留をこの場面で王監督は起用した。
真ん中のストーレートを投げた瞬間、テレビの前の父も雄たけびをあげる。「いったー！」。 右中間スタンド中段に、白球はすいこまれていった。2-0。ここから、日本の怒涛の攻撃が始まる。。。

チームのため

野球選手のよく口にする言葉、「チーム」のために。WBC(ワールドベースボールクラシック)でも、インタビィーをうける選手が口にする。では、チームのためにいったい何をするというのか。サインどおりに送りバントをすること「だけが」チームのためなんだどうか？自分のやりたいことをやらないことがチームのためになるんだろうか。

野球はバラバラなスポーツ

野球というスポーツは試合に出場する選手9人はそれぞれ、バラバラな動きを要求される。ピッチャー、キャッチャーなんてまったく違う技術。内野の連携プレーでは、外野手は蚊帳のそと。でも不思議なことに、9回まで、同じ数だけバッターボックスにはいり、ピッチャーと対戦することができる。4番も9番も、イチローも里崎も同じ数だけ。。。
だから、１人がいくらがんばっても、打つチャンスは同じ数しかない。ピッチャーがいくらがんばっても、サードがぽろりとボールを落とせば試合に負けてしまう。一人一人のやらねばならいことはまったく違う。だから、チームワークと選手は口にする。

チームワーク

チームワークはなかよしグループでは成り立たない。一人一人が仕事をそれぞれが完成したとき、そのバラバラの仕事が集まって、はじめて勝利を掴み取ることができる。お互いの仕事を理解して、相手にまかせた仕事は相手に任せ、自分は自分の仕事に集中する。送りバントの失敗はあったけれども、あの鉄柵のフェンスぎりぎりのファールフライを決死のダイブでアウトにした多村選手。まかりまちがえば大怪我をするところだ。そして、送りバント失敗。でも、8回には駄目押しのホームラン。自分のできる仕事に集中して。。。

彼の気持ちをチームメイトは理解している。だから、試合では決して同僚を責めたりしない。次はやってくれる。そう、信じている。だから、福富のホームラン、多村のホームランも生まれる。あの場面で、代打に福留を送った指揮官（コーチの進言かもしれませんが。。。）も調子の悪かった福留を信じていたはず。「なか日が1日あったし、気分も変わってきてるはずだ。。。」。指揮官の直感は見事に的中する。

絆

どんな場面でも、お互いを信じることができる選手。ここぞ、という場面で選手をつぶさに観察している指揮官。この絆をもって、試合に勝ったときに「チームワークがいい」とはじめて言われるものなのかもしれない。

お互いを信じることができる「絆」こそ、チームを勝利に導く。

転ばぬ先にNASを買い替える

毎年、NASを2台購入

毎年、会社で使用しているNAS(Network Attached Storage) を2台づつ購入してきました。もう3年以上になります。5万円程度のNASですが、だいたい1年で買い換えてきました。

さば：「今年も買い換える予定なんで、最近の機種、調べてくれないかな？」
若者：「え～、また買い換えるんですか？そんなに必要なんですか？」
さば：「ちょっとね。」
若者：「まだ、容量的には大丈夫なんじゃないですか」
さば：「ちょっとね。」

NASとは

NASは、ネットワークに接続して利用する、ファイルサーバの専用装置です。最近のものは、家庭用向けのNASであれば、外付けディスクとほとんど見分けがつきません。その程度の大きさです。管理用のインタフェースも多くがブラウザから行うものが主流になっています。あくまで、家庭用のものです。新人の方でも簡単に管理者の仕事をお願いできるので重宝してきました。

業務で使用するものでは、1テラで数100万を超えるものもあります。必要なところには、必要な投資なんでしょうが、グループで使用するNASにそれだけの投資をお願いすることはできません。でも正直、この部分に一番お金をかけなければならないのではと、周りの方に説明してきたことも事実です。どの程度の金額が適正なのか、未だ判断できていません。

NAS履歴

今まで使用してきたNASです。家庭向けのNASは寿命が短い。壊れたという話もよく聞きます。トンズラ？ってことでしょうか。

初代(ET-NAT60G)

Ｉ・Ｏ・ＤＡＴＡ社。当時はとにかく安かった。だから、安かろう、。。。
箱を開けて、ディスクを別のパソコンからマウントして、中の状態を確認しました。Linuxを搭載しているようだったので、rsync を書き込んで、cronから毎晩起動するように改造しちゃいました。2台のNASで、冗長化構成のシステムが格安の値段できでたことがとても記憶に残っています。

2代目NetPocket(LHD-NAS160)

ロジテック社。なんといっても、当時は消費電力の低さでした。25W程度なんて、蛍光灯なみです。24時間運転しても、電気代が気になりません。でも、結局故障しました。最悪の状態で。。。OSもNAS専用の独自OSで、いろいろ手を加えることができませんでした。とほほ。。。

3代目LANDISK(HDL-250U)

Ｉ・Ｏ・ＤＡＴＡ社。ちょっと熱くなるのが気になりますが、薄型、清音はディスクトップ向きです。一部、故障状態もありましたが、現在は後進にあとをゆずり、現役を退いています。

4代目LANDISK(HDL-300U)

3代目と同じ機種ですが、容量を300Gにアップしました。今の現役選手です。消費電力は20Wを切っていると思います。本当に、ハードディスク程度の大きさです。でも、やはり1年保障の商品です。1年たったら、買い換えないと。NFSにも対応していません。やはり、初代と同じように改造するしかないかな。。。

番外編HD-HBGLU2

NASとして買ってきたものでしたが、今はソルダムのPANDORA Rhapsody(真っ赤)のUSB外付けディスクとして使っています。性能には満足しています。

次は何にしよう

RAIDを信用していないわけではありませんが、メモリ、CPU、電源まで含めたとってもわかりやすい冗長化構成が好きなだけです。安物買いの銭失いと言われないように、次回NAS購入計画を真剣に考えないと。。。
身近なもので、使いやすいシステムを考える。身近なことで考える。だれでもできそうなことを工夫する。

ハードディスクは必ず壊れる。
１つ壊れたら、必ず同時期にもう一つが壊れる。

壊れてしまえば、すべてが無
転ばぬ先に、NASは新品に買い換えよ～っと

ペアプログラミングの再考

交代制のコーディング

敬愛するM先輩から、はじめてペアプログラミングについて説明していただいたのはもう、5、6年も前のことでしょうか。よく覚えていませんが、こんな会話だったと思います。

ねぇ、さばちゃん。ペアプログラミングって開発手法を知っている？2人、あるいはそれ以上で1つのプログラムを交互にコーディングしていく手法らしいんだよ。この手法だと、24時間、3交代制でプログラムを開発できる時代が来るのかもしれないよ。

今まではさぁ、このプログラムは僕、こっちはさばちゃんの担当、なんて決めてたでしょ。どうもそれは効率が悪いってことらしいよ。お互い、違うプログラムをコーディングしていくと、担当が休んだり、その中身がよくわからなくなったりしちゃうじゃない。わからないから関数仕様書を書けだとか。でもって、プログラム以外に文書を書く量が圧倒的に多くなるわけでしょ。これって、非効率なんじゃないってことらしいよ。でも、2人でコーディングしているんだったら、最低限、2人の約束事を決めてさ、気に入らなければ修正すればいいだよね。直したことろは、モニタでソースコード見ながら話しちゃえばいいんだよね。
究極的にはさぁ、同じプログラムを交互にコーディングしていくわけだから、「疲れたからちょっと交代」なっていう技も使えちゃうわけじゃない。これってすごくない？

エクストリームプログラミング

Kent Beckさんが、Planning Extreme Programming を提唱してから、何年たったのかわかりません。これに関しては、IBMのWebサイトの2つの記事が参考になります。翻訳ものですが、エクストリームプログラミングとはなんなのかは理解できると思います。将来、リンクが切れないことを祈ります。。。

私は、ほぼ10年間、何らかの形でソフトウェア業界で仕事をしてきました。その間、XPほど私を興奮させるソフトウェア開発手法を見たり、経験したりしたことはありませんでした。これは、プログラムするための理にかなった方法であると確信しています。。。。。

IBM Java technology より。。。
「XPの真髄」に立ち戻る

XPのプラクティスは、これらの価値を開発者として日々なすべき作業に言い換えたものです。これには、新しいことは何もありません。XPのプラクティスは、ここ数年業界で「もっとも優れたプラクティス」であると認識されてきました。事実、「エクストリーム (極端な)」という言葉は、以下の2つの事柄に由来しています。。。

IBM Java technology より。。。
XPの真髄

さば的プログラミング

普段、何気にこのXPのプラクティスを現場に取り入れてきたはずなのに、なぜかそれすら忘れてしまっていました。体系立てて実践している状況ではありませんが、無意識の中には刷り込まれているはずです。たぶん。。。現場の状況にあわせて、それぞれ対応してきたつもりです。

特にペアプログラミングはできるだけ、機会があれば実践してきました。でも、それはXPでいうところの「ペアプログラミング」とは少々、異なるかもしれません。(英語の原文は読んでいません）

• パートナーの席を隣にする。できるだけ、近くに。
• サンプルを作成して、パートナーに引渡し。
• 自分は契約の事務処理なども合間に実施。
• パートナーが煮詰まったら、そこから引継ぎ。パートナーはお茶の時間。
• 完成したプログラムはパートナーが試験。2人で作ったんだから安心して任せちゃう。
• 最初に作成するドキュメントはほとんどが「手書きの絵」（きたな～い。小学生の息子以下！）
• 書いた字はほとんど読めない（申し訳ない）。でも、字も｢絵｣でしかないと思っているからそれで十分。

日本的習慣

現場のプログラミングに必要な要素と、日本における商習慣とはだいぶ異なってしまうのが現実でしょう。後で誰が見るのかわからない詳細設計書の山。プログラムコードが読めない人でも、詳細設計書なら理解できる人なんているんだろうか。ほとんど同じような関数のインタフェース仕様書を、Excelの帳票のように1枚、1枚、帳票番号を割り振って、コピーライトを付けて、キングファイルに格納する。たった1行のコード修正に、いったいどれだけの文書を直して、その更新履歴を記録しなければならないか。関連する文書を探すだけでも膨大な時間と労力を使うことになる。

後は、お客様の理解

経費節減のために、しなければならないことは、きっとプログラマーに余計な仕事をさせないことだと思う。これからはもっと、このXPの精神を、現場の状況にあわせて「応用」していかなければ。中年の仕事だ。

でも最後は、やっぱりお客様の理解がなければできないこと。開発手法は着実に変わってきている。
いや、すでにもうだいぶ変わっているかも。。。私だけ？私だけ？

太陽と月

インターコンチの会議室

そのプレゼンは、インターコンチの最上階の会議室ではじまった。ノートに火を入れ、プロジェクターの電源を入れる。緊張の瞬間だ。我々の計算では総額10億のビックプロジェクト。想いのすべてを30分に凝縮しなければならない。プロジェクトの概要、もたらす利益、実現するための手段、それをささえる技術、そして何より、メンバの熱い想いを伝えなえればならない。徹夜続きでデータを集めてくれたメンバたちも、本社で「GO」サインを待っているはずた。 :-)

深夜の地下室

深夜、携帯の音で私はベットから起きることになった。SEコールだ。急いで、そいつのいる地下のサーバルームに車を飛ばすことになった。これで、3回目。そいつの %idle はまたしても 0 をさしている。いつものように ps で CPU時間があがっていくプロセスを特定し、strace でシステムコールを発行していないことを確認する。これだけの時間、ユーザ空間で処理が続いているのは、どこかで無限ループに陥っているはずだ。kill でそのプロセスを停止し、/etc/init.d/xxxx スクリプトでリスタートを試みる。監視モニターは正常。原因不明のアプリの障害だ。

正常な状態を保ち守ること

どちらの話もシステムエンジニアにとってありがちな話です。太陽のプレゼン、あこがれる姿。世間が「システムエンジニア」にたいするイメージは、こんなものかもしれません。でも、パッチの適用や、トラブルの解析、問題の修復、問合せの対応など、決して「世間のイメージ」どおりではありません。現場で働く人にとっては、日陰の保守、辛い日々、気がついたら愚痴、といった現実かもしれません。
大辞林。。。

保守名）スル
(1)古くからの習慣・制度・考え方などを尊重し、急激な改革に反対すること。
⇔革新
(2)正常な状態を保ち守ること。

システムの正常な状態を保つことが、どれだけ難しいことか。機械が壊れるだけなら交換すれば元に戻りますが、ここに人間のミス、ソフトウェアのミスが絡んできます。発生した問題は、自分の頭では理解できないこともたくさんあります。建築業界のように、分業も進んでいません。歴史もありません。現場のシステムエンジニアが「徹夜してでも、なんとかする」というのが、現状かもしれません。

コブクロ

娘の借りてきたコブクロの桜を、車に乗るたびに何度も聞いていた時期があります。忘れたころにドラマのエンディングに流れるようになり、毎週感動しています。
「冬の寒さに打ちひしがれないように。。。」
「時の速さに、けがされてしまわぬように。。。」
自分で歌っていると涙がでそうになります（車の中で娘と一緒に大声で歌っていました。笑われています。）。｢コブクロ」のお二人が歌に託したイメージとは関係なく、勝手に自分でイメージを膨らませています。
保守の業務は、春に大きな花を咲かせるために、冬の間にしっかり根を生やすようなものだと思っています。
システムエンジニアにとって、太陽と月のように。 8-)

頭痛と言葉力

頭痛

この２週間くらい、頭痛が続いています。頭痛薬も効かないし、風邪薬も効き目がありません。頭痛がはじまるとおよそ、一週間くらいこの状態をがまんしなければなりません。スポーツをすると良くなく場合もありますが、平日はなかなかそうもいきません。必然的に薬にたよることになるのですが、その薬もあまり力になりません。テレビの頭痛薬のＣＭでは、「あーすっきりー:-) 」といった場面がよく流れていますが、そんな経験を一度でいいから味わってみたいものです。

悩める人たち

調べてみると頭痛にもずいぶんたくさんの種類があるものです。片頭痛、緊張型頭痛、群発頭痛、慢性頭痛。頭痛 の検索結果は 約 3,510,000　件！多くの人が頭痛で悩んでいるのが良くわかります。「頭痛の原因はまだよくわかってない」というのも、いくつかのWebサイトで説明されていました。以前、病院で検査を受けたときも、「特に問題ありません。お薬、出しておきますから、痛みがひどくなるようでしたらまた来て下さい。」といった内容。なんの解決にもなりませんでした。これだけ科学が発達した日本でも頭痛の解決は難しいようです。社内でも頭痛で悩んでいる人、意外に多いかもしれませんね。

問診か。。。

多くの方が頭痛で悩んでいるにもかかわらず、診断は相変わらず「問診」のようです。「肩こり」＝「緊張型頭痛」や「片側が痛む」＝「片頭痛」などを「正しい」とする説も、「怪しい」とする説もありました。最終的には、本人の自己申告とその表現力が診断のポイントみたいです（痛みの表現はそれぞれ違うと思うんですが）。

日本神経学会の頭痛治療ガイドラインという文書を見つけました。問診で診断する場合の判断基準、治療に対する指示、提案（ガイドライン）が書かれています。しかし、この文章をざっと読むと、問診に対する疑問はさらに深まってしまいます。

• 痛みの性質は圧迫あるいは締めつけられる感じ
• 片側性，拍動性で頭痛により日常生活の活動性に影響し。。
• 悪心及び／又は嘔吐:-P

圧迫される感じの頭痛って？締め付けられる感じの頭痛って？活動性に影響ってどの程？歩けないの？悪心ってそもそも何？なんて読むの？中度、高度ってどこから高度？。私にはイメージできないあいまいな表現が並んでいました。

やはり言葉力

このガイドラインを批判しているのではありません。医者でもないのにそんな大それたことは考えていません。「問診」での「言葉」の重要性をあらためて感じただけです。｢頭痛」は、医者と患者が同じ言葉、同じイメージを共有できなければ正しい診断は行うことができない。あらためて実感しました。長年、私の頭痛の診断、病名が確定していないのは、自分の「言葉力」が無いことが原因なのかもしれません。

プログラマーって

プログラマー

プログラマーは「詩人」であり、「陶芸家」であり、「作家」であります。プログラマーは芸術家です。決して、自分の作品に妥協せず、時間さえあれば作品を作り直し、他人の作った物を評価し、流行ものはなんなのか探しまわり、本を読み、一人になり、自分の世界を作り上げます。

夢の中へ

新人のころ、お世話になったリーダに「夢で中でバグを解決できたら、一人前だよ」なんていわれたこともあります。「そんな馬鹿な？」と思っていましたが、今は「さもありなん」と思っています。夢でバクを解決するなんて不可能だと思いまずが、プログラムコードが頭を駆け巡り、眠れない夜を過ごすことは、実は今でもあまりかわりありません。本当。

舞台にマイクはおかないぞ

芸術家である以上、年を重ねても、休みの日でも、いつまでたっても、どこへいっても、貪欲に勉強していきます。自分の作品に納得してしまったら、その時点で新しいものを作ることはできなくなります。自分にできることはもうないんだと思えば、｢筆」をおろすしかありません。解散コンサートで「マイク」をステージにそっと置くような状況です（青い衝撃！）。

妥協

「今の技術と時間（納期）の制約のなかでは、これが精一杯の作品だ」と常に思っています。できなければ、出荷に間に合いません。サービスを提供することもできせん。次に機会があれば、今よりも、もっと「納得」できる作品を作れるでしょう。もっと「整理した」作品を作れるでしょう。もっと「美しい」作品を作れるでしょう。でも、今の作品を買ってくれる「お客さん」がいるかぎり、その時のその選択は、ぜったい後悔しません。したくありません。しません。（かな？）

弾いている

音楽の世界では、♪の数も、音の数も、記号の意味も、ごく限られた数しかありません。人はその組み合わせを何千年もの間、探し続け、納得せず、飽きずに作り、そして壊し、時代を超えていいものはいいと評価され、これ以上のものは作れるわけがないじゃないか、と思いながら、次の朝には、また新しいものを考えている。ギターを弾いている。ピアノを弾いている。。。

見えない作品の芸術家 ;-)

プログラマーは決して特殊な職業ではありません。「コンピュータの世界の芸術家」です。芸術家である心を失わないために、「これでいいのか？」と自問自答するのはあたりまえです。悩み、苦しみながら、自分の作品を発表し、いくつになってもプログラムを作り続けたい。橋のようには、音楽のようには、わかりにくい作品ですが。。。

棟梁を目指して

棟梁

棟梁という言葉の響き、持っているイメージは自分の目指している「人物像」にとってもぴったりです。昔からことあるごとに、「俺は棟梁になりたいんだ」といってきた気がします。いわゆる「大工の棟梁（とうりょう）」のことです。棟梁というより、「親方」といったほうがイメージしやすいかもしれません。

むねとはり

とにかく、いつもの大辞林を引くことにします。辞書を引かないと次の言葉が浮かんできません。

棟（むね）
(1)(ア)屋根の最も高い所。大棟。また一般に、屋根面の交わる稜線。隅(すみ)棟・降(くだ)り棟などがある。
(イ)棟木(むなぎ)。 (2)牛車(ぎつしや)の屋形の上に前後に渡した木。
(3)刀の刃のついていない側。みね。

「住宅ひとむねが全焼」などのように、家を数得る単位でもあります（子供に言わせれば、数取り団）。

梁（はり）
(1)屋根や上階の床の重さを受け支えるために、柱上に渡される横木の総称。うつばり。
(2)材軸に対して直角あるいは斜めの荷重を受け、この荷重を支点に伝える細長い水平材一般をいう。ビーム。
(3)算盤(そろばん)の用語。五玉と一の玉の境に設けた横木。

なんでこの２つが合わさって、親方のことを「棟梁」と呼ぶようになったんだ？変な疑問が出来てしまった。 =-o

語源

語源メモ＞た行より
「棟」 も 「梁」 も家屋の構造上大切なものです。そこから、大工の頭を指すようになり、転じて、おもだった人・かしらを意味するようになりました。

いまいち？

コラム建築版温故知新９より
元来は建物の最も高い所にある主要な構造材「むねばり」の意味ですが、それから転じて「源氏は武家の棟梁」というように、ある分野での実力者・統率者という意味で、既に広く使われている言葉でした。

豪華！

おやじ

語源の「像」とはだいぶ違いますが、目指しているのは「偉い」人ではありません。家作りに関しては、その地域に根ざした商売を展開し、営業、設計、施工、アフターケアまで自分の仕事の境は決して作らない、そんな｢像」を目指しています。棟梁には「大店」も必要です。自分ひとりでなんでもやれるわけでも、できるわけでもありません。経験しているから人に伝えることができる、経験しているからその人の苦労がわかる、そんな「おやじ」を夢見ています。

雨が降ったら傘が売れる

今日は雨

今日は朝から雨模様。子供たちにはいつものように「傘持ったのか？」と出掛けに声をかけます。雨が降っても、めんどうくさいのか、そのまま学校へ直行しちゃいます。本降りにでもなれば、妻が学校まで傘を持っていくはめに。毎度のことですが、「帰りにどうなるのか、わからんのか？」、ほとほとあきれてしまいます。 :-!

キオスクの品揃え

雨が降れば、キオスクの「軒先」には傘が並ぶことになります。裏にストックがあるのか、商品を発注するのかはわかりません。でも、雨が降れば、傘が売れると考えるのは誰にでも想像できることです。たぶん。 :-P 世の中の商売というのは、この「想像力」を持ち合わせている方が、大きな利益をあげているのかもしれません。

ざっと考えてみました。なんの根拠もありませんが。。。

• 長期予報では、今年の夏は暑くなりそうだ→エアコンの売上増へ
• 少子化がすすみ、１人っ子が多い→ひな人形は質、金額とも高価なものへ
• 小学6年の体力が20年前の小学1年程度に→スポーツ塾が増加か？
• フィギュアスケートで唯一の金メダル→スケート靴への注目が集まる
• ドラマの視聴率が20%に→所属レコード会社の株価アップ

こんな単純な発想で株に投資する、個人投資家も結構いるのかもしれません。いるわけないか。。。

もしも、ユーザが。。。

ドリフの「もしもシリーズ」ではありませんが、コンピュータシステムの世界では、「もしも」の発想に大きな意味があります。相手は実態のよく見えない「機械」です。毎日のように「もしも」を繰り返しています。私だけかもしれませんが。「もしも、メモリ不足が発生していたなら」、「もしも、数字ではなく、文字コードが入力されたら」、「もしも、１秒間に10,000回のトランザクションが発生するなら」。
もしも、つまり自分で「仮説」を立てること。これは、システムを保守できる、プログラムを作成できる、システムの設計ができる能力にとっても重要な要素の１つです。仮説は検証によって証明します。

テスターという仕事

この「仮説」をたてる「能力」を試される仕事があります。「テスター」です。ただ、テストを淡々とこなしていくだけでは「テスター」とはいえません。「テスター」は単なるアシスタントではありません。仕様書に書いてあることだけをテストしていても、実際の運用で発生するトラブルがすべてなくなるかは疑問です。「何か不足していないか？」、「本当にそうなのか？」「システム設計者が考えたことは正しいのか？」。書かれていないことを想像し、テストを計画し、実際のデータを投入、あるいはテストプログラムを起動し、そして、その結果から仮説を検証します。きっとこの繰り返しです。

雨が降ったら傘が売れる

「キオスク」では雨が降ったら「傘」が売れると「仮説」をたて、実際に商品の品揃えを「計画」し、店に並べて「いかがです？」と｢実行」し、その日の売上で「検証」する。そしてそれが事実であれば。。。でも、ある日の朝は、雨が降っても傘はちっとも売れない結果に。実は昨日も雨で、今日はあわてて買う人がいなくなったのかもしれない。また考える、また考える。
システムエンジニアにとって、特にテスターにとって、「雨が降ったら傘が売れる」発想は忘れてはならない「エッセンス」かもしれません。

かっこいい職業?

「システムエンジニアってどんな職業かイメージできますか？」
インターンの研修生にこんなこと、いっちゃいました。

• コンピュータの"何でも屋"
• 何かあったら真っ先に駆けつけます
• 10年選手のプログラマー（ここは横棒を伸ばしておこう）
• 時代の花形
• 詐欺師、寝業師

だれも、システムエンジニアはこういう職業ですと定義できていません。自分のなかでもあいまいな部分があります。「プロデュサー」、「教師」、「現場監督」、「店長」、。。。「大将」。
ＳＥって「かっこいい職業」と子供に威張っています。｢威張る」という字もかけないくせに。でも世間はやっぱり、「ＳＥって何？かっこいいじゃん？」というのが常識でしょうか。

ブログをはじめたきっかけ

単純なきっかけ

ブログについて個人的に詳しいわけでも、前からその存在に興味があったわけでもありません。きっかけは単純で、不純なものです。立場のイトーヨーカ堂の3Fの本屋でいつものように、本を眺めていると、「アフェリエイト」、「あなたも小遣い稼ぎ」、なる背表紙がやたらと目立つようになったことです。本当に儲かるのか？　何人かの方に確認したところ、「儲かるわけないじゃん」とあっけない返事ばかり。IYグループCEO、鈴木敏文氏いわく、「周りの人が、だめだ、といっていることは本当なのか？」が頭をよぎります。本当にビジネスにならないのか。
ブログをビジネスに生かしている人もいる。自分たちなりのビジネスは本当にないのか。こんな単純な発想から、ブログをはじめてみようと思いました。

思わず買ってしまった

最近、妻が「ここのケーキ屋さん、おいしいらしいわよ。こんど買ってみる？」と言ったことがあります。以前なら、「そう？」っていう程度であまり気に留めなかったかもしれません。でも、今の商売はこの「口コミ」抜きでは成り立たなくなっているも事実でしょう。「ねーねー、見た？昨日のテレビ？あれ、やっぱりおかしいよね？」「そうそう。あたしもそう思った。やっぱおかしいよね？」。人はいつでも、だれかに同意を求めたり、意見を求めたりするものです。私もその一人です。スーパーで他人の買い物かごの中身をみて、「あっ、やっぱり広告のビール買ってるじゃん。俺も買っとこうかな。」なんて考えたりします。別にその人のこと、知っているわけでもないのに、話してもいないのに、ビールを買うという行動が同じ結果になっています。広告だけでは買わなかったかもしれません。:-)

行動するということ

共感（きょうかん）
名）スル
(1)他人の考え・行動に、全くそのとおりだと感ずること。同感。
「―を覚える」「―がわく」「彼の人生観に―する」
(2)〔心〕〔sympathy〕他人の体験する感情を自分のもののように感じとること。
(3)〔心〕〔empathy〕⇒感情移入

ある人の人生そのものに「共感」するという崇高な哲学みたいなことから、思わずビールを買ってしまったという「たわいのない」ことまで、「共感」の示す言葉は幅が広いと思っています。ブログにかぎったことではありませんが、人が何か行動を起こす時に、何かに「共感」しているのかも、と思うようになりました。「共感」という言葉が適切ではないかもしれません。学者ではないので、論理が違うかもしれません。

先は長いかも。。。

エントリーでは、他人の批判はせず、自分の考えを押し付けず、うそをつかず、礼儀を忘れず、これからも少し続けていこうと思っています。

言葉の力

次期学習指導要領の改訂

やはり、「ゆとり教育」にはどこか問題があったんだ。文部科学省の次の目玉は、「言葉の力」ということらしい。昨日(2/9)の朝日新聞の一面の、「言葉の力」を核にという見出しは自分の目に大きく飛び込んできた。

「ゆとり」から「言葉の力」へ。約１０年ぶりに全面改訂される次期学習指導要領に、学校のすべての教育内容に必要な基本的な考え方として、「言葉の力」を据えることがわかった。文部科学省が近く、中央教育審議会の部会で原案を示す。「言葉の力」は、確かな学力をつけるための基盤という位置づけ。学力低下を招いたと指摘を受けた現行指導要領の柱だった「ゆとり教育」は事実上転換されることになる。

言葉の力

「言葉の力」とは？原案には「言葉は、確かな学力を形成するための基盤。他者を理解し、自分を表現し、社会と対話するための手段で、知的活動や感性・情緒の基盤となる」とあるらしい（2006/02/09 朝日新聞より)。今の自分に、とってもなじむ文章だ。システムを設計する場合も、問題点を指摘してする場合も、障害の原因を順序だてて調べる場合も、まず「日本語」という言葉で考え、会話し、論理を構成している。

言葉の力、思考の整理、伝える技術。それに比べれば、プログラム言語なんて、とっても簡単に思えてしまう。

:-)