思い出して辛くなることが多い
夜、寝る前。
シャワーを浴びているとき。
一人で片付けをしているとき。
最近あったこととか、昔のことをいつの間にか思い出してしまう。
楽しい思い出もあるけれど、思い出したくないようなこととかを思い出してしまう。
別に他の人にとっては気にしないようなことかもしれないけれど、自分にとっては気にしてしまっているようなこと。
不意に思い出してしまう。
他の人はどんな風に自分の過去と向き合っているのだろう。
今の自分は過去の自分で作られているように思う。
昔から、割りと悩みが多いほうだった。
それは昔から過去のことを振り替える癖があったからではないかとも思う。
自分に向き合おうとして自分の過去を見つめ直すのだ。
それで、得ることもある。
でも、負わなくていいような傷を負ってしまう。
これまでの生き方が基本的に自分に向き合うことで答えを探す生き方だった。
たぶん、これからもそうだろう。
でも、思い出して嫌な気持ちになって、叫んでしまったり、壁を殴ってしまったり。
どうしようもなく嫌な気持ちが突如沸いてくることがある。
あれは発作と呼んでもいいかもしれない。
そのときは抑えきれなくなって、壁を叩いたり叫んだりすることで現実に帰ってくることができる。
ああ、またやってしまった、と思うけれど。
もはや、それ自体にもなれてしまった。
人と交流する度に思い出して嫌なことは増えるし、嫌なことは消してしまいたくなる。
でも、消せないものもある。
だから、私は人と交流するのも怖いし、人前に出て記録に残るようなこと、写真をどこかにアップすることなんかも恐ろしかった。
消せないものを作ってしまうと消せない傷を作ってしまって、苦しむ種を作ってしまう。
だから、そもそも思い出して嫌になるものをはじめから作らないでおこうと、そんな風に思うようになった。
だから、年をとって、思い出したくない思い出を累積することが怖くて仕方なかった。
長く生きれば生きるほど、自分が思い出して辛くなることが増える。
生きただけ、傷が増えるようで。
でもそんな風に考えてると生きること自体に消極的になってしまう。
思い出さないようにすればいいんだけど。
世界の誰も思い出してないようなこと、勝手に自分だけ思い出して辛くなるのって馬鹿らしいじゃない？
でも、それをしようと思ってすぐできるわけじゃない。
過去の自分も受け入れられるようになりたい。
小説を書こうとしても結局おもしろい話を話せるかってのが鍵になってて
人よりも言葉での表現が多いタイプだし、何かを伝える時も、ああ、こういうのを伝えたいなってことを言葉にしようとすることが多い。
物語も結構好きだし、物語を書こうとすることがある。
小説というより脚本に近いのだけれど。
でも、書いてもあんまり面白くないし、話のオチが見えてこない。
話を書くときは、自分の解離人格というか、普段の自分とは切り離された自分で書いているけれど、あんまり面白くないのは自分のトーク力の違いなのか、やはり。
結局、物語を語るのも、以下にして面白いお話ができるかの延長のような気がしている。結局、普段からオチのある面白いお話をする人が上手い人のほうが、面白いお話ができるんだろうなと感じた。
少しショックである。
自分はわりと、そんなにオチのあるお話とかするのは上手ではなくて、わりと思っていることについてつらつらと話すのが好きな方なので、物語の語り部向きではないのかもしれない。
たしかに、自分が書いた創作の文章ってただのだらだらしたおしゃべりの域を出ない。
こういうところに自分の性格が反映されているんだなと感じた。
やっぱり人に話をする力ってのが必要になってくるんだなってことを感じた。
でもそれも一つの練習な気もするし。
練習すればできるようになるかな。
Linuxに詳しくなりたい FHSについて学ぶ
私は、それほどプログラミングをするわけではないけれど、何故かずっとパソコンを触っている。
何をしているのか自分でもよくわかっていないが、コンピューターの設定をいじったりするのが好きなのだと思う。
今使っているパソコンはUbuntu16.04だけれど、うまくプログラムを入れられなかったりとかすることもある。
また、サーバーPCの設定なんかで、CentOSとかの設定を見ていても、書いてあるとおりにやって見るだけで、全然原理がわかっていない。
インフラレベルのことが好きなのに、これでは全然ダメだなと思ってそもそものLinuxの原理、ソースなどを理解しようと思った。
とはいえ、いきなりソースを見ても何もわからない。
そこで、UbuntuのFHS（Filesystem hierarchy standard）について、勉強してみることにした。
結構わかりやすい。
わざわざここで転記して説明する必要もなさそう。
でもだからといって、これで開発ができるようになるわけではないし、インストールしたプログラムが、どこに何を格納しているかわかるわけでもないのだ…。
分野横断的な能力が求められるのはどうしてなのか
色んな所で、分野横断的な能力、学際的な能力、そういったものの重要性が強調されているように感じる。
それがいつからはじまったのかはわからないが、最近ますますその勢いは強くなっているように感じる。
なぜ、いま分野横断の必要性が指摘されているのだろうか。
私は、その経緯について考えてみることにした。
簡単に言えば、
「分業制、要素還元論的手法では解決することのできない課題を解決するために分野横断的な能力を必要としている」ということになると私は考えている。ここで、少しこのことに関して掘り下げてみたいように思う。
これまでの人類の発展の歴史を振り返ってみると、そこにヒントがあるかもしれない。
人類の経済の発展、技術の発展はいかにして行うことが出来たか。
分業が経済発展の基礎となったということは多くのところで指摘されている。私もそのように思う。分業によって、課題を細分化し、人間のリソースを細分化した領域に対して、掘り下げることで発展してきたところがあるように感じる。
それは、単純に上手くいっているように見えたし、今後もそれでうまくいくように感じていたのかもしれない。
この分業の過程は要素還元論的アプローチともいえるだろう。なにかを構成する要素を良くしていけば、全体としても良くなるだろうと考えてアプローチしてきた。
しかしながら、実際はそうではなかったかもしれない。たしかに、構成要素個別が良くなると、全体として多少は良くなるのかもしれないが、それに関して限界がやってきたのかもしれない。
結局、木を見て森を見ずになっていたのか。最終的に、ただ個別の部品をくっつけるだけで全体が機能するわけではなく、それぞれが、一体となって働くときにそれぞれの要素がそれぞれの要素に対して持つ関係が重要であるのではないかという風に思う。
かくして、大切なのは、あくまで構成要素単体ではなく、構成要素それぞれが組み合わさった全体像だということが明らかになって来たのではないかと思う。
しかしながら、これまでの学問的アプローチも技術的アプローチも、基本的には要素還元論的であった。
分業し、細かくすることで課題を解決してきたが、逆に言えばそれ以外の手法での課題解決にはあまり親しんでいないのではないかという風に思う。
だからこそ、今、分野横断的な能力が求められるのではないか。
これまでの分業制、要素還元論的アプローチでは解決することのできなかった全体がつながったときの問題を解決する人材が必要なのではないかと思う。
人の死を巡って
我々は生についてばかり考えてしまっているのではないかと思う。
生まれる瞬間があれば必ず死ぬ瞬間もあって、始まりと終わりは分けられない一対のものだと思う。
しかしながら、我々は如何にして生を送るか、どのように生を延長するかは考えるけれど、どのように死ぬかについては考えることを避けがちではないかと感じた。
とはいえ、死について考えなくてはいけない時代だと思う。
延命技術は格段に進歩している。DNARをどう扱うかというのは医療現場でも気にしているところだろう。
また、今後病床数が足りなくなって来ると言われる状況で、如何にして死に場所を用意すればよいのか。
死について考えることを先延ばしにしている間に、現実は死をどう扱うのか、その決断を迫りつつあるように感じる。
死について考えるにもいくつかの切り口があったほうが良いように思った。しかで以下の切り口を考えた。
死と心理…タナトスとデストルドー、リビドーとエロス、キュブラー＝ロス
死と芸術…メメント・モリ、ヴァニタス、カルペ・ディエム
死と法…安楽死法
死と医療…死亡診断、緩和医療
これを今後どう扱うか、それについては検討しなくてはいけない。
とりあえずまだ決まっているのはテーマだけ。
組織としての必要な構成要素
組織として、外の他の組織や人間との関係、組織内での人間関係について、必要な要素・昨日について考えた。
以下のネットワーク理論の記事の延長にある。
組織に必要な要素は、企業を参考にするのが良いと思う。
必要な機能
- 外との窓口（連絡をうける入り口としての窓口）
- 外への広報（外に向かって情報をアウトプットする発信）
- 組織内の連絡体制（組織内で必要事項を伝達したり、情報共有する体制がつくれている）
- 意思決定機能（何かをするときに、トップダウンであれ、合議制であれ、意思決定の仕組みがある）
「ネットワーク理論」の提唱と、人間組織、建築、コンピューターネットワーク
コンピューターのネットワークを参考に、コンピュータ、人間の組織、建築に適用可能な「ネットワーク理論」というのを考えた。
ベースは、デザインかコミュニケーション理論か、群論的な数学的なものになるのか、何になるのかわからない。
以下、理論のための用語解説
ノード…入力、出力、（何らかの処理の）機能を持った単位。
ネットワーク…複数のノードが入力と出力でつながったもの。ネットワーク自体が今度はノードとなり、より大きなネットワークを作ることもできる。
ノード間での入力と出力
ノード間での入力と出力される内容について、以下のように考える。
- コンピューター…情報
- 人間組織…情報
- 建築…人
入力と出力は、コンピューターで言うところのI/Oである。人では、人に話す・聞くである。建築では、特定のスペースに人が入る、出るである。
処理の機能については、人では、「考える、作る」などを想定している。建築では、「食事する、トイレする、買い物をする」といったような、そのスペースで人が行う行為を想定している。
ネットワーク理論は何のために役立つか
役に立つか立たないかと、日々学問が値踏みされる現状に置いて、どう役に立つかを考えることは、悲しいかな、重要である。私は、ネットワーク理論をコンピューターのネットワーク設計、組織設計、建築設計、をするときの、設計の良し悪しの評価の切り口として、また設計をするときの思想として有用であると考える。
ネットワークの良し悪しについての思想
ノードは、1つ以上の機能を持っている。ノードが複数の機能を持っている時、ノードには負荷がかかり、入力から出力までのパフォーマンスが低下する可能性が考えられる。そこで、ひとつのノードが持つ機能をほかのノードに分散することによって、ノードのパフォーマンスを向上させればよいのではないかと考えられる。
しかし、なんでもかんでも機能を分散させれば良いというのではない。ノード間の通信には、必ず「通信コスト」がかかるからである。超電導のように、ロスがなければいいが、現実はそうはいかない。
ということで、機能の分散によるメリット＞通信コストのときには、機能の分散をさせることは有用であるが、そうでない場合は、機能の分散は全体としてのパフォーマンスの低下を招く恐れがある。
また、ネットワークとしてのパフォーマンスの上昇のために必要なのは、各ノードの機能の向上か、あるいは通信コストの低下によって通信ロスを少なくすることである。
まず、機能の分散について。
人間の組織で例えれば、一人の人（ノード）が、情報収集、企画、営業、実行をすると、小回りがきいてスピード感が出るが、大規模なプロジェクトでは分業して行うことになる。それぞれのプロジェクトメンバーはお互いに情報交換し、ひとつの組織（ネットワーク）として機能する。
しかし、一人で出来てしまうような小さなプロジェクトに、何人も人を配置すると、お互いの情報交換がロスになり、「一人でやったほうがいい結果出る」というようなことになる。
建築で例えれば、トイレやキッチンを個人の部屋につけるか、共有化するか、といったような話で、それぞれの家庭では、一戸ごとにあったほうが融通が聞くが、オフィスやショッピングセンターでは、ひとつに集めたほうが、機能的にはいいものを実現できる。
次に、よいネットワークを作るための通信コストの低下について、人間の組織では、人と話すのにいちいち手続きを踏んで面会しないとダメなようでは、通信コストが高く、ネットワークとしてのパフォーマンスは低い。人同士の情報交換をもっとスムーズにできるように組織設計をする必要がある。
建築においても、それぞれのスペースの移動に非常に長い時間や階段による移動があると、建物全体のネットワークとしては良いとは言えない。エレベーターをつけたり、動く歩道をつけるなどして、通信コスト（人の移動コスト）を下げる必要がある。
機能分散のメリット
機能の分散をすると、何が良いか、ということに関しては、まず、分業によって専門化することで、それぞれの機能の水準が上がることが挙げられるだろう。
経済の発展の原則も分業であった。
発想の着想
コンピューターのネットワークインフラが好きで、分散コンピューティングについて考えていたり、Webサーバーのトラフィックについて考えていたりするうちに、抽象化すれば、人の組織や建築にも生かせないだろうか、さらに抽象化すれば数学的理論として確立できないだろうか、あるいはコミュニケーション理論などを礎として、ひとつの学問理論として確立できないだろうか、と思った。
