update it, Inc.社長のブログ

物事はシンプルなほうが良い。これは昔から、いろいろなことに対して言われていることだと思います。システムにしてもそうです。同じことを実現するのであれば複雑であるよりはシンプルなほうが良い。そのほうがバグを減らしやすいし、メンテナンスも楽です。なぜならば、理解しやすいから、です。

文章にしてもそうです。シンプルな文章のほうがわかりやすいですし、相手に伝わります。

シンプルさは、コミュニケーションや相互理解のための基本原則といえるのかもしれません。

しかし、シンプルであるというのは、実に難しい。本当にそう思います。何が難しいのかというと、「何を残し、何を削るべきか」という判断です。シンプルにするためには、余計なものを一切そぎ落とし、中の一番重要な、本質的なことだけを残すようにしなければなりません。

つまり、雑多な物事の中で本質的な部分とそうでない部分を分類する能力が問われるのだと思います。物事をシンプルにする能力というのは、この分類する能力と非常に近いのかもしれません。

crossnoteを使うとドキュメントを修正後、コミットするだけで、どこをどう変えたのかをプロジェクト関係者に通知することができます。この仕組みはオフショア開発に非常に向いていることがわかりました。（まあ、前からわかっていたことではあるのですが、いろいろな方にヒアリングを重ねるにつれ、その思いを強くした次第です）

実際、crossnoteのセキュリティ管理の仕組みも、まさにオフショア開発向きだといえると思います。まあ、正確には分散拠点開発向きで、国内でも同じことで、複数に分かれて開発している場合には非常に威力を発揮すると思います。

このブログを見ている方で、ご自身のところでオフショア開発を手がけていて、興味のある方はぜひご連絡いただけないでしょうか？　まずはマーケティングといいますか、今現在オフショア開発をしているところではどのようなことをしていて、どんなニーズがあるのかをもっと良く知りたいのです。

ご希望であれば、その場で実物のデモをお見せいたします。

（とはいっても、私としてはオフショア開発以外の部分でもぜひ使ってもらいたいと思っています。オフショア開発はやっていないけど、実物のデモを見てみたいという方がいらっしゃいましたら、ぜひご連絡ください。）

連絡先はinfoまで。（後ろに @updateit.co.jp を付けてください）
よろしくお願いします。

crossnoteはコンカレント性（同じドキュメントを複数人で同時に編集することが出来るようにすること）を確保するために、内部のデータ形式として独自フォーマット（というか、正確には独自データ形式）を採用しています。ところが正直なところ、セールス的な観点でいえばこの独自フォーマットであることはマイナス要因になります。

つまり独自フォーマットの場合、通常のワープロソフトではそのままではドキュメントを編集できないことがネックになる場合がある、ということです。例えば委託者側から、納品物を別のベンダーにメンテナンスさせる可能性を考えて、編集可能なドキュメント形式での納品を要求される場合があります。現在crossnoteについて、ヒアリングを進めているのですが、実際にそういう意見を頂きました。

これについては内部フォーマットは変えようがないのですが、通常のワープロソフトなどで編集できる形式で出力できるようにコンバータを用意しようと考えています。

皆さんもご存知かもしれませんが、WordやExcelにはファイルの中に履歴データが含まれています。それに気付かずにユーザに渡してしまい、隠しておいたはずのデータがユーザに見えてしまい、大変なことになった、という話を聞いたことがあるのではないでしょうか。お客様にWordやExcelの形式でデータを出す場合には、たとえ元のドキュメントと同じ形式であれ、クレンジングというか、中の見られてはまずいデータを削除する作業が必要です。crossnoteの場合にはコンバートして出力するので、そのようなデータが裏に入る危険性がない分、実はこのやり方のほうが望ましいのではないかと考えています。

残念ながら最初のバージョンでは間に合わないのですが、遅くとも来年の3月末までには、製品に組み込む予定です。

これとは別に、今までのプロジェクトのドキュメント類はどうしたらよいのか、という話もいろいろなところから頂いております。例えば通常のWordやExcelなどで作成された、既存資産です。

これらについてはバイナリデータとして、セキュアに、かつ履歴管理を行いつつやり取りするための仕組みとして、crossnote上でやり取りできるように機能追加していく予定です。ただしバイナリデータについては残念ながらコンカレント性はありません。（誰かが編集中の場合には他の人は編集できなくなります）　またバイナリとしての塊の単位で変更履歴管理を行いますので、中身について、どこをどのように変更したのかまでは追えません。

このように制約事項はありますが、できるだけ既存資産についてもシームレスに扱っていけるよう、サービスを改善していきたいと考えております。

近年、システム開発の世界ではITアーキテクトの必要性が叫ばれています。現実問題として、プロジェクトの中でITアーキテクトという職種が実際に存在しているチームはまだ少数派なのかもしれませんが、様々なシステムの仕組みを熟知し、要求仕様に対して適切なアーキテクチャを提案・実現する能力を持ったスーパーSEは、みんなから待ち望まれているのだと思います。

最近はプログラマのキャリアアップの１つの目標としてITアーキテクトの存在は大きくなってきているようです。スペシャリストとしての頂点という意味合いが強いのでしょう。

ITアーキテクトは対象のシステムの、アーキテクチャの全体像を設計する役割を持ちます。ITアーキテクトが決めた方向性に従ってシステムが設計されることになり、その大方針はそのシステムのライフサイクルにおいて大きな意味を持つことになります。

私はこの「システムのライフサイクル」という部分がポイントだと思います。つまり、ITアーキテクトは対象のシステムのライフサイクルを見据えて全体像を設計する責任を負う、ということです。しかし、昨今のシステムを取り巻く状況を考えると、これはとてつもなく大変な仕事であることがわかります。

システムを取り巻く環境は非常に早いサイクルでどんどん変わっています。従って採用したアーキテクチャが非常に早いタイミングで廃れてしまうことも十分考えられます。もしそうなってしまうと、エンハンスやハードウェアの載せ変えもできなくなってしまい、早々にシステムの「死」を迎えることになってしまいます。そのためにシステムのライフサイクルが不用意に短くなってしまい、作り変えのための余計なコストが必要になったとしたら、それはITアーキテクトの責任である、ということなのです。

つまりITアーキテクトは、一時の流行にとらわれることなく、少なくとも対象システムのライフサイクルの期間内は十分に使い続けることができるような、信頼のおけるアーキテクチャを選択する義務があるということになります。そしてもっとも重要で、難しいのは、採用する技術について未来を見通す力を持たなければならない、ということです。

ということで、私はITアーキテクトは予言者、それも客観的な予言者であれ、と考えています。できるだけ客観的に、技術動向を予言できる能力が必要だ、ということです。

昨日ご紹介した渡邉美樹さんが書いた、「もう、国には頼らない。」（日経BP社）の中に、学校の先生を360度評価するという話が載っています。先生にも切磋琢磨してもらうために、その評価基準として自分および上司だけでなく、同僚、部下、PTAの親、さらには生徒にもアンケートを取り、評価を行うということです。（ちなみに本人評価は自分に甘くなりがちであること、および校長を除く上司や部下による評価は結局年功序列的な結果となってしまうということで、途中から評価基準から外すように「改善」したそうです）

生徒からの評価というと、生徒に媚びる先生が高評価になるのではないかという疑問が出ると思いますが、生徒側が選ぶのは結局は尊敬できる先生を選ぶようです。先生は生徒から尊敬されるようにがんばる、ということになります。これは非常に自然なことだと思いました。

生徒というのは学校から見た場合の「お客様」に相当します。もちろん一般のサービス業における「お客様」の定義とはだいぶ異なるのですが、やはり学校というサービスとして考えた場合のお客様であることには間違いはありません。生徒からの評価を聞くというのは、エンドユーザにアンケートを行うというのと同じ話なのですよね。

さて、システムの開発現場でこの360度評価を取り入れるとしたら、どんな感じになるのでしょうか？　つまり上司だけでなく、同僚や部下、さらにはユーザや協力会社の社員など、プロジェクトの関係者に幅広く評価に参加してもらうということです。

プロジェクトが営業的にはうまくいったものの、プロジェクト・メンバーは疲弊しまくり、結局は大量の退職者を出してしまった、なんてことを避けるためには非常に良い方法かもしれません。また影に隠れて、ユーザからの評価に寄与していた人物が浮かび上がるかもしれません。プロジェクト内のコミュニケーションに大きく寄与していた人物がはっきりするかもしれません。

少しでも客観的な評価に近づくためには非常に有用な手法ではないでしょうか？

今、居酒屋で有名なワタミの社長をしてらっしゃる渡邉美樹さんが書いた、「もう、国には頼らない。」（日経BP社）を読んでいます。まだ読みかけなのですが、非常に共感・感銘できる内容で、夢中で読んでいます。

市場主義とは消費者が選ぶ直接民主主義の1形態であり、競争の原理を公のサービスにも導入することにより、大幅にサービスを改善することができること、そして本来「官」に求められるべき機能とは、フェアであることを監視する機能と、セーフティ・ネット（弱者保護）に絞られるべきである、という主張は非常に明快で、痛快ですらあります。

渡邉美樹さんの言う市場主義とは、あぶく銭を掠め取ることではなく、お金という投票用紙を用いた直接民主主義を用いて切磋琢磨しながら正しく経営、つまりマネジメントすることを指します。こういったノウハウを持っているのは、民間企業です。

つまり、結果として今まで公=官と考えられてきた分野でも、実は民間が行ったほうが効率的にサービスを改善できるということになります。そういえば最近郵便局が民営化されましたが、先日近所の郵便局に行ったらそれまでと対応が一挙に変わって銀行窓口並みにサービスに気を配るようになっていてびっくりしたのですが、こういったことも上記のことを立証する１つの事例かもしれません。

よく「お役所仕事」と揶揄されることとして、役人はプロセスに則ったことを淡々とこなしているだけ、という批判があります。プロセスにさえ合致していれば責任を取らされることはないので、それ以上「改善」しようと努力をしない、という話です。組織が巨大化してくるとある程度プロセスは重要になってきます。しかしだからといって、競争のない世界で同じことだけを繰り返していては組織は硬直化し、活力が失われ、金が無駄に使われ、ユーザが受けるサービスが最低になっていくことは、皆さんも百も承知の話だと思います。

これって、プロジェクトでも同じことが言えますね。重要なのはプロセス通りに進めることではなく、競争を意識した「マネージメント力」だと思うのです。

もし、自分の仕事にどこか「官僚的」なものを感じるのであれば、何かのヒントとして、ぜひ読んでみてください。読んで損はしない本だと思います。

ちょっと前にPair Programing（ペア・プログラミング、略してペア・プロ）という言葉が流行りました。コーディングを2名で同時に同じPCに向かって行うことで、より効率的にプログラミングができ、かつ互いの技術上のスキルの向上に寄与できる、というコーディング・スタイルです。update it, Inc.でもややこしい部分をコーディングしなければならないような場合に、社員が自主的にペア・プロを行っています。ただし普段からやっているわけではないです。

おそらく、技術的なスキル・ノウハウを「盗む」上では効果的な方法だと思います。ただし使うときを限定しないと、トータルの生産性はやはり下がるように思います。（どうしても片方の人が手を動かしている間はもう片方の人は見ている、つまり受身の状態になりやすいようです。）

以前、私自身の経験としてペア・プロ以上に効果的で、かつ生産性もかなり向上する方法だと思った方法として、Pair Designing、つまり2名で設計するというやり方があります。やっていた当時はそんな名前を付けていたわけではないのですが、今振り返って名前を付けるとなると、Pair Designing、ペア・デザですね。

用意する道具はパーティションのあるブースとホワイトボードだけです。そこに2名でこもって、会話と絵を描きながら延々と設計を進めます。誰でも打ち合わせと称して、パーティションに2名でこもってホワイト・ボードを相手に話し合いを進める、ということをよくやると思うのですが、そのスタイルで設計を行う、というだけの話です。

そんなの、いつもやっているよ、って人も多いかもしれません。

うまくツボにはまるとどんどんアイデアが沸いてきますし、一人で設計しているとなかなか見えてこない問題も見えるようになります。また「話す」ことによって、自分の考えをまとめるという効果も期待できます。

ペア・プロの場合と同じなのですが、この2名の設計者は2名とも実担当で、同じくらい設計対象のことをよく知っている必要があります。実力差が大きかったり、実担当ではない人とやるのではあまり効果がでません。

２、３時間もこれを真剣にやると、どっぷり疲れるのですが、非常に効率的に設計を進めることが出来ると思います。みなさんもぜひ1度、ペア・デザ、トライしてみてください。

CDS = Collaborative Documentation Serviceのまとめです。

CDSとは、以下のような特徴をもつ、プロジェクトにおけるドキュメント作成・管理を行う仕組みです。

１．ドキュメントを書き換えてコミットするだけで、対象者に「どこ」が「どう」変わったのかを伝えることができる。

２．非リアルタイム・コラボレーションであり、即座に変更したことを皆に伝えるのではなく、ある程度溜め込み、良く考えて練った上の内容をコミットした時点で、初めて公開される。

３．コンカレント性があり、同時に複数人で同じドキュメントを修正することも可能。

４．プロジェクトに関連する様々な人たちに対するインフラとなるサービスであり、本質的にセキュアでなければならない。

５．CDSの仕組みと履歴管理の仕組みは表裏一体であり、CDSを実現するシステムは、履歴管理の仕組みも有する。

CDS = Collaborative Documentation Serviceの話、第4弾です。今日は履歴管理について触れてみます。

Collaborative Documentation Serviceでは他の人のコミットした変更点が伝達されます。これを実現するためには、誰がいつ、どのような理由でどの部分を修正したのかをサーバ側で記録しておき、update時にそれをまとめてユーザに伝達するようにする必要があります。

この「誰がいつ、どのような理由でどの部分を修正したのか」という情報は、履歴情報そのものであり、これを管理しておけば履歴管理の仕組みが実現できることになります。

ある程度長期間に渡るプロジェクトの場合、プロジェクトの後半になってくると、ある仕様が当初からのものなのか、それとも何らかの理由があって途中で変更されたものなのかが問題になることがあると思います。これを後で探ろうとしても、いままではなかなかはっきりしない場合もあったのではないでしょうか？　CDSの持つ、この履歴管理の仕組みを用いれば、こういった調査がよりシステマティックに実施できるようになります。

ちなみにcrossnoteの場合、例えばVer 1.0リリース時のドキュメントはこうでした、という印を付けておき、必要な場合にはその印の付いた時点のドキュメントを取り出して見る、などといったこともできるようになっています。この印のことをタグと呼びます。CVSやSubversionなどにあるタグと同じものです。

今日も引き続き、CDS = Collaborative Documentation Serviceの話を続けます。内容は、CDSがなぜセキュアでなければならないのか、という話です。

CDSはプロジェクトにおいて、共同で仕様や設計を進めるためのインフラとなるべき仕組みです。一方でセキュリティは様々な部分で総合的・網羅的に機能する必要があります。１つでもホール（穴）があると全てが台無しになってしまうのは皆さんも百も承知の話だと思います。ですので、セキュリティを担保する仕組みはインフラ部分に組み込み、総合的にコントロールできるようにすることがとても肝要なのです。

ではプロジェクトにおけるセキュリティとはどんなことがあるのでしょうか？　1つには役割に応じて、できること、できないことをはっきり分けるということだと思います。

通常のファイル・サーバのセキュリティ管理の仕組みの場合、ドキュメントに関しては、大雑把に言うと、所属させるグループ毎に見れるか、書けるか程度のことしかコントロールできません。例えばあるサブシステムを開発するチームにおいて、パートナー会社の社員の場合には印刷やコピー、メールでの転送などでデータを持ち出せないようにしたい、と思ったとしてもまずほとんど不可能に近いことがわかると思います。

CDSはプロジェクトのさまざまな関係者が使うことを想定していますので、どういう人がどういったことができて、どううことはできないのかをきちんとコントロールできなければなりません。上記で説明したようなことはインフラとなるCDSがコントロールできるようにすべきでしょう。また権限のない人が勝手にドキュメントを消したり中身を改ざんするようなことはできないようにしつつ、一方でわからない部分にはコメントを付けて質問できるようにする、などといったコントロールもできるべきだと思います。こういったことは、単に読める、書ける程度のコントロールでは実現できないことです。

最近、様々な情報漏洩に関する事件が報道されています。また企業にとっても情報は最も重要な資産の１つのはずです。いろいろな立場の人が関わるプロジェクトだけに、こういったセキュアな仕組みが本来必要なのではないでしょうか？