update it, Inc.社長のブログ

私はソフトウェアの仕事が好きです。なぜ好きかというと、もちろん純粋にソフトウェアに対する興味という部分もあるのですが、何よりも魅力的なのは、クリエイティビティ=イノベーションを追求できる世界だという点です。

この分野では次々にイノベーションが起きていて、そのスピードは明らかに他の分野より速いです。ぼやぼやしているとあっという間に取り残されてしまいます。No.1がいつまでもNo.1でいられるとは限らない世界。非常に刺激的で魅力的な分野だと思っています。

従来の資本主義というと、巨大な資本力を持った者が圧倒的な強さを持っていたのですが、ソフトウェアの分野では必ずしも巨大な資本力を持った者が勝者になるとは限りません。新興の小さな会社が起こしたイノベーションにより、あれよあれよという間に成長して巨大な企業を打ち負かす、などという戦国時代さながらのことが当たり前のように起こり得ます。

「ペンは剣よりも強し」という言葉がありますが、ソフトウェアの世界では「アイデアは資本よりも強し」だと思います。どんなに資本力があっても、イノベーションを起こすアイデアがなければこのソフトウェアの世界では生き残れない。逆にイノベーションを起こすアイデアがあれば、誰にでもチャンスがある。このフェアな部分がソフトウェア分野の魅力だと思います。

資本主義から知本主義への転換。ソフトウェアの分野から世界を変えていきたいと思いませんか？

今日は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は使えません。何かいいものはないでしょうかね？

自分が普段使っているPCの裏で、どんなプロセスが裏で動いているか把握している人っていますか？　最近のPCにはいろんなものがてんこ盛りになっていて、知らないプロセスが一杯動いていて、わけがわかりません。Windows95のころまでは、どんなプロセスが動いているかぐらいはだいたいというか、なんとなくは把握できていたのですが…

先日、使っているPCが突然ウィーンとうなりを上げて冷却ファンが回り始めました。CPU負荷の高いようなことは何もやっていません。なので、気になってタスクマネージャを開いてみてみたのですが、CPUの%が高いのはSystem Idle Processだけです。でもCPU使用率の履歴グラフにはなんかのプロセスがCPUを使っているように表示されています。System Idle Processっていうのは、CPUの空きを示しているんじゃなかったでしたっけ！？　まあそれは置いておいて、改めてそこに並んでいるプロセスを眺めてみて思ったのは、ほとんどが知らないものばかりだということでした。（あの、一応ウイルスチェックはちゃんとやっていますよ）

裏で何か知らないプロセスがうじゃうじゃ動いているというのは気持ちのいいものではありません。メモリを食いますし、遅くなる可能性もあります。また「よくわからないものが動いている」という状態はセキュリティ的にも問題があるといえます。

しかし、最近のPCには実にわけのわからないプログラムが一杯プリインストールされてしまっています。また必要なプログラムをインストールする場合でも、そのプログラムがおまけのプログラムをいろいろ一杯インストールしてしまったり、更新をチェックしたり起動をスピードアップさせる常駐プログラムを裏に仕込んいる、なんてことはよくありますよね。

一方で、どのプロセスは必要で、どのプロセスは必要のないものなのかがよくわかりません。私は勝手にPCにインストールされている必要のないプログラムはさっさとアンインストールしてしまう派なのですが、果たして本当にそのプログラムをアンインストールしてしまって問題がないのか、いつも悩まされています。

食品の分野では消費者に対して使っている原材料を明記することが義務付けられていますが、システムの分野でも同じようにすべきではないでしょうか？　つまり、せめてアプリケーションをインストールすることによって、どんなものが追加されるのか、またどういう場合に必要で、逆にどんな場合には必要のないものなのかをユーザがわかるようにする、ということです。セキュリティの観点からは結構重要なことのように思えます。みなさんはどう思いますか？

だいぶ以前に、?設計書に書くべき範囲という似たようなタイトルでブログを書いていますが、今回は「詳細化」という観点から考察してみましょう。なおここに取り上げていないドキュメントについては、下のいずれかに相当するものとして考えてください。

昔は詳細設計書というのがあって、フローチャートなどという懐かしい図とともにかなり細かいレベルのドキュメントを書いていましたが、最近では詳細設計書は書かないのが当たり前になってきたと思います。（ただしミッションクリティカルな分野については違うかもしれません）

理由の１つにはオブジェクト指向の普及などにより、詳細設計書とソースコードがほぼ同義語と考えられるレベルになってきており、「２つのドキュメント（詳細設計書とソースコード）」の二重メンテナンスは避けるべきだと考えられるようになってきたこと、そして、コンピュータリソースが貴重だった時代とは異なり、昔では考えられないような高度な統合開発環境が誰でも使えるようになってきており、詳細設計書のレベルのことはソースコードで十分じゃん、というのがはっきりしてきたため、ともいえると思います。

では他の設計書はどうでしょうか？　基本設計書や概要設計書はその名の通り、詳細化しては「いけない」ものです。ここに詳細なことを書き込んでは、読み手が本当にそれを読んで押さえるべきツボを押さえられなくなります。基本設計書には基本的なこと、概要設計書には概要を書くべきであって、それ以上のものを書く場所ではありません。詳細化を避けることによって、これらの設計書が読みやすくなり、プロジェクト全体の方向性を定めるコンセンサスを取るための道具として、またプロジェクトへの新しい参加者向けの導入書として、またテスト設計する上での基準としても役に立つようになります。

では外部設計書はどうでしょうか？　これは十分に詳細化されてしかるべきものでしょう。もしシステム間インターフェースとなるデータベース項目やファイルフォーマットなどが最終化されたものがない状態で開発し始めると、後になって大きく回り道をする羽目になります。ユーザーI/Fも同じです。ユーザーI/Fが詳細化されていない状態で開発が進んだ場合、操作の一貫性が損なわれたり、同じような処理があちこちに散らばる結果になります。

ただし外部設計書も最初から詳細化されたものがいきなり出てくるわけではありません。通常はいくつかの段階を踏んで、徐々に詳細化していくものだと思います。最後に残ったドキュメントは詳細化されているべきだ、というだけで、途中の中間成果物まで詳細化されているべきだ、とは申しません。

トム・デマルコさんの書いた書物のいくつかには、ユーザマニュアルこそが究極の設計書だと書かれています。ユーザマニュアルは、ユーザが読む視点で書かれた外部設計書といえます。外部設計書としてはユーザマニュアル程度の詳細化が必要だ、ということかもしれません。

最近、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設計チーム」などといったワークグループを設定することができます。プロジェクトメンバはそれぞれのワークグループに役割に応じてアサインされます。例えば山田さんは概要設計チームにレビュアとして参加する、といった感じです。このワークグループと役割に応じて、例えばコメントを付与できるとか、持ち出しができないようにするとか、きめ細かく権限を設定することができます。

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

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

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

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

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

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

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

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

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

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