update it, Inc.社長のブログ

近年、システム開発の世界では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がコントロールできるようにすべきでしょう。また権限のない人が勝手にドキュメントを消したり中身を改ざんするようなことはできないようにしつつ、一方でわからない部分にはコメントを付けて質問できるようにする、などといったコントロールもできるべきだと思います。こういったことは、単に読める、書ける程度のコントロールでは実現できないことです。

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

CDS = Collaborative Documentation Serviceは、非リアルタイム・コラボレーションの一種です。

いままでのコラボレーション・ツールの主流はむしろ、リアルタイム性を重視したものが多いと思います。例えば誰かがスプレッドシートに数字を入力したら即座に同じスプレッドシートを見ている他の人に伝達する、といったものです。それに対して、CDSの考えではむしろ、ドキュメントを書いている最中は他の人にはその修正内容は見せずに、ある程度きちんと推敲し終わった後で初めてコミット→他の人に伝わる、という形になっています。

実際、ドキュメントの修正がリアルタイムで伝達されることが求められるのは、オンラインでの会議など、特定の使い方をする場合に限られるのではないでしょうか？　通常はドキュメントはいろいろと検討や推敲を重ねた上で公表、つまりコミットするものだと思います。ですので、むしろ非リアルタイムのコラボレーションとすべきものだと思うのです。

CDSは非リアルタイムのコラボレーションなのですが、もう一方で「コンカレント」であるという特徴があります。コンカレントとは同時に協調して動作するということです。普通は、サーバにおいてあるワープロのファイルを開くと、他の人は読み取り専用でしか開けなくなると思います。つまり、一人があるドキュメントを修正している間は他の人はそのドキュメントについては一切修正ができなくなり、その人が修正を終えるまで待たなければならないというのがいままでのワープロでした。

CDSでは、基本的にコンカレント性を重視します。つまりあるドキュメントを誰かが修正していても、他の人も同じドキュメントを修正できるようにする、ということです。例えばAさんが第1章から第3章までを担当し、Bさんは第4章から第6章まで、Cさんはそれ以降の部分を担当する、などということが、CDSでは各自ドキュメントをローカルにコピーなどすることなしに、同じドキュメントを直接同時に修正することで、できてしまう、ということです。

CDS – これはCollaborative Documentation Serviceの頭文字をとったものです。以前のブログにも書いたとおり、このCollaborative Documentation Serviceというのは、crossnoteのキー・コンセプトです。

これを一言で説明すると、以下のようになります。

Collaborative Documentation Serviceとは –
『ドキュメントを書き換えてコミットするだけで、対象者に「どこ」が「どう」変わったのかを伝える仕組み』

私が何でこれを思いついたかというと、プロジェクトで次のようなことが良く起こっていたからです。

１．最初のうちはきちんと仕様をドキュメントに書いています。

２．プロジェクトが進むにつれて、様々な仕様変更が発生します。その仕様変更について、メール上でああしよう、こうしようとやり取りします。

３．プロジェクトが忙しくなってくると、上記の仕様変更内容をドキュメントに反映し忘れ始めます。

４．これではイカンということで、ドキュメントを修正してメールで回覧する方式にすると、様々なバージョンのドキュメントが散乱することになり、それはそれでどれが正式の仕様なのかがわからなくなりがちです。またちょっと直しただけで毎回でかいドキュメントを送りつけられ、どこが変わったのかをチェックしなければならない受け取り側もえらい迷惑です。

５．最終的に、ドキュメントは「当初の」考えを示すだけのものになり、実際の仕様とは大きく乖離した状態になる場合があります。こうなってしまってはなかなかドキュメントを修正する気力も出ません。

６．さらに後になって、仕様がどうだったかを調べようとすると、ドキュメントとメールの両方を調べなければわからず、大変な思いをします。

皆さんはどうですか？　いつも完璧にこなしているという方もいらっしゃるかもしれませんが、私は恥ずかしながら、上記のような状態になることが多かったです。でもそこでふと考えたのです。そもそもメールとドキュメントの２つのものを同時に書かなければならないことが間違っているのではないかと。

ドキュメントの情報は後で参照するときに体系だてて理解できる構造になっています。一方のメールの情報は順を追って読まないとわかりづらく、また体系付けられてもいません。

では、メールを書くのではなく、ドキュメントを修正したら自動的に差分が通知されるようにしてはどうか？　その差分の情報をメールのように皆に通知してはどうだろうか？　さらに自分の「考え｣を説明するためにコメントなどをいろいろと付けて、そのコメントをやり取りできるようにすれば、もうメールは要らないのではないかと。

これがCDS – Collaborative Documentation Serviceを思い立った原点です。プロジェクトが破綻する最大の要因は、仕様を纏め上げる作業、すなわち上流工程に問題がある場合だと思います。プログラミングの世界ではどんどんシステム的なサポートが充実してきているのに、上流工程部分にはシステマティックなサポートがありませんでした。この仕様をまとめ上げる仕事を少しでもバックアップできるような仕組みとして、このCDSを普及させていきたいと思います。

先日からの競争入札に関するシリーズ、第3弾です。
そんなのあるか？（あるわきゃないだろ！）ってタイトルですね。もしそんな方法が存在していたら、皆がその方法を導入するので、結局は常に勝つというのはありえない。それはそうです。

だた１つだけ、方法があります。それは対象の領域において、競争のない、唯一の存在になることです。唯一の存在であればそもそも競争にはなりません。また唯一の存在の場合には、公共機関であっても随意契約が認められたと思います。

もちろん現実問題として、唯一の存在になるというのは通常は不可能に近い話です。対象領域でデファクトスタンダードとなれれば唯一の存在だといえますが、普通はそのデファクトスタンダードを目指しても、そうなれるものではないから苦労しているのですよね。

でも、たとえデファクトスタンダードなどという大仰しいものになれなくても、もしある特定の機能を提供できる唯一の存在になれたとしたら、少なくともその機能を欲する発注元からみれば唯一の存在になることができます。たとえそれ以外の部分は他のベンダーからも提供可能なものであったとしてもです。

つまり、画期的なイノベーションを独自に持つことができ、それがある機能を実現する唯一の方法となる場合、それを武器として競争のない世界へいけることを意味しています。イノベーションが大きな価値を創造するということです。