今月は，本を読み，学科の先生方の意見を耳にしながら，改めて，（エンジニアリング）デザインと，デザイン能力について，考えることができました*1．
メカニカル発想法から学んだこと
例えば，表4.4の小惑星の既成概念の数は20個にも及び，さらに発想すべき「エネルギー」は22個も存在し，加えて転換プロセス（p.60の表3.4）は8種類もある．単純計算すると，20×22×8=3520個もの組み合わせの中から満足できない屑発想を捨て去り，独創的な発想を選別することが要求される．
(略)
しかし，よく考えてみなさい．これは，われわれがこれらの発明品をすでに知っているから，発明の方法を後日談としてこのように解釈できるのであって，彼らが新機能を付加させようとしたとき，つまり発明をしようとしたときには，学生諸君が現在直面している問題＝既成概念の組み合わせの海で溺れるような錯綜した状況と同様であったはずだ．
(創造力育成の方法―JABEE対応の創成型教育, pp.79-80)
この引用部から学んだのは，次の2点です．
- ある課題から，一つの答えを求めるときに，「洗い出し」作業によって，答えを求めるための候補（必ずしも答えの候補ではない）が膨大になることがあります．そこから，与えられた条件を満たし，かつ評価者（授業なら採点者）に「なるほど」「すごい!」「よく考えた!!」と思わせるもの…独創的な発想…を一つ，見つけなければなりません．
- 例題やケーススタディから，技術者の当時の状況の一端を知ることができます．しかしそこで「解釈」を試みようとするのでは，自分が発想し，独創的なモノを作るときに役に立ちません．当時の開発者の状況に自らを置いて考え*2，現在の自分に適用することができてはじめて，その例題・ケーススタディを「消化した」となります．
数学ガール フェルマーの最終定理から学んだこと(1)
数学は，どっしりと存在している……と僕は思っていた．できあがった後の数学は確かにそうかもしれないけれど，できあがるまでの数学は，きっと，違う．
数式を書けば，数式が残る．途中でやめれば，書きかけの数式しか残らない．当たり前のことだ．
でも，教科書には，書きかけの数式なんて載っていない．建築現場から，すでに足場はかたづけられている．だから，数学といえばつい，整然と完成したイメージを持ってしまう．でも実は，数学が生み出されている最前線は，工事現場のようにごちゃごちゃしているのではないだろうか．
数学を見つけ出し，作り出してきたのはあくまで人間だ．欠けがあり，震えてゆれる心を抱えた人間だ．美しい構造に憧れ，永遠に思いを寄せ，無限を何とか捕まえたいと思う人間が，数学を現在まで育ててきた．
受け取るだけの数学じゃない．自分から作り出す数学だ．小さな水晶のかけらから，大きな伽藍を築いていく数学．何もない空間に公理を置き，公理から定理を導き，定理からさらに別の定理を導いていく数学．ひとつぶの種から，宇宙を組み立てていく数学．
ミルカさんのエレガントな解答，テトラちゃんのがんばり，ユーリが見せる条件への目配り……．数学へのイメージが変わってきたのは，彼女たちの影響も大きいな．
(数学ガール/フェルマーの最終定理 (数学ガールシリーズ 2), pp.196-197)
数学に限らず，多くの学問について
- どっしり存在しているわけではなく，新たな発見，発明，証明・実験により，「知」の体系は変わり得る
- 教科書では整理されているが，そこに至るまでの背後に多くの人の努力，苦労，失敗と成功があった
- 人によって書かれたものを読むだけ，例題を確認するだけで「理解した」とする人もいれば，与えられた最小の情報から目標に到達するにはどうすればいいかを追求し，実際に「達成した」人がいる
といったことが当てはまると思います．
上記引用の最後の段落について，これを引用したのは，これもまた，デザイン能力向上と関係があると感じたからです．周りの人（大学であれば，同じ授業を受ける学生ですね）を見て自己を相対化し，あるいは何らかの関わりによって自己の成長…というのが恥ずかしければ，自己の変容（ここも，大学で言うと，その授業を受ける前，あるいは入学前と，今の自分とを比較すればいいのです）に気づくことができれば，それが学習の意義ということであり，次のことを学ぶための土台となるわけです．
数学ガール フェルマーの最終定理から学んだこと(2)
「あの……ぜんぜんわからなくて解けないなら，いいんです．《ああ，あたしは○○を知らないから問題を解けなかったんだなあ》って納得します．でも，今回の場合，あたしはすべての道具をちゃんと持っていました．
この一つ一つについて，《これは何?》と問われれば，あたしは答えられると思います．でも――それなのに，あたしは問題を解くことができませんでした．(略) 除算ができる条件として，逆数に相当する要素――逆元――が存在する条件を調べよう……と発想できませんでした．(略)」
(略)
「なぜ? いったい，なぜなんでしょう．なぜ問題が解けないんでしょう．なぜあたしは重要なポイントに気づかないんでしょう．慣れ――なんでしょうか．いくら時間がかかっても，がんばって突破するというのが，あたしの得意技だと思っていました．今回，あたしも演算表を作りました．ちゃんとできました．けれど，そこまで．《1を探そう》と発想できませんでした……．もっと深く深く，深く，数学を読む力がほしいです……」
(同上，pp.204-205)
これは，「学生がなぜプログラムを組めないのか」という問題意識と同型になっています．すなわち，授業で文法を学び，プログラミングの成績はもちろん優で，教科書やGoogleから語句を調べるのは造作なく，サンプルソースもたくさん見たのに，自分でプログラムを組もうとすると，何かが足りずに完成に至らなくてもどかしさを覚えるだとか，友人や教員・TAのアドバイスを多数得て，一応仕様を満たすプログラムが完成したけど，もう一度自分で作れと言われると，作れるかどうか分からない，といった不安を生じるだとかです．
さてどうアドバイスしましょうか．思いつくままに並べてみると:
- 一つの着想を大事にしてください．それをコードにしてください．着想なく単純にプログラムができた，というときは，仕様の中で（あるいは，仕様から隠されている）重要なものを抜かしている可能性があります．
- プログラミングと数学の違いは，途中で*3検証（動作確認）してくれるものが自分以外にいるかいないかです．そのことを積極的に使って，構想はそこそこにしてコードを書き始め，気軽にコンパイラにかけて，エラーを教わって修正し，論理エラーも見つかりたびに原因を特定して取り除く，というのも一つの開発方法です．
- 人の完成品を見て，自分に足りないところを発見するようにします．そしてそれを言語化します．できればノートに書いておくのがいいでしょう．
