さいおす日記

インターオペラビリティに関わる技術標準

2009-04-27T15:23:00.001+09:00

「The Open Group」のSOA Japan Working Groupにて、SOAに関連する標準仕様について調査を実施。　SOAのインターオペラビリティについての検討の一環で標準仕様についての調査を開始したが、調査をし始めて非常に困難であることがわかってきた。　当初は、インターオペラビリティに関する標準仕様と、ミドルウェア・ベンダーやERPベンダーの対応状況も併せて調査する予定であったが、この調査は事実上不可能であるとの結論に至った。　それは、標準仕様の数の多さと関連する製品ベンダーの情報を全て把握することに非常に多くの時間を要する事が困難であるためである。　今回、調査した標準仕様の数は、１２０種類を超えている。　また、この中には各標準化団体間で重複している仕様や、新旧の仕様が混在しており、現時点でどの標準仕様が実用可能なのかの判断も非常に困難であった。　今回の調査から、SOA（Webサービスを含む）に関わる標準仕様は非常に多く存在しており、その中からどの標準仕様を選択して製品化または既存製品の利用をすれば良いかの判断が難しいことと痛感した。　そんな中での成果として、これらの潮流を読むには、ERPベンダーの標準仕様の採用状況がひとつの指針になる事を感じた。　SAP社、Oracle社ともに自社製品のSOA対応が進んでおり、それらの製品が採用している標準仕様は、今後も主流になる可能性が高い。　今回調査した標準仕様一覧について、現時点では公開できるレベルには無いことが残念であるが、これを０から調査するには相当な時間を要するので、是非公開できるよう努力したい。

スマートフォン

2008-10-07T17:50:00.001+09:00

BlackBerryが「BlackBerry Application Center」を立ち上げるらしい、と今朝のニュースで発見。Appleの「App Store」に対抗しての対応と思われる。スマートフォンユーザにとって利用できるソフトウェアが手軽に入手できる事は喜ばしいことである。　一方ソフトウェア開発をビジネスにしている立場から見ると、スマートフォン向けのソフトウェア開発は大きな夢を感じる。　前述のとおりネットを通して簡単に販売できるチャネルが確立しつつあるので、自社で開発したソフトウェアが世界中のユーザに利用していただける可能性があるためだ。弊社でもiPhone開発に注力しているが、早期に世界中で利用できるソフトウェアをリリースしたいと考える。　今後は、モバイル端末からクラウドのサービスを利用するのがトレンドになっていく可能性が高いが、利用可能なソフトウェアの絶対数が不足している状況なので、その領域でのソフトウェア開発の必要性を強く感じている。　

本当に統合して大丈夫？

2008-10-01T13:07:00.001+09:00

ここ数年サーバー統合が進んでいる。　スケールアウトでむやみに増加したサーバー群を管理する事が容易ではなく、運用コストも馬鹿にならないし、無駄なリソースがもったいないなど、問題が多いからだ。　そこで、統合、という動きは正しいと思う。だが、統合すれば全ての問題が解決されて皆ハッピーといくのだろうか？　多くの問題は解決されるだろうが、新たに背負い込む問題もある。　”統合＝集中”という構図では、今までは、どこかのサーバーが障害を起こしても、他のサーバーがなんとかしてくれていたはずである。　当然、統合したサーバーも冗長構成を組むなど、ＨＡ対応は必須であり、システムダウンしない対処が必要。　しかし、この集中化が厄介な面もある。　今までのスケールアウトな構成では、いい加減さを許容してくれていたのではないだろうか。　稼動するシステムのリソース計算など、”多めに用意すれば大丈夫だろう”といった感じで。だが集中したシステムでは、このいい加減さの許容が減ってくる。　ある意味メインフレームでのシステム運用に似てくると思う。　メインフレームは、”ほとんどダウンしません”とその可用性が売りであるが、本番業務で稼動しているシステムは、ダウンしないように最適化されているから可用性が高いのだ。　本番運用前のテスト稼動時の最適化前にシステムは結構ダウンする（こともある）。　安定稼動する為には、システムリソースの利用状況などを十分に試算した上で、本番業務運用に耐えうる”設計”が重要。　ＩＡサーバによる統合においても運用管理ツールやモニターリングツールなどで、最適化を図ることが可能である。よって、統合して”集中”したシステムが最適な状況にあるかどうかを見極める目が非常に重要であり、むやみに統合すると新たなリスクが発生する事を認識する必要がある。

今どきのソフトウェア開発

2008-08-13T12:48:00.000+09:00

最近、改めてソフトウェア開発のあり方を考えさせられる出来事があった。何年たっても一定人数を超えるチームでのソフトウェア開発は難しい。私自身が若いころは、重厚長大なメインフレームのオンラインシステムなどで、ウォーターフォールでソフトウェア開発を学んできた。しかし、時代とともに多様な開発方法が試され、ウォーターフォール開発の欠点を補完できることは立証されている。　私も前職では、反復開発に代表される開発プロセス・RUP（Rational Unified Process）を企業に導入する立場であり、ウォーターフォールとの違いや反復開発のメリットを企業側に説明してきた。　でも、この手法でやれば失敗はしない、といった開発方法論が存在しているわけではなく、むしろ開発手法以外の部分にソフトウェア開発の成功の鍵は潜んでいると考える。もちろん開発手法は重要な要素であるが、それだけでは駄目という意味。　少し古い話しになるが、2006年に、XPのケント・ベック氏が来日し、「Agileフォーラム2006」というイベントでトヨタ生産方式とアジャイルの関連や、ＸＰ導入の成功事例などを彼が話していた。このイベントで私も縁がありセッションを持たせていただいた。　その時に私が話した内容は、反復開発とアジャイルであり、重たいRUPプロセスをある程度軽量化し、アジャイルの要素を取り入れた開発手法が、最近の開発プロジェクトには適しているのではないか、との考えだ。　なぜ、こんな古い話しを思い出したかというと、冒頭にあるようにソフトウェア開発のあり方を考えさせられる出来事があったからだ。　これを機会に改めてソフトウェア開発のあり方を再考しようと思う。

BlackBerryの評価

2008-07-01T13:21:00.002+09:00

先月からBlackBerryの評価をしている。
スマートフォンがどの程度使えるのかを試すことが目的だ。以前、IBM製のPalmを使っていた経験があるが、その頃と今とでは、状況が大きく変わっている。　インタネットを介したサービスが豊富に存在し、PCからの利用は当たり前になっている。今回、特に興味を持って評価しているのが、Googleのサービスをスマートフォンからどの程度使えるか、である。　現在までに利用したのは、Gmail、Gmail for Google Apps、Google Map、Searchの4種類である。　いずれもBlackBerry用のクライアント・アプリケーションが用意されており、Googleのサイトから簡単にダウンロードが可能。　GmailをBlackBerryのブラウザで使ってみたが、ブラウザ経由だと、PCで使うほどユーザインターフェースがいけていない。　また、通信の回数が多いので実用面ではNGか、と思う。　しかし、クライアント・アプリケーションは、ユーザインターフェースがかなりいい。　Gmailのスレッド表示もPCのブラウザで使う感じで使える。　何よりもアプリケーションを起動すると、すぐにメールのInboxが表示されるところがいい。　電車を待っている最中にメールを確認したり、返信したりするのが、億劫ではない。　右上側の画面は、BlackBerryに各クライアント・アプリケーションをインストールした後の状態。　赤い”Ｍ”が通常のGmail（google.comドメイン）で青い”Ｍ”のアイコンが、Google AppsのGmail。　BlackBerryは、QWERTYキーボードを採用しているので、少々長い文章をタイプするのも楽チン。　しかし、電車の中で片手でタイプするのは、ちょっと厳しい。　今度はiPhoneを試してみたい。

IBM System iでのOpenSource協議会

2008-05-27T08:34:00.001+09:00

System iってご存知ですか？　AS400と言ったほうがピンッと来る方も多いかもしれませんね。最近はIBM iという名前になったそう。　さらに、このSystem i上でOSSが動作することを知っていますか？　AS400というとクローズなシステムという印象だった。しかし、現在は、各種OSSが動作できる。　System iでのOSSについて、調査したり技術について協議する会が、「OpenSource協議会System i」だ。　サイオスも参画してから1年ほど経過しているが、System iのインフラ環境に詳しくないので、明確な貢献が出来てなかった。　今回、同協議会に”Web分科会”というものを発足させて、System iプラットフォームで、JavaやAjaxなどのWeb技術を調査＆検討する事になった。　実は、サイオスの製品である「Sales Force Automation +」（営業支援ソフト）は、System iで動作している実績がある。同製品は、JavaのWebアプリ。　System iで難しいのは、動作環境が多様で、L-Per上のLinuxや、ネイティブOSなど、動作する環境で、アプリやミドルウェア対応も変わってくる。　協議会では、このあたりも調査していきたいと思う。　5月27日にサイオスにて第1回の分科会が開催される予定。
「OpenSource協議会System i」　http://i5php.jp/

The Open Group JapanにSOAワーキンググループ発足！

2008-05-19T08:21:00.000+09:00

ワールドワイドでは、The Open GroupにSOA-Working Groupがあり、活動をしているが、日本は、この活動になかなか貢献できていない現状がある。　今回、日本にSOA-Working Groupが発足され、近い将来にはワールドワイドの活動にも貢献できる事を目的としている。　SOAは、世界的には盛り上がっている情報が入ってきているが、日本では今一つ盛上り感に欠ける現状である。　しかし、日本国内でも導入事例は着々と増えてきているとの事。　なぜ事例情報が入ってこないか？　理由としては、導入企業が事例を公表することに消極的な姿勢であることがある。　中には、大規模なEAの道具として、SOA適用企業もあるらしい。　日本でのSOA発展のためにも、各企業が事例をオープンにして欲しいものである。

OSSiPediaがリニューアルした！

2008-04-28T17:12:00.002+09:00

今回のリニューアルでは、PDFドキュメントというカテゴリを追加し、の登録、閲覧が可能になった。　OSSを利用する方々は、是非活用して欲しい。　また、既にOSSを利用したシステム構築の実績がある企業の方には、事例登録にもご協力していただけると助かります。　OSSiPedia、是非ご活用を！！

OSSiPedia

EAのUMLモデル

2008-04-18T18:05:00.003+09:00

The Open Groupにて、Enterprise Architectureのモデルが作成された。
The Open Groupが提唱しているEA手法は、TOGAF（The Open Group Architecture Framework）
であるが、ドキュメントの量がかなり多い。　ドキュメントの量が多いということは、EA手法の
体系化が進んでいる事と意味しているが、全体像を掴むには少し難解である。
全体を掴むためにモデル化が必要であり、今回UMLモデルが作成されたことは喜ばしいことである。
TOGAFのモデルは、UML ProfileのひとつであるSPEM（Software Process Engineering Metamodel）を
用いて表現されている。　SPEMは、ソフトウェアプロセスを定義するためのUML Profileであり、
OMGが承認しているUML拡張用のモデリング言語である。
作成されたモデルは、以下で構成されている。　
Part I: Intro
Part II: ADM
Part III: Enterprise Continuum
Part IV: Resource Base
SPEMのモデルで、全体を捉えて詳細はTOGAFのドキュメントを活用すれば使い易いだろう。
現在モデル化されたものは、TOGAF8.1.1であり、今月Ver1.0が完成した。

またまた技術者勉強会

2008-04-06T13:44:00.000+09:00

今回は業務終了後に集まって良いコードに関する話と
DBに対するテストとCIでDBをテストする環境について勉強しあったそうだ。

我々ソースコードを書いてシステム作って保守していく
仕事をしている組織には必要な他の人にわかりやすいコードとは？等の
活発な意見交換ができたらしい。

また、DBに対するテストについても技術的な議論や
今後のツールのあるべき姿、そしてCIとして継続的にテストも
含めてやっていくには等の活発な意見交換ができたらしい。

こちらから資料はダウンロード可能になっている。

社内の技術者勉強会資料公開

2008-03-28T17:02:00.001+09:00

近日中に公開予定としていた資料を公開する。
サイオスのエンジニアの熱い思いを感じてもらえれば幸いだ。
ダウンロードはこちらから。

社内での技術者勉強会

2008-03-21T09:00:00.001+09:00

社内で自主的に勉強会が開始された。
業務後に資料を作り、休日に集まったという。

あくまでアンオフィシャルな自主的活動だが、
エンジニアたちが自分たちの意思で活動している。
我々上司たちの強制はそこには無い。

稚拙だったり、もしかしたら内容に間違いがあるかもしれない。
でも熱さだけは絶対に間違ってないはずだ。
その熱さで技術力を高めて揺るぎないものにして欲しい。

サイオスの技術者の熱い思いを知って頂きたいので、
あえて手を加えないで、このブログで公開したいと思う。

Flexについての勉強の発表、Javaのテストの発表、
開発環境についての発表、個人で作ってるビジネスロック層の
フレームワークの発表。

勉強会で作られたドキュメントは近日中に公開予定。

みんな頑張れ。我々の熱い思いで明日を創ろう。

Webアプリケーションサーバはどうなっていくのか？

2008-03-09T21:32:00.000+09:00

Webアプリケーションサーバの利用状況を見てみると、商用ではWebsphere、Weblogicの
シェアが高く、OSSではJBoss、Geronimo、Tomcatがメジャーではないだろうか。
特にTomcatの実用事例は多く、弊社のOSSサポートでも、多くのサポートを対応している。
近年の商用Webアプリケーションサーバの動向をみていると、SOAやBPMなどの
より付加価値の高いプロダクト開発に開発リソースを割いて、製品競争力を高める方向性
にあるように思える。　
コアのJ2EEに関しては、OSSのプロダクトも遜色ないレベルに来ている事もあり、
メーカー各社が、”枯れた技術”に注力しなくなったとも言えるのではにないか。
実際、JBossをはじめとするOSSのWebアプリケーションサーバのコア機能は、商用製品に
追いつくレベルにあると思える。　
さらに、ESB,BPMなどのミドルウェアも着々と実装されており、実用のレベルに近づいている。
ユーザ企業からすれば、選択肢が増えることは喜ばしいことであるが、商用・OSSを問わず、
これから実装されていく機能の仕様については、是非統一された仕様を実装して欲しい。
これが実現できないと、ダメージを受けるのは利用者であるユーザ企業だからである。

ソフトウェアのテストの話

2008-02-28T13:21:00.002+09:00

Junit Factoryをご存知でしょか？

コードを送ったら、テスト（コード）が返ってくる！　素晴らしい。
Junit Factoryは、米国AgitarSoftware社が運営している、テスト生成サービスの
Webサイトだ。

Junitを使って単体テストを実施しているデベロッパーは多くいると思うが、
新規の実装をしている時は、テストコード実装は苦にならないけど、
既存のソースに対して、ひたすらテストコードを実装していく作業は
結構つらいもの。　
このような場合に、Junit Factoryは便利ですね。

テスト生成の速度も結構速い。
Tomcatのテスト生成した場合で1時間強で終わるそうです。
（↑人から聞いた情報です）

Junit Factory、一度お試しする価値がありますよ。

http://www.junitfactory.com/

訂正します

2008-02-20T16:52:00.000+09:00

2/20の記事に誤りがありますので訂正いたします。

誤）　サオオステクノロジー
正）　サイオステクノロジー

自分会社名を誤ってはいけませんね。
失礼をいたしました。

ソフトウェア基盤と開発プロセス

2008-02-20T14:48:00.000+09:00

サオオステクノロジーは、創業してから今年5月で11年になる。
創業以来Webアプリケーションに関わる開発をしてきている。
当初は、Webアプリケーションを開発する基盤（フレームワーク）が
存在しておらず、自社でWebアプリケーション・フレームワークを開発し
開発の生産性と品質の向上を実現してきた。
また、フレームワークを適用して効率的に開発するための開発プロセスも
併せて検討してきた。
しかし、創業から11年経とうとしている今、新たな開発基盤や開発プロセス
開発への取組みを迫られている。
技術も進化し、アプリケーションの稼動環境が変化する中、当然リニューアル
すべきと考え、取組みを開始している。

技術進化として大きなインパクトがあるのは、Web環境でのリッチクライアントだろう。
稼動環境の変化としては、SaaSなどのサービス提供がある。
前者は、より高いユーザビリティをWebブラウザで実現することであり、FLEXなど技術。
後者は、より多くの利用者の同時接続に耐えうる軽量なWebアプリケーション・
アーキテクチャが必須となる。

取り込むべき技術は上記のみではないが、新たな世代のソフトウェア基盤を
開発する必要性を強く感じる。
ソフトウェア基盤が変化すれば、開発プロセスにも影響を少なからず及ぼす。
また、より高い品質を確保するためにも、開発プロセスの整備が重要である。
テストの自動化およびTestFastの考え方や、強力なソフトウェア構成管理
の採用をする方向だ。

取組みの経過は、公開できる範囲で書き込んでいきたい。

最近、開発プロセスそのもの管理にも興味がある。
今回の取組みでEPFも試してみたい。

EPF関連記事
http://japan.internet.com/column/webtech/20070628/6.html
http://japan.internet.com/column/webtech/20070726/6.html

Enterprise Architecture Practitioners Conference San Franciscoに参加

2008-02-07T23:42:00.000+09:00

1/28-1/30にサンフランシスコで行われた、The Open Groupのカンファレンスに参加した。

場所は、サンフランシスコで1,2位を争う、Fairmont Hotel！

普通は、ちょっと泊まれないホテルに滞在し、感激。

カンファレンスの概要を紹介しよう。

今回のメインテーマは、

「①SOA」、「②TOGAF＆SOA」、「③EA Management＆Governance」の

3つのトラックでセッションが構成される（すべて3日間）。　

① はSOAをPractice中心にITベンダー、エンドユーザがセッションを実施。　

③は、経営層に近いテーマでEAにおける管理、ガバナンスを中心に実施。　

②は、①と②の中間的な位置づけで、SOAを適用した場合に、同のようにTOGAFを推進して

EAを成立させるかがテーマである。　

私は、②を3日間に渡り受講。

メインセッションの全体感としては、SOA１色であり、海外ではSOAをかなり本格的に導入し始めている事を認識。

SOAを推進する中で、EAは欠く事のできない概念であり、実際に企業レベルでのサービス化を図ろうとすると、

TOGAFのような標準のフレームワークなしでは、まとめ切れないと感じた。　

ただし、TOGAFも標準のフレームワークには、SOA対応の概念は含まれていないので、

標準プロセスのどの部分にSOAのためのアクティビティを追加すべきか等のポイントはセッションから理解ができた。

The Open Groupで、SOAをEAについての真剣な取り組みが論じられていることから、世界的には、

本来のSOAが意味するところ（Enterpriseレベルのサービス連携）を実践するフェーズに入っているようである。　

しかし、日本では、本格的な事例もまだ少なく２００８年以降に導入が促進されていくのか、と思われる。

本格導入が始まると、EAの概念をうまく取り入れたアプローチでないとSOA化に失敗する事例も増えてくると見られる。

どうなる日本のSOA！

BTS/ITS使ってますか？

2008-01-31T10:02:00.000+09:00

バグの管理にBTS（Bug Tracking System）というジャンルの
システムを使用する事が昨今当たり前になってきている。

影舞、Mantis、Bugzilla、Scarab、Trac、redMine...
と言ったようなオープンソースのBTSが存在する。

最近はBugを管理していくというよりは範囲を広げて
ITS（Issue Tracking System）という事で物事の状態を
管理するということで使われる事になってきている。

弊社でも、プロジェクトによって採用するBTS/ITSの
OSSプロダクトはまちまちで採用し、正直統合されてこなかった。

AというプロジェクトはBugzilla、
BというプロジェクトはTracというように。

ここのところ、弊社のシステム・インテグレーション部隊の
Webソリューション部では、ある技術リーダーを中心に改善活動の一環として
BTS/ITSの統合に取り組みはじめた。

All in Oneで比較的基本機能で使えるredMineと
かゆいところに手が届きPlug-inが豊富でカスタマイズして
使い込んでいくTracとの比較を進めている。

BTS/ITSに慣れてないパートナーさんとの協業時に
実際に使ってもらって比較的わかりやすいという
声が出ているredMineをこの技術リーダーは押しているようだ。

でも色々出来るTracも好きなんですよ。と楽しそうに悩みながら。。。

まだExcelで管理していて興味を持った方は
BTS/ITSというものを試してみたらどうだろうか？

プロジェクト管理について

2008-01-21T11:14:00.000+09:00

十数年、ソフトウェア開発のプロジェクト管理を経験してきたが、
過去に失敗したプロジェクトがいくつかある。　
私にとってプロジェクト管理として重要なポイントは、ＱＣＤを
守る事だと考えている。
この事を、ベテランＰＭと話しをすると、”今更何を言っているの”という
反応を示す人がいるが、この基本的な事が結構難しいと私は思う。

Ｑ：品質
Ｃ：コスト
Ｄ：納品（納期）
この３つを厳守すればいい訳だが、この３つは互いに矛盾している部分がある。　
だから難しいのだと思う。
品質を確保するためにテストに時間をかけるとコストオーバー、納期厳守に
支障をきたす。
コスト削減、納期厳守重視で進めると品質が確保できない。
これは、多くの開発現場が抱えている問題ではないだろうか。
ＱＣＤを守る事は、プロジェクト管理だけで解決できる問題ではないが、
プロジェクト管理者の手腕によって大きく左右されることは間違えない。
効率的な開発＆テスト作業により、確かな品質を確保し、その効果で
納期を厳守でき、コストも予算内に収めることができる。
そんなプロジェクトが理想ではないだろうか。

このような背景から、サイオスでは、プロジェクト管理者の手助けをするツールして、
「ProjectKeeper」を開発している。

http://www.sios.com/product/ProjectKeeperPro/index.html
http://japan.zdnet.com/oss/story/0,3800075264,20365223,00.htm

「ProjectKeeper」はWebベースのMS-Projectライクなプロジェクト管理ツールである。
このツールで、難しいプロジェクト管理の手間を、少しでも軽減できることを
狙っている。　
プロジェクト管理で重要となる、作業（タスク）、要員、スケジュール、進捗状況、
工数予算／実績、コミュニケーションについての管理が可能で、その情報は容易に
プロジェクトメンバーで共有できる。
プロジェクト管理を成功させる上では、プロジェクト管理ツールが重要であるわけではない。
正しいプロジェクト管理の知識や経験が一番重要である事は言うまでもない。
しかし、プロジェクト管理者の作業を助けるツールは必要である。

ＰＭＢＯＫにおいても、管理すべき項目を知識エリアとして定義しており、
円滑にプロジェクト管理を実施するためのナレッジを提供している。
＜PMBOK知識エリア＞
・スコープ管理
・スケジュール管理
・コスト管理
・品質管理
・組織・要員管理
・コミュニケーション管理
・リスク管理
・調達管理

「ProjectKeeper」も今後はこれらの知識をエリアを意識した上で、機能追加を
していき、より便利なプロジェクト管理ソフトウェアとして成長させたい。

あけましておめでとうございます。

2008-01-08T12:04:00.000+09:00

2008年は昨日が営業初日で、例年どおり神田明神に行き、今年1年、よいビジネスができる様、
祈願してきました。
今年ですが、日本経済の減速感から、企業のIT投資は厳しくなってきそうですね。
企業経営とITの融合はいっそう深まる傾向にあるようですが、IT投資に対する評価は
各企業とも厳しくなるでしょう。
そんな中でも、コンプライアンス強化やナレッジワーカーのための情報共有などと
ITに求められる課題も多い状況にあります。
技術的な面でみると、昨年注目を集めた、エンタープライズ2.0、SOAなどが具体的な
事例として取り上げられ、特にSOAの企業での事例が2008年は加速するのでは
ないかと予想されます。
上記以外にも、仮想化やBCPも注目されるキーワードとなるでしょう。

と、評論家のような事を取りとめもなく書いてしまいましたが、
当社も2008年は、新しい技術にチャレンジしながら、お客様に喜んでいただける
製品やサービスを提供できるように引き続き努力していきたいと思います。

このブログも2008年は、もう少し深い技術に関する情報を書いていきたいと
考えておりますので、今年も引き続きよろしくお願いいたします。

The Open Groupでの活動

2007-12-16T14:47:00.000+09:00

当社は、The Open Groupのメンバーとして活動をしている。
The Open Groupには、下記のForumがありそれぞれが活発な活動をしている。
【Forum List】
・Architecture
・Enterprise Management
・Identity Management
・Platform
・Real-Time & Embedded Systems
・Security
当社は、Architecture Forumに参加している。
現在の大きな活動としては、先日リリースされた、TOGAF 8.1.1のドキュメント
レビューである。　
TOGAFは、EA（Enterprise Architecture）のガイドライン（方法論）であり、
世界中の多くの企業が採用している。
EAの方法論は、以前からDODAFなどいくかのものが存在しているが、TOGAFは
よりオープンな思想の元に多くの参加企業の意見を集約したガイドラインであり
その為に、多くの企業に受け入れられるものとなっている。
また、EAのみならず、付帯する様々なガイドラインとの関係についても積極的に
取り入れる姿勢がある。　たとえば、ITガバナンスのCOBITや運用基準のITILなど
がそうである。　EAやCOBITなどは比較的大きな話し（より抽象的）であるが、
そのような大きな話しだけではなく、より開発寄りの標準との関係強化にも活動を
している。　OMGとの連携についても積極的に行っており、TOGAFとMDA、RUPの
協調について調べているワーキンググループも存在している。
これらは、企業レベルのアーキテクチャをいかに効率よくソフトウェアシステムの
構築にいくかというテーマであり、今後の成果が興味深い分野である。
我々もさらに貢献できるよう前向き取り組んでいく予定。

「2007 CRMベストプラクティス賞」表彰式へ参加

2007-11-22T16:51:00.000+09:00

11月20日（水）に「2007 CRMベストプラクティス賞」表彰式に参加した。
本イベントは、CRM協議会（藤枝純教理事長）が主催しており、
顧客中心経営（CRM)で優れた実績を挙げた企業を表彰するものである。
当社も今年から理事会員として参加し、活動を支援している。
今回、13の企業および団体がベストプラクティス賞として表彰をされ、
当日は、受賞者全員の事例についてのプレゼンを聞くことができた。

各社の事例を聞いて感じた事は、各社が非常に真剣にCRMに取り組んでおり
各社毎（業種）によって、その取り組みも異なるということである。
いずれも、その根底には、”顧客中心”の取組みに苦労をしており、
私たちも、ソフトウェアを提供する立場から考えさせられる事も多かった。

顧客と企業経営の接点はどうあるべきか、また、その為にはどのような
マーケティング戦略が必要なのか、これらをクリアするためのITを
どう最適化すべきかが、大きなテーマである。
今後もCRM協議会を通じて学ぶべき事が多いと感じた一日であった。

CRM協議会：http://crma-j.org/