わさっきhb

大学(教育研究)とか ,親馬鹿とか,和歌山とか,とか,とか.

大学生活で学んでほしいこと

授業や研究室で,私が関わる学生に向けて,卒業までに何を学んでほしいかを,洗い出してみました.

  • 全体と部分の関係
  • 因果関係
  • 自己管理
  • スコープ
  • 主観と客観
  • ラベリング

以下一つ一つ解説していきます.
これらは,2007年7月17日〜20日 - わさっき その3の「幹」あるいは「デザイン能力」と密接なつながりがあります.それと,それぞれの概念は完全に独立ということではなく,かといって包含関係があるものでもありません.それぞれが共通部分を持ちながら,どの一つも取り除くことができないものです.

全体と部分の関係

研究室の内外で,議論を見ていて,「教員は全体像が見えているけど,学生は自分のことで精一杯だな」感じる状況がよくありました.
全体と部分の関係として,抑えておくことを挙げてみます.

  • 目的と手段は,全体と部分の関係になり得ます.その目的に関連する手段が複数あるとき,「いくつかの手段を連結して,一つの目的を達成できる」という直列の関係かもしれませんし,「一つの目的を達成するための手段は複数あり,状況に応じて一つの手段を決める」という並列の関係かもしれませんし,直列と並列が組み合わさった形態かもしれません.
  • 全体はいくらでも拡張できます*1.ある視点で「これを全体」と設定することはあります.口頭で議論をしていると,ときどきそのバリアが破れます.論点に応じて,全体はどんなものか,そしてその中で今,焦点を当てているのがどこかというのに気がつくことが,議論を理解する第一歩です.

因果関係

一方が原因,もう一方が結果,という関係,これで「因」「果」「関係」ですね.知っておくべきことは:

  • 論理の「ならば」の関係は,因果関係です.一つ,何かを主張したときに,「それはなぜ?」と問われたら,因果関係の「果」が伝わって,相手は「因」を知りたいのです.「それをしたら,どうなるの?」という質問だと,主張を「因」と置いて,「果」を答えないといけませんね.
  • 実社会上での因果関係と言えば,「ある物事を行うと,これこれこんな結果になる」,という関係のことです.言葉にすれば簡単ですが,実際にそれを行うのかどうか,完遂するにはどれだけのコストがかかるかを無視するわけにはいかないでしょう.ここで,コストは金銭的なものに限りません.時間のコストや,人的コストもあるかもしれません.ここから,何か活動する際に,キーとなる人を見定め,働きかけることの重要性が見えてくるわけです.
  • 授業で確率統計を学ぶとき,そして研究において統計処理を行うとき,因果関係でないものを因果関係と勘違いしないようにしないといけません.相関関係だったり,もっと緩い関係だったりするかもしれません.複数の因果関係や相関関係が結合して,二者間に従属関係が見えているということもあります.

自己管理

風邪をひかないように,交通事故に遭わないように…だけではありません.ここで取り上げたい自己管理は.

  • ある行為をすべきか,しないでいいか,してはいけないかを見極めることが不可欠です.すべき中にも,「ある条件のときに,する(今はその条件を満たさないので,しない)」ということもあります.
  • 大学生は,大学生という身分を中心としながらも,家では家族の一員だし,一人暮らしをするにもご近所さんがあるわけだし,通学でさまざまな人と接するわけだし,アルバイトをするならあなたは労働者となるわけで会社とか雇用主とかがあるわけだし,と,それぞれで「立場」が決まります.立場に応じて,振る舞いは変わるものです.その一方で,その立場というのは,完全に自由に自分で決められるものではありません.反社会的行為をすると,あなたの氏名(公表されるかどうかはともかく)だけでなく「大学の名前」も出るというのは,その分かりやすい例です.
  • さて学業その他の日常生活で,すべきことがたくさんあります.上述の「すべきか,しないでいいか,してはいけないか」を決めるための強力なツールが,「優先順位」です.優先順位を決めるということは,優先しないことを決めるということでもあります.優先順位をつけて紙などに書き出し,実施したら「済」の印をつけるなり,線を引いて消すなりすると,「やり忘れ」を減らすことができますので,そういうのをしたことがないという人は,一度試してください.

スコープ

scopeと綴ります.大学で教えるプログラミング言語では,宣言するそれぞれの変数に有効範囲があることを教わったり,いくつかの例題を通じて,有効範囲のルールを知らないと不思議にしか思えない挙動があるのを見かけたりしたことでしょう.スコープは,有効範囲とも言い換えられます.

  • 物事を主張するとき,それはどんな状況で成立する(正しいと言える)かを示しておくと,その有用性がアピールしやすくなります.人の主張を見聞きする際にも,適切な利用状況を見つけ,提示することで,コミュニケーションが進むものです.「Aという状況で,Xが成立する」という主張と,「YならばXである」という主張があるとき,Yは,Aという状況をつくるための必要条件かもしれませんね.
  • 状況を先に設定して,その中でベストな解決策を見つける,ということもよく行われます.そのような意味での状況は,「コンテキスト」(コンテクストとも)と呼ばれます.
  • スコープには類義語が多数あります.上で書いたものも含めて列挙すると,scope,有効範囲,状況,コンテキスト,コンテクスト,エリア,area,対象,ターゲット,領域,ドメイン,domain,ローカルルール,俺ルール,切り口*2,面,側,アスペクト,などなど.

主観と客観

学生時代,論文作成に関して「原稿を書いたら,客観的な目で,見直してごらん」と指導を受けたことがあります.主観的の反対は客観的,subjectiveのantonymはobjective,と知識として分かっていても,客観の重要性は,私にはこのアドバイスから始まったように思えます.

  • 卒業論文でも査読付き学術論文でも,客観性が重視されます.客観的に書くにはどうすればいいかを,簡潔に表現するのは難しいのですが,「敬語を学ぶように,論文の書き方を学ぶ」のがよさそうです.敬語は,定型の語句や表現というのがあります.論文でも,日常は使わない定型句が数多くあり,そこに注意すると,スムーズに書けます.英語で言う「If ..., then」や「In this paper」ですね.
  • じゃあ論文というのは100%客観的でないといけないのかというと,そうは思いません.成功に導く(導いたと主張する)ための,著者や協力者の発想(着想,アイデア),実現あるいは実証の労力,途中でうまくいかないときの苦悩などを経て,「論文」という文章が出来上がるのです.途中段階をもしすべてリストアップしたら,主観的な判断がいくらでも出てくるものです.http://d.hatena.ne.jp/kenken31/20080205/p1で目を引く語句に「感情的に」がありますが,感情*3すなわち主観を見出すことによって,客観をも見出すことになり,説得力のある論証ができるというものです.
  • 主観と客観は,語義としては対立するものですが,行動としては対立あるいは独立するものではなく,自分の中に両方あるものであり,両方あるべきです.これらを結びつけると,「メタ認知」という概念になります.

ラベリング

間違う人はいないと思いますが「ラベ + リング」ではなく,「ラベル + ing」です.これが「バッファリング」になると,これも「バッファ + ing」が正しいのですが,「バッファ + リング」と誤解する学生がいました.それはさておき…

  • 「あなたの研究の目的は,何になりますか?」「設計思想を教えてください」「コンセプトを明確に!」…言っていることは同じです.やったことを手短に,かつ他の研究やモノづくりやデザインと区別するように表現することが課されているのです.その結果として表した語句は,言ったら終わりではなく,文字列(ラベル)となり,手がけたことの妥当性を確認するため,そしてリリース後も「何するものなのか」を簡潔に表したものとして流布されます.
  • 自分のことなら,ラベルを決めるのは自分となるわけですが,学問において,ある語句が日常使うのと違う意味になることがあります.法律の分野なら,善意・悪意がよく知られていますし,コンピュータの分野ならそうですね,「計算の手間」を問われて自分のコンピュータで3時間かかったと答えたら,頓珍漢というやつです.「専門用語」(テクニカルターム,あるいは単にタームとも呼ばれます)に注意し,また専門用語を使えるようにしましょう*4
  • 産業の分野でよく見かける「標準化」は,ラベリングの一形態です*5.情報の分野だと,オブジェクト指向プログラミング言語を何か習得してから,「デザインパターン」を学ぶことをお勧めします.

*1:連想するもの…数学の「べき集合」,火の鳥 未来編のコスモゾーン.

*2:3次元上の空間…「3次元」はたとえですが…で議論していると拡散して分かりにくいけれど,適当な平面で切り,その切断面に着目することで,実りある結果に至る,というケースもあります.

*3:その感情をレポートに直接書くべきかどうかは,レポート内容というか,教員の性格によるでしょうが.

*4:専門用語を使って通じないときに,専門用語を使わず説明できるようになればなおよしです.

*5:標準化作業で時間を費やすのは,細部の仕様などかもしれませんし,仕様変更による技術者への影響を過小評価するわけにはいきませんが.