司会: | キーワードを |
A: | 教育。次世代育成 |
B: | タイムスケール |
C: | 大学は2年だが、大プロジェクトは10年。 大学は一通り装置全体を俯瞰できるが、大プロジェクトでは要素が対象となる。 大学の技術開発は独自性だが大プロジェクトはfeasibility。大学は失敗が許されるが、大プロジェクトは国際公約。 そういう観点で性格が全く異なる。 |
D: | 装置にかかわっている学生がどのようにD論をとるのか。 |
E: | 教育というと、学生のモチベーションをどのように喚起するか。 さらにその先のキャリアパス。 |
B: | 失敗したときのプランBがいるのでは。 |
A: | 失敗してもそれで学位が取れればいいのではないか。 |
B: | 客観的に評価される世界なので、それではまずい。学振とかが通らないのでは。 |
C: | 自分の装置でデータが取れるか取れないかは大きい。 大型プロジェクトは約束できないのでは。 |
司会: | 大プロジェクトは大変。 X線プロジェクトはかっちりとやっている。スタッフがドキュメントに苦労。TMTもそう。 プロジェクトはどのようにすすんでいるのか→スライド System Engineering Lifecycle: 大学ではこれが非常に早く回る。TMTはこれが10年かかる。 この中で大学ができるのはどこか。一番手が足りないところは装置を作るところ。 装置のリストは2010から2016まで少しずつ変わってきている。 第2期装置ではまだレベル2のところがまだ何もない |
司会: | 今やっている大学のプロジェクトがTMTなどの大プロジェクトにつながっていっていないのはどうしてか。 TMTで複数の装置開発が走る状況になれば、複数のプロジェクトのライフサイクルが並列して走ることになる。 初期のプロジェクトと後期のプロジェクトが並行すれば、それなりに参加できるのではないか? |
F: | 結局大学は学生なので、学生として何を学びたいか、という視点が抜け落ちているのでは。 参加できる、といわれても、この図を見て学生が参加したいと思うか。 上から目線ではないか。 |
司会: | 参加しにくい部分はそのとおり。 具体的に何をやるのかが見えてこない。 |
F: | 大学にも問題がある。 教員は、自分の経験でやるので、実は大学内での学生が求めているものと教員が提供しているものはずれているのかもしれない。 皆さんの意見を聞きたい |
司会: | マッチするかは重要。個別事例になってしまうだろうが何かあるか? |
G: | 修士でテーマがまだないのであればまずやってみるのが重要。 そのうえでミスマッチが起こったら教員と話をすべき。 ミスマッチが起きてもそれを教員と話せる環境が構築されていれば問題ない。ただ、ある程度入り込まないとミスマッチかどうかの判断はできないかもしれない。半年~1年くらいは判断するのにかかるだろう。 修士の半年から1年でテーマを知ることによって向いてなければ変えても構わないし、逆に深く知ることで面白くなってきたりもする。 |
I: | 実際にはどのようにミスマッチを認識したのか?Fさんに聞きたい。 |
F: | テーマというよりも、そもそも求めているものがずれている場合があるのでは。 モノづくりをしたいときに自分で手を動かしたい、という場合があるだろうが、大プロジェクトとなるとシステムエンジニアリングになってしまい、求めているものとずれてしますということがないだろうか。 モノづくりをしたい人は結構一人でやりたいという人がおおいので。 |
司会: | 大きなプロジェクトになればなるほどSEが大事になる。同時に、就職の機会が高まる。そういうことを伝えていかないといけないのだろう。 メーカーの方は? |
H: | なぜ学生を使うのかがわからない。 失敗できず、納期がある大プロジェクトでは、学生を使うメリットはない。 大学の職員で継続できる人間を10年単位で採用して教育するのが一番確実。 |
司会: | その通り。大プロジェクトとしては学生をすぐ使うつもりはないが。 |
H: | 何らしかの目標があるところになぜエンジニアを使わないのか? 学生だと継続ができない。それは効率が悪いのではないか。 それをやらないといけない背景は何なのか |
J: |
欧米流のシステムにしたいと思っていながら、日本の天文コミュニティは大学院生やポスドクの労力に頼らざる得ないのが現状である。 自分が総研大に入学した1992年ころに、一期生が学位をとる頃(1995年)までには、ハワイ大学のIFA(Institute for Astronomy)等のように工学系の博士が望遠鏡の建設や装置開発の主体になるようなEngineering部門を、天文台にも作らなければならないと教授陣が公言していた。 現実は、そうならなかった。 |
企業(A): | 前提が理解できていないので、なかなかコメントがむつかしい。 教育としては、おおきなプロジェクトにかかわれるのはうらやましい。 直接なにかに結びつかなくとも、経験になればいいのでは |
企業(B): | 自分の経験。超伝導体の研究をやっていて企業に行ったが、その当時は下働きだとおもっていたが、携われたのが一つの経験だったのは実感。 |
C: | 大学側で不満を持っているところはどれくらいあるのか? 京大としてはあまり不満はない。あと天文台はなにか問題があるのか。双方何も言わなければ現状は変わらない。 |
司会: | おそらくTMTの人が不満。大学にもっと参加してほしいと思っている。 |
C: | どこに参加してほしいと思ってるのか? |
司会: | そこが明確になっていない。TMT側の宿題が大きいように思う。 ただ、ポイントとしては、TMTの装置をやるのはそれなりの人間が必要であろう。専門のプロを10年単位で雇用して開発する必要がある。 ただ、観測装置については、なんらかの形で科学者が拘わらないといけないだろう。 |
K: | PDとして、大規模なプロジェクトにかかわりたくとも、自分のやらないといけないことがたくさんありすぎで関われない。 協力関係が必要なのであれば、まずはポストがないと。 |
L: | TMT側で枠組みをクリアにする必要がある。 司会さんが紹介してくれたSystem EngineeringLifecycleにおいて、TMTや各装置の日本関係者が現状でどこの担当に相当するのかを名前入りで教えてもらえると人がより見えてイメージがわきやすいと思う。 今後どの部分で人を雇い、どの部分で大学に参加してもらうのがあり得るかなどを 示してもらえるとよいのではないか。大学は現状で参加・不参加の両者があって不満自体は少ないようだが、TMTからみると今が参加のチャンスということだろう。 大学側でも参加するかしないのかを明確に決断する必要があるだろう。 TMTとしては大学が参加しないとどこが困るのか、人を雇えば済むのか、が知りたい。 |
司会: | 個人的には装置にかかわるのはまだちょっと早いとおもう。 |
A: | やはり大学の参加を求めるのは、予算が足りないのか? また、あまり人材の公募が出ていないが、やはり予算が足りないのか? |
司会: | IRISについてはいまwork breakdownしつつあって、募集の準備をしているところではある。 |
M: | 議論がかみ合っていないのは、司会さんの説明では大学からサイエンス
へのインプットを求めているのに対し、この場に来ているのは装置開発に関心
を持ってきている人が多いからではないか。 あと、今回 TMT で進んでいる観測装置や望遠鏡の開発に関する発表が全然 なかったが、こういう機会を捉えて、課題となっていることを宣伝してもら うことが、関わるきっかけを作る可能性となる。 水を撒くような活動で、実 質的な芽が出るかどうかはわからないが、地道に宣伝を続けてもらいたい。 大型プロジェクトの開発はその道の技術者が行うという点はその通りである が、院生が関わるような道も作って、昨日の長谷川さんの講演にあった 50人に1人や10人に1人というアイデアのある人材も取り込めるというバランス のある体制も必要であると思う。 |
N: | 今回発表しなかったのはまずかった。 大学に参加してほしい理由は、大規模プロジェクトの進め方を感じてもらい、そういうプロジェクトを進める次世代を育てたいという意図があるのでは。 もちろんコアに学生は入れられないが、少しでもかかわってもらう意義があるのではないかと思う。 |
C: | マネジメントやる人は天文学者ではなくていいのではないか。 大学はボトムアップなので、TMT側が個別に大学を訪問して課題を共に議論していけば協力体制は自然と生まれる。そういった議論を見ている学生が興味を持つかもしれない。 それを大学は止はしない。Web上に課題をパッケージにして提示するようなことをしても大学は反応しないだろう。 |
司会: | 現場レベルでは始まりつつあるので、それを促進できれば。 議論をするにもそもそも情報が足りない部分があった |
H: | 大学が大プロジェクトに参加する意義はおおむね分かったが、これまでの議論は通常のプロセスでは考えられない。 それでもやるというのであれば、それは学生に対して圧倒的な情熱と熱意で示すしかない。これは理屈ではない。 |
O: | TMTは大学には荷が重いと感じていた。むつかしい。 |
司会: | TMTへはいろんなアプローチがありうるので、どういう形で日本で作り上げるかという手続きはもうすこしあるかもしれない。 |
N: | コアの部分を学生に任せるわけにはいかないが、ブレイクダウンした個別の小さな技術課題は学生でも十分に対応できる。 ただ、そのような技術課題はプロジェクトを進めているなかで持ち上がってくるので、 いつ持ち上がるか予想できずワークパッケージとして準備しにくいのが 問題である。 |