update it, Inc.社長のブログ

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

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

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

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

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

先週の金曜日にデモ用に買ったノート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には実際のプロジェクトにおけるドキュメンテーションをより効率的に行えるための様々な工夫がされています。これについては次の機会に説明いたしましょう。

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

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

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

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

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

大手の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枚で、震えていました。今日もちょっと寒いですね。