責任を転嫁するヤツはそこが限界

何度か経験したことであるが、問題が起こった際に責任を転嫁しようとする輩は必ず居る。
人間の性、などとかたづけられることも多いが、そうではない。やはり人間性は出る。そこで他人に責任を転嫁してその場を凌いでも、結局の所は自分から逃げているだけである。

これを経験すると、「ああ、人間ってやっぱり自分が可愛いんだな」と感じることはよくある。エンジニアに限らず、顧客でさえもだ。
ただ、本人たちも「その場しのぎであること」は分かった上で話をしているのは分かるのだ。

何度か見ているが、私の人徳のなさかも、と思うことはある。そのときは責任は全部かぶってやることにしている。どうせ下らない言い訳を聞かされるだけで、時間がもったいないからだ。
しかし、自分の責任から一時的に逃げて、仕事に対して、部分的にでも「これは俺が責任を持つ」といえないヤツは、正直使い物になった試しがない。

これもひとつのＩＴ業界の無責任なところだ。情けないけれど。

聞く耳を持てなくなったらITエンジニアを廃業した方がいい

価値観はいろいろあるので、反対意見も多いかもしれないが。


コンピュータ技術は、「人の仕事をサポートするモノ」である。今まで人力でやっていたものをコンピュータ化し、人間では膨大な時間がかかることを高速に行うことができる。

一人で企画し一人で作るケースは稀で、その背景には、当然「こういうことをしたい」という要望なり希望なりがある場合がほとんどだ。業務系のエンジニアはその思いを翻訳し実現していくのがコンピュータのエンジニア、だと言って過言ではないだろう。客のニーズをどう具現化していくのかが肝である。
それを、自分の思いだけで進めていくエンジニアは実に多い。特に技術力がある程度あると、業務はおろか、技術についても耳を貸さなくなる連中が実に多い。
実際、これがコミュニケーションの障害になっているケースもよく聞く。同じ打ち合わせに出ているのに、なぜか自分の都合で、当然合意を得ることなしに処理を削ったりするのだ。

特定の言語の特性を細かく知ることも大切であるだろう。が、顧客の意を汲んで製品を作成できるエンジニアが非常に少ないことに懸念がある。
エンジニアの頭数が揃っているからと、SEクライシスが解消される訳ではない。それを数だけで判断されるの傾向があるので、聞く耳が持てないITエンジニアは廃業してもらうのがいいのかな、と思う。

データベースのテーブルの項目名はコード内で定義する

VBAに限ったことではないが、ソースコード内にSQL文をベタ書きしているケースを見かけるが、テーブルの項目やテーブル名の変更があった場合、ものすごく手間が掛かる。
レコードセットの何番目、などということを指定しているケースなんかもあるが、テーブルが変更になった場合、影響を調べるだけでも一苦労である。

少しでもそのリスクを減らすため、テーブルの項目名をコード内で定義し、その項目を使うことをお勧めしたい。
私がよくやるのは、テーブル／ビューごとに項目名を取得するクラスを作ることだ。ただ、これは手作業で作るのはあまりに手間がかかる。テーブル定義書から自動生成できるVBAを作ればよいのだ。
これ、そのうちにツールとしてダウンロードできるようにするつもりである。

実際にあったことだが、エンジニアが勝手にテーブル項目名を変更してしまったことがある。上記のクラスを作っておいたおかげで、エラーが出た際に「項目名がなくなっているのでは？」とすぐに推測することができた。

他のいい方法、もっといい方法もあるかもしれないが、この方法は推奨する。