« 2006年07月13日 | top | 2006年08月01日 »
2006年07月22日
IHCPC
白田氏の「インターネットの法と慣習」を読んだ。
アイデア満載で面白く、笑いながら勉強できるすばらしい本だった。
白田氏がひとつ面白いアイデアを提案していたのでここで紹介する。
hotwiredの元記事にほぼ同じテキストがある。
白田氏いわく、
> もうすでにあるのかも知れないけど、ネットワークでの人々の交流を分析したうえで、
> Inter-Human Communication Protocol みたいなものの草案を作成し始めてもいいんじゃないだろうか。
> プロトコルに従わない人を排除するのは、権利の否定や人格の否定ではなくて、
> 単に「403 Forbidden」というメッセージが返ってきただけのものとして処理することはできないだろうか。
> プロトコルに従わない人のメッセージを存在しないものとして扱う技術的・心理的実装はできないだろうか[*2]。
インターネット全体における人々の交流をプロトコルとして、
技術的に記述するという試みは、とても面白いのだが、そこに至るまでの道は、きわめて長い。
私は、インターネット全体を対象とするのではなくて、それより先に、
企業で働いている人同士のコミュニケーションのやりかたを技術的に記述する試みが、
まず最初に具体的な形になって現れてくると思う。
そして、ちょうどネットワークプロトコルスタックそのものの進化と同じように、
原始的な「組織内プロトコル」の事例が数百、数千と増えていったら、
組織内プロトコル同士をブリッジしたり変換したりするようなプロトコルが登場するのだ。
まず、企業やNPOなどの、ある目的を共有する組織は、かならず何らかのワークフローや
コミュニケーションの手順を、一部について明文化し、一部について暗黙に運用している。
そしてワークフローのペーパーレス化、リモート化、リアルタイム化、バーチャル化の進行にともなって、
これまで人力によって運用されていた部分が、相当程度、機械化されていく。
これは実際に、多くの企業において、ものすごい勢いで進行している現実である。
これまで「地理的に分散した組織の運営」は大きな企業だけの問題だったが、
これからは小さな企業も同じ問題をかかえるようになるから、ワークフロー管理システムも、
重厚なものから軽快なものまで、選択肢が増える必要がある。
たとえばコミュニティーエンジンでも、日本と中国のスタッフの合計人数が60人に近づき、
同時進行しているプロジェクトの数が15を超えて、顧客の数も増え、
組織全体に蓄積されている知識の量もすごい勢いで増え、管理の限界を超えつつある。
各プロジェクトや各個人がばらばらのツールを使っている状態が限界を迎えたのだ。
誰が何に詳しいのか、誰が何を担当しているのか、どのタスクがどんな困難を抱えているのか、
必要なドキュメントはどこにあるのか、ビジネス上のリスクはどこにあるのか。
ミクロな視点とマクロな視点の両方をもれなく提供するシステムが欲しい。
そのため、プロジェクトを横断する、全社的なワークフロー改善のためのしくみを
日本と中国の両方をつなぐかたちで同時に実装しようとしている。
そのために複数のエンジニアを割当てて、独自のシステムを開発するのだ。
このシステムを作るときには、会社組織の中でどんなコミュニケーションが必要なのかについて、
まさに人間同士のコミュニケーションのありかたをプロトコルとして定義し、
そのプロトコルに基づいてシステムを実装する作業をすることになる。
そのプロトコルには当然、誰が、いつ、どんなデータを、
何の目的で、誰に対して、どういう形式で送信し、どういった条件になったらエラーで、
データを受信したときにすべき行動は何で、といった技術的な記述が含まれる。
このプロトコルは、企業内で使うあらゆるデータを扱う、かなり複雑なプロトコルにならざるを得ないが、
それでも、ちいさな企業の内部で必要なプロトコルであれば、ネットワーク全体にくらべると、
現実的な時間の中で設計、実装ができるはずだ。
このようにして生まれる Inter-Human Communication Protocol in Corporation が、
いつか来る Inter-Human Communication Protocol の原型になっていくに違いない。
たとえば私たちの場合なら、プロトコル定義は以下のようになるだろうか。
スタッフの種類は、社長、PM、アシスタントPM、それ以外がある。それぞれのノードは図（省略）のように接続される。
スタッフ間の接続は、明示的なミーティング、動画ツール、メール、電話、なんとなく聞こえる音声、なんとなくみえる画面、skype、wiki、ブログ、SNS、によって実現する。
各スタッフは、個人作業状態、共同作業状態、コミュニケーション状態、アイドル状態のどれかである。
各スタッフがオフィス内のどの位置にいるべきかは、リソース管理の目的にそって決める。
各スタッフには中心とするスキルがあり、それはプログラミング、システム管理、グラフィックデザイン、サウンド作成、テスティング、経理処理、日本語文言作成、契約書内容確認、新規事業開拓、（以下略）がある。もっと細かく。
プロジェクトという単位があり、それは明文化された目的、手段、担当者、必要なスキルセット、期限、細分化された１ヶ月以内のtodoリスト、数ヶ月以内のマイルストーン、数年以内の長期目標をもつ。
各プロジェクトは、毎週の定例会議を行い、必要なスキルセットや資源などが不足していないか確認し、もし不足あるいは余剰があれば、リソース管理システムにアクセスしなければならない。また毎週の会議記録は別記のメタデータをつけた状態でデータベースに格納する。
プロジェクトの目的には大きく３種類があり、１）短期的な商品開発 ２）基礎部分の開発 ３）実験 それぞれごとに図（略）のようなスタッフ体制をとり、レポートラインを構築する。
．．．
といったような感じでおそらく概要仕様だけで数ページ分にわたるものになるだろう。
可能なかぎりすべてのコミュニケーションをプロトコル化することで、組織全体が
整然と足並みをそろえて目的のために進むことができる。
こんな組織は機械的すぎて嫌だ！という向きもあるだろう。
しかしこうして利益を生む部分の効率を20%上げることができたら、
余った時間で利益を生まないプロジェクトを自由に推進することができるのだ。
実験プロジェクトでは、型にとらわれず、自由なやりかたでやればいい。
ワークフローを徹底的に効率化して余剰資金を作り、
その金をつかって実験を繰り広げるというのは企業としては当然のことだ。
「コミュニケーション能力の高い人格者」が統治する政治から、
技術によるアーキテクチャが統治する政治へ移行するはずという、
白田氏の議論のベースとなっている考え方は、まず企業において適用されるのだろう。