続々 ままならない話

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

　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）