update it, Inc.社長のブログ

昨日、Ver 1.1.0をリリースし、Word 2007形式でのエクスポートができるようになりました。

本当は同時に、「もうひとつ目玉機能」をリリースしようと目論んでいたのですが、どうしても間に合わなかったため、そちらのリリースは機会を改めることにしました。（でも近日中にリリースします）

さて、このもうひとつの目玉機能とは、Q&Aの管理機能のことです。今までcrossnoteではドキュメントにコメントを付与することでメールのように関係者に内容を伝えることができました。が、これだけではプロジェクト管理の観点で考えた時、もしそれが質問の場合、いつまでに、誰がその質問に答えなければならないのかを管理することができませんでした。

で、次回のQ&A機能のリリースでは、今までのコメントとは別に、まさにQ&A（質問と回答）を管理できる仕組みを用意する予定です。この機能を用いることで、以下のような事項が管理できるようになります。

状態（OPEN, CLOSE, …)、カテゴリー、重要度
回答期限、回答すべき人、…

質問は今まで通り、ドキュメントに紐付けて質問することもできますし、ドキュメントに紐付かない形での質問もできるようになります。

皆さんに使ってもらえるとうれしいです。

ドキュメント指向コミュニケーションの話では今までドキュメントに書けば、それを効率的に関係者に伝達する仕組み、という側面ばかり説明してきましたが、もうひとつ特徴的なこと（？）を書いておきます。それがタイトルの「メールをドキュメントに添付」という考え方です。

普通は逆ですね。メールにドキュメントを添付する、です。これはメールが主で、ドキュメントが従の関係です。この方法はメールを用いているので、使いやすく手軽である、という点がポイントです。

問題は、３点あります。

１）ドキュメントの最新版がどれなのかがわからなくなる

ドキュメントの実体をメールに添付してしまうと、やり取りを繰り返しているうちにどれが最新版だかわからなくなってきます。

２）メールボックスの容量を食う

ドキュメント分だけメールボックスの容量を食ってしまうため、メールボックスが肥大化し、管理上いろいろな問題を引き起こします。

３）送られてきたメールをどうやって分類するか？

メールはそのままにしておくとどんどんたまっていきます。後になって、「あ、あの件どうだったっけ？」と思って参照しようとしても、探すのに一苦労です。

上の２つの問題点は実はドキュメントのリンクを添付するようにすることで解決可能なのですが、この３番目の問題はリンクでは解決しません。

さて、以上のような問題点を魔法のように解決する方法、それが、「ドキュメントにメールを添付する」という考え方です。ドキュメントは１か所で管理するので、どれが最新かで悩むことはありませんし、メールボックスの容量を食うこともありません。またドキュメントは最初から分類されているので、メールを分類する手間がかかりません。

これによりフローの情報（メールの情報）を自動的に分類して蓄積できることになります。

このように発想を逆転させ、ドキュメントを「主」、メールを「従」の関係にすることで、コミュニケーションが効率化できるわけです。

３月末と言っていたWordへの出力対応ですが、3/31（月曜日）にリリースします。今までのcrossnoteは出力形式がプリントアウトするか、HTMLへの出力のいずれかしかなかったため、PDFにはプリントアウトで対応できるものの、修正できるフォーマットで出力できるようにして欲しい、という要望が以前よりありました。

特にMS Word形式での出力を望む声が強くありました。理由はこのようなところです。

■ お客様より改変可能な形式でのドキュメントの提出を求められている。（お客様側で、直接ドキュメントの修正ができるようにしておくため）

■ SaaS形式での提供の場合、いざという時に中のデータをすべて持ち出して利用できるようにしておかないと心配。

それで、３月末までにWord対応をお約束していましたが、お約束通りリリースできる運びとなりました。

今回のWord対応とは、Office Open XML形式での出力です。つまりWord 2007フォーマットですが、Word 2003でもMicrosoftのWord/Excel/PowerPoint 2007 ファイル形式用 Microsoft Office 互換機能パックをインストールすることで、読み書きできるようになります。

Word 2000/97フォーマットとしなかった理由は、Word 2000/97フォーマットは仕様が完全に公開されたものではないため、図形などのデータを正確に変換しようとした場合、非常に困難であったためです。Open Office XML形式は仕様が公開されているので、今後もきちんとした対応が可能であると考え、こちらで対応することにしました。

なお、ODF(Open Document Format)対応については検討中です。

今回のリリース(3/31)ではこのWord対応と同時に、もうひとつ目玉機能をリリースします。そのため、Version表記を1.0から1.1へ上げる予定です。

今日の日経新聞の第二部ではNTTが始めるNGN(Next Generation Network)特集になっています。そのトップページでCISCOのテレプレゼンスというテレビ会議システムが写真入りで紹介されています。

テレプレゼンスはテレビ会議といえばそうなのですが、今までのテレビ会議システムというと何となく相手がいるのがわかる程度で、正直言って画面はあってもなくてもあまり関係がない程度だったと思います。このテレプレゼンスは高速通信を利用して、かなり高精度で、かつワイドな画面を提供するので、まるで本当にそこに参加者がいるように思える程度の臨場感がある、というのが売りです。

値段はだいぶ高い（４０００万ぐらいと新聞には書いてありました）ようですが、ここまで臨場感のあるテレビ会議ができるのであれば、それなりの価値があるのではないかと思います。遠隔地にいる人が会議に参加するのに交通費がかからないというだけでなく、時間を拘束されないという点も魅力ですね。時間のないマネジメント層には受けが良さそうです。

一方でもしこれが安くなれば、なんでもかんでもテレビ会議で済ませられるようになるかというと、そうではないと思っています。以前、はてな社長の近藤さんがアメリカに渡っていた時に、日本との間をスカイプで常に接続して、画面を通して相手を確認できる状態にしていたのにも関わらず、意思疎通面での問題から結局は日本に戻ってきた、という記事がITmediaに載っていましたが、リモートでテレビ越しに会話するというのと、実際にそこに居て見聞きするというのではやり取りする情報の質が違うようです。

この情報の質の違いとは、たとえば現場にいれば、食事しているときとか、ちょっと休んでいるときでも会話だけでなく、相手の顔色やしぐさなどからいろいろな情報を読み取ることができます。テレビ会議システムは普通持ち運びできないので、そのシステムの前に座ったときだけ情報の交換ができます。このほんの少しの情報をやり取りする「機会」の差が、質の違いとなってあらわれるのではないでしょうか？

とはいっても、いつも現場にいれるわけではない場合もあります。遠隔地にいる人も交えて毎週会議をする、などといった場面ではやはりテレビ会議システムのメリットが大きいのも確かです。テレプレゼンスならば、相手の表情も読み取れそうです。いつか、使ってみたいですね。

昨日、ちょっと調べるためにメインのPCにOffice 2007のあるプロダクトを入れたのですが、同時にIMEが2007に更新されてしまいました。どうもその影響で漢字変換がとてつもなく遅くなってしまいました。

とりあえずググったらこの件についてはみんな困っていたらしく、対象法がいろいろと書いてありました。一番決定的なのはOutlook用の辞書がデフォルトでインストールされているのを外す、というもののようです。私の環境もこれでだいぶまともに戻りました。

しかし、このIMEの標準セットアップとしてOutlookの辞書を含め、そのためにIMEの動作が遅くなってしまうというのは、正しいことなのでしょうか？　おそらくかなりのOffice 2007の利用者はこのようなことに気付かずに、ただ「遅いな」と我慢してしまっている気がします。

Office 2007を入れたからといって、すべての人がOutlookを利用するわけではありません。使っていないのにOutlook向けの設定のために遅くなっているとしたら、大部分の人は不快に思うのではないかと思います。

せめて、インストール時に「Outlook向けの辞書を入れるか？」ぐらいのことは聞いてほしいです。そしてこういう状態になるのであれば、デフォルトでは入れないで欲しい、と思いました。

ドキュメント指向コミュニケーションとは、以前Collaborative Documentation Serviceと呼んでいたものとほぼ同じものです。Collaborative Documentation Serviceという言い方だと、何が出来るようにするためのものかがはっきりしませんでした（そもそも何のことだかよく分からん、というのもありましたが）。

ドキュメント指向コミュニケーションはその名の通り、「コミュニケーション」、つまり相互に理解し合うようにやり取りをすることが目的です。そのコミュニケーションを「ドキュメント」を元に行ってしまおう、という考え方です。

通常、例えばAさんとBさんがいて、AさんがBさんにメールで何か仕様に関することを伝えようとしているとします。この場合、Aさんが書くメールには、AさんとBさんの共通認識になっていることは書かずに、共通に認識されていないことを書くと思います。

AさんとBさんの共通認識になっていることは、ドキュメント化されているとしましょう。そしてAさんとBさんの共通認識になっていないこと、これがドキュメントの「変更差分」です。Aさんがドキュメントに書き加えたこの「変更差分」を自動的にやり取りできるようにすることで、コミュニケーションが取れるようにしてしまおう、という考え方がドキュメント指向コミュニケーションです。

もちろん「変更差分」は結果を通知するだけなので、互いの考えを表明しあう検討段階のやり取り（私はこう思う、のようなもの）はメールのようなフロー型の情報のやり取りで行うのが自然です。ドキュメント指向コミュニケーションにおいてもこのようなフロー型の情報のやり取りは必要で、例えばcrossnoteではコメントや質問の機能が相当します。

ただこの場合でも、ドキュメント指向というからには、それらのフロー情報もドキュメントに紐付いているわけで、後でドキュメントを参照すればそれらのフロー情報のやり取りも同時に参照できるようにすべきです。このように紐付けしておくことで、ドキュメントと一緒に、フロー情報としてやり取りされた非常に有用なナレッジが蓄積されることになります。

わたしはできるだけ多くの人に、「ドキュメント指向コミュニケーション」という考え方を理解してもらえるようにしていきたいと思います。

今までcrossnoteを一言で説明する言葉として、crossnoteとは「ネットワーク・ワープロ」と説明してきましたが、正直どうもしっくりきていませんでした。周りにも「？」という反応を示す人がいましたし、また「ワープロ」という言葉を協調してしまうと「ワードとどこが違うの？」という反応が返ってきたこともありました。

そこで、いろいろと考えた結果、「ドキュメント指向コミュニケーション・ツール」（Document Oriented Communication Tool）という言い方に変更することにしました。また以前Collaborative Documentation Serviceと呼んでいたものも、同じく「ドキュメント指向コミュニケーション」と呼ぶことにしようと思います。

crossnoteはワープロ機能をフロントエンドにしていますが、ポイントはコミュニケーション機能にあります。ドキュメントを書くことと、知識を共有するためのコミュニケーションをとること、この２つのことを同時に行ってしまおう、という考えが基本です。

だからワープロではなく、コミュニケーション・ツールなのだ、と。そして、コミュニケーションをドキュメントを元に行うので、ドキュメント指向コミュニケーションというわけです。

昨日のIT Mediaで「発注者ビューガイドライン」が紹介されていました。「システムの作り直しをなくしたい」――SIer9社がガイドライン公開

まだ全部を読んではいませんが、なかなかの力作です。というか分量がかなり多いです。想定する読み手が

■ 情報システム開発を請け負う側である、SIベンダの従事者

■ 情報システム開発を発注する側である、ユーザ企業の情報システム部門、および業務部門の各ユーザ

となっているのですが、SIベンダの従事者はわかるとして、ユーザ企業側の特に業務部門の各ユーザがこれを見て、果たして分かるかなぁ？　という感じがしました。

おそらく書いてある内容が、SIベンダの視点で書かれているからだと思います。実際外部仕様書を書くベンダ側という観点では、気をつけるべきチェックポイントがいろいろと具体的に書いてあり、とても良い資料のように思えます。でも発注者側の、特に業務部門のユーザがここに書いていることをきちんと理解できるまでにはだいぶ時間がかかるように思えますし、もし理解した暁には十分システムの上流工程設計で飯を食っていけるようなレベルになっているようにも思えます。

とはいえ、きちっとやりたいと考えているユーザにとっては（どの程度いるのかはわかりませんが）なかなか良い資料なのかもしれませんね。

エクストリーム・プログラミング(XP)で有名なケント・ベックの書いた本「Extreme Programming Explained – Embrace Change」のEmbrace Changeの日本語訳として有名な「変化を抱擁せよ」ですが、現実のシステム開発の現場ではどの程度「変化を抱擁」できているのでしょうか？　現実問題として大きなプロジェクトの場合、「変化を抱擁」して失敗した、という例も多いため、できるだけ変化しないで済むようにコントロールすることが多いと思います。

変化を受け入れるためには、できるだけ小さい単位で「完結」していることが重要です。その単位で完結していれば、完結する範囲では変化を固定することができます。一旦完結した後で、次回（次のイテレーション）で次の変化を取り入れればよいのです。逆にいうと、完結していない単位でいろいろと変化を抱擁してしまうと、収束しない、デスマーチ状態になりがちです。

大きなプロジェクトの場合、それを細かい単位で完結するようにするように進めるのはなかなか難しい部分も多いと思います。だからどうしても長めの時間が固定されることになる。これはある程度仕方がないことだと思います。

それでもやはり、できるだけ細かい単位で分けられるような構造にして、それぞれがイテレーションの1単位として完結できるようにすべきでしょう。そのような形にすれば、プロジェクト管理の観点からも非常に望ましい結果を得られると思います。

細かいイテレーションの単位に分解した場合、その当初「どういう仕様にしたのか」をきっちり管理することが必要です。ベースライン管理ですね。イテレーションを基準としたベースライン管理がきちんと出来ていることが「変化を抱擁する」ための最低条件だと思います。

ということで、ベースライン管理にはcrossnoteをどうぞ。（なんだ、結局宣伝か。）  😀

今月の日経新聞の「私の履歴書」は住生活グループ（トステムとかINAXなどの持ち株会社）の前会長の潮田健次郎さんが書いていらっしゃいます。非常に興味深く読ませていただいているのですが、特に他社との差別化にこだわったという辺りが、成功の鍵だったのだと強く印象付けられました。

今日（17回目）の話に中空構造の形材を使ったアルミサッシの話が載っています。アルミサッシのメーカーとしてはトステムは後発で、しかも当時はまだ中小メーカーだったころで、市場には既に大手メーカーがいたそうです。それにも関わらず後発のトステムが勝ち残っていったのは、中空構造の形材のために他社の製品に比べて強度があり、しっかりしていたこと、そして密閉性に優れていたことなど、他社との差別化をしっかりはかっていたからだと思われます。

そしてその差別化したことを営業担当者が売り込みにおいて、とても分かりやすくデモをして見せた、ということも大きな要因だったようです。商品に差別化を図り、その違いをはっきりアピールすること。とても大切なことだと感じました。

では、当社のcrossnoteはどうかというと、もちろん差別化を図っているつもりなのですが、まだまだアピールの仕方がだめというか、こちらが差別化したつもりの部分がきちんと伝わらないことが多いと感じています。「差別化の見せ方」の問題ではないかと。

トステムは自社のアルミサッシの良さを、大手の先発メーカーのサッシと並べて実際に勢い良くホースで水をかけて実験して見せて、密閉性の良さをアピールしたと書いてあります。できるだけ分かりやすい方法で、差別化のポイントをアピールできること、このことが非常に重要なのだと感じました。