個人事業主活動の近況と言語化支援の断念について

前回からの続き

lacolaco.hatenablog.com

近況

おかげさまでAngularやWebフロントエンド開発についてのアドバイザリーをさせていただいてる会社もじわじわ増えつつあり、副業用に空けている可処分時間が減ってきました。 そのため現在は新規の受付を停止しています。最新の状態は https://lacolaco.biz/ に掲載しています。

言語化支援の断念

前回の記事で言語化支援をはじめようとしている話を書きましたが、ありがたいことに実験台になってくれた方のおかげで大きな収穫が得られました。 結論から書くと、言語化支援だけをスポットで引き受けるのは簡単ではないし、やりたい事とも違っていそうでした。よって、一旦個人事業主のラインナップからは取り下げることにしました。

抽象的な脳内のイメージや思考を対話を通じて言語化していくプロセスには、当然そもそもの対話の場のコンディションが重要です。ありていにいえば心理的安全性のある関係性が必要条件であり、またその題材・テーマについてある程度の基礎知識・理解を互いに備えていることも重要でした。つまり、初めて話す人と初めての話題でいきなり成果が出せるほど言語化支援というのは単純ではないし、仮に話が盛り上がったように思えて何かしらのアウトプットが出たように見えても、それは両者にとって納得の行くクオリティにならないだろう、というのがわかってきました。

裏を返せば、そういった信頼関係を構築しつつコンテキストについても理解を深めた上であれば、他者から視点と認識を提供しながら思考を組み上げていく言語化支援という価値は十分に可能であろうという見立ても得ることができました。 したがって当面は、技術アドバイザリーのような継続的な関係性の中で、そうした需要があれば1on1やワークショップなどを通じての言語化支援を引き受けていこうと考えています。

あらためて、実験に協力してくださった方々、ありがとうございました！

それではまた、暖かくなった頃に

知識の引力

知識には質量がある。そして万有引力をそなえている。

一箇所に集まった知識がある重さまで達すると、万有引力によって自然に周囲の知識を引き寄せるようになる。 T型の人材というのは、実は重力による歪んだ空間の形をしている。

国立科学博物館-宇宙の質問箱-宇宙論編より

ある特定の事物についての知識や技術を深めようとすると、おのずと周辺にある事物からの関連知識も増える。つまり、積極的に周辺領域へ知識を広げなくとも、重力が強ければ周りのほうから"落ちて"くるようになる。

したがって、T型を目指そうという者がまず形成すべきものは空間を歪ませるほどに重い知識の核である。そこがなければ、知識同士の引力に期待できないため苦労する。

このような学びの広げ方は、流れに任せた無軌道なものという見方もできる。また、知識が大きく偏ったものになる可能性もある。 そうだとしても新たな方向性として重心となる核を、意識的に新しく作り出すことはできる。複数の核がある程度重くなればそれらもまた引き寄せ合い、融合すれば一つの大きな知識体系となる。

Angularの本を書き始めました (Angular Advent Calendar 2021)

Angular Advent Calendar 2021の23日目です。

最近書き始めた薄い本の最初のページを無料公開したので、アドベントカレンダーの投稿ということで納めさせていただこうと思います。

zenn.dev

最初はAngularの中核にあるViewという概念について、本質的な理解につながるよう解説しました。 『Angularの基本語彙』は決して入門本ではないですし、Angularアプリケーション開発の実務に役立つものでもありません。Angularがどのように機能しているのか、そのメカニズムを理解しようとする人にとっての足がかりになるようなものに育てていければと思っています。 興味があればぜひ読んでみてください。

余談ですが、来年もAngular日本ユーザー会のオンラインイベントng-japan OnAirもよろしくおねがいします！

onair.ngjapan.org

SHIROBAKO 第23話は何度観ても同じところで泣いてしまう

SHIROBAKO Advent Calendar 2021 - Adventarの13日目です。

僕はアニメや映画で何度見返しても同じ場面で泣いちゃう爆弾をいくつも涙腺に抱えているんですが、SHIROBAKOの第23話はそのうちのひとつです。

今日書きたいのは、このシーンがいかに感動的なものなのかという評論ではなくて、なぜ僕は毎回このシーンで泣いてしまうんだろうという内省です。

結論から言うと、僕はこのシーンにおいて「おそらく彼女らの人生において一回しかないであろう、これまでの時間とロマンとが一体となった『成就』の実感、その儚くも偉大な瞬間に立ち会えたことの喜びと哀しさ」を感動として実感しているのだと思っています。

これまでの時間とロマンとが一体となった『成就』の実感

哲学のゼミで『感動』とは何かということについて考える本質観取に参加したことがあります。 そのときに『感動』には「奇跡型」と「軌跡型」があるのではないかという提起がされたのが印象に残っています。

奇跡型の『感動』というのは、自分の予想を裏切ったり越えたりしてくるような、超越的・圧倒的な事象との出会いに感じるものです。 一方、軌跡型の『感動』というのは、積み上げてきた時間や経験、つまり自分自身が、手が届かないと思っていた「ほんとう」と接続し、一体となった感覚から覚えるものです。 ロマンとの一体感、「つながった」実感。これまでの時間はこれと出会うためにあったんだと思うような昇華の感覚。そういう種類の感動もあると思います。

宮森はずかちゃんのこれまでの軌跡を知っている身として、ずかちゃんにとっての夢、ロマン、「ほんとう」の小さくも確かな成就を自分ごとのように実感し、共涙を流したんだろうと思いますが、この瞬間にロマンとつながったのはずかちゃんだけではなく、宮森自身もそうだと思います。宮森にとって自分ではどうしようもない手の届かないところにあった「アニメ同好会のみんなでアニメを作る」という夢（ロマン）が、突然目の前に現実のものとして到来したわけで、宮森自身にとってもロマン、「ほんとう」と出会った瞬間であるわけです。 そんな世界が変わるような瞬間は彼女らの人生において何度も起こることではなく、もう二度と訪れないかもしれない偉大なものです。そして今感じているこの実感も時間がたって思い出になっていく。そんな儚さと切なさ、『最期』の感覚が、その瞬間をたまらなく尊く、愛おしいものにします。

そうして、僕は喜びと同時に哀しさも同居した感動を、このシーンから呼び起こされてしまうわけです。 アニメの素晴らしいところは、彼ら彼女らにとっては一度きりのその瞬間を、僕は何度も体験できるところです。何周しても毎回同じ場所で感動してボロボロ泣いてしまいます。もう完全にわかっているのに感動してしまうのは、やはり感動に「奇跡型」と「軌跡型」の類型があることを実感させてくれます。

これ何の話？

これ何の話だったんでしょうね。 SHIROBAKOアドベントカレンダーは折返したばかりですので、14日目の記事をお楽しみに！

役割を定義すること・補集合の担い手について

先日 Front-End Lounge #2の基調講演として喋らせてもらった中で触れた基本的な原理について、汎用性が高く単体で参照したくなることが予想されるのでこの記事で簡潔にまとめることとする。

『フロントエンドエンジニアの価値はどこから生まれるのか』の発表資料です。https://t.co/hnwq1rMnPc#FELounge

— lacolaco / Suguru Inatomi (@laco2net) 2021年12月6日

（この基調講演の内容についてはまた別途ブログ記事の形で再編する予定である）

曖昧な空間の中に明確な範囲を定めても全体の曖昧さは減じない

頭の中にベン図を思い浮かべてほしい。 よくあるベン図では外側に全体集合があり内側に部分集合が描かれるが、普通のベン図と違うのは全体集合の輪郭が曖昧であることだ。つまり無限に広がる空間である。

部分集合の境界をどのように定めたとしても、それが部分である限り、補集合の輪郭は常に曖昧でありつづける。 当たり前ではあるが、この原理は集団における役割についても同様に考えることができる。

ある集団において発生する責任範囲が曖昧である（無限である）とき、その責任を果たそうとするならば、責任範囲を明確に定めない補集合的な存在が必要条件になる。

責任範囲が有限であるならばその範囲内でMECEになるよう分担すればよい。しかし、無限の責任範囲の中で明確な役割を定義することは補集合の総量をいくらか減らすことには貢献しつつも、補集合のすべてを無くすことはできない。

この原理を踏まえると、例えばCTOなどの役割において典型的に見られる「会社や組織によって責任範囲が違う」ということも、その本質が組織における補集合の技術的範囲をカバーする役割であるからと考えれば当然のことである。CTO以外の役割がどのように定義されているのかが組織によって違うのだから、補集合の形状も当然違うのである。仮にCTOが明確に責任範囲を定めるとすれば、それによって生まれる補集合はまた別の誰かが担うか、あるいは誰からも拾われず責任を果たせないことになる。

このような現象はCXOなど組織の上位だけで起きることではなく、どんな集団でも発生しうる。その一例が基調講演で触れたフロントエンドとバックエンドの分業の例である。 ところで、勘違いされないように念の為明言しておくと、バックエンドにはバックエンドの曖昧さが当然ある。アプリケーションの開発という曖昧な責任範囲の中である程度境界づけられているが、フロントエンドとバックエンドは互いに曖昧さを抱えており、その種類が分離されていると見るのが妥当である。この話の要諦は、分業単位が互いに責任範囲を明確に限定したときにはその外側に補集合が生まれるということである。したがって少なくともどちらか一方は曖昧な責任範囲である必要がある。そして現実には多くの場合双方がある程度曖昧である。

以上述べたように、集団の中で役割を定義しようという際には、まずその集団の責任範囲が有限であるか無限であるかを前提とし、有限であるならば隙間が生まれないように分割できるが、無限であるならば明確な役割定義によって生まれる補集合を誰が担うのかを先んじて定めることが必要であるだろう。