アリストテレス vs ホッブズ
misskeyにブログ埋め込み機能が実装されたので、そのテスト。
リヴァイアサンとニコマコス倫理学を読んでた時の引用をクリップしてたのでここに貼り付けておく。
オレオレコンテキストおじさん
「言語化をサボる人」というまとめ記事を読んでいて、その表現だとまだ正確に言語化できていないのでは？と思ったので、そのことについて書き殴っていきます。
まず最初に、前提として「言語化」はみんなが思っているよりも難易度が高い行為です。
普段の我々のやりとりは言語化ではなく、頭の中にある語彙をいい感じに組み合わせていい感じに発声しているだけのパズル＆リズムゲーに過ぎません。
パズル＆リズムゲーがうまくプレイできれば相手との良好なセッションが奏でられます。
似たようなことを以前にも書きましたが、コミュニケーションと抽象的な概念を言語化することは別なのです。
当ブログでは本一冊分以上の文章が書き溜めてあります。
それだけ文章を書いてきた自分でさえ、多分、皆さんよりも言語化や文章を書く行為は難しいという認識を持っています。
どこまで分かりやすく文章を書いたとしても、頭の中の思考を十全に表現できた、と思えることはありませんし、読んだ人全員に伝わるとも思っていません。
それはなぜかというと、自分は言語化にあたってちゃんと主語やコンテキストを認識しているからです。
主語やコンテキストを含めて、しっかり相手に伝わるように言語化しようと思ったら、その分、より面倒になるし、全ての人間の脳内コンテキストに合わせて文章を書くのは不可能だからです。
例えば、「マック」だけだとマクドナルドなのかマッキントッシュのことなのか分かりません。
マックを正確に伝えるためにはコンテキスト(言葉の背景)を明確にしなければなりません。
さらにマクドナルドはともかくマッキントッシュを知らない人はそれ相応にいると思われますから、そこを考慮するとより詳細に説明する必要がでてきます。
この辺の話は等しいのスコープとふわふわ時間をお読みください。
そういった意味で言語化は難しいし面倒くさいのです。
さて、冒頭の記事によると言語化をサボる人は、主語を抜き、理由を省き、具体例を考えない人らしいです。
お金をもらいながら仕事をしているのに「そんな奴おれへんやろ〜」と思いますが、これが実際に仕事をしているとそれなりに存在します。
しかも、自分の経験則で話すのなら、偉い立場の人ほどその傾向が強い気がします。
「んなアホな」と思うかもしれませんが、そうなのです。
そして、そうした人たちは自分が言語化をサボっている人間などとは露ほども思っていないのです。
それはなぜかというと、偉い人は偉いので、仕事上、たくさんの人とたくさんのお話をしているからです。
これだけ普段言語を操りながら人とやりとりしていて仕事を推し進めているのですから、そんな人が自分のことを「言語化をサボる」人間である、との認識など持たないでしょう。
で、いざその人と会話をすると、主語があやふやで話の文脈を全然考慮せず、その場の思いつきでそれっぽいことをそれっぽく喋ってきます。
挙げ句の果てには相手が言ったことを後日、その相手に報告すると「それはどういう事ですか？」と質問され、頭がポルナレフ状態になります。
偉い人は偉いので、きっといろんな案件を抱えていて、いろんなコンテキストをスイッチングしまくりながら忙しなく仕事をこなしているのでしょう。
だから、一つ一つの案件(コンテキスト)を詳細には把握しきれないのでしょう。(自分は偉くなったことはないので知らんけど)
このように偉い人は偉いので、言語化をサボっているわけではないのです。
言語化はするが、そのためのコンテキストの認識が必要十分量に足りていないだけなのです。
複数のコンテキストを抱えながらそれを頻繁にスイッチングするのが日常なのですから、スイッチング自体にコストを割いてられないのです。
もしくはスイッチングコストに対するの認識がないか、です。
しかし、偉い人は偉いので部下に対して色々指示をしないといけないし、部下からの報告も色々聞かないといけません。
コンテキストの認識が薄い状態で言語化を試みようとするので、主語を抜き、理由を省き、具体例が出せない状態になるのです。
ですので、もう一度言いますが、言語化をサボっているのではなくコンテキストの認識が欠如しているだけなのです。
さらに、偉い人は偉いですから、叱られる機会もあまりありません。
ですので、偉い人の自己改善に期待するのは望み薄です。
偉いが故に、そういったある種の井の中の蛙状態に陥り、えてして大手からベンチャーに転職した人はローパフォーマーになりがちです。
そして、コンテキストの認識の欠如を自覚することは、作業そのもの(コンテンツ)を把握するよりも難易度の高い行為です。
「AをBにする」だったら、それをその通りにすればいいだけですが、「AをBにする背景(経緯)」となると、個人個人で微妙に認識がずれてきます。
大概の仕事において大事なのは作業そのものよりも「その作業により何が解決されるか？」の方です。
Yを実現するために「AをBにする」タスクが発生したものの、実際は「CをDにする」方が正しい、みたいなことはよくあります。
「Yを実現する」がコンテキストで、「AをBにする」はそれを解決するために考えた手段でしかありません。
そして 「Yを実現する」コンテキストがあやふやだと、個人個人で「EをFにした方がいい」とか「GをHにした方がいい」といった作業認識もバラバラになってきます。
そういった人たちでミーティングを行うと「会議は踊る、されど進まず」となるのです。
オレオレコンテキストおじさんたちが好き放題話し合っても、各々のオレオレコンテキストの差分がコンフリクトを起こし、いつまで経ってもマージ不能状態が解消されません。
仕事を進める前に、まずはみんなの中のイマジナリーコンテキストを集約して、明確に文章化した「ワンピース(ひとつなぎの大コンテキスト)」を定義すべきなのです。
プログラマーがコンパイルしているのはコードじゃなく人間
昨今、プログラミング教育が盛んに行われています。
義務教育にプログラミングが導入されたり、システム(ソフトウェア)エンジニアになるためのプログラミングスクールが乱立しています。
私自身はプログラミング教育には懐疑的な立場(というか、教育という概念自体が懐疑的)なんですが、その理屈を言語化できたので(というかタイトルが全てですが)、今回はその内容を綴っていきます。
学校やスクールで具体的にどのような教育を施しているのかは知りませんが、その目的は被教育者がプログラムを書けるようになることだと思います。
いや、義務教育においては論理的思考能力を養う云々だったような気がしますが、まぁ論理的思考能力とプログラミングは数学的には同じようなものなので、あまり気にしないことにします。
プログラムを扱えるようになったらどうなるのかというと、プログラマーになれます。
人や文脈によってはコーダーやらエンジニアやら色々呼び名はありますが、プログラムを取り扱うという意味でここではプログラマーと表現します。
プログラムができるようになってフリーランスのエンジニアとやらになれば年収一千万も夢じゃないらしいです。
私もそれぐらい欲しいですね。
それはさておき、部外者がプログラマーと聞いて思い浮かべる仕事内容はずばり、プログラムを書くことだと思います。
実際にプログラマーはプログラムを書きます。
それは間違いないです。
しかし、しかしです。
長年プログラムを書く仕事をやってきた自分としては、プログラミングの仕事の本質はプログラミングではなく、他人(もしくはチーム・組織、会社、社会）の脳内活動の統一化及び言語化にあるのではないかと考えています。
そもそもプログラミングなんてものはプログラムを書けばいいだけの話で、何も恐れずに言うのなら誰にでもできる作業なのです。(実際、小学生でも書こうと思えばそれなりに書けます)
私自身も、最近はプログラムを考えるのがめんどくさくて、すぐChatGPTにコーディングを丸投げしてしまいます。
しかしながら、仕事として行うプログラミングとなると、そうは問屋が卸しません。
今まで業界の中の様々な戦場を渡り歩いてきましたが、数多の挫折者を横目にしてきましたし、自分自身も何度も躓いて挫折しそうになりました。
そう、プログラムが書けるからといって、簡単にプログラマーとしてずっと働き続けられるわけではないのです。
では、プログラムが書けるのにプログラマーの仕事が難しい理由はどこにあるのか。
それが先ほど書いた通り、プログラマーがする本質的な仕事はプログラミングではなく、自分以外の脳みそから生成された思考や概念を現実のロジックに落とし込むことなのです。
答えが決まっている問題であれば、それをコードに落とし込むのは容易いでしょう。
また、自分一人で完結するならば自分の頭の中をコードに書き下すだけでいいのですから、まだ難易度は低い方です。
ですが、他人の脳みそから発生したものであれば、それを自分が解釈できるように翻訳しなければならないですし、それが本当に実現できるロジックなのか確認しないといけませんし、さらにそれが無理なら、できるように無理やり捻じ曲げなければなりません。
さらにさらに、他人一人だけではなく、それがチーム、組織、会社、と関わる人が増えれば増えるほど、全体として認識を統一しなければいけませんし、それを全て統合したものを現実のロジックに落とし込まなければなりません。
これが競技プログラミングと仕事で行うプログラミングが全然別物である理由でもあります。
昔、言語化は思考のコンパイルで書きましたが、自分自身の思考を言語化するのも意外と難易度の高い行為(先ほど難易度が低いと書いちゃいましたが)なのです。
自分自身だけでも難しいのに、それが他人になり、さらに複数人に及んでくると、その難易度は指数関数的に上がっていきます。
SEの人が病みやすかったり、たいていの大規模プロジェクトが炎上してしまうのもこのためです。
えてして人の発言は、主語が欠けていたり、コンテキストが考慮されていなかったり、そもそも適切に言語化されているかもあやふやなので、それを自分が解釈・実装できるようになるまで徹底的に言語化しないといけません。
言語化されていなければプログラムに落とし込むこともできません。
でも実際は、ほとんどの人は客観的な言語に落とし込む作業をサボり、オレオレ解釈を駆使して無理やりコードを仕上げます。
そして、いざ出来上がったプログラムを動かすと他の人から「自分が求めていたものと違う！」となりプロジェクトは無事炎上します。
他人の脳内、ひいては集団の脳内を適切な実行形式にコンパイル・リンクするのは至難の業なのです。
昔、初代PSのリッジレーサーのプログラマーの人がプログラムの息抜きに別のプログラムを書いていると聞いて「いや、他に息抜きの方法あるだろ」と思っていましたが、大人になった当の自分が全く同じことをしています。(このブログもそう)
一見、気狂いじみた行動と思えてしまいますが、ここまで説明したことを踏まえれば、それが息抜きになることは自明です。
仕事では自分の脳外の世界を、自分の脳外の世界の人たちが納得するようなコーディングをしないといけませんが、息抜きで書くコーディングは決められた問題を解くだけだったり、自分の脳内をコードに落とし込むだけで結果も問われないので、全く別行為となるのです。
ソースコードのコンパイルはコンパイラに任せて、仕事人としてのプログラマーは人間(たち)をコンパイル・リンクして仕事の成果をビルドする必要があります。
Ruby on Railsの作者であるDHHが「採用で悩んだら文章力が高い人間を雇え」といっている本質もここにあって、仕事においてプログラムがどれだけ書けるかはあまり重要ではなく、人間(たち)をコンパイル(適切に言語化)してリンク(認識を統一)してビルド(システムを構築)する能力が真にプログラマーに求められる能力なのです。
Tag: プログラミング