update it, Inc.社長のブログ

先週の金曜日はオブジェクト倶楽部のイベントに行ってきました。いろいろな企画があり、面白かったです。（それでブログを休んでしまいました。すみません）

一番感心したのは、ライトニング・トーク(LT)といって5分間のプレゼンテーション・コーナーがあるのですが、出てくる皆さん、非常にうまい。プレゼンテーションソフトによるビジュアルをうまく使い、シンプルに、かつ非常にテンポ良くプレゼンテーションを進めています。笑いのツボを押さえている人も多く、それがさらにプレゼンテーションに魅力を加えていました。

ちなみに今回のLTを見ていて、いくつかのパターンを発見しました。

１．文字がでかい。
言いたいことをできるだけシンプルに訴えるためには、でかすぎるほとでかい文字が効果的なようです。

２．漫画を利用する。
自分の訴えたい感情を、本来はぜんぜん関連性のない漫画の一こまを利用して説明している人が多かったです。「なんでここでこの漫画がでてくる？（笑）」

３．「落ち」を用意しておく。
プレゼンテーションとしては、非常に高等な技ですが、これがあると印象がだいぶ違うようです。

あのプレゼンは、内輪だから面白いのでしょうか？　もし外向きの、例えばセールスのプレゼンテーションや、会社の企画会議であれをやったら、やっぱりまずいのでしょうかね？　（結構面白いかもしれませんよ。結果は保証しませんが。）

crossnoteを作っている間、できるだけマニュアル・レスで行こう、と社内で話していました。自分はマニュアルを読まない人だし、周りに話を聞いてもやっぱりマニュアルを読むって人はあまりいませんでした。だからマニュアルなんてなくてもいいじゃないか、そう思っていました。

でも最近ちょっと考えが変わってきました。やっぱり必要なのではないかと。もちろん機能説明に終始するようなマニュアルはあまり意味がないと思いますが、何か困ったことがあったときに、ちょっと参照して解決方法がわかるようにするためのマニュアル。これはやっぱり必要そうです。

これって、マニュアルというよりはQ&A集のようなものかもしれません。「やりたいこと」に対して具体的な手順がきちんとわかる形で書いてあればそれなりに役に立つのだと思います。

crossnoteは表向きのワープロ部分はさておき、同期をしたり比較したり、コンフリクトを解消したり、といった動作はCVSやSubversionのような構成管理ツールを利用したことのある人ならばすぐにピンと来ると思いますが、そうではない人にとってはいざ直面してしまうと面食らってしまうかもしれません。そんなときにちょっと参照できるものを用意していこうと思います。

昨日のブログには「創作活動は非同期的がいい」と書きました。そして「プログラミングだって立派な創作活動」とも書きました。その例として今日はオープンソースの世界を考えてみます。オープンソースの世界は昔から非同期的に時間が共有されていました。

オープンソースでのプログラムは世界中のプログラマー達がそれぞれの空いた時間などを利用して（たまに専任の方もいらっしゃいますが）開発されています。世界中の人が関与するということは、一同が会することはなく、時間も場所もばらばらに開発されていることになります。それでいて、ソースコードがおかしくならないように、うまく意思疎通をはからねばなりません。

オープンソースのプログラマーにとって意思疎通するための最も重要なものは、ソースコードそのものです。CVSやSubversionなどのバージョン管理システムを使うことにより、各プログラマーは誰がいつ、どの部分をどのように修正したのかがわかるようになっています。自分の修正が他人の修正とぶつかっていない場合には自動的にソースコードに変更点を反映させることができます。もし修正がぶつかってしまった場合にはそれを検知して、どこがぶつかったのかを教えてくれます。またどのように変更したのかを比較したり、バージョンを戻したりすることが自由に出来ます。

この仕組みがあるので、世界中のプログラマーが24時間、離れた場所にいても開発することができるのです。メールでのやり取りも重要ですが、それ以上にこのソースコード上でのやり取りができることが大きなポイントになっています。

これこそが、非同期的に時間を共有するための仕組みです。

オープンソースの世界に少しでも関わると、あ、世界につながっているんだなって、感じることができます。しかもこっちが寝ている時間帯でも誰かが関わっているかもしれない。非常に不思議な、面白い感覚にとらわれると思います。

ここのところ「非同期的時間の共有」をテーマにブログを書いていますが、今日は創作活動と非同期的時間の共有という考え方の親和性を書いてみます。

創作活動にはいろいろあります。文章を書くこと、絵を描くこと、作曲することはもちろんですが、例えばプログラミングだって立派な創作活動です。著作物を作っているのであれば、基本的には創作活動をしていると思ってよいと思います。

創作活動には時間がかかる、という特徴があります。ジャズのアドリブによるセッションなど、特殊な例はありますが、一般に創作活動といわれるものは一過性ではなく、時間をかけて作り上げる場合が多いと思います。これは頭を使わなければならないからでしょう。創作活動を行うには頭を使わなければならず、人間が頭を使うのには時間がかかる、というわけです。考えるには時間がかかるんです。

思いつくのは一瞬かもしれませんが、そこにたどり着く前にいろいろ考えた結果、思いつくのです。

さて、「非同期的時間の共有」が対象とするには、共同で行う創作活動が多いと思います。最初に「非同期的時間の共有」の例であげたニコニコ動画は個人の感想を述べ合うというのが個々人の創作活動かどうかは判断が難しい部分もありますが、そういった字幕が入り込んだものは、ある種の共同作品のようなものと言えるかも知れません。

共同で何かを行うためには、通常はみんなが、同じ時間・同じ場所に集まる必要があります。でもこれを何らかの仕掛けを使って、そのような制約がなく共同で創作活動ができるような仕組みを提供すること、これが「非同期的時間の共有」だと思います。

創作活動には自然に時間がかかる、その上同じ時間・同じ場所に皆が集まらなければならないとしたら、これはとてつもなく大変なことになると思いませんか？　なので、創作活動を非同期的に、たとえ場所が異なっていても、時間が異なっていても共同で行えるようになっていることは非常に都合がいいのです。

先週末に非同期的時間の共有というテーマでブログを書きましたが、今思い返してみると、crossnoteのようなものができないか、と思いついた最初のきっかけも、ある意味、この「非同期的時間の共有」的体験がベースになっています。

以前、Eclipseという統合開発環境とソースコード管理システムで有名なCVSを使ってプログラムを作っていたときがあります。これを使うとプロジェクトチームの誰かがプログラムのソースコードに修正を加えて、それを「コミット」していると、その後で自分がEclipseを立ち上げて、CVSの同期を行うと誰が、いつ、どの場所を変更したのかがわかるようになっています。

使っていると、単にプログラムの修正箇所がわかるだけでなく、「おー、あいつ、こんなにがんばって修正しているんだ」とか、「あいつ、こんな時間まで働いていたのか…」とか、「これ、難しいバグだったけど、よくこんなことわかったな」とか、いろいろなことがわかるんです。ソースコードの変更点を通じて、プロジェクト・メンバが前日にがんばっていた様子が浮かび上がってきて、うれしい気持ちになる、そんな体験を幾度となくしてきました。

この原体験（？）のようなものが、crossnoteのきっかけです。

非同期的時間の共有とは、ある種の記録の再生に過ぎないのだと思います。ただ今までの単なる記録の再生手段とことなるのは、そこに自分の意見なり、創作物なり、なんらかの手を加えることにより、時間を越えてコミュニケートできる、ということだと思います。そういった意味では、例えば手紙やメールなどの延長線上にあるものかもしれませんね。

最近、Second Lifeの人気が下がってきている、一方でニコニコ動画の人気は過熱する一方だ、という記事を見ます。Second Lifeは3Dの技術をたぶんに入れ、リアルタイム・コミュニケーションに力を入れてきました。一方のニコニコ動画は、言い方は悪いですが、Second Life程には技術力を誇示していないように見えます。またニコニコ動画上でのコミュニケーションはリアルタイムではなく、疑似リアルタイム的なコミュニケーションです。では、Second Lifeのほうがより未来型のコミュニケーションなのか、というと、どうも違うらしいということが上記の人気の結果でわかると思います。

リアルタイム・コミュニケーションを行うためには、関係しようとする人同士が同じ時間にコミュニケーションしなければならない、という制約が存在しています。実はこの制約が大きく作用していて、人気の差になっているということのようです。

同じ時間ということになると、その時間を逃せばもうコミュニケーションは成り立たなくなります。一方のニコニコ動画は疑似リアルタイムであり、実際には別々の時間にその動画にコメントした人同士が、あたかも同じ時間にコメントしあっているように見える、ということで、非同期のコミュニケーションを成立させているところが人気の秘密だそうです。

コンピュータによるコミュニケーションのすごさというのは、今までの通信とことなり、時間さえも越えてしまう、ということなのかもしれません。つまり、過去時点のある人と、現時点の私がコミュニケーションし合っているように感じるわけです。もちろんこれはあくまで「疑似｣体験に過ぎないわけですが、そう感じさせてしまうことって、すごくないですか？

いろいろな意味で、これからのコミュニケーションは非同期的時間の共有に向かう、と私は予測します。

本日はブログを休みます。

昔、同じ年金問題とシステムというタイトルでブログを書きました。そのとき、「裏付けのないまま事を運んだ場合のリスクを考えていない」ことを述べました。「一年以内の突合を公言したために、期限を守ることが絶対条件になってしまった、と考えると、この後、悲喜こもごもとしたことがいっぱい起きそうだ」とも書きました。

昨日の年金の「年金　年度内解決を撤回」ニュースを見ていると、やっぱりね、という感じを受けました。そもそも名寄せって、とんでもなく大変な作業であることは、やったことのある人ならわかると思います。「ここまでずさんであるこということは想定外」というコメントがありましたが、この発言者の方にとっては本当に想定外かもしれませんが、実際に関わっている当事者の人はどうなのでしょうか？

もし、本人達は無理だと気づいていても、それを言い出せないような状況になってしまっていて、切り出せなかったとしたら、やはりリスク管理に大きな問題があったことになるのではないでしょうか？

以前私は、システム開発が失敗する原因は要件定義段階に問題があるケースが多い、ということを言っていますが、今回のケースもおよそ同じような話だと思っています。そして、プロジェクトのメンバの中にはその失敗の芽に気づいている人もいるはずです。でもその声が反映されない「仕組み」に問題があるのだと思います。

こういうのって、ITガバナンス的な考えで解決すべきテーマなのかもしれませんね。

最近内部統制まわりの勉強中です。『これでわかる会社の「見える化」と攻めの内部統制 – 平松　徹著　週間住宅新聞社』という本を読んでいたら、ISOのマネジメントシステム関連の認証を取るケースで、良いISOと悪いISOがあるという話が載っていました。

この悪いISOのケースとして、ISO認証を取るためにドキュメントを2重管理している例を挙げています。ISO認証を取るためには業務プロセスのドキュメント化が必須ですが、その際に実際に使っているドキュメントとは別に、ISO認証を取るための別のドキュメント類を構築して両方を維持している場合がある。そうするとドキュメントの2重管理となってしまいコストが余計にかかってしまい、ISO認証は負担が大きいということで認証を返上するケースが相次いでいる、という話です。

業務設計する際に、システムによりデータを一元化するのは基本中の基本だと思うのですが、この手の作業を現場に任せてしまうとなかなか徹底されず、結局例外だらけで効率の悪い体系になってしまう場合があります。といって、外部コンサルタントに丸投げしてしまっては、結局現場では使い物にならないISO認証専用のドキュメントが出来上がり、現場で使い続けられるドキュメントとISO認証のためのドキュメントの2重管理になってしまう場合がある、ということなのでしょう。

いずれにせよ、実際に業務をしている人達が、自分達でその業務を効率的にまわすにはどうすべきなのかを一生懸命考え、その結果を１つのドキュメントとして反映させていくのが正しい姿なのだと思います。そして重要なのは、そういった、現場サイドにおける細かな改善をどんどんドキュメントに反映させていき、より良いプロセスに改善していくということではないでしょうか？

ドキュメントは一元化、そして現場での改善を吸い上げることが出来る仕組み、こういったあたりが成功へのキーワードではないかと思いました。

私はどうも日々の業務に忙殺されがちです。なんせ小さな会社なので、なんでも自分でこなさなければなりません。でもそんなことばかりやっていると、一番重要な、大切なことが抜け落ちてしまいます。そこで会社の関係者の方のアドバイスに基づき、中期アクションプランを作成することにしました。

要はプロジェクト・マネジメントと同じで、WBSに落とし込んでスケジュール化する、というだけなのですが、難しいのは比較的プロセスが明確なシステム開発プロジェクトとは異なり、状況に応じていろいろな「パス」が発生しうるという点です。その都度書き換えていけばよいのだと思いますが、そうは言っても想定しうるパスについては書いておきたいもの。

そうなると、ガンチャート的なスケジュールには不向き？のように思えます。何か良い方法はないものでしょうか？