再度、GENEさんのページを紹介する

こっちが向こうを知っていても向こうはこっちを知らない、という程度に有名なGENEさんである。彼のページに、Power of wordsというページがある。その中の次のページを紹介する。

• どんな業種でも、真剣に仕事に取り組む人

※　大方賛成だが、「最低限の準備しかしないうえに、」は「最低限の準備もしないうえに、」だと思うが…。

「下見」をしないで「現場処理」

世界的に有名で、日本に住んでいるほとんどの人がお世話になっている通信会社グループがある。各家庭にケーブルを引き込み電話を設置する、なんて仕事をしている。

この仕事振りが「現場処理」のオンパレードである。下請けの工事会社に「明日の工事予定」なんてFAXが来て、

• 午前○件、午後○件

で仕事をこなす。下見準備なんてまずしない。となると現場に着て初めて
  「ありゃりゃ？、ダイアモンド貫通が必要ジャン」
なんてこともある。だから工事車両の荷台には、なんでもかんでも載っていて、兎に角、収めて次の物件にというやっつけ仕事がメインになる。仕上がりが綺麗という事はまず無い。

以上のようなGENE先生の教えから反する事をやっているのは本体ではなく下請けの工事会社が担っている現場だけかと思っていた。ところが、時間をかける準備をしない　→　いつもやっつけ仕事ですませようとするというのは、この企業の体質ということがよく判った。準備をしないで、すべからく現場処理なのである。

不真面目な人、とてもその道のプロと呼べない人は、いつもやっつけ仕事ですませようとする。最低限の準備もしないうえに、準備不足が一目瞭然であることにも気づかない。

それをこれから述べる。

最低限の準備もしないうえに、準備不足が一目瞭然であることにも気づかない。

周りがドキュメントを書かない人たちばかりだから、実は意味の無いドキュメントであっても用意するだけで流石！と言われてしまうのである。本人もその気になってしまうのである。しかし、周到に考えられていたのならば、後で「こうしたらどうでしょうかねぇ」なんて設計者自らが変更するのは変である。

「たびたび予定と機材が変わったから」
という言い訳が認められているようだが、よく観察すると、新たな機材が増えたのでもなく、以前と同じである事が判る。現状把握の図面を書いただけで、「使用前」のみなのである。「使用後」が無いのである。つまりプランではないである。単に構築当日に、現場で収容位置を見て新たなアイデアが湧いただけのことで、本来設計ドキュメントに反映できていなければならない内容なのに、それを用意していないのである。

現場での気付き・提案をすべからく反対するつもりではないが、設計ドキュメントに反映されていないということは、

• 考慮が甘かった

というだけの事である。アドレス体系を管理しているのと、環境構築設計のスキルが有るのとがイコールではない事が今回の件でわかる。

サービス網のWebサーバとDNSサーバの構築は、設計者のサポートのもと、
  「私、新人だけれども、スキル有るもんね〜。」
とでも思い込んでいる人が行った。さっさと行えばいいものを、

• どんなサービスをインストールするのか
• ディスクのパーテーションはどのように分けるか

をいちいち設計者に訊きにいく。必要なサービスはわかっているのだから、さっさとインストールして用意してしまえばよいのに、

• どんなサービスをインストールするのか
• ディスクのパーテーションはどのように分けるか

の指示が無いのならば自分で思うようにすればよいだけの事。ネットワーク設計者がそこまで詳細を意識していないのならば指示は無いはずだし、決めていれば指示もしくは手順書・設計書等の提示があるだろう。それらがなくて、あとになって、
  「実はこれもインストールして欲しかったのに」
何てことがおかしい。それ以前に、どんな使い方をするのか？が判っていれば、インストール時の質問も無いはずだ。

同様に環境設計者が「どんな使い方をするのか？」知らないから、WebサーバとDNSサーバの構築を指示してしまうのだろう。
（そういえば、項目策定どころか手順書レビューにもいなかったしね。これでよく必要な設計ができるな！）

このWebサーバとDNSサーバをUnixでなければならない理由も無いし、設計者の好み、なんて理由が通るのが変である。

指示した人がアホウである。

WebサーバとDNSサーバのインストール実施者が全て悪いのではない。（もちろん、なんでもかんでも訊いていたのはよくないが。）インストールを指示した人がいけない。指示方法・指示内容に不備があるのだから。ポートコンベンションとか言う絵だけでなく、論理設計図・物理設計図に結線する各機器のポート番号が無いのが駄目である。

ただ、設計者が全て悪いのでもない。意味の無いドキュメントを用意している事を気付かずに設計した気になっているのだから駄目な点はある。しかし、そんな人に「環境設計」を指示している人が一番いけない。30日ほど前に駄目な前例を残しているのにも関わらずである。各機器を一番よく知っているという事とと設計・指示のスキルが有るとは同意ではない。

実際、運用状態に入った時には、このUnixサーバはほとんど出番が無い。サービス網のサーバは、中隊では評価の低いWindows serverを使用した。用意したのはもちろん、僕である。で、振り返ると大活躍である。

設定変更・設定追加も容易だし、Etherealのキャプチャも他のWindows XPと同様の操作でできる。取得データのモバイルメモリへの吸い上げも簡単だ。他のオペレータも、無能者に環境設定を指示した小隊長も、何の違和感もなく、当該PCサーバをオペレーションし、データを取得できた。UnixマシンにEtherealをインストールするところからはじめたら、いったい誰が用意できた？

RAを払い出す実験も簡単にできたし、MACアドレスやIPアドレスの重複試験もすぐにできた。環境設計者が用意したUnixマシンならば、サービス網のDNSとWebサーバ以外の仕事はできなかっただろうし、そのためRAやMAC重複・IPアドレス重複実験には､別途PCを用意する必要があったであろう。

別に、Unixマシンでも悪くは無いが、環境設計者が「どんな使い方をするのか？」知らないから、サービス網での只のサービス提供マシンとしてしか準備できていないUnixサーバの出番が無かったのだ。
（OSの違いという事ではなく、環境設計者とその人に環境設定まで任せた人がお馬鹿ということが判るね。）

後に、このUNIXサーバは当初の予定ではない役を担い戦列に復帰した。信頼性のない8-516Aのサーバを利用しないで名前解決できる事に気付いた僕が、転送網でのDNSサーバとして利用する事にしたのである。この役目ならばサービス網のPCと異なり、データ取得には利用しないので、オペレーションしないから、どっかそこら辺において置けばよいのだ。

環境設計者もインストール担当も無駄な稼動をしたのだという事を理解できていないだろう。できれば、彼らに任せた小隊長には、無駄な稼動が発生した事に気付いて反省して欲しいものだ。だってその時僕が担当させられたのはケーブル敷設だぜ。人の配置、間違っているよね。

反省なければ対策はなく、問題発生の予防にならない。問題発生の認識さえなければ、問題再発の可能性は更に高まる。アホな人たちの阿呆な仕事を見てフラストレーションがたまるのは避けたいと願う。