2014年4月4日金曜日

AIIM Conference 2014 に行ってきました

AIIM Conference 2014 - About the Event


 


またもや長い間放置してしまいました。復活したての弊社社長Blogにも激励が寄せられ、本人の腰が引け始めた感がありますので、私が逃げ道になるわけにもいかないという事情もあって久々の更新です。


行ってきました、というタイトルにしましたが、実はまだ米国に滞在中です。今回もJIIMA ECM委員として派遣されていますので、帰国後に月間IMへのリポート掲載と、AIIMのイベントでの講演を予定しています。詳しい話はまたそこで改めてさせて頂く予定です。


今回の会場はフロリダ州オーランドです。同じくフロリダ州のタンパで行われた新人研修、数年前のAlfresco社のパートナーイベント、結婚十周年旅行、に続いて4回目の訪問になります。英語に自信が無く不安そうな私に声をかけてくださる皆さんが「米国は初めて?」と聞いてくるのが心苦しくてなりません。


前回のAIIM Conference 2013ではソーシャルやモバイルなどの今風なテクノロジの導入による(企業内の)情報爆発というのが1つのテーマでしたが、今回もその路線が踏襲されているという印象です。ただ、情報爆発という言葉ではなくInformation Chaosという表現に集約し、その対応策の1つとしてInformation Governanceというキーワードを推している様に感じました。他にも、ここ数年で経営学(?)界隈で目にするようになったResilienceという言葉も出てきましたし、Data Guardianなんていう言い回しも複数の発表のタイトルに含まれているなど、細かい差違もありますが、基本となるテーマはInformation Governanceと考えて良さそうでした。


では、Information Governanceとはなんなのか(とりあえず次からはカタカナでインフォメーションガバナンスと書くことにします)、というのは発表者によって定義にもぶれがあった気がするのでもう少し時間をかけて考えをまとめたいところではあるんですが、今ざっとわかっているところを書き散らしておきます。


まず、この用語、インフォメーションガバナンスというのはそれほど新しいものであはりません。日本語では情報統治、という訳語で、情報セキュリティの文脈から情報の活用を推進する上でより広範囲のガバナンスの必要性が訴えられた時に用いられた用語です。そういう意味では10年近い歴史がある考え方になります。ただ、その時点ではあまりコンテンツ管理と結びつけて語られることはありませんでした。


今回の発表の構成は、この概念にECM及びレコードマネジメントの業界から再び光をあてようとしている、という事だと思います。


レコードマネジメントではレコード(記録)の識別という考え方があります。まず、その組織にとって「記録」と見なすべき情報がどんなものであるかを定義し、その条件に当てはまるものを「記録」として管理していく、という流れになります。昨今のビジネス(及びIT)の環境の変化は、この流れを維持できないものにしている、というのが、情報爆発改め情報カオス問題なわけです。記録の定義を杓子定規に捉えると重要な情報を無視することになってしまいますし、逆に理想的に考えると対象が増えすぎて管理体制が追いつかなくなります。そこで、文書でもコンテンツでも記録でもなく、広く「情報」を対象としつつこれまでと同様の「管理」ではなく新しい考え方を導入する余地を残したガバナンス、の組合せこそが今後進むべき道であると考えられているのではないでしょうか。


実際の施策としてはポリシーを定義して各情報リソースをチェックしていく、というそれほど目新しさを感じない作りになっていそうです。そこにどれだけ機械的な分析をかませるかはまだ今後の課題であるように感じました。(技術的な課題というよりは、どこまでそういったものに頼ってもよいか、という態度の問題が主な課題だと思いますが)。すでに幾つか製品はでていますし、そういったものの中にはCMISドライバもあるので、弊社のNemakiWareをそうした文脈の中で導入してもらう線もあるかもしれません。その意味でももう少し掘り下げて見たいテーマであると言えそうです。



(文責 Ishii Akinori IT-Coordinator)



2013年11月4日月曜日

そして、自社セミナもやります

イベント情報 | お知らせ | aegif: "弊社が中心となり開発を進めているOSS(CmisSync, NemakiWare)の機能や活用方法、最新情報をご紹介いたします。また、両製品に共通するトピックであるCMIS規格の概要や動向についても、これまでオープンソースECMを扱ってきた弊社視点でご紹介させていただきます。ぜひ皆様のIT投資への一助としてご活用ください。 "





前回の投稿に続きセミナ関係です。



今月19日じ弊社主催のセミナを行います。これまで取り扱ってきているLiferayやAlfrescoの新しい活用方法ですとか、自社製品CmisSyncやNemakiwareについてのご紹介をさせて頂く予定です。



前回の投稿でご紹介したCMISがどんな規格かというような話も冒頭で少しご説明させて頂く予定です。



しかし、私自身が細かく決めているわけではないのですが、こういう企画というのは本当に難しいですね。ご紹介したいお話はたくさんあるのですが、なかなか絞りきれません。



どの分野でも同じかもしれませんが、とりあえず来て頂いて休憩時間などでお話するか、ご挨拶だけさせて頂いて後日詳しい説明をしに伺うか、というところで具体的に見えてくるものがあるのが実情だと思います。とすると、極論登壇時のテーマは何でもよい、もしくは見た目にキャッチーなテーマであるほど良い、ということになりそうですが、そこまで割り切って進められる程講演テクニックに自信がもてるわけでもないですし…



(文責 Ishii Akinori IT-Coordinator)




2013年11月1日金曜日

ECMサミットで登壇させて頂きました

第10回 JIIMA ECM研究会のご案内: "ECM標準規格CMISの応用事例
��MIS規格を利用した自社製オープンソースソフトウェアである同期ツールCmisSyncと軽量リポジトリNemakiWareを題材に、この規格の成り立ちから各社製品サービスの対応状況などについても幅広く解説いたします。"



(Via ECMポータル.)



もう3週間も前のことになって完全に時節を外した感がありますが、ご報告です。それを言ってしまうと、Blog自体の放置期間はもっと長いんですが...



ECMサミットは私も参加しているJIIMA ECM委員会が主催しているシリーズセミナーで、IBMさんEMCさんをはじめいわゆるECM大手ベンダが一堂に会してプレゼンを行うという、ある種呉越同舟とも言える特徴的なイベントです。これまでのところ年2回のペースで行われていて、そのうち1回はJIIMAの展示会イベントであるeドキュメントJAPANのセミナー枠で開催されています。今回もそのeドキュメントJAPAN内の開催でした。



今回のECMサミットは、主要ベンダーが語るECMの最前線~入力からクラウドまで、コンテンツ管理の新潮流という恐ろしいタイトルで、果たして我々が主要ベンダなのかという大きな疑問も抱えつつお話をさせて頂くこととなりました。(実際には、これまであまりECM委員会では取り上げてこなかった、しかしトランザクショナル系のECMソリューションでは極めて重要な要素であるCaptureの部分、の製品紹介に重点が置かれていたので、私の所は言ってみればおまけみたいなものでしたが)



半分はECM委員の一人として、CMISの規格の概要を紹介しました。ECMポータルでも近いうちに資料のダウンロードが可能になると思いますが、要点としてはODMAとかJCRなど過去に普及に失敗した規格と違ってCMISは実際に活用されはじめていますよ、というようなお話をさせて頂きました。で、最後に弊社のCmisSyncとNemakiWareも具体例として概要を少しだけお話させて頂きました。



時間の都合もあって自社製品についてはほぼ口頭で説明するだけになってしまったのが残念でした。シンプルな製品なので少しでも感心を持って頂ければ後はいくらでも詳しい説明をしに伺うのですが…



ECM委員会のイベントはNo Showが少なく、真面目にアンケート回答を返して下さる方が多いのが特徴と言われていまして、今回も色々とフィードバックを頂きました。最後に出て来て国内では無名に近い「規格」の話しを駆け足ですることになってしまったので、用語説明等が不十分であったというご指摘を頂きました。確かに、「リポジトリ」という語を説明なしで使うのは、ビジネス系のイベントでは不適切だったかもしれません。これは以後気をつけたいと思います。



と思っていたところで、以前Alfrescoのトレーニングでご一緒したことがあるイタリアのPiergiorgio Lucidi氏が興味深い資料をslideshareにあげていたのを見つけました。個人的にはこの資料の一番面白いところは、彼がECMリポジトリのデータモデルが本来的にグラフ構造を持っていることだと考えているらしい点なんですが、今回の私の反省と関係するのは5ページ目の「What is a repository?」(リポジトリとは何か?)です。技術者向けのイベントで使い、slideshareにあげられるような海外の資料であっても、気を遣ってちゃんと定義・説明をするものなんですね、と。反省です。



(文責 Ishii Akinori IT-Coordinator)




2013年7月3日水曜日

ケースマネジメントの規格 CMMN

CMMN: "Case Management Model And Notation (CMMN)


'In Process' Version Of CMMN"



ケースマネジメントが話題にでることが多くなってきたように感じます。ECMの仕事をしているからであって、非常に狭い世界での動きなのは間違いないですが、おそらくECMやBPMの仕事をしている人は多かれ少なかれ意識はしてるのではないかと思います。



ということで、BPMNを策定しているOMGがケースマネジメントについての規格もまとめています。今年の1月にアップデートされたのでそこですぐにご紹介できれば良かったんですが、不勉強とものぐさが祟って今日まで果たせませんでした。



Oracle、SAPをはじめSaaSモデルでBPMを展開しているCordys社なんかも策定に参加しているみたいですね。逆にいうと、ECM専門ベンダの参加はないようなんですが、関連企業という意味ではKofax社が名を連ねています。この辺りは規格の内容というか性質にも影響を及ぼしているように見えますが、細かい話しはおいおいということにしたいと思います。



ひとまず、背景、と銘打たれた項目だけ簡易訳を載せておきます。厳密に訳しているわけではないのであくまで参考情報として扱って下さい。






4.1 Background 背景



この規格では、ケースのモデルとグラフィカルな表現の仕方、および異なるツール間でのケースモデルの交換を実現するための、メタデータモデルと記述方法を定義する。既存のケースマネジメント製品の共通点を抽出し、BPM製品におけるBPMNと同様のものを提供することを意図している。



BPMNは、事前に定義され、完全に特定された、反復可能なビジネスプロセスに対して良く適合している。



しかし、事前に定義することが難しく、それほど反復されないプロレスについてのモデル化が必要という議論が以前よりなされている。特にナレッジワーカが特定の文脈下で行うアドホックな意思決定や、ビジネスの環境が激しく変化する環境においてその必要性が指摘されてきた。(Thinking for a Living.やCase Handlingを参照)



ケースマネジメントは政府による許認可のプロセス、保険の申込と請求のプロセス、ヘルスケア分野における診断や患者のケア、住宅ローンの審査、コールセンターの問題解決、営業活動のプランニング、請求書の不一致の処理、機械設備の保守、受託生産のエンジニアリング、などの多様な分野で実際に利用されている。






ビジネスプロセスではなく、ケースのあり方を定式化された手法で記述し、ツール間で相互利用可能にする、ということですね。では、ビジネスプロセスの図とケースの図では何がどう変わってくるのか、というのは、あまり直感的な話ではないので、少しずつ具体例を示しながら紹介できると良さそうですね。現在営業用の資料なども用意しているところなので、でき次第支障がないところをSlideshareなどにあげつつご紹介したいと思います。



(文責 Ishii Akinori IT-Coordinator)




2013年6月25日火曜日

プレゼンスについて

Alfresco社としては弊社とのパートナーシップは黒歴史と化してしまったようですね・・・



弊社もかつては日本の独立企業としてトレーニングパートナーの契約をしてプレスリリースも打っていた経緯がありますが、確かに今ではパートナーシップを解消してしまっているので、プレスリリースを書く人の立場にたって考えると色々難しい気もしますね。まあ、「数年前にトレーニングがなくて困りました」なんてことを言われてしまうと、Alfresco自体の初期バージョンリリースから弊社とのパートナーシップ締結および最初のトレーニングの実施まで1年半もかかっていないと思うので、こういうところに愚痴めいたポストもしたくもなりますけども。(リンクを貼ったプレスリリースはトレーニングパートナーの契約時点の話でお客様に対するトレーニング等はもっと以前からやっていたという経緯もあります)



しかし、結局の所は自社のプレゼンス、情報発信力が十分でなかった故の行き違いであることは、間違いないですよね。



弊社のビジネスはAlfrescoにしてもLiferayにしても、リスク過大評価気味の日本市場において優れたOSS製品を提供している企業と早期にパートナーシップを確立することに依存してきたので、それらの優れた製品の力によってマーケティング的な面で有利な仕事をさせてもらってきたという認識があります。優れた製品、OSSというコンセプトという組み合わせは、理解の深いお客様との接点を作ってくれた要素の一つでもあります。そういう意味では今後自社製品の展開などを含めると、会社としての情報発信力をより強化していかないといけないわけですが、折角なので何か毛色のかわったことをやりたいですよね。今のところ個人的に満足してる施策は、クリンゴン語のランゲージパックぐらいなものなのですが、今後もそれに近い仕掛けを考えていきたいです。



(なんとなく如何にもWebマーケティングの営業がかかってきそうなことを書いてしまいましたが、マーケティング部門は粛々とちゃんとした仕事をしていて、プレスリリースやセミナー、ショーへの出展なども定常的にはやっていて特にそこに不足を感じているわけではないです。ちゃんとしたこと、以上のことをやれたらいいですね、というお話です。)



(文責 Ishii Akinori IT-Coordinator)




2013年6月20日木曜日

BROコラムに記事が掲載されました

BROコラム|知識0でも大丈夫!OSS導入のコスト面でのメリットを解説! ―IT投資施策決定における重要な4要素からOSSを評価する 前編 |BRO



ご無沙汰しております・・・



実際には結構前に書いた記事なのですが、私が確認作業を放置したなどの行き違いがあって、最近ようやく公開されました。IT投資評価の文脈で、適切にOSSを評価してもらうためのセットアップを期したのですが、なかなかうまくまとめるのは難しいですね。



(文責 Ishii Akinori IT-Coordinater)




2013年4月26日金曜日

求める人物像など

前回の記事が、結局ハードルを上げてしまっている、というもっともなご指摘してきをいくつか頂いてしまいましたので、さっそく続編を。頑張ってハードルを下げていきたいと思います。あ、下げ始める前に、ハードルの高さという意味でのネガティヴ要素を吐き出してしまうとすると、今現在の技術要員のほとんどが東大か京大の出身です。例外はありますが、個人始めたAndroidアプリのダウンロードが50万を超えた、とかっていうフランス人です。でも、学歴は別に条件ではないので、例外っていう言い方は不適切かもしれませんね。



よし、ハードルを下げる時がきました。(繰り返しますが、別に学歴やコミュニティ活動の実績は初めから求人の条件に入っていないので、それをもってハードルというのは本来おかしいんですけどね)



求める人物像



例によって、スキルや実績の話と性格や姿勢の話があると思うんですが、まずはより具体的な直近で求めているスキルの話から。



期待するスキル



今弊社で開発中の2つの製品CMISSnycとNemakiWareのうち、すぐにも人員を増強したいのはNemakiWareの方です。これはいわゆるNoSQL系の中でもドキュメントDBといわれるCouchDBを利用する文書管理のためのソフトウェアで、本体部分はJavaで作っています。検索はSolrを使っています。UI部分はRailsで作っています。CouchDBの都合なども考えると、言語としてはJavaかJavaScriptかRubyができれば良いということになるわけですね。(ハードル下げてますよアピールが鼻につく文体になりがちで、注意が必要な気がしてきました)



ただ、この製品はOASIS標準規格であるCMISに準拠するというコンセプトがあるため、この規格についての理解が求められます。おそらく日本国内にこの規格に明るい人材なんて数える程しかいないはずなので、これは参画の時点で求めるべきスキル・知識だとは考えていません。ただ、英語でこの規格についての文書を読み、理解を深め、場合によっては規格策定の当事者たちに質問して疑問を解消する、というようなことが求められる可能性はあります。(また、上がってきてしまいました)



ということで、新メンバーの方には、実際にはCMISについての理解度の要求水準が比較的に低いRails製のUIのところから着手してもらうことになるのではないかと思います。パッケージ製品として長期にわたって展開していくので、メンテナンス性や拡張性を考えた設計や実装をしていきたいですし、オープンソース製品なのでその成果物のほとんどは衆目にさらされることになります。このあたりを引き受けられるかどうかがポイントになるのではないかと思います。その点で信頼できる人であれば、たとえば仕事でRailsを使ったことがなくても問題ないくらいだと考えています。



スキルや経験以外の話



この場では副社長権限で私の好みについてだけ書かせて頂きます。実際にはチームワークなので、他のメンバーの好みはここに書かれているものとは異なりますし、採用の条件にはなりづらいと思いますが、少なくとも候補者の方の視点から私の好みを観察できることに意味はあると思うので。



色々考えたのですが、「自分のことを頭が良いと思っている」ということに尽きる気がしています。より正確に表現すると、「文脈・分野・問題によっては他の人より自分が考えた方が良い結果に繋がる(こともある)、というステートメントを引き受けることができる」ということなんですが、言葉が増えた割には明確にはなっていないかもしれませんね。要するに考えることをすべて他人任せにされてしまうととても困る、ということです。そして、自分で考えるという選択肢を主体的にとれるのは、そういう自負がある人だけだというのが私の考えです。



念のために書いておきますが、うちのメンバーが全員自分が一番賢いと思っている鼻持ちならない秀才タイプということではないです。むしろ逆と言っても良いくらいです。あえて当てはまりそうなのは私くらいじゃないかと思います。そういう思い上がりを表に出しても良いことはないわけですからね。



くどくなりますが、うちのメンバーは見るからに優秀です。特に技術部門のリーダーは(本人はありとあらゆる隙間を見つけて否定してきますが)相対する側が圧力を感じるくらいに優秀です。そのため新しく参画する人は、自分よりも他のメンバーに判断を委ねた方が組織全体のためになる、と考えてしまう可能性が高いわけです。特に自分がまだ不慣れな状況である、ということを勘案すれば、その選択はなかなか責められるものではありません。しかし、我々の業界では、考える部分を他人に依存し続けることで楽しく仕事ができることはほとんどないと思います。個別に正しい割り切りを積み上げていくと、結果みんなが不幸になってしまう。



弊社のような環境では、優秀な仕事仲間を仮想的な競合(敵)とみなすことなく、あくまで助言者として利用し、自分で考えて仕事を進めていく必要があります。そのためには、現場感覚としてはリスキーに思えても、自分から担当範囲を広げていくしかないわけです。その時の支えになるのが、これまでに積み上げた成功体験です。自分が考えたことで良い結果を生んだという体験がない人には、なかなかそのリスクを引き受けることができないのではないかと思います。だからこそ、私は「自分のことを頭がよいと思っている」人を求めているわけです。(東大卒の人達などは立場上普段から「自分はバカですから」という発言を封じられているという意味で、この基準をクリアしやすいという構造があると思います)



なかなかうまく表現できませんでしたが、個人の好みを書き連ねるのはここまでにします。もし、今後ここを読んだ候補者の方とお話をする機会が持てたとしたら、その時個別にフォローしたいと思います。



会社の特徴



今、イノベーションの主戦場がWeb系のサービス運営会社に移ってしまい、企業向けソフトウェアの業界はその魅力を失っていると言われています。我々は、その陰りが見え始めたと言われる業界において、もっとも活気があると思われる領域(の一つ)をホームとしています。



情報システム分野、特にソフトウェアについては初期投資があまり必要ではないため、新規事業者が戦い易い領域です。つまり、混沌とした競争環境が続く戦場です。その中で長期的に生き残る為には、何らかの競争優位な性質を見極め、そこに注力するのが良い選択だと考えられます。そこで我々が選んだのが「オープンソース」です。



これまでの仕事



今「オープンソース」はある特定の文脈においては、「ソーシャル・モバイル・クラウド」などに比べて新規性(輝き?)が失われたキーワードだと見なすことができるかもしれません。しかし、それを言うのであれば我々が戦略としてここに注力することを選んだ8年前でも、別に新しさのある言葉ではありませんでした。我々は新しい分野で目立ちたくて選んだのではなく、長期的な優位性を持ち得る考えたからこの道を選んだのです。



なぜ、オープンソースが長期的な優位を生むのか。それは、このモデルが一次生産者である個々の技術者と消費者の双方にとって有利なものだからです。IT技術はインターネットによって一般のビジネスにおける情報格差を消滅させ、多くの卸売業を窮地に追い込みましたが、IT技術そのものの供給は相変わらずIT技術の知識の有無という情報格差に依存したSIビジネスによってなり立っています。特に、ユーザ企業側の技術に対するコミットが弱いとされる日本企業においてその傾向は顕著であると言えるでしょう。それでも、一次生産者と消費者がオープンソースを選好していけば徐々に企業向けのITプロジェクトがオープンソース製品ベースのものになっていくと考えられるわけです。



なぜ、一次生産者と消費者にとって有利なのか。これにはいくつか理由があります。まず、ここでいう一次生産者はITベンダではなく、そこで働く技術者を想定しています。プロプラエタリな技術は徹頭徹尾勤務先であるベンダに帰属します。その知識や経験が適用可能なプロジェクトはそのベンダの製品を取り扱ったものに限られます。そして、その製品自体の寿命はその企業の経営状態にも依存してしまいます。ビッグベンダによって買収され、親会社の製品ラインナップのなかに無理矢理押し込められる、というのは恐らく最良に近い将来像であると言えるでしょう。つまり、仕事をつまらなくする要素に事欠かない、ということです。オープンソースの場合は、もう少し状況は改善されます。貢献の事実は個人の資産ですし、部分的にであれ良いものができているなら好きなだけ他のプロジェクトへ持っていくこともできます(持っていく先も多くの場合はオープンソースであることが期待されますが)



ソースコードを公開する、という前提があるので、ある程度以上の自信があるエンジニアでなければ精神的に辛い面もあるかもしれません。しかし、それはつまり、オープンソースのものとそうでない2つの技術なり製品があった時、前者側に参加しているエンジニアの方が相対的にスキルが高いと期待できるということでもあります。私の知る限り、優秀なエンジニアと一緒に働きたいと考えない「優秀なエンジニア」は存在しません。以上の帰結として、オープンソース製品には(相対的に)優秀なエンジニアが集まる傾向にあると予想できます。少なくとも自由に選択肢が提示されれば、そうなっていくはずです。その意味で、長期的な優位、です。



消費者にとって有利、というのも、価格のことだけではありません。特定のベンダにロックインされにくく、技術自体の存続性の期待が高い、そして優秀なエンジニアに担当してもらえる可能性も高い、ということです。こちらも、IT投資のリスクをどう評価するのか、という点にかかっているので、すぐにオープンソース陣営が大勝ちするということは期待していませんでしたし、実際に移行は緩やかなものだったと思います。「感度の高い」お客様から先にオープンソースの製品を採用していくという傾向がありました。これは、8年前の時点で明確に狙っていたことではありませんが、結果としてこれまでのお客様のほぼすべてが、皆一緒に働く甲斐のある人達でした。



これからの挑戦



そして今、私たちはさらに新しいことに挑戦しはじめています。自社製品の開発です。当然、オープンソースモデルを採用しています。



今までの経験がどこまで通用するか、まだはっきりとはわかっていません。しかし、海外で成功しているオープンソースの企業向けソフトウェアの実態や、それを日本で展開することのビジネス面と技術面双方での難しさ、などについての理解・経験においてすでに我々は国内でもトップの水準にあると思われます。それは確かに一つの経営資源であり、活かさない手はありません。その一つの方法が、自社製品の開発であると考えています。



ベンチャーなので、小さい会社なので、個人の裁量が大きいという言い方はあまりしたくないのですが、そういう実態があるのもまた事実です。そのことは、単なる丸投げ体質と言われかねないものでもあるでしょう。だからこそ、どういう見込みに基づいてこれまで仕事してきたのか、これからどんなレベルで試行錯誤をしていかなければならない状況にあるのか、ということについて可能な限り明らかにしておきたいと考えました。十分な整理なく、勢いで書いてしまっているので、冗長なわりに表現しきれなかったことばかりである気もしますが、以上が今回の人材募集の背景として考えていることになります。



まとめると、「なんだか面倒くさそうな人達と一緒に、RailsやNoSQLとJavaを織り交ぜて、企業相手のソフトウェアを書く仕事」に興味がある人いませんか? って感じです。



皆様是非よろしくお願い致します。



(文責 Ishii Akinori IT-Coordinater)