aegif CTO blog

御礼

Alfrescoセミナにご参加いただいた皆様、ありがとうございました。講演者の方々にも改めてお礼を申し上げたいと思います、、、が、恐らくここを読まれていることはないでしょうね。少なくともAlfrescoの2人は日本語が読めないですし。

私も最後の質疑応答の際には壇上に上がらせて頂きましたが、結局半端に司会のようなことをするだけになってしまったので少し反省しています。

その質疑応答セッションの中で1つ改めてここに記録しておいた方が良いと感じたやりとりがあったので、簡単にその部分だけご紹介したいと思います。

「コンテンツはDBに保存されるんですか？」

という趣旨の質問で、これは我々も非常に頻繁に出くわす質問です。Oracle社のECMとの比較で出てくることが多いと感じていましたが、今回回答したDenisはSharePointとの比較と捉えたようでした。私の経験ではこうした質問をされる方の意図は多くの場合コンテンツがDBに入っていればDBだけバックアップをとればリポジトリ全体のバックアップを取得できる（またその際には既存のバックアップツールがそのまま利用可能であると期待できる）、ということを念頭に置いているケースが多く、またSharePointと比較した質問をされる方はあまり具体的な運用負荷などまで検討されていないことが多いので、このギャップは非常に面白いと感じました。

回答は、「主にパフォーマンス上の理由でDBへの保管は採用していない。その方式はスケールしない」というものでした。実際に大きな提案の際にはベンチマークなどを実施して、Alfrescoが採用している（Documentumも同じですが）属性情報だけをDBに格納するという方式の方がスケールするということを示したこともあるんだそうです。確かにDB1箇所にすべてを集中することはパフォーマンス上有利とは言えないので、結果自体は説得力があるものだと思います。（そういった結末がある程度見えている勝負の場合、逆にどれだけ厳密にフェアな比較環境を用意できたのか勘ぐりたくなる部分もありますが）

他にもこれらの方式の比較には、暗号化やリソース競合の回避など、色々と比較すべき利点や欠点がありますが、まずはパフォーマンス、特にスケーラビリティというのが最初の回答であったということは強調しておきたいと感じました。SharePointとの比較論の中で彼らがスケーラビリティに言及する時も、常にこの違いは念頭にあるのではないかと思います。

（文責 Ishii Akinori IT-Coordinator）

Blog更新

このBlogはTypepadをサービスを利用して運営しています。実は数カ月前からTypepadのバージョンアップの告知を受けていたのですが、少しずつ新しい基盤に移行していくということで、その更新の順番が我々のところにはなかなかまわってこず少々じれったい思いをしていました。（恐らく法人ユーザの移行は相対的に遅れて実施する様にするという話だったと思います）

個人・法人ともにあれだけのユーザ数があると運用も色々と難しくなってきます。改めてSaaSやクラウドというキーワードが、運用の自動化や基盤の共通化との関連をからめて語られていることの意味を感じます。

BlogとECMではかなりソフトウェアの性質は違いますし、初めからSaaS型の展開を狙って作成されたソフトウェアと、元来オンプレミスを前提としてきたソフトウェアでも事情は異なるでしょう。また、Perlで書かれたソフトとJavaで書かれたソフトウェアを同列に語るのは不適切なケースもあるかもしれません。しかし、今後ECMもますますSaaSモデルでの調達が普及するであろうことを考えると、こういったバージョンアップ時の運用業務フローについては予め明確なイメージを掴むように努める必要がありそうです。（なかなか簡単なことではないと思いますが）

そういえば、GoogleのアプリケーションもいよいよIE6のサポートを打ち切りました。企業内の標準環境が依然IE6であるケースというのはまだまだあることだと思います。ベーンダーロックインフリーやゼロフットプリントというコンセプトの意義を理解して頂く上では好機とも言えますが、結局目下の問題の解決でバジェットが埋め尽くされてしまう、なんてこともありそうです。

（Ishii Akinori IT Coordinator）

社内研修はじめました

これまでaegifで社内研修というと、元同僚の会社であるLCIさんのコンサルティング研修を新規採用時に受講してもらうくらいだったのですが、社内メンバーが講師になる形での社内研修をはじめてみました。

題材は、英語・会計・Alfresco、です。当然、私はAlfrescoの講師を担当しています。

Alfrescoに関しては教育パートナーとしてのライセンスの問題に留意する必要がありますが、すでに公式トレーニングのコースやマテリアルを見聞きしているので、それと同じスコープの研修を行うことはさほど難しくはありません。システム管理、Webクライアントの拡張とカスタムモデリング、API開発、WCMなどのメニューがあります。受講者である社内メンバのすべてが技術系というわけではないので、API開発のコースに相当する内容までやるのは少し無理があるかもしれませんが、いずれにしても所要時間も含めて講師としては目安がいろいろと把握できているので、他のコースに比べてもやりやすい部類の内容になるかと思います。（他のコースは一般販売されている教材を利用しています）

しかし、本当は、ECMというキーワードの周辺事情についての細かい話（体系立てて話をできるかどうか微妙なところだと思っています）とか、コンサルティングの具体的な手法など、技術系の話題以外のところに踏み出してみたいという気持ちもあります。通常業務がたてこんでいるのでなかなか準備の時間をとれませんが、こういう取り組みの中から教材の公開などができるようになると楽しいのではないかと考えています。その時はまたこのBlogで告知をしたいと思います。

（文責 Ishii Akinori IT-Coordinator）

Alfrescoを補完する技術の模索 株式会社クレアリンクテクノロジーさんとの話

[From セキュリティ・高速通信・安心安全データファイル転送・暗号化・WEB製作／株式会社クレアリンクテクノロジー｜HOME]

最近、何度かお打ち合わせをさせて頂いている会社の1つに京都のクレアリンクテクノロジーさんがあります。元々TCP/IPなどの通信の高速化技術を持たれているベンチャー企業で、最近ではそのテクノロジを援用した電子カタログプレイヤなどの製品も展開されています。（電子ブックというとE-ink製品だと思われてしまいそうなので、電子カタログとしましたが所謂電子書籍を作成・閲覧するための製品です）

通常、IRMやDRMの仕組みとAlfrescoなどのECMのコア製品は別れています。Alfresco単体でももちろんユーザ毎の権限管理はできますが、リポジトリ上での「読み取り」権限の保持者は、Alfrescoから当該コンテンツをダウンロードできてしまうため、コンプライアンスに重点をおいたニーズにはそのままだとマッチしないことも多いのが現状です。かといって、あまり重厚な施策や広範なオプションを製品そのものに抱え込むことも得策であるとは思えません。Alfrescoの場合は、案件毎の作り込み部分を極力快適に行えるようにしていく、という対応をとってきています。そうした対応の選択肢として、クレアリンクテクノロジーさんのAeroBrowserが使えるのではないか、ということでご紹介を頂いたのが縁で、何度か社長の水原さんとディスカッションの機会を持たせて頂いてます。AeroBrowser自体も非常に興味深く、またこの主の製品としては珍しく仕様を公開する方向で開発されているので、近い将来連携のソリューションを作ることができるのではないかと期待しているところなんですが、先日まったく別の角度で実りのあるお話をお聞きしたので備忘としてポストしたいと考えました。

別の角度、というのはクレアリンクさんとしてはむしろ本業である、ネットワーク高速化の分野についてです。AlfrescoはCIFSプロトコルのサポートを1つの売りとしていますが、プロトコルそのものの制約故に遠隔地にあるクライアントからの接続にはこの機能はほとんど利用できないという問題点があります。CIFSプロトコルは最近では非常によく使われているプロトコルであるため（だからこそ「無法地帯と化した共有フォルダ」問題、に対する解としてのAlfresco、というストーリーがありえるわけですし）、この問題を解決する製品というものいくつか市場には存在します。要するに専用のキャッシュを積んだゲートウェイを用意するという方式のものが一般的なんだそうですが、クレアリンクさんのように圧縮や最適化による高速化というのも実用段階にあるようです。また、MicrosoftもVista移行ではプロトコルのバージョンを上げる形で、新しいOSの間では問題はある程度解決されて来ています。

今回水原さんから色々と教えて頂いたおかげでWANアクセラレータの動作特性や効果についてある程度定量的な理解ができたように思います。AlfrescoのCIFS問題についても、すべてがすぐに解決するわけではありませんが、対応の指針が見えてきました。是非具体的な検証をしてみたいと思います。

（通常所謂NAT越えが必要な場合はCIFSのかわりにWebDAVを利用することが推奨されています。この場合もクレアリンクさんの製品による高速化の恩恵を受けることができそうです）

（文責 Ishii Akinori IT-Coordinator）

あけましておめでとうございます

年末に引き続いて、挨拶だけの手抜きポストで済ませたいと思います。

あけましておめでとうございます。aegifとしては5期目がスタートしたことになります。まだ経験が浅い我々としては、5年といえば何かまとまった成果がだせる期間であるような気持ちにもなるのですが、それに見合った成果が果たして残せているのか、と考えると、まだまだ十分ではないような気がしてしまいますね。（不十分だと言い切るのも、一緒に頑張ってきてくれたメンバに対して不誠実だと思いますが）

年明け後、このBlogではとりあえずJohn Newton氏を初めとする、コンテンツ管理業界の2010予想記事をいくつか順番にご紹介していこうかと思っています。今年の予想とこれからの10年の予想がもしかすると入り交じる形になってしまうかもしれませんが（まだ細かく読んではいないので）、流し読みをしただけでも結構気になる記述が散見されます。

それでは今年もよろしくお願い致します。

（文責 Ishii Akinori IT-Coordinator）

仕事納め

イージフは明日まで営業ですが、私 石井はお休みを頂く予定ですので、今日が仕事納めです。

社長Blog、IFRS関連Blog、某AlternativeBlogなどの弊社の各Blogライタ達に対するプレッシャという目的も含めて、毎営業日を目標に投稿している本Blogも本日で2009年分は終了です。

不況ですが、幸いにしてこの2009年、aegifもAlfrescoも好調を維持したまま終えることができたようです。ブランド力やマーケティングコストによるプレミアムがない分、不況下においてオープンソース製品が勢いを持つ、というのはある種の説得力を持つ話ではありますが、やはり我々が勢いを失わないまま今年を乗り切れたのはお付き合い頂いている多くの皆様のおかげであると考える方が、当事者としてもしっくりきます。（大局的に見て比較的正しいであろうアプローチを取っているという自負がないことはないのですが、実際にお仕事を頂ける時に、それが勝因だという実感は当然ないわけでして、、、）

来年もよろしくお願い致します。

（文責 Ishii Akinori IT-Coordinator）

「業務の可視化、は誰の責任か」

「業務の可視化、は誰の責任か」という問いから

[From aegif blog: 「業務の可視化、は誰の責任か」という問いから考えた事 (1)]

先日のポストに対し、「結局、誰の責任なの？」というある種もっともな質問が寄せられました。

先日の記事は、あくまでその問いに触発されて考えた事を書き散らしたものなので、問いそのものに答える意図はなかったのですが、確かにそこを無視した記述をしてしまったのは「看板に偽り」の類と見なされてもしかたがないかもしれません。

しかし、率直に言って「状況による」としか言いようがない話であることも事実です。こういう場合は、どういう状況によるのか、をもう少し掘り下げてみるべきですね。

• 何のために可視化をするのか。システム化か、業務改善か、制度対応か。
• システム／業務／統制などの各観点を網羅的に理解している人材がいるか。いないとしてそのポジションに一番近いのはだれか。

得意な人、目的に関してポイントを外さない記述ができる人、がやった方が良い、という原則は1つあると思います。

ただ、そもそも業務の可視化や要件定義の文書化に関してユーザ部門側の負担が増えて来つつあるのは事実です。特にパッケージベースのシステムが増えてきた中で、そのメリットを十分に受けるためには、現業部門との緊密な協力体制が必須です。システムサイドの人材の独断により現業部門にとって使用に耐えないシステムができあがってしまう、という悲劇は過去に何度も繰り返されています。その意味で、現業部門を強く巻き込むアプローチ自体には大きな意義があると言えるでしょう。

その意味で、やはり現業部門といいますかユーザ部門がオーナーシップを持つべきタイプのタスクであり成果物であると考えます。スキルや時間的なリソースの問題で対応する余裕がないということであれば、（かなり我田引水ですが）我々のようなコンサルタントを使うという方法もあります。最近ではBABOKという「ビジネスアナリシス」の知識体系も公開されています。こうした技術を活用して、品質の高い業務の可視化と評価を行いつつ、システム側にシステム要件定義を渡していく、というのが現状妥当と考えられているフローになるのではないかと思います。

（文責 Ishii Akinori IT-Coordinator）

「業務の可視化、は誰の責任か」という問いから考えた事 (2)

昨日の投稿をざっと見返してみると冗長な表現が多く、少し落ち込みました。

さて、ややもすればコンサルティングの価値の源泉の1つとも言えそうな「業務の可視化能力」「抽象的な評価能力・表現力」のようなものが、実はより単純そうに見える「表記ルールの遵守」ができるかどうかに依っているように見える。そして、その見かけ上の矛盾は、実は「表記ルールの遵守」というのが意外に難しいってことで説明がつくのではないかと思っています、というところまでご説明したところでした。

業務の可視化というお仕事の成果物は、多くの場合フロー図です。（マジカは非常に美しい例外だと考えるべきだと思います。少なくとも今この瞬間においては）。そして、フロー図そのものが作業のゴールであることというのは非常に稀です。フロー図に従って、業務を分析する、新しい業務に切り替えてもらう、システムを設計する、などの後続の作業があるのが普通です。そして、それらの目的をかなえるためだけであれば、何も細かく表記ルールに準じている必要はないとも言えます。実際、細かい文書作成に時間をとられるくらいなら開発作業を先に進めましょう、という提言には十分な説得力があります。

したがって、「表記ルールの遵守」というのは、多くの場合「絶対にやらなければならないこと」とは思われていない、ということが言えそうです。そして、そのことが難易度を上げ、できない人を生み出しているのではないかと思うのです。

「絶対にやらなければければならない」という認識がなければ、細かい表記ルールに気を配ったり、既に書いてしまった成果物との整合性を常にチェックして矛盾を回避したり、という地味な作業にはどうしたって力が入りません。その意味で「表記ルールの遵守」を「絶対にやらなければならないこと」だと思えるかどうかが、業務の可視化スキルの有無を決定づけているのではないでしょうか。

いわゆるコンサルタントと呼ばれる人間が、お客様側の担当の方やSEと呼ばれる人達に比べて業務の可視化というジャンルでアドバンテージを持てるのだとすると、その理由には2つあるのではないかと思います。1つは、フロー図そのものが仕事上の最終成果であるケースがままあるということです。お客様担当者であればその先の業務そのものが、SEであればシステムの開発が、より上位のゴールとして見えています。もちろん、コンサルタントもより上位の目的を忘れないように心がけているはずですし、むしろそう言う視点も価値の源泉の1つであるとされることも多いと思うのですが、フロー図を作った時点で納品、その成果物の品質で仕事の評価が決まってしまう、というプレッシャが後続タスクが明示されていない分だけより大きくなるはずです。そのため、フロー図の世界の中での品質を追求する＝表記ルールも極力重視する、という結果に繋がります。

もう1つは、陳腐な例えですが、いわゆる”煉瓦を積む人”のようなお話です。やはりコンサルタントの方が、そうでない人に比べて「表記ルールの遵守」がプロジェクトの成功確率を押し上げる、というある種教科書的なテーゼをちゃんと信じている、という傾向があると思います。何故その表記ルールが制定されているのかという背景を理解し、そのことにより将来のどういうリスクを抑えているのか、ということを踏まえた上で作業を行います。そのため、単純に強制される作業ルールとして「表記ルール」を課されているという立場の作業者に比べると相対的に遵守レベルは高くなることが期待できます。（この辺りは、細かく1対1でルールの意味を咀嚼しているとは限らず、人によっては感性でその意義を嗅ぎ取っているとしか思えないようなケースも多々ありますが）

逆に言うと、それが自身の評価に繋がるという環境があり、またルールを遵守することが成功に繋がるという理論的バックボーンに対する信頼感を寄せていない限りは、「表記ルールの遵守」というのは中々難しいことなのではないかと思うわけです。

くどい話を続けた上で最後は精神論か、と言われてしまいそうですが、私は以上のような理由から、「業務の可視化」を実行できるかどうかは個別の知識や技能によるというよりも、むしろコンサルタントですとかビジネスアナリストなどの役割を与え、その役割の意義をしっかりと理解させられているか、という点に大きく依存するだろうと考えています。そしてその役割に耐えられるかどうかが弊社のメンバに期待する条件の1つともなっています。

#でも、例えば中途採用の面接でその対応力が計れるかというと、難しいんですよね。。。

（文責 Ishii Akinori IT-Coordinator）

「業務の可視化、は誰の責任か」という問いから考えた事 (1)

先日、営業で伺った会社さんで、「20年くらい前まではSEと言われる人が『業務の可視化』の責任を持っていた。しかし今ではそれはユーザ側の責任だ、と言われてしまう。で、作ってみるとこれではシステム化に十分な情報が盛り込まれていない、となる。昔の仕事の仕方の方が効率的だったのではないか」という趣旨のご指摘を頂きました。

そのお話をお聞きした時に、私がコンサルティングサービスの現場で感じている問題との関係に思い至ったので、今回は趣向を変えて「オープンソース」ではなく「コンサルティング」のお話をさせて頂こうと思います。（因みにその場では、「我々の先輩にあたるコンサルタント諸氏がパッケージシステムの隆盛に乗じてSEと呼ばれる人達からその業務を引きはがした結果」という説を提示すると共に、教科書的な「ユーザ参加の意義」を指摘するという少々煮え切らないお答えをしてしまいました）

我々はコンサルタントとして、時にこの「業務の可視化」の部分のみをお仕事として受けることがあります（実際にはパッケージシステムとのフィット・ギャップ分析の一部として実施されることがほとんどですが、フェーズで区切ればまさに可視化だけを粛々とやることになるわけです）。プロジェクトメンバであるお客様側のご担当の方が文書を書く作業をアドバイザリという立場で支援させて頂くこともありますし、我々が主体となってインタビューから記述まですべてやらせて頂くこともあります。こうした経験の中から1つ言えるのは、確かに「業務の可視化」という作業は人を選ぶ作業に見える、ということです。

#議論が発散しがちな領域なので、以下ではERP導入プロジェクトにおける「プロセスマップ」やSOX法対応における「業務フロー図」のようなフロー図を描く作業を「業務の可視化」と呼ぶことにします。非常に乱暴ですが、ToBeかAsIsか、という違いすら考慮しないこととします。

お客様側にも（残念ならが）我々のようなコンサルタントを生業とする人間にも、品質の高い文書をすぐに描き出すことができる人もいれば、そうでない人もいます。個人差はかなり大きいと感じられます。特にこの種の作業を苦手とする人が陥り勝ちな問題としては、

• 用語が統一できない（同じ文書や部門などの名前が場所によって違っている）
• 粒度が統一できない（あるところでは「箱」1つで表現している作業が、別の場所では2つ以上の「箱」の連なりとして表現されている）
• 語尾などの語法が統一できない（体言止め、などのルールがところどころ破られている）

という表現上のルール違反があり、これらが大部分を占めているとも言えると思います。

もちろん、そもそも何を書いたら良いのかわからない、自分の業務を抽象的に評価することができない、という問題を抱えているように見受けられる人もいます。そういう人は最後まで図を描き上げることが難しいので、お客様が主体となって作業をするタイプのプロジェクトでは別の担当を立てて頂くことになりますし、我々が主体となって作業をするケースではインタビューが紛糾することになります（もちろん、なるべく効率良く情報を収集するためのテクニックも存在しますが、やはりこうした作業に対して相性が良い担当者様の方がインタビューも簡単に済むのは間違いありません）。前者のケースで、引き継ぎ時などに途中まで書いたものを見せて頂くと、ほぼ間違いなく上記の「ルール違反」が含まれている、、、ような気がします。

「業務を抽象的に評価・記述できない人」は表記ルールを遵守できない（ことが多い）、という結論になりますが、これは少し実感に反する結論です。

表記ルールが遵守できる人なら、「業務を抽象的に評価・記述できる」のでしょうか？

すぐにYESと回答することはできない問いではないかと思います。単純にイメージの問題としても、「表記ルールの遵守」のために必要なスキルセットよりも「業務の抽象的評価」に要求されるスキルセットの方が高度であるというのが、一般的な認識だと思われます。つまり、より簡単と思われる要求が、より難しいと思われる要求の「十分条件」にあたるという主張になっているわけです。

この違和感の原因を考えると、（少なくともここまでの理屈の上では、）「表記ルールの遵守」というのが実は結構難しい、あるいは、「業務を抽象的に評価・記述できる」というのはそれほど難しくない、のどちらか、もしくはその両方、ということになりそうです。そして、私は「表記ルールの遵守」が意外に難しい、という立場でもう少しこの問題を掘り下げてみたいと考えているわけです。

続きます、珍しく

（文責 Ishii Akinori IT-Coordinator）

eドキュメントJAPAN 2009：47th 画像情報マネジメントショウ

[From eドキュメントJAPAN 2009：47th 画像情報マネジメントショウ]

JIIMA主催のeドキュメントJAPAN 2009へ行ってきました。単なる見学者として、ですが、久しぶりの見本市です。

あまり時間がなく細かく各ブースを見て回ることはできませんでしたが、色々と勉強になりました。弊社ではカバーしきれない紙文書やマイクロフィルムの管理業務アウトソーシングについての発表と、グループウェアまわりを中心に見てまわりました。

Alfrescoなどの海外製品のように理念的なものが先行しすぎて具体的な利用のシーンが（若干、だとは思いますが）見えにくくなってきているものとくらべて、やはり国産のツールはシナリオがかなり具体的であるように思えます。逆に、想定と異なる業務フローやユーザ規模、文書規模の場合、どういう対応が取れるのか、そしてその対応は現実的なアプローチと言えるのか、という問いに対してどういう答えが用意されているのか、という点では難しい面があるんじゃないかと思います。（単純に見本市のブースでは説明しきれないだけ、っていう面もあるとは思いますが）

ITPRO EXPO 2009も同時開催されていて、製品版のWindows7には今日Dellのブースで初めて触れました（ベータはいじったことがありましたが）。Windowsとは3.1が出る直前くらいからの付き合いなのですが、今では発想が完全にMacユーザになってしまっているのか、単にベータを見ていたためか、あまりこれという感慨はありませんでした。やはり「XPモード」が露骨にエミュレーションになっているんだな、ということだけは確認しましたが。

うちが次に出展するときのこともちゃんと考えなくてはいけませんね。

（文責 Ishii Akinori IT-Coordinator）