超個人主義？ の話。

また、少し間が空いてしまいました。

最近、身近なところでチームラボの猪子社長の記事が話題になって、「もしかしたら最近自分が考えてる（色んな人に話をしてもいる）事」と関係があるかも、と思ったのですが、実はあまり関係なかったので、改めてBlog記事を書くことにしました。（猪子さんは、自分と同じ年に生まれてるんですね、凄いなー　...って同年代で立派な仕事をしてる人なんて他にも沢山いるわけですけど）

さて、実際にリンク先の記事を見ても本文には載っていないのですが、記事のタイトルは「アメリカはチーム主義、日本は超個人主義」というものでした。日本人の個人主義というテーマについては、自分達のビジネスである業務用アプリケーションパッケージ、特にECMについて国内での活用がうまくいっていないという状況の説明として、これまでずっと考えてきたことだったので、似たようなことを言っている人がいるのかな？　と思ったわけです。実際には私が考えていたような就業観だとか企業文化といった話ではなく、教育の話でした。（それはそれで面白かったですし、共感するところもあるお話でしたが）

最近、この就業観についての話をする機会がとても多くなりました。ECM委員長なんて肩書きをもらったからかもしれません。どういうお話かというと、日本においてはカンバン方式的に「後工程（上司など）が本当に必要とするまでタスクを自分のところにキープする働き方」が当たり前だし、場合によっては奨励されているということです。

4コマ漫画的なものを描いてみました。ここで仕事を指示された人は、「別の仕事を振られたら面倒くさい」というネガティブな意味においても、（漫画では表現しきれませんでしたが）より現場に近い見地から上司が把握していないだろう状況の変化にともなう変更の発生時のフットワークを重視するというポジティブな意味においても、最後まで主体的に成果物の提出をしていません。結果的に当初期日よりも提出行為自体のタイミングは遅くなっています。

日本の場合はこれでよしとされるケースはままあるんじゃないかと思います。提出をしてなくても正味の仕事自体はちゃんとやっていた、と考えられるからです。

しかし、欧米で設計されている業務システム、例えばECMやBPMの場合、この辺の感覚が違っているように感じます。チーム/組織/会社に対して自分に与えられた分の仕事の結果を届けてはじめて仕事の区切りがつく。それは、それ以上の仕事はやりませんよ、というディフェンシブな態度にも見えますが、何かあったときに自分以外の人が対応をとれる状況を作っている（属人化を防いでいる）とも言えるわけです。

この2つの考え方の違いは、今では後者の方が説得力を増し始めていると感じますが（そして我々が導入支援を行っているコンセプトも技術も原則その立ち場に立つものだったりしますが）、本来はどちらか一方が正しいという性質のものではないように思います。ただ、ことITに関する限り、こういうものはグローバルにあわせておいた方が色々と合理的だとは思いますけどね！！

（追記　12/24）ごめんなさい。4コマ漫画的なものを「描いて」みました。って書いちゃいましたが、絵自体はツールのシェイプをそのまま貼っただけです。

（文責 Ishii Akinori IT-Coordinator）

コンサルタント合宿をやってみました@三浦半島

写真は泊まった部屋のバルコニーから見えた日の出です。

弊社の半分は技術系でできているので、いわゆるエンジニア的な合宿はこれまでにもやったことがあるのですが、今回はそうではないコンサルタントを中心にした合宿です。三浦半島に行ってきました。

コンサルタントとは？

今回私の担当はプロフェッショナルマインドでした。あまり得意な分野ではありませんが、これは我々の場合は突き詰めると「コンサルタントとは何か」という問いに行き着く領域だと思っています。

私や弊社の他の取締役がこの業界に入った2000年代の頭頃というのは、「新卒でコンサルティングファームに入社する」という選択肢が急激に一般化したタイミングでした。ですので、当時は、何故なんの経験も持たない新卒がコンサルティングなんていういかにも知見を必要としそうな業務を担当するのか（できるのか）ということについて数多の言説が流通していました。当事者でなくなったせいかもしれませんが、最近ではそういう話はあまり目にすることがなくなったような印象があります。いずれにしても、私個人として、社会人デビューの時期に「コンサルタントとは何か」という問いを何度もぶつけられたという経緯があるわけです。また、諸先輩方からも色々な考え方を聞かせて頂きました。恐らく、皆が自分なりの回答を獲得する必要があったのだと思います。

一方で、これは今でも感じるのですが、大手ファーム出身者信仰とも言えるような、「新卒の時にコンサルティングファームを経験した人材は使い勝手が良い」というバイアスが案件をご紹介いただける提携先やお客様先にも確かにあります。時として手っ取り早く評価を勝ち得る手がかりになるので、その便益を享受してしまってる立ち場ではあるんですが、2つの意味でモヤモヤとした気持ちにもなります。

• 大手ファーム出身者もそれぞれ異なるコンサルタントの定義を持っているように見えるのに、結論だけ都合良くまとめちゃってる気がする
• 他業種からの転職者で活躍している人達も多数存在する

求人時に学歴を参考にするかどうか、というのと同じく、それらが確定的な要素と考えているわけではなく、あくまでうっすらとでも相関を感じていればそれを意思決定に反映したい、という思いなのだというのは理解できます。しかし、コンサルタントというのは個人単位での評価を細かく受ける仕事でもあるので、個々の評価のタイミングで経歴要素が不当なバイアスとしてかかっている可能性、みたいなものを排除しきれないのは、多少気持ちが悪いわけです。

個人として、評価をする立ち場からこの気持ち悪さを乗り越える方法は、私もまた自分なりのコンサルタントの定義を相手に伝え、その定義と結びつけた評価を行っていくしかないと考えました。

なかなか時間的な制約もあって、今回の合宿でもらったコマの時間内ですべてを表現することはできませんでしたが、今後もこういう取り組みは続けていこう、ということになりました。

（私が具体的にどういう定義を採用しているのかについては、また今度機会があれば書いてみたいと思います）

BPMもやりました

本題です。1日目は上記の私の講義（？）と各コンサルタントからのプロジェクトの成果などについての報告、そしてボードゲーム大会…だったのですが、2日目には最近何度かここでも言及しているクエステトラのサービスを使ったワークショップをやってみました。

チームに別れて、対象業界を定義し、簡単な（プレ）提案資料とデモを作る、というワークショップです。事前に少しだけ座学っぽいセッションも入れましたが、基本的には朝から夕方までまるまるグループワークです。もしかすると丸一日かけなくても同じようなことはできるかもしれませんね。さすがはクラウドサービス。

これまでエンタープライズ系のパッケージ導入支援なんかをやっていたコンサルタントのメンバーから見ると、PDCAサイクルをお客さんに近いところで回せる、っていうところが大きな価値に見えるようでした。このあたりはちょっと深掘りしてみたい論点です。

普段はついつい、　PDCA？ 英語圏でもPlease Don't Change Anythingとか揶揄されてる奴？　みたいな似非無頼を気取り勝ちな私ですが、基本に忠実に、という美徳を思い出す良いきっかけであったように思います。反省しました。

（文責 Ishii Akinori IT-Coordinator）

ワークショップに参加するためにまた京都へ

11月12日にMIJS京都ワークショップ2014に行ってきました。今回のイベントは、パートナーでもあり大学院の先輩の会社でもあるクエステトラさんが幹事をやられていたそうです。

うちは（まだ？）MIJS会員企業ではないので、あくまで一般参加です。

MIJSはその名もMade in Japan Softwareコンソーシアムという組織で、圧倒的な輸入超過状態にある日本のソフトウェア産業の担い手達が、切磋琢磨しつつ海外市場へ乗り出していくためのグループ、、、だそうです。

大規模向けの業務パッケージソフトウェアは基本的に海外製である、というお話は実は私も折に触れてあちこちでさせてもらっていますが、それはあくまでパッケージソフトウェア導入コンサルティングという仕事の内容や特徴を説明するためであって、主体的に「自分達が日本製のソフトウェアを盛り上げていく」という立ち場にたって考えるということはほとんどしたことがありませんでした。（そもそも、自社でパッケージソフトウェアを開発するという、という立ち場にたったのも最近のことですし…）

日米の市場を比較して、日本ではパッケージソフトウェアそのものがほとんど導入されていない！　というお話がありました。私自身はERPのトレーニングを受けてその導入プロジェクトに参加した後で、そこからECMに流れていったので、「日本ではERP（やCRM）はちゃんと入ったのに、ECMは全然売れていない！」という枠組みで考えがちでしたが、もうちょっと視野を広げるとそもそもパッケージという枠組み全体での日米格差っていうのは確かにあったわけです。この辺はECMのことをよくご存じでない方々とお話する上では改めて留意すべき点であるように思いました。

あ、でもうちの製品はむしろ海外からの方が買ってもらってますけどね！　って全然規模が小さいわけですけど。

（文責 Ishii Akinori IT-Coordinator）

騎士団の招集に応じて（？）

OOTB！

OOTBという文字の並びを見ると、私の場合は『アウト・オブ・ザ・ボックス』かな？と思います。パッケージ製品をカスタマイズせずに利用する、というニュアンスの言葉で、いわゆるIT系の人が相手でも通じるとは限らない表現である気もします。（Python界隈の人だと『バッテリーインクルーデット』っていう別の表現もありますが、あくまで「カスタマイズ」の有無に関するものなので、実際には全然違う意味で使われる言葉になっています）

さて、妙な前置きが長くなってしまいましたが、パートナーシップは解消したものの依然として弊社のビジネスの中核を担う技術であるAlfrescoのお話です。

ここをご覧になっている方は大抵よくご存じであると思いますが、弊社がそのパートナシップの環から外れた後もAlfrescoは順調に業績を伸ばし、経営陣も入れ替えてIPOに向かって邁進し、業界に確固たる地位を築いています。国内でもパートナー企業が増えているので、以前に比べより多くの人にその情報が届く状況になってきたかと思います。

ハイブリッドクラウド構想とハイエンド指向を推し進め、大規模案件でも不安のない製品としてのポジションをオープンソース製品が勝ち得たことは非常に大きな意味があると思います。

そうした派手な方向とはまた別の指向で、そこまで大規模ではない事案へのフォローですとか、開発者コミュニティの育成という意味でのコミュニティの活性化という面でAlfrescoが話題になることはこれまであまりなかったように思います。強いて言えば、ecmarchitect.comの管理人でコミュニティアワードを受賞していたジェフ・ポッツ氏がコミュニティオフィサーという肩書きでAlfrescoにジョインした時くらいでしょうか。（そのジェフさんも先頃退職されてしまいましたが）

蜂の騎士団の結成

ようやく本題です。OOTBとはOrder of the beeの頭文字を並べたものです。ハリーポッターのフェニックス騎士団と同じ訳し方をするのであれば蜜蜂騎士団、という感じでしょうか。Alfresco Software社とは独立した形でAlfrescoのエコシステムを成長させていくために集ったコミュニティメンバーの組織です。その中には顧客側の人もいれば、Alfresco Software社の社員もいます。独立したエンジニアもいれば、我々のような会社もいるようです。

私自身も個人の名前で登録してもらっていますが、会社もプロフェッショナルネットワークのページに載せてもらいました。再びアジア初だったみたいですね。

（文責 Ishii Akinori IT-Coordinator）

韓国のu-Paperlessというイベントで講演をしてきました

人生初の釜山です。u-Paperless 2014という韓国のDCA Digital Content Associationという日本で言えばJIIMAにあたる団体主催のイベントでドキュメントプロセスアウトソーシング DPO Document Process Outsourcingというテーマで講演をしてきました。（ちなみに、すごく正直なことを言うと、DCAに対しては韓国はこういう活動に政府の後押しがあって羨ましい、という気持ちを持っています。イベントも立派でした。）

様々なトラブルがあったのですが、なんとか生き延びました。

ECM委員長になっての初仕事というつもりで半ば軽い気持ちで引き受けたのですが、（あ、初仕事はeドキュメント JAPAN版ECMサミットでしたね）、思いの外立派な会場で、完全に気合い負けしてしまいました。講演後の食事の席などで、各国の皆さんから暖かい言葉をかけられ、個別に深掘りしたような話もできたので、会場で見られただけの他の出席者の方には大変申し訳ないのですが、私としては収穫の大きいイベントでした。

講演したテーマについては勝手に資料を公開して良いのかどうかまだ判断がつかないので、簡単にここにまとめてしまいますと、

• DCAより歴史の古い（！）JIIMAの視点からみると、文書管理にはマイクロフィルム・デジタルイメージング・ボーンデジタルの大きな潮流あるいは「時代」があったと言える
• マイクロフィルムはアナログからアナログ、デジタルイメージングはアナログからデジタル、ボーンデジタルは文字通り始めからデジタルのものの取り込み
• それらの技術の提供者がオペレーションまで一括で引き受けるアウトソーシングには結構な歴史がある
• 技術者依存、ハードウェア依存、ソフトウェア実装、という形で後に行くほど取り扱いに（つぶしが利かない技術という意味での）専門性が不要になっていく
• アウトソーシングの分野でもBPO一般の事業をやっているプレイヤーや、所謂一般事務派遣に強い会社からのドキュメント関連プロセスへの参入がある
• e-Governmentのランキングなどから見ても韓国はボーンデジタルへの移行という意味で日本の先を行っている
• 日本の場合はドキュメントイメージングが主戦場であるという認識だが、そこにボーンデジタル時代の技術が援用できているという面白さもある
• 例えば（現地で紹介した事例）では3、4ヶ月でこれだけの処理能力があるセンターが立ち上がっている
• 新しい技術の活用とともにスキャニング前の事前準備の段階にノウハウの集積があるという点も重要である。このステップで時に10倍近くの生産性の差が生じると言われている
• ドキュメントイメージングの必要性は今更指摘するまでもないところだが、このように事業者側の組織的な学習の実態もあるので、業界全体は今後も成長を続けると考える

というような内容でした。いや、絶対こんなにちゃんと喋れてないですけど。後で英訳してメールも送っておこうかな…

（文責 Ishii Akinori IT-Coordinator）

経営情報学会で発表してきました。

新潟に来ております。
お邪魔し始めてからそろそろ1年ちょっとたつIT資産価値研究会（経営情報学会の部会になっているんです）の方々と一緒にグループ発表をしました。

見るからにマニアックなテーマですが、一応真面目に検討をしています。業務システムのコンサルティングの現場では、経営層や、あるいは時としてプロジェクト首脳部が、十分な技術的裏付け無しでの意思決定をしているようにしか見えない場面、というのに出くわすことがあります。少なくとも、現場レベルではありふれた愚痴の一つと言えると思います。

現場サイド、技術サイドが常に正しいとは限りません。それぞれの立ち場から見えるものだけを材料に判断せざるを得ないのは誰にとっても同じです。ただ、より上位の意思決定者の方が、単純な広さ（深さ、ではなく）という意味で、現場からは見えない幅広い情報（懐具合とか）を含めた意思決定をしているだけです。そういう意味では「大人はわかってくれない」式の愚痴でしかないのかもしれません。

大人は子供だったことがあります。子供はまだ大人になったことがないわけですから、ここには非対称性がある。しかし、どの大人も「今日の」子供であったわけではない。それに、忘れてしまっていることもありますし、単にしがらみが増えて自由度が落ちていることもあるわけですから、常に大人の方が正しくものを見てると考えるのは危険です。

ITシステムの話に戻すと、意思決定者であるビジネスサイドが適切な技術レベルの効果やリスクを理解できてないケースが非常に多いのではないか、という問題意識があります。（コストについては、こういう相互不理解はほとんどないと思いますが）
その最たるところが、技術的負債というものに対する評価だと思います。これは（原義とは異なりますが）ビジネスサイドの要望に応えるために、技術サイドが抱え込む「負債」です。負債なのにその意味がわかっているのは技術サイドだけ、という構造です。

そこで、「初期費用をケチらずに良い設計をしたら、後でどれだけ良いことがあるのか」を定量的に評価する試みをしてみました。題材は、初期費用をかけて開発段階でモジュラー化を十分に検討し、疎結合なアーキテクチャを採用すると、後の改修時（ビジネス環境の変化スピードが高くなればなるほど、多く発生するはずです）に、修正点を絞り込めるので工数もそれだけ減る。という構造をそのままモデル化しています。

まだまだ、こういう前提を勝手におくと、5年くらいでトータルコストが逆転するよ、とかっていう話しかできていませんが、ゆくゆくは現実のメトリクスなどを参考にしながらモデルの精緻化をしてみたいと思います。

その後で、（ECMやポータルエンジンなどの）筋の良いプラットフォームを導入することのメリットを定量的に説明できるようにして行きたいです。いつになるかはわからないんですが…

（文責 Ishii Akinori IT-Coordinator）

ポータルの方のMagic Quadrant

Liferay's Thoughts on the 2014 Gartner Magic Quadrant for Horizontal Portals というLiferay社CEOであるBryan CheungのポストがLiferay Blogに上がっていますね。

Magic Quadrant?

ここを見て頂いている方の多くには説明が不要かもしれませんが、Gartner恒例のマジッククワドラントという各ソリューション領域毎のベンダ評価マップとそのレポートに対応した記事です。マジッククワドラントは横軸にCompleteness of Vision（ビジョンの網羅性）縦軸にAbility to Execute（実現能力）をとった4象限のグラフに各ベンダを配置したもので、それぞれ、両軸共に優れたポジションにいるリーダー（右上）、ビジョンは優れているが実行能力や実績でリーダーに劣るビジョナリ（右下）、限定された領域で優れた実行能力を示しているチャレンジャー（左上）、それ以外のニッチプレイヤー（左下）に分類されます。

この分類においてLiferayはリーダーに位置づけられています。Liferayがこの象限に入ってからもう何年もたつので若干驚きが薄れてるところもありますが、これは実は結構凄いことです。

まず、リーダーには他にどんなベンダがいるのかを見てみると、IBM・SAP・Oracle・Microsoftと業界の4巨頭のみです。Liferayの様にポータル専業の会社は他にありません。

また、IPOで盛り上がっているという意味でも、大規模案件への対応力をしっかり示しているという意味でもこれまで以上にプレゼンスを高めているAlfrescoが、ECMのマジッククワドラントでは6年連続のビジョナリ（それだって凄いことなのですが）ということからも、オープンソースモデルの専業ベンダがこの象限に入っていることが如何に快挙であるかということがわかると思います。

昨年は、MicrosoftとIBMとOracleに対して実行能力で差を付けられた形の4位（ビジョンの評価はOracleよりもやや高かったのですが）ぐらいのポジションでしたが、今年はLiferayよりも高いスコアを出しているのはIBMだけです。

Gartnerはどんなことを言ってる？

実際には原文を見て頂くのが良いと思いますが、各ベンダの強みと脅威についてのコメントが出ています。

Liferayに関しては、この数年Javaベースのポータル製品としては最も高い成長スピードを見せているし、無償版とEnterprise版をうまく両立させているという評価がまずあります。さらに強みとして、大規模案件にも怯まず実績を積んできていること、モバイル・ソーシャルへの集中投資を続け素早い機能強化を成し遂げていること、顧客満足度が高いこと、を挙げています。

一方脅威としては、ライヴァルと比較して会社が小さい（さすがにあのラインナップでは！）こと、ユーザがオープンソースベースのアップグレードやサブスクリプションのモデルに馴染みがないことが（未だに！）あり得ること、エコシステムが拡大しているが小さい会社も多くスキルセットも分散気味（ごめんなさい！）であること、標準で提供される機能が競合に比して少ないこと、などが書かれています。

とりあえず、脅威に関しては、日本で弊社が支援しながら導入を進めていく、という意味では、特に問題はなさそうですね。（標準機能は多い方がいいですが、個々の機能についてグループウェアなどと直接戦うのにも限界がありますし）

Liferay CEOのメッセージは？

これも冒頭のリンクから原文をあたって頂くのが良いと思いますが（公式の翻訳ではないので）、幾つか面白いと思った点を紹介したいと思います。

まず、なぜGartnerのこのポータル領域のレポートにいわゆるWebコンテンツ管理製品（WCM、CMS）のベンダが名前を連ねているのか、という点についてのコメントがあります。要するに、現代の企業Webサイトは一方通行の情報発信ではなく、顧客体験にフォーカスせざるを得なくなっている。結果として、匿名のアクセスを捌くための従来型からあるWCMの機能とリアクション（分析とか追跡とか）を行うデジタルマーケティングの機能と、ユーザの登録・認証前提の体験、いわゆるポータルやカスタマーサービスのための機能の両方が必要になってきている、と。

その上で、それなら、はじめからログイン前提の使われ方（後者）の方で鍛えられてきたプラットフォームの方が有利だよね？と言っているわけですね。

次に、リーンなユーザ体験（Lean UXP）というキーワードに対してもコメントを残しています。これはちょっとまた話がそれてしまいますが、要するに、「Web配信のために素材や記事を溜め込んで、使い回したり、ワークフロー承認したり...」という従来的で重厚なCMSよりも、もっとスピードを重視しつつA/Bテストをはじめユーザの挙動を分析して露出面をどんどん練り上げていく方が大事だよね、という新しいトレンドにどう対応するか、というポイントです。これについては、その重要性を受け止めつつ、従来的なフレームワークの価値を手放さずに実現する手段として、Audience Targeting EEというアプリを紹介しています。

アジャイルな方向に攻めすぎると管理が疎かになるので、これは良い方向性だと思います。（それでも、もっとリーンに攻めたい、っていうニーズはあるかもしれないですけどね）

最後に、ポータル領域の3大シナリオ、というGartnerのニーズの整理について言及しています。パブリックなWebサイトはデジタルマーケティング、サービスポータルは顧客体験、従業員向けイントラネットは生産性と知識、と言った感じで3つのポータルのコアなユースケースに対するフォーカスポイントを示しています。このあたりは、我々が感じている顧客ニーズの方向性とも一致していると思います。

Blogの引越を試した流れで調子に乗って書いてみましたが、例によってちょっと冗長というか長すぎますね。図もないし...

（文責 Ishii Akinori IT-Coordinator）

ECM : 文書管理ソフト なら （ ） : ワークフローソフト の空欄に入る言葉は？

先週金曜日、Questetra クエステトラさんの矢作さんにパートナー向けのトレーニングを実施して頂きました。

営業向けセッションと技術系セッションの2本立てということでしたので、弊社側も（業務改善系などの）コンサルティングチームのリーダーやOSSコンサルティングのメンバー、それにマーケティングの人間を巻き込んで色々とお話を聞かせてもらう会になりました。

なんとなく想像はついていたことではあるんですが、やはりBPMあるいはBPMSのビジネスも「他のもっと安そうな奴」との比較にさらされるという難しさがあるようです。具体的には、いわゆる「ワークフロー」のツールと言われる、「簡易的に帳票フォームを作り、ユーザ好みの申請・承認フローに流せる」というソフトウェアとの比較、ということになります。

詳しい話はここでは割愛しますが、今回お聞きした色々な話は、我々がECMのビジネスを行う上でいわゆる「文書管理」のための国産ソフトウェアとの比較で説明に苦慮していたのと同じような構図にある、ということがとにかく印象的でした。あるいはエンタープライズポータルと「グループウェア」の比較、でもいいかもしれません。

プラットフォームかプロダクトか、という話題がLiferayのプレゼンなどにもよく出てきます。その上に独自の専用アプリをくみ上げていけるような環境を提供するのか、「箱を開けてすぐに使える」完成品を提供するのか。パッケージソフトウェアのビジネスも、実は、「パッケージ」なんだから完成品だろう、というような簡単な割り切りができるようにはなっていなかったりします。

例えば、Liferayはどちらの路線も捨てずに取りに行く、と宣言しています。プラットフォームとしての価値を確固たるものにするための技術的な努力と、「すぐに使えるアプリ」を提供していくことでエンドユーザにとっての魅力を高め導入スピードを速める努力、の両方を製造元の責任と捉えているということだと思います。

公的なマーケティングメッセージはプラットフォームとしてもプロダクトとしても価値のあるものを提供する、ということになりますが、私はより本質的な価値はプラットフォームとしての部分にあると考えています。個別のアプリケーションは、ユースケースや適用業界を絞ることでより洗練された設計と実装工数の節約ができます。（プラットフォーム指向ではない）専門アプリケーションの方が、多くの場合ではそこだけ見れば「できがよく」「価格も安い」。

ただし、それらの仕組みは新たなサイロを生み出します。

エンタープライズポータルにしてもECMにしてもBPMにしても、わざわざ「サイロを作らない統合的なシステム作り」を支援するような仕組みを大げさに持ち出すアプローチは、これまではコスト的なオーバーヘッドも大きく、プロジェクト単位の投資ではなかなか正当化が難しかった面がありますが、OSS製品やクラウドサービスの台頭によりシステム構築規模に比較するソフトウェアライセンスの金額的なインパクトが小さくなってきたことで、どうにか乗り越えられそうな素地が出来てきていると思います。

「新たなサイロができてしまうとしても、安くて導入が早いものを入れる」という判断がビジネス的に正しいというケースもたくさんあり得ます。私たちとしても単純な脅し文句として「サイロ」という単語を乱発したいわけではありません。新たなサイロが生み出す技術的な負債の評価ができているのか、ということだけが問題です。

そこで節約したコストと得られたスピードは、将来の維持コストの増大や潜在的な適用分野に関する制約（ある一定以上の範囲に広げようとすると技術的な無理が急激に増すとか、別製品への引越が必要になるとか）と見合うものなのか。

ECMやBPMなどの3文字略語の「意識高い系（？ 今日的な揶揄も込めて）」は、以前はビッグベンダや大手SIerによる安心料的な高コスト体質と不可分でしたが、今では違います。コストは如実に下がっていますし、クラウドの無償プランやOSSを組み合わせて、その気になれば自社でも検証や構築ができてしまうわけです。自社のシステムを長期の視点で主体的に育てていく気があるのかどうか、ということが実質的な分水嶺になると思います。

うーん、うまくまとまらない。一番言いたいのは、LiferayもQuestetraも、プラットフォームとしての目線の高さは維持したままプロダクトとしてすぐに使えるソリューションの提供に腐心しているから、最後のとこだけ見てる人から見るとその足枷が無い（逆に言えばそのソリューション領域に専心している）ツールに対して分が悪いこともあるかもしれない。でも、この目線の高さは、思った以上にすぐにメリットとして返ってくるもんですよ、ってところなんだけど。

表題は、イギリス:牛乳　＝　ロシア:（　　）の方が良かったですかね？
それとも、オランダ:靴　＝　（　　）:樫鳥で、ローカライズの困難さ問題に切り込むとか。

（文責 Ishii Akinori IT-Coordinator）

ECMサミット2014を無事に終えました

ナビゲーターとして、さも挨拶やらラップアップやらをやりそうなプログラムでしたが、ただの発音が不明瞭な棒立ち司会としての仕事しかやれませんでした。が、とにもかくにもECM委員長としての初のイベントから生還しました。残念ながらOracleさんだけは情報非公開ですがECMポータルのこちらのページから、各スピーカーの方々の発表資料をダウンロードして読むことができます。（OPENTEXTさんは差し替え修正が発生したようなので、公開が少しずれ込む予定です。）

ということで、現地であまり押しつけがましく語り出すのも良くないかと考えて控えさせて頂いた（？）、大まかな感想とまとめについて、ここにメモを残しておきたいと思います。

まず、この競業関係にあるビッグベンダによる競演形式についても、さすがにこれだけの回数繰り返してきていると各社も距離感が掴めてきているのか、テーマに謳われていなくても、必ず（社名の公開有無や国内外などの条件の差違こそあれ）具体的なケースについてのお話を入れてきて下さいました。やはりそういう要素がないとお客様が飽きてしまってあまり高い評価が得られないという傾向は確かにあります。

一方で、明日を語る、最新動向、というテーマですから、（世間一般でも言われているような意味での）デジタル化など新しい社会動向に対応する形でのビジョンやコンセプトについてのお話も、ある種似通った形になりました。コンセプト＋事例、ですね。

ECMは伝統的には「紙情報の電子化」というコンセプトを引き継いでいます。電子情報にすることで得られるコスト削減や利便性を実現する一方でコンプライアンスなどの課題解決にも資する、というのが最初の存在意義。次いで、そこで実現された高い機能や性能が、Born Digital、紙を経由せずに始めから電子的に作られるコンテンツの統一的管理基盤として認められたのが、ECMとしてのアイデンティティでした。さらに、いわゆる業務システム／業務プロセスの枠を超え、世の中全体がデジタル化していっている今、適切に電子化されたプロセスとコンテンツはさらにレバレッジを効いた大きな効果を生み出せるようになってきている... というのが各社がほぼ共通したメッセージとして語っていたところではないかと思います。

主催者の1人としてここで付け加えたいのは、ここで語られた新しいワークスタイル、ワークフロー、現代的なコンテンツの活用法のすべてを、新たなサイロを生むこと無く実現するためには、ECMプラットフォームが必須である、ということです。さらには、そうした実現能力を持つECM製品の技術の大半を、すでに見て頂いているということでもあります。

「デジタル化に対応した（そのメリットを最大化できるような）新しい仕組みを導入したい」と「これ以上の情報（システム）のサイロ化は進行させたくない」を両立させるようなまだ見ぬ銀の弾丸というのは存在しないということです。あるのはECMという（海外では良い意味でそれなりに枯れた）技術の集積のみです。　　　

...あ、弊社aegifだけは別、って話をこの流れでするのは良くないですよね？

他には、ケースマネジメントがある意味で典型的なECMの活用技法として定着しつつあるということ、プラットフォームとしてこそ輝くという点では一致していても、コーディングなしに拘るか標準技術の組合せをアピールするかという点で差が出ている、なんていうのも面白い点でしたね。専業ベンダーさんよりも、ビッグベンダー陣営の方が標準規格の推進に熱心であるような技術構成になっているという傾向なども綺麗にやり方が別れているようでした。目指すところはある程度重なっていても、実現方法はポジションによって結構変わってくるわけですね。その辺りもひっくるめてのアドバイザリー、というのも面白いかな、と思わないでもないんですが、委員としてはともかく本業的には今やうちもベンダーですから、独立した助言にはなり得ないんですよね。

次回は来年2月です。ECMサミットとしての単独イベントで、さらに盛りだくさんの内容になる予定です。是非とも多くの方にご参加頂ければと思います。

（文責 Ishii Akinori IT-Coordinator）

ECMサミット2014

恒例のECMサミットが近づいてきました。イベントの詳細については、ECMポータルの案内ページをご覧頂いた方がよいと思いますが、JIIMA最大のイベント、eドキュメントJAPANの中の1コマとして実施します。

ECM委員長をやらせて頂くようになって初のECMサミットであるため、緊張しております。

今回は残念ながらEMCさんは欠席（実は早いもの勝ちだったりするので、サミットとしての単独開催ではない今回のようなイベントの一部の場合枠に限りがあるのです）ですが、OPENTEXTさん・Hylandさん・IBMさん・Oracleさんというラインナップです。大雑把なくくりをしてしまえば、専門ベンダ2社、所謂ビッグベンダ2社という構成ですね。

国際展示場は交通の便の良いところではありませんが、お時間のある方は是非いらしてください！

（文責 Ishii Akinori IT-Coordinator）

BPMSはじめました（？）

怠け者の節句働きというか、降れば土砂降りというか（2回でそれは言い過ぎか）、昨日に引き続いて投稿します。

京大情報研の超交流会でもお世話になっているQuestetra クエステトラさんのパートナーシッププログラムに参加することになりました。

取り組みとしては2つのスタイルを考えています。1つは、BPRプロジェクトなどにも参加するいわゆるコンサルティングファームとして、もう1つはECMの専門家集団として、です。

イージフのコンサルティングとBPMS

弊社の技術系ではないコンサルティングのチームは、その多くが「業務改善」のプロジェクトで活躍しています。技術系のチームがOSSという旗印があるのに比べて、今ひとつ対外的にアピールしきれていませんが、こちらのチームに関しても特徴を持ったサービス作りを心がけています。（でないと、大手ファームと比較されると純粋に劣化版に見えてしまいますし、そう見られた状態でのコンサルティングは非常な困難を伴いますし）

具体例を挙げずに説明するのが難しいところではありますが、ビジネス環境の変化（商材や販路の追加・変更）が激しかったり、例外処理が多すぎてキーマンの判断依存の案件が山積みになっているような、IT視点でみて「成熟度が低い」修羅場にあえて踏み込んでいく、という経験は他社と比べても結構豊富なのではないかと思います。

こうしたケースでは、業務を効率化するための検討や判断にもキーマンの参画が必要になりますが、その人達の時間がすでに大幅に不足して限界状態にある、というのがスタート時点の前提条件であったりするわけです。そこで、改善に入る前に、弊社のメンバーが現場に入り込んで業務執行のレベルまで手を動かし、通常業務（とはいえ例外処理は多数含まれますが）の負荷を減らしてスペースを作り、そこから徐々に改善に入る、なんてことをやったりします。

このあたりのノウハウが形成された経緯としては、弊社が起業時点では平均年齢20代の若い会社だったということや、当時は内部統制ブームで各社とも業務執行の現場への負担を増やさざるを得ず、その追加分に関しては抽象化された業務プロセスの知識を持ったメンバーの価値を発揮しやすかった、ということがあると思います。いずれにしても、業務執行のレベルからお手伝いをする、そしてそのことの身の証を立てるために作業品質の向上を可視化してレポートできる状態をキープしていく、というスタイルには自信を持っています。

Questetraはクラウドサービスであり、ユーザ企業側が自発的に使いこなした時にその真価が発揮される、という面は確かにあると思います。コンサルなんかに頼っていては駄目なんじゃないの？ っていうことですね。そういう意味では、単に業務フローのお絵かき代行という意味でのコンサルティングサービスには、あまり大きなビジネスチャンスも無く、やりがいに溢れたお仕事でもなさそうな気がします。

しかし、上記の通り業務改善に関する限り、弊社のサービスは業務執行のレベルまで踏み込んで関与し、徐々に改善に向かっていくというスタイルが基本ですので、単なる代行ではないことができるのではないかと思います。また、我々にとっての生命線である「業務品質の向上分の可視化」についてもBPMSは強力な武器になるのではないかと期待しています。

このあたりは具体的な（公表できる！）事例が出てきた際にまた突っ込んでご紹介させて頂ければと思います。

ECMとBPM

思いの外前段が長くなっちゃいました。どうしよう。

こっちはリクエストがあったらまた日をおいてゆっくり考えることにして、今は考えていることを簡単に箇条書きするだけですませたいと思います。

• 単純なワークフローシステムとBPMSの違いは文書管理ソフトとECMのそれに似ている


• BPMSによるトークン管理の（ある種抽象的な）価値はECMによるコンテンツ単位のアクセス制御のそれに似ている


• CMISにはワークフローの規定がなく、弊社のNemakiWareにも該当機能がないのでQuestetraとの連携に期待している


• （ECM上のチェックアウトって該当ユーザが「球を持っている」状態を作ってるよね？ システム的に上手くマッピングされてる例をみたことないけど）

って感じです。

（文責 Ishii Akinori IT-Coordinator）

JIIMAのECM委員会で委員長をやらせて頂くことになりました

2ヶ月以上ぶりです。この所、社長の方が結構頑張ってコンスタントに記事をあげている感じなので、一段と心苦しい限りです。

さて、以前から予告めいたお話はそこかしこでさせて頂いておりましたが、今月から、公益社団法人 日本文書情報マネジメント協会JIIMAのECM委員会の委員長を務めさせて頂くことになりました。中学時代以来の委員長ポジションです。

JIIMAには幾つか委員会があるのですが、ECM委員会はその中でも「ナレッジ系」と言われる系統に属しています。資格試験やセミナーイベントなどの事業運営とは異なる、知識の収集整理と普及啓発を目的とした組織です。

これまで委員会を引っ張ってきた前任の方が初代委員長で（どこまで細かい情報を出していいのか判断が難しいので、少しぼかしますが）、EDMSと呼ばれていたころのECM製品を日本に最初に持ってきた人達の中の1人にあたります。まさに国内のECM市場を作ってきた人達なわけです。JIIMAは元々マイクロフィルムを扱う人達の業界団体で、ついこの間まで日本画像情報マネジメント協会という名前でしたし、マイクロフィルムからスキャナベースのイメージングという「紙の電子化」を経て、その上でECMに取り組んできた経緯があります。

対する2代目の私は、社会人キャリアのほぼ最初の時点からECM製品を取り扱ってきました。言わば、ECMネイティヴな世代と言えるかもしれません。年齢的にも結構な若返り人事ではありますし、伝統的なバックグラウンドに欠ける面があるという不安もあります。しかし、折角のチャンスですし、国内でのECMのさらなる普及とより一層の利活用を目指して頑張っていきたいと思います。

告知 大事なお知らせ

別に委員長になったからということではなく、これまでも委員として積極的にアピールしなければならなかった話ではあるんですが、今月JIIMA最大の恒例イベントであるeドキュメントJAPANが開催されます。我々ECM委員会が絡む企画として、2日目である16日に、これまた恒例のECMサミットを予定しています。皆さん是非お越し下さい！

ECMサミットは、主要ECMベンダさんが呉越同舟的に一堂に会して共通したテーマでプレゼンを行ってくれる珍しいタイプのセミナー企画で、今回で第10回目になります。同一カテゴリのソフトウェア製品のプレゼンを連続聴講するという経験は、他ではなかなかないことだと思います。ECMそのものずばりに関心がなくても、業務アプリケーション分野に携わる方であれば、面白いと感じて頂けるのではないかと思います。（各社が同じ事を言っているように見えるのか、それとも全然異なる戦略を取っているように見えるのか、そしてその印象を有無原因は何なのか、なんていうのは割と一般的な関心時だと思うので）

...本当は、これまでの委員会活動で色々なことを教えて頂いた尊敬すべき諸先輩についてのお話もしたかったんですが、変に湿っぽくなるか、単なるガジェット好き集団だと誤解されるか、のどちらかである気がして仕方が無いので、断腸の思いで割愛したいと思います。

皆様今後ともよろしくお願い致します。

（文責 Ishii Akinori IT-Coordinator）

文書・コンテンツ・ファイル 半構造データ（XML）とCCMS

最近、自社関連の各Blogが、書き出し部分にスマートに近況報告的な世間話を混ぜ込んでいくスタイルに収斂しつつあることに危機感を感じています。

前回の、補足でもあるのですが、ECMはファイルが基本の管理単位になります。従って、図面管理においても物理的には1ファイルにまとめてある中で「特定のページをめがけたリンクを埋め込みたい」、というニーズがある場合は、そのまま適用するのは難しくなります。（例えば1ページ毎のレンディション（PDF版）を別途作成し、そちらを参照させる、などのテクニックはありますが）

今回は、ファイルが主役である、という特性を改めてご説明した上で、CCMS（Component Content Management System） コンポーネント・コンテンツ・マネジメントシステムというコンセプトについてもご紹介したいと思います。

ECMの基本とする管理単位が「ファイル」であるということ

あちこちの講演でも繰り返しご紹介していますが、ECMはかつてはEDMS、電子的文書管理システムといわれたコンセプトの後継にあたります。時期としてはおおよそ2000年あたりにこのキーワードの交代劇が発生しました。なぜ、文書（Document）をコンテンツ（Contents）と読み替えることになったのでしょうか？

1つには、Webに代表されるインターネット技術の台頭があります。HTMLで記述される「ページ」は、その呼び名とは裏腹にあえて再現性の低い印刷工程を通さないと「頁」もなく、文書という従来からある言い回しに収まらないインパクトを持つものでした。また、技術的にも、体裁情報を定義したスタイルシートや画像ファイルなど複数の「ファイル」によって構成されていますし、特定のポイントを指さすリンク構造も持っています。そのため、当時はWebページを管理するためのコンテンツ管理システム、WCM（Web Content Management）の製品が多数出荷されました。このジャンルは後にPHPベースのシンプルで安価な製品群が席巻し、カジュアルにCMS（Content Management System） コンテンツ管理システムと言った場合、一般的にはECMの様な文書管理ではなくこれらのWebコンテンツの管理システムを指すようになっています。

2000年代においては、EDMSから進化したECM製品もWebコンテンツの管理機能を取り込もうとしていましたし、Javaで構築されたような重厚なWCM製品もECM的な文書管理やワークフロー、コラボレーション機能などを製品に取り込む努力をしていました。例えば、2005年に立ち上がったAlfrescoにおいても、WCMモジュールが後から追加されています。この時は、「重厚なWCM製品」の代表格であったInterwovenのチームのエンジニアを引き抜いて、かなり大がかりなフォルダ仮想化技術を実装していました。これは素晴らしい機構でしたが、ここでお話しているようにECMがファイルを基本単位としている一方でWebコンテンツはその枠組みに収まらないというギャップがあり、Alfrescoの内部構造に異なる2つのリポジトリエンジンを抱える構造を余儀なくされていました。結果、数年後彼らはこの重厚な仕組みを放棄して軽量なWebページ作成機能を別途開発します。そしてさらに、現在ではWebサイト側にもそれなりに複雑な要件があるケースではDrupalなどのPHPベースのCMSを別途立ててインテグレーションしたり、Liferayを並立させたりする構造が一般的になっています。

それだけ何を基本の管理単位としてシステムを設計するのか、というのは大きな問題であるということだと思います。

ワンソースマルチユース

全社的にECMが導入された場合、所謂コンテンツ・文書・非構造データについても、ワンファクト・ワンプレイスが実現します。冗長なコピーを作る必要がなく、漏洩の恐れもなく、必要な時に必要な人に必要なコンテンツへのアクセスを提供できます。（かなりの理想論ですが）

一つの文書が、色々な目的で使い回されることになります。

ワンソースマルチユースというキーワードがありますが、これはここでいうような「複数の業務プロセスや部門から横断的に同一のコンテンツが利用可能になる」というのとは少し違うニュアンスを持った言葉です。具体的には、コンテンツの意味内容をXMLなどのプレーンな形式で管理し、体裁情報をスタイルシートとして別管理しておけば、印刷用、Webページ用、ダイジェスト出力用、など同一の内容で体裁が異なる出力結果を得られる、という状態を指しています。これにより、意味内容に変更があった場合は1カ所だけ修正すれば、すべての出力結果にその修正を反映させることができるようになるわけです。

弊社の取り扱い製品のラインナップの中では、Alfresco上にDITAというXML標準を扱う機能を実装したComponizeが、このワンソースマルチユースを実現するための仕組みになります。

DITAの詳細の説明はここでは省きますが、トピックという単位で意味内容を表現した（主にテキストの）部品をなるべく文脈に依存しない形で構成し、マップという単位でそれらのトピックの構造をまとめあげ（目次を定義して、どの順番でトピックを並べるのか、を決めてあげます）、そこにスタイルシートを適用して体裁情報を加えた出力結果を得る、という仕組みです。意味と体裁、ではなく、意味の断片と構造と体裁、を独立したコンポーネントとして管理するわけです。

これらの管理をシステム的にサポートするのが、CCMS コンポーネント・コンテンツ・マネジメントです。この仕組みでは最終的には1つのファイルとして提供されるマニュアルの中の特定の箇所をめがけてリンクをはったり、そこを書き換えたりということも可能になるわけです。

CCMSではファイルが基本単位になっていない？（＝ECMとは相性が悪い？）

DITAはXMLの規格ですから、通常ECMが扱うような文書ファイル、Word Excel Powerpoint PDF、の類いに比べてHTMLやWebページに近い技術です。そう考えると、ECMによるWCMの取り込みが失敗に終わった歴史を振り返るに、Alfresco上にDITAコンテンツの管理機能を実装するというComponizeの取り組みは一見筋が悪いものにも見えてきそうです。

しかし、私はこれは非常に洗練された仕組みだと考えています。つまり、出力結果の1ファイルに主眼を置いてしまうと、その構成要素は複雑に絡み合う複数の部品となり、ECMが苦手とする領域に踏み込んでいるように見えますが、通常直接編集を行う個別のトピックを定義するファイルに注目して考えた場合は、依然として1ファイルが基本の単位になっているからです。

AlfrescoもECM製品として十分な「ファイル同士の」関連付け機能を備えていますので（残念ながら基本のUIからはその機能は見えづらいのですが、内部機構には強力な仕組みがあります）、どのトピックがどの出力結果に利用されているか、などの情報はファイルを基本単位としたまま適切に管理されています。

これらはDITAという標準規格がしっかりと定義されていて、わざわざ関連付けまで含めた管理機構を実装するに足るメリットがあるからこそ実現している仕組みであるとも言えるでしょう。

DITA/CCMSのメリットや必要性

残念ながらこれでワンソースマルチユースの洗練された管理機構を実現できるのはDITAが対象としているようなマニュアルや仕様書などのテクニカルドキュメントだけですが、その導入メリットは非常に高いものであると考えられます。

もちろん、管理の仕組みが大きく変わるだけでなく文書の作成方法も従来通りとは行かないため学習コストは相対的に高くなりますし、いかにDITAが洗練された規格であったとしても、既存の規格を知らずに作成されたコンテンツをその枠組みに押し込むには難しい判断を求められるケースも多くなります。（最近では、規格自体のアップデートなどもあり得るので、その動向に目配せをしながら判断した方がより望ましい、なんていう面もあります）

それでも、最終的なコンテンツの管理コストを下げ、陳腐化したコンテンツが滞留しないようにしていくことのメリットは非常に大きいはずです。未だ多くの企業においてはコンテンツの整備は製品・サービスそのものの提供と比べると副二次的なものであるという扱いを受け、管理人員が十分に提供されない状況があります。製品・サービスそのものと違い、コンテンツは何もしなければ堆積していきます。活用機会を失うだけでなく、誤った情報が残り続けることで、様々な領域で問題を生じる可能性があるわけです。

こうした観点から、広く技術系のコミュニケーションに問題意識を持っている方も徐々に増えているのではないかと思います。Componizeはクラウド上でのトライアルも可能な製品ですので、是非お気軽にお声がけを頂けると幸いです。

あー、また長文ポストになってしまった。一応、営業っぽいメッセージも入れたから許して欲しい、という業務メッセージを追加して、結びの挨拶とさせて頂きます。

（文責 Ishii Akinori IT-Coordinator）

文書管理と図面管理

最近、図面管理についてのご相談を頂くことが増えてきました。がっちりしたPLM（製品ライフサイクル管理）やPDM（製品データ管理）のコンセプトを実装した製品は複雑で高価、顧客にとって不要な機能を包含したものになりがちなため、文書管理ソフトウェアを使って図面を管理できないか、という着眼点からのお問い合わせ、というのがある種のパターンになりつつあります。

非常に大雑把なくくり方をすると、PLMをゴールとした場合のCAD図面の管理体制には以下の様な成熟度が考えられます。（図にするのであれば高い成熟度を上に持ってきたいところですが、Markdownで書いているので、ひとまず項番＝Lvという解釈で下へ行くほど成熟度が高くなります）

1. 図面ファイルを単なるファイルとして管理し、メールやファイルサーバで管理


2. ローカルではCADツール付属の図面管理機能で図面番号などの属性を管理


3. シンプルな図面管理ソフトウェアを使って共有


4. PDMツールを導入し、パーツ品番の管理や各種採番などもシステム化


5. PLMツールを導入し、関係各所とも一貫した情報管理を実施

紙図面を脱却し、パーツ情報の共有や生産情報などの基幹系システムとの連動を実現できるようなシステム的にユニークで一貫したIDの管理など、図面情報の高度化が希求されています。

IDの管理や図面全体に割り当てられるような図面番号や顧客名などの属性情報の管理などについては、まさしく文書管理やECMで行われていることと同じ機能が求められています。そのため、高価なPDMなどを導入しなくても当面必要な管理精度や検索の利便性などについては文書管理でもできそうだな、という印象を持たれる方も多いわけです。

しかし、パーツの管理や、パーツそのものに付加された属性まで管理しようとすると、なかなかに複雑になります。ECM製品であれば文書同士の関連情報を保持することも可能なので、サーバ内でパーツの図面と製品全体の図面を結びつけておくこと自体は可能ですが、CADファイルの中身を書き換える機能があるわけではないので、それを持ってパーツ側での仕様変更を製品図面に反映させる、などの機能を実現するのは無理があります。（せいぜい、パーツ図面の更新時に利用してる製品の一覧を表示するくらいでしょうか）

文書管理ソフトウェアやECM製品は、各文書の内部構造に踏み込んだ処理はあまり得意ではありません。

全文検索インデックスをつけるというのがこれらのツールにとって最も内部に踏み込んだ処理、と言っても良いかもしれません。もちろん、文書管理ツールで図面管理を考えておられる方が関心を持っている、プレビューやサムネイル作成の機能などもファイルの中身を使っての処理ですし、Excelの特定セルを読みこんで属性値として割り当てるとかPDFの属性情報を吸い上げるなんていう処理もありえます。しかし、これらの機能も、本体そのものはそのままの形で保持することを前提として、プレビュー用の補助ファイル（レンディションと呼びます）や属性値を周囲に配置することを目的としたもので、図面の内部へ変更を自動反映していくような位置づけのものではありません。

では、図面管理は専用のソフトウェアで行うべきであり、文書管理ソフトウェアやECM製品を無理矢理適用するのは間違っているのでしょうか？　

（例によって議論の幅が拡がり過ぎてしまいそうなので、ここから先は文書管理ソフトウェアというよりはECM製品を前提に続けたいと思います。弊社には文書管理ソフトウェア並に低価格なECM製品もありますし！）

図面管理分野でECMが活躍する局面

上述したPLMを頂点とした図面管理は、製品を設計し、材料を調達、製造して、販売し、（場合によっては）保守をする、というストレートな製品出荷を前提としています。そして、製品の種類が多ければ多いほど、効果が大きいと予想されます。また、どちらかといえば製品のライフサイクルが短く、どんどん新しいものを出荷する、というスタイルに向いているとも言えるのではないでしょうか。

しかし、製造業にも色々なスタイルがあります。例えば、私の実家は天井クレーンの製造販売を行っていますが、基本的には個別受注生産で、どの案件にどのパーツを使ったのかという情報は必要ですが、そのパーツも他社からの購入品であるため個別に図面を管理したりはしていません。では、図面管理の必要が無いかと言えばそんなことはありません。顧客毎、案件毎の管理をロングスパンで行う必要があります。クレーンは何年も使い続ける装置ですので、初期設置時はなかった安全装置を後で取り付けたり、古くなった部品を新しいものと交換する際に従来の部品が手に入らず新しい互換品を採用したり（あるいは互換品がなくて修正工事を行ったり）ということをしていきます。これらの情報が散逸してしまっては都合が悪いわけです。

もっと大きなビジネスをしている製造業でも、標準品の図面管理と、案件毎のカスタマイズによる施工図面を二重に管理せざるを得ないケースはたくさんあると思います。図面の内部に踏み込んでCADの内部で扱えるパーツ間の関係などにフォーカスするのではなく、図面の外にある（あるいは業務的な意味で設計の外にある）情報とのリンクを取り扱いたいのであれば、ECM製品を利用する意味合いが出てきます。

非常に大雑把なまとめ方をすると、製品と部品の関係をメインで取り扱いたいのであれば図面管理、製品と案件（工事）などの関係に着目する必要があるのであればECM製品を検討するのが良いのではないかと思います。

実際には他にも色々なケースが考えられますし、そういった事例もいくつか持っていますので、ご関心をお持ちの方はお気軽にお声がけ頂けると幸いです！

（文責 Ishii Akinori IT-Coordinator）

エンジニアの仕事環境と『小さな成功』のはなし

パートナーさんとの合宿のために軽井沢に向かっています。新幹線も空いているのでこれ見よがしにMacを広げたところです。

普段ならTwitterに書き散らすようなネタなのですが、うまいこと140文字に収まりそうにないので、こっちの自由記述欄に。

個人的には「ネット」という言い回し自体あまり好きではないのですが、TVや新聞ではなく基本的な情報収集の手段がインターネットになり、アグリゲートされた後の記事をナナメ読むことが多いので、私自身はかなりネット寄りな情報や論調に偏ったポジションにいる、という自覚はあります。その中で、これも嫌らしい単語だと思うのですがリテラシーという面では上級職扱いのIT業界の住人でもあります。自戒を込めて言うのであれば、そういう人種はやはり進歩的であったり、欧米的な価値観に寄り添った立ち場から社会を見ているような印象があります。その例の一つ、「（日本は）もっと失敗を許す社会であるべき」という意見について、少し思い付いたことがあります。

まず、私自身はこの意見に対して、どちらかというと賛成、くらいのスタンスです。言っている内容に妥当性を感じるが、殊更自分が声を上げて現状を否定するほどのものでもないし、なるようになるんじゃないか、という位の温度感です。（現状それなりに恵まれた環境で仕事をさせてもらっていることと、独立だの起業だのというリスクを一応は取っているということのバランス、がこのあたりに落ちてきています）

また前置きが長くなってきています。

（IT業界の）エンジニアは人から見えないところで小さな失敗と成功を繰り返せる環境を持っているので、ある種成熟した視点を会得しやすい

という仮説を考えました。

システム開発、特にコーディング部分に関わることのない人には本当に何を言ってるのかわからないと思うので、少し細かく説明します。（単純に私が注意力散漫とうこともあると思いますが、）通常、最初に書いたプログラムというのは上手く動きません。上手く、どころか、まず動かないことの方が多いくらいかもしれません。で、機械にだめ出しをされ、修正をし、どうにか動いてくれるのを確認、でも結果が想定と違うのでまた修正、そうするとまた動かなくなって、、、というのを本当に細かいレベルで繰り返します。

実際、こんなに頻繁にネガティブなフィードバックに晒される職種は珍しいんじゃないかと思います。ただ、あまりにも些細なものであり、相手が機械であるという点で、心理的なダメージは非常に小さくなっています。（ここに人間味があるネガティブコメントが付加されると一気に耐えきれなくなる、というのは感覚的にはあり得そうな話で、業界にメンタルを損なう人が多いことの数多い原因の一つだったりするのかもしれません）

一方で、そういう作業が上手く意図通りに行った場合の小さな達成感というのも当然あります。顧客に何らかの変革を強いる、いわゆるコンサルティングの仕事では、「小さな成功（win）」を顧客に感じてもらうことがプロジェクト全体の成功を握る鍵である、というような話がよくされるんですが、まさに「小さな成功」です。

つまり、多くの失敗と、そこそこの頻度で訪れる小さな成功、というサイクルで仕事を回しているエンジニアは、「失敗の許容」という冒頭の大人な意見に同調しやすくなってるんじゃないか、と。

Railsのブームの出始めあたりに、生産性に絡む評価として、個々のエンジニアが「俺すげー」って思えるポイントをチラしてある感じが憎い、みたいな視点があったような気がします。（ソースとなる記事がないかなと思いましたが、それらしいものはうまく見つけられませんでした）。最近だとVagrantとかChef/Puppet/AnsibleとかDocker界隈の技術にも似たような受け止められ方をされてる部分があるように思います。

やっぱり思ったより長くなってしまったので、さっさとまとめると、そういう個々人の体感の部分で「小さな成功」や高い生産性を感じさせてくれるツールが受けているということなのだとしたら、それをエンジニアだけでなくナレッジワーカー全体に適用するような工夫ができると楽しそうだな、と。細かいアイディアは幾つかあるので、実現しそうになったらまたご紹介します。

（文責 Ishii Akinori IT-Coordinator）

シンコム・システムズ・ジャパン、ECM分野でイージフと協業

シンコム・システムズ・ジャパン、ECM分野でイージフと協業 - シンコム・システムズ・ジャパン株式会社のプレスリリース: "このCMISコネクターはイージフが既に開発していたオープンソースECM製品であるNemakiWareをフォーク（分岐・独立して開発）したものである。"

少し前に、次はECMネタで、と書いた時に想定していたのはこのネタでした。色々あってプレスリリースの公開が昨日になったため、タイミングがずれちゃいました。

シンコムさんとは数年前からのお付き合いではあるんですが、今回は、独自のECM製品にCMIS互換のコネクタを増設するにあたってご協力させて頂きました。CMIS関連の知見を実際に役立てることができたというのが、一つ大きな達成感のあるところです。これからも、CMIS互換をうたう製品を増やしていく方向で動ければ、と考えています。

Cincom ECMはLiferayや各種CMSとの連携の事例も多いですし、タグやアソシエーション（コンテンツ同士の関連づけ）などの機能も使いやすい製品です。ベンダ独立の製品選定であれば、柔軟な価格体系・カスタマイズなしで使えるアソシエーションあたりがアピールポイントになるのではないかと思います。（例えば、Alfrescoの場合は協力な関連づけ機構を備えていますが、それを活用するためには設定ファイルやスクリプトをそれなりにちゃんと整備してあげなければならないので、エンジニアリング抜きでの展開は難しいという事情があります）

今回CMIS対応もかなったので、リポジトリにはCincom ECMを導入し、クライアントのところにCmisSyncを使うという具体的な連携も提案できるようになりました。このあたりの具体的な事例もどんどん紹介していきたいですね。

（文責 Ishii Akinori IT-Coordinator）

社内Bloggerイベント ベンチャーっぽい

といってもPC持ち込みでランチ一緒に行くだけなんですが、今日は少し余裕があることを見抜かれたのか、参加を求められたので付いてきました。

社長Blogやカリスママカロン先輩が率いるスタッフBlog（今日は先輩の担当日じゃないですけど）なんかの更新日が水曜日に集中しているのはこれが理由だったりします。以前は、aegif社員であることを明かした上でBlogを書いてる人達全員を対象に毎月抽選で景品を出したりもしていたんですが、今はやっていないのであがってる記事は物狙いではありません。いや、以前の投稿が物狙いだったわけでも、それで記事の質の低下があったわけでもないんですが、色んな制度を作っては壊して色々試してみるのもベンチャーの愉しみの1つってことなんだと思います。

そう言えば、この間の超交流会でも思ったんですが、自分達がやってることってベンチャーという言葉に相応しいものなんだろうか、という悩みというか後ろめたさみたいなものをここ数年抱えています。なんというか、一攫千金を狙ってガツガツとした行動力があるわけでもないし、どっかからお金を引っ張って一気にイノベーションを巻き起こそうっていう使命感のようなものを前面に押し出したりもしていませんし、「ベンチャー楽しいよ・成長できるよ」的な話題の時には結構深刻に身の置き場に困ります。行くところに行けば、そもそもベンチャーで9期目っていうだけで残念感が漂ってくるんじゃないか、という恐れもあります。

ガツガツしたところに欠けるのはパーソナリティ的にもしかたがないとしても、野心のようなものはそれなりにあります。

一つには、最近の言い回しでいうと働き方の選択肢を増やす、という感じになるんでしょうか。私自身は、何度か話に出していますが、「多少はプログラミングなんかもできないことはない新人」として外資系のコンサルティングファームに就職し、どうやら「開発スキルがあるほど単価も給料も安い」らしい、ということを実感してキャリアを考え直したという経緯があるので、その辺りの矛盾をどうにかしたいという気持ちは結構真剣に持っています。

これで当時の上司や先輩とまったく話が噛み合わなくて辞めた、ということであれば話はある意味でクリアになるところだと思いますが、実態はそうでもありません。高水準のスキルや知見を持ってる人達が確かにそこにはいて、（すべてのケースではないにしても）多くの場合それを必要とするクライアントのために活躍している姿を見てきました。でも、工程における上流下流の切り分けだとか、多重請負とか、本来的に正しいことをしているようには感じられなかったのも事実です。思えば、常に自分達の働き方が「必要悪」であることを確認しながら生きていた気がします。

この辺りはBlogで語るのは差し障りがある気がするので、一度中断しますね。落ち着いた状態で、ちゃんと扱ってみたいテーマでもあるんですが。

もう一つには、やはりECMの国内展開です。米国でもヨーロッパでも、アジアの新興国でもよく使われているのに、何故か日本では導入が進まない。理由はたくさん考えられますし、あちこちでお話もしているので、ここでは今どんなことを考えているかだけ、さらっと書いて今日の記事を閉じたいと思います。

まず、低価格でカスタマイズが負の遺産になりづらい技術要素を提供する。Alfrescoもそうでしたが自社製品のNemakiWareはCMIS互換リポジトリの低価格域での選択肢を増やすという点で意味があると信じています。次に、ECMベースのシステム構築の理論的な正しさを訴える。これはIT資産価値研究会などに混ぜてもらってアカデミックな方面で活躍している方々と相談しながら進めています。まだまだ入り口に立っただけで成果をお見せできるとこまで辿り着いていませんが、是非何かの形にまとめるところまでは行きたいと思っています。最後は、JIIMAの活動や各種セミナなどを通しての普及啓発（大上段な言い回しに過ぎるかもしれませんが）の活動を続けていく、というものです。ここ2年のAIIMカンファレンスへの出席には個人的にも手応えを感じていますし、ECM委員の皆さんは本当に勉強になる話を色々と教えてくださるので、まだまだやれることがありそうです。

もうちょっと、単発の技術ネタでまとまりの良い記事を書かないと、ぐだり状態を脱却できない気がしてきました。Dockerだな、Docker。

（文責 Ishii Akinori IT-Coordinator）

超交流会、行ってきました

ベンチャーやるなら「企業向け」でヨロ！ - 京大情報学同窓会 超交流サイト: "このセッションでは、エンタープライズITのポテンシャルとオモロさについて、事例をおりまぜながら、コテコテに議論してみたい。"

母校の同窓会イベントに初参加してきました。

と言っても、我が母校は宿命的に権威的なものに冷淡というか、標準では群れることを良しとしていないというか、社交性のある人間が多数派を占めていないというか、なかなかに難しい環境だということもあってか、このイベントは参加者（出展側も含めて！）に同窓生や関係者であることをまったく求めていないという極端な仕様になっています。

実際、この形式を導入する前の同窓会は、閑古鳥が鳴いてるどころではなかったらしいです。2001年卒業の私が2期生の若い組織だってこともあるんだとは思いますが。

で、第6回目の今回、一般参加を飛び越えて登壇者として初参戦してきました。交流なんて柄ではないんですが（書いてるそばから直流の対義語にしか見えない）、結果としては非常に面白く、刺激になりました。勢いあまって、移民受入論の後押しをしはじめそうなくらいです。「単体での発展性に限界を感じているが、独自性には一定の自信を持っている集団が、外の血を入れて活性化」してる感じです。（移民の話で血という表現は生々しい気もしますが、あくまで慣用句です）

まずは前夜祭

今回、中心人物であるクエステトラの今村さんにお声がけ頂いた関係で「登壇者」扱いだったということもあり、前夜祭と銘打った前日の飲み会からまず潜入してきました。個人的にはまずこれが良かった。交流会で名刺交換とか本当に苦手なので、ゆっくり座って喋ることができる環境で顔見知りを増やしていくことができたのには本当に助けられました。

席も元同期や現在の仕事仲間を共通の知人とする人達に囲まれる感じで、これが同窓の良さかと勝手に追い風を感じていました。よく考えなくても元同期は京大関係ないんですけどね。

前夜祭でお話してくださった皆さん、本当にありがとうございました。おかげで相当気持ちがほぐれました。

ブース出展

一応僕も副社長でビジネスを背負っている訳ですから、会社案内と自社製品ポスター＆パンフレットによるブース出展なんかにもチャレンジしたんですが、これはちょっとイマイチだったかもしれません。登壇中は放置ですし、他の面白い話もなかなか聞けにいけないので。

協賛はしたいし、そこで学生さんをはじめとした色んな人を捕まえてアピール、ってのも大事だと思うので、ブースを出すこと自体が間違ってるということはないと思うんですが...

そして登壇

冒頭のリンク先を見て頂ければ一目瞭然ですが、何故か有名人・実力者揃いのメンバーにどう考えても場違いなのが混じり込んだ感じ…

正直なこと言うと、かなり不安で憂鬱な感じだったんですが、結果としてはかなり良いセッションになったんじゃないかと思ってます。（実際は、聞いて下さった方々の感想を聞かないと分からないですけどね）

始まる前は、
* 就職氷河期以降を代表して年長者に噛みつく
* コミュニケーション弱者を代表して「個人客が怖いからBtoCはやらない」と喧伝する
* ひたすら追従して聞き手代表みたいな顔をする

などの姑息な作戦をいくつか脳裏でもてあそんでいたんですが、そんな面倒なことをする必要はありませんでした。（し、その余裕もなさそうでした。そもそも白髪が増えてますます年齢不詳な感じになっているので、私だけが年齢的に下っ端というのもどこまで共有されていたかわかったものではないらしいです）

内容は多岐にわたったので、なかなかまとめられませんが、米国でのエンタープライズ向けソフトウェア市場の活発な動きや、ベンチャービジネスという意味でのコンシューマ向け市場の行き詰まり感の話と、日本にもまだまだチャンスが眠っているという感覚の共有などは、聞く人が聞けば結構意義のある話になっていたような気がします。

しかし、ウルトラマンのお面は出てくるわ、バックに見知らぬ資料が大写しになるわで、本当に冷や冷やしましたが、よくあそこまで綺麗に話が進行したものだと思います。大人凄い。

そう言えば、直後に頂いた感想に、「面白かったです。でも、学生さん、聞いてわかるんでしょうか…」というのがありました。確かに！ と思い、もう少し親切な表現もあったかな、と若干反省もしましたが、こういう話を聞き流すだけ聞き流しておくのも悪くない気もします。

最後に自分が学生の頃聞き流していた話など

京大に入学してすぐ、教授会主催かなにかのレクリエーション＆懇親会のような席である先生が、「東京という政治の中心から距離をおいているので、京都には物を考える上でも独特の環境がある。それが東大との違いだ」というような話をされました。

私は関東出身ですし、メディアも発達した現代社会でこの程度の「距離」に意味があるとは思えませんでしたし、狭い国土の中で無用に東大を意識しているようで何となく興の冷める挨拶だな、とその時はこの挨拶にはあまり良い印象を抱きませんでした。

その後、関東に戻り、東京でのビジネス経験を十数年積み、少し考え方が変わってきたのを感じます。どんなコミュニティにも独自性や慣性のようなものがある。技術で距離を乗り越えても、そんなに簡単に均質化されるものではない。また、そこに何かのチャンスがあると考えるのは自然なことだと思います。

ただ、チャンスというだけあって、この独自性の活用、のような話は説明がとても難しい。例えば、最近は国力の衰えからか「実は凄い日本人」的なメッセージが乱発されていて、個人的には正直言って食傷気味なところがあります。でも、その多くは個別に見ていくと、「日本人」なんていう大雑把な繰りで損なわれた自信を取り戻したいというステレオタイプで暗い欲望などではなく、本当にそれまで光があたらなかったものに対するリスペクトから出発していることがわかったりします。

交流に対して腰を持ち上げるのに6年もかかった非社交派としては、このあたりの行き違いを摺り合わせて、コミュニティの影響力が外に大きく作用させられるようなお手伝いができるといいな、と感じました。

例によって最後が抽象的な話でぐだりましたが、とりあえず、ご報告まで。

（文責 Ishii Akinori IT-Coordinator）

aegif Labo Blog: CmisSync for Macのベータ版をリリースしました

aegif Labo Blog: CmisSync for Macのベータ版をリリースしました: "CmisSync for Macのベータ版をリリースしました"

自社関連Blogでは皆言及しているのに私だけ何もしない、というのも肩身が狭いので。

自社製品である同期ツールCmisSyncのMac OSX版をβ版がリリースされました。クラウドストレージのような利便性を社内の文書管理サーバを対象にフォルダ同期を行うことで実現しようというツールです。

作業環境としてはMacを使っているけど社内情報共有はSharepoint、というケースにも対応できるということで、公開前から度々お問い合わせを頂いていたものになります。嵌まりそうな環境をご存じの方は是非ご紹介ください。

（文責 Ishii Akinori IT-Coordinator）

ECMサミット2014/MAYに登壇しました

ECMポータル　：　ダウンロード: "ECMサミット2014/MAY（2014年5月28日開催、JIIMA東京セミナーA5セッション）"

先週28日にJIIMAセミナーでお話をさせて頂いた内容を少し補足したいと思います。

基本的には、4月のAIIMカンファレンスの報告なので、
* 情報カオスというキーワードがでてきたこと
* そのソリューションの1つとして情報ガバナンスが位置づけられていそうなこと
* 言い換えると、圧倒的な情報の「量」に対して戦い方の工夫が求められている、ということ

というのがメインのメッセージではあったのですが、その背景を理解するためのキーワードとして、SoE システムオブエンゲージメントについても、お話しました。

性格的に、マーケティング目的で薔薇色の言説のみを積み上げることができないので、やや露悪的な表現を使ってしまったため、結果的に飲み込みづらいお話になってしまったのではないかと反省し、（どれだけの人が見て頂けるか不明ですが）ここにも補足の記事を上げておこうと考えました。

SoEは通常、従来型のSoR システムオブレコードとの比較で、無機質な記録（業務上の数値・事実など）の取り扱いを主目的とせず、有機的な人と人との繋がりを活性化するようなシステム、例えば社内SNSやコラボレーションツールのようなもの、と説明されます。要するに、これからはソーシャル・モバイル・クラウド（・ビッグデータ）だ！と言い募るための語彙でもあるわけです。ただ、個人的にはこれを単なるバズワードだといって流してしまうのはもったいない、と考えている部分もあります。講演では少しでもその部分を掬い上げたいと考えました。

その結果として盛り込んだ発言が、
1. エンゲージとは「歯車」のかみ合いである
2. 技術トレンドは分散/集中など振り子の様に移り変わる、システム/人の間の振り子が今「人」側に振れてきている
3. SoRとSoEは従来から言われている基幹系と情報系という表現とかなりの部分で被る（が、少しだけニュアンスが異なる点もある）

の3つです。今振り返っても、いきなり何を言い出すんだ、という感じですね。

まず、1.の「歯車」について

「エンゲージメント」という言葉自体はビジネスの世界でも結構前から使われています。主に人事のジャンルになるんではないかと思います。うちの社長もエンゲージメントのフレームワークを全社ミーティングでの発表で参照したりもしていました。ただ、やはり日本語としてはどうしても「婚約」という訳語が一般的ですし、人事の話も基本的には愛社精神と言いますか、愛着心をテーマとしています（満足度ではなく愛着心、が新しい点であったと思います）。

愛着心があった方が、色々なことがうまくいく。ガイ・カワサキさんの「聴衆を魅了する方法」の第一が好感を持たれることであったことにも通じますし、好きこそ物の上手なれ、という言葉もあります。なので、素直に愛着心の話と受け取ってもいいところなのですが、私自身の趣味としてはもう少し工学的に理解したい。

原語のEngagementには歯車の噛み合わせという意味があります。（壁に柱を埋め込むのもengageだったような気もします）。SoEという言い方で、新たなシステム投資を提唱する際、そこにあるのは漠然とした「皆、もっと会社（仕事）を好きになろう」というスローガンのようなものではなく、「個人の力を引き出し、方向性を揃えて組織の目的にそった出力を最大化していく」というような積極的なイメージがあるのではないか、ということを考えています。

次に、2.の「人/システム」について

技術トレンドには振り子のような性質があると言われます。メインフレームという「集中」アーキテクチャから、ダウンサイジングブームを経て「分散」へ、そして今（細かい技術要素としてはそれこそ分散、と言いたいところもありますが）再び企業をまたがってのより大規模な「集中」であるクラウドコンピューティングの時代がきています。

企業における業務効率化の関心時も同じような振り子的性質を持っていると考えられないでしょうか。元々は「人」がマニュアルでやっていた仕事を、技能の育成や仕事の仕方の工夫で効率を高めていた。情報技術がやってきて簡単に置き変えられるところかどんどん「システム」がその仕事を代替するようになっていく。「システム」が十分に複雑になると、今度はその中での多重投資や相互依存による非効率が問題になり、システムを「より良いシステム」で置き変えることで効率をあげることができるようになった。これはある意味で情報技術のみで完結できる仕事で、まさにSIビジネスという市場が成立した背景であると思います。

そして、そういった「システム」の世界に閉じた改善、バージョンアップだけでは十分な効果が出ない、とされる時代がきました。

そこで、今度は「人」の領域に改善余地を求めて、矛先を向けているのが、SoRからSoEへの転換と言えるのではないか。皆でモチベーション高めて一致団結していこう、というポジティブメッセージも嘘ではありませんが、個々のメンバーの能力を効率良く活用（悪く言えば、絞りとって）具体的な成果に結びつけよう、という非常に冷静なビジネス方針という面もあると考えています。

（コスト削減には限界があるので、売上を上げる方に目を向けていこう、というよくあるお話に近い、と言いますか）

最後に、「基幹系/情報系」について

SoEは、一般的な意味でいう基幹系システムではありません。従って、実際のIT投資判断の現場では、情報系の一部あるいは亜種として扱われるのが実態だと思いますし、その事は特に問題ではありません。では、なぜわざわざ新しい言葉を使いたがるのか。

1つにはマーケティング的に新しいメッセージを出していかないと注目を得られないという、商売上の都合、が間違いなくあるでしょう。もう1つには、上に書いたような、より「人」に注目することが効果を高めるという信念があると思います。そして、そのことによってフォーカスに若干の違いが生まれているのも確かです。

情報系、の主役の1つにDWH、BIあたりのソリューション群があります。実は、SoRという表現自体は元々DWHの世界から来ています。溜め込んだデータから、有意義な情報を取り出し、整理して活用しやすくするのが、これらのツールの主目的です。

ただ、SoEという言い方になると、SNSですとかコラボレーションツールの方が主役級の扱いを受けることになります。これらのツールは、（他所のシステムで生成されたデータなどを）整理するのではなく、直接雑多なデータをどんどん産み出していきます。データの発信源である、というのが、大きな違いであり、AIIMをして情報カオスという用語を作りださせた要因でもあります。

---

結局、長い間企業向けの情報システムの仕事をしていると、折角システムを作ってもユーザが使ってくれず「使われないシステム」として無駄扱いされる、という失敗体験が積み重なって行くので、facebookやtwitterでユーザが主体的に情報入力をしまくっている姿を目の当たりにすると、冷静ではいられなくなる、ということなのかもしれませんね。（私が、ということではなく、SoEを盛り上げていこうとしている人達の皆の心情という意味で）

（文責 Ishii Akinori IT-Coordinator）

Liferayがイージフ社を日本初のプラチナパートナーに認定 - All Liferay Press Releases | Liferay

Liferayがイージフ社を日本初のプラチナパートナーに認定 - All Liferay Press Releases | Liferay: "Liferayがイージフ社を日本初のプラチナパートナーに認定"

 

以前ほどではないですが、また少し間が空いてしまいました。もっと言うと、折角のニュースであるにも関わらず、即時の反応ができていませんでした。

それには少しだけ理由があります。このプラチナパートナー認定のためには認証資格を取得したエンジニアを一定数確保する必要があります。幸い、弊社のテクノロジーチームは非常に優秀なので、みないち早くこの試験を受験合格を決めていってくれたため今回の認定にこぎ着けたのですが、その過程で私にも「メンバーに受験を強制するならお前も受けろ」というミッション（？）が課せられてしまいました。で、ぐずぐずしているうちに他のメンバーが規定数をクリアしてしまったため、ますます受験へのモチベーションが失われ、忙しさを理由に今日まで逃げ回っていたわけです。

今日、いよいよその年貢の納め時が訪れまして、どうにか無事合格することができました。これで胸を張ってプラチナパートナー認定を喧伝することができます。

試験はなかなか実戦的といいますか技術的に細かいところを問う問題ばかりでした。Alfrescoの試験よりも私にとっては難易度が高かったように思います。（Alfrescoの方は当時は私は問題を考える側だったので公平な評価ではないんですが、弊社の両方の資格を持った人間も同意しているので、それなりに正しい評価なのではないかと）

Liferayはプラットフォームとしても非常に強力ですし、パッケージとカスタマイズのバランスをとってシステム投資をしていくという日本的（？）な課題に対しても大きな可能性を持った製品であると考えています。今後とも緊密なパートナーシップを維持していきたいですね。

（文責 Ishii Akinori IT-Coordinator）

JIIMAセミナー2014 登壇します

JIIMAセミナー2014 これからの経営が求めるクラウド・ビッグデータ時代の文書情報マネジメント～紙から電子の社会をめざして～: "ECMサミット2014/May　『米国におけるECM市場の潮流（ECM最新動向）』"

5月28日のJIIMAのイベントに参加します。AIIMカンファレンスの視察報告をさせて頂きます。

一応、ECMサミットとしての開催になっていまして、Hylandの新井さんや富士通総研の小林さんと日米のECM市場の違いについてパネルディスカッションといいますかインタビュー形式のコマにも参加させて頂く予定です。

ちゃんとやれるだろうか・・・

視察報告は色々と詰め込もうとすると破綻しますし、（私が考えるところの）キーとなる要素に絞り込むとあっというまに終わってしまう恐れも。

関心を持って頂いた方にはイベント後にフォローをさせてもらうのが良いような気もしますが、なかなかそこまで引っ張るような牽引力がないんですよね。色んな意味で。

頑張ります。

（文責 Ishii Akinori IT-Coordinator）

続々 ままならない話

　連休が間に入ったので自分でも何を書きたかったのか曖昧になってきた感がありますが、なんとか締めまでは持っていきたいです。

　OSSビジネスがもたらす経済合理性が事前の想像よりも大きかった、ということと、楽しい仕事をしたいですよね、という話をしかかって中断していたような記憶があります。ただ、読んでくれた人から個別に質問をもらったりもしたので、まずはそのフォローから。

マージンってなに？

　それこそ新人のころに、ベンチャーなどの勢いがある若い組織と、歴史のある組織の違いとして、個々のメンバーの仕事の守備範囲にフォーカスした記事を読みました。歴史の長い組織にいる人の方が「自分の仕事」を狭く評価する傾向があり、人と人の間にスキが生まれてしまう。そうした如何にも縦割りな、柔軟性のなさが組織の老朽化の典型的な弊害である、とかなんとか。「明確に自分に責任があると定められていること以外のこと」を実行に移して、もし失敗したらペナルティだけは間違いなく自分に降りかかる、という環境では人は保守的に振る舞わざるを得なくなります。

　自分の仕事はこれだけ、そこに含まれないものは他の人の仕事、という線引きができれば、対象に含まれる仕事の効率はもしかするとあがるかもしれませんし、働く人としてのストレスも少ないかもしれませんが、多くの場合より広い視座から見れば効率が悪いセクショナリズムに見えます。どこの部門の仕事の定義にも含まれないものが発生した場合に、非常に効率の悪い例外対応をすることになるとか、あるいは大した件数がない事象なのに専用の要員を要求されるとか、ってことですね。そういうものを前の記事ではざっくりとマージンと呼んでいました。

　なので、マージンを取り除く、というのは、ある意味では当事者にリスクを取ってもらうということでもありそうです。

OSSで取り除けるマージン

　前の記事では、開発元、SIサービス提供者、お客さんなどの特定の技術を顧客に届けるまでの直線的な取引／サービスの流れの中でのマージンの説明をしました。これについては、OSSコンサルティング事業を始める時点でも意識していた点です。「ソースが見せて貰えるなら（パートナーとして）もっと良い仕事ができる」ということですね。

　ただ、現実にこのジャンルの仕事をしてみると、例えばAlfrescoやLiferayなどの特定の製品だけでなく、直接パートナーシップを持っていない他のオープンソース技術との間の垣根の低さにも意味があるということに気がつきました。プロプライエタリの製品とのシステム連携を考えるとSDK評価版の入手であるとかNDAの締結であるとかっていうステップが間に入ります。とりあえず試してみる、ということがやりづらい。性格的なところも多分にあると思いますが、トライアルの申込みをしてしまうと相手先の営業さんにもプロスペクトとして認識されることになってしまう、というのもなんとなく心理的なハードルをあげます。どのくらい簡単にできるのかを実験したいのに、ちゃんとできないと申し訳ないような気がしてしまう、という。

　ことマージンという考え方からすれば、相手側の会社やコミュニティから連携部分の実装をしてもらって、そちらでメンテナンスまでしてもらえれば色々と楽にメリットだけ享受できる、という下心をお互いに持っていてもおかしくない状況でもあるわけです。それも含めてこっそり自由にやらせて欲しい。そういう仕事のしやすさ、というのは、後で成果にも跳ね返ってくるんじゃないかと思っています。

楽しい仕事をしたい

　自分達の技能を効率良く使って、できれば人から喜ばれる仕事をしたい。そう考えると、衛生要因扱いという、かSLAが高いところにあるビジネスはたとえ売上が上げやすかったとしても、今ひとつ気持ちがもりあがりません。例えばインフラのお仕事であればお客様からは使えて当然に見えているので、あまり喜んで貰える機会がないと予想されます。その場合は、効率を上げるツールを作るとか、っていう方向で誰かが喜ぶようにするところから考える必要があります。

　そう考えると、エンタープライズ系の製品での利益の源泉として「ミッションクリティカル」というキーワードがありますが、それはちょっと面白くない。ミッションクリティカルな用途にも使えるような設計のソフトウェアを産み出すことには関心が持てますが、システム全体としての可用性を高めるためにはハードウェアから運用チームの体制まで多岐にわたって気を配りリソースを配置する必要があるので、そのこと自体で付加価値を生むのは小さいチーム向きの仕事ではありません。

　マージンを取り除いて付加価値を生むことがリスクを取ることと表裏一体なのであれば、他の人達が自分達よりも怖がっているようなリスクであるのが一番です。多岐にわたるサービス領域のどこかでミスが発生しても全体で取り戻せる！というのは大きな組織のビジネスです。機動的にあちこちのまだ実績や日本語資料がない技術・製品を評価してみたり、通常のSIサービスの域を少しだけ踏み越えて製品の改善を行ったり、ということで既存のプレイヤよりも大きな風呂敷を広げて、コミットメントの部分で差をつけることなら小さいチームでもできます。OSSにしても昨今の技術Blogなどでの情報公開の文化も、小さいチームであってもスキルが蓄積しているということを示すための武器を与えてくれます。なので、なるべくそういう方面で付加価値を出していきたいと考えて、今の事業ドメインに落ち着いてきたわけです。

　OSSで、サポートサービスをサブスクリプション（購読）型で売ります、というビジネスをしているということもありますが、元々やっていたコンサルティングサービスの領域でも、度々「日本人はサービスに対価を払う文化を持っていない」という壁（？）にぶつかります。これは多くの場合はただの愚痴として語られる言葉です。商品としてのサービスを上手く説明したりパッケージ化したりすることに失敗しているとか、（海外でも恐らくは同程度の困難を伴っていると思われる）市場の育成がまだ十分行えていない、とかってのが実態に近いことがほとんどだと思います。（いや、それがやりにくいからこういう文言がでてくるんだよ、っていう気持ちは非常によくわかるんですが）

　生意気なことを言えば、こういう愚痴がある程度の説得力を持つ環境というのは、それだけ既存のプレイヤに力がないということです。実質的な参入障壁が低い。うちのような小さい会社でも実績を積むだけのチャンスを与えられてきましたし、小さい会社としては（9年目という）それなりのボリュームを持つ実績も示せるようになったので、今のところ、「仕事は楽しい」と言って嘘ではない感じです。

何がままならなかったかというと

　このシリーズの最初に引用した弊社杉本の記事で、Railsベースでプロダクトを作ったらWindowsユーザ向けのインストーラの構成がやたら大変だった、という話です。エンジニアが扱う限りにおいては、細かい環境の違いとか例外ケースに応じたマニュアルとかっていう部分にかかる工数を省略をして、ソフトウェアそのものの強化や品質改善に力を注げるはずです。しかし、我々が取り扱ってる領域は企業ユースですし、その情報システム部門の人達にこちら側へ歩み寄ってもらうことでより効率的な分業を実現したいわけなので、今回のようにハードルを下げるための工数も取らないわけにはいかない。ビジネスドメインの選定についてはある程度自覚的だったつもりですが、実際に工数の割り振りをしていく中ではもっと攻める領域にメンバーのリソースを割り振ることができればな、、、とついつい思ってしまいますよね、という身も蓋もない話を簡単にするつもりでした。

結局まとまらなかったな・・・

（文責 Ishii Akinori IT-Coordinator）

ままならない話の続き

今更になって、ここの環境だとMarkdownの強調文字が反映されないことを知りました。見出しはちゃんとでるのに。

前回のまとまらない話の続きです。「自社のためにソフトウェアを書き、そのソフトウェアによって構築するシステムとそれが実現するサービスで付加価値を生む」、いわゆるWeb系のサービス企業が全盛とも言える中で、大雑把に言ってしまえば「顧客のためにシステムを構築、あるいはその支援をし対価を得る」従来型のビジネスにまだ魅力があると考える理由、の話でした。

基本的な「仕事」観

最初に務めた企業、その業種や業態によって、その人の「ビジネスの常識」がある程度規定されてしまうのは仕方のないところなのではないかと思います。私の場合は、21世紀に入ってすぐぐらいのタイミングで当時会計系と言われていた外資系コンサルティングファームに就職したので、以下の議論にはその影響が色濃く出ていると予想されます。（実家の天井クレーン工場の影響も多分にあるはずですけど）

当時、いわゆるITコンサルティングの業界ではSAPをはじめとするERPの導入が全盛を迎えていました。我々新人は、今がピークということは今後成長速度は鈍るし、そういうスキルを身につけることは本当に得なことなんだろうか、という悩みを広く共有していた気がします。私は実際のプロジェクトでは全然関係ない役割を負ったものの所属としてはSCM（サプライチェーンマネジメント）のチームだったので、そのコンセプトやツール・方法論などについても色々と教えてもらいました。

「基本的に技術を理解すればするほど単価も給料も低くなる」ということを実感し、結果的には3年に届かずに辞めてしまうかなり典型的な感じに駄目な若者だったので偉そうなことを言える立ち場ではないんですが、新人は新人なりに考えることもあります。当時の私は自分の職業とその環境について以下の様に考えていました。

• パッケージソフトウェアは社会的な分業である。多くの企業で共有できると規模の経済によりベンダに富が集中しやすくなる


• 業種、企業、部門、などのサイロや「壁」はどこにでもあるし、それを壊すことは基本的に善いこととされている。効率が上がる。抵抗の声は単なる既得権の主張に聞こえやすい


• 自分たちの仕事の仕方が「他社よりも優れている」と考えている人は非常に少ない。同程度に他社を知らないと言い出しづらい主張だから


• 自分達の従来の仕事の仕方が「低リスクである」と考えている人は非常に多い。精査されているかどうかは別として実績はあるし、今更否定されても困るところだから。でも通常、それが現状であること以上の根拠はない


• パッケージ化されている業務とシステムにもそのプロセスが「最善である」という根拠はない。すでに実装されていて他所でも動いている、というだけである


• 我々は宣教師である。客観的に最善である保証はないが、内部のロジックは整備されている。後は勢いで取り込めばお互いに幸せに近づく

これ以外にも、コンサルティングサービスの具体的な効能、などについても色々と考えていましたが、基本的な仕事観としてはこんな感じだったと思います。

要するに、皆がせっかく確保してきた「自分が快適に過ごすための他者との間のマージン」を取り上げて自分の手柄にするお仕事、というわけです。

ただ、どんなマージンを取り除くのか、どうやって取り除くのか、それ次第によっては、組織全体（あるいはエコシステム全体？）にとってはもちろんのこと、個々の部門や個人にとってもプラスになる。そこに職業としての価値があると考えていました。どうやって、のところはツールや手法だけでなく、理由、根拠付けも重要です。

どのマージンをどういう理由・手法で取り除くのか。例えば前述のSCMにしても、それまで注力してきた企業内の部門や業務プロセスの間のマージンではなく、企業間のマージンに手を入れる、それも国際的な競争の激化を背景に新しいツールによって実現される精度やスピードを活用する、という建て付けで盛り上がっていたように見えました。そして多くの方法論が、マージンを取り除くことの意味・価値をステークホルダー全員がしっかり理解し共有することが肝だと主張していました。そりゃ、ま、皆がそういう気持ちなら導入も楽ですよね。

OSSによって取り除かれたマージン

さて、ようやくオープンソースです。ソースコードの隠蔽や独占というのは、ベンダ・SIer・ユーザ企業という企業間の壁にもなるし、開発者と支援者との間の壁にもなる。オープンソースならその壁は始めからないし、皆がそのことを理解している（という期待が持ちやすい、くらいですか）。

話が前後してしまいましたが、あらゆる「壁」を取り除けばいいというものではない、というのはある種自明なことと考えています。組織の構成要素の1つとも言えますし、例えば壁がなさ過ぎると他部門からの膨大な作業依頼や割込的なコミュニケーションで担当者がパンクしてしまう、なんてこともよくある話です。壊すべき壁とそうでない壁がある、と。

これはあちこちでお話していますが、プロプライエタリのパッケージ製品のコンサルティングをやっていると、国内代理店（もしくは国内法人）のサポートスタッフ、技術スタッフ、海外にある本社のサポートスタッフ、開発エンジニア、と非常に層が厚いコミュニケーションパスをくぐり抜けないと「ソースコードレベルの問題解決」にまで到達できません。層の厚さはスピードの低さだけでなく信頼性の欠損に直結します。

もちろん、今では弊社でも製品サポートサービスをやっているので、サポートメンバーの所で以下にしっかりした防波堤を築くか、がビジネス的に重要であるということも十分理解しているつもりですが、プロジェクトという期限が切られた環境で直に顧客と接するコンサルタントの立ち場で、バックエンドとのこの距離感は辛いものがあります。OSSのビジネスではまずここが劇的に改善されています。従って、これは壊すべき壁であったと考えています。

言い換えると、ソフトウェアのソースコードを出発点として、それを実際のユーザ企業まで届けるまでに関与するITプロフェッショナル全員の間の壁は、少なくともソースコードの隠蔽や独占という意味では取り払うべきだという主張です。

この壁、マージンを壊して新しいやり方に移行していく過程には十分なビジネスがあると考えました。顧客サイドにとっても価格面やロックインフリーという意味で魅力があり、個々のエンジニアも雇用されている企業が独占できないレベルでキャリアが積めるというメリットがあり、他人の目を気にしたコードの品質の高さもなども含めて、根拠付けもばっちりです。何より、我々にはこの変化で失うプロプライエタリ型の収益もありませんでした。

以上が元々考えていた企業向けOSSビジネスを選んだ理由です。しかし、これだけだと（一時的に、かもしれないにせよ）他の選択肢を捨ててまで集中する理由としては乏しいかもしれません。もっと効率的に、もっとたくさんのマージンを取り上げる方法があるなら、そっちを選択すべきでは？　と。その問いかけに対しては、完全ではありませんが2つ回答があります。

• 実際にやってみるとOSSモデルが取り除いたマージンは上記の想定よりも大きかった


• スキル、経験、そして個性を活かせるポジションを求めた

また、長くなってしまったので、この辺で一旦終わります。続きは恐らく連休明けにでも

（文責 Ishii Akinori IT-Coordinator）

NemakiWare 1.1 リリース：ままならない話

NemakiWare 1.1 リリース：Cathedral Break in Action：ITmedia オルタナティブ・ブログ

自社製品のNemakiWareの新バージョンをリリースしました。で、プロダクト責任者の杉本のブログも更新されています。

社内メンバーからも「Railsはサービスとして使うのはとっても良い技術だと思いますし、開発という意味でもすぐれたフレームワークではあると思うのですが、企業向け OSS のプロダクトとしては少しはやかったかなーとも感じました。」なんて書いちゃって大丈夫？ というコメントがあったので、少し補足を入れつつ企業向けOSSプロダクトの難しさについて思うところをつらつらと書きたいと思います。社内から、ってところは少しショックな気もしますが、うちはIT以外のコンサルティングもやってますし、それも含めてダイバーシティ、と思うことにします。実際、社外の目、を意識する上ではとても有用なフィードバックです。

あ、念のために言っておくと、杉本が書いているのはRailsは（人気もあるし品質的に不安があるフレームワークではないけど）インストール型のプロダクトのベースとして使うには、環境毎にインストールで失敗する要因があちこちに潜んでいるのでフォローが大変、でも頑張って押さえ込んでますよ、ってことなので、無事インストールされた後の製品の品質とはほぼ無関係の議論です。

多分、例によって長くてもやっとした話になります。でもって、ほとんどNemakiWareの新バージョンとは関係ないので、製品に関心をもって頂いてる場合はこれ以上読んで頂かなくても・・・

企業向け&OSS&プロダクト

プロダクトのところは、パッケージという言い方でも良いかもしれません。要するにオンプレミスでも自分のコントロールできる環境にインストールして利用できるソフトウェアという意味です。弊社イージフのメインビジネスの一つが、この3要素を重ね合わせたところにあります。ビジネスドメインという意味では「何をやらないか」を表現した方がわかりやすいかもしれないので、対義語を並べると、一般消費者向け・プロプライエタリ・（クラウド）サービス、あたりになりますか。（実際は、いつ何をはじめてもおかしくないですけどね。9期目とは言え規模的にも立ち位置的にもベンチャーのつもりなので）

市場が企業向けなのか一般消費者向けなのか、というのは誰からお金をもらうのかという話なので比較的わかりやすい話なのですが、問題は残る2つです。OSSはなんとなくプロプライエタリよりも新しくて良いものな気がする、のと同じくらいのノリで、パッケージビジネスよりクラウドサービスの方が新しくて良いものな感じがするというのが、2014年現在のカジュアル（あるいはナイーヴ）な感想なんじゃないかと思います。うちは、片方では目新しい方、もう片方では伝統的な方に軸足を置いているので、少しややこしいわけです。

クラウドサービスを支える大部分の技術はOSSでしょうし、サービス企業からコミュニティに提供されるオープンソースのコードによる貢献の比重は極めて高いということもよく知られています。OSSというキーワードは、「クラウド」にバズワード的な意味での地位を譲ったような印象もありますが、実際にはこの2つは技術面では非常に高い親和性があります。ですから、両方新しいトレンドに乗っかってもよさそうなものですが、うちはそうしていません。（企業向け、ということでは、誰がどの領域をコントロールするのか、ロックインされるものが何か、という意味で大きく性質を異にする、とか色んな背景がありますが、ここではひとまずおいておきます）

サービスって？

伝統的なOSSビジネスが、ライセンスからサポートサブスクリプションへというビジネスモデルの転換をうたい、「これからはサービスで稼ぐ時代」なんて言い方をしていたのも、さらに話をややこしくしてくれます。当時言われていたサービスはいわゆる製品サポートと、前後してIBMあたりがサービス重視！なんて言って売り込んでいたシステムインテグレーションとかコンサルティングとかっていうものを漠然と含んだ概念であって、今日Web系のサービスとかクラウドサービスとかって言われるものとはだいぶ異なっていました。あくまでお客さんは企業、それも多くの場合は情報システム部門を相手にする仕事だったわけです。（Webサービス、っていうとWeb上で提供される各種のサービス、ではなく、SOAPとかRESTって解釈するクラスタ、と言ってもいいかもしれません）

現在我々が提供しているサービスも基本的にこの若干古めかしい意味でのサービスになります。導入支援、製品保守、カスタマイズ、etc.　もちろん、企業向けであっても素晴らしい（クラウド）サービスはたくさんあります。利用者や支援者の立ち場でこれらのサービスを活用していく、というのも現在のコンサルティングサービスには欠かせない要素になっています。しかし、弊社の場合、自社のサービスは今のところ伝統的な意味のそれにフォーカスしています。何故なら、そこにはまだビジネスチャンスも社会的な意義も眠っていると考えているからです。

あ、やっぱり長くなったので、続きは後日にします。まとまらない話だった。

追記）このポストを受けて杉本が元記事を若干訂正して引用部分にズレが生じているようですが、こちらはそのままにしておきます。

（文責 Ishii Akinori IT-Coordinator）

友人が出した本を読んだので

Amazon.co.jp： チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus): 池田 尚史, 藤倉 和明, 井上 史彰: 本: "本書はサービスやアプリケーションを開発する企業において、複数の人たちでチームを組んで開発を進めていく際に必要な考え方や使用するツール、またそれらをうまく使いこなすためのノウハウをまとめています。本書の最初でうまく物事が進んでいない開発現場の一例を示し、その理由と対策についてまとめています。次にその対策に必要なツールである、バージョン管理、チケット管理、CI(継続的インテグレーション)、デプロイ、リグレッションテストの章を設け、その使い方と上手な運用ノウハウなどについて現場での経験が豊富な著者がまとめています。"

(Via Amazonの内容紹介.)

昨日の移動中に読みました。友人の本、といっても共著の3分の1ですし、献本もしてもらっていないレベルなのでステマではないと思うんですが、すごく良い本だと思うのでご紹介を。

内容については引用した通りなんですが、まさに今このタイミングで書籍として出されるべきもの、という感想を持ちました。友人は自らの筆の遅さを嘆いていた気もしますが、タイミングとしてはまったく悪くないと思います。

ITコーディネータとしての活動でも、本業（？）のコンサルティングのお客様との会話の中でも、システム開発の環境が大きく変わってきていて、新しいツールや方法論の導入にはかなり具体的なメリットがある、というお話をさせて頂く機会があります。最近は特にそういう話題が増えている気がします。

特にITコーディネータの方の繋がりだと年齢層が高くなるためか、「アジャイル」というキーワードに対してどういう態度を取るか、というのも現在進行形の議論だったりします。当然、要件要求の反映の仕方とか、ITとビジネスの関係性とかって語り口になるんですが、実際にはこの本で紹介されているようなツールの支援があって初めて現実的に仕事のやり方を変えていくことができる、という実感があります。（ツールの導入自体も業務改革ではあるんですが、変えた方が良い理由、変えることができる理由を捉えるにはツールの実態に踏み込んだ理解が必要だと思います）

筆者の一角を担っている僕の友人は、外資系のコンサルティングファームでのERP導入の現場も、国内パッケージベンダの開発や保守の現場も、B2B分野での国産クラウドサービスの開発という希有な環境もよく知っていて（最近では時流に乗りすぎてコンシューマ向けの世界に行っちゃいましたけど）、従来型の働き方の問題点の捉え方や表現の仕方のバランスが非常に良く取れていると感じました。本人は見た目からして偏屈な頑固親父風なんですが。

今、仕事としてのソフトウェア開発の環境を改善する（まだ十分に普及していない）技術が同時多発的にでてきています。この本では、それらをある種満遍なく紹介しつつ、現場のどういう問題を解決するのかを具体的なシナリオを提示しながら説明しています。

• どんな問題があるのか


• どんなツールがあるのか


• どう使うのがお薦めなのか

機能的な使い方も大事ですが、この手のプロ向けのツールは色んな使い方ができるようになっているので、運用ルールを決めるのが難しくそこが隠れた障害になります。最近では、技術系のBlogなどを調べていけば、こうした運用上の工夫を公開してくれている記事もたくさんあるにはあるんですが、そこはそれぞれ1チームの例だけになってしまうことが多いですし、情報自体も分散しています。

書籍になっていることで、こうした情報がまとめて把握できますし、何よりチームメンバーとまわし読みすることができます。これは非常に意味があることだと思います。社会的な貢献、と言えそうなくらいです。

業務系のシステムを開発している会社こそみんな買った方がいいですよ！

#あー、でもコンシューマ系よりもエンタープライズ系は遅れてるし地味ですよね、みたいなテイストになると6月のパネルセッションが苦しくなる気も・・・

#いや、その前に自分の仕事の仕方を・・・

（文責 Ishii Akinori IT-Coordinator）

ベンチャーやるなら「企業向け」でヨロ！ (仮) - 京大情報学同窓会 超交流サイト

ベンチャーやるなら「企業向け」でヨロ！ (仮) - 京大情報学同窓会 超交流サイト: "ベンチャーやるなら「企業向け」でヨロ！ (仮)"

6月に、母校の同窓会イベントのパネルセッションに参加する予定です。

一応2期生ですし、立ち場的にもこういうネットワーキングには積極的に参加していくべき、、、なんですが実は初参加です。そして、他の登壇者ラインナップが立派すぎて早くも気後れ気味なんですが、頑張ってきたいと思います。

企業向けITの世界は、データアナリストがそうであるという意味で近年ますます”セクシーでない感じ”になってきてると思います。あんまりセクシー路線に興味がないので、それはそれで結構なことである気もしますが、ビジネスとしての魅力が過小評価されて縮小にむけたスパイラルに嵌まっていくのは健全なことではないですよね。　っとかって感じなんですかね？

実際には主催者である1期生の先輩（クエステトラの今村さん）から無茶振られたっていうポジションなんですが、普段のんびりと好き勝手やってるので、この先輩からタスクが飛んでくる感じが新鮮でかなり楽しいです。

（文責 Ishii Akinori IT-Coordinator）

ECM普及の日米格差問題について

最近弊社のブロガーミーティングが復活したということで、私も参加して一緒に書くことにしました。

そのわりにはいきなり硬いテーマです。私のキャリアの半分くらいはこの問題を中心にまわっていると言えるかも知れません。「なぜ日本ではECMは売れないのか？」市場規模として米国の10分の1以下とも言われています。

この問題については、これまでも色々な人の色々な意見を聞いてきました。

• 日本人は紙が好き。（ペーパーレス化のタイミングで紙を廃棄するという不可逆でリスキーな意思決定をするのを嫌う）


• 日本では人材の流動性が低い。（業務コンテンツの所有権を組織側で吸い上げて属人化させない、とか、硬直的であってもシンプルで効率的なワークフローを導入する、などのモチベーションが相対的に低い）


• 日本ではユーザ部門の発言権が強い。（パッケージの素っ気なく汎用的なUIなど受け入れられない。文書登録の手間が飲み込んでもらえない）


• ミドルウェア的なものや、コンテンツの1ファクト1プレース化などの、抽象的なコンセプトのレベルでの優位性が評価されない。（個別プロジェクトでのコスト評価ではメリットが出せないため稟議が通らない）


• 日本にはエンタープライズ規模導入は視野に入れないかわりに比較的低価格で海外製品よりも使い勝手が良い「文書管理ソフトウェア」が多数存在する。


• e文書法などの制度が諸外国との環境上のギャップを生んでいる。


• メインフレームが未だに高いシェアを誇っている。（オープンな技術でコンテンツ管理をするモチベーションが低い）

業界によっては上記のどれもが当てはまることもあるでしょうし、そうでない場合も当然あると思います。実際には複合要因ということかもしれません。しかし、いずれにしても全体のトレンドとして、日本のビジネス環境もグローバル化を迫られている方向にあり、幾つかの条件は徐々にあたらなくなっていく方向にあるのではないかと思います。

また、最近よく見かける言説でもありますが、日本のSI業界の特殊性というもの関係していそうです。厳密には、それこそ米国との違いということなんですが、日本では顧客からSIerへの丸投げ、受けたSIer側での多重下請構造、という奴です。（この分業については日本独自とは言い切れないと聞きますし、ECMはヨーロッパでもアジア諸国でも順調に売れているので、現時点では本当に大雑把な物言いになってしまうんですけど）

ECMは、各ユーザ（主にナレッジワーカ）が産み出したり業務システムが出力したりするコンテンツを、ポリシーにあわせて管理できる、ということに価値があります。業務プロセスやユーザ・組織が変わっても、コンテンツに一貫したポリシーを適用していくことができる。業務システムの刷新があっても、データ部分であるコンテンツの一貫性を担保しやすくなる。長期的なメリットにその本質があるわけで、個別のシステム導入プロジェクトの単位では、そのメリットが生まれることはほとんどないわけです。（モデリングとかデータのハンドリングを独自実装するよりECMのAPIを叩いた方がスマートであるとかって話はもちろん別途ありますけど）

その為、プロジェクト単位のお付き合いである外部専門家よりも、長期的な視点で自社のメリットを考えるポジションから見て初めて魅力的ということです。その割にはテクニカルでビジネスユーザにとって直感的ではない。それが、テクノロジ面での専門性を持つスタッフを内製化していることが多いとされる米国で受け、逆に日本で受けていない理由ではないか、ということになります。

この説明が現状を正しくうつしとっているかどうかはわかりませんが・・・（前述の米国以外の話からも怪しい部分があります）

 

いずれにしても私としてはECMは日本企業にとっても導入するメリットのあるコンセプトだと考えていますし、その普及を進める施策を打っていきたいと考えています。

今時点で考えている（あるいはすでに実行している）アクションは以下の3つです。

1. 個別プロジェクト単位の投資判断の中にも滑り込ませられるような低価格でシンプルなECMリポジトリの提供。要するに、NemakiWareの開発


2. ユーザ部門側の抵抗を生まずにECMリポジトリへのコンテンツ登録を推進する仕組みの提供。要するに、CmisSyncの開発


3. ミドルウェアとしてのECMの経済価値の評価方法の整備（サービス指向アーキテクチャや疎結合の正当化のようなイメージです）

今後ここでも、それぞれのアクションについての進捗をご紹介できればと思います。

（文責 Ishii Akinori IT-Coordinator）

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）