update it, Inc.社長のブログ

最近、IT企業に分類される会社で広告モデルに走っている会社が増えています。Googleを先頭に、マイクロソフトまでが広告モデルの事業を展開しています。同じ「IT企業」でも、純粋にシステムを作って販売している会社と、Web2.0時代の広告モデルで成り立っている会社ではまったく別のイメージです。そもそも同じ分類（業種）と考えるべきではないのかもしれません。

広告って金融と同じく、企業が活動していく上では必ず必要になるものです。そしてGoogleの急成長振りを見ても、そこで大きなイノベーションと変革が起こっているのは明らかだと思います。だから様々な会社が乗り遅れまいと広告型モデルへと走る。今はいわば、ゴールドラッシュ的なものなのでしょう。

でももし、5年後の世界から今を覗き見たら、どんなように見えるのでしょうか？　おそらくこんな感じではないでしょうか？　「おー、このころはまだみんながんばっていたね。でも結局、みんな○×△に収斂しちゃったよなー」　みんながこの○×△の枠内に入ることを目指していると思うのですが、みんながこぞって参入しているということはそれだけ競争が激しいわけです。5年後において、果たしてどれだけの会社が残っているのでしょうか？

孫子の兵法で有名な「戦わずして勝つ」という言葉がありますが、戦わないことも１つの戦略です。人と同じ方向に走っても、その集団で競り勝つのは至難の技です。勝つためにはむしろ、人と違う方向に走るべきだと思うのです。

今、私の下の子がサッカーチームに入っているのですが、まだ低学年なので、みんな団子のようにくっつきあいながらボールを追い回しています。みんなが一斉に同じボールの方向に向かって走ってしまうのです。でもシュートを決めることができるのは、むしろその集団から離れてちゃんと自分の役割を考えながら機会を狙っている頭のいい子なんですよね。

え、では　update it, Inc.がどうだって？　他の会社とは違う方向を向いているつもりです。私は戦わずして勝つことを信じていますよ。

先週、デモ用に買ったVistaの載ったノートPCのインストールに苦労したという話を書きましたが、今日はVistaを使ったインプレッションを書きます。というか、書きたくてしょうがない。

というのも、「遅いぞ、こら！」

今回買ったマシンはCore 2 Duoで2GByteのメモリーが載った、最初からVistaに対応している最新機種です。にも関わらず、信じられないくらいすべてが遅い。特に漢字変換の反応の鈍さはたまりません。なかなか変換しないんで、いらいらしてしまいます。あとログイン・ログアウトが限りなく遅い。マシンはActive Directoryのドメインに参加させているのですが、Control+Alt+Deleteキーを押してからログイン画面が出てくるまでにしばらく待ちます。ログアウトも同じような感じで、XPのマシンの倍ぐらいかかっているんじゃないか？って感じです。

VistaのノートPCの場合、電源ボタンを押したときにはデフォルトでスリープ状態（メモリーに電源が供給されたままの低消費電力状態）になるようなのですが、これだとそのまま数日放置するとかなり電池を消費していしまいます。なので休止（メモリーの内容をハードディスクに書き出してから電源をとめた状態）になるように変更したのですが、2GByteのメモリーがたたったのか、実際に休止されるのに結構待たされます。

あとわけがわからんというか、ちょっと呆れたのが、Windowsサーバー上のドライブがネットワークの一覧に表示されないこと。Sambaじゃないっすよ。最新のWindows Server 2003のドライブ。VistaからはLink-Layer Topology Discovery(LLTD)という仕組みが使われているらしく、このLLTDレスポンダがインストールされていないXPやWindows ServerはVistaマシンから一覧で見ることができません。しかもLLTDレスポンダはXP用しかでていない！　まあSambaサーバが見えないのは百歩譲ったとしても（あまり譲りたくはない）、なんでWindows Server 2003用がないの？

MSはVistaをビジネス用には売りたくないのだろうか、と勘ぐってしまいました。正直なところ、仕事に使うにはまだ早いのかもしれません。最近、VistaマシンをXPに載せ変えることを「アップグレードする」というらしいですが、うーん、なるほど、ですね…

以前、@ITに書いた記事の内容と関連しますが、今日はリスク・エクスポージャという概念をご紹介します。

リスク・エクスポージャはもともと金融の世界の概念です。金融の世界では、今自分が持っているポジション（例えば株や債券など）がどれだけ「やられる」可能性があるのか、それを金額で表した数字をリスク・エクスポージャと呼んでいます。現物資産（株や債券）の場合、その現物の金額に「やられる確率」(リスクの発生する確率)をかけて求めます。数学の期待値というヤツと一緒です。

この概念を用いると、システムのプロジェクトが抱えるリスクを金額で表示することができるようになります。つまりプロジェクトが失敗することにより、どういったコストがかかるのかを原因別にリストアップし、それらのコストと発生しうる確率を求めて掛け合わせて各要因毎のリスクエクスポージャとします。そしてそれらを全部足し合わせたものがプロジェクトの抱えるリスクエクスポージャとなります。（@ITの記事では、これをテスト不足によって発生するリスクエクスポージャとして求め、テストの金額を求めるということを書いています）

私の敬愛するトム・デマルコさんのティモシー・リスターさんとの共著「熊とワルツを」（日経BP社 伊豆原弓訳）の本でもこのリスク・エクスポージャについてわかりやすく説明しています。お勧めです。

なぜこれを書いたかというと、この概念はプロジェクトマネージャであれば皆が知っているべき概念だと思うからです。プロジェクトにはリスクがつき物です。リスクがあるのは、おそらくどんなプロジェクトマネージャでも知っていることだと思います。でも、それを適切に表現する方法を知らない。こんなリスクがある、あんなリスクがある、ということは言えても、それがどれだけ深刻なものなのかを表現する術を持っていないと思います。

そこで、リスク・エクスポージャの出番です。そのリスクを金額で表現してしまうのです。みんな、お金になっているとわかりやすいでしょ。例えば、このリスク・エクスポージャは1億円相当だ、なんて言われたら、目の色を変えて対応しますよね。
ぜひうまく活用してみてください。

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

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

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

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

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

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

もう自分の今日の仕事は終わった、時間的にももう帰る時間だ、疲れたし、もう帰ってくつろぎたい、と思っているのに帰れない、というか帰りづらいときってありませんか？

プロジェクトの雰囲気によってだいぶ異なるのだと思いますが、なんか帰りづらい雰囲気がかもし出されている場合も多いと思います。でもそれでだらだらと帰らないでいると、さらにその人の下の人たちも同じように帰れないままになってしまい、余計に帰りづらい雰囲気が強化されてしまうことになります。

ある人から聞いた話なのですが、残業の時間帯に上司の人が残っていてなんか帰りづらいな、と思って覗き込んでみたら、なんとその上司の人は一生懸命、携帯メールを打っていたそうです。あぜんとしますよね。

しかし日本の職場というのは、自然にまわりと同じような行動を求められる場合が多く、一人だけ先に帰ってしまったりすると、陰口をたたかれたりします。そんなこんなで、なかなか帰らない人がでてくると思うのですが、ここはひとつ、プロフェッショナルの仕事をしましょう！　つまりやるべきことをやったら帰る。これは非常に当たり前の話だと思います。だらだらと残っているのは、仕事ではなく、作業をしている人です。クリエイティブな仕事をするためには、自分で適切な時間管理が必要になります。それができないのはプロフェッショナルとはいえないのではないでしょうか。

あ、もちろん、プロフェッショナルというのはやるべきことをきちんとやる人であり、残業をしない人という意味ではありませんので、よろしく。

今日のテーマはカテゴリーをプロジェクトとしていますが、ちょっとずれているかもしれません。

「エンジニアの運」と書いたのは、ある人が仕事に就いてからどういう活躍をするのかは、一番最初に新卒で配属されたところの職場によってかなりの部分が決まるのではないか、という仮説です。私も長年仕事をしてきて、いろんな人からいろいろな影響を受けていますが、一番決定的な影響を受けたのは、やはり新卒で配属された最初の職場が一番大きかったと思っています。

やはりそれまでの学生時代と就職してからではありとあらゆるものが変わるので、非常に印象深くなるのは当然かもしれませんが、単にそれだけではなく、そのときの職場の先輩や上司の方から受ける影響は、それ以降のその人の仕事におけるベース（仕事に対するスタンスや考え方、習慣など）を決定付け、それ以降で受ける影響とは比べ物にならないぐらい大きなものだと私は考えています。

もしこの仮説が正しければ、その人の運は、最初に配属された職場によって大きく決定付けられるといえるのではないでしょうか？　つまり最初の職場で仕事がバリバリできる優秀な先輩や上司に恵まれれば、仕事とはこういうものだとインプリンティング（刷り込み）され、その人自身も自然にそういう一員として振舞うようになる。逆に運悪くそういう環境に恵まれなかった人は、やはり同じようにインプリンティングされ、その人自身もなかなか芽がでなくなる。すべての人が環境だけに左右されるわけではないとは思いますが、割合的にそうなる人が多いのではないかと考えています。

一般に学生は、就職して実際に職場に配属されるまで、その職場の様子がわからない場合が多いと思いますが、実はそのときにその人の人生を左右するような大博打をしているのかもしれません。そういった意味では、インターンのような制度をもっと普及させるべきではないでしょうか？

先週の金曜日にデモ用に買ったノートPCが届きました。Core 2 Duoで2GByteメモリーがのったVistaマシンです。で、おもむろにセットアップを開始したのですが、いやー、半日くらいかかっても終わらない。いい加減、いやになってきました。

時間がかかるのは、1つ目の理由は、まだVistaマシンの使い方の良くわかっていないから。何かいろんなものがいろいろ変わっています。Windows 2000からWindows XPに変わったときもずいぶんメニュー体系などが変わってしまって覚えるのに苦労したのですが、今回も同様に、「そう簡単には使わせないよ」戦法によってかく乱されてしまいました。

2つ目の理由はインストールの嵐！　インストールしてはパッチを更新してセッティングして、さらにインストールして…の繰り返しです。誰かがこれをインストール・マーチと呼んでいたのを思い出します。ほんと、延々と終わりのない行進曲のようです。

さて、一通りセットアップした後で、アプリケーションが起動していない状態でタスクマネージャーを見たら、1GByteぐらい食っていました。こりゃ、推奨メモリが1GByteという意味がわかります。偉大なり、Vista君。（ちなみにその後で再起動後に確認したときには780MByteぐらいだったので、1GByte食っていたのは何かが裏で動いていたからだとは思います。でも、780MByteって何？）

今日書くことは、非常に当たり前のことなので、人によっては何でこんなこといまさら書くの？　という方もいらっしゃるかもしれません。テーマは設計書を書く前にやるべきこと、です。

昨日の「システム屋の書いた文章」にも多少通じるところがあるのですが、設計書を書く前にはまず「すり合わせ」をしましょう。（「にぎる」と言うこともあります）　非常に当たり前のことだと（少なくとも私は）思っているのですが、意外とやっていない人がいると聞きます。

ここはぜひ、ユーザ側の一人になったつもりで考えてみてください。例えばもしある日、システム屋があなたの前に最終的な設計書をいきなり持ってきて、「これでいいですか？」と言われたとします。そして読んでみたら、あれ、期待している動きとちょっと違う。でもそれを話したら「今さら設計を変えろといわれても、スケジュールがずれるのでできない」と言われたとしたら、あなたはどう思うでしょうか？

設計書を書いている側では、要求仕様（例えばRFP)に沿って設計しているから正しいはずと思い込んでいるかもしれません。しかし要求仕様の中にユーザ側の考えがすべて反映されているとは限りません。また曖昧さのために、期待されているものと違ったものを設計してしまうリスクがあります。もちろんその場合、要求仕様に問題があるといえますが、すべてにおいて完璧な要求仕様をつくることができないのは、バグのないシステムを作れないのと同じことです。（ここでバグのないシステムを作れない、といっているのは理論的な話ではなく、現実的にできないでしょ、という話です）

もちろん、システムのスケジュールや予算も要求仕様に合わせて確保されているので、そこから大きく逸脱することはありえないのですが、いきなり完成した設計書を持参するのではなく、要求仕様に対する解決策をユーザと一緒に考え、提案することが重要だと思います。そうすることで、ユーザの考えをうまく盛り込むことができ、満足度の高いシステムとすることができると思うのです。

ある人から、自分のプロジェクトメンバの書いたドキュメントについて、お客さんからわかりづらいと言われているという話を聞きました。実は私も似たような経験があります。どうもシステム屋の書いたドキュメントというのは、ユーザからわかりづらいといわれることが多い気がします。どうしてでしょうか？

わかりづらいといわれる理由には様々あって、簡単に1つの理由ですべてを言い表すことはできないとは思いますが、１つの傾向として、システム屋というのはどうも細かいことをくどくどと書きすぎる傾向があるように思います。でも書いている側からみれば、どれもこれも大切なことであり、そう簡単に削れるようなことではなかったりします。ではユーザの側が面倒くさがって、内容をよく読もうとしないのがいけないのでしょうか？　うーん、それはそれで、一方的な思い込みかもしれませんよね。

ひとつ思うこととしては、相手が何を求めているのかを考えて書いているか、ということがあります。つまり読み手側の立場に立って書いているか、ということです。

システム屋は自分がこれからやろうとすることをできるだけ細かく、正確に書いて、それの承認を得ようとします。この場合、そこに書いているのは「自分がこれからやること」という観点で書いています。でも「自分がこれからやること」と、ユーザが「やって欲しいと思っていること」がすり合っているかどうかが簡単に判断できない場合、ユーザは「わかりにくく」感じるのではないでしょうか？

つまりユーザの視点で、何を解決しようとしているのか、何をしようとしているのかを明確にし、それに対する解決策として、前提条件や考え方を明記し、その後で具体的にやることを対応を付けて書く、というようにするだけで、ユーザ側のやって欲しいことと、システム屋がこれからやろうとしていることとの対応付けが簡単にできるようになり、ユーザの「わかりにくい感」を減少させることができるかもしれません。

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

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

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

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

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

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

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

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

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