update it, Inc.社長のブログ

さて、crossnoteの小さな工夫シリーズの第5弾です。今日はプロジェクト・キーワードという仕組みをご紹介します。

プロジェクト・キーワードとはプロジェクト毎に定義することができるキーワードです。例えば、

プロジェクト名　「APISプロジェクト」
プロジェクトID　「UPDATEIT-001」
システム名　　　「apis」
商品名　　　　　「crossnote」

のようなキーワードと値を予め登録しておきます。ドキュメントの中で「プロジェクト・キーワード（例えばプロジェクト名）の挿入」を行うと、値（例えば「APISプロジェクト」）に置き換わって表示されます。プロジェクト・キーワードの部分は背景色が水色になっているので、ドキュメントのどの部分がプロジェクト・キーワードになっているかはすぐにわかります。

プロジェクト・キーワードの値は1箇所で管理されるので、プロジェクト・キーワードの値を変更すると、そのプロジェクトのすべてのドキュメントについて、自動的に新しくセットされたキーワードの値に置き換わるようになっています。

同じように、ドキュメント毎にドキュメント・キーワードを定義できるようになっています。ドキュメント・キーワードとは、例えば「ドキュメントID」などのようなものを登録します。

さらに、crossnoteのドキュメントのヘッダーやフッターはプロジェクト・キーワードおよびドキュメント・キーワードを使って生成されるようにしています。これによって、個別のドキュメントの中のヘッダーやフッターを直接編集する必要がなくなり、プロジェクト全体のドキュメント・フォーマットを揃えることが出来るようになります。

今日もcrossnoteの小さな工夫シリーズ、第4弾です。今日は表のオートスケール機能をご紹介します。

仕様書をWordで書いていて、その中に表を載せなければならない場合、皆さんはどうやっていますか？　例えばマイクロソフト社のWordの場合、大きく２つの選択肢があると思います。

１．Word固有の表機能を用いる
２．Excelで表を書いて貼り付ける

Word固有の表機能の場合、表の構造を変更するときに苦労しませんか？　例えば列を追加したいときに、カラムの幅がうまく調整できず、苦労した経験がある人も多いのではないでしょうか？　ちなみにWordではカラムをコピーしてペーストすると、単純にインサートされ、表が右側に大きくなります。これによってページをはみ出すと、はみ出したカラムは操作できなくなります。これであせった経験をもつ人も多いのではないでしょうか？

また「列の挿入」で列を増やした場合には、テーブルの全体幅は保ったまま増えるようになっています。これはこれでいいのですが、文字の大きさは変わらないので、１つのカラムの幅がどんどん小さくなり、文字がはみ出して表が汚くなっていきます。

一方Excelのデータを貼り付ける場合には、オブジェクトとして貼り付ける方法と、形式を選択してRTFやWMFやEMFなどのフォーマットで貼り付けることができますね。でも皆さんのなかで、これを使い分けることが出来るようなエキスパートな人はどの程度いるのでしょうか？　さらに貼り付けてみると表が途中で切れてしまっていて、うまく表示される貼り付け方を探るという非生産的な作業に没頭した経験をお持ちの方もいるのではないでしょうか？（私です…）

いずれにせよ、少し大きめの表をWordで作るというのは、結構つらい作業だと思います。面倒くさいのでExcelで作ってしまい、別々に管理しているという人も多いと思います。

crossnoteではこの問題に対して、表が横方向にページをはみ出してしまう場合には、表全体のスケールを自動的に調整することで対処しています。例えばカラムを増やしていくと、自動的に表全体をスケールダウンして、横幅がページ幅内に収まるように調整するようにしています。その際には文字もスケールダウンしていきますので、表の形は崩れません。（ただし便利だからといってやり過ぎると文字がどんどん小さくなってしまうので、読みにくくなってしまいますけど）

さらには縦方向にも表を1ページ内で収めたい場合には「1ページに収める」と設定すると、全体が1ページに納めるように調整する機能もあります。

crossnoteは汎用ワープロと比較して見ると非常にシンプルです。見方によっては機能が貧弱に見えるかもしれません。しかし私達は、汎用ワープロ = Fat word processorではなく、プロジェクト用ドキュメント作成ツールとして、さくさくっとドキュメントを作り上げるObjective word processorを目指したいと思っています。

今日もcrossnoteネタの、crossnoteの小さな工夫シリーズ、第3弾です。今日はシーケンス・パラグラフをご紹介します。

設計書を書いていると、手順を説明することってよくありませんか？　たとえば以下のようなものです。

ハンバーグの作り方
(1) 玉ねぎをいためる。
　このとき、茶色っぽくなるまでしっかりといためること。

(2) 他の材料とあわせる
　いためた玉ねぎをボウルに移動し、パン粉などと合わせます。

(3) 形を整える
　中の空気を抜くようにして…

この(1)、(2)、(3)と番号を振ってタイトルを書き、その下に説明文を書くというのは良く使う手法だと思いますが、例えば代表的なワープロであるWordでこのようなスタイルで書く際、中の説明文を書きたいところに勝手にナンバリングされてしまいます。いちいちナンバリングを外す操作をしなければなりません。また説明文をいじっているうちに、下の項目がまた1から始まるようになってしまったりすると最悪で、結局自動ナンバリングをやめて手で番号を振りなおしたことも何度となくあります。

crossnoteでは上記のような書き方をするために、シーケンス・パラグラフというものを用意しました。シーケンス・パラグラフとは順序を説明するためのパラグラフという意味で、ナンバリングしたタイトルと本文という組み合わせの文章を書きやすくしています。

シーケンスパラグラフのナンバリングはアウトラインの構造に従って行われるので、ナンバリングが思ったように行われずにいらつくこともなくなると思います。また開始番号を指定することもできるので、節をまたいで通し番号で説明するなどといったことも可能です。さらには通常のパラグラフとシーケンス・パラグラフで切り替えることも簡単です。

今日も引き続き、crossnoteネタです。

設計書の場合、全体はA4なんだけど、途中の図表だけA3にしたい、なんてことが良くあると思います。そんなときってどうしていますか？

あるワープロソフトの場合、ページ設定の用紙設定の機能を使うと、「これ以降」と指定したところのページ設定を切り替えることが可能です。でも使っているとわかるのですが、ドキュメントの構成を変更するためにコピー＆ペーストを繰り返していると、気がついたら「これ以降」の設定がぐちゃぐちゃになっていることがあります。つまりA3で出すべき図表がいつのまにかA4に戻っていたり、逆にA4で出したい本文がA3に出力されてしまっていたりする、という話です。

この現象は「これ以降」というページ設定方法のために発生します。A3で書いた表や図でも、これ以降がA4としているページに貼り付ければA4になってしまうのです。また「これ以降」の設定部分を誤ってBSキーなどで消してしまうこともあります。用紙が混在したドキュメントで構成変更をするたびに、私は何とかしたいと思っていました。

crossnoteではページ枠というのを用意しました。アウトラインを表示するView上で「A3横」などといったページ枠を挿入し、その中にパラグラフや本文、図表を入れると、その枠内はすべて「A3横」の設定になるのです。ちょっとした工夫なのですが、アウトライン上で、どの部分がA3で出るのかを簡単に指定・確認できることでかなり使い勝手がよくなっていると思います。

さらに「A3横」のページ枠上の図・表はコピーしてペーストすると、自動的に「A3横」のページ枠が差し込まれた上でペーストするようにしています。これによって構成変更をしていても勝手に用紙サイズが変更されることがなくなりました。

これでちょっと大き目の図や表が必要な場合に、気軽にA3のページを差し込むことが出来るようになったと思います。

今日は開発中のプロダクト、crossnoteについての小さな工夫の１つとして、アウトライン機能について書いてみます。

私はワープロを使って仕様書を書く場合、いつも章立てや段落設定がなかなか思ったとおりにならずに悩まされてきました。皆さんはどうでしょうか？　メジャーなワープロの場合、ENTERキーを押したときに自動的に対象のスタイルを自動的に判別して変更してくれたり、ナンバリングしてくれたりしますが、場合によってはこれがかえって余計なお世話で、なかなか意図した状態にならなかったり、空白行に章が設定されたり、変な改ページが行われたりして、よくイライラしています。

crossnoteではシンプルな使い勝手を目指して、文章の構成要素として大きく次の2つに分けています。

１．パラグラフ（章や節などを表すもの）
２．本文（テキスト枠、図形枠、表枠など）

そして、パラグラフとするのか、本文にするのかはユーザが自ら選択して決めるというスタンスをとっています。つまり予めパラグラフ枠を挿入すればパラグラフですし、テキスト枠を挿入すれば本文になります。ユーザが指定した「構造」に応じてナンバリングされていくので、意図しない番号が振られることはありません。

普通、仕様書や設計書などを書く場合、あらかじめ全体の構成を考え、章立てを最初に作ってしまうと思います。crossnoteにはアウトラインをいつも表示しておくためのViewがあり、この上でパラグラフを追加してはタイトルを入力、と繰り返すことで全体の構成を作ってしまい、それから本文を書き始めるということができます。さらには本文の枠にもタイトルを設定でき、そこに書くべき内容をメモしておくこともできます。

アウトラインを表示するViewでは、パラグラフや本文はドラッグ＆ドロップなどで簡単に位置を移動することができます。このあたりの動きはアウトライン・プロセッサに準じたものです。

「アウトライン機能っぽいもの」が付いたワープロも多いと思いますが、私の場合、この手の「アウトライン機能っぽいもの」では満足できません。crossnoteは基本はワープロの使い勝手を基本としつつ、誰でもアウトライン・プロセッサの良さを味わうことができるように設計しました。

まあ、百聞は一見にしかず、ですよね。いずれこのあたりを機能をよりわかりやすく説明する資料やデモ環境を用意する予定です。

今日はcrossnoteネタです。

告白。

crossnoteはEclipseベースです。つまり、Swingベースではなく、SWTベース(+Draw2D/GEF)です。SwingUnitを作っていながら、これは何？　といわれてしまいそうですね。  😀

正直なところ、初期のころにSwingベースで一からつくるか、それともEclipseベースのRCPアプリケーションにするかでだいぶ悩みました。私自身はSWTはまったくの初心者ということもあり、自信はなかったのですが、以下の理由でEclipseベースを選択しました。

１．社員のメンバーの中にEclipseベースの開発に強い人がいたこと。
２．ワープロ部分の漢字入力への対応がSwingベースよりもEclipseベースのほうが確実に対応できそうであったこと。
３．多くのツールがEclipseベースで開発されていることを考えた場合、同じプラットフォームで動くメリットを享受できる可能性があること。

一番の決め手になったのは、３の理由です。

やってみてわかったことですが、Eclipseベースの場合、Swing系に比べるとOSのAPIがベースになっているだけに、その制限に縛られることが多く、アプリケーション全体として仕様が制限されることが多いという問題がありました。おそらくSwing系でJava2Dなどを利用したほうがもっと多様なことに対応できたのではないかと思います。まあでも、そもそもcrossnoteはプロジェクトのドキュメント作成用のワープロを目指しているのであって、アーティスティックな表現が求められているわけでもありませんので、そこは割り切って考えています。

今悩んでいるのは、テスト駆動開発に関する記事を書いておきながらお恥ずかしいことですが、ユーザI/F周りのユニットテストの自動化です。いまのところ人力でやっているのですが、回帰テストの量が膨大になります。でも、当然のことながらSwingUnitは使えません。何かいいものはないでしょうかね？

今日は現在開発中のプロダクト、crossnoteについての説明です。前回はコンセプトであるCollaborative Documentation Serviceについて説明しましたが、今回はプロジェクトにおけるドキュメンテーションを効率的に行うための工夫として、crossnoteの特徴を５つのポイントに絞って説明します。

１．もっとも重要な「Updateボタン」
これを押すと、他の人がコミットしたドキュメントの変更点がわかります。そして変更点をダブルクリックするだけで、変更前と変更後を並べて表示し、比較しながらどこをどう変えたのかを一目で確認できます。もし、自分が同じ部分を修正中だった場合（これをコンフリクト状態と呼びます）には、他の人がやった修正とのマージ作業（他人の修正と自分の修正をMIXさせる作業）をその比較画面上で行います。

２．オールインワン
crossnoteは普通のワープロのように文章を書いたり、図形を描いたり、表を書いたりすることができます。WordやExcelを使ったことがある人ならば無理なく使うことができます。またWikiのような記法を覚える必要もありません。

３．アウトライン機能とテンプレート機能
crossnoteはアウトライン機能が強化されています。ドキュメントはパラグラフ（章や節など）やテキスト枠、図形枠、表枠といった単位でどういった構造になっているかが簡単にわかりますし、その単位で操作することもできます。パラグラフやタイトルにつける番号はアウトラインの構造に応じて自動的にナンバリングされるので、思ったようにナンバリングされないで悩むこともありません。またドキュメントの体裁はテンプレートを指定することでほとんど決まってしまうので、プロジェクト内のドキュメントの体裁を均質に保つことができます。

４．ドキュメントステータス
crossnoteの各ドキュメントはドキュメントステータスと呼ぶ属性をもっています。これは例えば「個人ワーク」とか、「内部グループレビュー中」とか、「承認済み」などといったようなものです。これらの状態に応じてドキュメントを見せる範囲を切り替えたり、レビュアを指定してシステム上でレビューすることができます。

５．強力なセキュリティ機能
crossnoteにはプロジェクト単位にプロジェクトポリシーを設定し、そこで様々なセキュリティー設定を行うことができます。プロジェクトには「概要設計チーム」とか「DB設計チーム」などといったワークグループを設定することができます。プロジェクトメンバはそれぞれのワークグループに役割に応じてアサインされます。例えば山田さんは概要設計チームにレビュアとして参加する、といった感じです。このワークグループと役割に応じて、例えばコメントを付与できるとか、持ち出しができないようにするとか、きめ細かく権限を設定することができます。

今日は、開発中のプロダクト「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弾です。

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

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

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

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

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

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