日本ＩＢＭが１０００人削減－問題はやめた人がどこへ行くかだ・・

ここのニュース
1000人規模の人員削減へ＝正規雇用にもリストラの波－日本IBM
http://headlines.yahoo.co.jp/hl?a=20081125-00000210-jij-bus_all

問題は、このやめた人たちが、どこへ行くかだ・・・

ほかの会社って言ったって、ほかの会社もリストラしてるわけだし・・・

ま、ＩＢＭに勤めていたような人は、人生勝ち組、お金いっぱい持ってるから・・・

会社でも、経営してやる？
でも、お客さんも、不況で仕事を出せないだろうし・・・

やっぱ、ここは、その有り余る財産を使って、デイトレーディングでもしていただくと、株式市場も活況になって、株価上がる？？

Ｐ．Ｓ　でもね、仮に会社やったとしても、勝ち組みなんだろうな・・・
　って話は、今度また書きますね

SaaS＋運用を販売となると・・・

　で、さっきの話。

　ＳａａＳのＣＲＭソフトなどは、形式的な共通化、つまり、どんな業務でも、オブジェクトを作って載せられますよ、だけど、ユーザーインターフェースとか、オブジェクトの実装の仕方は、共通化しましょうね！という形になっている／なっていくように思われる。

---

　でもそうなると、どんな業務でも載せられる反面、その業務を、ＳａａＳ上に実装するには、だれかがオブジェクトを作ってカスタマイズしなきゃいけなくなる（プログラムを作るほどではないけれど・・・）

　さらに、ＳａａＳ＋カスタマイズ、カスタマイズした部分の教育が必要になってくる。教育が多く必要なら、めんどっちいから、運用までしてよ・・・っていうことになって、ＳａａＳのサービスだけでなく、そのサービスを使う運用までアウトソーシングになってくるかもしれない。

---

　しかし、ここで問題になってくるのは、ＳａａＳ＋運用にした場合、中小だと、誰が売りに行くのか？という話。

　すぐに思いつくのは、内田洋行、大塚商会などなど・・だけど、

　そーいうところは、むしろ、ハード売り、ＳａａＳまでは売ったとしても、運用を販売するかどうかまでは。。。？？

---

　なぜ？かというと、利益構造が違うから。

　たしかに、運用は安定した収入が入ってくるんだけど、人をアサインしないといけない。

　そして、運用契約解除された場合、その人は解雇・・・といけばいいけど、正社員だと、そうやすやすと解雇できない。一方、人は、どれくらい必要かがはっきりしない。

---

　ということで、内田洋行、大塚商会などなどが、ＳａａＳはまだしも、その運用までを販売するみたいなことがあるのか？その場合、自社で人を抱えるのか、エコシステムをつくって、中小運用会社と連携して販売するのか？なーんていうことは、まだ見えてこない。

　しかし、形式的な共通化としてのＳａａＳ・ＡＳＰを考えた場合、そういうビジネスも可能になってくるっていうところが、ビジネス的に、面白いところ・・・

Ｐ．Ｓ「中小運用会社と連携して」って、そんな、中小のＳＩさん、ソフトハウスが急に増えるのか？ってはなしは、また今度。

ＳｕｇａｒＣＲＭは、５．０で意味的共通化から形式的共通化に変わり、利用範囲が広がった

　このまえの、意味的共通化と形式的共通化の話だけど、

　SaaS・ＡＳＰなどの場合、オブジェクトと属性を自分が作れるかどうかで、話が変わってくる。

　オブジェクトを生成できないと、かりに属性がいじれても（追加、削除できても）、事物の関係は、そのオブジェクトに拘束されてしまう。なので、そのオブジェクトを利用するストーリー（業務）しか展開できず、新たなオブジェクトを作成しないとできないような業務は利用できない。

　したがって、オブジェクトを生成できない場合のＳａａＳ・ＡＳＰなどは、意味的な共通化をして、ＳａａＳ・ＡＳＰが提供するストーリーにあっていないと利用できない。

---

　一方、オブジェクトが作れる場合、自分たちの業務に合わせて、オブジェクトを作成し、そのオブジェクト間の関連を引き、属性を設定できる。つまり、この場合、表示方法など、形式的な共通化をしているに過ぎず、自分たちの業務、ストーリーに合わせて、オブジェクトを作って作成できる。

---

　ＳｕｇａｒＣＲＭの場合、５．０までは、オブジェクト（Ｓｕｇａｒの場合はモジュール）を作成するには、自分でプログラムを書くしかなかった。なので、画面操作だけでやる場合は、意味的共通化のレベルだった。となると、Ｓｕｇａｒの体系（つまり、リード→取引先と発展していくような関係）に沿った業務でしか利用できず、それ以外で利用しようとすると、大幅なカスタマイズを必要とした。

　ＳｕｇａｒＣＲＭの５．０になって、モジュールビルダーが登場し、自分たちでオブジェクトを作れるようになったので、業務に沿ったオブジェクト（モジュール）を作成し、属性を設定することが出来るようになった（Ｓｕｇａｒの体系がいやなら、全部それを隠してしまって、自分たちのモジュールだけを表示するのも可能だし）。

　表示方法などは統一されるため、形式的な共通化となるが、業務的な共通化の束縛からは解放されたため、利用範囲が広がったといえる。

---

　ただし、意味的共通化から形式的共通化になると、ちょっとした困ったことがあり、そこが商機につながるわけだが、それについては、また今度。

C#で、階層構造を表示したいときに。。。

目の前にある紙を処分したいので、元ネタのＵＲＬをメモメモ

C#で、階層構造を表示したいときには、TreeViewコントロールを使うと思う。

このとき、項目を追加するには、
TreeViewコントロールへ項目を追加するには？
http://www.atmarkit.co.jp/fdotnet/dotnettips/259treeviewadd/treeviewadd.html

ノードが選択されたとき、イメージを切り替えるには
06.ノードの選択/非選択時にイメージを切り替える
http://hiros-dot.net/CS2005/Control/TreeView/TreeView06.htm

さらにそこから、ＤＬＬを呼び出したいとき
Win32 APIやDLL関数を呼び出すには？
http://www.atmarkit.co.jp/fdotnet/dotnettips/024w32api/w32api.html

ついでにＣ＃とは、関係ないけど・・・
二村射影について
MyC言語からOCamlへの「コンパイラ」
http://itpro.nikkeibp.co.jp/article/COLUMN/20070410/267632/?P=2
これだけで、何をやりたいか、気づいたあなたはすごい！