Post(s) tagged "アウトプット"
シゴタノ! — 他人の興味関心フィルターを利用した情報収集/ビギナーズ・ハック第21回
TwitterやBLOGのRSSなど、特定の誰かのアウトプットをウォッチしておくことで、その人の興味関心フィルターを通した情報を得ることができます。それぞれチェックする対象によって得られる情報の鮮度や濃さが変わってくるのですが、例えばBLOGやはてなブックマークなどのアウトプットについてはTwitterにも更新情報を流すため、Twitterを見ていれば網羅的に情報を得ることができる可能性が高いです。(その人が情報を集約していない場合もあるので一概には言えないのですが)
Twitterのフォロワー、もしくはリストに自分がウォッチしたい人を集めておくことで、Twitterのタイムラインに自分にとっても興味の対象となり得る情報が流れてくる確率を高めることができます。
— 良い進捗報告のやり方 - 発声練習
- 教員にとって良い進捗報告
学生が行っている作業やプロジェクトが自分の研究のプロジェクトの一部であったり、研究室で取り組んでいるプロジェクトの場合とそうでない場合では教員にとって作業の進捗の意味がある程度変わる。前者の場合は、自分のプロジェクトの一環なので、作業やプロジェクトの進捗がそのまま自分のプロジェクトの進捗に反映されるので、より真剣に、場合によっては過剰に干渉して進捗状況を制御しようとする可能性がある。後者の場合は、学生が順調に卒業/修了できるかどうかが興味の焦点になるので、学生が援助を求めてきたならば援助しようという程度の干渉の可能性がある。ここいらへんは指導教員の性格による。
どちらの場合にしても、教員が知りたいのは「どこまで進んでいるか」と「援助は求められていないか」の2点。自分のプロジェクトの一部の場合には、研究者の性格的に「何か面白いことがおこっていないか」もすっごく知りたいことかもしれない。
よって、教員にとって良い進捗報告とは以下の条件を満たす報告。
- 作業やプロジェクトの進行状況が簡潔にかつわかりやすく説明されていること
- 作業やプロジェクトの進行を妨げる各種トラブルについて、明確に（かつ具体的に）提示されていること
- 作業やプロジェクトの遅れを取り戻すために必要な援助について明確にかつ具体的に提示されていること
- 報告者にとって良い進捗報告
報告者にとっては、今行っている作業やプロジェクトが自分のキャリアアップや技能習得、知識獲得に直接的につながっている場合と、卒業/修了のためにこなすべきタスクの場合の2通りの場合がありえる。前者の場合は、放っておいてもがんばれるので、目的はよりよい成果を得ること。後者の場合は、たいていモチベーションはあがらないので、とにかく課せられた（自分で課した）目標を達成することが目的となる。
どちらの場合も、作業やプロジェクトを遂行することが重要であり、そのためには自分の力でどうにもできないことやわからないことについての助言を適宜得られることが重要となる。また、作業の進め方やプロジェクトの管理の仕方などわからないことだらけなので、適宜、メタ研究の技術に関しても指導教員や先輩の支援が必要となる。
さらに、タスクとして作業やプロジェクトを進めている場合、何らかの締切りがないとモチベーションが維持できない。進捗報告は外部的なモチベーションとしても利用できる（だから、教員は進捗報告を定期的に課す）。
よって、報告者にとってよい進捗報告とは以下の条件を満たす報告。
- 前回の進捗報告から今回の報告までの自分の作業を振り返れること
- あらかじめたてていた研究計画と現状がどのくらい異なるのかを認識できること
- 作業やプロジェクトの進行を妨げる各種トラブルについて、解決策およびヒントが得られること
- 作業やプロジェクトの遅れを取り戻すために必要な援助が得られること
- 必ず進捗報告をしなければならないこと
- 他の学生にとって良い進捗報告
研究室ごとのやり方にもよるけれども、研究室のメンバーおよびプロジェクトのメンバーが全員集まって、進捗報告をしあうとき、他人の進捗報告を聞く学生にとってこの時間が無駄になるのは良くない。
他人の進捗報告を聞く学生は大きく分けて、報告者のプロジェクトに関連している学生とそうでない学生にわかれる。前者は、報告内容に興味があるので基本的に教員にとって良い報告ならば、その人たちにとっても良い報告となる。後者は、基本的には報告内容に興味がないので、工夫がなければ無駄な時間になってしまう。
一方で、研究のやり方、質問の仕方、プロジェクトの管理の仕方、分野における一般常識などはどのような作業を行っていようが有用なものである。報告者のプロジェクトに関連していない学生にとっては、これらを得ることができる報告が良い進捗報告となる。
よって、他の学生にとって良い進捗報告は以下の条件を満たす報告。
- 作業やプロジェクトの進行状況が簡潔にかつわかりやすく説明されていること
- 作業やプロジェクトの進行を妨げる各種トラブルについて、明確に（かつ具体的に）提示されていること
- 作業やプロジェクトの遅れを取り戻すために必要な援助について明確にかつ具体的に提示されていること
- プロジェクトの内容に精通していない人間でも、進捗報告を聴き続けることによって、そのプロジェクトの概略ぐらいは理解できること
- 作業を進めるのに有効だった道具や方法、プロジェクトを管理するのに使用している道具や方法を紹介してくれること
- 良い進捗報告とするために守らなければならないこと
報告者、指導教員、傍聴者の3者の誰にとっても良い進捗報告を行うためには以下のルールを守る必要がある。
- 報告者
- 嘘をつかない
- 隠し事をしない
- コメントのない進捗報告は良くない進捗報告であったと認識する
- コメントはすべて、報告した「事柄」「主張」に対するものであり、「私」に対するものでないと認識する
- 自分の作業やプロジェクトを進めるのが最優先、議論して他の人をやりこめることの優先度は低いことを認識する
- 指導教員
- 嘘をつかず、隠し事をしなかったという点を褒める
- 嘘をつかれたり、隠し事をされたりした場合は、そのことに深く傷ついたということを明確に報告者に伝える
- ネガティブな成果もちゃんと報告した事実を褒める。むしろ奨励する。
- 「人」でなく「事柄」「主張」についてコメントする
- 学生からの質問、意見を時間が許す限りどんどん奨励する
- 真剣に進捗報告を聞く、内職をしない。
- 傍聴者
- すべての進捗報告には自分を高めてくれるヒントが隠されていることを認識する
- どんな疑問も、あなたにとっては「つまらない疑問」ではないことを認識する
- 報告、質問、議論のよいところを学び、悪いところは反面教師として使う
- 進捗報告に含むべき内容
進捗報告ではアウトプットを見せること。頭で考えているというのはアウトプットではない。頭で考えているだけならば、何もしていないのと一緒。数式や文章、図で頭の中を外に出してはじめて「考えていました」と言える。（元ネタは消えてしまったので、私がその元ネタを知ったエントリー：DESIGN IT! w/LOVE：Fw：本当に考えたの？（それは「考えた」と言わない。））
アウトプットと言えるのはたとえば以下のもの。他人には見えない、触れない、聞こえないものはアウトプットとみなされない。
- 研究を行ううえでの学問的な課題や疑問
- （学問的なことに限らず）研究を行う上で今困っていること
- 文献調査の結果
- 実験方法（手順、環境、条件、試薬など具体的に）
- 実験結果（表やグラフで）
- 各種図や表
- 各種数式
- プログラミングコード
スライドには以下を含んだ方が良い。
- 前回指摘/助言された点についての対応について報告
- 前回報告時の作業計画
- 前回の報告から今回の報告までに行った作業の一覧
- 各作業の報告
- 各作業の概要（何を行ったのか？what）
- 作業の目的（なぜこの作業を行う必要があるのか、why）
- （必要に応じて）作業の具体的内容（どうやって行ったのか？How）
- 結果と評価（得られた結果は何で、目的をどの程度達成できたのか）
- （もしあれば）トラブル、疑問、相談したい点
- （1ヶ月に1度くらい）中期目的あるいは最終目的に今回の報告まででどの程度近づけたのかについて報告
- 次回報告時までの作業計画
- （発表時間に余裕があれば）トラブル、疑問、相談したい点の列挙
言い訳や決意表明ではなく、行った作業を説明すること。もし、何らかの事情で作業が進められていないときには、その理由をセットにして正直に報告すること。理由をセットにして欲しいのは、作業できない理由を指導教員の助力で取り除けるかどうかが知りたいため。別に「彼女/彼氏といちゃいちゃしすぎて研究なんてやってられませんでした」という理由を知りたいわけではない。
指導教員の考え方にもよるけれども、私の場合は理由と助力の仕方の関係は以下のとおり。
- 遊んじゃった
- →本人の責任なので特に助力なし。
- 勉学・就活・アルバイトなどで時間が足りなかった
- →継続的に発生する可能性があるのでスケジュール調整で対処を指示。
- 体調不良などで作業ができなかった
- →基本、本人の責任なので特に助力なし。要請があればリカバー方法を提案
- ハードウェア/ソフトウェア的トラブルで作業ができなかった
- →お金や交渉で解決可能ならば助力
- やる気がでなかった
- →継続的にこの理由であるならば相談にのり、場合によっては学内カウンセラーを紹介
- 研究上の難点に直面
- →一緒に解決法を考案
- その他
- →ケースバイケースで対応
- 進捗報告のやり方
報告者にとって進捗報告で重要なのは助言と援助をもらうことなので、これが得られやすいように最大限に配慮する。
- 口頭のみの発表は止める（発表スライドや配布資料をつくることで頭の整理を行えるし、これを論文や報告書に流用できるため）
- 発表スライドを使って発表する場合、細かすぎる情報は配布資料として別途配布する
- 録音機で自分の発表および質疑応答を録音する（iPhoneならボイスメモでOK。研究室になければMP3録音機を一台買ってもらうこと）
- 進捗報告後は、その日のうちにいただいた助言や指摘をメールでまとめて進捗報告会参加者全員に送ること
— 100冊読む時間があったら論文を100本「解剖」した方が良い 読書猿Classic: between / beyond readersアウトプットは、できればインプットと同じ水準のものがいい。
たとえば論文を読むなら、論文を書くつもりで読むこと。
そうなると内容を得るだけでは済まなくなる。
- どういった構成で書かれているか？
- どんな決まり文句や、つなぎの言葉が使われているか？
- 主張を支えているものは何か？
- データはどうやってつくられたのか？
- それにはどれくらいの時間とリソースが必要なのか？
- どの参考文献から、どんな一節が引用されているのか？
といった「こまごました」こともチェックすることになる。
何もかもを一度に読む取ることは難しいのなら（確かに難しいことだ）、内容が理解できたと思う論文を、今度は「書き手」の立場から再度（多分、繰り返し）読み返すこと。
だから読むのなら、再読に耐えるようなものがいい。
行なうのは、論文のリバース・エンジニアリングだ。
とことんバラバラに分解して、分解・解析の結果は、自分がすぐにでも利用可能なようにストックしておくこと。
最初は手間がかかるが、すぐに役立つ。
2 notes
感性に触れるもの
様々な興味
全てをクリップ
diverse interests
