ECMサミット2016を開催しました

またもやかなり時間をあけてしましました。その上、事後報告ですが、日本文書情報マネジメント協会JIIMAのイベントでECMサミットをやりましたので、そのご報告をしたいと思います。

今回のテーマは『ワークスタイル変革とECM』でした。パネルディスカッション形式にさせて頂きました。パネリストとしてご参加頂いたのは、IBMの三ツ谷さん、OPENTEXTの市野郷さん、Hylandの金井さん、そして富士通総研の小林さんの4人の有識者の方々です。私は、事前のナビゲーションと司会を担当しました。

色々と反省点の多いイベントとなってしまいましたが、以下私がナビゲーション部分で表現し切れなかった部分を含めてテーマの趣旨やそこで語られた内容についてご紹介したいと思います。

ECMサミットのテーマは毎回ECM委員会のメンバーが定例会の中でディスカッションをして決めています。都度のアンケートの中でリクエストがあればなるべくそれに沿ったものにしたいと思いますが、毎回それなりに苦労と議論があります。今回は確か、AIIMがDigital Transformationなどより幅広いテーマに乗り出して頑張っているという話をきっかけに、Digital Transformationというと大袈裟でバズワードに見えるがワークスタイル変革では現在進行形のどの企業にとっても現実的に取り組みを始めているか検討中の地に足がついたテーマと言えそうだということでまとまりました。実際、日頃の提案でも取り扱うことがある題材です。

ただ、当日もお話させて頂きましたが、ワークスタイル変革自体は例えば労働負荷の軽減など労務的な文脈が強い領域ですし、オフィスレイアウトを見直して創造的な議論を引き出そう、などのおよそECMとは無縁な取り組みもたくさんあります。それでも、ワークスタイル変革の成果を具体的に出していくとためには、文書情報（を含む業務情報）の管理精度の向上が求められるだろうという思いもありましたし、実際に提案の現場での顧客との対話や情報共有を推進した事例などネタとなる情報はそれなりに集められるだろうという手応えを感じていました。

時短やリモートワークを推進すると、（これまでと比較すると）限定されたリソースで個々の仕事を回さなければいけないケースが増えます。1人の人間に情報を集中させることで情報共有を省略するような働き方は有効ではなくなります。物理的に人と物が集約されていることに依存している業務スタイルは、リモートワークによって確保される労働力を有効活用することができないという大きな弱点を持つと評価されることでしょう。時間的空間的に業務（とそれに必要な情報）を分離可能にする必要があり、それこそ我々が推進してきたECMの価値なわけです。

（この辺り、内部のディスカッションでは20年近く前からあったサテライトオフィス構想とその当時の顛末などかなり突っ込んだ内容がたくさん出てきて非常に刺激的だったのですが、そのまま外には持ち出せないので関心があるかたは是非JIIMAとECM委員会に加入してください！）

当日のディスカッションは、上記を結論の先出しにならない程度に希釈したナビゲーションを私が喋り、そこから、

・ワークスタイル変革をどう捉えているか

・その成功要因は何か

・成功要因の根拠となるような事例はあるか

・反対に注意点や失敗などはあるか

というような設問に各パネリストからの回答を求めるスタイルで進めました。

印象に残ったところを幾つかご紹介させて頂くと、唯一コンサルタントという製品ベンダを代表しない立場でご参加頂いた小林さんの「具体的な特定業務の改善はBPR、それ以外の全体を底上げするような取り組みがワークスタイル変革」という整理などは会場の反応も大きく、皆さん感銘を受けている様子でした。（個人的にはこの結論に至る前段階の、「SIerの本分はBPRである」という言い切りが素晴らしいと思いましたが）

OPENTEXTの市野郷さんからはそれこそDigital Transformationなど広い視点からのトップベンダーらしいコンセプチュアルな説明が整った形で提示されました。それに加えて、ワークスタイル変革の本質は（良い）労働力の確保である、という立ち位置から一貫性のあるご回答を頂けたことにより議論の見通しが良くなったという意味で司会としては非常に助けられました。

Hylandの金井さんは純外資系ベンダであるにもかかわらず（？）、非常に丁寧に設問の意図にそったご回答をご用意頂きました。そして、実際にアメリカで最先端の（自社製）ツールを活用した在宅ワーク中心の働き方を体現しているという立場からのご発言を頂くことで単なる欧米式礼賛の恐喝的マーケティングになることを回避できた点もとてもありがたかったです。

同じく体現者の立ち位置から立体的なご説明を頂いたのがIBMの三ツ谷さんです。社内制度を当事者としてご紹介頂き、「信頼」関係の確立が実際どのような形で効いてくるのかをお話いただけました。会場の反応としても、この部分の具体性についてご評価頂くと声がありました。

全体を通してみると、HylandさんとOPENTEXTさんという専門ベンダからは「統一基盤（プラットフォーム）に揃える」ことのメリットを強調する発言が多く、より統合的な視点にたつ富士通総研さんとIBMさんからは状況に応じたツールの使い分けのお話が出てくるという差異が印象的でした。この辺りの整理は当日は力不足で言及できませんでした。（共通点や差異をわかりやすく提示するのはファシリテーターの役目だと思いますが完全に能力が不足していました）

相変わらずテキストだけの色気のない投稿ですが、取り急ぎ開催のご報告まで

石井

AIIM2016に行ってきました

毎年恒例（？）の行事として、米国のAIIMカンファレンスに参加してきました。今回もJIIMA（日本文書情報マネジメント協会）からの派遣という形で、ABBYY社のご協力もあってAIIMプレジデントのジョン・マンシーニ氏とも打ち合わせなどをさせてもらいました。詳しいレポートは月刊IMに投稿予定ですが、まずはご報告まで。

http://www.aiimevents.com/events/aiim-conference-2016/event-summary-981cb8aa25d64787b08466904f21a986.aspx

 

会場はニューオリンズで、私が初めて参加した3年前と同じ場所でした。プレジデント及びゲスト2名のキーノートセッション、業界の主な視点（ガバナンス、とか、エンゲージメント、とか）毎のパネルディスカッション、ラウンドテーブルセッション、一般的な形式のセミナー、などの基本的な構成は例年と変わらず、といった印象です。

一昨年、昨年と、近未来を見据えて、ECMというキーワードの陳腐化について真っ正面から捉えた言説が散見されていたのですが（昨年にいたっては「何か新しいキーワードが必要」とまで言っていました）、特に新しいキーワードが発表されたかというと、そんなことはありませんでした。概ね落ち着いた調子で業界の新しい動向を共有しあう会であったかと思います。

（むしろ、「記録管理という実験は失敗に終わった」とか「文書管理は死んだ」みたいなストレートな煽りを見かけなくなった印象です。たまたま私が参加した枠になかっただけかもしれませんが）

ゲストスピーカーは、Socialnomics（訳書『つぶやき進化論 「140字」がGoogleを超える! 』）の著者エリック・クァルマン氏と、The Future of Workの著者ヤコブ・モルガン氏のお二人でした。このあたりも、ソーシャルだとかデジタル変革などの伝統的な文書管理・記録管理に収まらない範疇をターゲットとして情報発信を続けているAIIMらしいラインナップであると思います。

プレジデントであるジョン・マンシーニ氏は今年でその席を降りAIIM内では別の役割を担う予定だそうですが、その彼のキーノートセッションではAIIMのテーマは一貫して「People, Process and Technology」である、と強調されていました。ECMコンサルタントの立ち場としては、コンテンツでもドキュメントでもなく「プロセス」が強調されていることにはある種の驚きがあります。実際には、人とプロセスを結びつける技術はすべてAIIMの関心領域に含まれる、ということで、時代によって変遷する技術のところが個別のテーマとして深掘りされる、という建て付けで、コンテンツ・ドキュメントとそれにまつわるツールや手法はそちら側ということのようですが、普段はプロセスとコンテンツをどこまで分離できるかということに頭を使うことの方が多いので、そもそも自分達が相手にする問題領域には先天的にプロセスが備わってるはずである、という視点は非常に興味深かったです。

その他印象的だった点としては、eSignatureのラウンドテーブルで「まだ導入できそうにない」という立ち場で最初にお話をされていた人が日系企業の方だったというちょっと出来すぎなくらいのシチュエーションがあったり、Infomation Governanceはかなり一般的な宣伝文句として各社のブースやパンフレットに記載され特に製品としての競争優位を争うポイントではないように見えたり、デジタル変革の議論ではやたらとDisrupterとかDisruptionという表現が使われているように感じたり、ということがありましたが、その当たりはまた時間があるときに深掘りしてみたいと思います。

（文責 Ishii Akinori IT-Coordinator）

 

ECMサミット2016（冬）開催しました

例によって、かなり出遅れた開催報告です。申しわけありません。

まず一番大切なことから。資料ダウンロードをようやく開始しました。ご参加頂いた方々も是非またご覧になってください。

今回のテーマについて

ECMのミライ〜知識・協働・ディスカバリーの先へ〜というテーマを掲げました。ミライという言い回しはマーケティングのバックグラウンドを持つ先代委員長梅原さんのお知恵をお借りしてつけたものです。委員会内でのディスカッションにおいて、

「アメリカに対して日本はこんなに遅れている」という一本調子には皆食傷していると思うが、日本でもコンテンツ管理に課せられる責任や課題はとっくに変化している。各企業は新しい課題に個別に対応しつつも、それをコンテンツ管理や文書管理というキーワードと結びつけて考えていないということではないか。

という論点が浮かび、それをサミットのテーマにいかに落とし込むかというご相談をさせて頂きました。

この論点・問題意識は委員会中核メンバーである富士通総研の小林さんの最初のプレゼンで丁寧にカバーされていると思います。

一定以上の規模の組織においてはその管理運用状態は別として、文書管理規程がすでに整備されていることが多いはずです。しかし、ほとんどの場合それは「紙の」「完成した」文書の管理ルールを定めたものか、そのルール自体はそのままに対象範囲だけを「電子的な」文書に拡大しただけのものであると考えられます。言い換えると、

• いわゆる文書管理規程とは完成された文書に限定された管理ルールである。
• それが限定されているのは成立した時点では電子的な文書作成プロセスが現在の様に一般化されていなかったからである。

ということになります。しかし、一方で例えば個人情報保護であるとか、情報セキュリティであるとか、ITの普及に伴い各企業において情報全般を管理したり保護したりするためのルールはこれまでも強く要請され、実際にそうした管理体制を整えてきてもいるわけです。これらの電子的情報に関するルールと文書管理規程は縦割りで完全に分離されているのが多くの企業の現状ではないでしょうか。

その分離の問題に焦点をあてるというのが、今回のテーマの狙いの1つでありました。

なぜディスカバリーを取り上げたか

知識・協働・ディスカバリーという副題に並べたキーワードですが、恐らく多くの人にとってディスカバリーだけが馴染みが薄く、また具体性の高い単語であったかと思います。知識はナレッジマネジメント、協働はコラボレーション、という言い方でこれまでのECM関連の話題の中でもそれなりに触れられてきたものです。（ナレッジマネジメントもコラボレーションも、「完成済み」文書の保管庫としてだけないリポジトリの活用用途の典型的なシナリオと言えます）

それでもあえて具体的にディスカバリーを取り上げたのには理由があります。1つはこれが日本の特に製造業などの輸出産業において非常にクリティカルな問題となり得るのではないかという危機意識です。もう1つは、ECM委員会としてECMというメリットが分かりづらい技術・コンセプトを説明する具体的な事例としての分かりやすさです。

危機意識については詳細は資料等をあたって頂くべきかと思いますが、アメリカの裁判制度においては自身の主張とは無関係に係争のテーマと関係する証拠情報をまとめて期日までに提出する義務があり、それを果たせないとペナルティが科せられる、というの制度上のギャップが問題になります。

今日では電子的な情報はあちこちに残すことができるため、紙の時代では捨てられていたあるいは「捨ててしまった」と主張しても無理がなかったメモや細かいコミュニケーションの履歴も、証拠性を持ち得るとされます。となれば、それらの情報を整理していつでも取り出せたり、あるいは削除すると決めたら確実に削除しているという運用実態を示せないと、本当に関係するかどうかわからないもの含めて全部さらけ出さなければならなくなります。さらに専門家（弁護士）がその1つ1つをチェックするわけです。それにも莫大なコストがかかります。

残念ながら、ECMの様な統合的な管理基盤や、完成済み文書に限定されない文書管理ルールを持つ日本企業はまだまだ稀であると言わざるを得ません。情報の削除についても仮にルールがあったとしても運用実態としては怪しいものがあります。（例えば、メールサーバのメールが定期的に削除されるのでローカル保存をしている、というナレッジワーカーはたくさんいるはずです）

したがって、アメリカのルールでの裁判に巻き込まれた場合、日本企業は大きなハンデを背負うことになるわけです。ここにかかるコストとかペナルティは実際の判決とは無関係だということが重要です。悪意を持って喧嘩をふっかけられた場合、などでも対処の仕方が難しいわけです。このあたりはオープンテキストの大沢さんの講演で詳しく説明がされました。（残念ながら、公開用の資料は頂けなかったのですが）

大沢さんの講演は、パテントトロルなどの例を引いて、以上のリスクが高まっていることを示すと共に、「アメリカのルール」で戦う必要性を却下してもらえた事例などにも言及するなど、ホラーストーリー一辺倒ではない素晴らしいものでした。

ECMの方向性

ディスカバリーだけが今回のテーマではありません。IBMの三ツ谷さんからは、クラウド、アナリティクスの領域と繋げて利用範囲を拡大していっている方針が具体的に示されていました。リーダー企業の一角であるIBM社が、ECMリポジトリの技術をサービスラインのどこに位置づけているか、というのは業界の動向という観点では大きな意味を持ちます。

分析・可視化の道具としてのBI、アナリティクスだけでなく、人工知能のエンタープライズユースを進めている中で、今後ECMがどのような役割を演じることになるのか、という点は今後ますます関心を集めるところだと思います。この辺りはAiimにおけるInformation Chaos云々の議論とも深く繋がります。

ECMは非定型データに関してもSingle Place of Truthを実現するための仕組み、と言えるはずですが、その権威が人工知能と組み合わさった時の作用には大変興味があります。

Hylandの新井さんのプレゼンは、前回のサミットのパネルディスカッションでも明示されていたアプリケーションプラットフォームとしてのECM、というテーマにまつわるものでした。

各業務、各アプリケーションによって生み出され利用されるコンテンツに対し、横断的に管理精度を保証するのがECMの役目なのであれば、それらのシステムと併置して連携をとるだけでなくECMの「上に」個々のアプリケーションを乗せるという方向で、もっとシンプルに（アジャイルに）ビジネスニーズを満たせるはずである、という主張だと受け止めました。

業務切片から見た場合にそれが最適解に見えるか、企業のIT投資全体としてECMプラットフォームに依存することが良いことなのか、などの点ではまだ考えるべきことはたくさんありそうですが、少なくともコンテンツ（非構造データ）管理の角度から考えた場合、プラットフォーム（共通基盤）になる、というのはそのメリットを最大化させる方向であると言えそうです。

その他

今回、色々と混乱があり、結局最後まで募集ページにはどのようなタイトル・内容の講演が並ぶのかという説明を掲載できませんでした。であるにも関わらず、大変多くの方に集まって頂き、お借りした会場（かなり広いところなのですが）が満席となりました。大変ありがたいことだと思います。

ECMサミットは（無料セミナーであることもあり）JIIMAの取り組みの中でも集客がしやすく、またアンケートの回収率も高いことで（内部では）知られています。そのため、リピーターの方が数多くいらっしゃるものだとばかり考えていたのですが、今回アンケート項目を増やしてこれまでの参加回数を問うたところ、意外にも初来場の方の比率が高いということがわかりました。大変驚いています。また、集計の合理化という観点も含めて、Webフォームのアンケートサイトを用意し、アンケート用紙にもそのQRコードを印刷するという方法をとらせて頂きましたが、回答の半数近くがWeb経由という結果になりました。ご協力ありがとうございました。

引き続き、テーマの募集を行っています。ECMベンダ各社にまとめて聞いてみたいこと、などでも結構です。お気軽にお声がけください。

（文責 Ishii Akinori IT-Coordinator）

会社設立から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に絡まないコンサルティングで求められているとの共通点が色々と見えてくるということもあります。
　以上のことから、私は個人的にも「エンジニア（システムエンジニアおよびプログラマ）は最終成果物として動くものを納品するという責任の取り方がある。コンサルタントの仕事にはそれがない」という話をよくしています。

では何を売っているのか

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

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

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

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

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



（文責 石井昭紀）