台風が東京に接近してきた。大型らしい。

ウェザーニューズの台風チャンネルで動きを確認してみる。天気予報はYahoo!にもあるが、こちらの方が美しい。

この会社、東証1部上場で、時価総額90億円弱。四季報によれば、「3年後に国内と海外の売上比率同等（現状7対3）が目標」とのこと。売上は110億円程度。前期は赤字だが、きちんと配当も出しているし、株価は安値圏にあると感じる。

以前、「日本オラクルは割安」と書いたが、ここにも期待できそうだ（日本オラクルは結局買ってないです。念のため）。海外進出加速でこのビジネスモデルとくれば・・・。

JCF　2005の記者発表会のあとで、米IBMのPLMソリューションズ　ゼネラル・マネージャー、ウォルター・ドナルドソン氏と少しの間、話す機会があった。

私はAMRリサーチのブルース・リチャードソン氏がさまざまな場面で話しているDDSN（デマンド・ドリブン・サプライ・ネットワーク）が理想型だと考えているのだが、最大手のベンダーとして、IBMがどう考えているのか聞きたかった。

ドナルドソン氏は、非常に親切に質問に答えてくれた。私はたいして英語をしゃべれないので、質問したときに相手の耳の傾け方を見るだけで、まじめに聞いて答えようとしているのかどうかがわかる。がんばれば意味は通じるのだ。とにかく、ドナルドソン氏は、黒人らしい（たいてい、黒人の声のトーンは優しいと感じる）やわらかさで、思うところを語ってくれた。

今回のカンファレンスは、主題がPLMとはいえ、ダッソーと共催なので必然的に設計・開発段階の効率化が主要な話題になる。ただ、ドナルドソン氏は、ゼネラルセッションの講演でも、そこだけがPLMではない、と明言した。実際に、製品の寿命が終わっても、企業は保守部品を在庫しておかなければならない。製品のローンチに失敗したら、在庫コストをまかないきれないかもしれない。

そうしたリスクも考えた上で、PLMをどう実装してくべきかを考えるべきだろう。また、ドナルドソン氏は、CRMとの連携など、いくつかの興味深い話をしてくれた。現場の話を聞いている人ならでは、だ。これから、世界で最も品質の高い製造業者（であり、かつIBMの顧客）を巡るらしい。再び日本に来てくれたら、是非会いたい。有意義な話を聞けた。

なお、製造業の海外移転が騒がれているが、この問題は面白いのでいままさに調べているところだ。製造コストなんて、実はそれほどでもない可能性がある。

JCFに参加して、最も面白かったのは３D　CADのデモだった。

PLMと聞けば、最近上場したネクステックのおかげかどうか、BOMが中心になってしまいがちなのだが、BOMは見えない。

今回、JCFではダッソーがメーンだったために、CADが中心だった。3DのCADは、目に見える。トヨタの講演で、自動車が障害物に衝突してつぶれる実験と、CADによるシミュレーションを同時に見せてくれたのだが、これが非常によかった。トヨタ幹部も絶賛とはいかないまでも、使える程度のシミュレーションになってきたとの太鼓判。技術の進歩はすごいなあ、と単純に感心した。

こうした「見える」ものが多いので、製造業もしくはIT系で製造業に興味のある人は、CAD系のカンファレンスに行くと面白いはずだ。こうしたソフトウェアはダッソーを含めた数社の寡占状態なのが現状。使うのは難しそうだが、使いこなせれば相当に役に立つのだはないだろうか。これは、ベンダーの売り文句だけでなく、心からそう思った。3D CADはこれからユーザビリティの勝負にはるのだろう。そうなれば、記者にはわからない世界かもしれない。ともあれ、より使いやすくなることを切に望む。

名古屋で開催されている2005 JCFを取材している。

日本IBMとダッソー・システムズが主催しているPLMカンファレンスで、今年で6回目。名古屋での開催は初めてで、これはダッソーが愛・地球博のフランスパビリオンに出展していることとのからみもあるそうだ。名古屋のおかげかどうか、トヨタ自動車役員の講演も予定されている。

現在、1日目のゼネラル・セッションが2本終わった休憩中。15時より第2部がスタートし、夕方に記者会見が行われる。

なお、PLMという考え方は相当に幅広いが、今回はダッソーのソリューションが中心なので、設計・開発の最適化・効率化がメーンになっている。

IT以外のことでもたまに書くのは許されるらしいので書いてみる。ITにしか興味のない人は読まないでください。

昨日、非常に興味をひかれるニュースに接した。そのまま引用すると著作権がどうのこうのとうるさいので、サマリを。

『仕事上の失敗をした会社役員の男性に言いがかりをつけた元暴力団員が、医者に麻酔を打たせた上で小指の第1関節を切断させた』

ニュースソースによって、「医者も一緒になって言いがかりをつけた」「医者はその後（傷口を？）治療した」（でも指をくっつけようとしたのかどうかはわからない）などとさまざまだったのだが、私が不思議に感じたのは、「指詰め」についてだ。

指詰めは、その痛さが第1、次に指がなくなることへの恐怖、そして指のない生活の不便さ、という順番で苦痛を与えるものだと考えていた。つまり、指詰めの瞬間が悪事に対する最大の罰であり、続いてそれまでの恐怖、詰められた後はそれほどたいしたことはない、と考えていたのだ。ネットでは、詰める＞詰める前＞詰めた後とでも表記すればいいのだろうか。

ところがこのケースでは、詰めた後に重きを置いていると考えられる。麻酔が全身麻酔でなければ、詰める前も多少は恐怖を感じるだろうが、麻酔のない恐怖よりましだろう。そうでないとすれば、会社役員のやったワルイことが苦痛を与えるほどではない、と判断されたのだろうか。

ネットで検索して調べてみたのだが、詳しそうなサイトを見ても、「相手への恭順を、苦痛を我慢することで示す」（指詰め時）「小指がないと力が入らない」（指詰め後）など、どこに重きが置かれているのかよくわからない。

気になるので、詳しいひとがいたら教えてください。

　前回の×を消す作業を始めよう。前回は、企業が2007年問題に立ち向かうため、新しいシステムを作ることと、現行システムを運用し続けることの2つの選択肢を提示した。引用する。

1．新しいシステムを作る場合

○　新しい世代によって適切に運用される
×　これから作る世代もいずれは引退する
×　ノウハウの積み重ねのある基幹部分を若手やアウトソーサーがきちんと作れるかどうか不安
○　運用・維持コストが下がる
×　初期コストが莫大
○　アーキテクチャが新しくなれば、ニーズの変化に対応しやすい
×　標準的なアーキテクチャは移り変わるため、作ってもどうせまた古くなる

2．現行システムをそのまま運用する場合

○　初期コストが不要
×　高額な運用・維持コストはそのまま
○　引退したベテランを安く雇える
×　人間には寿命がある
○　これから仕様書を整理すれば業務ノウハウも引き継げる
×　ツギハギだらけで拡張性に乏しいシステムのままでは、ニーズの変化に迅速に対応できない

それぞれについて見ていこう。

1．新しいシステムを作る場合

×　これから作る世代もいずれは引退する

→スタッフ個人のノウハウに依存しないシステムを開発しなければならない

×　ノウハウの積み重ねのある基幹部分を若手やアウトソーサーがきちんと作れるかどうか不安

→パッケージを使えば問題はクリアされるかもしれない
　→パッケージベンダーが倒産したり、買収される可能性は排除できない
　　→パッケージベンダーに出資することの検討
→「あなたがたにできたことは、若手にもできます」。信じましょう

×　初期コストが莫大

→上記と同様、パッケージの検討
→運用する期間を考え、トータルコストで比較する

×　標準的なアーキテクチャは移り変わるため、作ってもどうせまた古くなる

→上記と同様、パッケージの検討
　→できる限りノンカスタマイズで導入し、バージョンアップをスムーズにする努力が必要
　　→パッケージに求めるレベルは相当高くなる
→はやりのSOAを使ってすべてを開発する
　→ベンダーによってSOAの定義が違うため、単純にSOAと言っても古くなるかもしれない（潮流に取り残されるかもしれない）

2．現行システムをそのまま運用する場合

×　高額な運用・維持コストはそのまま

→サーバコンソリデーションなど、ハードウェア面でコストを抑える努力は可能

×　人間には寿命がある

→回避不可能。担当者が生きているうちにドキュメント化しておかなければ、最終的には大変なことになる

×　ツギハギだらけで拡張性に乏しいシステムのままでは、ニーズの変化に迅速に対応できない

→拡張性を上げるために、BPM機能を含むインテグレーション基盤を構築する
　→インテグレーション基盤から現行システムへのつなぎ込みに業務ノウハウが必要

　ここまで、1と2の×を消す作業を行ってきた。この中で決して消えない×は2の「人間には寿命がある」である。同じ人が永遠にお守りをしてくれるわけではない。1の「標準的なアーキテクチャは移り変わるため、作ってもどうせまた古くなる」も消えそうにないが、いまより良くなるのなら、新しくした方がいい。あとはコストの問題だ。システムを新しくした方が運用・維持コストが下がるのだから、何年使うつもりなのかを考えて、コスト計算をする。これは企業によってまちまちであり、一概に新システムに移行する方がいいとは言えなくなってくる。いまより良くなるメリットと良くするコストが釣り合わなければならない。

　ともあれ、これまで頼りになったベテランは一線を退く。知識の伝承は必要だ。ここまで見てきたように、当面やるべきことは、「きちんとした現行システムの仕様書を作ること」である。2の○に「これから仕様書を整理すれば業務ノウハウも引き継げる」と書いた。じつはシステムに縛られていたために変えたくても変えられなかった業務プロセスがあるかもしれない。そういうものも洗い出す必要がある。

　これができれば、おそらく新たなシステムを作るという決断を下す企業の方が多くなるのではないだろうか。

　谷島さんからいただいたメールを引用しておく。ニヤリとできるはずだ。

--
谷島の考えは、引用していただいたように、現行の基幹系システムは全面的に見直す必要がある、にもかかわらずそれは並大抵のことではできない、というものです。ではどうするのかと言われると、自分で考えてください、というのが答えですがこう書くと殴られそうです。
--

　そのときがくるまで、まだ1年以上の時間が残っている。

　なお、私のざっくりとした考えは、以下のとおり。

フェーズ1：現行システムの正しい仕様書を作る（3～4カ月）
フェーズ2：RFPをばらまき、パッケージ選定（2～4カ月）
フェーズ3_1.a：システム導入（基幹業務系）（6～12カ月）→合うパッケージがあった場合、もしくはパッケージに合わせる場合
フェーズ3_1.b：システム導入（基幹業務系）（24カ月）→パッケージを使わず、自社開発する場合
フェーズ3_1.b：システム導入（BPM系）（12カ月）→まっさらな状態で導入する

　やはり新しいシステムは必要なのではないだろうか。しかし、単純に私がパッケージ至上主義者と見なされるのもどうかと思うので、なぜ自社開発もしくはオーダーメイドでなく、パッケージを選ぶべきなのかを次回に書きたい。

　今回から、2007年問題について、私の意見を書く。まずは、議論の前提として、考え方のベースを書いておく。言葉足らずな部分があるかもしれないし、そもそも前提に反論したい人もいるだろう。ぜひコメントください。

　前提条件は、「業務システムはコスト削減装置である」という考え方に置く。IT全体ではなく、業務システム。利益を生むための仕組みをITで作ることは可能になったが、ルールを作ってそのルールどおりに動かせばそれで済む部分は、“人手を省くために”システム化する。その、せっかく人手を省いた部分が、結局は人手によって支えられていて、しかもブラックボックス化していることが2007年問題の本質ととらえたい。「ITは企業文化そのものだ」と言う人もいるが、それは自分の所属する情報システム部門の雰囲気を指しているだけ。企業内ユーザーである業務部門からそういう声を聞いたことがない。

　では、2007年問題は、システムを作り直すチャンスととらえたらいいのだろうか。

　ツギハギに次ぐツギハギで膨れ上がったシステムに、企業はいくらのコストを注ぎ込んでいるのか。それは考えてみるべきだ。これから引退するベテランは、失礼ながら非常に高コストな存在だ。彼らが一気にいなくなる。そのコストをシステムの新規開発に転用する。もちろん、システムがすぐに出来上がるわけではないため、ベテランの中で必要な人材には、嘱託として（給料を下げて）残ってもらい、システムの保守を任せればいいではないか。こう考えてもいい。

　しかし、システムを新しくするだけで問題が解決するのだろうか。2つにわけて考えてみたい。

1．新しいシステムを作る場合

○　新しい世代によって適切に運用される
×　これから作る世代もいずれは引退する
×　ノウハウの積み重ねのある基幹部分を若手やアウトソーサーがきちんと作れるかどうか不安
○　運用・維持コストが下がる
×　初期コストが莫大
○　アーキテクチャが新しくなれば、ニーズの変化に対応しやすい
×　標準的なアーキテクチャは移り変わるため、作ってもどうせまた古くなる

2．現行システムをそのまま運用する場合

○　初期コストが不要
×　高額な運用・維持コストはそのまま
○　引退したベテランを安く雇える
×　人間には寿命がある
○　これから仕様書を整理すれば業務ノウハウも引き継げる
×　ツギハギだらけで拡張性に乏しいシステムのままでは、ニーズの変化に迅速に対応できない

　ITベンダーの売り文句だけではなく、新しいシステムに入れ替えたいという思いが顧客サイドにもあるように感じる。若手にとってはワクワクする仕事になるだろうし、そろそろツギハギにも限界が見えてきている。

　一方のベテランはどうか。こちらは少し感傷的なようだ。ソースコードのコメントアウトに自分の名前が入っているシステムが消えるのが寂しい。しかも、それは長年お守りしてきたシステムである。私も仕事で仕方なくプログラムを作ったことがあるので、自分の書いたソースコードが動く感動を知っている。

　希望的観測は、ベテランが引退間近になって積極的に知識を残そうとすること。作って動いているシステムよりも、作るための業務知識の方に価値がある。この事実を、ベテランに理解してもらう必要があるだろう。これがうまくいかなければ、すべてが水泡に帰す。

　今回は結論まで至らなかった。とりあえずは、現行システムを残すという選択肢を提示しておく。次回は、1と2の×を消す作業によって、どちらがより良いのか考えてみたい。

＃長く更新できなくてすみませんでした。
　すでに週末に書いているので、次回は明日アップできます。