update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

昨日は「生きたプロセス、死んだプロセス」という題名で反復可能で改善可能なプロセスの話を書きましたが、今日もそれに関連した話題です。

もし、あるプロジェクト・チームが優れた、反復可能で継続的な改善可能なプロセスを長年培ってきたとします。ではそのプロセスを標準プロセス化したら良いのではないか？　そう考える人もいるでしょう。　でも、おそらく、それを標準プロセスにして他のプロジェクト・チームにそのまま適用したとしても、結局は昨日書いた「死んだプロセス」になってしまうと私は考えています。

優れたプロセスとは各プロジェクト・チームが徐々に改善を積み重ねて編み出していくものだと思うからです。せっかくの優れたプロセス定義があったとしても、なぜそれが必要なのか、それによって何を得ようとしているのか、そういった背景的なことも含めて良い点、悪い点を理解していないと、宝の持ち腐れならまだ良いほうで、場合によっては足を引っ張るだけになりかねないからです。

プロジェクトが必要とする最適なプロセスとは、そのプロジェクトによって少しずつ異なっているはずです。また手法や開発技術は日々進化しています。また優れたプロセスでは、常に継続的な改善が必要とされます。だから決して「標準プロセス」というのはテンプレートにすぎず、固定的、決定的なプロセスというのは本来存在し得ないはずなのです。

すぐれた開発プロセスというのは、その開発チームの勲章のようなものだと思います。部門毎に異なるプロセス定義を持つ状態よりも標準プロセスに準拠した状態のほうがより上のレベルであると一般にいわれていますが、各プロジェクトが改善と最適化を遂行した結果としてそうなっている場合のことを考えると、常識のウソの１つではないかと考えています。

大手のSIerの場合、その会社独自の開発方法論を持っている場合が多いですが、実際の開発の現場ではどの程度利用されているものなのでしょうか？　一応、WBS(Work Breakdown Structure)はその開発方法論に沿ったものになっているし、各種の儀式（InspectionやCutover criteriaなど）はやっているものの、何かこう、しっくりきていないというか、「やらされている」だけで積極的に推し進めていないという場合もあるかもしれません。

もし、その「しっくりきていない感」があるのだとすると、おそらくそのプロセスで定義されていることが古臭くなっているとか、あまり役に立っていないとか、何らかの理由があるのだと思います。

標準化されたプロセスというのは、ある想定をおいた、いわば仮想のプロジェクトを対象に設定されたものです。実際のプロジェクトにそのようなプロセスをそのまま適用しようとしても、その想定と異なる部分があるのは当然のことといえます。ではそのような場合でも敢えてそのまま実施することに意味があるのでしょうか？　私はそのように、標準化されたプロセスを何の疑いもなくただ実施している場合、そのプロセスは「死んだプロセス」になっていると思うのです。

あるプロジェクトマネージャの人から聞いた話なのですが、その人のプロジェクトの場合、同じような開発を繰り返したことで、独自の開発プロセスが出来上がっていて、しかも毎回、前回の反省点を踏まえてその開発プロセスを見直し、改善してきている、と言っていました。つまり、ちょっとカッコいい言葉でいうと、反復可能でかつ継続的な改善が行われるプロセスということです。

そのプロジェクトマネージャは、今はプロジェクトが非常にうまく回っているので、自分がやることがなくなるのが欠点だ、と言っていました。

これこそが「生きたプロセス」ということではないでしょうか？　標準的なプロセスがあることは悪いことではないのですが、それに縛られるのではなく、より良いものへ常に改善していき、必要な場合にはそこから離れていくぐらいのことが必要なのだと思います。

建築の世界でもシステムの世界でもモデル（模型）をよく作成します。でも建築の世界では作った模型を元にして実際に建築物を作ろう、などという無謀なことを考える人はいませんが、なぜかシステムの世界ではこのようなことを考える人たちが多くいます。建築の世界で模型を作る場合にはスケール（大きさ）が違うので一目瞭然、誰もそんなことは考えないわけですが、システムの世界ではモデルとして作るものと実装物の違いがはっきりしない（と思っている）ので、そんなことを考えるのでしょう。でもよくよく考えてみると、ちょっと不思議な気がしませんか？

先に断っておきますが、ここでいうモデルとはMVCのModelではなく、UMLで指すところのModelを指しています。MVCのModelは現実世界との対比（抽象化）という意味でModelという言葉が使われていますが、そこではシステムに必要な実際のデータとビジネスロジックが扱われますので、いわゆる模型という意味ではありませんね。

え、UMLのModelも抽象化という意味も含んでいるって？　まあ、確かにその通りですが、ここで議論したいのは、みんなの理解を深めるためのモデルという観点の話です。

モデルと実際の実装物との違いは何でしょうか？　モデルは必ずしも最終的な実装物そのものを表す必要はありません。モデルを作成する目的は、実装物がどんなものであるかをイメージしやすくすること、そしてその段階でわかる設計上の不具合を予めつぶしておくことだと思います。

逆にいうと、この目的を満たさないモデルは、モデルではないのです。モデルを見て、あ、これはこういうことね、と簡単にわかるようになっていなければ、本来のモデルとしての意味を成していないということになります。

イメージがしやすく、わかりやすいモデルというのは、実際の実装物に比べるとだいぶシンプルで、あまり重要ではない部分や例外的な部分などをばっさりそぎ落としたものであるべきです。本質的な、ごく重要なことだけをモデルとして表現することによって、誰が見ても何をやろうとしているのかがわかりやすくなります。また最終的なインプリメンテーションと多少異なっていても構わないんです。重要なのは厳密であることよりも、おおよそが合っていることが重要なんです。

システムの世界ではモデリングの表記法としてUMLが一般的になりましたが、UMLはどんどん「厳密に」定義できるように複雑化してきました。でもこの流れは本来の目的から外れているのではないでしょうか？　私はUMLとは単なるスケッチだと思っています。(Martin FlowのBlikiにもそんな記事がありますね）　もっとラフに、部分部分の局面でうまく利用するツールとして利用したいものです。

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

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

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

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

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

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

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

昨日の帰りはTシャツ1枚で、震えていました。今日もちょっと寒いですね。

以前PDAというタイトルでブログを書きましたが、いまだにCLIEを愛用している私が最近非常に惹かれているデバイスが、iPhoneです。CLIEの次はぜひiPhoneに切り替えたい！　日本の携帯と規格が違うので導入には困難が伴うようですが、日本の携帯会社さん、ぜひがんばってiPhoneを導入してください。

私がiPhoneに惹かれている理由は、TODOとかアドレス帳とか、普通のPDAに必要な機能がそろっていて、かつ使いやすそうだから。CLIE(というかPalmOS）の場合も、起動が早くて十分に使いやすかったのですが、日本では今現在、PalmOS系の選択枝がありません。そろそろWindows CE(PocketPC)マシンに切り替えなきゃならないかな、と思っていながら、なかなか踏ん切りがつかない矢先だったのです。でもiPhoneについてのレビュー記事をいくつか見ているうちに、iPhoneが日本で発売されるまで我慢して待とうか？という気になってきました。でも待っていて、果たして出るのかな？

本質的にはPocketPCマシンと極端な違いがあるわけではないと思うのですが、日本で売られているPocketPCマシンはどれも重くてワイシャツのポケットに入るようなものではありません。これが私がPocketPCマシンになかなか踏み切れなかった最大の理由です。一方のiPhoneは十分に小さくて軽い。携帯デバイスなんがら、小型であること、軽いことこそが高性能なんです。

またCLIEの場合には携帯とPDAと両方持たなければならなかった、という問題が一気に解決します。この点でも「買い」です。

もちろん見た目のカッコよさとか、アプリケーションの動きの滑らかさも大きな魅力の１つです。ほんと、センスが違いますね。

ちなみにJavaVMはまだサポートされないようですね。でも、こんなことが気になっちゃうのはシステム屋の悪いところか…

ちょっと前ですが、シマンテックがアンケート調査した「PCは遅い！」、ユーザーの6割がストレスという記事が@ITに載っていました。PCそのものは処理能力が年々向上しているはずなのですが、使っている人たちはその恩恵をほとんど感じていない、ということになります。なんとも不思議な話です。

実際、私のPC(Window XP, Pentium D 3.2GHz, 2GByte Memoryのマシン）も朝立ち上げてログインした直後はしばらくまったく使えません。一応画面上、ディスクトップは表示されるのですが、右下の常駐アプリケーションのところが一通り出揃うまでは裏でCPUやハードディスクなどががりがり動いていて、その状態で何かアプリケーションを起動してもなかなか立ち上がってきません。試しにその状態で起動してみると1分ぐらい平気で待たされてしまいます。

でもしばらくして（数分後）落ち着いてからは、すんなりと待つこともなくアプリケーションが起動されます。また通常に使っているときには特に遅いと感じることは少ないです。

上記の記事で皆がPCが遅いと感じているのが、この起動直後の状態を指しているのかははっきりしないのですが、私はかなり関連しているのではないかと考えています。もしそうだとすると、これは何が悪いということになるのでしょうか？　もしかしてアンチウィルスソフト？　そういえば私のPCのアンチウィルスソフトはXXXXxX製ですね。  😎

PCの起動直後というのは、まさにそのPCを使いたいと思って使い始めた直後のことなので、そこで待たされてしまうと、ことさら遅さを感じてしまう気がしています。

突き詰めて考えてみると、ユーザが求めているのは、動かし始めたときの起動の速さなのかもしれません。使い始めたときにさくさくと動けば早いと感じ、なかなか立ち上がらないと重いと感じる。例えばJavaのアプレットが人気が出なかったのに対し、AjaxやFlashがなぜに人気があるのか？　なんてことも、その仮定を裏付ける１つの事例のように思えます。またYouTubeがWindowsのMedia Playerではなく、Flashベースなのも、Google MapやGoogleブック検索がPDFなどではなく、GIFベースなのも、さくっと動きはじめることを重視しての選択のように思えます。

梅雨のこの時期に、なんかでかい台風が近づいているみたいですね。

運用をしている人でないとあまり縁がないものかもしれませんが、今日は障害報告について、です。これをテーマにしたのは、私の経験上、障害報告をもっと「有効活用」すべきではないかと感じることが多かったからです。

システムが障害を起した場合、障害報告書を書いて提出しなければならないことが多いですが、みなさんは、これをどのように活用していますか？　もし障害報告書が単に懲罰的な意味合いでしか使われていないならば、非常にもったいないことです。本来は、同じ間違いを繰り返さないために書くものだと思うからです。

同じ間違いを繰り返さないためには、事後の分析が重要です。直接的な原因ももちろんのこと、その背景の問題についても深い洞察が必要だと思います。そして分析の結果を「失敗のパターン」として広く社内に公表し、改めるべきところを改め、また同じような事例がほかのシステムでも発生しないように社内にとして紹介したり教育していく仕組みがあってしかるべきだと思うのです。

失敗の経験は非常に重要なことです。それを個人の経験として閉じ込めてしまうのは、会社としては大きな機会損失をしていることになります。

こういったことが会社としてうまく機能するようにするためには、それが個人を攻撃するためのものでは決してないことをトップダウン的に伝達し、広く浸透させる必要があります。そうなっていないと、問題を深堀することは、ぎすぎすした、あまり楽しくない職場にしてしまう可能性があるからです。

重要なのは当事者を責めることではなく、次の当事者を作らないように社内が仕組みを作り、バックアップしていくことだと思います。