堅牢な人間関係を作りたいならコンセンサスはラフにしておくに限る何事にも「タメ(時空間上の余裕)を作るクセ」を作らないと、世の中はうまく回らないことになっている。不良設定な二者択一の課題に条件反射で反応してしまい、取り返しのつかない事態になってしまった経験がある人も多いだろう。タメは、時空間上にはグレーゾーン(=どっちに転んでも良い)として存在する。このグレーゾーンをうまく生成するための技術が「ラフ・コンセンサス」である。Force)がインターネット(TCP/IP)およびその上で展開される技術標準を決める時の合意形成の方法論である。緩い合意形成の上で実際にコードを書いて、走らせてみて、当初の合意を微妙に変化させつつ、徐々に品質を高めていく開発手法、あるいはその時にその開発グループにもたらす集団的な感覚という文脈で用いる。いわゆる「アジャイル開発」とは似て非なる、一種の思想のようなものだと考えて良い。ラフなコンセンサスは、サービス・インした後も維持されるので、特にクラウド上で展開されるWebサービスは常にベータ版であるという「コンセンサス」に基づいて日々改良が行われていたりする。合意自体はラフでも、必要な作業は極めて緻密に行われるのはいうまでもない(注1)。いうようなラフなコンセンサスの本来の意味はともかく、この「コンセンサス(=合意形成)」の手段として私たちが日常的に行っているのが「会議」だ。ところが、多くの日本の企業で行われている会議は「この会議室で、何時から、誰が出席し、1時間で終わる」という形式だけが「厳格に合意」されていて、肝心の議論のテーマや中身がラフ(荒削りというよりは単に杜撰なだけ)なので、何ひとつ「まともな合意形成」ができないまま終わる。成果が出ていなくとも、会議の出席者は一仕事終えた気分になれるから厄介だ。膨大な時間が浪費されていることを想像すると、戦慄すら覚える。真逆の例が、宮本常一の『忘れられた日本人(初版は1960年、未来社)』で紹介されている。ここでは、とある村の公民館での会議(集会)の様子を宮本が観察した結果が報告されているのだが、この村で実施されているある日の会議は、解決すべき課題(テーマ)はざっくりと決まっている。主催している人もずっとそこにいる。ところが、その会議に出席すべき村人は、適当な時間にやってきたり、面白くないと思えばいなくなったり、という具合で、なんともいい加減なものだ。時間は長時間に及び、最初から最後まで参加している人はほとんどおらず、出入り自由でもある。建設的な意見を述べる人もいれば、横になって寝ているだけの人もいる。農作業で疲れた体を癒すためだけにそこへ足を運ぶ人でさえ歓迎される。ところが、朝から晩まで続くこの緩々の会議は、最終的には村人ほぼ全員の合意を取り付けることに成功し、「たった1日」で極めて堅牢かつ柔軟性の高いコンセンサスが出来上がる。優秀な大卒を揃えた大企業で展開されている無駄な会議よりも、こちらの公民館での会合に「知性」を感じるのは筆者だけではなかろう。ラフコンセンサス事例は、音楽の世界でいうとジャズに多い。)のライブなどは、テーマとざっくりしたグルーブ感やニュアンスだけ事前に大まかに合意しておいて、演奏(テーマ)がスタートすれば、適当なタイミングで個々のアドリブを延々と回した後、最初のテーマに戻ってマイルスがまとめる。アドリブの長さや内容などは、個々のミュージシャンにお任せ、演奏全体の出来不出来は終わってみなければわからない、というようなものだが、参加しているミュージシャンが高いレベルで揃っていると、作品のレベルは(まあ当たり前だが)高い。増えるほど、合意の粒度(granularity)は大きくなり、個人レベルでの具体的な作業の詳細も曖昧になっていくので、ラフコンセンサスは似たような水準の少人数で実施していく方が良い。少人数の人間関係を堅牢にする手法としてラフコンセンサスの右に出るものはない、ということもいえるだろう。「こいつとは月に1回くらいのペースでメシを食いながら議論すればいいかな」という具合に「相互に暗黙の合意があるのだが、合意の輪郭自体をラフにしておく」ことが長続きの秘訣になる。事業開発自体を一種のアイドリング状態にしておいて、あまり強い制約のない状態で、ああでもないこうでもない、と議論していれば、そう遠くはない将来に何か形になる。待てば海路の日和あり、というわけである。誰とコンセンサスを形成するか、ということ以上に重要なのが「そのコンセンサスをどこで形成するか」、つまり「場所」だ。場所こそがコンセンサスの品質を決めるといっても過言ではない。ネット空間(における閉じたコミュニティ)はラフコンセンサスを形成する場所としては最悪だろう。納期が短く、かなり細かい作業の進行管理以外では使わないほうが良い。Backlogのような進行管理ツールでラフコンセンサスを、と考える馬鹿が1人乱入すると、そのプロジェクト全体が台無しになる。場所としては、実空間に勝るものはない。Communities)」に限る。サードプレイスとは、簡単にいえば「自宅と職場ではない場所」である。彼のいうサードプレイスはくつろげることが目的になっているので、ロンドンでのサードプレイスの例としては「パブ」が紹介されている。ラフコンセンサスが目的になるのであれば、酒が前提のパブではなく酒をあえて排除したコーヒーハウス(Coffeehouse)、すなわち17世紀から18世紀にかけてロンドンで大流行した「喫茶店」の方が良いだろう。Lloyd’s)がコーヒーハウスを発祥の地としているのは有名な話だが、酒が入るとラフの輪郭がさらにボヤけ、かつ無駄に大きくなるので、実行可能性が低くなる。居心地の良さ自体がゴールならパブや居酒屋の方が良いのはいうまでもない。和文化独特の視点からは、縁側・土間・離れが魅力的だ。残念ながら全て絶滅危惧種になりつつある施設だが、WeWorkのような舶来商品に飛びつく前に、今一度、日本らしい価値創造を行うための日本らしいサードプレイスの再発見とその運用に注力した方が、安上がりでかつ教養的だと思うのだが、いかがだろうか。注1)このような仕事の進め方は、セキュリティ対策等がどうしても事後的になるので、この思想で規模を大きくしたベンダーは何か事故が発生するとメディアから叩かれる傾向にある。そもそもこの思想でなければ、価格性能比を現在のレベルにまで到達させるのは不可能だっただろう。critical)」は、交通機関などの社会資本や金融機関の基幹システム、すなわち極めて高い安全性や信頼性が求められるシステムに必要な要素として語られる。ラフなコンセンサスでメール配信に失敗するのは構わないが、ミッションクリティカルなのに電車の信号機システムが故障したら、下手をすると大惨事になる。したがって、厳格な要求仕様書が必要になるのだが、これを複数のベンダーで共有しつつ開発した勘定系システムが万人にとって使いものにならないものとして「完成」しても許容されるのが日本だったりする。余談だが、筆者は過去に数多くのプログラマとの付き合いがあるが、「ああ、この人は優秀だなあ」と思う人は例外なく「先回り」が得意である。仕様書から勝手に逸脱して、近い将来に顧客が欲しがるであろう機能を勝手に実装してしまう人だ。高次元なラフコンセンサスがあると、たまにこういう僥倖に巡り会えるのだ。reserved.FacebookTwitter。