文書管理と図面管理

最近、図面管理についてのご相談を頂くことが増えてきました。がっちりした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）