2020/01/21

天才を殺す凶器

愛の反対は憎しみではなく、無関心です。

エリー・ウィーゼル

『天才を殺す凡人』では天才は凡人に理解できないから排斥される、という内容が書いてあったが、個人的には天才の殺され方には2パターンあると思っている。

上記の殺され方は、まだ殺害件数が少ないほうだと思う。

「理解できない」ということを理解できているのは、天才に対してまだ認識を持てている段階だ。

「理解できない」ことを理解できていない、いわゆる無知の知がもう一つの殺害パターンだ。

これが天才を殺す一番の凶器として機能していると思っている。

天才に対する無知の知を現実で起こることで表現するとどうなるか？それは「無関心」だ。

「無関心」こそ真に天才を殺す凶器である。

理解できないことによる排斥とか嫌いという感情以前に、そもそも認知自体されないつらさがある。

人は自分の理解の及ばないものに対して、それを認識すること自体ができない。

理解できないものは意識すらされない。

よってその人の中では存在すらしない。

例えばFGOというゲーム自体は好きなり嫌いなりの何かしらの感情を持って人々から「関心」を持たれる。

しかし、中で動いているCRIWAREに対して関心をもつ人はほとんどおらず、普通に遊んでいるだけの人が意識することはほぼない。

実際に動いて存在していても、それにみんなが関心を向けてくれるわけじゃない。

役に立っているからといって、利用者全員から評価されるわけじゃない。

関係性が間接的になればなるほど「無関心」になっていく。

そして、その無関心がゆくゆくは自分の生活を支えていた人たちを迫害していく。

「関心」を持つこと自体が一つの才能なのだ。

ちなみに、意識が高いことと関心の広さは比例しない。

前回書いたとおり、人が意識を持てるのは自分の認識内だけであり、そこから外れたものはそもそも関心を持たない。

いくら意識が高くても無知の知にアプローチすることはできない。

FGOをいくらやり込んだとしても、CRIWAREについての知見は一ミリも得られないのと同じように。

クリエイターやアーティスト系の人は「無関心」という凶器に一番傷つけられている人たちだと思う。

人気のあるアーティストでもアンチの存在による精神ダメージ(排斥)よりも、自分の表現に対する共感性の欠如(無関心)のほうがダメージがでかい気がする。

表面的な名声はたくさん得られるだろうが、自分の感性が鋭い分、そのほとんどが的外れであることも理解できるので、自身が得られるのは「理解できていないことに対する理解」となる。

それは自分が共感して欲しいところに共感してもらえない状態で、いってみれば能動的な無関心を常に浴び続けている状態と言える。

そして多くのアーティストは酒や薬に溺れて自滅していく…

Tag: 本

2020/01/07

ドーナツホール

ドーナツの穴は穴じゃなくて実際は何もありません。

ドーナツという存在によって初めてドーナツの穴が生まれるのです。

ドーナツがなければそこには何もありません。

子供っぽい屁理屈で言えば空気があるだけです。

日本人の一般的なイメージとしてドーナツの穴はドーナツがドーナツとして認識されるための重要な要素です。

しかし、ドーナツをドーナツたらしめているドーナツの穴は、穴を穴だけ切り取ることができません。

ドーナツを食べればドーナツの穴も同時に無くなります。

このように、存在しないものが別の存在によって存在するようにみえることがあります。

「無知の知」も少し似たような構造をしています。

知識の大きさを円に例えて円の外側を無知の領域とします。

知識が増えて円が大きくなると、同時に円周の長さも増えます。

結果、無知の領域に対する接合点が増えて、知れば知るほど、自分がまだ知らないことに対する認知が増えていくという現象が起こります。

よく人が「完全に理解した」と言い出したと思ったら、次に「何も分からない」と言い出して、最後に「チョットデキル」と控えめに発言する現象が起こる原因がこれです。

ドーナツは真ん中が空洞ですが、無知の知の円だと外周円の外側がドーナツホールに該当します。

ドーナツでも知識でも、何かが無いことは何かがあることによって初めて可視化されたり概念としても認知できるようになります。

こういった現象は、人間社会のあらゆるところに潜んでいます。

潜んでいるどころか、ドーナツにおけるドーナツの穴の部分こそがあらゆる物事の本質だと思うのです。

東京は世界的に見ても大都市ですが、その大都市の中心にあるのはなんでしょうか？

実は東京の中心には何もないのです。

ビルも建っていなければ電車も通っていません。

東京もドーナツのような都市構造になっていて、山手線も首都高も環状線上に走っています。

それは何故でしょうか？

それは東京の中心は皇居だからです。

突き詰めていえば東京の中心は天皇陛下が存在するだけの土地です。

そして当の天皇陛下は別に何かを生産しているわけでもなければ統治しているわけでもなく、日本の象徴として存在しているだけです。

社会活動の熱量として評価すれば、そこは「無」になります。

しかし、日本の本質は何かと問われれば、天皇陛下の存在そのものとなり、すなわちそれが国体となっています。

まさにドーナツホールのような構造になっています。

ちょっと話が大きくなりすぎたので、目線を身近なところに向けます。

我々庶民の一人ひとりのパーソナリティーについてもドーナツホールの構造が成り立ちます。

以前に個性は幻想という文章を書きましたが、個人の人格もドーナツの穴と同じで実際には存在しないのです。

普段、実際に接している人々とのやりとりで、その人たちが自分に対して「この人はこういう人だ」という認識をそれぞれ持つようになります。

相手によって自分のどこかしらの部分が噛じられて、その時の味がその人の印象になります。

そして、部分部分を味わったそれぞれの人の印象で「この人はこういう人だ」というふわっとした人格が形成されます。

その人格がその人のコアとして存在するかのように扱われます。

しかし、当の本人は状況や相手によって食べられる部分を変え続けているだけで「ホントの自分はこれだ！」という中心部分は空洞なのです。

周りも自分もドーナツの存在によりドーナツホールを認識しているに過ぎないのです。

よく物事には本質があるように語られますが、実際のところ本質などないのです。

ペルソナを通して中の顔が存在すると思い込んでいるだけで、仮面がなくなれば全てなくなるのです。

「噓から出たまこと」と言いますが、そもそも嘘がないとまことは存在し得ないのです。

Tag: 哲学

2019/12/02

antiタスク分解論

世の社会人の方々はなぜ作業をタスク化するのでしょうか？

それは多人数による作業分担を可能にするためです。

そしてなによりも作業見積もりを出すためです。

何かを始めるとき、それがいつ終わるのか、目安が必要です。

作業分量がわからないと、どれだけのリソースをアサイン(大人語)すればいいか分かりません。

成果物の内容が大雑把になればなるほど完成までの時間を予測しにくくなります。

「面接予約システム」だけだといつ完成するか予測しづらいですが、「登録日時の降順でユーザー一覧を表示する」であればなんとなく実装時間を予測できます。

このように、作業単位が細ければ細かいほど作業にかかる時間の予測がしやすくなります。

自分が自宅から会社まで歩いてどれくらい時間がかかるのか？はパッとは分かりませんが、最寄り駅から次の駅までの距離であればなんとなく所要時間の目処が立ちます。

その距離と所要時間を足がかりにして、あとは会社までの各駅間の距離を調べれば、会社までのそれぞれの駅間の所要時間の目処も立つようになります。

自宅から会社まで5駅だとすると、まず「A駅〜B駅」「B駅〜C駅」「C駅〜D駅」「D駅〜E駅」の4つの工程に分けることができます。

その中で「A駅〜B駅」で所要時間の目処をつけて、残りの駅間の時間も算出していきます。

それらをすべて合計すれば全体のおおよそ時間を算出することができます。

全体の工程を細かく区切ることにより、見積もりの精度を上げて、さらにそれを合算することにより全体の見積もりも算出できるようになります。

これが社会人の方々がタスク化を行う理由です。

全体を分解すればするほど、自分たちの仕事がいつ終わるかの正確な目安を得ることができます。

ゴールの見えない道を進むより、辿り着くべきゴールが決まっている道を進む方が安心感があります。

社会活動においては予算やリソースも限られているわけですから、ある程度、これはどれくらいで完成するか？という目安がないと走り出せないわけです。

たしかアジャイルやスクラムもそのような課題設定のもとに生みだされた開発手法だったと思います。

作業単位をなるべく細かく短く区切って、そこから作業時間を算出していって、工程を進めるごとに作業精度を上げていって、徐々に完成までの見積もり精度を上げていきましょう。最初から全行程の正確な見積もりは無理ですよ。そもそも最初に作ろうとしたものと最終的に出来上がるものは別物になりますよ。──といった感じです。

タスク分解はとても便利でいいものですね。

みんながタスク化して仕事を進める理由が分かりましたね。

今日書きたいことはそれくらいです。

……いや違います。真逆のタイトルを付けていました。

タスク分解にもデメリットはあるのです。

今回はそのデメリットのお話です。

前置きがクソ長くなりました。

このブログ内では何回も書いている気がするのですが「言葉」は世にある全てを表しているわけではありません。

タスク化は言ってみれば「作業の言語化」でもあります。

ということは言語にならなかった情報はすべて作業タスクから抜け落ちてしまうのです。

少し雑な例えになりますが、αシステムを作るためにA機能とB機能とC機能にタスクを分解してそれぞれに担当者を付けたとしましょう。

αシステムの仕様には上記の3機能しかないものとします。

であれば、全然問題のないように思えます。

「A+B+C＝α」なんだから何も問題ないのでは？と思うことでしょう。

しかし実際の「システム」はそんなに単純なものではないのです。

たいていのシステムは「フレームワーク」と呼ばれる開発基盤上に機能を載せていく感じで作られます。

そのフレームワークを準備するのは誰なのか？初期設定はどうするのか？そもそも開発環境は誰が作るのか？

などなど、実際に仕事を始めようとすると結構な量の細々した、タスク化されていない作業が発生します。

作り始めたら作り始めたで、A機能とB機能と同じ処理が存在するので処理をモジュール化(共通化)したい、みたいなことも発生します。

そうなるとA機能担当者とB機能担当者との間でタスクに存在しないコミュニケーションコストがかかってしまいます。

また、A機能作成中にA`機能も必要なことが判明するかもしれません。

作り終わったら作り終わったで、それぞれの機能をまとめてαシステムとして統合する作業が発生します。

3つの機能が相互に連携していないと一つのシステムとは呼べません。

タスクの連携にまつわるコストの話はこちらをお読みください。

このように目に見える表面上の作業は各機能作成だけですが、実際の作業となると実に様々な「やらなければいけないこと」が発生します。

完成までにおける実際に必要なすべてのタスクを事前に全てタスク化するのは人類には不可能なレベルで難しいことです。

実務をやり始めて、初めて「やらなければいけないこと」が可視化されるのです。

実作業前のタスク分解化には限度があるのです。

それを踏まえた上で先ほど挙げたアジャイルやスクラムという開発手法が提案されたのです。

タスクに分解したとしても、それを合計したものが全体全てになると思ってはいけないのです。

人類には、実行する前の段階で実作業上で発生するすべての作業を正確に定義する、などということはできません。

さらにタスク化には「作業を効率化させる作業」や「品質を向上させる作業」が発生しにくいという欠点もあります。

先ほどの例だと「処理のモジュール化をしたい」となったとしても「そもそもタスクになってないし、やったら互いに余計な作業が発生するから、気づかなかったことにしよう」となる可能性が高くなります。

この例に限らず「こうすればもっと良くなる」と思ったとしても「でもそれはタスクとは関係ないし、やったら余計に時間かかるし、やった結果、後で問題になったらやだな」となってしまって結局やらなくなります。

リーダーなりマネージャーに提案すればいいじゃん、と思うかもしれませんが、大抵の人は自分に与えられたタスクでいっぱいいっぱいなのでこれ以上仕事は増やしたくないのです。

タスクの分解化は見積もりと作業分担化が可能になる多大なメリットがあります。

しかし、タスク化されなかった作業によるオーバーヘッドの発生や、作業全体や最終的なゴールに対して作業員の意識が向かなくなるデメリットも発生します。

1から100まで発生する作業すべてを完璧にタスクに落とし込めない限り、タスク化の恩恵だけを受け取ることができないのです。

しかし、ほぼ全てがオートメーション化している工場などは、タスク分割による恩恵を最大限受けていると言えます。

刺身の上にタンポポを乗せる人は作業全体や最終的なゴール、ましてや隣のラインの人が何をしているのかすら気にする必要はないのですから。

Tag: 仕事