System House ACT Weblog

新年度前ということで、私の周りの仲間たちも次年度の契約更新が終わったようです。

先日、半年ぶりくらいに情報交換という名の飲み会で話をする機会がありました。
そのときに出た話題です。

技術者の人件費は、会計処理的には費用（経費）でしょう。
そのため、多くの SI 企業は利益を確保するために経費削減の名のもと、技術者の人件費を減らしているようです。
しかし、IT 不況からなかなか脱することのできない原因の大きな理由の一つがここにあるように思えます。

技術者の人件費は、経費ではなく『投資』と考えるべきです。
当然のことながら『投資』ですから、すぐに結果は出ないかも知れません。
また、結果的に『損』をするかも知れません。

しかし、経費として考える限りにおいては『将来の利益を生む』ことはありません。
投資と考えることによって、初めて『将来の利益を生む』ことが可能になります。

思えば、派遣業者が技術者派遣を行うようになって、この投資という考えがますますなくなってきています。
派遣業者にとって、技術者は投資の対象ではなく『商品』だからです。

ただ、逆の見方をすれば、技術者の人件費を『投資』だと考え、今の時点で人に投資することのできる IT 企業はチャンスです。
優秀であろうとなかろうと、一律に経費としてしか評価されない技術者の中から、優秀な技術者を見つけだすことができれば、将来大きな利益を生むはずです。

設備投資を行わない製造業の会社が衰退していくように、技術者に投資しない IT 企業も衰退していきます。

今も昔も IT 企業にとっては人が財産だったはずです。
財産を散財（人材の流出）することにもっと危機感を持って欲しいものです。

話は脇道にそれますが、私が取引させていただいているある企業は、人材を『人財』と表現しています。
何となく、未来を感じるのは私だけでしょうか？

仕様書に、

消費税額は 1 円未満を切り捨てる。

と記述されていた場合、

10.5 → 10.0

となるのは、誰もが正しいと答えるでしょう。

では、マイナス値だった場合、

(a) -10.5 → -10.0
(b) -10.5 → -11.0

のどちらを仕様作成者は意図しているのでしょう？

Microsoft Excel の切り捨て関数は FLOOR 関数なのですが、FLOOR 関数ですと (a) の -10.0 になります。
つまり、切り捨てとは「ゼロに近い方へ丸める」と定義していることになります。

一方、Java や VB.net, C# 等の floor 関数は、(b) の -11.0 になります。
関数仕様では、引数の値「以下」で最大の整数 と定義されています。
単純に表現すれば、「小さい方へ丸める」ということです。

では、データベースの ORACLE 等では、切り捨て関数というと trunc になるのですが、(a) の -10.0 になります。
これは、切り捨てとは「その桁以下の数値をゼロにする」と定義しているからです。

どれが正しいかというのは、実はナンセンスな議論になります。
なぜなら、何れも定義の問題だからです。

さて、ここで最初の質問に戻ります。
「消費税額は切り捨てる」と仕様書に記述した作成者の意図はどうなのでしょう？

正解は「わからない！」です。
作成者が仕様書に定義していない以上、作成者以外にわかる人はいないはずです。

しかし、ほとんどのプログラマは、作成者に確認することなく、自分自身の解釈(定義)でプログラミングすることでしょう。
作成者の意図が、その解釈とは異なっていたとしても、テストでもスルーしてしまい、結果的に本番リリース後に発覚するということが多々ある事例です。

悪いことに、SE 自身も自分自身の解釈(定義)で仕様書を作成していることすらあります。
エンドユーザーの担当者が「消費税額は切り捨てる」と言ったので、そのまま記述してしまったということです。

私の経験ではユーザー部門の多くは、切り捨てというとデータベースの trunc 的な「その桁以下の数値をゼロにする」と解釈していることが多いようです。

ということで、SE の皆さん、「切り上げ」や「切り捨て」については、

仕様書に正負の数値を例示する！

ということを心がけるようにしましょう！
そうすれば、仕様書のレビューの段階でユーザー部門に対しても確認することができます。

当サイトへのアクセスログを見ると 124.42.121.39 をキーワードで訪れる方が多いようです。
この ＩＰ アドレスへのアクセスを誘導する迷惑メールは、From アドレスを変え、かつドメインを大手 ISP や企業のものに詐称するなどしながら、日に３通～５通程度送りつけてきますから迷惑この上ないものでした。

私の場合は、もともと au 携帯の「指定受信機能」＋「なりすましメール拒否機能」＋「インターネット（PC）メール一括拒否機能」を使用することにより、迷惑メールの受信はほぼ皆無でした。
たまたま今回、大手 ISP のドメインを詐称された結果届いてしまい、ドメイン詐称の対策として「ドメイン認証規制」を行ったところ、逆にこの 124.42.121.39 のような迷惑メールの受信が増えてしまいました。
それが 124.42.121.39 というタイトルの記事 になった訳です。

現在は、再び「指定受信機能」＋「なりすましメール拒否機能」＋「インターネット（PC）メール一括拒否機能」に戻しています。
戻してから１週間ほどになりますが、その間に届いた迷惑メールはありません。

「ドメイン認証規制」では役に立たなかった au 携帯ですが、この「指定受信機能」で登録できるメールアドレスやドメインの数は 100 件あり、docomo の 40 件、Softbank の 20 件と比較してかなり大きくなっています。

迷惑メールは、送信元 (From) メールアドレスを毎回変えて送られてきますから、事実上拒否リストはまったくと言っていいほど効果がありません。
携帯の場合において効果がある対策は、

迷惑メールを拒否するのではなく、受信したいメールのみ受信する

です。
従って、「なりすましメール拒否機能」＋「インターネット（PC）メール一括拒否機能」で原則拒否しておき、受信したいメールアドレスを「指定受信機能」で指定するということになります。
そうすると、40 件や 20 件では明らかに少なすぎます。
その点で、 au 携帯の 100 件はかなり評価できます。
ドメイン詐称の対策としてドメインではなくメールアドレスで指定したいので、100 件でも少ない（既に 100 件設定しています）のですが、それでも迷惑メールの受信は月 1 件未満です。

ということで、au 携帯で迷惑メールにお困りの方は、「指定拒否」ではなく「指定受信」で対策してみてはいかがでしょう。
最初に「指定受信リスト」に登録するのはかなり手間ですが、設定後はその手間に見合うだけの効果を実感できるはずです。

タイトルは、もちろん IP アドレスです。

先月下旬くらいから、携帯（au）のメールアドレス宛に送られてくるようになった迷惑メールの本文中にあるアクセス先の IP アドレスです。

これを契機に、携帯の迷惑メール対策を考えてみます。

メール自体の発信元は

• 189.93.181.72 （詐称ドメイン : hotmail.com）


• 88.191.44.184 （詐称ドメイン : biglobe.ne.jp）


• 213.136.110.51 （詐称ドメイン : xfire.jp）


• 202.72.246.58 （詐称ドメイン : takefuji.co.jp）


• 213.134.167.232 （詐称ドメイン : gree.jp）

などとなっており、中には念のいったことに envelope-from も詐称しているものもありました。
この発信元はボットによるものですので、送信者の from や envelope-from によるフィルタリングでは防ぎようがありません。
効果のありそうな対策として、SPF や DKIM によるドメイン認証を利用するものなのですが、SoftBank（S!メール） や WILLCOM（Eメール） は受信側に実装していませんので無力です。
また、au（EZweb） は受信側に SPF 認証を実装こそしているのですが、None や Neutral を拒否しません。従って、事実上は未実装に近く、やはり無力です。
唯一、docomo（iモード）だけが受信側に SPF 認証 Pass 以外を拒否する実装をしています。

au（EZweb） は、SPF 未実装ドメインのことを考慮しての実装なのでしょうが、指定受信リストをホワイトリストとして用意しているのですから必要のない考慮です。
実装した技術者のセンスを疑います。
ちなみに、例として挙げた IP アドレスからの迷惑メールは、docomo（iモード）だけが「なりすましメール対策（一般ドメイン）」ですべて拒否できます。

しかし、ドメイン認証だけでは拒否できない迷惑メールがあります。
例えば、

• 203.167.89.167 : ghjgahja.com （詐称ドメイン : goo.jp）


• 203.167.105.89 : kjdhskjhjh.com （詐称ドメイン : clubbbq.com）


• 203.167.105.185 : kjahkjdj.com （詐称ドメイン : gmail.com）


• 203.167.93.50 : mnjjghjhgjk.com （詐称ドメイン : yahoo.ca）

などは、SPF レコードを実装した上で、迷惑メールを発信しています。
さらに、認証ドメイン名は毎回異なっています。
このような迷惑メールを防ぐためには、ドメイン認証後に「受信を許可する認証後ドメイン名」を指定できるようにするしかないと考えます。

設定が大変になりそうな感じもしますが、今まで受信を許可するメールアドレスリストを設定していたことを考えれば、かかってもそれと同等の手間にすぎません。

実際のところ、ここまで行って初めてドメイン認証の効果が現れると考えます。
そんなに大変な実装とも思えず、かなりの効果が期待できそうなのですが、さて携帯各社はどのように考えているのでしょう？

まさか、ある程度の迷惑メールがユーザーに届いた方がパケット代が稼げるので、今のままでいようとか…。（笑）
しかし、受信ドメイン認証を行っていない会社を見てみると…。まさかね。（笑）

さて、タイトルの件に話を戻します。
この 124.42.121.39 が本文中にある迷惑メールについて検索してみると、かなりの方が被害に遭われているようです。
幸か不幸か、IP アドレスや内容はほぼ同じなので、元から断つためにも 迷惑メール相談センター に情報提供しましょう。

自動車産業や電機産業といった製造業を中心とした派遣契約の打ち切りが社会問題化しています。
そんな中で、どうも気になるのは、派遣先に責任があるかのような報道や意見が多いことです。

そもそも、派遣という雇用の仕組みは、このような状況になった際の調整としての目的を持っていたはずです。
そうであれば、今、派遣先がまさしくその調整を行っているに過ぎない状況ではないでしょうか。
派遣先に雇用の保証を求めること自体が、派遣の趣旨に反していると言っても過言ではないといえます。

冷静に考えてみれば、派遣労働者が責任を求めるべきは派遣会社であるはずです。
派遣先との契約が打ち切られれば、派遣会社としてもどうしようもないという意見もあるでしょうが、それが通用するなら派遣会社ほどおいしい商売はないということになります。
現に今まで派遣会社はおいしい商売を続けてきたはずです。

派遣先に契約の延長や打ち切りの撤回を粘り強く申し入れるのは、派遣会社が責任を持って行うべきことです。
どうして現場の派遣労働者自身が派遣先と交渉しなければならないのか、また、それが当然のような報道にかなりの違和感を覚えます。

派遣先にのみ責任を求めている今の状況は、派遣会社を利するだけと思わずにいられません。

NBonline(日経ビジネスオンライン)にクロサカ タツヤ氏が『希薄な目的意識と、時間単価の“共犯関係”～下がり続けるIT関連業務の賃金』という記事を書かれています。

ユーザー自身が意識改革すべきという提言に異論はないのですが、ＩＴ業界に携わる側からの提言となるといくつかの疑問があります。

まず、最初に違和感を感じたのは、本来ＩＴ業界側が自己の意識改革で解決すべきことをユーザーへ責任転嫁しているのではないかということです。
『行き先を告げずにタクシー乗りますか』という例えがありましたが、実際のところはどうなんでしょう？
もしそうなら、『行き先を聞かずにタクシーを発車させる』ような業界にこそ問題があるのではないでしょうか？
しかし、ユーザーは『行き先を告げている』のが実情だと思います。ですので『行き先を聞かずにタクシーを発車させる』というようなことはないでしょう。
『行き先を告げずにタクシー乗っている』のではなく、『乗ってから行き先を変える』というのが実情でしょう。
でも、それはタクシーにおいても多々あることで、そのことが問題になることはないでしょう。

それよりも問題とすべきは、『行き先を告げている』にも関わらず『回り道をして料金メーターを上げるドライバー』の存在です。
確かに、『回り道』に気付かないユーザーやそれを指摘できないユーザーにも問題はあるでしょう。
しかし、タクシードライバーのプロとしての職務は『回り道をせず最適な道を選択する』ことではないでしょうか？
そのことが業界の評価へとつながり、堂々と対価を要求できる土壌をつくることだと考えます。
それは、ＩＴ業界自らが行うべき意識改革ではないですか？
決してユーザー側の意識改革で成しえることではありません。

次に、時間単価というビジネスモデルは否定すべきものかということです。
例えば、成功報酬という言葉が出てきましたが、ＩＴソリューションは原則成功して当たり前なのですから、時間単価に成功報酬を付加するとそれは二重取りになります。
ユーザーとベンダー間においては、時間単価（人月単価）に変わるビジネスモデルは難しいと感じます。

次年度から『工事進行基準』が義務付けられます。
人がすべてのＩＴ業界において、プロジェクトの人件費（原価）はどうしても人月単価や時間単価にせざるを得ない実情があります。
ですので、工数や原価の見積もりにおいていえば決して否定すべきビジネスモデルではありません。
問題にすべきは、その単価が妥当に評価されたものであるかということです。
ただ、それも妥当の基準がない以上は難しいといえます。

《続きがあります》

Panasonic Let's note T4 を愛用しているのですが、今回 VisualStudio 2008 をインストールしようとして、HDD容量が決定的に不足しているという状況に陥りました。

そこで、もう既に保証期間も過ぎていることから、HDDの換装を行いました。

購入したHDDは、東芝の MK1234GAX です。
秋葉原の T-ZONE PC DIY SHOP で、消費税込 ￥9,429でした。
120GBで、内蔵されている40GBの MK4025GASL よりも電源特性も若干良いようですので、電池の持ちにも効果がありそうです。

あと、HDDの内容をコピーするために、玄人志向の USB 2.0接続2.5型HDDケース GW2.5AI-U2 を消費税込￥980で購入しました。

HDD内容のコピーについては、System Selectorという手持ちソフトにパーティション管理機能がありますので、今回は購入する必要はありません。

さて、いよいよ換装作業です。

《続きがあります》

巷で問題になっている『年金特別便』。

誰（どの会社）がそのフォーマットを設計したかは知りませんが、決定的に欠けていたのは、『何のために』という視点です。

設計者は『データベース上にある年金記録の個人別一覧』を出せばいいくらいの気持ちだったのではないでしょうか？

『何のために』 … 年金の記録漏れを確認してもらう

このことをきちんと理解していれば、記録漏れが確認しやすいフォーマットを考えたはずです。
例えば、

昭和25年4月1日～昭和43年6月30日 (株)○○
昭和43年7月1日～昭和43年9月30日
昭和43年10月1日～昭和53年3月31日 国民年金

というように、期間を連続させ、記録のない期間は期間のみ表示してあとは空欄にします。

これくらいのことは、『何のために』ということが分かっていれば誰でも思いつくはずです。

《続きがあります》

社会保険庁のシステムの話題を黙って観ていたのだが、マスメディアを使ってそこまでいい加減なことを堂々と知ったかぶりするキャスター氏と国会議員の諸先生方にはあきれました。

《続きがあります》

今日のITプロ（http://itpro.nikkeibp.co.jp/）の記事だ。

記事は以下で読むことができる。

http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/?ST=biz_shinzui

的確な指摘をしているので、興味のある方は、是非一読されることをお勧めする。

さて、ここで取り上げたのは、一点だけ追加したいことがあるからだ
《続きがあります》