友人が出した本を読んだので

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）