update it, Inc.社長のブログ

ちょっと前に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弾です。
そんなのあるか？（あるわきゃないだろ！）ってタイトルですね。もしそんな方法が存在していたら、皆がその方法を導入するので、結局は常に勝つというのはありえない。それはそうです。

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

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

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

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

昨日の競争入札の話と若干絡む話題ですが、今日はベンダーの評価について書いてみます。昨日は競争入札制度について疑問を投げかけたのですが、そうは言ってもこれについてより良いベンダーの選定方法があるかといえば、正直なところ、現時点ではなかなか難しいのだろうと考えています。なぜならば、ベンダーを評価する客観的な指標といえるものが存在していないからです。

現状の競争入札制度は客観的な指標として、価格に非常に重きをおいたものと考えることができます。これは非常に明快な指標であり、ブレがありません。従って客観的な判断材料としては非常に優れた指標です。

ただ、目的（システムを品質、コスト、納期をバランスさせてもっとも良い状態で完成させること）を達成するための指標としては偏った指標であるといえます。

もし、より適切な方法を考えるのであれば、KPI(Key Performance Indicator)のような考え方が必要なのかもしれません。ただしこれを行うためには、主成功要因(CSF)は何か、それを表す指標(KGI)は何なのかをシステムを発注するたびに、事前に定義する必要があります。また参加するベンダーはみな、普段から指標値を計測しておき、発注元から求められたときにその値を提出できるようにしておかねばなりません。またその値が正しいかどうかを監査する第三者機関も必要になります。

そもそもシステム開発を成功させるためのCSFは何で、それを適切に表すKGIとしては何を参照すべきかについてはかなりの研究が必要で、そうおいそれと「とりあえずこれで行こう」というわけにはいきません。

いままでシステムの開発工数を算出するための研究というのはいろいろ行われてきたと思うのですが、適切なベンダーを導出すためのファクターを研究したというのは、私が知らないだけかもしれませんが、少なくともあまり有名なものはないのではないでしょうか？

将来に向けて、こんな研究を行う大学があっても良いと思いますが…

今日も天気が悪い。

昨夜帰るときに小雨が降っていたので、自転車で帰れませんでした。従って今日の出社も電車です。雨が降ると自転車に乗れないのが悲しい。

公的機関や公共性の高い法人などがシステム開発を委託する場合、通常は競争入札が必要とされています。コストを下げるという観点ではとても重要な仕組みだと思いますが、私は果たしてシステム開発の委託に対してこの競争入札という仕組みは適切なのだろうか？　といつも疑問に感じてきました。

その理由は以下のような点です。

１．価格が安いところが本当に適切な委託先なのか？

２．ある程度の規模のシステムを委託開発する場合、「上流工程」と「下流工程」を分離発注せざるを得ないが、このことがかえって非効率性を生まないのか？

３．競争入札制度が成り立つには、「どこに発注しても結果は同じ」という前提が必要だと考えられるが、これは果たしてシステムの委託開発について成り立つのか？

価格については、確かに安いに越したことはないのですが、プロジェクト・マネージメントの基本原則であるQuality/Cost/Deliveryのバランスのことを考えた場合、CostとDeliveryが極端に抑えられた成果物のQualityはどう担保するのだろうか、と思います。つまり果たして委託する側はそのQualityをきちんと『事前に」評価することが出来るのだろうか、ということです。

もちろん受託側がオフショア開発などによって構造的に低コストで開発する能力を持っているのならば良いのですが、それでもQualityを確保するには相応のCostが本質的にかかるはずです。（ここでのQualityは単なるソフトウェアのバグの割合の話ではなく、そのソフトウェアがどれだけ「役に立つか」という観点の話です。）

上流工程と下流工程の分離発注と競争入札が組み合わさると、それぞれ違うベンダーが担当することになりますが、これは逆にコストアップ要因になってしまうのではないかと思えます。上流の設計する側がどう作りこむかという観点なしに勝手に設計を進めてしまっては、結局下流工程担当側が相当な修正を強いられることになり、結果として工期が余計にかかってしまうことになりかねないのではないでしょうか？

最後の「どこに頼んでも結果は同じ」というのは、恐らく皆さんも納得しない人が多いのではないでしょうか？　やっぱり受託する会社、もしくは担当するプロジェクトチームにより「できる」「できない」の能力差が大きく出るものと私は考えます。プロジェクトが成功した割合は100%を大きく下回っているという事実があります。受託する会社の能力によって、この割合というのは大きく変わると考えるのは自然ではないでしょうか？

世の中の報道は一方的に随意契約が悪い、ということしか取り上げませんが、そういったニュースを聞くたびに果たしてもう一方の競争入札制度が本当に正しい姿なのか、私はいつも疑問に感じています。