イチブトゼンブ

最近の科学では統計的アプローチが幅を利かせている気がする。

統計は英語で書くとstatisticsで省略形がstatsになる。

statsの方はスポーツやゲームで割とよく見る単語だ。

ボール保持率やパス成功率、打率や防御率、収集アイテムの取得数など、試合やゲームの結果を色んな分析要素を定義して数値として表現してくれる。

要は、できるだけいろんな要素を数値化して物事を解釈しやすいようにするのが統計的アプローチだ。

過去に何回か書いた気がするけど言葉にした時点でかなりの情報量が削り取られている。

そこから数値だけを抽出するとさらに情報が削り取られる。

挙句の果てには、人から人に伝聞されることによって削り取られるどころか変形して別の意味になったりする。

はたまたデータサイエンティストによって意図的な結論に誘導するために使われたりもする。

ともあれ統計となると数値として表現しなかった側、少ない側のデータはなかったことにされがちである。

100%に満たないのであれば、それがどんなに大きな要素であったとしても全体の中の一部分でしかなく、全てではないにもかかわらず。

95%の人に有意の結果が出た場合、とても素晴らしい結果のように聞こえる。

しかし95%に含まれなかった5%は無視される。

100人中5人、20人中1人と書くとかなりの割合にも思える。

1クラスに1人か2人は該当するということだ。

これはそんな簡単に無視できる数字じゃない気がする。

しかし統計は小さな不利益を捨てて大きな利益を取りにいく。

5人が幸せで95人が不幸であるよりかは、5人が不幸で95人が幸せであるほうが当然いい。

上条当麻でもない限りはみんな後者を選ぶはずだ。

数値化による有意性はほとんどの人にとって利益があるので、人類全体から見れば統計学は役に立つ学問であると言える。

ただやっぱり不利益はあるのでそこの部分はみんなもう少し意識を持ってほしい。

ダイバーシティを謳うならマジョリティーだけではなくマイノリティーも当然考慮に入れるべきだ。

統計学は学問なので、その結果はやはり「科学的」であるとされる。

みんなの「科学的」なイメージは0/100できっぱりと結果が分かれるものだと思う。

5＋6は必ず11であり、たまに10になったり12になったりはせず、水(2H2O)を分解すれば必ず水素(2H2)＋酸素(O2)になりNH3(アンモニア)などは発生しない。

これがみんなの思う「科学的」なイメージだと思う。

しかし最初に書いたとおり、統計はそうではない。

数式の例で例えると、95人には5＋6=11となるが、残りの5人は5＋6=10だったり5＋6=12になったりする。

100%絶対に11になるという保証はない。

しかし「科学的」と言う名の虎の威を被るとあたかも100%絶対に11になるという世間通念が出来上がってしまう。

この統計学は優生学と非常に親和性があって、時にとても危険な差別や思想を生みだす。

例えばA地区とB地区といった区別やA人種とB人種の区別分けにより犯罪率を比較した結果、A地区やB人種の犯罪率が高いとする。

そうなればA地区は危険な区域という認識になるし、B人種は危険な人たちという認識になってしまい差別を助長してしまう結果になる。

しかも統計の結果、数値化されてしまっているし、そのデータをエビデンスとして提示されると言い返しにくくなる。

あくまでも全体の傾向でしかないものであるにも関わらず、A地区やB人種である事実だけを取って、そのようなレッテルを貼られて差別(区別)される。

100人中5人ぐらいだったらまだ少ないものの100中30人となってくると、かなりの人数が統計という名のレッテル貼りの被害を被ってしまう。

これは確かに全体としてみれば利益があることは確かだ。

B人種よりA人種と付き合うほうが犯罪に巻き込まれる確率は低いのだから。

履歴書の賞罰欄で前科持ちの人がいたら採用しないでしょ？

これは犯罪者の再犯率が高いのは統計で証明されているので、その結果、前科持ちを差別(区別)して採用しないようにしている。(ちなみに、よく企業が募集要件を大卒以上にしているのも似たような理由で、大学に行くお金のない貧困層をフィルタリングしていた名残。貧困家庭の子は素行が悪い可能性が高いため)

しかし、前科持ちの人でも再犯する人もいればその後は何も犯罪を犯さない人もいる。

さらに前科持ちであっても人は生きている限りは生きなければならないので、どこかしらの組織に属して飯の種を確保しなきゃいけない。

統計の結果、あぶれた側の人達にも人生があり、それがマイノリティーであったとしても完全に無視することはできない。

A地区やB人種を無視することはできないし、さらにその中にはそうでないにも関わらずにレッテルだけを貼られた、ほんとはマジョリティーなのにマイノリティーとして生きている人も犠牲にしてしまっている。

統計は傾向の問題を個人の属性にまで転嫁する。

統計はある一定量の例外には目をつぶりつつ、最大限の社会利益を追い求める。

マジョリティーからすれば一見、うまく社会がまわっているように見えるが、その裏のほとんどの人の目の届かないところでマイノリティーの人たちは苦虫を噛み締めながら日々を生きている。

このようにゼンブがイチブをかき消しながら、はたまたイチブがゼンブを飲み込みながら社会は突き進んでいく。

しかしイチブはゼンブではないし、またゼンブはイチブでもない。

統計はあくまでも「傾向」を数値化しているに過ぎない。

Tag: 哲学

One Wild 確定申告 2021

(※2021年３月初頭時点の情報です)

freeeとマイナンバーカードを使ってe-Taxによる確定申告にチャレンジした際、何回か心を折られたのでその時のメモ。

QRコードを表示できない(e-Tax用のファイルがダウンロードできない)

freeeの確定申告書類の作成を進めていって、提出の画面。

マイナンバーを入力してもe-Tax用のファイルダウンロードボタンもQRコード表示ボタンも押せない。

e-Taxのサイトを見るとマイナンバーカードを持っていれば「利用者識別番号」はいらないように読めるけど、freeeを使った申告では必須なよう。

マイナンバーだけでなく利用者識別番号も入力しないと上記のボタンを押せない仕様だった。

e-Taxのサイトを直接利用すればマイナンバーカードだけでいけるのかもしれなかったけど、今回はチャレンジしてないので分からん。

とりあえず利用者識別番号を入力するひとつ上の「電子申告に必要な準備をしましょう」の項目から「電子申告開始ナビ」のリンクを押して利用者識別番号の取得と利用者識別番号と電子証明書の登録(マイナンバーの紐付け)をする必要がある。

電子申告アプリでログインできない

freeeの電子申告アプリでログインしようとした際、何回やってもログインできずロックが掛かった。

アカウント(メールアドレス)のロックは反映されてるようで本家のアプリのAPIが死んでデータを取得できなくなってて、ログインはできないしロックもかかるというクソみたいな状況になった。

電子申告アプリはGoogleアカウント連携には対応しておらずfreeeアカウント管理からパスワードを設定することによってログインできるようになった。

電子申告アプリで文書が取得できない

ログインできるようになったのはいいものの、最初の項目の確定申告の提出画面でe-Tax用のファイルダウンロードが押せるところまで入力済みなのに、電子申告アプリでは文書が取得できない。

このアプリは基本的にfreee本体で作成したQRコード(URLリンク)を踏んで起動させる使い方っぽい。

QRコードを読み込んで起動すると文書が自動でダウンロードされる。

ちなみに、「電子申告開始ナビ」で電子証明書の登録(マイナンバーの紐付け)をする時も電子申告アプリを使用するが、その時もQRコードを読み込んで使用する。

マイナンバーカードを読み込んでくれない

マイナンバーカードの読み込みに対応する端末一覧をみると現在使用中のiPhone12シリーズがなかったので手持ちのAndroid端末(Pixel5)を使って読み込もうとしたけど、これがすべての不幸の始まりになろうとは…

Androidだと「JPKI利用者ソフト」というアプリが電子申告アプリとは別に必要で、このアプリがマイナンバーカードを読み込むんだけど、これがエラーばっかりで全然読み込んでくれない。

「マイナカードはこのパスワードじゃなかったかな？」「署名用電子証明書じゃなくて利用者証明電子証明書のほうかな？」みたいにいろいろやってたら無事パスワードロックが掛かる。

何時間ぐらい待てばロック解除されるのかな？と調べると、なんと、役所に直接出向いてパスワードの再設定をしなければいけないらしく、かなり絶望した。

マイナンバーカード作った人はわかると思うけど、パスワード設定用に使うタブレット端末もめっちゃ扱いづらい。

多分この影響で自分が誤入力してしまって、最終的に2日連続で役所に行くことになった。

この時点で税務署に行ったほうが早い。

結局、手持ちのiPhone12miniでチャレンジしたところ普通に読み込めたので、Androidだけは使わないほうがいいと思う。

パスワード関連について

ちなみに電子申告時に使う「署名用電子証明書」のパスワードは英大文字と数字の組み合わせだけど、iPhoneのJPKI利用者ソフトで検証したところ、小文字でも大文字と小文字を混ぜてもどちらでもOKだった。

役所でパスワードの再設定を行うと反映まで1日待ってって言われる。

この一日が24時間待つのか、翌日まで待つ(日付またぎ)のかはよくわからない。(役所の人は仕様知らない)

再設定直後だと、マイナンバーカードで認証しようとするとパスワード更新中みたいなエラーが出て使えず、 翌日の朝にやると使えるようになってたので、多分、早朝バッチで処理してるっぽい、知らんけど。

あと、確定申告の書類を提出したいだけなのに管理するパスワードが多すぎる。

マイナンバーカードで5種類、freeeの追加設定で＋1、利用者識別番号の発行で＋2、もともとGoogleアカウントのパスワードも足すと全部で9種類もある。バカか。

まだ電子申告アプリでエラーがでる

2日に渡る役所通いを経てやっとマインバーカードの認証は通ったもののまだエラーが出る。

調べると最初の「利用者識別番号」の取得の手順で、利用者識別番号と電子証明書の登録(マイナンバーの紐付け)を忘れていたらしい。

利用者識別番号を取得するだけじゃなくてマイナンバーとの紐付けもしっかりしないといけない。

肝心の納税の仕方がよく分からない

紆余曲折を経てなんとか確定申告は終了。

と労われるが、たしか確定申告の期限と所得税の納付期限は同じはず。

所得税まで払いきってやっとすべて一段落となる。

が、納税の仕方がわからない。

freeeだとクレカ決済のページを紹介してくれるが、入力作業があるのと手数料が法外な金額なのであまり使いたくない。

振り込みで払おうと思ってググって調べてみても、いまいち何を言ってるのかわからない。

最終的に納税用のQRコードを発行してなんとかコンビニで支払うことができた。

以下、(iPhone12miniを使った)QRコード発行までの手順。　※ちなみにQRコードによる納税は30万円まで

• 「マイナポータルAP」というアプリをインストール
• ブラウザ(safari)でe-Taxのサイトのログイン画面へ

• 「マイナンバーカード読み取りへ」をタップ→「マイナンバーカードの読み取り」をタップ

• 以下の画面が出てくるので「開く」をタップ

• マイナポータルAPが起動して下記画面が出てくるので利用者証明用電子証明書のパスワードを入力して「次へ」をタップ

• スマホの下にマイナンバーカードを置いて「読み取り開始」をタップ

• 画面の表示の通りsafariに戻る

• 戻ってきて白い画面だった場合はタブをタップして元のe-Taxの画面に戻る

• e-Taxの画面に戻ると最初は多分下記の画面になる

• freeeの「電子申告開始ナビ」で一回連携させたとは思うが、ここは断腸の思いで「利用者識別番号・暗証番号お持ちの方はこちら」を選んで再度紐付けを行う(スクリーンショット撮ってないのでここは頑張って)

• メインメニューに戻って「送信結果・お知らせ」をタップ

• メッセージボックス→メッセージボックス一覧を順にタップ

• 「納付情報登録依頼」のメッセージをタップ

• 画面の一番下の方までスクロールすると「QRコード作成」ボタンがあるのでタップ

• なんかメッセージが出るけど「OK」

• QRコード作成の画面が出る、入力項目は全部埋まってるはずなのでそのまま「帳票表示・印刷」をタップ

• なんかメッセージ出てくるのでそのまま「OK」をタップ

• QRコードが生成された画面が表示される

• ファミマかローソンに行って店舗端末で上記のQRコードを読み込ませると支払い用のレシートが出てくるのでレジに行って支払う

Tag: 日記

野生のプログラミング

概念が豊富であるということは、現実のもつ諸特性にどれだけ綿密な注意を払い、そこに導入しうる弁別に対してどれだけ目覚めた関心をもっているかを示すものである

コンピューターサイエンス vs 野生のプログラミング

よくコンピューターサイエンス(以降CSと省略して表記)が大事だと聞きます。

特に欧米ではエンジニアとしての就職にCSの学位が必須だと言われています。

しかし、日本で働いている限りにおいてはあまり気になったことはありません。

まず、CSが具体的に何を指すのか自分にはよく分かりません。

実際にエンジニアとして働いている人にCSとはなにか？と伺っても明確な解答をしてくれる人もあまりいない気がします。

自分の大雑把な理解だと、大学や大学院における専攻科目の履修内容がそれにあたり、卒業をもって学位が与えられる認識です。

自分は大学に行ったことがないので教育機関でどのような内容を教えているのかは分かりません。

実際の中身についてですが、軽くググった感じだと、データ構造やアルゴリズムの知識だったり、基本情報技術者試験の知識だったり、実際のプログラミングだったり、コンピューターやネットワークにまつわる知識だったり、ソフトウェア工学の内容であったり、人やコンテキストによって様々です。

さて、学位がないとしても上記の内容を網羅的にどこかしらの教育機関でガッツリ学んだエンジニアの人はどれぐらいいるのでしょうか？

自分の過去の職場を思い起こしてみると、大卒でも別の専攻であったり、専門学校出身であったり、高卒であったり、CSの学位を持つに相当する教育履修者にほとんど会ったことがありません。

しかし、エンジニアとして働いている人はたくさんおり、優秀な人もそこそこにはいます。

その優秀な人はCSの被教育経験はないにしても、それ相応の知識は身につけているように思えます。

では、彼らがどのように知識を身に着けたかというと、独学であったり、仕事において業務遂行に必要な知識が漸進的に体に染み付いていった結果だったりします。

ほとんどの人が学問や教育としてCSを身に着けたのではなく、仕事や実践を通じてCSに相当する知識と経験を得ていると考えられます。

この事実は学問的基盤であるCSよりも実践経験、いわゆる野生の思考にこそプログラミングの本質が宿っていると考えることができます。

科学や学問は既存の存在する現象や概念を分析して導き出した思考群であり、学問が発生するよりも前にコンピューターとプログラミングはすでに存在していたのです。

プログラミングが存在するから、それに対する分析欲求の結果としてCSも存在しえるのです。

プログラミングが先に存在しているならばそれを扱うための思考もすでに存在しているはずです。

それこそがプログラミングにおける野生の思考であり野生のプログラミングとも呼ぶべき概念となります。

数あるLisp方言の処理系やPerlやRubyなどのほとんどのプログラミング言語は学問やアカデミズムから生まれたのではなく優秀な個人や集団の思考と実践の結果として誕生したのです。

そういった意味でもプログラミングの始まりは野生の思考からスタートしているのです。

CSは世の中に既に存在するコンピューターやネットワーク、プログラミングを分析の対象として、それを体系化して万人が利用できる知識にしているに過ぎません。

CSがあるからコンピューターやインターネット、プログラミング言語が生まれたわけではないのです。

概念分割欲求

ここまでで、野生の思考(プログラミング)から派生して生まれたのが学問(CS)である話をしました。

ここからトーテムとプログラミングの関係について語っていきたいのですが、まずは野生の思考(プログラミング)から学問(CS)が生まれる過程について考察します。

『野生の思考』では、いろんな民俗学者が各部族のトーテムについて、どのような意味が込められているかを色々考察した遍歴がつらつらと書かれています。

しかし、レヴィ＝ストロースはトーテム単体には意味がないとし、トーテムとトーテムとの差異に意味を見出しています。

民俗学者がやっていたように、ある一つの対象を分析して意味を見出す方法と、レヴィ＝ストロースのように多数の対象を俯瞰してその差異に意味を見出す方法論があります。(自分は互いのアプローチの違いをピックアップしただけで、レヴィ＝ストロースがこの方法論を提唱しているわけではないです)

この2つの方法論が学問体系を作り上げる基本的な欲求として存在している気がします。

例えばソート処理の場合、ソートとしての機能性を追求しアルゴリズムを研鑽する方向性。

もう一つは、バブルソートやクイックソートなどをアルゴリズムごとに分類し、それぞれに概念を与えて知識体系に組み込む方向性です。

一般的な日本語の認識だと前者が科学、後者は学問といったところでしょうか。

後者の学問的アプローチはシステム開発における要件定義にも生きてくる部分があります。

次の例え話がこのパラグラフで一番言いたかったことなんですが、概念を分割して定義することはとても重要です。

あるB2Bのシステムを開発していて「ユーザー」という概念があった場合、それが具体的にどのステークホルダーを指すのか特定することができると思いますか？

例えば自社でWordpress(ブログの運用システム)の開発・保守をサービスとして提供していると考えましょう。

この場合、ユースケースの登場人物として「運用者(自社の人)」「顧客(自社のサービスを契約した法人)」「閲覧者(Wordpressのサイトを見に来る人)」がいることになります。

では「ユーザー」とはどの人を指すのでしょうか？

自社から見れば自社サービスを契約して使ってくれている「顧客」が「ユーザー」と捉えることができます。

しかし、「顧客」からみれば「閲覧者」が「ユーザー」となります。

システム運用上、自社目線と顧客目線の両方の「ユーザー」を取り扱わなければなりません。

よってDDDにおけるユビキタス言語よろしく、自社から見たユーザーは「クライアント」、クライアント(顧客)からみたユーザーは「エンドユーザー」といったように概念を分割することによって立場による認識違いを防ぎ、コミュニケーションを円滑にすすめることができるようになります。

これは未開人が弁別のためにトーテムを利用していたのと同じ動機で成り立っています。

こういった場面でも野生の思考を感じることができます。

トーテムとフレームワーク(種)とサービス(個体)

『野生の思考』ではトーテムを弁別の実践のための道具として解釈している部分が大いにあります。

トーテムは自然から意味を抽出しているのではなく、あくまでも弁別のために自然から名前を拝借しているだけなのです。

分析的解釈ではなく概念を分割し比較することによって得る解釈なのです。

ある対象を分析してその正体を明かすのではなく、ある対象と別の対象とを比較して、その差異からある対象の正体を浮き上がらせることがトーテムの本質的な役割としています。

弁別のための方法論がトーテムなのです。

急に話は変わりますが、ポケモンのピカチュウを思い浮かべてください。

ピカチュウは種族名であって個体名ではないことに気をつけてください。

アニメではサトシは自分のピカチュウをピカチュウと呼んでいます。(ゲームだと自分の捕まえたポケモンに好きな名前を付けることができます)

これは飼っている猫をネコと名付けているようなものです。

そこでマチスとのバトルになり、マチスがピカチュウをくり出してきました。

このとき、マチスもピカチュウをピカチュウと呼んでいた場合、第三者が互いのピカチュウを個体名だけで分別することができなくなります。

そこで「サトシのピカチュウ」「マチスのピカチュウ」のようにマスターの名前を紐付けて呼ぶことにより互いのピカチュウを弁別することができます。

このときの「サトシの」「マチスの」の部分の修飾語が部族の自然の要素からトーテムを借用する使い方と同じ働きをしています。

ポケモンと部族との違いは弁別のための要素をマスター名から拝借したのか自然の動物からなどから拝借したかの違いしかありません。

互いに対象を弁別したいプリミティブな欲求によりトーテムを利用した、という点で同じなのです。

現代社会にあるポケモン一つとってみてもトーテム的な需要は発生しているのです。

ポケモンの例では、種と個体に同一名を採用したが故に弁別の必要性が発生しましたが、プログラミング業界ではこれとは逆方向の問題が観測されます。

あるシステムを作ったとき、そのシステムで採用したフレームワークとサービスとの関係性が重ねられて語られることがあります。

これはトーテムが特殊化としてではなく普遍化として働いてしまう例です。

Ruby on Railsを利用して自分の独自サービスを開発しても、ある程度の距離感から評価を受けると「Railsのシステム」という判で押したような解釈をされます。

これはサービスごとの個別性よりもRailsのトーテムとしての存在感のほうが勝ってしまうからです。

弁別のために利用していたトーテムが逆に概念の収斂化を促進することもあるのです。

またポケモンに戻って例えると、マチスはでんきタイプのトーテムを持っているので、人によってはライチュウやコイルを見ただけでマチスを連想してしまう、といった具合です。

前章で取り上げたWordpressもとてもトーテム力(？)が高いのでWordpressを基盤にして、その上にどれだけシステムを構築しようと「Wordpressのシステム」というトーテムによる普遍化からは逃れられないでしょう。

種から個体弁別のためにトーテムを利用することもあれば、トーテムの持つ吸引力が逆に個体を種に収斂することもあるのです。

プログラミングとトーテム

その他にもプログラミングの世界ではトーテムの息吹を観測することができます。

言語名にはRubyやPerlなど宝石を冠したもの、JavaやPythonのように豆やヘビと紐付いた名前になったものがあります。

PHPやScalaは“Hypertext Preprocessor”と“scalable language”のように言語に対する期待をそのまま名前に反映したものもあります。

実際の生い立ちについては諸説あるでしょうが、言語には何かしらのシンボルとしてのトーテムが設定されていると考えることができます。

技術書の定番であるオライリーの表紙にはインパクトのある生物絵をトップにドンッと掲載しています。

オライリーの表紙を一覧にして眺めているとプログラミングまわりの概念にもトーテムが息づいていると感じませんか？

……感じませんか、そうですか。

トーテムを感じる要素はまだまだこれだけではありません。

プログラミングの世界にはたくさんのジャーゴン(専門用語・概念)が存在します。

デザインパターン、オブジェクト指向などの設計思想、キャメルケースなどのコード記述スタイルなど多様な言葉と概念があります。

これらの各種ジャーゴンは業界内の宗教戦争の火種によくなります。

一番代表的なのはVim vs Emacsのようなエディタ論争あたりでしょうか。

こういった宗教論争が起きる理由は、まずジャーゴンがトーテムとして機能していること。

ついで、前章で言及したトーテムには個体を種に収斂させる効果があること。

最後に、カーストとトーテムに親和性があることが起因していると考えられます。

『野生の思考』ではカーストとトーテムの関係にも言及しています。

カーストは本当の文化を偽って自然化するが、トーテム集団は偽りの自然を本当に文化とするのである

プログラマーの世界ではどのプログラミング言語が一番最高か(もしくはクソか)という醜い言い争いが頻発しています。

この問題自体は個人の好き嫌いとコンテキストに依存する問題なので、どのような結論が導き出されてもどうでもいいのですが、宗教戦争の一つとしてよく観測されます。

この章の最初で言語とトーテムの結びつきを指摘しましたが、言語がトーテムとして機能しているからこそ言語間の差異があらわになり、トーテムの個体から種に収斂する効果が人々をまとめ、そこからカースト付けの動機が発生し、言い争いを生むのです。

トーテム集団としてのプログラミング言語は自身の文化を自然化するための衝動を秘めています。

そこでの衝動欲求がカーストを呼び覚まし、宗教戦争が発生するのです。

概念に染み付いたトーテム性が宗教色を帯び、概念ごとに発生した差異が比較衝動を刺激し宗教論争へと発展します。

また宗教戦争以外でも、トーテムの残滓を観測することができます。

コード規約は相同性はあるもののプロジェクトや現場によってそれぞれ違います。

それぞれの現場で規約は自律性を持ち、それぞれが独自なものへと進化(時に退化)していく過程は部族の持つトーテム性と似通ったものがあります。

キャメルケースとスネイクケースの使い分けや命名規則による弁別のアプローチも概念分割欲求としてジャーゴンを生み、そのジャーゴンがトーテムの類似性を継承しているようにもみえます。

たくさん例を上げたので、そろそろプログラミングの世界にもトーテムの息遣いを感じて欲しいところです。

プログラミングは知識ではなく実践

トーテムについて長々書いてきましたが、ぶっちゃけトーテム周りの話はただの蛇足です。

プログラミングまわりの事象と『野生の思考』の内容を無理やり併合させようとしたあがきです。

プログラミングは野生の思考の産物でCSはその端女でしかないこと。

最初の引用にある概念の細分化の必要性が当エントリで伝えたかったことになります。

実践におけるプログラミングは常に未知との戦いなので、我々は常に「野生」の中でプログラミングを行っています。

学問領域はあくまでも野生で戦う我々をサポートしてくれる万能ツールに過ぎません。

戦場は常に野生であるのです。

最後に野生のプログラミングの実践編みたいな文章を過去に書いていたのでそれを紹介して終わります。

知識とパタン・ランゲージでは知識よりパターン認知が大事という話を(今読むとパターン認知も知識の一つでは？という気がしないでもありません)、spec考とプログラマーにアルゴリズム脳はいらないでは知識よりもトライアンドエラーが大事だという話を書きました。

トライアンドエラーこそが野生のプログラミングであり、知識よりも上位にある実践価値を生みだす水源となっているのです。

Tags: プログラミング, 哲学, 本