00:03
はい、9月…違うわ、4月10日月曜日。遅刻が昨日14分になりました。すみません、ちょっといろいろバタバタして今からになってしまいました。だいぶ遅れてしまいましたね。はい、おはようございまーす。
メビウィのkeethことくわはらです。えー、ではでは本日も朝から始めていきたいと思います。
で、えっと今日はですね、えーと、昨日、読もうと思ってた記事のお話をしたんですけど、すみません、リンクがわからなくてですね、バッと今ググったんですけど、履歴にすら残ってなかった。なんでか知んないけど。
ので、すみませんが、今日は全然違う記事をちょっと読んでいこうと思っております。今日はですね、あの、のぼりさんですね。はい、IPAののぼりさんの、えーと、「論理的思考の放棄」っていうブログですね。
僕もこれ実は人生2回読んだんですけど、ちょっと改めてこれに触れる機会がありまして、人生3回目なんですけど、改めてちょっと読み直したいなと思ったので読んでいこうと思ってます。
またこのブログ、意外とこう知られてなかったりもするので、まだまだ知らない方もいらっしゃるというところなので、まあ一緒になんか読んでいけたらなと思っております。
はい、では早速入っていきましょう。論理的思考の放棄ですね。はい、えーと、多分スタンプがついているのでおそらくスーさんが参加されていると思います。ありがとうございます。いつもよりありがとうございます。
では早速読んでいきましょう。僕はですね、1日に少なくとも3000行程度、もう多く書くときで1万行以上のプログラムを書くことができると、その結果多い月で10万行ぐらい書くこともあります。
なお、言語は各ソフトウェアの性質上大半がC言語であると。はい、このブログ自体が2007年の3月24日ので、もう実に16年前なんですけどね。
なので、まあまあその当時ののぼりさんはそういうC言語で書いたということですね。はい、でまたプログラミングにはバグがつきものなんですけど、ここ2、3年の間は発生するバグの数を極めて少なく保つことに成功しています。
とても大きく複雑で、かつレイヤー的にOSに近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも事前の設計が極めて重要となります。
設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となりとか、開発者の苦痛の原因となります。
当然のことながら、これまで書いたいくつかの大きく複雑と言えるソフトウェアの大半の設計も自分で行いました。
いかなる場合でも、設計は最初の1回目で確定させ、それ以降、プログラミングの作業に入った後も、その設計を公開したり修正しないといけなくなったりするようなことは、極力起こらないようにしており、その結果、そういう惨事は発生していない。
すごいですね。
ランニングしながら設計をうまくブラッシュアップしていくっていうのではなくて、最初の設計でガッと作ったら、そこから先は修正しないんですね。なるべくしないようにしているんですね。
へへー、すごっ。
へへーって言いながら、これ、僕、さっき言ったけど3回目なんですけど、3回ともたぶん僕、へへーって驚いてますね。
このようなことは、僕が大学に入学してから現在までの4年間ずっとやってきたことだが、同時にソフトウェア開発だけでなく、大学の単位の履修ですね。大学では普通に進級し、特に留年等をすることなく卒業できました。
もしくはその学術活動、4年間で学会で4件の招待講演、1件の受賞、5件程度の多大学での招待講演を行いました。
03:01
ベンチャー企業と経営など、いろいろなことを高い密度で行ってきました。同時に多数のことを行っても、能力不足による支障はほとんど出ませんでした。
よく考えたら、C言語で開発してたっていうので、C言語って言えばレイヤーが低いだけあって、そんなバグが起きたりとか、設計を後から見直すみたいな、結構厳しいんじゃないかなと思いますね。
制約もあったりとか、よりハードウェアに近いところでやるので、そんなちょちょコロコロ変えれるようなものじゃないのかもしれないですね。
僕はさらにフロントエンドの方の仕事をすることが多くて、やっぱりレイヤーが高ければ高いほど、見た目の方に注視するので、変更が容易であるというのは間違いないですよ。
だからこそ、ちょっとABテスト的に見た目を変えてみて実験したりとか、違うバージョンで実施したりとか、しょっちゅうビジネス的にある話なので、
そういう意味で言うと、あんまりガッツリ最初に設計をしないっていうのが僕らの状況だったりするので、C言語で開発してる人は確かにそんなに変更はしないのかもしれないですね。
だからこそ最初の設計が大事だったりするという話かもしれないです。
僕の友人はFPGAをやってるらしくて、まさにハードウェアの仕事なんですけど、
1回のビルドとかコンパイルに数時間かかって、1日にコンパイルなんて2、3回しか行えないので、1回のバグがかなりシビアだみたいな話をしてて、
やっぱり状況とか環境、場所が違うとそういうことがあるんだよなっていうのは思い出しました。
はい、余談です。
で、戻りまして、自分の能力は上記程度であるけど、能力というのはこれぐらいが標準的なのだろうと思っており、
自分の能力が特別高いということは思っていませんでした。
しかしどうやら色々なソフトウェア開発者の話を聞いたり、記事を読んだりしてみたところ、
上記の程度にできる人はごく少数らしいということに最近気づきましたと。
色々調べた結果によると、普通の開発者の作業能力は1ヶ月数百行程度、多い人でも1ヶ月で3000行程度らしいですと。
はい、1日数百行ではなく1ヶ月数百行である。
もちろん職業プログラマーの話で、仕事の他に毎日大学へ行ったり、
自分の会社を持っていたりしているわけではなくて、プログラミングに専念していてもこの程度だというイメージしていただいた現状と全然違うと。
野森さんはそうですよね。
自分の会社があったりとか、別の大学の研究とかがあったりすると。
それでも1日に数百行で1ヶ月、多い時は10万行も書くというところですよね。
それはイメージ違いますよね。
そこで、ここ4年くらい、自分自身の能力の根源について探求を重ねるとともに、
色々なことを調べているうちに、普通の人の考え方と自分の考え方が大きく乖離しているということが分かりました。
このようなことだけを書くと、自分にはそういう能力には縁がないとか、
少しできるからと言って自慢するなとか、偶然だとか思う人がいるかもしれないから、
これから誰でも少し考え方を変えるだけで、上級のような能力、作業効率を獲得することができるものだということを伝えたいと思います。
そうすれば、自分一人ではなく、みんなにとって有益だと思うからになります。
まず最も重要な前提知識として、以下の3つのことを遵守することが必須であります。
1つ、努力しないこと。
2つ、論理的に考えないこと。
3つ、頭を使わないこと。
06:00
はい。
やっぱり何の読んでも嘘やろと思う3つですね。
はい。いきなり上のようなことを読むと、普段言われていることのようなことと正反対で驚いたり疑ったりする人がいる。
というか、大半の人がそのような気である気がする。
はい、そうですね。と思います。
我々は普段、社会通念として、①努力すること、②論理的に考えること、③頭を使うことといったようなことをいつも言い聞かされています。
そのような誤った指導を、小学校から就職退職までの間、つまり人生のほぼ全てで受けるので、全く自分の能力に気づかないまま一生終わるという人もいるようです。
特にコンピュータープログラミングは、論理的な仕事の極端な例なので、プログラミングをする時の開発者の頭の中はとても論理的に思考しているんだろうと思われるのが通常であり、
上記の特に②ですね、論理的に考えないことにとても大きな違和感を感じる人が多いと思うので、まずこの点について説明しましょうと。
最近いろいろ話してみると、コンピューターに関する技術的な仕事、特にプログラミングやソフトウェア設計などは、論理的思考で行うのが良いと誤解している人が結構いるということを知りました。
確かにプログラミングなどは、コンピューターに対する指示をプログラミング言語を用いて論理的に記述する作業になりますので、その作業中は論理的な思考をすればするほど能力が上がるというふうに考えてしまうのは自然であります。
しかし実は正反対であります。複雑で難易度の高い作業においては、たとえコンピュータープログラミングなどの超理論的な結果を得るための作業であったとしても、論理的な思考というのはほとんど不要になります。
ここで論理的な思考の定義を細かくすることはしません。そもそも細かく定義しようとすること自体がすなわち論理的な思考である。
論理的に厳密に定義しないので、あなたの頭の中で論理的な思考というイメージを実際に思い浮かべればいいですよと。
僕は脳科学について詳しくありませんし、今勉強を始めるとしているところなので、いかに書くようなことは論理的、既存の科学的には間違っているかもしれません。
だが、論理的な思考をしないでほしいという意図を説明するために書くのだから、論理的に間違っている点については目をつぶってほしい。
プログラミング処理を行うのは当然人間である。人間はプログラミングを行うことによって、実現したい処理内容の指令を論理的に記述し、コンピューターに書き込みます。これがプログラミングです。
コンピューターに対する論理的な指令という目的があるため、プログラミングは論理的な仕事であるように思ってしまい、プログラミング作業の全部において、
人間の側が論理的な思考を持って作業を行ってしまうのであります。実は、プログラミングの作業のほぼ全てにおいて、論理的な思考というのはほぼ全くと言っていいほど必要ない。
例えば、論理的でない作業について考えてみましょう。音楽を聴いてこれは良いと思ったり、映画を見て感動したりするといった作業は、論理的な思考というよりもどちらかというと直感的な作業になります。
音楽を聴いていて、この周波数やパターンの音色が数ミリ秒ごとに連続して現れる、これは良いというような、いつも論理的に思考していては音楽をちゃんと聴くことはできない。そりゃそうだよね。
もっと直感的に、なぜか上手く言葉で正確に論理的に表現することはできないんだけど、この音楽は自分としては良いというような知覚というものが発生します。
09:08
コンピューターのプログラムを読んであり、書いたりするといった論理的な技術方式を対象とする作業であっても、論理的な思考というのは音楽を聴いたりするときと同様にほぼ全く必要がない、論理的でない考え方をすることが重要なのだが、ここでは仮に感覚的な思考とでも書いて表現することにいたします。
一応現在の科学では人間の脳はコンピューターのようなものであるということになっています。
しかし当然、本能満型のコンピューター、現在の普通のコンピューターのアーキテクチャーのことではないです。もっと効率が良い方法で色々な作業を行うことができるんですよ。
現在のコンピューターは論理的な処理しかできないが、人間には感覚的な思考処理が行えます。人間のアーキテクチャーと現在のコンピューターのアーキテクチャーは全然効率が違います。
ところがなぜかプログラミング作業をやっていると、対象となるコンピューターが論理的処理しかできないので、人間の側もいつの間にか無意識のうちに論理的思考しかできなくなってしまいます。
ここに大きな落とし穴がある。人間のアーキテクチャーは感覚的思考によって動作し、その勝利能力がとても高いんですね。
そのため人間は努力すればするほど、感覚的な思考の機能の上に普通のコンピューターが行っているような論理的処理を行う環境を仮想的にエミュレーションし、
その上で様々な論理的プログラムを実行することができる。
例えば電卓を使用しなくても数字の暗算ができたり、短いプログラムであればコンピューターに入力しなくても頭の中で実行することができる。
だが、人間の感覚的思考の機能の上でエミュレーションされた論理的処理機能というのは、
所詮エミュレーター上のようなものなので、実マシン、人間本体と比較するととても処理が遅いです。
オーバーヘッドが大きすぎるのであります。
あらゆる方式の処理を瞬時に同時実行することができる人間の頭脳がせっかくあるのに、
論理的処理用の仮想環境を脳の中で構築し、その上で物事を考えるから効率が悪くなる。
これが普通のソフトウェア開発者が1ヶ月にわずか数百行から3000行程度しかプログラムを書くことができない原因になっています。
人間の中に構築することができる仮想の論理的処理のエミュレーターというのは性能が低すぎるのであります。
そこで、論理的思考を極力排除し、人間の本来の得意な思考法である感覚的思考機能を用いて色々な作業を行うことにすればとても効率的になります。
ここで多くの人は、この人間が持っている超高性能な感覚的思考機能というのは、
例えば作曲だったり小説の執筆だったり絵画の制作などの芸術的な創作作業でのみ使用することができ、
プログラミングとか設計とか計算とかそういう類の論理的な作業では使用することができないと誤解してしまっています。
論理的に考えると、確かに論理的な作業というのは論理的な基盤の上でしか行うことはできません。
だが僕はプログラミングやその他の論理的な作業についても超高性能な感覚的思考機能の方を直接用いることにより、
わざわざ脳内論理回路エミュレーターを用いなくても効率よく処理できるということを知っているので、そっちを使っているというだけであります。
12:06
実際のプログラミング作業を例にして解説してみます。
まず、だいたいこういうソフトがあればいいなとか、このような機能をつける必要があるなとかいったとても抽象的なことを思い浮かべます。
この際、絶対に論理的に考えないことが必要である。
論理的に少しでも考えてしまうと、途中までうまくいってもそれが壊れてしまい、最初からやり直しになるので注意をしましょう。
感覚的な思考で持ってこれを置くのであります。
次にだいたいイメージができたところで、心の中にソフトウェアの設計図やデータ構造といったものを思い起こします。
ここで注意するのは、絶対に論理的に考えて設計をしないことになります。
徹底して感覚的な思考で設計をします。
ここまでは全て頭の中で処理することができるので、別にコンピューターがなくても良い。
電車の中でも、事業中でも、運転中でも行うことができ、便利であります。
蒸気まででほぼ全ての作業が完了している。
とにかく論理的に考えて設計しない。感覚的にまずやっていく。イメージというところですよね。
残された仕事として、最後にコンピューターに対してプログラミングを行う必要があります。
これには物理的なコンピューターとキーボードがどうしても必要である。
紙にペンに書くと手が疲れるし、キーボードがなくても結局コンピューターに入力することができる便利で、高品質なデバイスはまだないからですね。
プログラミングの目的は、そのコンピューターに処理を実行してもらうことなので、コンピューターにプログラムを入力しないという意味がない。
そこで仕方なくコンピューターの前に座ります。
コンピューターの前に座って、キーボードの上に両手を置けば、あとはあまり考える必要はない。
自動的に手がキーボードを打ち、プログラムを入力して完成させてくれる。
この処理は一切論理的指向では行われないので、途中で論理的指向を行うことは厳禁であります。
作業の邪魔になるとかひたすら何も考えない。
これができればね、話は速いって毎回思いながら読んでます。
自動的に手がキーボードを打つって言うけど、実際このメソッドどうしようかとか、変数とか分岐処理どうしようかなとか、
ここのコンポーネントとかスコープの違いとかみたいな、いろんなことをやっぱり結局書きながら考えてしまう気がするんで、
ここに関してどうなんだろうというですね、それすら能しのしというか、自動的に手が動くようになるんですかね。
のぼりさんももしかしたらなるのかわかんないですけど。
感覚的、思考で設計した詳細度っていうのですかね、っていう解像度がすごく高いのかもしれないです。
のぼりさんはそもそも設計レベルがもう頭の中で感覚的に、物詳細設計くらいまでできてて、
あとはガード手が勝手に頭の中を吐き出してるだけみたいなのかもしれないですね。
そもそものその能力の違いはいつも感じながらこれを読んでます。
けどまあそういうことを彼は知っているということですね、少なくとも。
入力エラーがなく手を浮かせる速度には物理的な限界があるようだ。
多くても1日1万行程度ぐらいが限界であります。
それでも入力エラーは頻繁に発生します。
この作業はエネルギーが必要なので食事をちゃんと取ることや、好きな飲み物100%オレンジジュースがいいらしいです。
等を机の上に用意しておくことが推奨される。
15:00
プログラムが一通り完成したらテストしてみる。
上級の過程でもやはり若干のバグが発生することはあります。
一大半はコンピューターへのプログラムの入力中に発生する脳内での変換エラーのようであります。
脳内にある感覚的なプログラムの構成データをコンピューターが理解できる
論理的なプログラミング言語のソースコードに変換する部分で若干間違うこともあります。
しかしこれも回数を重ねるたびにより正確になっていくので心配する必要は特にありません。
何度テストしても後になってバグが出てきてしまうこともあります。
論理的に考えれば長期のような正確なプログラミング作業の後には若干の誤りもないはずなのだが
これは論理的な処理ではないのでなぜバグが発生してしまうのかは論理的にはわからない。
これは仕方がないものと考えてバグを直せばよい。
それでも普通のプログラマーが論理的な思考でプログラムを書く際と比較して
バグの発生件数は大幅に減り楽になります。
長期のような方法はおそらくプログラミングだけでなく色々な物事の設計とか文章の執筆
自動車等の運転などおよそのほとんどの作業で活用することができるのではないかと思っている。
しかもこの方法は一切努力をしたり苦労したりする必要がなくとても気楽になります。
なお何人かの作業効率が良いコンピューター関係のことをやっている人と話したところ
だいたいは上記のようなことを表現は異なるけど普段から実践しており
それによって平均的なレベルと比較してはるかに高い能力で作業しているようであります。
最大の問題点はせっかく上記のようなことを読んでも
大抵まず頭の中にある論理的思考が上に書いてあるようなことは論理的にありえないという風に論理的に考えてしまい
いつまでも論理的に考えてしまうことというのが最大の問題点です。
論理的に考えない方がうまくいくと聞いてもそれが正しいかどうかやってみずに
論理的な整合判断をしようとして論理的に考えた結果まさかこんなことはないだろうというような論理的な考えに従い
いつまでたってもやってみないということがあります。それはとてももったいないことであります。
そこで今後時間があるときに日記か何かでさらにこのことについて詳しく話しできれば大人でも利用してもらって
役に立つ程度にまとめたいという風に思っていますと。
というところでこの記事ですねブログには続きがあって論理的思考の方記2という風に続きます。
どうしようかな。短いので2もちょっと今の時間オーバーしたんですけど一瞬ですね。
なのでちょっと読んでいこうと思います。論理的思考の方記2です。
最近あまり日記を書いていなかったので少し書いてみたら賛否両論のコメントがたくさんついたことを嬉しく思うというので
はい。先ほどの記事のリンクですね。もほほ面白いということで
いつも書くようなくだらない内容の日記と比較して
昨日のは短時間でこれだけのコメントがついたということがこのような問題解決方法に関する
汎用的な方法を知りたいという関心度の高さも表しています。
作業の例としてプログラミング、作業効率の例として行数を上げて説明したつもりだが
プログラミング以外の作業にも適用可能だと。
依頼されて行う仕事も自ら行う趣味というのも同じだと思うし
また作業効率として行数のみを上げようとするのはやっぱりおかしいという話も最もあります。
それらの表現は一種の分かりやすい比喩として例示したものなので
別の表現に置き換えていただいても構わない。
方法を知ることでそういう効率的な方法で仕事ができるようになるのだが
18:03
その方法を他人に伝えるということはとても難しいことになります。
なぜならばその方法は論理的でないためでありますと。
頭の中の論理的でない部分を最適化しないといけないためで
そのための方法を言葉という論理的な方法、表現方法ですね。
で、記述することは極めて困難であると。
しかしそう言って伝えることを諦めてしまうのも面白くないので
もう少し時間をかけて、どのようにすれば分かりやすくまとめることができるんだろうか
ということについて研究してみて
うまくなれば発表しようと思うからしばらくお待ちください
というところでこの記事は締められておりました。
はい、いかがだったでしょうか。
僕らクリエイティブの中でもさらにプログラミングという
論理的思考が求められると思い込んでいる世界の人間
しかもその中の頂点みたいな人が
論理的思考の宝器というところをブログに書かれるというのは
とても面白い記事でしたね。
はい、これ僕3回目なんですけど
何度読んでもやっぱりインパクトあるし
何度読んでも僕このチャレンジちゃんとしてなかったなと思うので
これは改めてやってみたいと思います。
なんか論理的であることの必要性、重要性というのは全然ありますし
そのケースバイケースになると思いますけど
全部のケースにおいて論理的思考が必要だというわけではないというのを
ちゃんと自分たちの中に一回考え方を壊すというのはやっぱり必要だと思いますね。
そういう技術的なお仕事とかプログラミングとかもそうですし
設計をする人たちもそうですけど
っていうのは論理的で考えなければならないという
一種ある種の思い込みがやっぱりすごい強くて
でも実際はそうではなく感覚的なところでやってみて
実際に行っている第一人者ということもたくさんいらっしゃるし
そういう人たちのほうが結果が出ている可能性が多いにあるんですよね。
というところでその論理的の何ですかね
論理的思考の中で呪縛と言ってもいいかもしれないですけど
一回脱却をするための感覚的思考で仕事をしてみるっていうのに
チャレンジしてみるのが一ついいかもしれないですね。
はい、というところでした。
いかがだったでしょうか。
でもこれは僕の感覚なので
皆さんがどう読んだ時にどう感じるかっていうのもあると思いますので
ぜひぜひ読んでみていただければと思います。
はい、特にですね
僕ら同じ仕事をしている方は特に読んでほしいなと思います。
この記事もツイートでシェアしますので皆さんで読んでみてください。
ではではこの辺で
9時半も越えてきましたので朝方は終了したいと思います。
本日はですね
オンラインで多分見えてないスーさんという方と
あとヤンさんですね
ご参加いただきありがとうございます。
っていうかご無沙汰してますね。
はい、全然ちょっと違う業界のお話だったと思いますけど
ご参加ありがとうございました。
はい、というところで
じゃあ月曜日ですね
今日からまた1週間スタートしますけど
皆さんまた頑張っていけたらなと思います。
はい、それでは終了します。
お疲れ様でした。
