update it, Inc.社長のブログ

今日も引き続き、CDS = Collaborative Documentation Serviceの話を続けます。内容は、CDSがなぜセキュアでなければならないのか、という話です。

CDSはプロジェクトにおいて、共同で仕様や設計を進めるためのインフラとなるべき仕組みです。一方でセキュリティは様々な部分で総合的・網羅的に機能する必要があります。１つでもホール（穴）があると全てが台無しになってしまうのは皆さんも百も承知の話だと思います。ですので、セキュリティを担保する仕組みはインフラ部分に組み込み、総合的にコントロールできるようにすることがとても肝要なのです。

ではプロジェクトにおけるセキュリティとはどんなことがあるのでしょうか？　1つには役割に応じて、できること、できないことをはっきり分けるということだと思います。

通常のファイル・サーバのセキュリティ管理の仕組みの場合、ドキュメントに関しては、大雑把に言うと、所属させるグループ毎に見れるか、書けるか程度のことしかコントロールできません。例えばあるサブシステムを開発するチームにおいて、パートナー会社の社員の場合には印刷やコピー、メールでの転送などでデータを持ち出せないようにしたい、と思ったとしてもまずほとんど不可能に近いことがわかると思います。

CDSはプロジェクトのさまざまな関係者が使うことを想定していますので、どういう人がどういったことができて、どううことはできないのかをきちんとコントロールできなければなりません。上記で説明したようなことはインフラとなるCDSがコントロールできるようにすべきでしょう。また権限のない人が勝手にドキュメントを消したり中身を改ざんするようなことはできないようにしつつ、一方でわからない部分にはコメントを付けて質問できるようにする、などといったコントロールもできるべきだと思います。こういったことは、単に読める、書ける程度のコントロールでは実現できないことです。

最近、様々な情報漏洩に関する事件が報道されています。また企業にとっても情報は最も重要な資産の１つのはずです。いろいろな立場の人が関わるプロジェクトだけに、こういったセキュアな仕組みが本来必要なのではないでしょうか？

CDS = Collaborative Documentation Serviceは、非リアルタイム・コラボレーションの一種です。

いままでのコラボレーション・ツールの主流はむしろ、リアルタイム性を重視したものが多いと思います。例えば誰かがスプレッドシートに数字を入力したら即座に同じスプレッドシートを見ている他の人に伝達する、といったものです。それに対して、CDSの考えではむしろ、ドキュメントを書いている最中は他の人にはその修正内容は見せずに、ある程度きちんと推敲し終わった後で初めてコミット→他の人に伝わる、という形になっています。

実際、ドキュメントの修正がリアルタイムで伝達されることが求められるのは、オンラインでの会議など、特定の使い方をする場合に限られるのではないでしょうか？　通常はドキュメントはいろいろと検討や推敲を重ねた上で公表、つまりコミットするものだと思います。ですので、むしろ非リアルタイムのコラボレーションとすべきものだと思うのです。

CDSは非リアルタイムのコラボレーションなのですが、もう一方で「コンカレント」であるという特徴があります。コンカレントとは同時に協調して動作するということです。普通は、サーバにおいてあるワープロのファイルを開くと、他の人は読み取り専用でしか開けなくなると思います。つまり、一人があるドキュメントを修正している間は他の人はそのドキュメントについては一切修正ができなくなり、その人が修正を終えるまで待たなければならないというのがいままでのワープロでした。

CDSでは、基本的にコンカレント性を重視します。つまりあるドキュメントを誰かが修正していても、他の人も同じドキュメントを修正できるようにする、ということです。例えばAさんが第1章から第3章までを担当し、Bさんは第4章から第6章まで、Cさんはそれ以降の部分を担当する、などということが、CDSでは各自ドキュメントをローカルにコピーなどすることなしに、同じドキュメントを直接同時に修正することで、できてしまう、ということです。

CDS – これはCollaborative Documentation Serviceの頭文字をとったものです。以前のブログにも書いたとおり、このCollaborative Documentation Serviceというのは、crossnoteのキー・コンセプトです。

これを一言で説明すると、以下のようになります。

Collaborative Documentation Serviceとは –
『ドキュメントを書き換えてコミットするだけで、対象者に「どこ」が「どう」変わったのかを伝える仕組み』

私が何でこれを思いついたかというと、プロジェクトで次のようなことが良く起こっていたからです。

１．最初のうちはきちんと仕様をドキュメントに書いています。

２．プロジェクトが進むにつれて、様々な仕様変更が発生します。その仕様変更について、メール上でああしよう、こうしようとやり取りします。

３．プロジェクトが忙しくなってくると、上記の仕様変更内容をドキュメントに反映し忘れ始めます。

４．これではイカンということで、ドキュメントを修正してメールで回覧する方式にすると、様々なバージョンのドキュメントが散乱することになり、それはそれでどれが正式の仕様なのかがわからなくなりがちです。またちょっと直しただけで毎回でかいドキュメントを送りつけられ、どこが変わったのかをチェックしなければならない受け取り側もえらい迷惑です。

５．最終的に、ドキュメントは「当初の」考えを示すだけのものになり、実際の仕様とは大きく乖離した状態になる場合があります。こうなってしまってはなかなかドキュメントを修正する気力も出ません。

６．さらに後になって、仕様がどうだったかを調べようとすると、ドキュメントとメールの両方を調べなければわからず、大変な思いをします。

皆さんはどうですか？　いつも完璧にこなしているという方もいらっしゃるかもしれませんが、私は恥ずかしながら、上記のような状態になることが多かったです。でもそこでふと考えたのです。そもそもメールとドキュメントの２つのものを同時に書かなければならないことが間違っているのではないかと。

ドキュメントの情報は後で参照するときに体系だてて理解できる構造になっています。一方のメールの情報は順を追って読まないとわかりづらく、また体系付けられてもいません。

では、メールを書くのではなく、ドキュメントを修正したら自動的に差分が通知されるようにしてはどうか？　その差分の情報をメールのように皆に通知してはどうだろうか？　さらに自分の「考え｣を説明するためにコメントなどをいろいろと付けて、そのコメントをやり取りできるようにすれば、もうメールは要らないのではないかと。

これがCDS – Collaborative Documentation Serviceを思い立った原点です。プロジェクトが破綻する最大の要因は、仕様を纏め上げる作業、すなわち上流工程に問題がある場合だと思います。プログラミングの世界ではどんどんシステム的なサポートが充実してきているのに、上流工程部分にはシステマティックなサポートがありませんでした。この仕様をまとめ上げる仕事を少しでもバックアップできるような仕組みとして、このCDSを普及させていきたいと思います。

さて、引き続きcrossnoteのお披露目シリーズ、第５弾です。（すみません、そろそろワンパターンですね）
今日はアウトライン機能を使って、ドキュメントを編集するデモをお見せします。

上の図をクリックして、表示されたFlashのStartボタンを押してください。

crossnoteではドキュメントを直接ワープロのように修正することも出来ます。設計書や仕様書などを作る場合、今回デモしたようにドキュメント全体の構成をタイトルを考えることであらあら決めておき、後で中身を書くという使い方が多いと思います。そのような場合にはこのアウトライン機能は非常に強力な助っ人になると思います。

今週載せたFlashのデモですが、IEだと見れなかったようです。（FireFoxでしか確認せずに気づきませんでした。すみません）

今は直っていると思います。見れないと思ってあきらめた方、ぜひもう一度トライしてみてください…

さて、引き続きcrossnoteのお披露目シリーズ、第４弾です。
今日は大盤振る舞い（？）で、テキストの比較のデモと表の比較のデモの２つをお見せします。いずれも非常に短いデモですので、気軽に見てください。

まずはテキストの比較です。

上の図をクリックして、表示されたFlashのStartボタンを押してください。

テキスト枠が変更されたときの、中身同士の比較の例です。

次は表の比較のデモです。

このように、中身同士の比較を行うこともできます。

次回は、アウトライン機能を使うあたりについて説明したいと思います。

さて、引き続きcrossnoteのお披露目シリーズ、第３弾です。
今日はドキュメントの構成比較のデモをお見せします。

上の図をクリックして開いたFlash画面のStartボタンを押してください。

パラグラフが追加されてきた時の、構成比較の例です。crossnoteは通常のワープロとは若干異なり、ドキュメントはパラグラフやテキスト枠、図形枠、表枠などといった「部品」を組み立てて構成します。これらの「部品」がドキュメント上でどのような順序で配置しているかを表現したものが「構成」です。そしてupdateする前とした後でこの構成がどのように変化するかを比較する画面が、この構成比較です。

次回は、テキストの比較画面について説明します。

先日に引き続き、crossnoteのお披露目第２弾です。
今日はupdateボタンのデモをお見せします。

上の図をクリックして開いたFlash画面のStartボタンを押してください。

これはupdateボタンを押したときの動きを説明しています。自動的に同期Viewに切り替わり、他の人が変更した箇所が表示されます。また同時に開いているドキュメントも修正されています。

次回は、この先の比較画面について説明します。

今日はcrossnoteのスナップショットを、このブログを見ていただいている皆さんにだけ特別に、ちょっとだけ先行公開します。

こんな感じです。

（大きな画面でよく見たい人はこちらをどうぞ）

ま、見た目はワープロみたいなものでしょう。左側にプロジェクトを先頭にしたフォルダーやドキュメント、またそのドキュメントの中身がツリー上になって見えているのは通常のワープロとは違う点かもしれません。

大きな画面で見ないと良くわかりませんが、上のツールバーのところに、保存ボタンの隣の、左から２番目に表示されている矢印のボタンが、Collaborative Documentation Serviceを実現するためのもっとも重要なボタン「updateボタン」です。

また近日中に続きをお見せします。

さて、今日もcrossnoteの小さな工夫シリーズ、行きます。今日ご紹介するのはビュー機能です。（Eclipseを知っていると、いろいろと用語が混乱するかもしれません。これはEclipseのViewとは異なります）

crossnoteではWindowsのExploreのようにプロジェクトやドキュメントをツリー状に表示するための「ワークスペース」という画面があります。このワークスペース画面にはビューと呼ぶフィルター機能がついています。

ドキュメントを新規作成する場合には、ドキュメントがどのビューに所属するのかを指定します。このビューとは、例えば以下のようなものです。

「成果物」
「検討資料」
…

ドキュメントを作るにあたっては途中、いろいろな検討資料も必要になります。しかもこのような検討資料は無秩序に増えやすいと思います。そうすると、あるフォルダの中で、どの資料が最終的な結論が書かれた成果物なのかわかりにくくなります。実際、後からプロジェクトに関わった場合とか、あるサブ・プロジェクトの成果を利用して別のサブ・プロジェクトを進めるような場合には、どれがあらかじめ読んでおくべき資料なのかがわからず、後になって大切な資料を読み忘れていた、なんて経験のある人も多いのではないでしょうか？

このビュー機能を用いると同じフォルダー内でも指定したビューのドキュメントだけが表示されるので、例えば外部からの参加者に対しては成果物ビューの中の資料だけ読めばよい、などといった使い方ができます。なおすべてのドキュメントを表示する指定方法もあります。

なおこのビュー定義は、プロジェクト・ポリシーの設定にて、プロジェクト毎に独自の定義を行うことも可能です。