2017-12-31

2018年のアイヒマンとアーキテクチャ

2017年の流行語大賞には、「忖度」が選ばれた。組織や偉い人の意向にそうように、誰から言われるでもなく行動をしてしまうことだ。これは日本だけの現象ではなくて、同じ2017年のdictionary.comのキーワードには"complicit"が選ばれた。悪いと知りながら、その行為に消極的に加担してしまうことだ。

世界は少しずつ排外主義に向かっている。自分ではない何者かを自分のエリアから追い出さなければ、自分たちがとり殺されるという不安を抱えた人々が、その「構造」そのものではなく、目に見える仮想敵を取り除こうとしている。

この忖度の正体はなんだろうか。周囲を気にして、周囲の望むように振る舞うのはなぜなのか。山本七平は、このような目に見えない力のことを「空気」と呼んだ。彼のいう日本教の中では空気は最高権力者であり、目に見えない面妖な妖怪だと言った。第二次世界大戦に突き進み、そしてそこから撤退できなかったのも空気による支配がそれを許さなかったからだと論じた。

空気を読むこと。これは今の日本ではコミュニケーション能力のうちで必須の力だと思われている。つまり、周囲に合わせて、周囲の望むような自分であろうと合わせて行くことだ。

女性は、女性であろうとする。周囲が望むように女性であろうとする。
男性も男性であろうとする。周囲が望むように男性であろうとする。

「仕方ない」そう飲み込んだ言葉の中に、あなたを僕を取り殺そうとする何かがある。
僕が自分の人生の中で明確に「敵」であると言えるものはこの「空気」だけだった。

少し考えればわかる。「このままではダメなのかもしれない。」そのことに無自覚で、一歩前に踏み出すことができない人々。いつでも責められる誰かを探して、それで溜飲を下げている人々。そういうちょっとした弱さが、真実に向き合うことのできない弱さが、世界中の悪を作っているし、あなたのチーム、会社、地域の、日本の、世界の悪を生み出している。

かつて、ユダヤ人虐殺についての行政的な主導を行なっていたアイヒマンに対して、ハンナ・アーレントは「凡庸な悪」だと言った。システムの中に組み込まれ、ただ小役人として世界最大の虐殺を実行したにすぎない。誰もが、あの場面いたら、そして自分自身もがそれにあがらえなかったのかもしれないと喝破した。彼女は、アイヒマンを擁護しているように思われバッシングを受けた。ちがう。彼女だけがあの瞬間に本当の悪魔の存在に気がついたのだ。

悪魔は、僕たちの「認知」の中にある。アーレントは「全体主義の起源」の中でどのように全体主義が人々を蝕んで行くのかを述べた。まずは、国民国家によって枠を認識した。存在しない架空の物語で繋がる人々が規定された。アーリアン仮説と優生学だ。そのことで初めて不快だが寛容に認めている隣人であったユダヤ人を自分の枠の中にある異物と認識するようになった。断片的な情報を取捨選択し、あたかもユダヤ人が自分たちを脅かそうとしているのだと見せた。そして、敵を作り、物語をつくった。

f:id:hirokidaichi:20171231160715p:plain

僕たち人間は、事実を正しく認識できない。ゲシュタルト原則というものがある。人間は、近くにあり、類似したものをグループ化し、わずかな痕跡からそこに隠された図形を見出す。この２つ。全体主義の起源とゲシュタルト原則に非常に似たものを感じないだろうか。

誰かが自分と違うものだと思い、誰かを自分と同じものだと思う。
自分と違うものを排出して、自分と同じものを取り入れようとする。
ここに情報の非対称性が生まれ、その密度の差が見えない風をうむ。
高気圧から低気圧に空気が流れるように、情報の格差から風が生まれる。
これが空気と呼ばれるものの正体だ。そして、この境目に、不幸が生まれる。

違うと思う理由なんてなんでもいい。
生まれた地域、人種、宗教、職業、政治観、年齢格差、経済格差、そして性差。

悪魔は僕たちの認知の中にあって、あなたの仮想敵の中にいるのではない。
僕らが試されようとしているのは、2018年のアイヒマンにならないかどうかだ。

卑近なことでいい。あなたの職場に、あなたの仲間ではないと思っている仮想敵はいないか。あなたを不幸にする元凶だと思い込んでいる誰かはいないか。あなたの学校に、自分たちの仲間ではないと排斥して楽しんでいる人はいないか。あなたの地域に自分たちではないと思って、取り除こうとしている人々はいないか。あなたの国に。世界に。

本質的なコミュニケーション能力とは、「空気を読む」ことではない。
その空気の発生源になっている「情報の非対称性」を取り除くことだ。
認知の歪みを振り切り、あなたの仮想敵を深く知り、共感してみせることだ。
そしてあなたのことをあなたの仮想敵にこそ伝えて見せることだ。

ちょっと言いにくいこと。ちょっとだけのことだ。
自分が何を不愉快に思い、何を嬉しく思うのか。

しかし、この認知の歪みは、一方で人類に繁栄もまたもたらしている。
というのは、共感と連帯、そして社会、宗教の生みの親でもあるからだ。
サピエンス全史では、そのことが一貫したテーマとして語られている。

ゲシュタルト原則や僕らの認知能力の限界は、それ自体が大きなうねりとなって社会を作り上げている。デザインやアーキテクチャとは、この見えない力を積極的に作り出す行為だ。多くの場合、社会のために。あるいは自分たちの利益のために。

ミシェルフーコーはこのような見えない力の作用を生の権力とよんだし、
レッシグはアーキテクチャ型権力と言った。

それでも多少は僕は、アーキテクティングやデザインの力を信じていたし、それは「空気を作り出す」ものだと思っている。それは見えない空気の力を見るものだからだ。そして、不幸の連鎖に人があがらう唯一の手段だからだ。アフォーダンスも忖度も空気も優れたソフトウェア設計も組織設計も同じものに過ぎないとしても、一歩前に出ることからしか、進まない。

組織や社会がコミュニケーションの失敗に伴う偶発性・不確実性によって生まれていると指摘したのはニコラス・ルーマンだった。デザインもアーキテクチャも、不確実性を食って、成長する散逸構造だ。せめて、不確実性を前にして不安にとり殺されることなく、不確実性を食って自分のものにすることが必要だ。

東浩紀の観光客の哲学は、約めていえば観光客というコンティンジェンシーの増加（コミュニケーションの誤配）によって、排外主義とグローバリズムの悪しき側面を食い止める何かが生まれることを期待する話だった。これを郵便的マルチチュードと呼んだ。

この抵抗が無駄に終わるかもしれないし、何も残らないかもしれない。
一切の戦略も見えないし、どうしたらよいかわからないけど、
僕は2018年も自分自身に恥ずかしくないように、アイヒマンにならないように、
前に一歩でることを恐れない人間でありたいと思う。

2016-01-26

プロダクトからサービスへ。

IoTと呼ばれているものの本当の姿は、「製品のサービス化」にあるという話した。
今まで、製品と呼ばれていたものがサービスに変わるという変化はそこかしこで既に起きていて、それが家電製品なりその他のガジェットと呼ばれるものに進出したにすぎないのだーという話だ。

ここでいう製品とは売り切りのものである。
定価で売って、その後のリベニューはない。

なので製品サイクルを激しくしなくては、利益が増大しない。
その結果一製品あたりにかけられるコストは縮小され、ニーズは細分化される。ラインは複雑になり、付加価値は買ってから増大することがないので、ずっと償却されていくことになる。
ここでいうサービスとは、継続的な価値提供がなされるもので、
継続的にリベニューにつながる。継続的に提供されるそれは、関連製品・サービスの互換性のため、M2M・S2Sのインタフェースを持つように変化しやすい。
継続的なリベニューにつながるため継続的なバージョンアップが可能になる。そのため一製品よりもUXに対して投資をしやすい。

たとえば、ゲームのオンラインゲーム化なんかは分かりやすい例で、2000年代初頭にはすでにサービス化が進行している。現在のスマホゲー、ソーシャルゲームと呼ばれているものもその一部だ。「シェアリングエコノミー」と呼ばれているものも、一部のものは製品のサービス化だ。「カーシェア」とかまさにこの形態で、製品の償却費にサービス費用（つまりエクスペリエンス）を上乗せして売っているわけだ。IoTという表現は表層で、その一部なのでそこを間違えるとビジネスモデルそのものが崩れてしまいがちだ。

私見ではITのビジネスは、

「情報のインデクシングとデリバリ」
「仲介の自動化」
「製品・業務のサービス化」

という３つの組み合わせでビジネスモデルが成立し、
そこにどういう分野でやるかというマーケット設定があって
はじめて継続可能な何かになると思っている。

そうすると「安く」て「有益」になるからだ。

2016-01-26

タイムマシンはすでに開発されている。

タイムマシンはすでに開発されていると言ったら、驚く人は多いのではないだろうか。
いや、オカルトや陰謀論の話をしようとしているわけではないので、ちょっと聞いて欲しい。

ある調査によるとタイムマシンを使ってやりたいことは、未来に行って投資や投機で大儲けしたいということらしい。
とても即物的で面白い考え方だ。おそらくバックトゥーザフューチャーの影響があるんだろう。

現実的に考えて、タイムマシンがSF作品のまま開発されていたら大変なことになる。
過去は人々の好きなように改変されてしまうし、未来にいって他の人の著作や発明、権利を盗んでしまうのは重大な人権侵害だ。

それを防ぎつつ、タイムマシンの利用を厳格化していくとどうなるだろう。
きっと、他人の権利を奪うような利用は禁止され、利用には相応のコストがかかり、過去の改変を許さないような運用になるだろう。

そんななかでの使い道は、たとえば今は学生なので収入がない。親からの学費負担も期待できないといった人々に「未来の自分に学費を払ってもらう」ことなどではないだろうか。

未来の自分は働いているのだから、（しかも、学費を負担してもらって大卒であるので）ほどほどに金銭的余裕がある。
だから、未来の自分に学費を負担してもらおうという理屈だ。

このような使い方であれば、他の人の権利を侵害せずにタイムマシンを利用できる。社会的に適応したタイムマシンのあり方だ。

こんな使い道はどうだろう？
とても面白いビジネスのアイデアを思いついた。今はお金がないのでできないが、
これを実現できればきっと未来の自分は莫大な利益を得ているはずだ。
その未来の自分にこのビジネスアイデアの初期投資をしてもらおう。

ちょっとした不良品のタイムマシンであればパラドックスを引き起こしかねないが、これも認められるだろう。
誰の権利も侵害することがないし、儲かっているはずの自分からしてみればほんのわずかなお金だ。

ここまで書いて、ご理解いただけたと思う。
僕の言うところのタイムマシンとは「銀行」のことだ。

「銀行」というタイムマシンは、そのビジネスアイデアを精査して、イメージのなかで未来に行ってみてくる。
タイムパラドックスが引き起こされてしまう可能性も十分にあるが、その時のためにタイムマシンの利用料を頂いておく。

タイムマシンが生まれたら、世界はとんでもないことになるのではないかと想像するのは楽しい。
だが実のところ、この手の銀行はすでにタイムマシンそのものだった。

この銀行のタイムマシン機能のことを「信用創造」と呼ぶ。
その結果、人類の富の総量は指数的に膨れ上がることになる。

タイムマシン後の世界に僕らは生きているのだ。

2012-05-11

perlでcoffeescriptの分割代入

cpanizeはしてないけど、とりあえずgithubにはあげた。
https://github.com/hirokidaichi/p5-Data-Destructuring-Assignment

分割代入ってなにかというと"分割"して "代入"できるという機能です。

詳しくは
http://coffeescript.org/#destructuring
ここを参照

destruct([\my $hoge,\my $fuga]) = [10,20];
print "hoge is $hoge";# hoge is 10
print "fuga is $fuga";# fuga is 20

こんな風に左辺に構造をもって、右辺の構造とマッチングして、代入することができます。

destruct( \my $hoge ) = 10;

変数はリファレンスで渡してください。

destruct( [\ $a ,\ $b] ) = [$b,$a];

swapもこんなに簡単。

destruct( { hash => \my $hash } ) = { hash => [1,2,3]};

hashrefもできます。

my @array =  map{ +{ hoge => "$_",fuga => $_ * 2}} (1..10);

while(destruct({ hoge => \my $hoge } ) = shift @array) {
    # $hoge..;
}

while句の中で。

my @array =  map{ +{ hoge => "$_",fuga => $_ * 2}} (1..10);
for my $elem (@array){
    destruct({ hoge => \my $hoge, fuga => \my $fuga}) = $elem;
}

for文とともに

my $template = { hoge => 1,fuga => 2};
if( destruct({ hoge => \my $hoge ,piyo => \my $fuga }) = $template ){
    ::pass 'matched any';
}else {
    # not come here
}

if文の中ではこう。一個でもmatchするとtrueです。

2012-05-10

coffeescript/ harmonyのdestrucutring assignmentをperlでやる。

なんか気になったのでPoCで作ってみた。

package Data::DestructuringAssingment;
use strict;
use warnings;
use Exporter qw/import/;
use List::MoreUtils qw/all/;
use base qw/Tie::Scalar/;
our @EXOPORT_OK = qw/destruct/;

sub destruct : lvalue {
    my ($data) = @_;
    tie $data , __PACKAGE__,$data;
    $data;
}

sub TIESCALAR {
    my ( $class,$scalar ) = @_;
    $class->new($scalar);
}

sub FETCH {
    my ( $self ) = @_;
    die('Disallow Fetch');
}

sub STORE {
    my ( $self,$value ) = @_;
    $self->assign($value);
}
sub new {
    my ( $class,$data ) = @_;
    return bless { data =>$data },$class;
}

sub assign {
    my ( $self,$target ) = @_;
    return __assign($self->{data},$target );
}

sub __is_hash_ref{
    return __is_ref_of('HASH',@_);
}
sub __is_scalar_ref {
    return __is_ref_of('SCALAR',@_);
}
sub __is_array_ref{
    return __is_ref_of('ARRAY',@_);
}

sub __is_ref_of {
    my $ref = shift;
    all { ref $_ and ref $_ eq $ref } @_;
}
sub __assign {
    my ( $data,$target ) = @_;
    return __assign_scalar($data,$target) if __is_scalar_ref($data);
    return __assign_hash( $data,$target ) if __is_hash_ref($data,$target);
    return __assign_array($data,$target ) if __is_array_ref($data,$target);
}

sub __assign_scalar {
    my ( $ref,$data ) = @_;
    $$ref = $data;
}

sub __assign_hash {
    my ( $data,$target ) = @_;
    for my $key ( keys %$data ) {
        next unless exists $target->{$key};
        my $element = $data->{$key};
        __assign( $element,$target->{$key});
    }
}

sub __assign_array{
    my ( $data,$target ) = @_;
    for my $index (0..(scalar @$data) -1) {
        next unless exists $target->[$index];
        my $element = $data->[$index];
        __assign( $element,$target->[$index]);
    }
}

1;

destruct( [ \my $value, \my $next, { hoge => { fuga => [ \my $last ] } } ] )
    = [ 10, 11, { hoge => { fuga => [20] } } ];

print "value is $value \n";
print "next is $next \n";
print "last is $last\n";

2012-01-04

素敵なアイデア

アイデアの伝達について、2011年は思案した年だった。
2012年になったので、考えていたことをまとめてみるよ。

俺の定義では、アイデアってのは、複数の見えている問題と複数の見えていなかった問題が
すぐれたシンプルな方法で解決するものだ。

で、俺ってばアイデアマンなので、何か素敵なアイデアを発明するってのが
今までの自分のスタンスだった。

でも、まあアイデアを広めていく中で、ボトムアップ的なあるいはゲリラ的なやり方に限界を感じていたのも確かだ。
そこでまぁ、「アイデアを伝える」っていうことが2011年のキーワードとして出てくることになった。

アイデアを伝えるためには、まずなんでそれをやるのか？というのが大事になっていくんだけど、
これの難しさっていうのが、なかなか理解されない。いや、簡単に言うんだよね。なんか説明とかすればいいじゃないみたいに。
いやいや、これはそんなに単純なもんじゃない。（これもまた理解はされないんだよね）

既存の事柄を誰にでもわかるように説明するなんてのは、簡単で、むしろ俺にとって得意分野。
そもそも、対象の精神に落ちていない概念を構築するなんていう荒唐無稽なチャレンジに比べたら、圧倒的に簡単なので
アイデアの伝達もまた簡単なものだと思っちゃうんだろうね。

アイデアの伝達は「なんでそれをやるのか」っていうことの伝達が一番大事だ。
「なんでそれをやるのか」はつまりは「問題の認識」で、「問題の認識ができる」というのはほとんど解決の方法がわかるというようなことだ。
それならそもそも伝達するまでもないんだ。俺はそれをやります。で済むからね。

問題の認識ってのが簡単だったら、それは簡単に解決しているはずのことなんだ。
誰だって正しく認識された問題を解決する程度の能力はあるはずだからね。

アイデアってのはそんなもんじゃない。それは体感によって初めて理解されて、説明によって理解されないものなんだ。

説明によって理解されるものは、もうすでに体感しているようなものであって、
多くの人にとって体感してしまっているようなものはアイデアとしての力を持ってない。

アイデアは、説明できないのだから、うまく実施するには自分で行動するしかない。

実施されたアイデアは徐々にミームとなって人々の行動様式を変化させて、
根付いていき、共通概念化されて理解されていく。

こういうフェーズを経た頃には当たり前になって消えていく。
０という概念が無い頃をもう思い出せないようなもんだ。

こんな流れをアイデアの普遍化と呼んだりしようか。

よくあるのは、問題の表層化を境にアイデアが理解され始めるというようなことだ。
表に出てこないときは、いくら言葉を尽くしてもダメ。こういうことが起こりえますよとか言っても、なしのつぶてだ。
いまだったら、原発の件で騒ぎ立てたんだからよくわかるだろう。失敗が表面化すると最初から理解していた振りをする連中がいるってことを。
一度表層に現れたら、簡単に普遍化を起こす。でもまぁ、表層に出てくるのを待ってたら、それって負け戦だからね。

そういう意味では、
理解されるってのがそもそも負け戦なんだ。
多くの人に理解される問題解決ってのは、もう問題が露出してしまっていて、その上に乗っかったものなんだ。

理解されていないこと、だけど体感できているってことが大事で、その体感は当たり前になって消えていく。
これがアイデアの正しい流れなんだ。

そういうことが「体感」できたことで
ようやく「わかった」。

「アイデアを伝達する」ってのは、そもそもナンセンスなんだ。
アイデアってのは、ゆっくりと普遍化するのが常であって、伝達なんかできないんだ。

だから、
アイデアを伝達して実施するなんていうのはナンセンス。
本当にやりたかったのはアイデアの総量の増加なんだから、次のようにすることにした：

自分でアイデアにたどり着ける人に問題認識の種を与えて、たどり着いてもらう。（問題解決の委譲）
自分でたどり着けない人には、具体的な指示を積み重ねて、自分だけの問題エリアを見つけてもらう（領域の限定）
本当にぶっ飛んだアイデアは自分でやってしまう！（自己解決）

この３パターンだけだ。

そんで、生み出されたアイデアが普遍化するまでは、簡単な理由だけつけて
「こうでなくちゃダメだ」と言い続ける。あるいはそのサポートをすることだ。

みんなに理解できるものなら、アイデアでもなんでもないんだから。

2011-12-27

知性に対する確信

最近は、知性に対する確信のようなものが大事だとおもってる。
その問題を跡形も無く消し去ってしまうアイデアというのは、深い洞察と探究心だけがGiftしてくれるものだ。
クールなソリューションに出会えないエンジニアは頭が悪いんじゃなく、その手前で立ち止まって、知性に対する確信を放棄しちゃうからだと思うんだ。

すごいアウトプットが出せないときって、単純にインプットと思考と洞察が足りないんだよ。
かけてる時間がすごいとか、朝から晩までやってるとかそういうことじゃない。

アウトプットが足りないときに、じゃあインプットと思考を巡らそうと考えて、行動に移せる人は思いのほか少ないのは、やっぱり焦ってしまうんだろうと思うんだ。
その焦りの源について考えてみると、それは「知性に対する確信が足りない」ってことなんじゃないかと思ってしまう。
十分なインプットと問題認識にこそ時間をかけてやれば、きっといいアウトプットが出てくる。この信仰まがいの哲学が「知性に対する確信」だ。
この信念が弱いと焦ってしまう。誰も皆アウトプットを出したいからね。それで、アウトプットに生真面目に取り組んで結果として悪いソリューションを出してしまうんだ。

よく設計が場当たり的な理由を「時間がない」んだと説明されるんだけど、そうなんだろうか。
記述する時間なんて、全体の時間からすれば誤差。考える時間は、それこそいくらでもあるんじゃないか。

要するにそれは、迷路の中で絶対にたどり着けるって確信がないと引き返してしまうのと同じなんだろう。
だからトーチが照らす一寸先を闇雲に歩いてまわる。結果として、怖くなって引き返してしまうか同じところをぐるぐると回る。

まずは、本当はこうなってなきゃいけないんだよなーと考える。
本当に？と問う。こう書きたいんだ。こう働きたいんだ。こうなってるといいんだ。
をまずはっきりさせる。そこから実装が始まる。

末端の細かい実装なんてのは、最後の最後にすればいい。でもこれも怖がって、なんとなく動くコード書いて満足しちゃう。

テスト駆動開発とかビヘイビア駆動開発とかのミソって、こうあるべきを最初に書いてしまうことで、
アウトプットへの焦りと戦って、自分がたどり着きたいところを明示的にしてしまうことなんだよ。

じゃあ、それができないときに、どうやったらできるように変わってくるか考えてみる。
頭の良さとかそういうことじゃなくて、アイデアがすべてをがらっと変えてしまうという確信をどうやったら培えるんだろう。

最初に書いたコードを捨ててしまう勇気と自分自身の力で問題を再定義する成功体験かな、やっぱり。