会社設立から10年が経ちました

iPad Proを抱えてスターバックスに来てみました。Bloggerアプリからの初投稿です。

弊社、株式会社イージフは今日2月22日で10周年を迎えました。

20代の終わり頃勢いに任せて作った会社が節目を迎えたことを、まずは素直に喜びたいと思います。

私ともう一人の取締役である加納は社長の藤井の新卒同期、さらにもう一人の創業メンバーである野口は「会計士としての」藤井の同期で、年齢も近く、ほぼ何の実績も後ろ盾もないところからのスタートでした。

私はサークルの後輩たちにまで就職活動をしていることを疑われるぐらい実社会向きではないタイプだったはずなのですが、ある日実験の結果がうまくまとまらず純度100％の冗談のつもりで「就職でもしますかね」と言ったのを研究室の先輩（厳密には社会人からの出戻りなので登録上は後輩でしたが）に聞きつけられてしまいました。その先輩の代理エントリーの結果、気がついたら外資系のコンサルティングファームに就職していました。（当時は「お姉ちゃんが勝手に申し込んだ」ミスコンやアイドルオーディションのようなものだ、と言っていました）

就職した先のコンサルティングファームでの仕事は中々刺激的でしたし、幸いコンピュータに関しては実家の手伝いで小学生の頃から表計算やCADのマクロを書いたり、当時流行りだったネットベンチャーでのアルバイトで中小企業向けのシステムを組んだりしていたので最低限の知識はあり、新人なりに役に立てることがあるという意味でもやりがいがありました。（大手企業や大規模システムと自分の知識の間を埋める、ということが入社時点での自分の目的になってました。あまり主体的な目標設定ではないんですけどね）

ただ、大規模なERP導入のプロジェクトでECM関連サブプロジェクトに従事させてもらっている中で、一つの残念な事実に気がつきました。どうやらこの職場・業界ではプログラムが書ければ書ける程給料が安いのです。当時は、技術系のキャリアの先がプロマネだけでいいのか？ということが問題になり始めた頃で、例えばアーキテクトというロールもあり得るのではないか、なんて話があちこちでされていました。一方で大企業の発想や大規模なプロジェクトの力学で中小のそれと一番異なるのはどうやらリスクに対する考え方だ、という結論めいたものも見えていました。（若者らしい薄っぺらい結論だという自覚も一応ありましたよ！）。全体がこけるリスクを抑えることが、部分を積み上げることよりも重視されている。それが技術よりもマネジメントを重んじる理由であると考えました。プロジェクトの全体を見るマネージャーや、それよりも高い視点を持つ経営者が、意思決定のためのより良い情報を持っている、ということが保証される限り、それはそれで良い気もしました。

しかし、このロジックの中では個々のプロジェクトや企業の視点では「部分」しか見てない扱いになる技術者ですが、その技術は世界中で利用され共通の変化にさらされているわけです。その動勢をマネージャも経営者も把握できていません。（世界共通云々を抜きしても、いわゆる「技術的な負債」を担当マネージャーが把握しきれてないなんてこともあるかもしれません）

そんなわけで、当時の私は、技術的な知見を持つ人だけが持つ、良い判断材料というものがあるのではないか、その重要性は高まりつつあるのではないか、という（コンサルティング業界の中では）技術寄りの人間だった自分の我田引水的な発想を暖めていたわけです。そこに、一緒に会社を作らないか？という誘いと、仕事で取り扱っていたエンタープライズ向けソフトウェアのオープンソース版ともいうべき製品が、元の製品を立ち上げた本人の手で立ち上がったというニュースが入りました。それが、弊社とAlfrescoの出会いであり、その後、オープンソース技術のエンタープライズ分野での活用というニッチなテーマに取り組むことになるきっかけでした。

とはいえ、まだ20代。最初の会社でかろうじて覚えたコンサルティング以外の稼ぐ手段をほとんど知りません。地元や大学、新卒時代の友人達の協力を受けながら徐々に仕事の幅を広げていきました。力を貸してくれた人たちは本当に仕事ができる人たちばかりで、長年続いた不景気ムードがなければ、こんな海のものとも山のものともつかない会社に助力なんかしてくれなかったのではないかと思います。今では、技術的な知見についても私はメンバーの水準に達しているのか怪しい限りです。（それでいいのかCTO）

10年。時代が変わった、と言っても良いと思います。オープンソース技術の価値を真剣に考えるべき役目・ポジションは、やはりそれほど経営層の方向には伸びませんでした（CIOには考えてほしいと思いますが、それが必須であるとは言えません）。クラウドの活用によりITに関する意思決定の形が大きく変わった分野もたくさんあります。技術者の地位は向上しています。しかし、それは一定の格差の出現を伴ったものであるようにも見えます。働き方も変えやすくなったと言われています。自分たちは割と好き勝手にやってきたので、その変化についてはもしかすると鈍感なのかもしれないと感じます。

節目の年、ということ自体には多分、特別な意味はありません。できる人は毎日でも自分を振り返ったり目標を見据え直したりできるのかもしれません。そんな人はなかなかいなそうな気もしますが、私がそうした意志の強さにおいて人並みの域に達しているかというと、かなり難しいと思います。そんなわけで、今日改めてこれまでの仕事を振り返ってみました。

私たちの仕事には時として「自分のなら（自分の方が）うまくやれる」という自負が求められることがあります。会社を作ったのも、その一環でした。既存の企業よりも多少なり良い器を作れるのではないかと考えたから「会社」を作ったのです。、、、ということ反省するのを最後にスターバックスをはしごして書き連ねたドヤ顔ポストを締めたいと思います。

（文責 Ishii Akinori）

ECMサミット2016（冬）やります

気がつくと、前回のECMサミット2015以降更新がなかったですね･･･

前回のものについての報告記事は月間IMに書いたのでそちらの紹介なんかもさせて頂くつもりだったのですが、気がついたら次の告知が必要な時期になってしまいました。

ecm-portal

ECMサミットとは

くり返しのご案内になりますが、私が委員長をやらせて頂いている日本文書情報マネジメント協会（JIIMA）のECM委員会主催のイベントで、主要ECMベンダが一同に会して業界の最新動向などをお伝えするイベントです。

ECMは海外での事例の豊富さと比較して、日本ではあまり導入が進んでいない領域です。日本企業のITに対する取り組みや、日本人の就業感など、内外差の理由は色々なところにありそうですが、それらを再検討する上でもこのあからさまに普及度合にギャップがあるソリューション分野というのは興味深いのではないでしょうか。（普及啓発をミッションとしている人間が言ってしまうのは無責任かもしれませんが）

～ECMのミライ～　知識・協働・ディカバリーの先へ

というテーマになっています。

今回のテーマの狙い　地味な裏メインテーマ『eディスカバリー』

さて、実は数年前にも少しだけ取り扱ったことがあるテーマでもあるのですが、私自身ここ数年の間、eディスカバリーについてももう一度取り上げたいと考えていました。社内にある文書情報を未整理な状態で放置することが、直接的なダメージになりうる、ということを端的に示したテーマだからです。

残念ながら国内企業の多くは、海外企業（より具体的にはアメリカ企業）と裁判になった場合に、タイムリーに証拠となりうる情報を提出するためのインフラを持ちません。アメリカの裁判制度においては、これは非常に大きな弱点となります。日本における文書情報のあり方がこうした問題に対応するのを苦手としていることは、それほど一般に知られていることではないと思いますが、いつの間にかハンデ付きの戦いに巻き込まれてる、という状況をなくしていくために、広く伝えて行く必要を感じていました。

ただ、ECMはディスカバリー（ここでは、アメリカの証拠収集手続を意味しています。それをさらに電子的な情報に拡大したのがeディスカバリー）対策のためのソリューションではありません。ECMを入れることが、ディスカバリー対策の意味ですぐに効果を発揮するかというと、残念ながらそこまでのインパクトはないでしょう。あくまで、対策の土台となる情報の整理ができあがる、というだけです。ディスカバリー自体はあくまで法律分野の問題です。

ちょっと正確性を欠く表現かもしれませんが（ご指摘、お待ちしております）、アメリカのディスカバリー制度では「係争相手が持っている文書」を提出させることができることになっています。我々が想像する裁判は、それぞれが自分に有利な証拠（だけ）を持ち寄って議論を戦わせる、というイメージだと思いますが、アメリカのルールにおいては、裁判の目的に沿っていものであれば本来持ち主が出すつもりのない資料も証拠として無理矢理提出させられてしまうわけです。

これはちょっと不思議な話です。自分に不利になるはずの証拠文書を指定されて開示しろ、と言われても、それは嘘やハッタリの類いかもしれないわけです。実際、該当する資料が無かった場合、当然拒否することになるわけですが、そこで「悪魔の証明」、すなわち、その資料が存在しないことの証明責任を求められることになってしまいます。であれば、難癖の付け放題になってしまうのではないか？

しかし、この制度は長きにわたって存続運用されています。もちろん、裁判所の目が光ってるということもあるとは思いますが、「悪魔の証明」がある程度簡略化されている、ということも重要なポイントです。

「どのような文書情報を、どれくらいの期間、どのように保管しているか」

というルールを定め、その様に運用していると見做されれば、そして裁判に関係ある情報を全量とりまとめて提出できる能力さえあれば、「その中に無ければ無い」と主張できるわけです。

これが、例えばメールはすべて5年で削除というルールがあるのにそれ以前のメールをローカルにバックアップを保存してしまう従業員がいたりすれば、運用実態に疑義が生じてすべてのPCの中身をひっくり返さないと結論がでないことになります。ルール通りに運用されていても、〇〇という製品に関係する資料をすべて、という指定に対してメタデータやインデックスなどの整備がされていないと、本当にすべてを引き出せているかどうかが曖昧になってしまいます。その場合も一目でチェックが必要になるでしょう。（この場合の人目は法律の専門家であることが求められる、とするとその費用が莫大なものであることが想像できると思います）

このあたりの状況を改善するためには、社内の文書情報の管理ルールと、それを支えるシステムの整備が有効である、という結論になるわけです。

でも、いくら大切と言われても裁判の話に興味がある人なんてごく少数ですよね

表テーマ　完成図書管理の限界

ということで、eディスカバリーからは一旦離れて、サブタイトルに知識・協働・ディスカバリーと並べていることの意味についてご説明させて下さい。

要するに、今の日本企業が持つ文書管理規程、文書に関するルールは紙の文書の取り扱いを前提としていて、そのことと現実世界の要請との歪みがとても大きくなってしまっている。それが端的に表れてるのが、ナレッジマネジメントやコラボレーションなどの生産性向上の取り組みとディスカバリーの領域である、ということです。

電子的な文書の比率はどんどん高まっていますが、文書管理規程とIT関連のセキュリティなどの規程と個人情報に関する規定はすべて独立して構成されていることが多いと思います。施策や、場合によっては運用したり管理したりする組織も違っているかもしれません。

こうした環境の中で、文書管理の規程やシステムの役割は、社内で正式にオーソライズされた文書を恭しく正式の最新版として取り扱う、というところに重点が置かれてしまっています。

つまり、「正式な最新版＝完成図書」がコンテンツとして完成するまでの過程については、主な関心領域ではありませんでした。

しかし、このコンテンツの作成過程もITサポートによって効率が向上することは自明です。実際多くのツールが提供されてきました。最近では社内SNSだけでなくチャットツールなどのチーム作業への貢献度が見直されたりもしています。もちろん電子メールにより社内外のやりとりもこの領域の情報をふんだんに含んでいます。

昨今問題になっている日本のホワイトカラーの生産性の問題、特に個人による仕事（情報）の抱え込みもここで発生しています。

生産性向上ツールはあると嬉しい。それが会社の正式な文書体系と繋がってるとより美しい。だけれども、投資にあうリターンがあるかどうかは不明だし、従業員も積極的に活用してくれそうにない。したがって様子見、あるいは中央集権的な仕組みには手を出さす部門単位の細かい施策から試す（そして新たなサイロを）、、、というのがECM（だけではなさそうですが）の和製アンチパターンであると言えると思います。

さて、ディスカバリーの話に戻ります。先ほどは、国内企業の不利を正すため、というようなある種きな臭い理由付けをしてしまいましたが、ここにもう一つこのテーマが国内でのECM活用に繋がるはずだ、と私たちが考えるようになったポイントがあります。

完成図書だけが証拠ではないのです。現代の業務環境においては、ディジタル情報の形で文書・コンテンツが生成されていく過程の付帯情報も自動的に大量に生み出され、原理的にはその補足と管理も可能なのです。そして、司法もそのようなかつては揮発してしまった「言った言わない」のような情報までも、証拠性を認めうるとしています。しかも、先述の悪魔の証明の議論までついてくるのです。

eディスカバリー制度というものの存在が、生産性向上のような攻めのニーズだけでなく、コンプライアンス的な守りのニーズの文脈からも、紙を前提とした完成図書管理が時代遅れであることを端的に示している、と言えると思います。

ECMサミットでは私は冒頭のナビゲーションと最後のご挨拶だけですが、より深い知見や経験を元に各社のスピーカーから、さらに具体性をもったお話が聞けるのではないかと思います。

例によって大変冗長な記事になってしまいましたが、是非とも会場に足を運んでいただけらたら、と思います。

よろしくお願い致します。

（文責 Ishii Akinori IT-Coordinator）

ECMサミット2015、パネルディスカッションやります

eドキュメントJAPAN 2015 ― 53rd 文書情報マネジメントショウ

ECMサミット自体は年2回の恒例行事、なのですが、eドキュメントJAPANの枠でやるのは年に1度だけです。

今年は例の規制緩和があることもあり、各社展示ブースやセミナーも気合いがはいっているのではないかと思います。

ECMサミットもECM委員会なりに力の入った構成のつもりです。

パネルディスカッション、やります

ECMサミットは、競合しているトップベンダが一堂に会して同一フォーマットで講演を行うという特徴をもったイベントですが、基本的には各社に一定の時間枠を担当していただいて、連続して講演を聴くというスタイルになっています。この形式に対しては毎度アンケートでは、もっと統一感を出して横串で比較し特徴を見いだせるような形にして欲しいというコメントを多々頂いておりました。

過去には質問形式で議事パネルディスカッションのようなことも行い、高評価だったこともあるのですが、やはり中々登壇者の負担が大きく、毎回の実施にまでは至っていません。

ということで、今回は（主観的には結構頑張っての）パネルディスカッション形式になります。

（すべてのECM活用事例に当てはまるわけではありませんが、）ECMはプラットフォームとして捉えた方が見通しが良い、というのは近年かなり整理されてきた論点だと思います。そこについて各社なりの視点で語っていただくことをメインのトピックと考えています。

インフォメーションハブですとか、ケースマネジメント、デジタルイノベーションなど、比較的新しい言い回し、用語、の真意についてもなるべく分かりやすく語って頂けるように工夫をしていきたいと思います。

10月1日という日程的にはかなり厳しい条件もあるのですが、是非ご来場頂ければと思います。

（文責 Ishii Akinori IT-Coordinator）

コンサルティングって何？ という質問と、論理的思考力とやらの話

　aegifは外資系コンサルティングファーム出身の若者（当時）を中心として作った会社なので、それ以外に稼ぎ方を知らないという意味でもコンサルティングファームだったわけですが、今ではソフトウェアベンダとしての顔も持つようになってきていますので、改めて私が考えるコンサルティングサービスについてまとめてみたいと思います。
　あくまで個人的な意見です。仕事仲間にはまったく別のことを考えている人もいますし、自分達の仕事のすべてを以下の要素で説明できるわけではありません。最近この説明しきれない部分についても考え始めたことがあるので、後日機会があればそれもご紹介したいと思います。（そんなことばかり書いている気もする）
　今回ここにまとめる内容は、新卒2ヶ月目くらいの時に自分なりに整理した内容がほとんどなので、その程度の薄っぺらさだと思って頂けると幸いです。でもまだ自分の子供たち（小学校3年と1年）にうまく説明できるところまでシンプルにもなっていないのですが･･･

意識は高くなくとも

ざっくりとコンサルタント、それも外資系出身、と言われた時、どのような人物像が想像されるでしょうか？　英語が喋れて、切れ者で、メンタルが強くて、ハードワーカーで、向上心に溢れている、なんてところでしょうか。いわゆる意識高い系という言葉に付随する揶揄のニュアンスや、押しが強くて近づき難い感じとか、抜け目なさそうなところとか、拝金主義的なイメージもあるかもしれません。あとは、頭が良いアピールがうざいとか。
　概ね正しい気もするのですが、（他の多くの職業と同じく）全部が全部そのイメージ通りでもなく、実際には色々な人がいます。例えば私の場合は、英語はIT絡みならなんとか、切れ者に見えるかどうかはともかく、メンタルは弱いし、ハードには働けないし、知識欲はあっても向上心は半端です。意識はさほど高くないと言えるでしょう。（頭が良いアピールには余念が無い方だと思いますが）
　そんな私であっても、十数年も続けていればコンサルティングサービスに対する一家言と言いますか、地味は地味なりに職業倫理みたいなものを抱えていてもおかしくはありません。ということで、今日はそういう話。

よくある説明

私が新卒の頃も、コンサルティングには個人の知識や経験を売るグレイヘアードのコンサルティングとファームに所属してチームによる組織力で問題解決を図るコンサルティングがある、だとか、戦略系・会計系・人事系などのファームの色やサービス領域による分類などはよく語られていました。ITに絡むところだと、多重下請け構造のトップに「プログラマ」「システムエンジニア」の上に君臨するポジションとして「コンサルタント」と書かれていたりもします。
　ITに絡むところと、絡まないところでは、「コンサルタント」の定義や位置づけは変わるのでしょうか？
　プログラマはプログラムを書き、システムエンジニアは仕様書を書きます。「コンサルタント」は？　要件定義書？　RFP？
　「プログラマ」と「システムエンジニア」は（下請け構造があるにせよ）顧客からみると商流上同じ会社の下に入っていることが多いのに対し、コンサルタントはそうでない場合がままある（というかその方が多い？）ので、それが違いだという説明もあります。
何故そうなるのか。企業のとるアクションを意思決定から遂行に川の様に流れるものとして見た場合、上流の方があいまいでリスクが高い領域であると考えられます。そこで、そこを担当するコンサルタントがより顧客に寄り添ったポジションにいたり、リスクを見込んで高単価であったりというようなことも考えられそうです。また、あいまいさが大きくなればなるほど、ITに絡まないコンサルティングで求められているとの共通点が色々と見えてくるということもあります。
　以上のことから、私は個人的にも「エンジニア（システムエンジニアおよびプログラマ）は最終成果物として動くものを納品するという責任の取り方がある。コンサルタントの仕事にはそれがない」という話をよくしています。

では何を売っているのか

リスクがある領域で勝負しているから単価が高い。というのは、コンサルティングの仕事の性質をある程度反映した説明であると思います。ただこれは、その仕事、働き方を選択する人間の側からの説明であって、顧客が高いお金を払う理由にはなりません。
　果たして我々はどんな価値を提供しているのか。意識高くないコンサルタントとしては、卓越した問題解決能力みたいなことはあまり言いたくありません。恥ずかしいので。では、何を売りとしているのか。私は、第一にお客様のプロジェクトの成功確率を上げる（リスクを低減する）ことだと考えています。
　どのような企業にも通常業務と呼ばれる仕事、収益を上げるための活動があります。ルーチンワークと言っても良いかもしれません。そして、基本的にその作業量はその組織に所属するメンバー全員の稼働の限界に近いところで回っていることがほとんどです。そのため、例えば法律が変わったとか、新しい事業を始めたいが社内に適切な経験をもった人材がいないとか、競合会社の新戦略に対抗する施策を打ちたいとか、っていうことを考えたときに、落ち着いてそれら問題に対応できるだけの人的な余裕がないわけです。（その種のピーク時にあわせた雇用をしてしまうと、通常時に収益性が落ち込むことになります）
　そこで、それらの本来の業務ではない仕事をプロジェクトとして、期限付きの仕事として定義し実行します。このプロジェクトのチームに参画し、その成功確率を上げることがコンサルタントの主要な価値である、というのが私の主張です。

注）もちろんそれだけがコンサルタントの価値であるわけではありません。知識・経験に十分な市場価値があり、それを展開していく形で活躍されている方もたくさんいらっしゃいますし、問題解決力に特化して「考えること」の価値をマネタイズできているプレイヤーもいます。

プロジェクトの成功確率と論理的思考力

通常論理的思考力というのは、問題解決力あたりと関連付けて語られることが多い「能力」だと思います。しかし、実際にはブレイクスルーを起こすために求められる思考であるとか、イノベーションに繋がる発想だとかというものは、それほど純粋に論理的なものではないように思います。（論理と感性のバランスが必要、というような話は右脳左脳と結びつけてあちこちで語られています。右脳左脳の論に非常に強い抵抗を感じることもあり、ここでは詳細は割愛します）
　思いついたことを、他の人にも理解できるように形にしていく過程においてはもちろん論理的な思考が必要とされるでしょうが、突破力のあるアイディアを引き出すまでの過程は必ずしも論理的であるとはいえないでしょう。（そもそも論理的である必要がありません）
　ではなぜ、世の中ではコンサルタントには論理的な思考力が必要とされているのでしょうか？
　論理的な思考とは、同じ前提条件を並べられれば同じ結論を導ける、ということを保証するものだと、私は考えます。プロジェクトワークは、多くの不慣れな、あるいは、不完全な意思決定の積み上げによって行われます。作業を進めていく中で新たな事実が判明し、それまでの作業が無駄になる、ということも珍しくはありません。（それをミニマイズするための仕事の進め方を方法論という形でまとめ、活用することも大事ですが、ゼロにはなりません）
　いわゆる「手戻り」の発生です。その時その時の影響範囲にもよりますが、手戻りが発生したからといって、毎回その時点まですべての作業を巻き戻していては到底スケジュール通りに成果を上げることはできませし、何より、手戻りの発生はメンバーに混乱をもたらします。誰の責任でこの手戻りが発生したのか、という犯人探し（個人的には、そういうのは犯人探しではなくて、魔女裁判の類だと思いますが）が始まってチームが瓦解しかねません。
　だからこそ、各意思決定の時点で、どういう前提条件が見えているのかを把握し、その上で選んだ結論であるということを意識し、記録に残すことが重要になります。後で手戻りが発生するというのは、その前提条件に間違いや不足があったからであり、そこが変化したら結論がどう変わるべきかもクリアに見通せるようになります。こまめにセーブをすると被害が大きくなりづらい、ということですね。
　この、細かい意思決定の積み上げ時の前提条件の確認・把握と、その記録というのは、あまり華々しい前向きの仕事ではありません。インタビュー時に会議の勢いを削ぐかもしれないような細かい質問をし、確認を求め、議事録などの文書に残し、関係者の意識から漏れないように注意を払う、というような地味な作業によって成り立ちます。こうしたセーフティネット的な作業をどれだけ、勢いを殺さずに実施できるか、必要十分なレベルをキープできるか、というのはプロジェクト慣れと同時に、前提条件と結論の論理的な関係を見失わない能力がダイレクトに求められる領域なわけです。
　だからこそ、コンサルタントには論理的思考力が求められる。これが、意識の低いコンサルタントが論理的思考力を馬鹿にできない理由です。

　本当はソースコード管理と継続的インテグレーションみたいな話と結び付けたいところなんですが、ちょっと話が散らかってしまったので、続きはまた今度。（本当にこんなことばかり書いている）



（文責 石井昭紀）

EFSSという用語がどこまで浸透しているかは別として

CMSWiREにEnterprise File Sharing: Good Intentions, Bad Executionという記事が載っていました。直訳すると「エンタープライズファイル共有。意図は良いが、実行は悪い」というタイトルになるでしょうか。

EFSSって？

Enterprise File Sync & Shareの略です。エンタープライズ ファイル共有と同期。我々文書管理を専門とする人間にとってはここ数年頻繁に目にするようになったキーワードですが、一般にはそこまで普及していないのではないかと思います。
要するに業務で使えるDropboxみたいなツール全般のことなんですが、例によってくどく説明したいと思います。
まず、本題に入る前に「エンタープライズ」という用語について確認したいと思います。もともとはざっくりと大企業向けと解釈しておけば間違いのない言い回しでしたが、実際にはいくつかのニュアンスが混在したものになってきていると思います。

• 規模が大きい（データ量や処理能力など機械的な意味で）
• 高い可用性が求められる
• 業務用である
• IT部門によってコントロールされる

「高価格」であるとか、日本的SIerの飯の種であるとか、スーツ族の世界であるとかっていう表現も可能かもしれません。
今回の議論とは直接関係ありませんが、もう一つ、ERPやECMの世界では重要な視点があります。

• 中央集権的に全社統一で利用される

もちろんここにあげたものはお互いに結びついているコンセプトですが、最後の観点については、Enterprise-wide（全社スコープ）での導入か、Department（部門単位）での導入か、というのが対比で語られる、というのが特徴的であると思います。
話をEFSSに戻します。これは最近できた言葉なので、そこでいうEnterpriseも最近強調されている語感を意識して捉えるべきです。つまり、ここでいうEnterpriseの対義語はDepartmentではなくConsumerであるということになります。

Enterprise vs Consumer

数年前から日本ではSIerのキャリアパスへの不安感やWeb上のサービスを行ってるベンチャーの急成長もあって、Webネイティブな技術を牽引しているエンジニアとSIerの多重下請け構造に属しているエンジニアの間の断絶が度々問題になってきました。Web系、という言い方は業務系のシステムも世代はともかくとして同じようなWeb関連の技術を利用することが多くなってきているため、あまり通りが良くないということもあり、横文字を多用する文化圏ではConsumerizationなんていう言い回しも盛んに使われていました。
それまでは、業務向けに開発され磨かれてきた技術が徐々にコモデティ化する中で一般消費者向けにも利用できるようになるというダウンサイジング的な技術の伝播が基本だったのに対し、一般消費者向けに開発された技術の方が業務向けで使われている技術よりも先行しだしている、という状況を説明する用語でした。
Dropboxなどもその典型になります。今ではEnterprise向けのサービスも展開されていますが、基本的には個人利用をベースとして構築され成長してきたサービスです。
冒頭でリンクを貼った記事では、企業のためのEFSSと、現状利用されているファイル共有サービス（Dropbox、OneDrive、Googleドライブなど）を比較するため、後者をCFSS、 Consumer-level File Sync & Shareと位置づけています。EnterpriseとConsumerを対比させているわけですね。
面白いのは、「電子メールにファイルを添付して共有」などの技術的にはさらに古い世代のものも彼ら（？）にとって「あるべき姿」であるEFSSとの対比の意味でCFSSに含まれている、という点ですね。
このBlogでも米国のカンファレンスでDropbox問題という言い回しが一般化していた、というようなエピソードをご紹介させて頂いたことがありましたが、単に黒船が来て場当たり的に反応しているのではなく（多分に見栄が含まれていると思いますが）「もっと大きな視野で解決すべき課題を捉え、それが解決できるソリューションとそうでないものを峻別しているのである」という姿勢には敬意を払いたいと思います。

なぜEFSSが必要なのか

なんとなく想像がついてしまうこと以上の視点はとくにないのですが、（いくら日本が立ち後れていると言われていても）企業内の情報はどんどんディジタル化しています。ディジタル化するということは、余程気を付けない限り、利便性やコストメリットと共に以下の特性を抱え込むということでもあります。

• すごい勢いで増える
• 簡単にコピーされる
• 簡単に消せる

要するに散らかりやすく、漏れやすいということです。これはクラウドだからとかモバイルだからとかいう以前の問題です。（もちろんそういう要素が加速する面もありますが）
従来であればECMリポジトリが、この問題に対する一つの解だったわけです。しかし、ディジタル化の波は取り扱うデータの範囲をどんどん広げていますし、社外とのディジタルデータでのやり取りも増える一方であるため、社内に抱え込んだリポジトリだけでは追いつかなくなってきている。そこにさらにDropboxのようなCFSSがシャドーIT（会社のコントロール下にないIT技術利用）的に利用されはじめてしまっているわけです。
同期ツールの利便性は高く、使い勝手の悪い仕組みの利用を強制させるのは困難です。そのため、使い勝手として同等な、しかし安全な仕組みを企業側から改めて提供していく必要がある、というのがEFSSが必要とされる理由になります。

宣伝！！

弊社では、一定の安全性が担保されている社内ECMリポジトリに対して自動同期アクセスをかけることができるデスクトップツールCmisSyncを開発しています。オープンソースモデルで開発を進めており、単純に同期をするだけであれば無償でお使い頂けます。管理機能を高めたBusiness版もご用意しています。そもそも社内にECMリポジトリなんか持っていないよ、という場合は、シンプルなECMリポジトリであるNemakiwareもご提供していますし、そろそろ10年近い付き合いになるAlfrescoの導入支援やCommunity版への独自サポートプログラムなどもあります。お気軽にお声がけください。
（文責 Ishii Akinori IT-Coordinator）

浜名湖フォーラムに行ってきました

コンサルティングファーム時代の先輩からChromebookを譲って頂いたので、今日はMarsEditではなくBloggerの標準UIで投稿してみようかと思います。

IT経営会議 浜名湖フォーラム2015 に行ってきました。これで3回目の出席になります。

ECMもEIPもBPMも、一般にはアプリケーションとして扱われているにもかかわらず、特定の業務だけをスコープにIT投資を考える場合にはなかなかメリットが訴求できない基盤／プラットフォーム／ミドルウェア的な技術です。これらの技術がもたらす利点を以下に投資企画策定時に理解し取り込んでもらうか、という検討をしている中でIT投資マネジメントを研究されている方々の取り組みを知り、ほぼ飛び入りに近い形でカリアックにお邪魔したのがきっかけでした。（IT資産価値研究会にもそこからのご縁で参加させて頂くことになりました）

自分の発表について

さて、今年は色々と忙しく、昨年以上に発表の準備に時間をかけることができませんでした。昨年はシステムダイナミクスを使って、疎結合により柔軟性を担保した仕組みの方がモノリシックな仕組みよりも、たとえ初期費用で上回っていても中長期的にはメリットが出る、というお話をさせて頂きました。（厳密には、メリットが出る時の条件を検討する枠組みだけ作った感じでしたけど）

今年はその延長で、クラウドとオンプレミスを比較し従量制と定額制の組み合わせの最適値をさぐるようなお話を考えていたのですが、思った以上に要素の数が大きく、なぜそれを考えたいのか、という説明だけして撤退、というありさまでした。

ここでも簡単に説明させて頂くと、

• クラウドとオンプレミスは課金モデル以外にも違いが大きすぎて、現在一般に行われているTCOの比較は誠実な検討とは言えないのではないか
• クラウドによりスモールスタートを「スタート」しやすくなったが、適用ユーザを広げるとリニアにコストアップになるので結局「スケール」しづらくなってはいないか

というようなことを考えています。

イージフではこれまで一貫してロックインされないことを重視し、オープンソース製品の紹介を進めて来ました。私はその経緯もあって、柔軟性とは「将来における選択肢の幅を狭めないこと」であると考えています。今年の発表ではそのあたりのバイアスをうまく整理しきれず、研究会のリーダーである向さんから、クラウドの柔軟性と言われれば聞き手はスケーラビリティのことだと思うよね、という至極順当なご指摘を頂きました。まったくその通りなので、忘れずに反映しないと・・・

（あと発表内容が難解すぎるので飲み会で語ったIngressとモチベーションの話の方をテーマにしてくれれば良かった、というお言葉を数度頂きました）

他の方の発表について

今年も多岐に渡る発表がありました。どこまでこうした場でご紹介していいのかわからないので簡単にキーワードとそれらについての雑感だけ、メモとして残しておきたいと思います。

• デザイン思考　……アイディアの出し方そのものをサービスのネタにすることの難しさや面白さについて、具体的なシーンを元にしたお話を多数聞けたのが有意義だった。
• IoT　　……CPS（サイバーフィジカルシステム）という表現から迫ったほうが穏当？　EDIの置き換え文脈もここに含まれるというのが面白かった。FAXの代替は電子メールではなくECモジュールかも、など
• 地域支援　　……コアとなる中堅・中小企業の支援。新しく白書もでた小規模企業の支援。国などからの制度設計の視点ではROIを意識せざるを得ないが、現場は「個」の特徴に注目せざるを得ないし、成功事例はその個性を意識したところにしかない

他には、栗山先生の一連の研究にあるプロジェクト成功可否に大きな影響を与える要素としての「経営者」というお話が、改めて非常に示唆に富んだものだと思いました。IT資産価値研究会も単なる財務的な評価ではなく、意思決定に資するようなより実質的な評価を模索しているわけですが、そこには客観的な確からしさが担保される指標だけでは不十分である、という葛藤が常にあるように思います。プロジェクトの成功要因として「経営者のコミットメント」を挙げるのは、お手軽だし正しい。しかし、ワイルドカード過ぎて空虚な話になり勝ちなわけで、そこを掘り下げていくというお仕事の過程をお聞きして、どこか似たような葛藤を抱えておられるような印象を受けました。いわゆるアートとサイエンスの狭間にはありがちな話なのかもしれませんが、なんとか次の締め切りまでには自分の方も何か形にしたいものだと思います。

（文責 Ishii Akinori IT-Coordinator）

ECMの過去・現在・未来

毎度のご挨拶と化していますが、ご無沙汰しております。

AIIMが「ECMの次」をあからさまに模索している中、改めてECM業界に寄せられる期待について、この15年で感じた変化についてまとめたいと思います。

ECMってなんだっけ？

ECM（JIIMAの訳語では統合文書情報マネジメント）とは、企業の文書情報管理の基盤を中央集権的に持ち各業務システムと連動させることで、一貫したポリシーに基づいた文書情報の管理を実現するコンセプトであり手法を意味します。これはかつて流行したIT業界3文字略語の特徴をそのまま備えた用語なので、ERPがそうであるように、手法・コンセプトを意味すると同時に、ツールとしてのパッケージソフトウェアを呼ぶ名前にもなっています。

過去

ソフトウェアとしてのECMは、技術的には3つの構成要素から成り立っています。（元々は2つでしたが、今では3つ目もほぼ必須と考えて良いでしょう）

1. 文書ファイルを保管するファイルシステム（ストレージ）
2. 文書のメタデータ（属性情報）を保管するデータベース
3. 全文検索インデックス

の3つです。

「文書の本体と、その文書に関する付加情報（メタ・データ）を峻別しつつ一貫した管理ができること」という目的に即した構造です。紙文書のファイリングの文化を継承し、正しく分類整理することも重視されました。したがって、当時重視されていた機能は以下の様なものでした。

• 階層化された整理構造に綺麗に文書を格納できること
• 事前に明確に定義属性情報を一律に関連文書に割り付けること
• 入力された属性情報に基づき素早く文書を見つけられること（後に全文検索も）
• 各文書の最新版を明確化するための履歴管理と編集ロックができること

他にもそれまではサインや印鑑で担保されていた文書情報の確からしさを担保するためのワークフロー機能や、ユーザの行動履歴を保管する監査証跡などの機能もありましたが、それぞれにトレードオフがあり、すべてのユーザが利用するというところには至りませんでした。

現在

主にWebの世界が牽引したその後の情報システムの発展を受け、ECMのコアバリューも変化してきています。今、文書情報のより良い管理手法というものを考える時、紙文書のファイリングを踏襲したものとは異なる視点が導入されました。今、ECMに期待されている機能は以下の様なものです。

• 文書と文書の関連性を保持すること
• 後から定義された属性項目や任意のタグなどの動的なメタデータを文書に貼り付けられること
• 他のユーザのアクティビティを把握できること
• クラウドに文書を配置しデバイスを問わずアクセスできること

関連性

文書同士の関連付け情報はAlfrescoで言えばアソシエーション機能、いわゆるリレーションのことで、関連情報の使い方が業務毎にブレ幅が大きいため、以前はそれほど利用されていませんでした。しかし、例えば別々の組織・プロセスが主管している製造図面と施工図面を関連付けることで、メンテナンス時の障害から製品側へフィードバックを返すなどのフォロー業務の漏れをなくすことができたり、設計標準と設計図面を結びつけることで標準を更新したタイミングで影響を受ける図面を洗い出したり、ということができるようになります。

ECM製品は標準UIを持ち、そのままインストールしても文書の保管や版管理、アクセス権管理などのメリットを享受できる作りになっていますが、やはり他の業務システムの共通バックエンドとして利用されることでよりその効果が高まります。関連情報はまさに組織や業務を横断したトレーサビリティを実現する機能であり、その効能が理解されるようになるまでに少し時間がかかったということかもしれません。

動的なメタデータ

アスペクトやミックスインなどと呼ばれる、後付けの属性定義を実現する機能は比較的後発のものです。やはり、初期のECM製品はRDBMSへのマッピングが単純だったこともあり、（もちろん、業務ニーズが比較的固定的だったこともありますが）、こうした機能は提供されていませんでした。後付けが可能ということは、文書の分類（文書型定義）とは別に個別の文書に対して貼り付けることが可能ということでもあります。

しかしこの機能は、変化する業務要件に対して追随するための型定義を行っていくということなので、実務上はやはりハードルが高かったと言えそうです。かわりに、最近よく活用されているのが、タグ付けの機能です。

元々、伝統的な文書管理の慣習にのっとって綺麗な階層構造を持たせなくても検索機能さえ十全に備えられていれば管理精度は落ちない、という考え方が少しずつ市民権を得てきていたという経緯もあります。その上で、タグ付けによる情報整理の効能をyoutubeなどのコンシューマ向けのWebサイトで各ユーザが学習してきているので、アスペクトやミックスインのような学習障壁の問題がなく、実際によく活用されている機能と言えそうです。

弊社ではこれらの点も踏まえてNoSQLベースのECMを開発しました！！（宣伝）

アクティビティ

監査証跡はとにかくログを残しておいて有事の際に証拠や手がかりとして使おうというものでした。使うかどうかもわからない情報の記録に毎回コンピュータリソースを消費し、ストレージも占有するということもあって、よく吟味した上で適応を見送る、というケースも散見されました。

各製品のWeb化が完了した後の世代になるとWriteイベントは補足するがReadに関してはWebサーバのアクセスログで代替する、なんていうケースもありました。

SNSの台頭と、タイムラインビューの一般化を受けて、自分や同僚の直近の活動履歴を表示共有することのコラボレーション上のメリットが注目され、現在では監査証跡よりもこちらにより強い関心を持たれてるという印象です。（もちろん業務領域によっては監査証跡の方が有効であるケースはあります）

クラウド（とモバイル）

数年前まではECMベンダ各社ともクラウドは重要なトレンドだがECMへの適用は後回しになるだろう、と主張していました。現在では、クラウドに乗せるべきものは積極的に乗せてそのメリットを享受しよう、という主張が一般的です。

Dropboxライクな環境を業務システムの世界に導入するための、EFSSなんていうキーワードも出てきています。

ただ、やはりあくまでハイブリッド、使い分け、というのがECM業界全体のスタンスということではありそうです。すべてがクラウドに乗るわけではない、と。

弊社ではオンプレミスリポジトリに対してもファイル同期を行える製品をご提供しています（宣伝）

そして、未来

将来についても幾つか考えていることがあります。整理しきれていませんが、簡単に頭出しだけ。

まず、ソーシャル系の機能、例えばいいね！ボタンなどは現在の製品にも搭載されていて場所によっては使われています。しかし、その本格的な活用はまだこれからだと思います。

次に、アナリティクス系の機能、これも現在進行形の商談のスコープに入ってきているという認識ですが、やはりまだまだ発展途上だと考えます。ログや全文検索インデックスへの解析には一定の成果がありますが、機械の主張・助言を業務上どのレベルの「確からしさ」があると判断するのか、というハードな問題をこれから段階的に解いていく、というのが事の本丸ではないかと考えています。

次に、ソーシャルグラフとアグリゲーション。友達の友達まで開示、などという権限モデルは現在の通常の業務システムにはないものですが、「なんでも完全公開というのはナンセンスだが、なるべく共有は進めたい」という考え方はそれなりに一般的なものであるので、一定のニーズがあるのではないかと思います。さらに、アクティビティやここのコンテンツについても、自分以外のメンバーに「読んでもらう」「気がついてもらう」ということに意識的な仕組み作りの必要性もあるのではないかと考えます。詳細はまた機会があれば！

最後に、プルリクエスト。少し前に就労規則をGithubで公開、さっそくプルリクも！ というニュースがありました。文書に関してもプルリクエストベースのコラボレーションの効能というのは間違いなくあると思います。問題は、差分ベースのコンテンツ管理というのは、ECMの基本思想とある意味で正面からぶつかるということですね。ECMは、広く多様な業務にかかわるコンテンツを抱え込むために文書本体には手出しをせず外側に管理情報を付加するという手法を採用してきました。対立するコンセプトとしては例えばXMLデータベースなどではタグ単位での差し替えなどが可能でしたし、ソースコード管理システムを下敷きにした差分管理に特化したソリューションなどもありましたが、これまでのところECM以上の成功を収めてはいません。もしかしたら単に早すぎただけかもしれませんし、中央集権的なリポジトリを実現するためにはやはり「中身」に入り込むと破綻するのが世の真理なのかもしれません。しかしながら、差分情報を複数のユーザが取り交わせるという業務スタイルの強力さは、人を引きつけるものがあると思います。これも深掘りすると長くなるので、詳細はまたということで･･･

（文責 Ishii Akinori IT-Coordinator）