update it, Inc.社長のブログ

今日は、開発中のプロダクト「crossnote（クロスノート）」のコンセプトであるCollaborative Documentation Serviceについて説明します。といっても、ここに書く内容はまだ秘密のことですから、このブログの読者にだけこっそり教えましょう  😀

ちょっと前のブログAPISの紹介第2弾では、crossnoteの対象とする問題領域として、プロジェクトに関わる人数が増えると、仕様を決めるために必要なコミュニケーション量が爆発的に増えることを挙げています。この問題を改善する一番いい方法は何かを考えぬいた１つの結論は、「無駄に伝達される情報量を減らす」ということです。

プロジェクトでは非常に多くの情報がやり取りされます。でもその大量の情報の中で、本当に意味のある情報というのは実は少ないのです。では、本当に意味のある情報とはなんでしょうか？　それは「今知っていないこと」だと思います。もし、今知らないことだけを効率的に伝達することができれば、無駄な情報を減らし、本当に必要な情報だけを伝達することができるのではないでしょうか。

一方で、整理・統合されていない情報には意味がありません。情報を伝達する際には知らないことだけを教えて欲しいのですが、後で「ここどうだったっけ？」と調べるときにはちゃんと体系だてて書いたドキュメントそのものであるべきですよね。

メールは「今知っていないこと」をやり取りするには非常に有効な手段なのですが、そこでやり取りされた情報は整理・統合されておらず、後になって最終的な結論を知るには非常に苦労します。

一方で、今まで設計に用いられてきたワープロなどで書かれたドキュメントには最終的な結論しか書いてないので、どういう経緯でそのようなことになったのかわかりません。またドキュメントのレビューなどでドキュメント全体を添付する形で皆にメールしたりしますが、これだとドキュメントを全部読まないと前回のレビューのときからどこがどう変わったのかがわかりません。改定履歴を作ったとしても参照しづらいですし、作るのに手間がかかります。

Collaborative Documentation Serviceの考え方では、ドキュメントを変更してコミットすると、その差分としてどこが変更されたのかが関係者に通知されます。通知された人は、そこをダブルクリックするだけで、変更の前と後を比較することができます。つまりどのドキュメントのどの部分がどう変わったのかが一目瞭然になるわけです。

プログラムを実際に開発されている人はピンと来ると思うのですが、Eclipseなどの統合開発環境をCVSやSubversionなどの構成管理ツールを組み合わせて使うと、他の人がソースコードのどこをどう変更したのかが簡単にわかります。要はあれのワープロ版が、Collaborative Documentation Serviceです。ただCollaborative Documentation Serviceは単なる構成管理ツールではなくて、オールインワン、つまり文章も図形も表も一緒に、今までのワープロを使うのと同じ感覚で簡単に使えるというところが味噌です。

基本的なコンセプトはこのようなものですが、crossnoteには実際のプロジェクトにおけるドキュメンテーションをより効率的に行えるための様々な工夫がされています。これについては次の機会に説明いたしましょう。

さて、現在開発中のプロダクト（コードネーム:APIS）の製品名（およびサービス名）が決まりました。

crossnote (クロスノート）です。

で、このcrossnoteとは何か？　ちょっと見た目はほとんどワープロです。それも機能的には、MS WORDとかに比べるとだいぶ足りないです。縦書きの機能なんてありません。HTMLエディタの機能もありません。Visual Basicも付いていません。

まあ、通常に文章を作ったり、表や図を描いたりすることはできます。またWORDに比べると、ちょっとアウトラインプロセッサっぽくて、構造的にドキュメントを扱うには適しているかもしれません。

ドキュメントの見た目はほとんどがテンプレートで決まってしまうので、テンプレートを選ぶ以外、あまりドキュメントを書くときの自由度はありません。そのかわり、非常に単純（シンプル）なので、わかりやすいかもしれません。

こう書いてしまうと、機能的に劣ったワープロのようにしか思えませんが、実はcrossnoteはプロジェクトの設計文書などを書くのにもっとも適したワープロであることを目指したプロダクトなのです。でも、ワープロと呼ぶのはあまり適切ではないので、より内容を的確に表せるよう、勝手に造語してみました。それが、Collaborative Documentation Service です。

では、このCollaborative Documentation Serviceとは何なのか。そしてcrossnoteのワープロ以外の機能は何なのか。それはまた次回の機会に説明したいと思います。

さて、私の会社で現在研究開発中のプロダクト（コードネーム：APIS）についての説明の第2弾です。

会社のホームページには「銀の弾丸」を目指す、と勇ましいことを書いているのですが、正直なところ、このプロダクトを入れたからといってプロジェクトの生産性がウン倍にアップするなんてことは決してありません。私達が目指しているのはそういうものではなく、プロジェクトチームが円滑に機能しやすくする、手助けのためのツールというか、サービスを目指しています。

私達の対象とする問題領域は、次のようなことです。

・プロジェクトに関わる人数が増えると、仕様を決めるために必要なコミュニケーション量が爆発的に増える。（図の中の矢印が示しています）

実際、プロジェクトの規模が膨らむと、生産性を向上させるために人をつぎ込む以上に、コミュニケーションの問題を改善するための人が大量に必要になります。つまり仕様を関係者全員に伝達して理解させたり、検討したり認識合わせをしたり、意見を調整したりレビューしたり、など、一連のコミュニケーションにかかるコストが膨大に膨らむということです。そしてこういったコミュニケーションがうまくいかないことが、プロジェクトにまつわる悲哀を生む原因になっていると思うのです。

私達のプロダクトはこの問題を改善するための提案です。具体的な説明は次回に譲りますが、一定以上のサイズのプロジェクトのコミュニケーションの問題を如何に解決するか、という観点で設計しています。

もちろんプロジェクトが円滑に機能するのは、チームメンバの前向きながんばりによるものであり、ただプロダクトを入れただけでは効果はでません。非常に勝手ながら、少しでも良くしていこうという前向きのプロジェクトのところにだけ入れて欲しいな、と思っております。

このブログを見ていただいている方の中には、安中はいったい何をやっているんだ？と思っている人も多いと思います。たまには私の会社でやっていることも書きましょう。タイトルのAPISとは現在開発中のプロダクトのコードネームです。（ちなみに商品・サービス名はこれとは異なる予定です）　

ホームページにも書いたのですが、弊社は現在、「まったく新しい形のコラボレーション・サービス」を目指して研究・開発中です。プロジェクトのチームワークの力を高める手助けとなるシステム・サービスを提供したいと考えています。このシステム・サービスを提供するためのプロダクトのコードネームがAPISというわけです。

APISとはミツバチの学名（正確にはミツバチ属の名前）です。ミツバチは社会性のある昆虫で、それぞれが役割を担いながら巣を作っていくイメージを、チームがプロジェクトを進めるイメージと重ねあわせて、APISというコードネームにしました。

現在、開発は7月末のM2を目指しているところです。その後、8月末にRC1、9月末にRC2とし、10月には1.0をリリースする予定です。RC1もしくはRC2についてはClosed βという形でお披露目できるかもしれません。

で、肝心な中身というか、どんなものなのかについては、今後このブログを通じて少しずつお伝えしていきたいと思います。お楽しみに。