数学的・数理的思考（？）が苦手

質問

細かい数学的・数理的なことを厳密に考えるのが苦手です。
とはいってもそんな学問的な話ではなくて、
例えば
・algo（ゲーム）で紙を用いずに数字を読むのが苦手
・プログラミングでこの配列がこうなってこうなる…というトレース？が苦手

一方、方針を立てるのは好きなので、脳みそに正直に言えば、
「こうやったらできる。あとは誰かお願いします…」
という気持ちになってしまいます。

複数の友達にきいたところ、逆の人のほうがむしろ多いらしく、
「俯瞰的思考は苦手だけど、緻密な作業や計算に没頭するのは好き」という感じだそうです。

さて、私が質問したいのは数理的というかミクロ的思考の訓練方法ではなく、
・あなたはミクロ的思考が好きですか？その理由をできれば言語化していただけませんか？
・ミクロ的思考と俯瞰的思考は同時にできると思いますか？それとも脳の構造上別のタイミングで処理しなければうまくできないと思いますか？
・こういうものは向き不向き（例えばミクロ的思考は頑張ればできるが、それに快感がない場合は不向き）があると思いますか？

以上、よろしくお願い致します。

回答No.2

ddtddtddt · ベストアンサー

プログラムの話が出たので、ここではミクロ的思考：ボトムアップ設計，俯瞰的思考：トップダウン設計としておきます。

　オブジェクト指向が言われてからもう久しいですが、その影響かトップダウン偏重の傾向があると思います。しかしトップダウンであろうとボトムアップであろうと、やり過ぎは有害であるが自分の意見です。それはアプリケーション開発を考えれば明らかです。

　顧客ヒアリング→仕様策定→適用技術選択→プログラミングと単純に図式化しますけれど、普通の分類では［顧客ヒアリング→仕様策定］が上流工程（トップダウン），［適用技術選択→プログラミング］が下流工程（ボトムアップ）という事になりますが、本当はこれらはみんなフィードバックし合ってます。

　まず下流工程は上流の影響を受けるのは当然としても、プログラミング作業としてその仕様は不可能だとか（適用技術選択，仕様策定へのフィードバック）、顧客の曖昧な要求をプログラミング作業として理詰めに詰めてみたら、じつは顧客のやりたい事は策定された仕様ではなかったなんてのは、普通にあります（顧客ヒアリングへのフィードバック、そのやり直し）。

　要は普通、中間で始まるんですよね。［仕様策定→適用技術選択］くらいで。これらにはもちろん上流・下流どちらの影響も背景としてあります。そこを切り出せば、

　　顧客ヒアリング→［仕様策定⇔適用技術選択］←プログラミング

ですし、

　　顧客ヒアリング←［仕様策定⇔適用技術選択］→プログラミング

にもなります。どちらかを偏重するのは良くないと思います。

＞・あなたはミクロ的思考が好きですか？その理由をできれば言語化していただけませんか？
　徹底的なボトムアップにより、大局的な問題点が明らかになるケースは絶対にあります。またボトムアップが、その背景（目的）としてあるトップダウンを実現するのを観るのは楽しいです。逆にトップダウンをどうやってボトムアップで処理しようと考えるのも楽しいです。

＞・ミクロ的思考と俯瞰的思考は同時にできると思いますか？それとも脳の構造上別のタイミングで処理しなければうまくできないと思いますか？
　短いタイムスパンでは交替にやるしかないと思いますが、長い目で見れば常に交替して考えるのは、同時にやってるのとほぼ同じです。

＞・こういうものは向き不向き（例えばミクロ的思考は頑張ればできるが、それに快感がない場合は不向き）があると思いますか？

　それはあると思います。思いますが、しょせんは訓練です。もしくは仕事上のプレッシャーかな(^^;)。

回答No.1

dottimiti

暗算に苦手意識があって、３つか４つくらい過去のことになるとすぐ忘れるような感覚があります。細かい計算は間違えることが多く、数学では苦労しました。

そういう意味で、ミクロ的な思考に苦手感を感じてきました。

今考えると、紙をメモリー替わりにして、自分で瞬発的に考える段取りを減らせば良かったんですけど。

大人になってからは、細かい計算はエクセルなどにやらせることにして、検算の仕組みを考えたり「構造的にみてこのくらいの値になるのは正しいか」「ほかの人からみてこの計算結果は見やすいか」ということをよく考えてます。

絵を書くことは好きで、図を描いて考えるのは楽しく感じます。一方、段取りをひたすら頭と身体に覚え込ませる楽器の演奏のようなことはすごく苦手に感じます。

お礼

すごく分かります。自分は視覚優位のアスペルガーのような脳の偏りがあるのかな、と分析しています。