私が使用しているランニングシューズは「adidas Tempo 2 W」です。これ、実はレディースです。私のサイズは24cmなのですが、メンズだとこのサイズがないのです。
本格的なランニングシューズを履くのはこれが初めてですが、非常に軽く、アスファルトを捉える時のグリップも強く走りやすいです。
ちなみに雨の日はウォーキングのみ行いますが、この時は昔買った訳の分からない運動靴を使ってます。
2009年9月29日火曜日
Hyper-V
ラベル:
IT
私は積極的に仮想化技術を採用しています。その第1の理由はコストですが、第2の理由は扱い易さです。物理的なものは扱いに手間がかかりますが、論理的なものは扱いが楽です。いまさらいう話でもありませんが、システム管理者として30台近いサーバーと100台を超えるクライアントを日々管理する私にとっては、運用管理の手間が減少することは大変嬉しいことです。
VMに関しては、MicrosoftのVirtual PCを手始めに、昨年Virtual Serverでの運用を開始し、今年、Hyper-Vを運用するために2台のサーバーを購入しました。現在は、System Center Virtual Machine Manager 2008の評価が終わり、まもなく本運用を開始する段階です。
System Center Virtual Machine Manager 2008は、VMの利便性をさらに向上させてくれる大変有益なツールです。私が気に入っているのはVirtual Server等を統合管理できる点と、ライブラリ機能、チェックポイント機能、P2V機能です。いずれの機能も、Virtual PCで初めてVMを体験したころに比べて、仮想化技術の恩恵をより一層享受してくれるものです。
現在は構想段階ですが、我が社の情報インフラを大々的に仮想化しようという構想を練っている最中です。大きなシナリオとしては、シンクライアント システムを仮想化技術の更なる採用によりパワーアップしようというものです。これについても本ブログで紹介していきたいと思います。
VMに関しては、MicrosoftのVirtual PCを手始めに、昨年Virtual Serverでの運用を開始し、今年、Hyper-Vを運用するために2台のサーバーを購入しました。現在は、System Center Virtual Machine Manager 2008の評価が終わり、まもなく本運用を開始する段階です。
System Center Virtual Machine Manager 2008は、VMの利便性をさらに向上させてくれる大変有益なツールです。私が気に入っているのはVirtual Server等を統合管理できる点と、ライブラリ機能、チェックポイント機能、P2V機能です。いずれの機能も、Virtual PCで初めてVMを体験したころに比べて、仮想化技術の恩恵をより一層享受してくれるものです。
現在は構想段階ですが、我が社の情報インフラを大々的に仮想化しようという構想を練っている最中です。大きなシナリオとしては、シンクライアント システムを仮想化技術の更なる採用によりパワーアップしようというものです。これについても本ブログで紹介していきたいと思います。
カメラ
ラベル:
写真
私は結構多趣味ですが、カメラは17年位続いている趣味です。
この趣味に目覚めた当時、私はキヤノンの品質保証部で、光学製品の品質テストに携わっていましたので、特に迷うこともなくカメラはCanonだなぁ… と思い、Canonの EOS10 QDを手に入れました。それからずっとCanonのカメラを使い続け、2台目はEOS-1N HSというプロ機を20万強のお金を出して買いました。これはとても素晴らしいカメラで、デジタルに移行するまで10年近く使用しました。
次はデジタルになってEOS 30D。これは現在のメインカメラです。プロ機からハイ アマチュア用のカメラに移行するのは、つまらない見栄からすれば嫌だったのですが、当時プロ機のデジタル一眼レフは、確か80万円位してとても手にできるような品物ではなかったのです。しかし、3年近く使用し、現在はとても気に入っています。
一眼レフではありませんが、もっと手軽に扱えるカメラが1台欲しいと思い、去年の12月にサブ機としてPowerShot G10を買いました。これも非常にいいカメラで気に入っています。
レンズは、広角から望遠までさまざまなレンズを使ってきましたが、徐々に広角にシフトしてきました。最初の標準ズームのワイド側は35mm、これでは物足りなく28mmに買い替え、また物足りなくなり17mmに。現在はついに魚眼レンズが私の標準レンズになってしまいました。これはトキナーのAT-X107という魚眼ズームレンズです。
この趣味に目覚めた当時、私はキヤノンの品質保証部で、光学製品の品質テストに携わっていましたので、特に迷うこともなくカメラはCanonだなぁ… と思い、Canonの EOS10 QDを手に入れました。それからずっとCanonのカメラを使い続け、2台目はEOS-1N HSというプロ機を20万強のお金を出して買いました。これはとても素晴らしいカメラで、デジタルに移行するまで10年近く使用しました。
次はデジタルになってEOS 30D。これは現在のメインカメラです。プロ機からハイ アマチュア用のカメラに移行するのは、つまらない見栄からすれば嫌だったのですが、当時プロ機のデジタル一眼レフは、確か80万円位してとても手にできるような品物ではなかったのです。しかし、3年近く使用し、現在はとても気に入っています。
一眼レフではありませんが、もっと手軽に扱えるカメラが1台欲しいと思い、去年の12月にサブ機としてPowerShot G10を買いました。これも非常にいいカメラで気に入っています。
レンズは、広角から望遠までさまざまなレンズを使ってきましたが、徐々に広角にシフトしてきました。最初の標準ズームのワイド側は35mm、これでは物足りなく28mmに買い替え、また物足りなくなり17mmに。現在はついに魚眼レンズが私の標準レンズになってしまいました。これはトキナーのAT-X107という魚眼ズームレンズです。
撮り方でいろいろな映像を創り出せるところがこのレンズのとても面白いところであり、難しいところでもあります。この不思議な目で、今後もいろいろな映像を創って行きたいですね。
質と量を使い分ける時代
例えば、VMサーバー用に次のようなスペックを想定してみましょう。
私ならDELLのサーバーを選びます。でも、2台買います。2台買っても富士通より安いですから。
私がここでいいたいことは、富士通とDELLの価格差ではありません。タイトルにあるように、質と量を使い分けましょう、ということです。
この想定ではVMをホストするサーバーを考えているので、次のような考え方をすることができます。それは、
今回の例でいえば、富士通のサーバーを1台買って大事に使うよりも、DELLのサーバーを2台買い、1台はHyper-Vをインストールした状態でコールドスタンバイさせておくというのはどうでしょうか？
仮想化の時代においては、安価なハードで高価なハードに対して数で勝負する、そんな選択ができると私は考えます。
- Windows Server 2008 Standard Edition(x64)
- Xeon E5540 × 2
- メモリ32GB
- RAID1でハードディスクは450GB×2
私ならDELLのサーバーを選びます。でも、2台買います。2台買っても富士通より安いですから。
私がここでいいたいことは、富士通とDELLの価格差ではありません。タイトルにあるように、質と量を使い分けましょう、ということです。
この想定ではVMをホストするサーバーを考えているので、次のような考え方をすることができます。それは、
「VMは、VHDをバックアップしておけば簡単に復元することができる。ミッションクリティカルでないシステムなら、多少システムの停止時間が出ても業務継続性に問題はない。であるなら、VMのホストはできるだけ安いものを用意し、その代わり複数台用意することによって冗長性や可用性を高めた方が投資効果は高くなる」というものです。
今回の例でいえば、富士通のサーバーを1台買って大事に使うよりも、DELLのサーバーを2台買い、1台はHyper-Vをインストールした状態でコールドスタンバイさせておくというのはどうでしょうか？
仮想化の時代においては、安価なハードで高価なハードに対して数で勝負する、そんな選択ができると私は考えます。
2009年9月28日月曜日
仮想化技術の広まり
ラベル:
その他
日経情報ストラテジーという雑誌を購読していますが、11月号の52ページに「高額品こそネットで売る」という記事がありました。ミサワホームが戸建て住宅をネットでダイレクト販売しているという内容です。
私は方向性の似た企画を今年の初めに社に提案しましたが、我が社には早すぎるようで不作に終わりました。時期をみていずれまたチャレンジするつもりですが、先を越されたような気がして正直悔しいですね。
ビジネスはスピードです。特にアイデアは先にものにしないと大きな成果に結びつきません。一方でアイデアを形にするのは大変なことです。だからこそ、日々の積み重ねが大事なのですが、日本の多くの人々は、そのことを実感として認識していないと思うのは私だけでしょうか？ 未来への種まき、これを怠るとGMのようになってしまうのですが…
＊タイトルと内容が不一致と思われるかもしれませんが、ネットビジネスやクラウド、抽象化など、こうしたことも広義における仮想化と私は捉えています。そして、さらに先には拡張現実があると…
私は方向性の似た企画を今年の初めに社に提案しましたが、我が社には早すぎるようで不作に終わりました。時期をみていずれまたチャレンジするつもりですが、先を越されたような気がして正直悔しいですね。
ビジネスはスピードです。特にアイデアは先にものにしないと大きな成果に結びつきません。一方でアイデアを形にするのは大変なことです。だからこそ、日々の積み重ねが大事なのですが、日本の多くの人々は、そのことを実感として認識していないと思うのは私だけでしょうか？ 未来への種まき、これを怠るとGMのようになってしまうのですが…
＊タイトルと内容が不一致と思われるかもしれませんが、ネットビジネスやクラウド、抽象化など、こうしたことも広義における仮想化と私は捉えています。そして、さらに先には拡張現実があると…
2009年9月27日日曜日
マラソン大会に向けて
ラベル:
ランニング日記
昨日は割りと早くに休日出勤したので、走ることができませんでした。マラソン大会まで後1週間。今日は少し長い距離を走ろうということで、いくつかあるコースの中から8Kmコースを選びました。
練習メニューはいつも一緒です。まず家の中で10分ほどの準備運動後、最初の20分はウィーキング、それからその時の気持ちよく走れるスピードで走ります。これはどのコースを選んでも一緒で、とにかく怪我をしないように、無理をしないように、しっかりとウォーミングアップしてから走り、走り終わってからはクールダウンをしてシャワーを浴びる、こんな感じです。ちなみにランニング後の体重は52.8Kg。体もだいぶ絞れてきました。
今日はかなりいい感じで走れました。いつも白いG-SHOCKをしてタイム（運動量）を把握しながら走りますが、今日のタイムはウォーキングを含めて1時間5分19秒です。最初にこのコースを走ったのは7月11日で、その時のタイムが1時間14分17秒ですので、自分としては上々のタイムが出ました。また、このコースは長い登り坂の多いコースなのですが、最近は登りがあまり苦にならなくなってきましたので、これまでの成果としてそこそこの走力が付いてきたことを実感しています。
今週は仕事もかなりこなさなくてはなりませんので、どれほど練習できるか分りませんが、大会に向けて調整を進めていきたいと思います。
練習メニューはいつも一緒です。まず家の中で10分ほどの準備運動後、最初の20分はウィーキング、それからその時の気持ちよく走れるスピードで走ります。これはどのコースを選んでも一緒で、とにかく怪我をしないように、無理をしないように、しっかりとウォーミングアップしてから走り、走り終わってからはクールダウンをしてシャワーを浴びる、こんな感じです。ちなみにランニング後の体重は52.8Kg。体もだいぶ絞れてきました。
今日はかなりいい感じで走れました。いつも白いG-SHOCKをしてタイム（運動量）を把握しながら走りますが、今日のタイムはウォーキングを含めて1時間5分19秒です。最初にこのコースを走ったのは7月11日で、その時のタイムが1時間14分17秒ですので、自分としては上々のタイムが出ました。また、このコースは長い登り坂の多いコースなのですが、最近は登りがあまり苦にならなくなってきましたので、これまでの成果としてそこそこの走力が付いてきたことを実感しています。
今週は仕事もかなりこなさなくてはなりませんので、どれほど練習できるか分りませんが、大会に向けて調整を進めていきたいと思います。
2009年9月26日土曜日
RDRA
ラベル:
Enterprise Architect,
IT,
Open Knowledge,
RDRA,
お勧め,
研究開発,
要件開発
私は絶えずいくつかの仕事を並行して行っていますが、その内のひとつが新システムの要件開発です。この新システムでは、プロポーザル方式で複数社から提案を受けることにしていますので、要件開発に基づくRFPの作成までが主たる私の業務となります。
今回の要件開発にあたっては、リレーションシップ駆動要件分析RDRA（ラドラ、Relationship driven requirement analysis）という手法を採り入れました。これは次期基幹システムでの苦い経験を基に、上流工程のあり方を自分なりに再構築する中で、RDRAに関する書籍に出会い、感銘し、これを要件開発の核になる方法論として組み入れようと考えたからです。
これまでの知識経験とRDRAを組み合わせることにより、新たな要件開発方法論を手に入れた私は、6月からこの方法論による要件開発を進めています。進捗としては、9割弱まで開発が進んだかな、というところです。
新しい試みですので、当然試行錯誤がありますが、中でもモデリングを効率的に行うことに最も試行錯誤しています。
モデリングツールには、Enterprise Architectを使用していますが、モデルの規模が大きくなるにつれて、全体を効率よく整合させていく作業に工夫が必要になります。これは、私のツールに対する熟練度もあるでしょうが、モデルを描くディスプレイの大きさや紙の大きさなど、いくつかの制約の中でモデリングを進めるためには、私のみならず工夫がいるのではないかと考えています。
そんな試行錯誤も、いずれ紹介できればと思うのですが、要件定義に悩みを抱え、RDRAをご存じないのであれば、是非一度RDRAを勉強してみてください。
関連記事
性質変換によるデスクワークの工場化
ソフトウェアの開発プロセスについて
Open Knowledge System
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA
今回の要件開発にあたっては、リレーションシップ駆動要件分析RDRA（ラドラ、Relationship driven requirement analysis）という手法を採り入れました。これは次期基幹システムでの苦い経験を基に、上流工程のあり方を自分なりに再構築する中で、RDRAに関する書籍に出会い、感銘し、これを要件開発の核になる方法論として組み入れようと考えたからです。
これまでの知識経験とRDRAを組み合わせることにより、新たな要件開発方法論を手に入れた私は、6月からこの方法論による要件開発を進めています。進捗としては、9割弱まで開発が進んだかな、というところです。
新しい試みですので、当然試行錯誤がありますが、中でもモデリングを効率的に行うことに最も試行錯誤しています。
モデリングツールには、Enterprise Architectを使用していますが、モデルの規模が大きくなるにつれて、全体を効率よく整合させていく作業に工夫が必要になります。これは、私のツールに対する熟練度もあるでしょうが、モデルを描くディスプレイの大きさや紙の大きさなど、いくつかの制約の中でモデリングを進めるためには、私のみならず工夫がいるのではないかと考えています。
そんな試行錯誤も、いずれ紹介できればと思うのですが、要件定義に悩みを抱え、RDRAをご存じないのであれば、是非一度RDRAを勉強してみてください。
関連記事
性質変換によるデスクワークの工場化
ソフトウェアの開発プロセスについて
Open Knowledge System
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA
RXDB
次期基幹システム(2)で紹介したシステムコンセプトを、
もう少し詳しく書きたいと思います。
まずは、RXDBから…
RXDB
ビジネスで取り扱う大部分のデータは、値単独で存在するのではなく、データを格納する構造と一体を成しています。そして、値の変化を扱うことは簡単ですが、構造の変化を扱うことは非常に厄介です。私の在籍する会社は不動産業を営んでいますが、例えば、こんなデータが厄介です。
不動産（賃貸住宅など）には、交通という属性があります。これは最寄駅へのアクセスを示すものであり、具体的には「JR横浜駅徒歩5分」というようなデータです。一見簡単に扱えそうなデータですが、このデータの構造は変化します。例を挙げてみましょう。
ここで論点を明確にしますと、私は伝統的情報処理技術（RDBなど）によっていかに実装するかを論じたいのではありません。さまざまな技術を用いていかにエレガントに実装できるかを論じたいのです。つまり、このようなデータをRDBで実装すること自体は簡単です。最も単純な方法は、文字列の固まりとして記録する方法。ちょっと複雑にしてテーブルを分割する方法などが考えられますが、このような方法はメンテナンス性やデータ処理の柔軟性を失わせたり、データベースオブジェクトやアクセスロジックを複雑化させてしまったりします。これをどう回避するか？ ということを考えていきたいのです。
そこで私はXMLの処理技術に注目しています。
XMLは、多次元構造を持つデータをエレガントに表現できる手段です。より正確にいうならば、XMLにより記述できるツリーというメカニズムは、多次元なデータ構造を表現することができます。そして、多次元構造を表現できるメカニズムは、RDB（2次元）を遙かに超えるデータ構造のバリエーションを扱うことできます。
先程の交通をXMLで記述してみましょう。RDBよりスマートに表現できていませんか？
まあ、スマートとか、エレガントといったことは主観によるでしょうが、XMLは多次元、RDBは2次元である事実は明かです。ここに疑問を感じる方は、さまざまなデータ構造をXMLでモデリングしてみると、多次元の良さを実感できると思います。
また、多くのRDBMSが大きなコストによりOLAPなどのサービスを提供することに比べて、単なるプレーンテキストであるXMLは、実に安価な多次元データベースといえます。
しかし、いいことばかりではなく、メモリやプロセッサなどのリソースに関する制約との兼ね合いや、検索などのパフォーマンスに関する課題など、実装においてはいくつかの課題解決が必要となるでしょう。
以上から、私は現在の技術レベルにおいて最良の選択は、XMLを扱えるRDBMSにより、2次元と多次元の良いところをバランス良く活用するということです。
例えば、SQL Serverにおいては、構造変化の少ないデータ（硬度なデータ）に対しては通常のRDBの方法論でアプローチし、構造変化が起こるデータ（軟度なデータ）には、XML型により処理するというアプローチです。
私はこれらのことを称して、RXDB(Relational & XML Database)と呼んでいます。
もう少し詳しく書きたいと思います。
まずは、RXDBから…
RXDB
ビジネスで取り扱う大部分のデータは、値単独で存在するのではなく、データを格納する構造と一体を成しています。そして、値の変化を扱うことは簡単ですが、構造の変化を扱うことは非常に厄介です。私の在籍する会社は不動産業を営んでいますが、例えば、こんなデータが厄介です。
不動産（賃貸住宅など）には、交通という属性があります。これは最寄駅へのアクセスを示すものであり、具体的には「JR横浜駅徒歩5分」というようなデータです。一見簡単に扱えそうなデータですが、このデータの構造は変化します。例を挙げてみましょう。
- JR関内駅徒歩5分。または市営地下鉄関内駅徒歩4分。
- JR逗子駅より京急バス15分。バス停葉山大道下車徒歩3分。または京急新逗子駅からバス13分にて葉山大道まで。
ここで論点を明確にしますと、私は伝統的情報処理技術（RDBなど）によっていかに実装するかを論じたいのではありません。さまざまな技術を用いていかにエレガントに実装できるかを論じたいのです。つまり、このようなデータをRDBで実装すること自体は簡単です。最も単純な方法は、文字列の固まりとして記録する方法。ちょっと複雑にしてテーブルを分割する方法などが考えられますが、このような方法はメンテナンス性やデータ処理の柔軟性を失わせたり、データベースオブジェクトやアクセスロジックを複雑化させてしまったりします。これをどう回避するか？ ということを考えていきたいのです。
そこで私はXMLの処理技術に注目しています。
XMLは、多次元構造を持つデータをエレガントに表現できる手段です。より正確にいうならば、XMLにより記述できるツリーというメカニズムは、多次元なデータ構造を表現することができます。そして、多次元構造を表現できるメカニズムは、RDB（2次元）を遙かに超えるデータ構造のバリエーションを扱うことできます。
先程の交通をXMLで記述してみましょう。RDBよりスマートに表現できていませんか？
まあ、スマートとか、エレガントといったことは主観によるでしょうが、XMLは多次元、RDBは2次元である事実は明かです。ここに疑問を感じる方は、さまざまなデータ構造をXMLでモデリングしてみると、多次元の良さを実感できると思います。
また、多くのRDBMSが大きなコストによりOLAPなどのサービスを提供することに比べて、単なるプレーンテキストであるXMLは、実に安価な多次元データベースといえます。
しかし、いいことばかりではなく、メモリやプロセッサなどのリソースに関する制約との兼ね合いや、検索などのパフォーマンスに関する課題など、実装においてはいくつかの課題解決が必要となるでしょう。
以上から、私は現在の技術レベルにおいて最良の選択は、XMLを扱えるRDBMSにより、2次元と多次元の良いところをバランス良く活用するということです。
例えば、SQL Serverにおいては、構造変化の少ないデータ（硬度なデータ）に対しては通常のRDBの方法論でアプローチし、構造変化が起こるデータ（軟度なデータ）には、XML型により処理するというアプローチです。
私はこれらのことを称して、RXDB(Relational & XML Database)と呼んでいます。
2009年9月25日金曜日
マラソン大会
ラベル:
ランニング日記
高校生の時以来、マラソン大会などというものに何十年かぶりで参加することになりました。
ここ2年位でしょうか、お酒を飲みまくり、だらしのない生活をしたせいで、
体形がかなり崩れていたのが5月ごろです。
ちなみに、私の身長は160cm、その時の体重は56Kgですので、スペック的には普通です。
しかし、脂肪の付き方がなんともみっともない…
お腹だけがポッコリと出ている感じで、実にかっこ悪い体形なのです。
これはまずいと、6月位からウィーキングをはじめ、現在はゆっくり１時間位走れるようになりました。
仕事でかく冷や汗と違い、運動でかく汗は気持ちよく、土日は必ず走り、
平日も早く帰れた日は走っています。
速く走れるわけではありませんが、間違いなく、近年の自分と比べれば体力は改善されたと認識しています。
そして何より嬉しいのは、「痩せたね」といわれる一言です！
そんな時、友人からマラソン大会に誘われたので、参加してみようと思ったわけです。
大会は10月4日、距離は5km。
きっとビリから数えたほうが早い結果に終わるでしょうが、まずは、楽しく走ってみたいと思います。
ここ2年位でしょうか、お酒を飲みまくり、だらしのない生活をしたせいで、
体形がかなり崩れていたのが5月ごろです。
ちなみに、私の身長は160cm、その時の体重は56Kgですので、スペック的には普通です。
しかし、脂肪の付き方がなんともみっともない…
お腹だけがポッコリと出ている感じで、実にかっこ悪い体形なのです。
これはまずいと、6月位からウィーキングをはじめ、現在はゆっくり１時間位走れるようになりました。
仕事でかく冷や汗と違い、運動でかく汗は気持ちよく、土日は必ず走り、
平日も早く帰れた日は走っています。
速く走れるわけではありませんが、間違いなく、近年の自分と比べれば体力は改善されたと認識しています。
そして何より嬉しいのは、「痩せたね」といわれる一言です！
そんな時、友人からマラソン大会に誘われたので、参加してみようと思ったわけです。
大会は10月4日、距離は5km。
きっとビリから数えたほうが早い結果に終わるでしょうが、まずは、楽しく走ってみたいと思います。
次期基幹システム(2)－システム コンセプト
次期基幹システムの開発に関する紆余曲折を語る前に、
私が描いた当初のシステム コンセプトを語りたいと思います。
【データベース層】
まず自論ですが、データには硬度があるので、硬いデータにはRDBで、
軟らかいデータにはXML(Extensible Markup Language)で対応することを原則とする、というもの。
つまり、データの構造と中身が変化することが少ない「硬度なデータ」はRDBで、
変化する「軟度なデータ」に対してはXMLで対応するということです。
しかし、データベースへのアクセスは一元化したいので、
XMLを扱えるRDBMSを採用することによって、
私が考えるRXDB（Relational & XML DB）を実現しようと考えたのです。
【ビジネスロジック層】
次にビジネスロジック層ですが、これにはSOA(Service-Oriented Architecture)により、柔軟性を持ったシステム構造を実現すると共に、
BPM(Business Process Monitor)機能を実装することにより、業務の継続的改善基盤を構築しようと考えました。
いうまでもなく、業務は時間経過とともに変化しますが、システムのロジックは手を施さない限り変化しません。
絶え間ない変化を受け入れるシステム、これがこの階層のコンセプトです。
【プレゼンテーション層】
再び自論ですが、業務にはストック系とフロー系の2種類の業務があるので、
それぞれの特性に合わせたプレゼンテーション層を構築しようというのがこの階層のコンセプトです。
ストック系は、定型的な流れを持たず、さまざまな利用シーンの中で繰り返し行われる業務です。
たとえば、「商品データベースを参照する」というようなユースケースです。
フロー系は、前工程が後工程に影響を与えるという依存関係を持ったプロセスが集まった業務です。
たとえば、「契約情報に基づき商品を仕入れる」というようなユースケースです。
私はこの前提の下、ストック系には既存資産を生かした開発アプローチを、
フロー系には手組みによるアプローチをとろうと考えました。
つまり、ストック系にはExcelによるデータアクセスやSQL ServerのReporting Serviceを活用することにより、
アクセスロジックの構築や帳票開発の手間を省き、
フロー系は手組みによって、より業務にフィットしたものにしようというコンセプトです。
そして、このコンセプトの実現を追い求める中で、
いくつかの苦労を背負い込むことになるのでした…
続く…
私が描いた当初のシステム コンセプトを語りたいと思います。
【データベース層】
まず自論ですが、データには硬度があるので、硬いデータにはRDBで、
軟らかいデータにはXML(Extensible Markup Language)で対応することを原則とする、というもの。
つまり、データの構造と中身が変化することが少ない「硬度なデータ」はRDBで、
変化する「軟度なデータ」に対してはXMLで対応するということです。
しかし、データベースへのアクセスは一元化したいので、
XMLを扱えるRDBMSを採用することによって、
私が考えるRXDB（Relational & XML DB）を実現しようと考えたのです。
【ビジネスロジック層】
次にビジネスロジック層ですが、これにはSOA(Service-Oriented Architecture)により、柔軟性を持ったシステム構造を実現すると共に、
BPM(Business Process Monitor)機能を実装することにより、業務の継続的改善基盤を構築しようと考えました。
いうまでもなく、業務は時間経過とともに変化しますが、システムのロジックは手を施さない限り変化しません。
絶え間ない変化を受け入れるシステム、これがこの階層のコンセプトです。
【プレゼンテーション層】
再び自論ですが、業務にはストック系とフロー系の2種類の業務があるので、
それぞれの特性に合わせたプレゼンテーション層を構築しようというのがこの階層のコンセプトです。
ストック系は、定型的な流れを持たず、さまざまな利用シーンの中で繰り返し行われる業務です。
たとえば、「商品データベースを参照する」というようなユースケースです。
フロー系は、前工程が後工程に影響を与えるという依存関係を持ったプロセスが集まった業務です。
たとえば、「契約情報に基づき商品を仕入れる」というようなユースケースです。
私はこの前提の下、ストック系には既存資産を生かした開発アプローチを、
フロー系には手組みによるアプローチをとろうと考えました。
つまり、ストック系にはExcelによるデータアクセスやSQL ServerのReporting Serviceを活用することにより、
アクセスロジックの構築や帳票開発の手間を省き、
フロー系は手組みによって、より業務にフィットしたものにしようというコンセプトです。
そして、このコンセプトの実現を追い求める中で、
いくつかの苦労を背負い込むことになるのでした…
続く…
次期基幹システム(1)－現在、運用テスト準備中
今日は、12月から本稼働する次期基幹システムのユーザー向け操作説明会を行っています。
構想からシステムテストまで2年弱の月日を経て、
現在運用テストの準備を行っているところです。
システムの構成は、物理3階層・論理3階層のWebアプリケーションです。
DB層にはSQL Server 2005、ビジネスロジック層とプレゼンテーション層にはIIS6.0。
APS.NET 2.0とNetCOBOL for .NETにより構築されています。
現在稼働中の基幹システムは、メインフレームのシステムであり、
その基礎部分は15年ほど前に開発されたものです。
それゆえ業務の変化によるシステム改定を重ねた結果、
ひと言でいえばスパゲッティ状態に陥っています。
そこで、いわゆるレガシー マイグレーションによって、
システムを最適化すると共にコストパフォーマンスを改善し、
データの再利用性を大幅に高めようというのが、
次期基幹システムの技術的コンセプトです。
開発費は3億円。我が社としてはかなりの投資額です。
それゆえプロジェクト責任者である私の責任は大変大きなものですが、
ここまで来るには紆余曲折がありました。
続く…
構想からシステムテストまで2年弱の月日を経て、
現在運用テストの準備を行っているところです。
システムの構成は、物理3階層・論理3階層のWebアプリケーションです。
DB層にはSQL Server 2005、ビジネスロジック層とプレゼンテーション層にはIIS6.0。
APS.NET 2.0とNetCOBOL for .NETにより構築されています。
現在稼働中の基幹システムは、メインフレームのシステムであり、
その基礎部分は15年ほど前に開発されたものです。
それゆえ業務の変化によるシステム改定を重ねた結果、
ひと言でいえばスパゲッティ状態に陥っています。
そこで、いわゆるレガシー マイグレーションによって、
システムを最適化すると共にコストパフォーマンスを改善し、
データの再利用性を大幅に高めようというのが、
次期基幹システムの技術的コンセプトです。
開発費は3億円。我が社としてはかなりの投資額です。
それゆえプロジェクト責任者である私の責任は大変大きなものですが、
ここまで来るには紆余曲折がありました。
続く…
2009年9月24日木曜日
alan
ラベル:
My Music
このところ気に入っているボーカリストはalanです。
初めてalanを聴いたのは、インターネット サーフィン中に、
「懐かしい未来」のPVを見つけた時で、
以来ファンとなってカラオケでも自ら歌っています。
好きな曲は、
alanのオフィシャルサイト
alanのブログ
また、「BALLAD ～名もなき恋のうた～」がYouTubeで配信中です。
初めてalanを聴いたのは、インターネット サーフィン中に、
「懐かしい未来」のPVを見つけた時で、
以来ファンとなってカラオケでも自ら歌っています。
好きな曲は、
- 懐かしい未来
- 群青の谷
- 恵みの雨
alanのオフィシャルサイト
alanのブログ
また、「BALLAD ～名もなき恋のうた～」がYouTubeで配信中です。
Green IT
ラベル:
IT
我が社のIT機器から排出される年間のCO2を推計してみました。
年間のCO2排出量は、推計72トンです。
これは多いのか？ 少ないのか？
日本の1人あたりの年間排出量は約10トン、
日本全体では約13億トン、
世界では約273億トンです。
＊データはいくつかのサイトから調べたものですので、
統計の年度などが統一されていません。
我が社のCO2排出量は世界全体から見れば微量ですから、
CO2削減を高らかに謳うほどのものではないと考えます。
しかし、塵も積もれば山となるですから、
仮想化技術などの積極的な採用により、
CO2を少しでも減らすシステムを構築していきたいと考えます。
ちなみに、我が社が導入しているシンクライアントによるCO2の削減効果は、
年間約5トンです（同等スペックのリッチクライアントと比較）。
年間のCO2排出量は、推計72トンです。
これは多いのか？ 少ないのか？
日本の1人あたりの年間排出量は約10トン、
日本全体では約13億トン、
世界では約273億トンです。
＊データはいくつかのサイトから調べたものですので、
統計の年度などが統一されていません。
我が社のCO2排出量は世界全体から見れば微量ですから、
CO2削減を高らかに謳うほどのものではないと考えます。
しかし、塵も積もれば山となるですから、
仮想化技術などの積極的な採用により、
CO2を少しでも減らすシステムを構築していきたいと考えます。
ちなみに、我が社が導入しているシンクライアントによるCO2の削減効果は、
年間約5トンです（同等スペックのリッチクライアントと比較）。
鋼鉄神ジーグ
ラベル:
その他
先の連休は、2日程休日出勤しましたが、後は比較的のんびり過ごしました。
暇つぶしに何かネットで映画なりドラマなりを見ようかと思い、
作品タイトルを眺めていて「鋼鉄神ジーグ」が気になりました。
前作の鋼鉄ジーグがテレビ放送されていたのは確か私が小学生の頃。
懐かしい思いと、今DSiで遊んでいるスーパーロボット大戦Kにも登場するので、
まずは無料配信の第1話を見ました。
特別何がいいというわけではなかったのですが、
雰囲気というか、作風が子供時代によく見たテレビアニメ風で、
それなりに楽しく、結局13話すべてを連休中に見てしまいました。
昔のこの手の作品の主人公は実にシンプルで、
熱血とか、根性とか、そんな分かりやすいキャラクターだったような気がします。
ガンダムからでしょうか、そうしたシンプルさが薄らいできたのは？
どちらがいい、ということではありませんが、
あまり考えずに楽しむという点においては、
こうしたシンプルな登場人物による作品の方が良いように思います。
ロボットは、とにかく子供の頃から現在に至るまで、ずっと好きなものです。
まぁ、スーパーロボット大戦というゲームにはまるくらいですから…
仮想世界の好きなロボットは、
暇つぶしに何かネットで映画なりドラマなりを見ようかと思い、
作品タイトルを眺めていて「鋼鉄神ジーグ」が気になりました。
前作の鋼鉄ジーグがテレビ放送されていたのは確か私が小学生の頃。
懐かしい思いと、今DSiで遊んでいるスーパーロボット大戦Kにも登場するので、
まずは無料配信の第1話を見ました。
特別何がいいというわけではなかったのですが、
雰囲気というか、作風が子供時代によく見たテレビアニメ風で、
それなりに楽しく、結局13話すべてを連休中に見てしまいました。
昔のこの手の作品の主人公は実にシンプルで、
熱血とか、根性とか、そんな分かりやすいキャラクターだったような気がします。
ガンダムからでしょうか、そうしたシンプルさが薄らいできたのは？
どちらがいい、ということではありませんが、
あまり考えずに楽しむという点においては、
こうしたシンプルな登場人物による作品の方が良いように思います。
ロボットは、とにかく子供の頃から現在に至るまで、ずっと好きなものです。
まぁ、スーパーロボット大戦というゲームにはまるくらいですから…
仮想世界の好きなロボットは、
- ZGMF-X10A ストライクフリーダムガンダム
- AV-98 イングラム
- VF-25 メサイアバルキリー
システムの紹介
ラベル:
IT
私が管理している情報システムを概要を紹介します。
私の会社のユーザー数は約100人。
すべての従業員はFeliCaのIDカードを持ち、
これによりCitrix Presentation Serverによって構築された
シンクライアント システムにログインします。
シンクライアントには、富士通のFMV-TCシリーズを採用しています。
プリント時もIDカードで認証する仕組みを採用しています。
つまり、情報のインプットとアウトプットで認証する仕組みを採り入れている訳です。
ちなみに、印刷にはリコーのimagio Neo C455itなどを採用しています。
このシステムが本稼働したのは2006年4月です。
シンクラ+リコー個人認証キットによるこのシステムは、
当時としては最新のソリューションでした。
このシステムを導入する以前を、私は博物館と表現しています。
NECの98シリーズ、IBM PC/AT互換機が併存し、
OSはMS-DOS、Windows 3.1からWindows XP、
サーバーOSはWindows NT 4.0からWindows Server 2003まで、
アプリケーションもバラバラ、とにかくいろいろなものが混在していて、
管理の手間は尋常ではありませんでした。
そこで、Transformationと呼称する中期的なIT戦略を社に提案し、
約6ヵ月かけて一気にシンクライアント システムに移行しました。
その後、システム障害などで運用の苦労もありましたが、
コストパフォーマンスが高く、セキュリティのしっかりしたインフラが構築できたと自負しています。
私の会社のユーザー数は約100人。
すべての従業員はFeliCaのIDカードを持ち、
これによりCitrix Presentation Serverによって構築された
シンクライアント システムにログインします。
シンクライアントには、富士通のFMV-TCシリーズを採用しています。
プリント時もIDカードで認証する仕組みを採用しています。
つまり、情報のインプットとアウトプットで認証する仕組みを採り入れている訳です。
ちなみに、印刷にはリコーのimagio Neo C455itなどを採用しています。
このシステムが本稼働したのは2006年4月です。
シンクラ+リコー個人認証キットによるこのシステムは、
当時としては最新のソリューションでした。
このシステムを導入する以前を、私は博物館と表現しています。
NECの98シリーズ、IBM PC/AT互換機が併存し、
OSはMS-DOS、Windows 3.1からWindows XP、
サーバーOSはWindows NT 4.0からWindows Server 2003まで、
アプリケーションもバラバラ、とにかくいろいろなものが混在していて、
管理の手間は尋常ではありませんでした。
そこで、Transformationと呼称する中期的なIT戦略を社に提案し、
約6ヵ月かけて一気にシンクライアント システムに移行しました。
その後、システム障害などで運用の苦労もありましたが、
コストパフォーマンスが高く、セキュリティのしっかりしたインフラが構築できたと自負しています。
登録:
投稿 (Atom)