Vol.101〜150

用語集


Ｖｏｌ．101　　今後は...

　そうですね。このページは日記みたいなものですね。

　というのも、私が何を書こうかと考えているときに、社長から「なんだ。日記を書いていたのか」言われたのです。

　前回、”「こういうサイトがほしかった」と思うようなものにしていきたい”とはいったものの、第三者として見た場合、なにがそう思えるものなのかがまとまりませんでした。
　自分と同じ立場で作業をしている人がどのような問題を抱え、どのように解決し、どのようなことで悩んで...。
ということが書いてあるサイトがあればなあ...。というような感じで頭にはぼんやりとあったのですが、それは何かという答えが出なかったのです。

　しかし、それは日記だったのですね。

　そんなわけで、今後は測量会社でシステム管理をしている私が抱えている問題、解決手段、悩み、覚えたことなどを日記として、毎日のことではないので日記と呼べないかもしれませんが、技術的なこと、精神的な話を問わず書いていけたらと思いつつ、次回へ渡すのでした。

03/08/2000

<<

Ｖｏｌ．102　　拡張子のこと

　拡張子について聞かれることがよくあります。
「この拡張子は何のファイルか」といった感じのことなのですが、やはり業務の関係上、画像や図面に関連するファイルの拡張子について聞かれることが多いです。

　そもそも拡張子というものは、ファイルの種類を区別するために、「ファイル名.○○○」といった具合にファイル名の後部に付ける識別子のことだというのは既にご存知かと思います。

　で、いまさらそんなのは...と皆さん思われるでしょうが、今回は私自身の整理の意味も含めて、よく見かける拡張子をまとめてみました。

拡張子

種　　　　類

DXF

CADデータフォーマットの一種

DWG

AUTOCADフォーマット

JPG

画像フォーマットの一種

GIF

画像フォーマットの一種

TIF

画像フォーマットの一種

DOC

MS-Wordのフォーマット

TXT

テキストフォーマット

XLS

MS-Excelのフォーマット

PDF

文書ファイルのフォーマット

EXE

実行ファイル



　情報量としては全然足りないですが、普段の作業の中で目にするものはこの程度です。

　ところで、表中の”EXE”拡張子。これは実行ファイルと書きましたが、普段見かけるのは自動解凍形式で圧縮されたファイルあたりですね。DOSを使っている方は別として。
　図面のデータなど、サイズが大きいファイルをメールに添付したり、FDに保存する場合に使われるでしょう。

　とはいうものの、Windowsは標準で拡張子を表示しないような設定になってますし、あまり拡張子を意識する必要もないのでしょうか。
Macintoshは拡張子なんてありませんし。
そのせいもあってか、Mac<--->Win 間のファイル共有があまり...。

03/10/2000

<<

Ｖｏｌ．103　　計算式変換

　私の手元に、あるシステムのデモ版が届きました。

　それは、Excelに入力した計算式を表示用の文字に変換するというものです。
具体的には、「1*2*3」と入力したものが「1×2×3」と表示され、隣のセルには計算結果が...というソフトです。

　良いソフトだとは思うのですが、残念なことに実は同じようなものを作っていたのです。
　　半年くらい前になるでしょうか。企画から1時間半程度で作ったものなのですが、そこそこうまくできていたのでけっこう自分でもお気に入りのプログラムでした。

　しかし、同じ主旨のものが製品化されていたとは。

　とはいうものの発案自体は私ではなく、設計部門から「計算書を作る際にこういうのがあれば」という話があってのことです。
　本来ならば私のほうから、作業のそういう部分をみつけて「こんなの作ってみましたけどどうですか？」という話をしなければならないのですが。

　そんなところも含めて、「測量会社のシステム管理者」として私に足りない部分なのでしょう。

03/15/2000

<<

Ｖｏｌ．104　　システム部門は

　会社は各部門が密接に関わっていく必要があるんですね。当然ですね。
そんななかにあってシステム部門はどうなのでしょう。

　ある意味異質で、ある意味密接で、ある意味確立された立場で、ある意味曖昧で...
実際作業をしている中でそんな風に感じることが多くあります。

　部門の技術者の立場に立って、でも考え方の切り口はシステム管理者でなければならない。

　打合せをしていると、相手の言っていることがいまいち理解できず、また自分の言っていることがうまく相手に伝わらない。という状況がよくあります。
　相手の言っていることが理解できないのは、その業務に対する経験、知識が私にないからで、自分の考えが伝わらないのは私のシステム管理者としての経験、知識がまだまだ足りないからだと思います。

　ようは勉強が足りないということですが、書籍などで知識だけを詰め込んでも使えるものではないのでしょうね。その知識は。
ですから経験も含めて勉強と。
　それができてはじめて、密接で異質で確立されて曖昧な立場をうまくとりまわせるようになるのでは？

なんて最近よく考えます。

03/17/2000

<<

Ｖｏｌ．105　　RAID

　RAID(Redundant Arrays of Independent Disks)ってご存知でしょうか？
私は、RAID＝信頼性の高い外部記憶装置を構成するために安価なディスクを複数使用する方法。程度の知識しかありませんでした。

　いろいろと考えるところがあって、調べなければと思っていた矢先に、とあるメーリングリストでRAIDの話題が見られたので、ちょっと調べてみました。

　RAID0：ストライピング（主にデータ転送向上が目的？）
　RAID1：ミラーリング
　RAID2：エラー訂正コードの使用
　RAID3：固定のパリティディスクを持つ
　RAID4：RAID3でのストライピングの単位を拡張
　RAID5：パリティディスクが固定されない

上の中でも製品化されているのは、RAID1、3、5辺りのみだとか。

　ということなのですが、それぞれについてあまり深く掘り下げると、このページの主旨がちょっと変わってしまいそうなのでこの程度にしてみました。
もっと詳しく知りたいと思われる方がいらっしゃいましたらこちらをご覧いただければと思います。

　で、ちょっと不思議に思ったのが、なぜ記憶装置の台数が増えるのに信頼性が向上するのかということです。
　情報処理試験の世界では、故障間隔とか修理時間などが絡んでくる計算式によって、台数が増えるほど信頼性が低いものになるんですけど。
　などと難しそうなことを考えても、その分野の凄い人たちが考えたことなのでしょうから、多分信頼性は向上するのでしょう。

03/22/2000

<<

Ｖｏｌ．106　　プリンタがPostScript

　近頃プリンタの調子が良くありません。

　約6年使用しているので、調子の悪い部分が出てきてもおかしな話ではないのですが。
　業者さんの話によると、またすぐ不具合が出るようならオーバーホールが必要になるとか。

　今はプリンタも低価格化がすすんでいますし、これを期に買い換えたほうが良いような気もするのですが、PostScript対応の機種はまだまだ低価格と言えるような値段にはなっていないようです。
　しかも、電子化、電子化言われている現在において、出力機器に費用をかけることはどうなのかとも考えてしまいます。

　逆に電子化が叫ばれているならば、印刷物にそれほどこだわらずにPostScript非対応のものを導入しても良いのではないかという考えも。
　かといって現状、印刷物の存在はまだまだ大きいし、ないがしろにするわけにもいきません。

　という感じでいろいろと考えてしまうわけですが、今回調子が悪くなったプリンタの他にもPostScript対応のものが当社にはありますし、もしもの時は非対応の機種を新規で。と提案しようかと思っています。

03/24/2000

<<

Ｖｏｌ．107　　ファイルサーバー

　アメリカのアップル社サイトで面白いサービスを目にしました。

　インターネット上に自分専用のファイルサーバーを無料で設けることができるというものです。
　これはMacOS9を使用している場合のみ利用可能なサービスなのですが、今後無料でこういったサービスを提供するところが増えれば、非常に重宝すると思います。

　自社でサーバーを管理している場合、ファイルサーバーを公開するのはちょっと怖いのですが、これからはファイルサーバー経由でファイルのやり取りをすることも必要になるでしょう。
　メールの添付ファイルでは限界がありますし。
　そんなときに、上記のようなサービスが利用でき、しかもセキュリティもばっちりとなれば、管理する立場としては非常に楽です。

　が、自分の手が届くところにあったほうが安心できるとも考えます。

　その辺はそれぞれの環境や考え方によるのでしょう。

　私の場合は、自分で管理したほうが、総合的に見て良いような気がします。

03/29/2000

<<

Ｖｏｌ．108　　専門家

　ある作業の電子化について担当部署の社員と打ち合わせをしたのですが、やはり専門家ですね。

　自分の仕事を知っているという表現がふさわしいでしょうか。

　ただ、それをうまく電子化に結びつけることがなかなか難しいようで、そこをうまく繋ぐのもシステム管理者の仕事だと思います。本来ならば。

　で、その打ち合わせ中は、相手が「こう考えていて、この部分でシステム管理者の意見が聞きたくて...」という具合に話を持って来たのですが、私ときたらあたりまえの返答しかできないのです。
　これは以前も書いたように、相手の業務を知らない、自分の業務の経験が浅い。辺りが大きな原因になるのでしょうが、これでは専門家とは言い難いと自分でも思いました。

　そんな状態で当然提案などできるわけも無く、「もっとこっちの分野の話だったら...」などと思いつつ、聞かれたことに対して答えるという形式に終始した打ち合わせとなってしまいました。

　なんか心残りな第１回打合せだったので、次は少し予習をして打ち合わせに臨みたいと思います。専門家に近づけるように。

03/31/2000

<<

Ｖｏｌ．109　　年度始めに

　今年の4月1・2日が土曜・日曜ということで、昨日は年度最初の出勤でした。

　当社でも新入社員や部署を移動した社員、などなどありまして、私はメールのアドレス帳を修正していたのです。
　そんなとき、ふと新入社員のアカウントをサーバーに登録していないことに気付き、アドレス帳の修正をそのままに、アカウントを登録することにしました。
　登録作業中に、またまた思い出したのがグループウェアの設定です。
　アカウントの登録後にグループウェアの設定を修正していると、今度は機械の配置図を修正しなければならないことを思い出しました。

　そんな具合で、ついでに座席表も、PC管理表も...と次々に修正して、ようやく一通り終わったであろう頃に、このような作業もマニュアル化しておく必要があると感じたのです。
　これは、そのときの環境によって当然作業のやり方も変わるでしょうし、まるっきりマニュアル通りに、とはいかないかもしれませんが、それでも項目が列挙されているだけで作業効率が全然違うと思います。

　来年度は迷うことのないように、早速修正する項目を書き留めて置きました。

　と、アドレス帳の修正が途中であることを思い出し、これから取り掛かります。

04/04/2000

<<

Ｖｏｌ．110　　祝「iモード」企画

　先日、当社にも「iモード」が数台導入されたということで、今回は豆知識程度にiモードのメールサービスの仕組みをご紹介したいと思います。

　まずiモードに宛てられたメールは、DoCoMoのメールサーバーに届きます。すると監視ソフトがメール到着の旨をゲートウェイサーバーに知らせます。
　知らせを受けたゲートウェイサーバーは、指定されたiモード端末、つまり携帯電話を呼び出します。
　呼び出された携帯は、逆にサーバーを呼び出し、メールサーバーからメールを持ってきます。

　と、かなり大まかですが、だいたいこんな仕組みらしいです。

　ちょっと気になるのは、通常のインターネットメールであれば受信はPOP3を使うものですが、携帯ではPOP3を使わないようです。
　理由はどうやら着信通知にあるようで、なんでも着信通知の為にPOP3でメールボックスを定期的に確認する仕組みをとると、サーバーの負荷が大きくなるとかなんとか...
そのため、メールが届いた時点で宛先を調べる方法を採用しているらしいのです。

　因みに、インターネットと携帯ではプロトコルが違うことはいうまでもないでしょう。
その変換をしているのはもちろんゲートウェイです。

　個人的にはEZWeb派なので、そっちの企画をと思ったのですが、まあ「祝iモード」ということで。

04/07/2000

<<

Ｖｏｌ．111　　業務範囲＝試験範囲

　次の日曜日は、試験が私を待っています。

　今回受験する第１種情報処理試験は、これまで受験してきた２種とは違い、システム監査の問題などが出題されるんですね。
　ちらっとそれらしい問題を見てみると、なんとも難しい言葉が書いてあり、解答するのは到底無理のように感じられました。
　こりゃ今回はだめだな...なんて思いながらもう一度問題を見てみると、ただ言葉が難しいだけで、普段の業務で行なっている作業となんら変わり無いことを質問されていることに気がつきました。

　本来、資格試験というものはこうあるべきだなんて思っても、私が不用と思っている試験範囲を普段の業務としてる方も受験されるわけですし、結局は受験者全員に対して平等なんでしょうね。

　実務が試験の範囲になっている部分は、いうなれば毎日勉強しているようなものですから、あとは私が不用と思っていた部分、つまり実務範囲外の勉強をすれば良いのですが、もろもろの事情が複雑に絡みあって...ということを言い訳にあまりやれてないです。

04/11/2000

<<

Ｖｏｌ．112　　「へえ」と思う

　「私がシステム管理者です」なんて言ってますけど、社内の電算環境でもまだまだ未知な部分があるんです。

　例えばCAD環境。こんなことを言うのはあまり好ましくないのですが、それについての質問が来るとお手上げという状態です。
　もう「業者さんに聞いてください」としか返事のしようがないのですが、それではあまりにも役立たずなので、一応話を聞いて問題の切り分けぐらいは協力させていただいています。

　そんなやり取りの中でも、話を聞いていると「へえ」なんて思うことが結構多く、そういう知識を明文化してみんなで共有しましょうよ。と言いかけるのですが、それをやるのは私なんですね。
　システム管理者だからとかそういう理由ではなく、今「へえ」と思った人がまとめたほうが、”知らない人が知りたいこと”をうまく拾えるような気がするのです。

　かくいう私もコンピュータの不具合等について説明することがよくあるのですが、なかなかうまく伝わらないということが多々あります。
　多分それは、その件について私が「へえ」という感覚を忘れていて、知らない人にとって大事な部分を省いた説明になっているからと思います。

　ですから、「へえ」と思った人が思ったときに明文化して共有することが望ましいのではないかと考えるのです。

なんか社内の掲示板にそのような主旨のコーナーがあったような．．．？

04/14/2000

<<

Ｖｏｌ．113　　実際にあるのでは？

　一昨日、私は第一種情報処理技術者試験を受けてきたのですが、これは本当に難しかったです。

　で、その試験の午後の問題に面白いものがありました。

　ある会社での手順にしたがって、システム開発することを仮定した問題だったのですが、これは下手をするとどこかの会社で実際にやってますよ。この手順で。

　この問題は実際にシステム設計やレビュー等を行なったことがないと、解答は難しいと思いつつ問題を解いていました。
　二種の午後のプログラム問題などは「そこはこうしたほうが実用的なのに」などと思うこともあったのですが、一種はかなり実務的な問題が出るものだと非常に驚きました。

　まあ、面白いとは言うものの、全問解けたわけではないし、解答したところも正解かどうかはかなり怪しいですけど。

　しかし、2時間半で8問解かなければならないのに、問題ひとつの説明が3ページにも渡るというのもどうなんでしょう。

04/18/2000

<<

Ｖｏｌ．114　　キャンセル

　4月13日のowner通信にもありますように、私はLinuxの勉強用にパソコンを購入してもらうべく申請をしました。
　で、納品まで1ヶ月待ちと。

　一昨日、別件でパソコンを注文した業者さんに来ていただくことがありまして、電話で連絡をとったところ、「午前中には伺います」とのこと。プリンタのトナーを届けてもらうことにしたのです。

　そのうち、その業者さんが見えたとの連絡が入り、受付までいってみるとトナーと社長が注文したらしきソフトが並んでいました。
　軽く挨拶を交わし、納品内容を確認した後、業者さんが「それと...」なんて言いながらおもむろに取り出したIBMの箱。

　なんと注文していたThinkpadが届いたのです。

　なんでも問屋さんのほうにキャンセルがあったらしく、それでこちらに回していただいたとか。
こんなこともあるんですね。

　それにしても他の納品物と一緒に並べておかず、あとで「ジャーン」といわんばかりに出してくるという、なんとも心憎い演出をしてくれるものだと思いながら早速ThinkPadを触ってみるのでした。

04/21/2000

<<

Ｖｏｌ．115　　コミュニケーションは

　趣味の都合上、打ち上げやミーティングと称して大勢で食事なんかをする機会がたびたびあります。

　大勢でとなると、どうしても近場同士でグループっていうか、会話をする人が固定されてしまうんですね。
　すると、どの輪にもなかなかは入れない人が出てきます。よくある風景です。
　そういう傾向になりがちな人を見ていると、どうも自分から話題を持ち出すといったことが少ないようです。
　？？？なんかどっかで聞いたような...と思いつつ、あまりそういうのが好きではないので、入って来やすいような話題を、その人をはさんで遠くに振ってみたり、その人に直接話し掛けたりします。
　そんな時「あ！」と思うのです。電子メールや電子会議室など、社内の電子的な環境でも以前同じようなことをやっていたのでは!?

　どっちにしても結局は人間がやることですからね。大差ないのは当然なんですね。

　でもその作為的なグループ崩壊策以降、その人が話の輪に入るのか、それっきりになってまた元に戻るのかは本人次第だと思うんですけど。

　電子的な環境も同じなのでしょうか？

04/25/2000

<<

Ｖｏｌ．116　　Sendmail

　今週はメールに関する苦情がちょこちょこありました。
ひとつはメールソフトに関する問題。あとは送信不可という問題。
送信不可については、Sendmailを再起動することでとりあえずは回復しています。メールソフトの件は今しがたようやく解決しました。

　結果的にどちらも現在は動作しているのですが、送信不可の問題のほうがどうも気にかかります。
　というのも、Sendmailを再起動して送信できるようになってから、それまで溜まっていたメールがどどっと流れてきたのです。
　幸い今回は社内での出来事ですからそれに気付いたし、外部の方に迷惑をかけることはなかったのですが、外部のサーバーでもこんなことがおこらないとも限りません。

　なにしろ、ログをみてもそれらしいエラーなどは見当たらず、原因が特定できないので。
　また、もし発生してもメールを送るという行為をしなければ気付かないことも考えられます。

　2時間おきとか、定期的にサーバーから私の携帯電話にメールを送るような仕組みを作ろうかなんて考えたのですが、私の今の技術ではちょっと無理っぽいですし。

　しばらくはマニュアルで定期的にメールを送るしかないようです。

04/28/2000

<<

Ｖｏｌ．117　　流れがわかりません

　先日、あるセミナーに参加してきました。
それは電子納品やGISに関する内容のセミナーで、主催者であるメーカーさんの製品を使ってそれらにどう対応し、発注者に提案するかという感じで進められました。

　事前に目を通していた案内資料によって、どのようにセミナーが進行するかはある程度予想できたので、私としては当然「セミナーの内容をどう当社に置きかえるか、その場合の自分の役割は」ということに主眼を置いて受講するつもりで会場に向かったのです。
　で、実際にセミナーが始まって気付いたことは、私が測量についてあまりにも知らない。メーカーさんのコンセプトやそれらをどう具体化していくか等は理解できたのですが、じゃあそれを当社に置きかえると...？現状どうなっているんだろう？

　これは非常にまずいことです。この場所でこのようなことを発表するのもどうかと思ったのですが。
　細かい計算方法などまで知っているにこしたことはないのですが、せめて作業の流れぐらいは把握しておかないと話になりませんよね。
　なにも提案できないし、しても使える案ではありません。それについては前々から問題視して、ここでもとりあげていたのですが、現在に至る。

　ちょっと作業を止めてでも、入札から納品までそれぞれの段階の担当者にくっついていろいろ教えてもらいたいなんて考えています。

05/02/2000

<<

Ｖｏｌ．118　　Linuxのすすめ

　以前、ここで書きましたThinkPadですが、現在どうなっているか。
Linuxの勉強のためということで申請したわけですから、当然Linuxをインストールしています。

　しかしLinuxはなかなか面白いですね。
普段仕事以外ではあまりパソコンに興味を持たないのですが、Linuxの設定は、時間があれば「ちょっとやってみようかな」なんてついつい機械を立ち上げてしまいます。
　一応Windowsと両方立ちあがるようにしてはいるものの、Windowsを立ち上げたのは最初の数回程度しかありません。

　といいつつ、連休中にようやくpingが通るようになったばかりで、使いこなすというには程遠い状況なのですが。
　それでも、ちょっと興味を持たれている方にはお勧めしたいです。
いろいろと難しいことを考えて疲れたときには、脳味噌の体操になりますよ。まあ体操というには難易度が高いかもしれませんが、気分転換には良いと思います。

　私は今後各種サーバーを立ち上げる予定です。

　タバコを吸いながら、インストール時に行なったことや設定したことを書き残しているときも結構楽しかったりします。

05/09/2000

<<

Ｖｏｌ．119　　インターネットに

　私はシステム管理者という立場で仕事をさせていただいております。
　今の日本、または世界の風潮にあって非常に良い響きの立場だと思っております。

　そんな立場にありながら、私はあまりにもそういう意識がなさすぎると自分でもつくづく感じる今日このごろです。
　例えばインターネット。本来ならば社内の誰よりも早く自宅に接続環境を確立して、会社で導入する頃には、当然のように使いこなしていなければならなかったのではないかと思います。
　それがどうでしょう。私ときたら昨日ようやくプロバイダから書類がきて接続できるようになったという状況なのです。

　と、前半部分にいろいろと書きましたが、結局はインターネット接続環境が出来上がったことがうれしいんですけどね。
まだアナログ回線で繋いでいるんですけど。

　しかし長かったです。なにが長かったかってプロバイダ選びにえらく時間をかけてしまいました。
「究極の中途半端」ともいえる知識を持っている私は、本当はCATVが良かったんですよ。でも私の住んでいるところにはCATVが来ていなかったのです。
　それで最終的に選択したのが、月1,600円で使い放題（電話代別）というプロバイダです。
　そんなに遅さは感じないのですが、これから使っていくうちに不都合な点なども見えてくるのでしょう。

05/12/2000

<<

Ｖｏｌ．120　　議事録とは

　ある会議の議事録をまとめました。これは別にシステムを管理しているとかそういうのは関係なく、一般的に行なわれていることなんですけど。
で、気付いたことは、議事録をまとめるのは難しい。

　なるべく会議の内容に忠実にまとめようとすると膨大な量になってしまいます。そんなの議事録じゃないとか言われて、確かにその通りだと思い、まとめなおすことにしたのですが、これがなかなかうまくいきません。

　会議の流れを変えない程度に要点を整理する。

との教えを頂き、それにそってやっているつもりなのですが、どうも長くなってしまいます。
　例えば自分の発言はばっさり切ることはできても、他の方の発言はどうしても要点の周りの修飾語的な部分まで必要に思えてくる。
　その部分は要点を修飾しているに過ぎないことは分かっていても、それを削除してしまうと、いまいち会議の雰囲気が伝わらない。ということはそれらも含めて要点なのか？などと考えてしまうのです。

　昔からそんな感じで、国語があまり得意なほうではなかったんですよね。「上の文中の○○の気持ちを20文字以内でまとめなさい」とか。
でも、そんな様子ではこれからも困るでしょうし、なんとかしなければと思ってます。

05/16/2000

<<

Ｖｏｌ．121　　電源タップの発想

　自宅のパソコン周りの電源を再検討してみました。
これまでは電源の口が足りずにどれかを使う場合にはどれかを抜いて、違うやつを使う場合にはまたひとつ抜いて...としていたのですが、いいかげん面倒になったので、この際電源タップを買ってしまおうと、電気屋さんに行ってみたのです。

　案の定、私が要求している7口以上のものは2,000〜3,000円が相場のようです。
　厳しいと思いつつも買わないことには仕方がないので、なかでも一番安いものを手に取ったところ、妙な形のタップが目に入りました。
　普通電源タップというと、皆さんが思い浮かべるであろう、1cm弱の差込口がいくつか並んでいるものなのですが、私が目にしたそれは10cm程度の溝が2本、平行にあるだけなのです。
　パッケージ裏の説明を見てみると、なんでも溝のどの部分でも差し込んで電源を供給できるとか。

　原理的に、ようはプラスとマイナスなのでしょうから、そんなに難しいことではないのでしょうが、発想がすばらしいと思います。

　たぶん社内にもそんなことが転がってるんじゃないでしょうかね。この部分を電子化するだけで効率が全然違うとかいうことが。捜してみるんですけどなかなか...

05/19/2000

<<

Ｖｏｌ．122　　データあってのデータベース

　どうも私のメールソフトの調子が悪いというかおかしいというか、良くありません。

　受信したメールに大事な情報があれば、当然削除せずにとっておくのですが、あるときそのメールをみてみると、とんでもないことになっています。
　本文は、虫食いどころかばっさりと抜け落ちていたり、あいだにヘッダが入っていたり、ほかのメールの本文が入り乱れていたりなどなど、情報として使える内容ではありません。
　これはあまりにもひどいことなので、他のメールソフトを捜してみたのですが、慣れもあってなかなか使い勝手の面で満足できるものが見つからないのです。
　そこで考えたのがMS-Accessをつかっての管理。受信したなかで保存しておきたいものはAccessにコピーしておくという方法です。
　さっそくMS-Accessを使ってメール管理システムの構築を始めました。ヘッダの情報をフィールドに振り分けて検索しやすいようにするなど、構想は広がります。
　が、なかなかプログラムがうまく作成できずに足踏み状態です。そんなことをしている間にもメール内の情報は次々と壊れていきます。
そこでとりあえずテーブルをつくっておいてデータだけ移しておくことにしました。

　そういえば、以前頻繁にデータベースシステムを構築していた頃、「データあってのデータベース」という話を聞いたことがありました。
　処理上の不備や使い勝手の悪さはあとでいくらでも修正は利きますが、データはそれひとつしかないと。だからまずはデータ確保を考える必要があるんですね。とかく小手先のプログラミング等に走りがちですが。
　設計の都合上テーブル構成を変える必要があってもデータさえあればなんとかなるものです。

05/23/2000

<<

Ｖｏｌ．123　　電源供給が原因

　ちょっと前、私の機械からネットワークに接続することができなくなってしまいました。
　最近は減っているものの、普段からそのような苦情を受けているため、それについての対策はできています。
　一通りその対策に沿って修復を試みたのですがどうもうまくいきません。
　そこで、正常に動作している状態で最後に起動したのはいつか、そのときから異常が発生するまでの間になにをしたか、を思い起こしてみました。
　思い当たることといえばSCSIボードをさしたことぐらいでしょうか。その先にはMOドライブが接続されています。
　ちょっと思うところがあって、MOドライブの電源を入れてパソコンを再起動すると、今度はうまくネットワークに接続することができました。

　以前CAD機のCOMポートにプリンタを繋いだところ、別のCOMポートに繋いでいるプログラムキーにきちんと電源が供給されず、うまく動作しないということがあったのです。そのときもプリンタの電源を入れることによって解決したため、今回の件もその類ではないかと。

　ネットワークとSCSIなんて一見たいした関係もなさそうですが、よくよく考えてみればカードを差しているところは同じなんですよね。

　表面から一歩踏み込んだところで原因が見つかることも多いのではないでしょうか。

05/26/2000

<<

Ｖｏｌ．124　　掲示板のコーナー

　当社の掲示板は、導入当時から見るとかなり活発化してきています。

　書きこみが増えると、どうしても設定されているコーナーの主旨におさまらないものも出てくるわけで、それは「その他の情報」的なコーナーに記入することになります。
　でも「この情報をその他として扱うのはいかがなものか」と考えさせられる内容もあるのです。
　そうなると当然新しいコーナーの設置を検討するのですが、ここでもうひとつ考えなければならないことがあります。
　以前は、たいして考えもせずにコーナーを設置し、こういう主旨の書きこみはここにするように。なんてやっていたのですが、そんな感じで作ったコーナーでいくつか活きていないものが...。
　本当に今検討しているコーナーは設置するべきなのかを考えてみなければなりません。

　とはいうものの、設置しようとするからにはその時点ではもちろん必要性を感じていたでしょうし、すぐに書きこみがなくなるであろうことを予想しているはずもありません。
　それと、頻繁に書きこみがあることと必要性があることとは別だとも考えますし、情報を出す側と受ける側など、立場の違いによってもその感覚は変わるのでしょう。

　そんなことを考えると、掲示板のコーナーは個人の独断で設置するのは難しいように思えます。

05/30/2000

<<

Ｖｏｌ．125　　原因を究明したい

　継続してこのページを読んで下さっている方はお分かりかもしれませんが、私はどうも原因を究明することができません。

　例えば、ある日ファイルサーバーの共有領域が見えなくなったとしましょう。そうすると私はまずログを見るのです。
　その現象についてログファイルに残っていることはあまりないので、とりあえず思いつくことをやってみます。問題が発生している機械の再起動やSambaの再起動、ユーザーの再登録などなど。

　いろいろと手を施して、ようやく回復したので一安心して苦情の発生元に報告。そこで「なにが原因だったの？」と訊かれると、あれ？なにが原因だったんだろう...。

　まったく分からないわけではありません。例えばパスワード再設定で直ったのなら、パスワードを保存するファイルの一部がおかしかったことが原因といえるかもしれません。
　でもそうじゃないんですよね。ユーザーはもちろん、だれよりも私自身が知りたいのは、なぜそのファイルが壊れたのかということなのです。
　それを究明して修正しておかないと、また同じ問題が発生する可能性があります。さらにはその先の原因、またその先の原因といった具合に根本を解決することが必要なのに。

　それができないのは、それに対する理解度が浅いせいだと思うのですが。

06/02/2000

<<

Ｖｏｌ．126　　過去の記事が売れてます

　ここのところ、このページの過去の記事を見てくださる方が増えているようで、非常に喜ばしく思っております。

　もちろん最新の記事を見ていただけることもありがたく思っておりますが、わざわざ過去のものにさかのぼってとなると、私が書いたつたない「日記」でも、情報として利用してもらっているのかと調子の良いことを考えてしまうわけです。
　そう考えると、どうにも嬉しいものです。
　その反面、それだけの価値がある記事を今まで書いてきただろうか...という不安も湧き上がってくるのですが。

　もしかしたら、ただロボットに引っ掛かっただけかもしれませんが、それをきっかけに今後当サイトをご贔屓にして頂けるかもしれません。
　そうしたくなるような価値がある記事を今まで書いてきただろうか...という不安も湧き上がってくるのですが。

　ともあれ、どんな理由で、どんな方法であるにしても、多くの方に見ていただけるということはうれしいもので、いままで記事を書いてきて良かったと思いますし、また、今後はもっといい記事を書いていこうと思えるのです。
　と、いえるような価値がある記事をこれから書いていけるだろうか...という不安も湧き上がってくるのですが。

06/06/2000

<<

Ｖｏｌ．127　　うそ日記

　先日NHKの「課外授業」という番組を見ていたところ、面白い授業をやるものだと感心したことがありました。

　この番組は著名な人が小学校に行って、一日教師としてその人独自の授業を行なうという主旨で、私はときどきみています。
その日の一日教師は、名前を忘れてしまったのですが確か作家の人だったと思います。
　で、授業の内容はというと、子供達に「うそ日記」を書かせるというのです。自分の存在以外はすべて想像で、時間、環境などはそれぞれが勝手に考える。
　近頃の子供はイマジネーションが欠乏していると言われている時代に、果たしてそんなものを書くことができるのだろうかと思いつつ見ていたのですが、書き上げた作品の内容に驚きました。
　子供達が書いた「うそ日記」は、どれもすばらしい出来で、そのまま短編小説にでもなるんじゃないかと思わせるような作品ばかりです。

　近年あらゆる分野において作業に創造力を要求される世の中で、測量業や情報分野も例外ではなく、発想が作業の良し悪しを分けることも多くなっていることと思います。
　そんなときに子供達が書いた「うそ日記」的な発想をある意味うらやましく思うのでした。それとその授業を考えた先生も。

　私は趣味の関係上、瞬間的なひらめきや発想、創造力を要求されるのですが、やっぱり「うそ日記」のようにはいかず...

06/09/2000

<<

Ｖｏｌ．128　　話す

　人と話すということは、生きているうえでどうしても必要なことですよね。
システムを管理している私は、人一倍社内の人間と話をしなければならないのかもしれません。
でもこれが一つ間違えると非常に問題になる場合があるんですね。

　といっても特に具体的な例があるわけではないのですが、物申すじゃないですけどこうするべきではないですか？的な話は注意が必要と思います。
　話の内容が内容だけに、とり方によっては押しつけのように思われることもあるのではないでしょうか。
　そのうえちょっと表現がまずかったとなると、どんどんお互いの考えが違った方向に進み出し、収拾がつかないままになってしまったり...。

　その表現が故意に出たものなのか、それともちょっとした間違いなのかは言った本人しか分からないのですから、言われた側にすれば相手の人間性を疑ってしまうのは仕方のないことかも知れません。

　本来私がやるべき作業は、みんなの意見を聞いてそれを作業に反映させる、または自分の考えをみんなに理解してもらい、提案内容を実施していただく。ということが非常に重要ではないかと考える日々。
　どんなに忙しくても、言葉を一つ一つ吟味して、きちんと自分の意思が伝わるような話し方をしなければならないと再確認するのでした。

06/13/2000

<<

Ｖｏｌ．129　　特性と要因の図

　みなさんご存知であろう特性要因図。

　これは情報処理の試験にもでるんですよ。ただ、これが試験のいやなところで、私の場合"見た目"的な特徴とその名前程度しか覚えないんです。
　ですから、その質的な特徴や有用性などは知る由もありませんでした。
ところが機会があって内容をよくよく考察してみると、なんとも使えるツールであることに気付いたわけです。

　前述のとおり皆さんご存知かとは思いますが、ちょっと知ったかぶりをさせていただきますと、
　ある問題（特性）とその問題を構成している細かな要因を魚の骨のような形にまとめた図のことを特性要因図というのです。
まあ、特性と要因の関連性を表した図。特性と要因の図。特性要因図。ということでしょうか。
　これまでは「魚の骨＝特性要因図」と覚えていたんですけど。

　で、それを使用して視覚的に問題の関連性が細部まで把握できれば対策も立てやすいと。
　もっと早くそれを知っていたらいろいろと作業に役立てることができたのに、中途半端な勉強をしているから大事なことを逃してしまうんですね。

　広義でのシステム管理を考えた場合に、かなり有効なものだと思うので、これからことあるごとに使っていきたいと思います。

06/16/2000

<<

Ｖｏｌ．130　　スマートメディアは抜くべきか

　皆さんはデジカメを使わないとき、スマートメディアってどうしてますか？
スロットに差したまま放置していませんか？
　私はそうでした。それでいいと思っていましたし、抜いておくとなくしそうで。

　でもそれはあまり良くないらしいですよ。
なんでも、長期間いれっぱなしで放置しておくと、接点不良の原因になるとか。

　その長期間というのがどれほどの期間を指すのかは定かではないのですが、でもそれだったらなおさら差しっぱなしにはしないほうが良いですよね。

　デジカメを使うようになってから何年か経ちましたが、その間私のカメラのスマートメディアはほとんど抜かれることなく、カメラの中で過ごしているのですが、現状不具合は出ていません。あまり使わないんですけど。
　反対に会社で使用しているカメラはデータを取り込むたびにスマートメディアの抜き差しが行なわれ、最近ちょっとおかしいことがあったり。

　もしかしたら、長期間差しっぱなしも悪いけど、あまり頻繁に抜き差しされるのも良くないのかも...という説が私の中で生まれました。

　因みに上の説の事実関係は確認がとれていませんので。

06/20/2000

<<

Ｖｏｌ．131　　まだまだを確認しました

　先日、当社の社長も講師として参加した建設CALSフォーラム2000仙台セミナーですが、細かい内容については、21日づけのOwner通信及びプレゼンピッチをご覧頂くとして、私が感じたことは、自社の社長ながら、さすがだなと。
　テーマが「情報化の実践」ということで、ある意味この電算導入の歩みとかぶる内容になりがちと思ったのですが、情報化の歩みをうまく要約して、電算導入の歩みとは違った角度からまとめてあると感じました。

　ですが、あくまでもそれは概略をまとめたもので、詳細についてはこの電算導入の歩みを見ていただかないことには...という宣伝につながるのですが。

　しかし経営者とシステム管理者とでは、同じ社内での出来事をまとめるにしても結構な視点の違いが見られるものですね。
　まあ当然といえば当然なのですが、私が読ませて頂いてます「日経情報ストラテジー」などによく出てくる「これからのシステム管理者は経営的な知識も必要である」という言葉を受けて、社長の立場だったらどう考えるだろう。ということを考えるようにしているのですが、やはりまだまだのようです。

　ということで、20日のセミナーは、私はまだまだである、ということが確認できただけでもよかったと思いますし、それとここだけの話、ちょっと緊張気味の社長を見ることができたことも...。

06/23/2000

<<

Ｖｏｌ．132　　テレビをたたく

　社内でモニターに関する苦情が来ました。

　なんでも画面に横線が入るとか。見てみると確かにチラチラッと画面に横線が入ってぶれます。
　常に出ているわけではなく、ときどき出ては消え、暫くするとまた発生してというのを繰り返しているようです。
　定期的ではないので、物理的な部分での不具合であるように思えます。
予想通り原因はケーブルの接触不良で、対処することができました。
たたけば直るじゃないですけど、結構簡単な原因の場合が多いですよね。

　ところで以前テレビを見ているときに面白いものを目にしました。
　ある電気店の店員さんにテレビが故障したらどうすればいいのかというインタビューをしていまして、店員さん曰く「まずお店に持ってきてください。たたいたりしては絶対にいけません」
　で、スタッフがその店員さんの自宅に先回りして、テレビを移らないようにし、隠しカメラを設置しました。
暫くして店員さんが返ってくると家族からテレビが映らないとの報告。

　そして店員さんが最初にしたことは「テレビをたたく」。

モニタを直しながらそんなことを思い出してしまいました。

06/27/2000
<<

Ｖｏｌ．133　　現場が大事

　ある雑誌に「新世紀IT経営　100の勝因・敗因」という特集が組まれているのを見ました。
　これは５つのIT経営手法についてそれぞれの成功と失敗の要因を合計100個掲載していて、そのなかで目をひいたのは、ナレッジマネジメントの敗因「システム部門が推進役ですべてを取り仕切っている」です。

　正直それのどこが悪いのかわからないまま読みすすめていたのですが、要は「現場に役立つ知恵は現場からでるもので、それを評価するのも現場である」とのことです。
　ここまで読んでようやくなるほどと思えたわけですが、たぶんシステム部門が取り仕切ること自体が悪いのではなく、現場の声よりもシステムを重視してしまうことが悪いということでしょうね。

　幸いなことに？当社のシステム管理者は強力に推進できるほどの技量は現時点で持ち合わせておらず「すべてを取り仕切っている」には程遠いものとなっていますが。
　ですが、それではシステム部門が現場の視点で推進すれば良いのかというと、それには限界があるんだと思います。
　所詮それは現場の「視点」だけであって、経験など重要なものは何もないわけですから。と、考えると、紙面にあった「システム部門が取り仕切る」は、やはりだめみたいです。

　いままで、現場の視点で考えられるということは非常に大事なことだと思っていましたが、それにも増して、現場の意見を反映できることが大事なのではないかと考えるきっかけになった記事でした。

　そのほかにも「なんでそれが悪いの？」と思うような敗因が一杯載っていて参考になります。「日経情報ストラテジー」。

06/30/2000
<<

Ｖｏｌ．134　　外からも見える

　7月の3,4日と東京でセミナーを受講してまいりました。
内容は非常に充実しており、大変勉強になりました。セミナー以外でもいろいろとありましたし。
　セミナーの内容について具体的なお話をするのも良いのでしょうが、今回はちょっと見方を変えて。

　まず、講習会場の設備にも驚きました。十数部屋あったように記憶してますが、それぞれの部屋でそれぞれの講習が行なわれており、しかも各部屋20台程度パソコンが配置されていました。もちろんネットワーク接続されて。
　コンピュータが絡むセミナーをするには絶好の環境でした。まあそれを商売とされている企業ですから当然といえば当然なのですが。

　そんな環境を目の当たりにしてまず考えたのが、維持管理が大変だろうなと。
　ネットワークに接続できないなどの問題が発生するとあれだけの台数（部屋数）ですから範囲を特定するだけでも一苦労しそうに思います。
　なにしろ私は現在の社内環境でもヒーヒー言っているので。しかも配線が床下に潜っていたようで、もし何らかの事情でケーブルを変えなければならないとなるとそれはもう大忙しなのだろう...とセミナーが始まるまで一人で部屋を見渡したのです。

　それとセミナーのカリキュラムとでも言いましょうか、テキストに沿ってマニュアル通りとも思えるようにすすんでいき、かといって流れに外れた質問にもきちんと対応できていました。
　最後に講師を評価するものと思われるようなアンケートも準備されています。

　業務がきちんと体系化されているであろうことが外からでも覗えるような、そんなセミナーでした。

07/07/2000
<<

Ｖｏｌ．135　　試験区分が変わります

　先月の末に第1種情報処理試験の合格者が発表されました。

　私の場合は受験後の自己採点で合格の望みが薄いことは分かっていたのですが、それでももしかしたらという期待を持って発表を見たところ、案の定不合格でした。

　次こそは...なんて思ってもみたのですが、来年から試験区分が大きく変わるんですね。
　これまでの1種や2種といった幅広い分野をカバーするものではなく、より専門分野に特化した形になり、それについて深い知識が要求されるようです。

　さらに、得た知識を実務に生かすには「どの業種で」という範囲も加わり、ますます専門化された知識が必要になると思います。
　ただし、「どの業種で」という部分まで試験に出るはずもなく、それについては実際に経験していかなければならないのでしょうが。

　ともあれ、さしあたってはテクニカルエンジニア試験のうち2部門合格を目指して勉強をしていきたいと思っています。その前に今秋のネットワークスペシャリストがありますけど。

　「どの業種で」は、実際の業務のなかで深めていけたらと。

07/11/2000
<<

Ｖｏｌ．136　　交換するか

　外出先からでもインターネットに接続する機会がありまして、いわゆるモバイルですか、今後も確実にそれが必要な予定も見えていることから、携帯電話を変えようかと思ってみました。

　現在はセルラーのcdmaOneを使用しているのですが、その機種はPaketOneに対応しておらず、通信速度が14.4kbpsなのです。
　で、64kbpsのPaketOne対応機種に交換しようといろいろ調べたところ、64kは下りだけで、上りは14.4kのままということをはじめて知りました。
　しかもプロバイダがPaketOneに対応していないと意味がないとか。
　そんなことから携帯を捨ててＨ゛なるものに乗り換えようかとも考えたのですが、メモリに登録してある人全員に番号変わった通知をするのは非常に面倒だし、あまり良い評判も聞かないのでそれも見合わせることにしました。

　でも、実際に現在の携帯では速度的にかなりの問題があるわけですし、かといって64kに変えたところでどれほどの違いがあるのかもISDNの経験から疑問視するところで、プラス個人的なもろもろの事情もあるため現状維持の状態がずるずると続いているのです。

　理想はセルラー（「au」ってなるんでしたか）から決め手となるサービスが出てくることなんですけど、正直な気持ちそれもあまりのぞめないような気がします。

　結局しばらくは現状維持が続きそうです。

　個人的な主観だけの内容でした。

07/14/2000
<<

Ｖｏｌ．137　　プロセスも

　 最近どうもこのページの更新が遅れ気味だったのですが、とうとうこんな時間になってしまい、反省するばかりです。

　ところで、いままで自分があまりにも予測で仕事をしていることに気付かされました。
　「このこらいの説明で分かるだろう」とか、そんな勝手な予測で行動していたのです。

　これでは全然システム的ではないし、場合によっては作業の効率を下げる原因になってしまいます。
　当然自分の中では考えるプロセスがあるわけですから、どんな説明をしたって自分ではわかりますが、他の人にはそのプロセスも話さないと分かるはずもありません。

　前に聞いた話で、ある人が何時の新幹線に乗ることになっているのかを、同行する人に聞くと、暫くして返ってきた返事が「大丈夫です」
その人の中では、
　10時の新幹線-->今は9時-->時間的に問題ない-->「大丈夫です」
となったらしいのですが、質問には全然答えていない。

　ちょっと極端な例ですけど、ようするにこういうことをやっていたんですね。

　今後作業をする上で非常にためになりました。

07/18/2000
<<

Ｖｏｌ．138　　最初の対策

　 各セクションごとに、パソコン担当とでも申しましょうか、部署内システム課とでも申しましょうか、そんな感じの役割を設けています。
　つまり、セクション内で発生したパソコンに関する疑問をその人たちに聞いてもらうような体制なのですが、どうもこれがうまく根付きません。

　原因をいろいろと考えてみると、私にあった相談は私がそのまま対処してしまうことや、担当者に十分な意思伝達がなされていないことなどがあげられます。

　まず私が処理してしまうことですが、相談があったことを「担当者に訊いて下さい」というのは結構難しいもので、それに担当者といっても通常の業務のほかに、という形なのでなかなか手がまわらないだろうなんて考えると、ついつい対処してしまう。
　また、対処したことをグループウェアなどで公開すれば良いのですが、なぜかそれもしていない。

　意思伝達についても、掲示板や会議室を利用すればもっとスムーズに行なえるはずなのに。
　それをもって、同じことを何回も質問されるなんて言ってみたところで仕方ないんですね。
　それに、グループウェアがうまく利用されているのだろうか...なんて考えても私がうまく利用していないのですから。

　ということで、上記各問題の最初の対策としては、私がもっと積極的にグループウェアを利用することなのでしょう。

07/21/2000
<<

Ｖｏｌ．139　　危機管理

　 7月24日、つまり昨日ですが私は東京でセミナーを受けていました。
　終了予定が17時だったので18時30分ごろの新幹線には間に合うだろうとふんでいたのですが、セミナーがおして終了したのは18時過ぎ。

　次の20時30分あたりのに乗ることにして、まずはグループウェアでも確認して...なんて思いながら接続してみると、やけに時間がかかります。
　結局接続することができませんでした。

　疑問に思いつつも回線が混んでいるのかも程度にしか考えず、メールをチェック。
　するとグループウェアの不具合を知らせるメールが届いてました。

　外部からはどうすることもできず、山形に到着次第会社に直行。で、なんとか復旧したのですが、帰宅後メールをチェックしてみると危機管理のご指摘が。

　そういえば2000年問題のときに考えたきりで、普段の業務にはさっぱり活かせてませんでした。危機管理。
発生することが考えられる問題について、誰がどのように対処するべきか。
　なにかが起こったときに、これが明文化されていればもっと速やかに対処できることはたくさんあるのに。

　今回の件は不具合が発生したことよりも、その対処に手間どったことに注目して今後の作業を考えるべきなのでしょうね。
　原因追求も必要ですが、対処の仕方の分析や体制の確立が求められているように思います。

07/25/2000
<<

Ｖｏｌ．140　　処理＆整理

仕事は早めに処理しておくべきです。

いつも私は言われます。

ちょっと気を抜いたりするとあっという間に山です。

そうこうしているうちに、優先順位もつけられなくなってしまいます。

そしてなにをやらなければならないのかも把握できなくなってきます。

関連資料なりちょっとしたメモなり打合せの記録なり、なにかしら残っているのでなんとかできるものの、非常に良くないと自分のことながら思います。

ひとつずつ処理しているうちに思い出すこともあります。

「これが終わったら忘れないうちにそっちをやろう」なんて思ってちょっとメモをとっておくのですが、そうなると思い出した作業のことが気になって今進めている作業に身が入らなくなってしまいます。

そんな感じであちこち少しずつ手をつけて、全体的にちょっと進行するものの、当然終わるのは遅くなります。

早めに処理することはもちろんですが、うまく整理する方法を学ぶことも必要なのでしょうか。

今日も今日とて、ある作業をしている最中に思い出したことがあります。
このページの更新です。

ということで毎回のように更新が遅くなって申し訳ございません。

07/28/2000
<<

Ｖｏｌ．141　　Macの価格

　機会があって、ある社員の自宅のパソコンを見せていただいて、入っているソフトの多さに驚きました。

　価格的には今の競争状況から見るとそれほど安くはないのですが、ソフト分の価格を差し引けば本体価格は凄いことになっているような気がします。
　まあそのソフトをすべて使うのかどうかということは別として。

　そんな中でなかなか価格が下がらないのがMacintosh。以前から比べると実際はかなり安くなっているようですが、DOS/V機のそれと比べるとどうしても割高感を感じてしまいます。

　ちょっと考えてみたのですが、 Macintosh には競合する会社がないのでは？と思います。

　VS_MS-Windows という考え方もあるでしょうが、それでもMacでなければ...という固定客というか浮動票というか、あるんでしょうね。

　ほんとのところ、価格がDOS/V並に下がらない原因がそれなのか、もっと言えば果たして固定客が本当にいるのかは定かではないのですが。

08/01/2000
<<

Ｖｏｌ．142　　来年の春

　今日が秋季情報処理試験の申し込み締切りの日です。

　今回私はネットワークスペシャリスト試験を受験することにしたのですが、この試験も今回限りとのことで、なんとも合格しておきたいところです。
　なにしろ春の1種は逃してしまったので。

　で、秋季の合否に関わらず、来年の春季試験でもなにかしら受験するつもりではいるのですが、これまで目標にしてきた1種がなくなった今、なにを受験するべきか。

　情報処理技術者スキル標準というものが発表され、現在は５つの試験区分に対してのみなのですが、それを見る限りでは実業務と照らし合わせるとテクニカルエンジニアのシステム管理部門あたりが適当に思えます。
　以前でしたらソフト開発やデータベースを受験するところなのでしょうが、最近の作業傾向から見るとどうも違うような。違うことはないのでしょうが要求されていることまたは自分が欲しているところとは若干ずれているような気がします。

　まあその前にネットワークスペシャリストがあるわけですし、スキル標準を読んでみて、情報技術者の先輩に相談してみて、それから決めてもいいかなと。

　ちなみにスキル標準は情報処理技術者試験センターのサイトから入手可能です。

08/04/2000
<<


Ｖｏｌ．143　　ほんとの目的以外で
　

　昨日（8/7）は東京でセミナーがありまして、同社主催によるセミナーは今回で3回目です。
　終了予定は17:00なのですが、内容が濃く、いつも40〜60分終了がおしてしまいます。

　昨日も例によって終了が17:40。18:32の新幹線に乗りたかったので、終了後会場から最寄駅までダッシュ。
　時間的には1時間近くあるので急がなくても間に合うのですが、30分前にはホームにいないと山形まで立ちっぱなしという事態に陥ってしまいます。
　で、東京駅についたのが18:00ちょうどだったので、なんとか座れるであろう時間帯であったわけですが、改札の脇に山形新幹線発車時間未定の張り紙が。

　会場から駅までダッシュした意味を分析しつつ、とりあえず携帯電話から新幹線が遅れている旨を会社へメールで送信しました。
　まもなく社長から「飯でも食ってゆっくり帰ってきてください」との返信があり、まあ発車のめどが立たないしそれも良いだろうと階段を降りて食事する店を物色することにしました。
　ちょっとすいているそば屋に入り、夕食をとって再び改札付近にいったのが19:35あたり。
　するとなんと19:34だったかそこらの時間帯に山形新幹線が出るらしいのです。
　いろいろあって多少出発が遅れても、今からホームへ行ったのでは確実に間に合わないと判断し、結局1時間後の最終に乗ることにしました。

　最終の新幹線もこれまでに経験がないくらいに混み合っており、座席に座ることはできたのですが、私の目の前に、通路ではなく座席の間にまで人が入りこんでいる状態。
周りを見渡すとそれは私のところだけだったようですが。

　セミナー以外のところで妙に疲れを感じた一件でした。

08/08/2000
<<

Ｖｏｌ．144　　時期
　
　ちょっとした会話で、ある情報技術者の方がもとは異業種の仕事をしていたことを耳にしました。
　そう思って回りを見てみると、情報技術の先輩方には、もともと違う仕事をしていて、その中で情報技術に触れ、それから本格的に勉強されたという方が多いように感じます。

　私の場合は、そもそもが情報技術。そのため、測量や設計のことがいまいち良くわからず苦労していることはここでも何度か書いているとおりです。

瞬間的に考えることは、隣の芝は青く見えるとでもいいましょうか、情報技術から入ってその他の業務を身につけるよりも、その逆、つまりもともとある分野で仕事をしていて、その流れから徐々に情報技術へ...という流れのほうが両立しやすいんじゃないかなどということ。
次の瞬間でそれは思い込みであることに気づくのですが。

　話をもどしてちょっと考えたことは、ある時期から情報技術自体が職業として成り立つというか、それが確立されたというか。

　まあそれでも企業の中で情報技術者の存在を突き詰めると、結局は情報技術だけでなくその企業の業種に関する知識や経験が必要になることはすでにみなさんご存知の通りかと思いますが。

その両立がなかなか難しいんです。

08/11/2000
c

Ｖｏｌ．145　　法則
　

　今週の前半にお盆休みを頂きまして、その間のシステム管理は私以外のシステム課員2名にお願いしました。

　以前セミナー受講時に会社でグループウェアの不具合が発生し、帰県後夜中に会社直行という苦い経験もあり、今回はそのあたりの体制を前もって整えてから休みを頂いたつもりです。
　体制を整えて、といっても「こういう問題が起きたら、こんな感じで原因を特定してこの手順で対処して...」という簡単なものですが。

　でもそういった段取りをきちんとしたときっていうのは、なにも問題が起こらないことが多いようで、逆に大丈夫だろう...なんてなにもしていかないと問題が発生する。ということはどこかで法則として確立されているのでしょう。
　今回もその法則を破ることなく、問題は起きませんでした。

　そもそもが夏休みを楽しむために作成した資料ですが、作成中は結局自分の作業を見なおすことができたり、あらためてその作業の意味を正確に把握できたりと、自分自身に役立つことが多かったりします。
　それに自分が持っている技術、といっても大したものではありませんが、それを課内という狭い範囲ながらも伝えることができるのではないかと。

　今月末にはまたセミナーがありますし、今度は緊急時の手順だけでなく普段の作業手順もつくっておこうかと考えています。
　それでセミナーを終えて帰ってきたら仕事がひとつ片付いてた...なんて考えてみたりするのですが、いかがでしょうか？

08/18/2000
<<

Ｖｏｌ．146　　Satchmo the great(番外編)
　

　電算とはなにも関わりの無いことですが、先週の土曜日山形の旧県庁（文翔館）で、ある映画が上映されました。
タイトルは「Satchmo the great」

　これは9月3日に行なわれるYAMAGATA JAZZ-MEETING のプレイベントと位置付けられていまして、なんでもフィルムが日本に1本、世界でも数本しか残っていないというものらしいのです。

　内容は、ジャズの歌い手兼トランペット吹きである"Lois Armstrong"という人のライブの映像とインタビューのみで、ストーリーがどうこうとかいうものではありません。
　しかも字幕がないのでインタビューでは断片的にしか内容を理解することができませんでした。それでも非常に満足の良く内容だったのですが。

　"Lois Armstrong"、もしくは"Satchmo"という人は、あまりにも有名な人で、ジャズをあまり聴く機会の無い私でさえ名前は知っています。
　名前をしらなくても「What a Wonderful World」と言う曲は、日本でも成人の7割は知っているのではないでしょうか？タイトルでピンとこなくてもメロディを聴けばわかるはず。

　上映会以来、すっかりサッチモにハマってしまいまして、翌日早速アナログ盤を探しに出かけたのですが、結局見つからずじまい。
　CDはいくつかのタイトルが置いてあったのですが、「ジャズを聴くならアナログ」と考えている私がそれを購入することはありません。
　黒人音楽が好きな私がジャズを聞く機会が少ないのはその辺に理由がありまして、近々セミナーのために東京へ行く機会があるので、そのとき時間を見つけてレコードをさがそうかと思っています。

もちろんセミナーの勉強もきちんとしますよ。

以上番外編でした。

08/22/2000
<<

Ｖｏｌ．147　　役割を考える
　

　私は開発部システム課に所属しておりまして、システム管理という仕事をしています。

　最近というか前々から必要なことだったのですが「開発部の役割」について考えていて、実はこれが結構難しかったりします。

　企業の中での役割ですから、当然最終的には利益を生む必要があります。
「利益を生み出すことは、利益を生む活動と競争力の元となる活動によって構成される」
ということを以前目にした覚えがあって、それから考えるとあきらかに私の作業は競争力の元となる活動に該当するわけで、それと現在行なっている作業という両端から、中心に向かって考えていけばなんとなく自分の役割全体が見えてくるでしょう。

　でもこれが開発部という括りになると、そうはいかないようです。

　開発部の役割を考えるということで、以前こんな話し合いを部署内でしたことがあります。
　開発部として共通の目的というか役割というかを仮定として掲げ、それを右端としましょうか。それと各人の作業を左端とし、間の部分について考えてみようと。具体的に右端だの左端だのという話はしませんでしたが。
　それがどうしても結びつかないのです。
　右端と左端とが結びつかないのなら、仮定した内容かまたは現在作業として行なっていることが本来の筋から外れていたと考えられるのですが、左端だけでも複数の方向に向いて、まとまる様相を見せないのですから。

　手法が間違っていることを願っていろいろと模索しているのですが、もしそうでないとするとさらに面倒なことになりそうです。

08/25/2000
<<

Ｖｏｌ．148　　PS対応、非対応
　

　電子化が叫ばれている中こんな話もどうかと思うのですが、プリンタの件です。

　以前にも何度かここで書いているのですが、当社にはポストスクリプト対応のプリンタがあります。
　ポストスクリプトプリンタは
「WYSIWYG(What You See Is What You Get)」
を実現できると言われていますよね？
つまり見たままの出力がえられるということなのですが、私が受け付ける苦情の中には「画面と印刷物のイメージが違う」というものが意外と多く、ポストスクリプトの意味を考えてしまったことがありました。

　でも実際には、プリンタとは関係の無いところ、具体的には書類を作成したアプリケーションの段階で問題があるようで、編集画面とプレビューでの表示が違うのです。
　これをポストスクリプトのせいにしてみてもなにも始まりませんし、第一ポストスクリプト対応ではないプリンタでも違って印刷されるのですから、見当違いもいいところです。

　そんなことを考えた後は妙にポストスクリプト対応プリンタから印刷されたものがきれいに見えたりするんですけど。

　ただ、両方のプリンタを使用していて実感することは、図を含まない書類であればポストスクリプトであろうとなかろうと、たいして違わないということ。もし図を含んでいたとしても、その印刷の美しさがメインでもない限り、PS非対応のプリンタでもまったく問題がないということです。

　ようは目的にあったものを選んで、それに対してどのくらいの費用をかけられるかなのでしょうね。
（PS対応と非対応では結構な価格の差があるようなので）

08/29/2000
<<

Ｖｏｌ．149　　こんなときにかぎって
　

　またしても出張中に問題が起こってしまいました。

　社内のネットワークがつながらない状態で、メール、HTTP、ファイル転送などが行なえないとのこと。
　原因はどうもネットワークカードらしく、サーバーの再起動で復旧することができたようです。
　障害自体はたいしたことではなかったように感じるのですが、問題はやはり連絡でしょうか。

　これまでも何度か同じような障害が発生しており、当然その時の様子は文書化してサーバーに残してありますが、今回はそのサーバーが見えなくなってしまったのですから意味がありません。
　それと対処マニュアルを、こちらは印刷して留守をお願いしていた社員に渡し、そこにはどうにも復旧しなければ再起動が必要であることも記しておいたのですが、これもうまく機能せず。
　対処中、担当者から私に連絡を頂いたのですが、そんなときに限って携帯電話の調子が悪く、万年圏外状態。
　宿泊先にもどり、電話を直して留守電を聞いてはじめて問題が起きていることを知ったありさまです。連絡が入ってから2時間弱経っていました。

　その後、会社や復旧してくれた業者さんに連絡し、症状や回復した旨を聞き安心したのですが、いろいろと考えなければならないことが多いです。

　瞬間的にマニュアルを直さなければと思ったのですが、今になって考えてみると操作上の手順よりも、体制的な面で見なおしが必要に思えます。

09/05/2000
<<

Ｖｏｌ．150　　ままならない
　

　先月の末から今月の始めにかけてセミナーを受講してきまして、早速その成果が活かされる仕事に着手しています。

　要はシステムの構築なのですが、これが思ったより難しいんです。
　まあ設計の段階で悩むのは私の常ですから、ある程度予想はしていたのですが、実際に作成する段階で苦労するとは思いませんでした。
　セミナーで習ったのは基礎で、実際に構築するとなると当然基礎だけでは事足りないのですが、習ったはずの基礎さえもテキストを見なければ、ままならない始末。
　本当に習得することができたのだろうか？なんて考えているときに、セミナー中にあったことを思い出しました。

　同じくセミナーを受講された方が、講師に「テキストを見ないと構築できそうにないのですが...」との質問をされていました。
　講師の答えは「テキストを見ながら構築できるのでしたら良いのではないでしょうか」

　確かに現在仕事で活用している技術は、本で読んだこと、教えていただいたことを少しずつ実体験してようやく習得してきたものですし、いまだに資料を見ながらというものも多くあります。
　そう考えると、今の時点でいろいろと悩むのはそんなに悪いことではないような気がします。

　暫くはヘルプとテキストに大変お世話になることと思います。

09/08/2000

copyright1998：株式会社朝日測量設計事務所

ASAHI SURVEY ＆ PLANNING OFFICE CO.,LTD.