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)




2013年4月25日木曜日

改めて求人を担当するにあたって

困ったことになりました。いよいよもって人手が不足しています。受注が重なってしまい、自社開発プロジェクトに深刻な影響がではじめました。そこで、私が担当となって追加の技術要員を探すことになってしまいました。



人材の募集は常に行っているのですが、通常ですとメンバーが業務の隙間時間に面談を繰り返し行い、最後に我々取締役が最終面談、という流れであり、最近は忙しくてなかなか手が回らない状況が続いていました。特に、弊社の場合はコンサルタント要員よりも技術要員の方が実質的なハードルが高い、というやや特殊な状況がどうもあるようで、まずはそのあたりの整理から着手していく必要がありそうです。(ここでいうコンサルタント要員はビジネスコンサルティングの部門の要員という意味で、OSSのコンサルティングは弊社ではどちらかと言えば技術要員の仕事になっています)



ですが、時間がないので最初のところから私が担当することでスピードアップを図りたいと思います。一人で勝手に候補者に会って即決、というわけではなく、今まで通りの面談は実施していく予定ではありますが、時間を短縮することくらいはできるのではないか、と。



せっかくなので何故技術要員のハードルが高くなっているのか、というお話や求める人材像(?)についてもう少し。記事の性格上会社の特徴なんかも必要かもしれませんね。また、無駄に長くなりそうですね・・・



高いハードル



後で会社の特徴としても触れるかもしれませんが、経営陣の一人である私に技術者重視の会社を作りたいという気持ちが元々あること。そのくせ日和って技術畑でない人とのバランスや収益性を考えると、技術者パラダイス的な組織を用意するような器があるわけではないこと。それらの結果として他社がやりたがらない難しい仕事ばかりをやらざるを得なくなっていること。そして何より、現状のメンバーがそれが出来てしまうくらい優秀であること。



結果として、どの仕事も新しい人を割り当ててうまく行くイメージを持てない、という状況がうまれました。



これは、私の、(しかも残念な事に、世の中にはありふれている類いの)失策です。優秀なリーダーと優秀なメンバーに甘えすぎました。



難しい仕事とは



弊社の技術部門の場合は、オープンソースの企業向けソフトウェアの導入コンサルティングや技術アドバイザリ、製品サポート、トレーニング、などがそれにあたります。他社に先駆けて取り扱いを開始したため資料は仮にあったとしても全て英語ですし、複雑な問題解決には開発元の人達との英語でのコミュニケーションが必要になります。その場合、ソースコードが読めることは大前提です。



一方で顧客サイドに対してもまだまだ理解度に濃淡がある「オープンソース」に対する期待をコントロールし、ライセンス費用が無償である分時として逆に期待レベルが上がってしまっているスキルに対する要望に応えていかなければなりません。



こうして仕事の性質を並べて書いてしまうと、とても割の良い仕事には見えないかもしれません。実際、メンバーには負担をかけているところもあります。それでも、ソースコードへのアクセスがある、製造元の技術力やビジョンを直接自分で判断できる、ということのメリットは大きいはずですし、年々顧客サイドの理解も深まっています。何より、弊社のメンバーはその仕事をこなし、今回のような人手不足を生じさせてしまうほどの評価も得ています。



ですから、難しい仕事という言い方は、実は一面的すぎたわけです。



私の反省すべき点



問題なのは、この「オープンソースかつ企業向け」というマーケットの可能性を私自身が十分に信じ切れておらず、事業としてのリスクをメンバーのスキルのみで押さえ込んできてしまった、というところにあります。



このビジネスにはもっと間口を広げて(現状の技術メンバーの大部分のように元々の知り合いで、すでに「できる」ことがはっきりしている人以外にも)もっと人員を多く動員できるだけの余地が十分にあったし、今もある、ということです。



次回予告



やっぱり長くなりすぎるので、求める人材像と会社の特徴の再整理の話は次に持ち越します。上記の話はこれまでやってきたOSSのコンサルティングのビジネスを下敷きにしてしまっていますが、現在の募集はそこだけでなく、より技術志向の強い自社製品開発の部分に重点をおいています。(既存のコンサルティングの募集ももちろんやっています)



次もすぐ書きます。今日か明日には。



(文責 Ishii Akinori IT-Coordinater)




2013年4月11日木曜日

ソーシャルとコラボレーションの話 特にco-meetingについて

いつのまにかMarsEditの設定が狂っていたのか、Typepadの移行のタイミングで何かミスをしてしまっていたのか、ここ数回のポストは改行がなくなってました・・・ まったくチェックをしていないことがばれてしまいますね。誤字脱字も多いので、それ以前の問題である気もしますが。



さて、ソーシャルとコラボレーションというキーワードで、何件かLiferayのお話をさせて頂く機会がありました。Social Officeというプラグインもありますし、Socialの名前がついたPortletも幾つか公開されています。まとまった説明ができるといいんですが、今はまだ準備中というところです。



AIIMに関してもそうなんですが、ECM製品はこの10年くらいコラボレーション機能を強化してきた歴史があります。それこそちょうど10年くらい前に、現在はEMCの一部であるDocumentum社がeRoomを買収したあたりのタイミングで、その流れが明確に認識できるようになったと思います。当時は「柔らかい文書管理」というような言い方もされていて、文書として完成したものを「しまっておく」格式の高い保管場所としてのリポジトリから、文書の作成過程へと守備範囲を広げていくというトレンドがありました。ソースコード管理システムはすでにある程度普及していた(といっても現在のスタンダードであるgitなどの分散リポジトリどころか、その前の世代のsubversionですらなく、CVSかMS製品か、という印象でしたが)ため、版管理機能そのものは生産性向上にも効果を発揮するはずだ、という話もたびたび話題になっていました。P2P技術を使ってリアルタイムにオフィス文書を編集しる技術や、専用機材ではなくWebカムを使ったビデオ会議なども手に入りやすくなった時期で、eRoomの営業資料などには、コラボレーションとは必ずしも「リアルタイム」「ビデオ」を意味するものではありません、なんて文言が散りばめられていたのを覚えています。



そして現在、コラボレーションと共に語られるキーワードとしては「ソーシャル」がもっとも目立つ存在ではないかと思います。Enterprise 2.0であるとかSocial Content Managementだとか、という切り口でECM製品もソーシャルテクノロジについては積極的な対応をうたっています。弊社もコンサルティングファームとして単純なパッケージ導入以外にもこうした企業向けアプリケーションの中でソーシャル対応をうたうものの選別や導入支援などのお話をよくさせて頂いています。(また、ECM方面だけでなくLiferayがソーシャル基盤としての機能強化を意欲的に進めていることも本来であれば無視できない話題ですが、今回は省略します)



そうした立ち位置で現在弊社が社内のコミュニケーションの基盤として試用・評価中のものにco-meetingがあります。ざっくりとした説明をしますと、Google Reader廃止以前はもっともショッキングだったGoogle系ロストテクノロジ(?)のWaveに近い作りのツールです。(ざっくりしてるわりには、相手を選ぶ説明でしたが、そのまま続けます) リアルタイムチャットで、漢字変換確定前のタイピング過程まで共有表示されるという特徴を持っています。この最終的に確定する文言以外の情報が相手の目に触れうる、という感覚が非常に面白いので、小規模利用は無償でできるので、是非これを読んだ方は試してみて頂きたいのです。初回、私は、この遊びとも言える部分がノンバーバルコミュニケーション的な補完作用を持っているのか? という妄想にかられました。リモートワークの取り組みの中でオフィス内にカメラとマイクを設置して「雰囲気」の直接的な共有を試みた事例がありましたが、それに近い感覚的な御利益がある気がします。



ただ、私が特に面白いなと感じたのが、このツールが「コラボレーション」のためのものであるし、現代的な作りで、現代的な技術で作られているにもかかわらず、まったく「ソーシャル」的ではない、ということです。具体的には、これは運営している株式会社co-meetingの方達とも直接お話して確認したのですが、彼らはこのツールの得意分野を「議題・題名が明確についたやりとり」と見極めて開発をしている、という点からも言えることだと思います。



ソーシャルテクノロジによって電子メールが廃れる、という考え方があります。若い世代はSNSがあるので電子メールには見向きもしない、とか、逆にFacebookが情報で溢れてしまったのでむしろある程度ハードルがある電子メールに回帰してる、とかっていう話題は定期的にIT系のメディアに登場するので、妥当性はともかく今やそれほど突飛な考えではないと思います。この場合、ソーシャルテクノロジと比較した場合の電子メールの特徴は「題名」「宛先」を明確化しないと書けない、という点にあるとされます。(無駄なコピーが増えるなど、「問題点」はもっとたくさんありますが、コミュニケーション手段としての特徴はこの点に集約できると思います)つぶやき、にはどちらも要求されません。SNSのメッセージング機能も多くの場合は相手こそ選ぶものの表題は要求されません。



いわゆる社内SNSというのも、情報共有、組織活性化などを目的にすることが多いと思いますが、そこで前提とされているのは、グラフ起点でうっすら届くので個別の「宛先」設定がいらないし、「議題」確定前の緩い情報もはき出せる、という環境を用意することで、これまで電子化どころか言語化されなかった情報まで吸い上げることが可能になる、という期待でしょう。これに対して、co-meetingは明確に「議題」が設定された後のやりとりに集中しています。またも、ざっくりしている割には伝わりにくい説明をするのであれば、先日tumblr経由でながれてきた喧嘩の売り方のツィート『ガンコ親父「表へ出やがれ!!」
不良「ちょっと体育館ウラまでこいや」
ヤクザ「ウチの事務所いくか?お?」
数学者「じゃ黒板のある部屋行きましょう」』の数学者のところに近いイメージが理想的なco-meetingの使い方であるように感じています。



co-meeting社の方にお話を伺ったときも、yammerやchatterなどのソーシャルツールで議題が浮かび上がってきた後の詰めをco-meetingに舞台を移して行うパターンと、co-meetingのグループ内に「雑談」という名前の会議室を作っておいてそこで議題設定前のメッセージを受けとめるというパターンがありうる、というご説明をいただきました。弊社でもとりあえず、後者の「雑談」会議室パターンを試してみているんですが、yammerなどと比べるとグループとはいえあくまで公共の場という印象になってしまいあまりにも個人的なつぶやきのようなものは出しづらい感じがしました。このあたりは個人の性格や組織の文化もあるとは思うのですが、ソーシャル系のツールとco-meetingの性質の違いを強く感じられるポイントだと思います。



co-meetingも非同期的なコミュニケーションの基盤としての利点を持つツールなので、未読のメッセージを処理していくUIを備えていますが、それも最新情報が上にくるタイムライン的な表示ではありませんし、(少なくとも今のところ)そういう流し読み把握をブーストするようなモバイルクライアントもありません。そういうツールやモードもあったらあったでありがたいな、と思いますが、コラボレーション基盤としての軸をぶらさずに突き抜けて欲しいという気持ちもあり、なかなか難しいところです。最近、Facebook上でモバイルブラウザ向けのスタイルでアクセスできるページが紹介されていましたし、今のご時世まったく対応がなされないということはないと思うのですが、どこをどう工夫しても万人の賛同は得られない領域だと思うので、co-meeting社の次のうごきには注目ですね。



(文責 Ishii Akinori IT-Coordinator)




2013年4月4日木曜日

(続き)AIIM Conference 2013 #AIIM13

前回、予告しておきながらカバーできなかった話題、『ECMの終焉』について、です。ECM eraが終わった、っていう言い方もされていたので、その場合はECM時代の終焉、なのかもしれませんが。



元々はマイクロフィルムから始まっているとはいえ現在のAIIMはECMの業界団体でもあるわけですから、ECMの終焉というメッセージは穏やかではありません。ただ、容易に想像がつくことですが、これはあくまで関心を引くためのアジテーション的な言説で、実際、カンファレンスの最後を飾る会長のキーノートでは、「現時点でのビジネスの中心は従来的なECMビジネス。System of Engagementというコンセプトがお金を生み出すのはこれから(ただし凄く近い将来)」というような趣旨の発言がありました。



では、何故ECMの終焉という言い方がされるのか。それは、北米圏ではECMが普及しきっているから、という今までなされてきた説明だけでなく、Saas・クラウドの普及によって顧客が求めるサービス形態やスピードが変化してきていて、CRMやERPなどのかつて3文字略語と言われたアプリケーションカテゴリのラベルだけでビジネスをするのが難しくなってきたからだ、ということのようです。



これは営業マン向け(?)の別のセッションでも言及されていたことなんですが、今までは単純な組合せの数式でビジネスをしてきましたね、と。


Microsoft Sharepointの式は「ECM + Collaboration = $$$」(ECM plus Collaboration makes much moneyと読みます)、Alfrescoであれば「ECM - $$ = $$$」(ECM minus money makes more moneyだったかな?)、という具合に。


でも、そういうのはもうやめましょう、もっと自分たちの強みを見極めつつ、ECMそのものの価値を過小評価せずに商談を進めて行くべきです、というような話しがされていました。
ECMの終焉という話題もそこと基本線を同じくしています。ECMと例えばスキャナ管理ソリューションを単純に組み合わせて売るのではなく、自分たちのプラットフォームの上に顧客が実現したいソリューションを表現するアプリを載せていく形になっていくべきだ、と。


なので、キーワードとしてECMという言葉を出してものを売る時代は終わったんだ、ということのようです。
正直な感想としては、アプリを構築するのと特定モジュールをECMとの抱き合わせで売ることの違いがどこまであるのか、特に顧客アピールという面ではピンとこなかった部分もあるのですが2013年現在のAIIMのメッセージの方向性は上記のようなものになっていると考えていいと思います。


後は、日本の市場がそれをどれだけフォローするか、ってことになりますが、ECMの普及率の違いだけでなく社内システムの構築に対する組織構成がだいぶ違っているようなので、こういうコンシューマライゼーションが絡む領域だと単純に日本がアメリカをフォローするっていうモデルは通用しないですよねぇ、、、



��文責 Ishii Akinori IT-Coordinator)



2013年4月2日火曜日

AIIM Conference 2013 #AIIM13

AIIM Conference 2013 #AIIM13: "The AIIM Conference 2013 is ONLY for those who are ready to think strategically about information management on a massive scale"


(Via AIIM.)



JIIMA ECM委員の1人として、先日行われた北米AIIMのAIIMカンファレンス2013の視察に言ってきました。別途レポートを月刊IMに寄稿する予定ですし、イベントでも報告させて頂くことになるとは思いますが、こちらにも簡単にご紹介を。



AIIMはJIIMAと同じくマイクロフィルムの普及を目的として設立された団体で、JIIMAよりもさらに10年長い歴史を持っています。その後、電子的な文書管理、ECMなども世界最大の業界団体として引き受け、拡大していったため、これまでは見本市とせっとで恒例のカンファレンスをやっていたのですが、今年からはカンファレンスのみの開催となっています。


よりインタラクティブなやりとりが重視されるということで、あまり英語、特に英会話に自信がない身としてはかなり緊張したのですが、折角の機会ですので視察員として立候補してしまいました。(立候補なんて何年ぶりだろう、と思いましたが、よく考えたら学生時代も特にそういう華々しいことはしていませんでしたね・・・)



実は、ここ数年、AIIM関連のイベントや、関係者のBlogなどでは「ECMは終わった」というようなメッセージをよく見かけていたので、「じゃあ、今後はどうするんだ?」という関心もありました。JIIMAの方々もそのあたりには強く興味を持っているようでした。



結論としては、従来のECMのビジネスは今なお継続しているし、簡単になくなるものではない、というある種予想通りの回答がそこにはあったわけですが、一方で、この2,3年彼らが主張してきた『ECM時代の終焉』というテーマについての議論もずいぶんと整理されてきたような印象も受けました。


今回のポストではこのあたりについて簡単に触れたいと思います。
まず、例えばAlfrescoあたりが主張していたSocial Content ManagementやCloud Connected Contentという標語からも見て取れるように、いわゆるソーシャル・モバイル・クラウド(・ビッグデータ)というIT業界全体のトレンドとの絡みがあります。これまで、こうした波が押し寄せてきた結果、従来型のECMが通用しなくなるよ! という危機感の煽り方がなされてきたわけですが、今回のカンファレンスの発表ではこのあたりのロジックがもう少し丁寧になっていました。


例えば、ソーシャルコンテンツとレコードマネジメントの組合せが何度か例として現況されていました。レコードマネジメントは、それこそ紙からマイクロフィルム、スキャンされた電子データ、Born Digitalと言われる初めから電子形式で作られる文書ファイル、とその対象範囲を広げてきました。ただ、これまでは対象の「形式」が増え、検索などの「機能」も拡張されてきましたが、基本的には紙文書の代替物として理解できるコンテンツというところに大きな変化はありませんでした。しかし、ソーシャルの仕組みが導入されると、文書としての態をなしていないコンテンツが業務上の意味を持つというケースが出てくるわけです。これはレコードマネージャにとって非常に難しい課題であると言えます。



似たような議論として、情報爆発についての言及も繰り返し行われていました。今、ECMのエンドユーザである一般的な企業ユーザの1人1人が処理しなければならない情報は加速度的に増えていっています。エンゲージメントを巡る議論、社内SNSで組織活性化!、などの話題は国内でも馴染みのものですが、なぜ活性化をする必要があるのか、という点についての踏み込みが感じられました。情報過多が人々を疲弊させている、というストーリーがまずあって、適切に情報をフィルタリングする仕組みを入れることでその課題を解決する、という建て付けになっているようです。日本だと、雰囲気不景気で人々が疲弊しているのは所与の条件というムードがあって、わざわざ何故疲れているのかっていう話しにはならないですからね・・・
いずれにしても、思った以上に分析や自動分類がECMの基本機能として取り込まれていきそうな感触を受けました。


人々を情報流による疲弊からガードしつつ、管理のための管理作業(メタデータ入力など)から解放するという方向性ですね。
あ、予定から外れて『ECMの終焉』まで到達できませんでした。続きは次回にします。



��文責 Ishii Akinori IT-Coordinator)



2013年4月1日月曜日

Alfresco が WeWebU Software AG の買収を発表 | Alfresco

Alfresco が WeWebU Software AG の買収を発表 | Alfresco: "コンテンツ管理に適した最先端のビジネスアプリケーションのWeWebUが、Alfrescoソリューションをさらにパワーアップする。"


(Via Alfresco Software社Webサイト.)



数ヶ月前のニュースですが、Blog放置期間に図らずもスルーしてしまった話題の中でも個人的には「大物」だと思っていたものなので改めて。



WeWebUはかなり前からAlfrescoのオルタナティブクライアントを作っていた人達ですね。最初期のコミュニティアワードの受賞者も輩出していたような気がします。(うろ覚えなので、間違っているかもしれません)
商用オープンソース製品は、製品本体への機能の取り込みの判断が非常に合理的で、ニーズが一般的でなく標準の拡張ポイントにクリーンなカスタムコードを載せることで実現できそうな機能はほとんど取り込まれません。


機能競争をしているプロプライエタリ製品の場合は、機能と設定項目がその数だけ増えていくことになるので、それに比べれば理に適った方針です、、、と距離のあるところからは無邪気に発言できるのですが、実際にはカスタムコード抜きでUI上で色々実現して欲しいという要望は山ほど受け取るわけです。


初期においてはドラッグアンドドロップでのファイル登録などもなかったので、顧客の期待とのギャップは大きく、Flexなどを利用したオルタナティブクライアントに期待が寄せられることになりました。
その後はHTML5を使って標準のUIが強化されると、そうしたオルタナティブクライアントを擁していた企業は、よりビジネスアプリとして進化したり、モバイルアプリとのシナジーを目指したり、CMISに対応したり、という動きを見せることになります。


WeWebUは特にうまくやっていたように見える会社で、結果としてAlfrescoによる買収、という形になったわけです。

#ECMベンダ独立なCMISクライアントが減るというのは立場的には少し残念ですけど。


今後はビジネスアプリとしての展開が特に注目されると思います。やはりプロプライエタリベンダの方が、「新機能」の源泉を買収に求める傾向は元々強く、ECMコア以外の部分ではAlfrescoは競合する他社ECM製品群よりも手数が少ない印象があります。


さらに買収で広げていくのか、こうした新モジュールも含めたパートナーソリューションの横展開を推進するのか。個人的にはCase Managementの実装に関心があるのでそのあたりが盛り上がってくれると楽しそうなのですが。



今モバイルアプリとしてAlfrescoから提供されているソフトは2つあって、1つがWeWebU由来のAlfresco Workdesk、もう1つが従来からあるAlfrescoモバイルアプリなんですが、そのAlfrescoモバイルアプリの製造元であるZia ConsultingもAlfrescoベースのCase ManagementのWebinarシリーズを計画しています。


時差の関係でなかなか難しいんですが、余裕があれば是非聴講しようと思います。何か面白い話しがあればここでもご紹介したいですね。




��文責 Ishii Akinori IT-Coordinator)