Ubuntuサーバが乗っ取り被害に(2007年8月16日 @IT)
これは・・・DELLにも採用されいい感じだったんですがイメージダウンは避けられないですね。

残念ながら、コミュニティ管理者ジョノ・ベーコン氏によると、これらのサーバはいずれもバージョンが古く、Webソフトが多数詰め込まれており、セキュリティパッチが当てられていない―― 少なくとも、どのバージョンを走らせているか容易に分かる状況ではない――ことが分かった。(引用元 同上)

これはカミングアウトしすぎでしょ少なくとも。セキュリティホールはイタチごっこ的なもので、最新版であろうとも100%はないことは分かりますが、バージョン管理してません、いま何が動いているか分かりません、というのは・・・反面教師。

その他、News clipsいろいろ

IBM、サンのSolarisを自社サーバ搭載へ
(2007年8月17日 @IT)
Solarisって今更・・・何狙いなんだろう?合併への序曲?

デルが過去4年間の決算を修正・再表示、内部調査で不正行為発見【WSJ】(2007年8月17日 IT+PLUS)
DELLよお前もか・・・これからは大企業受難の時代なのかも・・・

東証大引け・大幅に3日続落――ITバブル崩壊時以来の下げ幅(2007年8月17日 日本経済新聞)
どこまで下げるか。来週も下げるか。絶好の買い場が到来。でもそういうときに余剰資金がないんだよなあ。


 さすがは時代の最先端を行ってる超先進国日本、温暖化なんて生易しいものじゃなくて、既に熱帯化に突入。
 いや暑いですね。40℃オーバーってのはどこの国だよ?という感じです。

 こう暑いと、家庭でもエアコン全開。省エネには協力したいけど、暑さによりIQが日経平均なみにダダ下がりで頭がボーッとしてきて、包丁で指切ったりガス〆忘れて爆発したり、なんか事故を起こしそうなんで、どうしてもエアコンに頼っちゃうんですよ。

 で、ブレーカーが落ちると。本日は、1度のみならず3度もやってしまいました。

 PCでなんか作業しているときにブレーカーが落ちると、立ち直るのに数時間、下手をすると1日以上立ち直れないショックに見舞われることがあり得ますが、そんなときでも、パソコン用UPSを設置していれば、精神衛生上、非常によいです。

 これのおかげで、不覚にも電化製品をブン回しすぎてブレーカーを落としてしまった場合でも、PCだけは煌々とディスプレイ光を放ちながら生き長らえ、セーブやシャットダウンを行うことが出来ます。大抵の場合は、それっぽい電化製品の電源をOFFにしてブレーカーを上げにいくわけですが、その程度の時間は十分持ちこたえてくれます。

 会社ってそもそも停電することが少ないし(ビルによるでしょうが)、大抵は重要ファイルを格納しているサーバーは最低限UPS設置しているでしょうから、PCが落ちても「仕事ができない!」なんてちょっとうれしそうに一息つくのが関の山ですが、家庭では作業データは大抵全てPCの中に格納しています。
 そんなPCが突然の電源断で、よりによってお亡くなりになった日にゃあ、泣くになけません。

 一家に一台、UPSは必要だと思いますよ。

#ちなみにウチはOMRONのBZ50LTという人気機種。長時間バッテリータイプで、値段も手頃。っていうか当たり前だけど自分が買ったときより安くなってる・・・

  1. 会社が儲かった
  2. 会社が儲からなかった
  3. 制度・法律が変わった
  4. 会社が問題を起こした

システム化の提案をするタイミング(2007年8月13日 一般システムエンジニアの刻苦勉励)

 システム化の提案タイミングって確かにいろいろありますね。

 自分は技術屋ですが、そうした提案段階において、営業につきあって探りを入れるみたいなこともやってたんで、経験にもとづき、尻馬に乗ってみます。他の皆さんどうやってるんだろう?

 どっちかというと、システム化提案のさらに前段階、いつごろシステム化の話を切り出すべきかをどうやって知るか?みたいな感じになりましたがパターンとしては概ね以下のとおりです。

  1. 組織変更、人事異動のタイミング:大抵4/9月だけど会社によって7月とかいろいろあるので慣例を聞き出すとよいでしょうね。部課長などの異動だけじゃなくて、新しい役員が入ってきて暫くしてからとか、出てったときとか、システム刷新!みたいな話が出やすいと思います
  2. 来期事業計画を考え出すタイミング:3月決算だとだいたい12月くらいからは来期の話をしだす(少なくとも自分が取引した大手SIerはそうだった)
  3. リース更改の1.5年前くらい:リース切れと同時にシステムも新調、っていうパターンが多いような。リース期間は現行H/Wが何かを聞き出せれば、発売時期と法定耐用年数と一般的なリース設定可能レンジから計算して、いくつかのタイミングにヤマをかけられる(実際には話術で直接聞き出してしまうのだが)
  4. 相手がひまな時期:あたりまえですが相手が忙しいとあんまり取り合ってもらえない

 結論としては、相手が「新しいことを始めよう!」という心理状態になっているタイミングを計るってのが重要だと思うのです。でも結局そうした情報を得るためにはある程度中の人と懇意にして出入りが出来る状況がないと辛いですね。

 結局、相手の状況次第という感じで。我ながら整理してみて思いましたが、意外と「意外性」はないですね。

SEやプログラマを少人数で派遣してしまうと、改善や計測のノウハウが誰にもたまらなくなってしまうことが多いことが指摘されていた。個人的な経験からも、あまり分業せずに一通りの仕事を一度やってみることはスキルや知識を積み重ねていく上で重要だと思っている。また、モチベーションの面でも同様なことがいえるのではないかと思う。

開発者の人材派遣の話とモチベーション(2007年08月14日 森崎修司の「どうやってはかるの?」)

 なるほど同じような悩みを持つ人はたくさんいますね。この悩みは業界における構造的な問題であると再認識。こと日本では永遠の課題なのかも知れない。(海外は知りません)

 ただ実際、自分の経験にあてはめると、派遣という形態も、用法を間違わなければ、そして運がよければ、ノウハウ蓄積手段としてさほど悪者でもないこともある。

  1. 派遣先によっては自社ではとてもできないような恵まれた環境で仕事ができることもある。例えば、自社ではとても触ることのできないようなインフラ設備や、自社ではとても協業などできないようなレベルの高い取引先との協業、など
  2. 派遣先で信頼を得れば、より重要な決定事項に関われる機会もあり得る。究極的には、例えば開発企画とか、予算配分検討とか、仕事の源を自らコントロールすることも可能(但しこれは、派遣先の上司が大変素晴らしい方であったために、派遣技術者である自分が本来関われないようなところまでやらせてもらった特殊ケースなのかも知れない)
  3. 請負開発によって「ある工程からある工程まで」をぶった切られた状態として仕事を分解されると、全体像が把握しづらい状態となり、開発という「部分」しか経験できない。企画段階で何がおこるのか、運用フェーズで何がおこるのか、そしてその対処や解決はどのように行うのか、など(運用は場合によっては開発と同じく請け負うことも可能だが、企画段階というのはほぼ派遣形態じゃないと関わることができない)
  4. 派遣先の「異文化」に触れることで、自社の文化の良いところ、悪いところを客観的に見ることができる(自社のほうが良いところが少なくて失望しちゃう危険もあるけど。他人の芝は青い!)

 こうして自己整理してみると、ある程度プログラミングも設計も経験して、ヒューマンスキルの基本を学んだ段階で派遣されたからこそ、そしてその派遣先の上司の考え方が柔軟であったからこそ、派遣のメリットを享受できたということなのであって、恵まれたケースだったとは思う。

 確かに、経験の幅が乏しい若手を派遣に出してそれっきり数年、なんてことになると自社にノウハウをためられる可能性は少ない。

 その一方で、派遣先の環境で自社では経験し得ない経験を積んで帰ってくれば、どんな状況で働いていたとしても少しくらいは後で実務に活かせるノウハウを身につけている(上手くいかなかった反省も次への改善につなげることが出来ればノウハウ足りえる)と思うし、そういう考えで仕事をしていない、させていないとすれば、それは契約形態の問題というよりも、その会社の人材育成に対する考え方や直属上司の問題でもあると思う。(あとは、あまりそこに逃げたくないけど、本人の意識や資質)

 というわけで「人材派遣を続けるとノウハウがたまらない」大局的には同意。

 ただ、そこに問題を帰結させる前に、派遣なりのメリット極大化デメリット極小化を考え実践したか、という視点も必要だし、自分の周囲にいる派遣中心の会社のなかにはあんまりそういうことを考えずにローリスクローリターンな派遣形態に自分から流れていきながら「派遣はだめだね」なんて言ってる人達も結構な数いるよ、ということで。

 といいながら具体的にはどうなのよ?という部分はもやもやしている。
 あと森崎さんの提起されている「営業的観点」ってやつから離れてしまった。

 日をおいてもう一回考えてみます。

関連記事1:明日の自分を創る
関連記事2:SE/PGという言葉で安易に技術者を区分けしてしまう行為自体が問題だ

 「Linux and Windows Interoperability:On the Metal and on the Wire」(マシン上およびネット上でのLinuxとWindowsの互換性)と題された講演でラムジ氏は、「各種のデータセンターアプリケーションを組み合わせたいという顧客の要望はよく聞くが、デスクトップ上でLinuxアプリケーションを使いたいとか、Linux上でデスクトップを仮想化したいといった要求はあまり聞かれない」と述べた。

「Linux上でWindowsの仮想化、認めない」――米マイクロソフト(2007年8月9日 @IT)

 へえ。当然ライセンス持ってるけど、それでもダメなの?「認めない」ってつまり「訴えるぞコノヤロ」ってことでしょうか?

 タイトルがセンセーショナルだ。実際の講演はひょっとしてもう少しソフト表現だったのかも知れないけど、このタイトルに食いつくブロガーは多いはず。もともと敵が多いであろう市場の支配者の一人であるMS、小市民が叩いてもびくともしないところが、余計に叩きやすいだけに、この発言は「釣りなのか?」というくらいベタなタイトルだ。

 しかしLinuxはともかく、Macユーザなんかは、仕事上MSプラットフォームを持っている必要性がある人もいるだろうに。
 (いまの時代そんなことねえ!Macだけあればどんな相手と仕事するにも十分だ!ということだったらごめんなさい)

 そういう人達にもOSが追加で「売れる」としたらMSにとっては利益なんじゃないのかなあ。仮想化して使うつってもライセンス不正で使うわけじゃないんだし。

 上記の発言の論拠が分からないので何とも言えないが、せっかくOSSにも実は多くの貢献をしていたりするMSなのに、こうした発言がOSSの敵として流布されてしまう(であろうという)のは、もったいないと思う。

 まあ確かに総じて言えば、デスクトップに関しては、異OS上で仮想化するニーズはそれほど多くないのかも知れない。
 (クライアントOSやブラウザの種類ごとにテストをしたいときなどはデスクトップ仮想化も便利である気がするが)

 しかし、サーバは別だと思う。現に、過去に構築されたシステムにおいては、ハードウェア老朽化&リース切れに伴い新ハードウェアに更改するものの、その上で稼働させているソフトウェアについては「作りなおすほどの資金も使いたくないし、互換性を調査したりする時間の余裕もアタマの余裕もない」といった理由で、何とかそのまま稼働させることができないか?という要望も少なからずある。

 新ハードウェアとなったことでOSそのものが大幅に新しくなってしまうと、多くの場合ソフトウェア互換性が失われるため、仮想化技術を使って「旧サーバをそのまま再現」させることで対処したりする。

 特にスクラッチ開発したソフトウェアは、パッケージなどと違って、ほとんどの場合アップグレードパスまでは用意されていない(下手をすると開発ベンダがなくなっていたり、担当者が辞めてしまって対応できなくなったりしている)。

 本来、Windowsの場合は特に、そこそこ下位互換があるので、試験さえ全て実施可能なら新OSに移植するのが望ましいのだが、受託開発のシステムでは、ドキュメントに不備が多かったり、ソースがつぎはぎで「その場限りのやっつけ」だったり、そもそも上記で述べたように元の担当者から引継を受けることが不可能であるケースが多いのだ。

 実際、VMWareで旧環境をまるごと動かす、なんていう話が出始めている。

 このように、既に「やっちゃった」人達にはどんな影響があるのだろうか?

 それとも新Windows上で旧Windowsを動かすならおk。という「ずっと俺のターン!」ということなのか?